5 ms·

What argument are you referring to?

jacobush 7y ago
That you must never use urandom for serious stuff?
geofft 7y ago
The question of whether "true random numbers" as defined by this weird government standard exist. More fundamentally, an important conceptual part of crypto is that you can use a random key of a very small, fixed size, like 16 bytes, to generate an infinite amount of output, such that knowing any part of the output doesn't help you guess at any other part of the output nor the input key. If true, this is an amazingly powerful property because you can securely exchange (or derive) a short key once and then you can send as much encrypted data back and forth as you want. If you needed to re-seed the input with as many bits as you take from the output, disk encryption wouldn't be sound (you'd need a key or passphrase as long as your disk), SSL would be way more expensive (and couldn't be forward-secure) if it even worked at all, Kerberos wouldn't work, Signal wouldn't work, etc. The claim of /dev/random and this wacky government standard is that in fact disk encryption, SSL, etc. are flawed designs, good enough for securing a single communication but suboptimal because they encrypt more bits of data than the size of the random key, and so when generating random keys, you really ought to use "true random numbers" so that breaking one SSL connection doesn't help you break another. Whether it's a pen-and-paper cipher like Vigenère or a fancy modern algorithm like AES, anything with a fixed-size key can be cryptanalyzed and you shouldn't provide too much output with it, for your secure stuff you must use a one-time pad. The claim of the cryptography community is that, no, in fact, there's nothing flawed about this approach and stretching fixed-size keys is the very miracle of cryptography. We know how to do it securely for any worthwhile definition of "securely" (including definitions where quantum computers are relevant) and we should, because key-based encryption has changed our world for the better.
- throw0101a 7y ago
  > ... like 16 bytes, to generate an infinite amount of output, such that knowing any part of the output doesn't help you guess at any other part of the output nor the input key. Isn't that the theory behind every stream cipher? (And stream ciphers are generally just 'simplified' one-time pads.) That's what OpenBSD's arc4random(4) start as: the output of RC4.
  - cosarara 7y ago
    From a more recent OpenBSD man page: > The original version of this random number generator used the RC4 (also known as ARC4) algorithm. In OpenBSD 5.5 it was replaced with the ChaCha20 cipher, and it may be replaced again in the future as cryptographic techniques advance. A good mnemonic is “A Replacement Call for Random”.
  - ben_bai 7y ago
    Yep. The OpenBSD bootloader reads an entropy file from hard disk, mixes it with RDRAND from CPU (if available) and passes it to the Kernel. The Kernel starts an ChaCha20 stream cipher with this supplied entropy while constantly mixing in timing entropy from devices. This chipherstream supplies the Kernel with random data and once userland is up this is good enought and also used for /dev/random and /dev/urandom, which on OpenBSB is the same device(non blocking). Now the fun part: When a userland process gets created it has a randomdata ELF segment that the Kernel fills and which is used as entropy for a new ChaCha20 stream, just for the application should it decide to call arc4random or use random data in any other way (like calling malloc or free, which on OpenBSD make heavy use of random data).
    - throw0101a 7y ago
      > When a userland process gets created it has a randomdata ELF ... This is news to me. When did they add this (neat) functionality?
      - notaplumber 7y ago
        In 2012, first release 5.3 in 2013. Added by Matthew Dempsky. It was used for the per-shared object stack protector cookie extended for the per-function cookies required for RETGUARD. https://github.com/openbsd/src/blob/master/libexec/ld.so/SPECS.randomdata https://github.com/openbsd/src/blob/master/libexec/ld.so/SPE... https://www.openbsd.org/innovations.html https://www.openbsd.org/innovations.html No other OS has this.
        geofft 7y ago
ATsch 7y ago
The idea of "randomness" being "used up", and then "running out of randomness", somehow. So let's look at how a hypothetical CSPRNG might work. We get our random numbers by repeatedly hashing a pool of bytes, and then feeding the result, and various somewhat random events, back into the pool. Since our hash does not leak any information about the input (if it did, we'd have much bigger problems), this means attackers must guess, bit for bit, what the value of the internal pool of entropy is. This is essentially how randomness works on Linux (they just use a stream cipher instead for performance) This clarifies a few things: 1. even if you assume intels randomness instructions are compromised, it still is not an issue to stirr them into the pool. Attackers need to guess every single source of randomness. 2. "Running out of randomness" is nonsensical. If you couldn't guess the exact pool before, you can't suddenly start guessing the pool after pulling out 200 exabytes of randomness either.
- throw0101a 7y ago
  > 2. "Running out of randomness" is nonsensical. If you couldn't guess the exact pool before, you can't suddenly start guessing the pool after pulling out 200 exabytes of randomness either. Not entirely. /dev/random and arc4random(4) under OpenBSD originally used the output of RC4, which has a finite state size: * https://en.wikipedia.org/wiki/RC4 https://en.wikipedia.org/wiki/RC4 Rekeying / mixing up the state semi-regularly would reset things. It's the occasional shuffling that really helps with forward security, especially if a system has been compromised at the kernel level.
  - tptacek 7y ago
    No, Arc4random didn't reveal its internal RC4 state as it ran, in the same sense that actually encrypting with RC4 doesn't deplete RC4's internal state.
    - cperciva 7y ago
      Many implementations didn't do enough mixing before generating output, though. Also, when you look at cache side channel attacks -- RC4 definitely publishes its internal state.
Rebelgecko 7y ago
that /dev/random must be better than /dev/urandom because it blocks until there's "enough" entropy (where "enough" is a huge misnomer and not really something you need as long as you're using a modern OS)

