4
$\begingroup$

I read somewhere that TRNGs are better than cryptographic algorithms that generate pseudo-random numbers (PRNGs) because these algorithms are more energy intensive than TRNGs.

By low power devices, I mean things with limited computational capacity or limited power. Like a small IOT device.

Would there be any benefit to using TRNGs in those? If we don't use TRNGs in them, why is that? And if we do, which ones are the gold standard?

$\endgroup$
6
  • $\begingroup$ If you ask for "the best" then the question is likely due to be closed as opinionated. However, there are probably objective criteria here to choose one over the other. Especially for IoT I'd hope for a CPU internal RNG as external RNG's are more prone to attacks if the device is accessible to adversaries. I'm not sure if there are any papers on which entropy source is best for that though. $\endgroup$
    – Maarten Bodewes
    Aug 23 at 8:12
  • $\begingroup$ Obviously, just a PRNG is insufficient, as they cannot create entropy themselves; you need something else to generate the initial entropy. $\endgroup$
    – poncho
    Aug 23 at 12:27
  • $\begingroup$ @MaartenBodewes can you link me to any papers about "Especially for IoT I'd hope for a CPU internal RNG as external RNG's are more prone to attacks if the device is accessible to adversaries." $\endgroup$ Aug 23 at 12:37
  • $\begingroup$ No, but since the simplest thing would just to disable the RNG, should I really have to? $\endgroup$
    – Maarten Bodewes
    Aug 23 at 16:53
  • $\begingroup$ Do you think that this question might be more focused if we considered milliwatts per mm2? We need numbers. b degnan ; your domain... $\endgroup$
    – Paul Uszak
    Aug 24 at 23:11

4 Answers 4

4
$\begingroup$

TRNGs are better than cryptographic algorithms that generate pseudo-random numbers (PRNGs) because these algorithms are more energy intensive than TRNGs

Random number generation in IoT devices is necessary and challenging, with many proposed solutions. However, any modern computing system (including IoT devices) will have some kind of TRNG if they need random numbers. Albeit, the minimum entropy (also discussed here) that can be extracted from each type of random event, in any set amount of time, may vary widely between each. TRNGs on their own are typically not suitable for many cryptographic uses, because the trueness(0)(1) of their randomness does not imply the non-bias uniformity of their outputs. This non-uniformity may be of particular issue when translating from a measurement domain (for instance $\mathbb R$) to the domain of requested randomness (usually, but not limited to, $\subset \mathbb N_0$).

The approach is almost always to use both TRNGs, to sample randomness, and PRNGs, to mix new randomness with stored randomness into unique, unguessable, uniform(2) and statistically independent(3) outputs. In such a system, which is well-designed and implemented, having access to any number of outputs should not help in guessing past or future outputs. If a system is only using a TRNG with no kind of PRNG, I would be highly suspect, even if the TRNG is shown to be less energy intensive.

Would there be any benefit to using TRNGs in those? If we don't use TRNGs in them, why is that?

We do, and they are very useful, as explained above.

And if we do, which ones are the gold standard?

There are many great sources of true randomness. But any one of them may fail, or otherwise be insufficient due to speed of generation, quality or unavailability (malicious or incidental). The standard(4) is to use collections of TRNGs together to minimize the chance of catastrophic failure.

enter image description here

Fig. 1 | Illustration of a typical entropy life-cycle management system.

It's generally accepted that the faster, more uniformly distributed, more entropic and more efficient, the better. But the point of using PRNGs and TRNGs together, perhaps to create a CSPRNG, is that: Once enough initial randomness has been acquired, speed, uniformity and entropy can be gained by continuously seeding the pools with even rather low-quality TRNGs, and then extracting outputs using an efficient PRNG, such as a light-weight symmetric cipher or hash function.

$\endgroup$
0
4
$\begingroup$

Without boring you with the actual hardware details, IoT devices do not generally have the classic entropy pools that exist in modern OSes. IoT is also a broadly loaded term, as I can make two passively-powered RFID devices communicate, which thereby makes it an IoT-class of system.

The primary source of randomness that you can harvest in a transistor circuit from two-way shot-noise (note: this is not Johnson noise!), or using a resistor and amply it (that one is Johnson noise). Using a power-on of an appropriately designed circuit will give you purely random number. Generally, I will create a bunch of these based on the bus-width of the system and then run them through a hash to make them whatever length that I need. These circuits are usually specific to the application, and you cannot have a general solution as silicon costs money, so you'll try to make the smallest thing possible.

$\endgroup$
3
  • $\begingroup$ "and then run them through a hash to make them whatever length that I need" do you mean a XOF or a hash that has at least the size of the register / data line? $\endgroup$
    – Maarten Bodewes
    Aug 24 at 22:31
  • $\begingroup$ I too am bored. The fourth Indictment? I cry. But isn't the standard on all digital attempts ring oscillators? Not shot noise. Wobble it about and suck it? $\endgroup$
    – Paul Uszak
    Aug 24 at 22:44
  • 1
    $\begingroup$ @MaartenBodewes I generally use BLAKE2-256 as it has good physical size (And I have the tool chain). For example, if I need a 256-bit word and a 16-bit TRNG, I'll generate it by doing an XOR into the bottom 16-bits of the register, and executing the BLAKE2 algorithm, and repeat 15 more times. I've settled on BLAKE2, curve22519, and AES (unless I'm doing RF with fast clocks, and then I use SIMON) $\endgroup$
    – b degnan
    Aug 24 at 23:50
2
$\begingroup$

I read somewhere that TRNGs are better than cryptographic algorithms that generate pseudo-random numbers (PRNGs) because these algorithms are more energy intensive than TRNGs.

Well, that depends which PRNG & TRNG is used of course. Earlier implementations often used the keystream generated using a lightweight stream cipher for instance. Using the NIST approved algorithms (based on block ciphers or hash functions) certainly will draw more power. It also depends on the TRNG used I presume; if it is slow it'll probably draw more power per bit.

By low power devices, I mean things with limited computational capacity or limited power. Like a small IOT device.

Many cheap / small CPU's may not have a TRNG build in. Nor may they have acceleration for block ciphers and / or hash functions. Still, it will be possible to retrieve some entropy using CPU or memory timing delta's and such. All in all, which one is best performant / most efficient depends on the CPU.

Would there be any benefit to using TRNGs in those? If we don't use TRNGs in them, why is that? And if we do, which ones are the gold standard?

Especially for IoT you'd probably have to depend on the network or CPU delta timings, if no TRNG is implemented in the CPU.

Note that generally you'd need some kind of processing or whitening to happen after extracting entropy. TRNG's may not produce the kind of distribution that you're after. TRNG's are not necessarily better nor faster than a well-seeded PRNG.

$\endgroup$
2
  • $\begingroup$ "CPU delta timings" what is this formally called? I cant find any papers that talk about this. I am sure it is a thing, I am just unable to find it. $\endgroup$ Aug 25 at 8:41
  • 1
    $\begingroup$ I guess that the better term would be "Timing Jitter". This can be performed using CPU, memory, interrupt or network timing information. Of course, having a TRNG based on electronic noise will always be better, but beggers can't be choosers. If you have an isolated SoC you'll have to base entropy on something. Basically you'd just generate a seed using these methods and then rely on a PRNG. $\endgroup$
    – Maarten Bodewes
    Aug 25 at 15:10
0
$\begingroup$

As noted in other answers, you need a good source of randomness these days. Taking numbers from a cryptographic pseudo random number generator works well. That PRNG needs initialising from some entropy source. In embedded systems, there is not the option of using user generated entropy, so a TRNG is necessary.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.