4 ms·

Wonderful exposition. One nitpick: please do NOT suggest seeding random functions with &main. Although ASLR is widespread, it is by no means guaranteed, and the

Wonderful exposition. One nitpick: please do NOT suggest seeding random functions with &main. Although ASLR is widespread, it is by no means guaranteed, and the default compilation options on many platforms will still produce non-PIE executables. This would render your seed completely static. A separate problem is that ASLR on some platforms has limited entropy. For example, on 32-bit Linux platforms the executable randomness has between 8 and 16 bits of entropy - which means your program would only ever have a small, finite range of possible random streams (16 bits correlating to less than 1 day of time() output taken once per second). Don’t rely on ASLR for randomness. At best it can be used as an additional source of random data. The C standard provides no mechanism for obtaining high quality entropy, as some environments (especially freestanding ones) may be unable to offer such randomness.

loeg 8y ago
On recent unix-likes, use getrandom() or getentropy(). On Windows, use CryptGenRandom, RtlGenRandom, or BCryptGenRandom (I'm not very familiar with Windows, sorry).
- loup-vaillant 8y ago
  And on embedded systems with no RNG in sight, use a deterministic random number generator, with a seed generated from another system. Use fast key erasure to ensure forward secrecy. https://blog.cr.yp.to/20170723-random.html https://blog.cr.yp.to/20170723-random.html If the device ever powers down, you will need 32 bytes worth of persistent storage, so you don't repeat the random stream every time you boot up.
  - loeg 8y ago
    I don't think this advice is really detailed enough to cover the breadth of the embedded space and/or comes with enough caveats about lack of writeable storage and reused keys. Also, sometimes people use 'embedded' to refer to things that are really full-sized computers (e.g., ARM with ordinary read/write storage), and on those you should just use ordinary CSPRNG implementations like Fortuna (which is not deterministic but does implement key erasure).
    - loup-vaillant 8y ago
      > I don't think this advice is really detailed enough to cover the breadth of the embedded space and/or comes with enough caveats about lack of writeable storage and reused keys. I believe the link I gave is. I highly recommend you read it. It's from a trustworthy author (Daniel Bernstein): https://blog.cr.yp.to/20170723-random.html https://blog.cr.yp.to/20170723-random.html
  - dfox 8y ago
    I believe that there is no such a thing as useful system without any viable source of entropy. Any useful system has to communicate with something and has to have at least some vague idea of passing of time and thus you can hash timing and contents of outside communication into your preferably persistent entropy pool.
    - loeg 8y ago
      Ah, thank you. This is a good summary of another problem I had with the comment we're both replying to, that I had trouble voicing. The assumption that there is no entropy available almost directly contradicts the idea of using cryptographic random data for almost any purpose. I'm having trouble imagining a use case but I don't think it's entirely impossible one exists.
      - loup-vaillant 8y ago
        > The assumption that there is no entropy available almost directly contradicts the idea of using cryptographic random data for almost any purpose Strictly speaking, that's correct. For practical purposes however, all you need is 256 bits of entropy. From there, you can generate an unbounded stream of independent random streams, which you can use for your crypto stuff. You don't need to re-seed. Ever. How do you think stream cipher work? You start from 256 random bits, and you generate a virtually unbounded random stream that encrypts your message. The use case of this scheme is mainly reducing the attack surface. Not re-seeding prevents some attacks, detailed in the link I gave above.
        loeg 8y ago
        > For practical purposes however, all you need is 256 bits of entropy. You need 256 bits of entropy and permanent, reliable power; or permanently writable and reliable media. You haven't addressed the bit where you're presenting a solution in search of a problem. > You don't need to re-seed. Ever. How do you think stream cipher work? I'm quite familiar with random devices (i.e., Fortuna) and stream ciphers, thank you.

loeg 8y ago

On recent unix-likes, use getrandom() or getentropy(). On Windows, use CryptGenRandom, RtlGenRandom, or BCryptGenRandom (I'm not very familiar with Windows, sorry).

loup-vaillant 8y ago
And on embedded systems with no RNG in sight, use a deterministic random number generator, with a seed generated from another system. Use fast key erasure to ensure forward secrecy. https://blog.cr.yp.to/20170723-random.html https://blog.cr.yp.to/20170723-random.html If the device ever powers down, you will need 32 bytes worth of persistent storage, so you don't repeat the random stream every time you boot up.
- loeg 8y ago
  I don't think this advice is really detailed enough to cover the breadth of the embedded space and/or comes with enough caveats about lack of writeable storage and reused keys. Also, sometimes people use 'embedded' to refer to things that are really full-sized computers (e.g., ARM with ordinary read/write storage), and on those you should just use ordinary CSPRNG implementations like Fortuna (which is not deterministic but does implement key erasure).
  - loup-vaillant 8y ago
    > I don't think this advice is really detailed enough to cover the breadth of the embedded space and/or comes with enough caveats about lack of writeable storage and reused keys. I believe the link I gave is. I highly recommend you read it. It's from a trustworthy author (Daniel Bernstein): https://blog.cr.yp.to/20170723-random.html https://blog.cr.yp.to/20170723-random.html
- dfox 8y ago
  I believe that there is no such a thing as useful system without any viable source of entropy. Any useful system has to communicate with something and has to have at least some vague idea of passing of time and thus you can hash timing and contents of outside communication into your preferably persistent entropy pool.
  - loeg 8y ago
    Ah, thank you. This is a good summary of another problem I had with the comment we're both replying to, that I had trouble voicing. The assumption that there is no entropy available almost directly contradicts the idea of using cryptographic random data for almost any purpose. I'm having trouble imagining a use case but I don't think it's entirely impossible one exists.
    - loup-vaillant 8y ago
      > The assumption that there is no entropy available almost directly contradicts the idea of using cryptographic random data for almost any purpose Strictly speaking, that's correct. For practical purposes however, all you need is 256 bits of entropy. From there, you can generate an unbounded stream of independent random streams, which you can use for your crypto stuff. You don't need to re-seed. Ever. How do you think stream cipher work? You start from 256 random bits, and you generate a virtually unbounded random stream that encrypts your message. The use case of this scheme is mainly reducing the attack surface. Not re-seeding prevents some attacks, detailed in the link I gave above.
      - loeg 8y ago
        > For practical purposes however, all you need is 256 bits of entropy. You need 256 bits of entropy and permanent, reliable power; or permanently writable and reliable media. You haven't addressed the bit where you're presenting a solution in search of a problem. > You don't need to re-seed. Ever. How do you think stream cipher work? I'm quite familiar with random devices (i.e., Fortuna) and stream ciphers, thank you.