[Cfrg] Randomness Recommendations (was: no subject)

[Jack Lloyd <lloyd at randombit.net>]

On Wed, Sep 01, 2004 at 04:45:47PM -0400, John Kelsey wrote:

[...]
> probably our cryptographic PRNG based on HMAC.  Alternatively, Peter
> Gutmann has a nice design in Cryptlib, which he's analyzed in some
> depth, and I published a design with Bruce Schneier and Niels
> Fergusson called Yarrow-160, which I think is pretty reasonable.

Yarrow (at least the instantiation in the paper) makes me nervous, in that it's
never going to get you more than 160 bits of security. For AES-256 or
generating a new RSA key, you might want more than that (of course you pointed
this out in the paper itself). Seems easy enough to instantiate it with AES-256
and SHA-256, though.

> b.  How unpredictable something is usually depends somewhat on the
> attacker.  For example, packet arrival times are pretty easy to
> predict if I'm on your local network and am monitoring it when you
> collect them, but they're a wonderful source of entropy if I am not on
> your local network.

The easiest thing being to include them, along with everything else you can
find, and make sure that even if the attacker knows (or is controlling) some of
the inputs, they don't get any advantage. Kitchen sink entropy gathering. :)

[...]
> I think the other thing you need to get across here is that entropy
> sources are implementaton-dependent.  If you're timing packet arrivals
> with the cycle counter on your CPU, you're going to get a lot more
> entropy than some other guy who's timing them with something driven by
> the 18.x times/second external timer interrupt.  If you're designing a
> system that needs to collect entropy from these sources, you really
> need to know whether you've got a cycle counter you can use for
> timing.

Almost all modern CPUs have them -- the problem is that on some (PowerPC,
XScale) access to it is restricted to the kernel, and on all the rest (586+,
Alpha, SPARCv9), the kernel can choose to disallow access to it from userspace,
though I've never encountered one that was configured like that.

But ultimately it's security vs functionality. Either I make due without a
cycle counter, or I look for it, fail, and die. So either be ready to lose
access to various markets because they use CPUs that don't have usable cycle
counters, or make sure your design can tolerate it.

[...]
> Anyway, there's a fair bit of cryptographic RNG hardware out there.
> Intel did a design (which flopped), and VIA has one now.  Several
> smartcard/token vendors do special purpose hardware for cryptography.

Most of the common crypto accelerators (AEP, Rainbow, etc) have them as well.
Of course it's rare for a user to have one of those, but it's nice to be able
to use it if it's there. AMD shipped one similiar to Intel's in the Southbridge
for a while, but it only showed up on a Athlon MP boards, AFAICT.

-Jack

_______________________________________________
Cfrg mailing list
Cfrg at ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg