Re:The strange story of “Extended Random”
by tptacek on Saturday December 23, 2017 @10:46PM
(#15997814)
I've had a couple beers and am having trouble holding all these paragraphs in my head.
But, at the risk of being repetitive, because maybe this simplifies things:
Generate a random 128 bit key by hashing something. This is what the Linux KRNG does with raw entropy.
Initialize AES-128 with that key and start running it in CTR mode. Encrypt a file with known contents, like /etc/ttys. That's ~1300 bytes of known plaintext.
Now, recover the AES-CTR keystream (just XOR /etc/ttys against the AES-CTR ciphertext).
Is it your contention that, having done that, you've placed yourself closer to guessing the underlying 128 bit AES key?
If not, you see also why drawing out 1300 bytes of Linux KRNG randomness doesn't help you predict future values. The randomness you read from /dev/urandom is fundamentally just PRF keystream.
If you could look at AES-CTR keystream and use it to make an advantaged guess at the underlying AES key, AES would be grievously broken.
But, at the risk of being repetitive, because maybe this simplifies things:
Generate a random 128 bit key by hashing something. This is what the Linux KRNG does with raw entropy.
Initialize AES-128 with that key and start running it in CTR mode. Encrypt a file with known contents, like /etc/ttys. That's ~1300 bytes of known plaintext.
Now, recover the AES-CTR keystream (just XOR /etc/ttys against the AES-CTR ciphertext).
Is it your contention that, having done that, you've placed yourself closer to guessing the underlying 128 bit AES key?
If not, you see also why drawing out 1300 bytes of Linux KRNG randomness doesn't help you predict future values. The randomness you read from /dev/urandom is fundamentally just PRF keystream.
If you could look at AES-CTR keystream and use it to make an advantaged guess at the underlying AES key, AES would be grievously broken.