Re: Security Engineering vs. Crypto Academics... (was strengthening /dev/urandom)
From: Peter Gutmann (pgut001_at_cs.auckland.ac.nz)
Date: 09/07/04
- Next message: David Wagner: "Re: Hand Waving vs. Rigorous Analysis... (was Security Engineering vs. Crypto Academics...)"
- Previous message: Rob Warnock: "Re: Encryption of Computer screen typing?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: 7 Sep 2004 04:50:13 GMT
tytso@mit.edu (Theodore Y. Ts'o) writes:
>I will also note that /dev/random relies is very conservative about what
>crypto properties it depends upon for its security, precisely because I was
>very paranoid about advances in cryptoanalytic techniques. This is one of
>the reasons why (in order to generate 10 bytes of entropy) we hash the entire
>512 byte pool, and then take the resulting 160 bit SHA hash and fold it half
>using XOR. (While we are doing this, we are also mixing the intermediate
>hash values back into the entropy pool; this prevents back-tracking attacks.)
>What is important here is that we only expose 10 bytes of data from 512 bytes
>worth of input; so even if SHA-1 is totally broken and it is possible to
>completely invert it, at *most* all that can be revealed from a single turn
>of the hash function is 10 out of 512 bytes.
This seems to be a common theme in any generator that's had some thought put
into the design. It's interesting tracing the evolution of these things, PGP
1.0 introduced the randomness pool but with a rather poor LCRNG-based mixing
function, PGP 2.0 introduced the mixing-via-hash-function (MD5 at the time,
IIRC the code was actually grabbed from the HPACK archiver), PGP 5,
/dev/random, and cryptlib added the fold-in-half obscuring of the output which
AFAIK was a Colin Plumb idea (he's influenced an awful lot of RNG design), etc
etc etc. The various designs were all cross-pollinated from other designs,
leading to a common set of best practices for randomness modules (large pools,
hash-based mixing, feedback into the pool, folding the output in half,
interlocks to prevent output if insufficiently seeded, two (or more) stages
with periodic re-seeding, not relying on a single crypto primitive, etc etc).
It's interesting to note that the proposed X9.82 spec contains a number of
these naturally-evolved design principles, so that any well-thought-out
generator will be more or less automatically compliant with the standard's
requirements.
(The one problem area is their PRNG, which is a somewhat awkward FIPS 186
derivative. The spec very thoughtfully allows it to be run in parallel with
another PRNG, so it's not that bad).
>(That's another big difference between those people who have a security
>engineering point of view, versus those with the academic point of view. For
>all that they claim they are worried about theoretical attacks, they tend to
>make assumptions that the crypto primitives will remain inviolate.)
One of the (unwritten) design principles for the generator I use is that any
component in it should be able to fail completely (it can be replaced with the
identity transformation) without affecting the overall security. I haven't
looked at /dev/random for awhile so I can't comment on that, but the PGP 5
generator also seems to have followed a similar unwritten design rule. The
idea is that if someone were to publish a paper tomorrow with a title like
"How to invert SHA-1 in 2^8 steps", there'd be no need to field-upgrade every
app that uses the generator (there would be a need to field-upgrade other bits
of the app, however).
Peter.
- Next message: David Wagner: "Re: Hand Waving vs. Rigorous Analysis... (was Security Engineering vs. Crypto Academics...)"
- Previous message: Rob Warnock: "Re: Encryption of Computer screen typing?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