That you must never use urandom for serious stuff?

The question of whether "true random numbers" as defined by this weird government standard exist. More fundamentally, an important conceptual part of crypto is that you can use a random key of a very small, fixed size, like 16 bytes, to generate an infinite amount of output, such that knowing any part of the output doesn't help you guess at any other part of the output nor the input key. If true, this is an amazingly powerful property because you can securely exchange (or derive) a short key once and then you can send as much encrypted data back and forth as you want. If you needed to re-seed the input with as many bits as you take from the output, disk encryption wouldn't be sound (you'd need a key or passphrase as long as your disk), SSL would be way more expensive (and couldn't be forward-secure) if it even worked at all, Kerberos wouldn't work, Signal wouldn't work, etc. The claim of /dev/random and this wacky government standard is that in fact disk encryption, SSL, etc. are flawed designs, good enough for securing a single communication but suboptimal because they encrypt more bits of data than the size of the random key, and so when generating random keys, you really ought to use "true random numbers" so that breaking one SSL connection doesn't help you break another. Whether it's a pen-and-paper cipher like Vigenère or a fancy modern algorithm like AES, anything with a fixed-size key can be cryptanalyzed and you shouldn't provide too much output with it, for your secure stuff you must use a one-time pad. The claim of the cryptography community is that, no, in fact, there's nothing flawed about this approach and stretching fixed-size keys is the very miracle of cryptography. We know how to do it securely for any worthwhile definition of "securely" (including definitions where quantum computers are relevant) and we should, because key-based encryption has changed our world for the better.

throw0101a 7y ago
> ... like 16 bytes, to generate an infinite amount of output, such that knowing any part of the output doesn't help you guess at any other part of the output nor the input key. Isn't that the theory behind every stream cipher? (And stream ciphers are generally just 'simplified' one-time pads.) That's what OpenBSD's arc4random(4) start as: the output of RC4.
- cosarara 7y ago
  From a more recent OpenBSD man page: > The original version of this random number generator used the RC4 (also known as ARC4) algorithm. In OpenBSD 5.5 it was replaced with the ChaCha20 cipher, and it may be replaced again in the future as cryptographic techniques advance. A good mnemonic is “A Replacement Call for Random”.
- ben_bai 7y ago
  Yep. The OpenBSD bootloader reads an entropy file from hard disk, mixes it with RDRAND from CPU (if available) and passes it to the Kernel. The Kernel starts an ChaCha20 stream cipher with this supplied entropy while constantly mixing in timing entropy from devices. This chipherstream supplies the Kernel with random data and once userland is up this is good enought and also used for /dev/random and /dev/urandom, which on OpenBSB is the same device(non blocking). Now the fun part: When a userland process gets created it has a randomdata ELF segment that the Kernel fills and which is used as entropy for a new ChaCha20 stream, just for the application should it decide to call arc4random or use random data in any other way (like calling malloc or free, which on OpenBSD make heavy use of random data).
  - throw0101a 7y ago
    > When a userland process gets created it has a randomdata ELF ... This is news to me. When did they add this (neat) functionality?
    - notaplumber 7y ago
      In 2012, first release 5.3 in 2013. Added by Matthew Dempsky. It was used for the per-shared object stack protector cookie extended for the per-function cookies required for RETGUARD. https://github.com/openbsd/src/blob/master/libexec/ld.so/SPECS.randomdata https://github.com/openbsd/src/blob/master/libexec/ld.so/SPE... https://www.openbsd.org/innovations.html https://www.openbsd.org/innovations.html No other OS has this.
      - geofft 7y ago

ATsch 7y ago

The idea of "randomness" being "used up", and then "running out of randomness", somehow. So let's look at how a hypothetical CSPRNG might work. We get our random numbers by repeatedly hashing a pool of bytes, and then feeding the result, and various somewhat random events, back into the pool. Since our hash does not leak any information about the input (if it did, we'd have much bigger problems), this means attackers must guess, bit for bit, what the value of the internal pool of entropy is. This is essentially how randomness works on Linux (they just use a stream cipher instead for performance) This clarifies a few things: 1. even if you assume intels randomness instructions are compromised, it still is not an issue to stirr them into the pool. Attackers need to guess every single source of randomness. 2. "Running out of randomness" is nonsensical. If you couldn't guess the exact pool before, you can't suddenly start guessing the pool after pulling out 200 exabytes of randomness either.

throw0101a 7y ago
> 2. "Running out of randomness" is nonsensical. If you couldn't guess the exact pool before, you can't suddenly start guessing the pool after pulling out 200 exabytes of randomness either. Not entirely. /dev/random and arc4random(4) under OpenBSD originally used the output of RC4, which has a finite state size: * https://en.wikipedia.org/wiki/RC4 https://en.wikipedia.org/wiki/RC4 Rekeying / mixing up the state semi-regularly would reset things. It's the occasional shuffling that really helps with forward security, especially if a system has been compromised at the kernel level.
- tptacek 7y ago
  No, Arc4random didn't reveal its internal RC4 state as it ran, in the same sense that actually encrypting with RC4 doesn't deplete RC4's internal state.
  - cperciva 7y ago
    Many implementations didn't do enough mixing before generating output, though. Also, when you look at cache side channel attacks -- RC4 definitely publishes its internal state.

Rebelgecko 7y ago

that /dev/random must be better than /dev/urandom because it blocks until there's "enough" entropy (where "enough" is a huge misnomer and not really something you need as long as you're using a modern OS)