[Cryptography] RFC possible changes for Linux random device

[Jerry Leichter]

On Sep 16, 2014, at 6:43 AM, John Denker <jsd at av8n.com> wrote:
> Bottom line: 
> ++ Please let's be fastidious about the distinction 
>  between entropy on the one hand and pseudo-randomness
>  on the other hand.
Agreed.  But let's also be more careful about attacks.

Suppose we implemented an AES-CTR PRNG, initialized using a TRNG.

- If I'm implementing a crypto system whose fundamental security depends on AES "acting like a random function" (yes, this should be formalized carefully), then relying on this PRNG as my source of random values does not add any new weaknesses.
- If, on the other hand, my crypto system can survive a break of AES (probably because it doesn't use AES at all - many systems rely on the security of AES *plus* the security of, say, RSA, and they are just as vulnerable to a break of AES), then I should *not* rely on this PRNG as my source of randomness.

So we need a finer-grained distinction than TRNG vs. PRNG:  If we want to do a careful threat analysis, we need to understand how the PRNG works.  The definition of a deterministic PRNG *must* indicate, in detail, what security assumptions it depends on.

In practice today, many widely-used algorithms are inherently dependent on the security of AES, so relying on an AES-dependent PRNG has minor, if any, affects on the security of the system as a whole.  So why not use this is a fast alternative - which as a deterministic algorithm also has other good features like testability.  (Of course, *security* is still dependent on a proper TRNG for initialization.  You can't get away from that.)

One thing to note is that if you ever decide that AES is vulnerable, you can upgrade the generator to something else *entirely on your own*:  Unlike changing the ciphers used in communication, the cipher or other mechanism used to build a PRNG is a purely local decision.  So you aren't making the cipher upgrade problem any harder.

> ++ The idea of having an wasteful PRNG /per process/
>  is very much open to question.
I don't see why this is wasteful.  As Ts'o proposes it, only those processes that happen to use it get it.  The only thing I would add to his proposal is a system call to securely destroy the current process PRNG data structure, resetting the process to the "no PRNG" state.  That way (a) a process that doesn't think it will need the PRNG any more can return the necessary resources to the system; (b) since the next call to get a PRNG output will create a whole new PRNG, seeded with true entropy, a process can at any point destroy any connection between "random values" it has already used and "random values" it will use from this point on.  I'd also suggest that the PRNG state be destroyed on exec - a new program should not be able to get any information about the "random number" some *other* program generated in the past, even if they happen to live in the same process.
                                                        -- Jerry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140916/44ddd70b/attachment.bin>