6 ms·

These tokens, like the OneRNG, are quite interesting from an engineering point of view, but as a developer all you ever need to know or do about secure randomne

These tokens, like the OneRNG, are quite interesting from an engineering point of view, but as a developer all you ever need to know or do about secure randomness is to use /dev/urandom and nothing else (unless it's a wrapper for /dev/urandom). Not /dev/random, not rand(), not something you found in a library. Just bytes, read from /dev/urandom. Here is my CCC talk about why that is, which includes everything from kernel sources to authoritative quotes: https://media.ccc.de/v/32c3-7441-the_plain_simple_reality_of_entropy https://media.ccc.de/v/32c3-7441-the_plain_simple_reality_of... EDIT: the talk is in English, but you have to select it from the video UI, in the bottom right.

deleted 10y ago
[deleted]
nine_k 10y ago
I wonder what to use on Windows. Because sometimes you maybe need robust randomness on a popular desktop.
- FiloSottile 10y ago
  CryptGenRandom. It's the Windows equivalent of /dev/urandom.
- veeti 10y ago
  CryptGenRandom [1] would be the equivalent. [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa379942(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...
  - cpeterso 10y ago
    Or rand_s(), which wraps CryptGenRandom() with a more convenient API: https://msdn.microsoft.com/en-us/library/sxtz2fa8.aspx https://msdn.microsoft.com/en-us/library/sxtz2fa8.aspx
    - ryuuchin 10y ago
      RtlGenRandom[1] is probably the most convenient way on Windows. Does require certain definitions when including the header file for it[2] but otherwise does not require a CSP context and can generate any number of CSPRNG bytes. [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa387694(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... [2] https://boringssl.googlesource.com/boringssl/+/master/crypto/rand/windows.c#26 https://boringssl.googlesource.com/boringssl/+/master/crypto...
      - cpeterso 10y ago
        You're right. Calling RtlGenRandom() directly is probably the best option. I forgot that rand_s() calls RtlGenRandom(), not CryptGenRandom(). Plus both Firefox and Chrome ran into rare crashes when some bad third-party software (antivirus or malware) injects advapi32.dll hooks, causing rand_s() to crash when it tries to load advapi32.dll in order to call RtlGenRandom(). Firefox bugs: https://bugzil.la/1240589 https://bugzil.la/1240589, https://bugzil.la/1167248 https://bugzil.la/1167248, https://bugzil.la/694344 https://bugzil.la/694344 Chrome bug: https://crbug.com/348400 https://crbug.com/348400
        ryuuchin 10y ago
        You can also specify the number of bytes you want with RtlGenRandom. rand_s only gives an unsigned int per call. Not a huge deal but you may be able to cut down on some function call overhead depending on how stuff gets inlined/optimized.
- PascLeRasc 10y ago
  Ubuntu is a pretty good distro to start using linux with, try that.
  - darkstar999 10y ago
    You're missing the point. Sometimes you need to write software for Windows users.
- ryuuchin 10y ago
  CryptGenRandom[1] or RtlGenRandom[2]. Although CryptGenRandom is the offical version they probably would rather you use I'm fairly certain that most people are more likely to use RtlGenRandom because it's accessing the same thing but doesn't require a CSP context in order to use it (you can just call it straight up). You have to include ntsecapi.h with some fixing definitions[3] to use RtlGenRandom. [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa379942(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... [2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa387694(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... [3] https://boringssl.googlesource.com/boringssl/+/master/crypto/rand/windows.c#26 https://boringssl.googlesource.com/boringssl/+/master/crypto...
Nrsolis 10y ago
There is this too: http://ubld.it/products/truerng-hardware-random-number-generator/ http://ubld.it/products/truerng-hardware-random-number-gener...
nickpsecurity 10y ago
High-assurance security products (eg Type 1 NSA stuff) have always relied on verifiable or dedicated RNG's. Typically TRNG's. Here's some reasons: 1. Easier to trust one based on physics with decades of verification of its behavior vs mathematical constructions with vastly less certainty or verification of correctness. 2. Bit-flips or EMI on internal state might affect a software algorithm's randomness. Won't happen with certain types of analog noise with carefully tuned and measured circuits. 3. Can verify the circuits do exactly what I expect by eye and hand with a logic analyzer. No speculation due to No 1. Can then trust that circuit as a pluggable component in any other system without further evaluation. 4. Building on above, a compromise of the host PC requires me to recover the host but not dedicated chips like the TRNG or proper HSM. I can still trust them if they have no firmware (eg analog TRNG) or it's not write-able. 5. Using Nizza Architecture, I can put Linux in an untrusted partition with crypto/CRNG/secure-storage directly on microkernel in dedicated, isolated partition. TRNG HW or dedicated crypto SOC gives me this plus benefits above. So, the difference between high-assurance setup with HW support for security-critical functions and software on an untrustworthy box... probably x86 with its vPro backdoor circuitry... is pretty astounding in capabilities. Seeing the differences & how cheap you can do that stuff should make anyone wonder why it's not standard in security-focused projects.
- FiloSottile 10y ago
  I've never worked on state-level appliances, so thank you for the information, but just for the sake of stopping urandom-fear, let me spell out why this all does not apply to the 99% of us developing for consumer processor architectures (which I'm sure you realize): - the "uncertain mathematical constructions" are hashes. More precisely, in Linux case, SHA-1 preimage (not collision) security. No civilian cryptosystem would survive the fall of hashes. - all other points are void as soon as you use that randomness from a regular application running on regular CPUs, as all the bit-flips, compromises and backdoors can simply happen there. - having the keys on hardware DOES make compromise recovery much easier, but there we are speaking of HSM capable of doing the private key operations themselves, not simply providing randomness.
  - nickpsecurity 10y ago
atoponce 10y ago
Well, you do need to seed /dev/urandom with sufficient entropy. Hardware random number generators work here. After it's seeded, my only concern would be backtracking resistence, but haveged(8) works well here.
- FiloSottile 10y ago
  Yes, but no. The kernel and the OS will take care of seeding for you, and haveged can't create out of thin air any unpredictable events that are somehow invisible to the kernel. Anyway, Linux urandom is backtracking safe as long as SHA-1 preimage security holds.
  - atoponce 10y ago
    Well, not all Linux hardware provides sufficient entropy on first boot, such as solid-state embedded hardware or virtual machines. The CSPRNG will happily provide random bits regardless of initial seeding or not. Flip a coin 512 times, record the results, and "echo tththhhhthh... > /dev/random". Most people don't want to do this, so hardware RNGs simplify this. If only the Linux kernel used as entropy everything that was available to it. That's the pitch of haveged(8) I think. There are significantly more timing events the kernel could use for input entropy that it's not. It would be great to see these timing events land in random.c, but they're not there. Lastly, slightly off-topic, but the Linux CSPRNG is poorly designed. In reality, while preimage SHA-1 might still have a sufficient security margin, it suffers from poor performance due to ad-hoc design. Instead, using AES-128 CTR_DRBG with AES-NI would give the kernel CSPRNG a much needed performance boost, provide backtracking resistence, and remain secure. Current testing shows it could improve from 20 MiBps to 2 GiBps.
    - ryuuchin 10y ago
      > Instead, using AES-128 CTR_DRBG Just for comparison this is what Windows does[1] for it's PRNG stuff (in Vista SP1 and newer at least). It uses AES256 in CTR mode as a DRNG[2]. [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa379942(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... [2] NIST 800-90
trollingineeer 10y ago
HackerNews - where everyone needs to compare the size of their diminutive e-penis.
cnvogel 10y ago
> use /dev/urandom and nothing else Or the getrandom() syscall, once it has trickled into all mainstream distributions' libcs. Which is basically /dev/random, but without the need to open() and close() the device first and after you've consumed your entropy. http://man7.org/linux/man-pages/man2/getrandom.2.html http://man7.org/linux/man-pages/man2/getrandom.2.html

deleted 10y ago

[deleted]

nine_k 10y ago

I wonder what to use on Windows. Because sometimes you maybe need robust randomness on a popular desktop.

FiloSottile 10y ago
CryptGenRandom. It's the Windows equivalent of /dev/urandom.
veeti 10y ago
CryptGenRandom [1] would be the equivalent. [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa379942(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...
- cpeterso 10y ago
  Or rand_s(), which wraps CryptGenRandom() with a more convenient API: https://msdn.microsoft.com/en-us/library/sxtz2fa8.aspx https://msdn.microsoft.com/en-us/library/sxtz2fa8.aspx
  - ryuuchin 10y ago
    RtlGenRandom[1] is probably the most convenient way on Windows. Does require certain definitions when including the header file for it[2] but otherwise does not require a CSP context and can generate any number of CSPRNG bytes. [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa387694(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... [2] https://boringssl.googlesource.com/boringssl/+/master/crypto/rand/windows.c#26 https://boringssl.googlesource.com/boringssl/+/master/crypto...
    - cpeterso 10y ago
      You're right. Calling RtlGenRandom() directly is probably the best option. I forgot that rand_s() calls RtlGenRandom(), not CryptGenRandom(). Plus both Firefox and Chrome ran into rare crashes when some bad third-party software (antivirus or malware) injects advapi32.dll hooks, causing rand_s() to crash when it tries to load advapi32.dll in order to call RtlGenRandom(). Firefox bugs: https://bugzil.la/1240589 https://bugzil.la/1240589, https://bugzil.la/1167248 https://bugzil.la/1167248, https://bugzil.la/694344 https://bugzil.la/694344 Chrome bug: https://crbug.com/348400 https://crbug.com/348400
      - ryuuchin 10y ago
        You can also specify the number of bytes you want with RtlGenRandom. rand_s only gives an unsigned int per call. Not a huge deal but you may be able to cut down on some function call overhead depending on how stuff gets inlined/optimized.
PascLeRasc 10y ago
Ubuntu is a pretty good distro to start using linux with, try that.
- darkstar999 10y ago
  You're missing the point. Sometimes you need to write software for Windows users.
ryuuchin 10y ago
CryptGenRandom[1] or RtlGenRandom[2]. Although CryptGenRandom is the offical version they probably would rather you use I'm fairly certain that most people are more likely to use RtlGenRandom because it's accessing the same thing but doesn't require a CSP context in order to use it (you can just call it straight up). You have to include ntsecapi.h with some fixing definitions[3] to use RtlGenRandom. [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa379942(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... [2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa387694(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... [3] https://boringssl.googlesource.com/boringssl/+/master/crypto/rand/windows.c#26 https://boringssl.googlesource.com/boringssl/+/master/crypto...

Nrsolis 10y ago

There is this too: http://ubld.it/products/truerng-hardware-random-number-generator/ http://ubld.it/products/truerng-hardware-random-number-gener...

nickpsecurity 10y ago

High-assurance security products (eg Type 1 NSA stuff) have always relied on verifiable or dedicated RNG's. Typically TRNG's. Here's some reasons: 1. Easier to trust one based on physics with decades of verification of its behavior vs mathematical constructions with vastly less certainty or verification of correctness. 2. Bit-flips or EMI on internal state might affect a software algorithm's randomness. Won't happen with certain types of analog noise with carefully tuned and measured circuits. 3. Can verify the circuits do exactly what I expect by eye and hand with a logic analyzer. No speculation due to No 1. Can then trust that circuit as a pluggable component in any other system without further evaluation. 4. Building on above, a compromise of the host PC requires me to recover the host but not dedicated chips like the TRNG or proper HSM. I can still trust them if they have no firmware (eg analog TRNG) or it's not write-able. 5. Using Nizza Architecture, I can put Linux in an untrusted partition with crypto/CRNG/secure-storage directly on microkernel in dedicated, isolated partition. TRNG HW or dedicated crypto SOC gives me this plus benefits above. So, the difference between high-assurance setup with HW support for security-critical functions and software on an untrustworthy box... probably x86 with its vPro backdoor circuitry... is pretty astounding in capabilities. Seeing the differences & how cheap you can do that stuff should make anyone wonder why it's not standard in security-focused projects.

FiloSottile 10y ago
I've never worked on state-level appliances, so thank you for the information, but just for the sake of stopping urandom-fear, let me spell out why this all does not apply to the 99% of us developing for consumer processor architectures (which I'm sure you realize): - the "uncertain mathematical constructions" are hashes. More precisely, in Linux case, SHA-1 preimage (not collision) security. No civilian cryptosystem would survive the fall of hashes. - all other points are void as soon as you use that randomness from a regular application running on regular CPUs, as all the bit-flips, compromises and backdoors can simply happen there. - having the keys on hardware DOES make compromise recovery much easier, but there we are speaking of HSM capable of doing the private key operations themselves, not simply providing randomness.
- nickpsecurity 10y ago

atoponce 10y ago

Well, you do need to seed /dev/urandom with sufficient entropy. Hardware random number generators work here. After it's seeded, my only concern would be backtracking resistence, but haveged(8) works well here.

FiloSottile 10y ago
Yes, but no. The kernel and the OS will take care of seeding for you, and haveged can't create out of thin air any unpredictable events that are somehow invisible to the kernel. Anyway, Linux urandom is backtracking safe as long as SHA-1 preimage security holds.
- atoponce 10y ago
  Well, not all Linux hardware provides sufficient entropy on first boot, such as solid-state embedded hardware or virtual machines. The CSPRNG will happily provide random bits regardless of initial seeding or not. Flip a coin 512 times, record the results, and "echo tththhhhthh... > /dev/random". Most people don't want to do this, so hardware RNGs simplify this. If only the Linux kernel used as entropy everything that was available to it. That's the pitch of haveged(8) I think. There are significantly more timing events the kernel could use for input entropy that it's not. It would be great to see these timing events land in random.c, but they're not there. Lastly, slightly off-topic, but the Linux CSPRNG is poorly designed. In reality, while preimage SHA-1 might still have a sufficient security margin, it suffers from poor performance due to ad-hoc design. Instead, using AES-128 CTR_DRBG with AES-NI would give the kernel CSPRNG a much needed performance boost, provide backtracking resistence, and remain secure. Current testing shows it could improve from 20 MiBps to 2 GiBps.
  - ryuuchin 10y ago
    > Instead, using AES-128 CTR_DRBG Just for comparison this is what Windows does[1] for it's PRNG stuff (in Vista SP1 and newer at least). It uses AES256 in CTR mode as a DRNG[2]. [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa379942(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... [2] NIST 800-90

trollingineeer 10y ago

HackerNews - where everyone needs to compare the size of their diminutive e-penis.

cnvogel 10y ago

> use /dev/urandom and nothing else Or the getrandom() syscall, once it has trickled into all mainstream distributions' libcs. Which is basically /dev/random, but without the need to open() and close() the device first and after you've consumed your entropy. http://man7.org/linux/man-pages/man2/getrandom.2.html http://man7.org/linux/man-pages/man2/getrandom.2.html