6 ms·
Could someone explain DJB's point to me: Cryptographers are certainly not responsible for this superstitious nonsense. Think about this for a moment: whoev
by bredman 13y ago
Could someone explain DJB's point to me:
Cryptographers are certainly not responsible for this superstitious nonsense.
Think about this for a moment: whoever wrote the /dev/random manual page seems to
simultaneously believe that
(1) we can't figure out how to deterministically expand one 256-bit /dev/random
output into an endless stream of unpredictable keys (this is what we need from
urandom), but
(2) we _can_ figure out how to use a single key to safely encrypt many messages
(this is what we need from SSL, PGP, etc.).
For a cryptographer this doesn't even pass the laugh test.
Is the argument here simply that a properly encrypted message should look like randomness? And as a result we should be able to turn something non-random into randomness?
- bradleyjg 13y agoWell close, though you use the word random or randomness where he uses unpredictable. His basic point is that we can use the 256-bit random output as the key for a stream cipher, and voilà you have yourself an endless stream of unpredictable keys. And if you don't believe that, then in what sense do you trust the stream cipher?
- agwa 13y agoThe same types of cryptographic algorithms used in SSL, PGP, etc. are also used to securely expand a small bit of entropy into an endless stream of good randomness. It's intellectually inconsistent to not trust these algorithms when used in an RNG, but to trust them when used in SSL, PGP, etc. See the contradiction with stressing the importance of using random, not urandom, when generating SSL/PGP keys?
- Tomte 13y agoIt's an informal way to put it, but yes, it boils down to that. It's almost the definition of a block cipher. See http://en.wikipedia.org/wiki/Pseudorandom_permutation http://en.wikipedia.org/wiki/Pseudorandom_permutation
- marcosdumay 13y agoI don't understand your theory, sorry. I can't tell if you are right. So, I'll just put my understanding here. There are people that assume that both: 1 - 256 bits aren't enough entropy to create a long chain of random numbers in a CSPRNG; 2 - 256 bits (after adjusting for known attacks) are enough entropy to encrypt a long chain of data in a symmetric cryptography algorithm. Since encryption and creating random numbers are normally the same operation, 256 can't be both enough and not enough. I don't know if SSL even supports symmetric encryption with more than 256 bits of entropy. I've certainly never seen it.