Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:18:27
David R. Conrad (drc@adni.net)
Wed, 10 Feb 1999 12:02:49 -0500 (EST)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 8 Feb 1999, bram wrote:
> On Mon, 8 Feb 1999, David R. Conrad wrote:
>
> > When they are asked to return random bits, they apply SHA-1 to the pool,
> > do some mixing of the pool so that it'll never return the same thing
> > twice, and decrement the count of bits in the pool as appropriate. Thus,
> > you can't directly control the bits in the pool by writing to it, and you
> > can't learn the state of the pool by reading from it.
>
> Ah, but there's a chance you can. There's an attack on hamsters where you
> can get them to repeat the same output over and over again by sending them
> messages with a specific pattern. RSAREF is similar to the above except it
> uses addition instead of polynomials, and a number of people have figured
> out a rather practical attack on it. There's probably a similar attack on
> using a polynomial mixing function.
References?
> There's another whole piece which is missing as well. You never ever want
> to add entropy of only a bit or so directly to the pool, because that
> would allow for continuation attacks.
Here I get to reveal my ignorance; what's a continuation attack? I can't
find this term in AC2 or the Yarrow docs.
> Come to think of it, there's a bit of an implemention question here - the
> API for adding to the pool should really include information about how
> much entropy is in the data being added....
I'm not sure, but I suspect it doesn't trust the bits it's fed to contain
any entropy, and only trusts the keyboard/mouse/etc events to have some
predefined number of bits per event.
[Discussion of /dev/prandom and physical randomness elided.]
> The I/O problem possibility I was talking about was one of API - if
> /dev/random doesn't have enough stuff in the pool, it blocks, but you as a
> developer might want to view insufficient entropy as a very serious
> problem and fail immediately instead of blocking until such time as
> entropy might become available.
Erm, couldn't you just look for this with select(2) and/or O_NONBLOCK and
then handle as necessary? You might even be able to do something similar
in Java with java.io.FileInputStream.available().
> (Someone got a linux web server running on a device the sice of a matchbox
> - yeesh.)
(Wow!)
> > I was fascinated to discover that there are a number of configurable
> > options. First, the POOLWORDS, which as I said can be increased up to
> > 2048 from the default of 128, second, several unrolled versions of SHA-1
> > which make size/speed tradeoffs (or you can even use MD5 rather than
> > SHA-1, not that you'd want to)
>
> If you're using SHA-1, there's no point in having a pool of more than 160
> bits, since that's how much output SHA-1 gives anyway.
Huh? Why would you want to limit the pool in this way? Then it could
never return more than 20 bytes without blocking. Even if you were using
SHA-1 as your mixing function on the pool, you could mix N 160-bit chunks
as follows, with O being the last output, and | being concatenation:
for (i = 0; i < N; i++)
chunk[i] = SHA(O|i|chunk[i]);
If N was large, you could precompute the state of SHA after hashing O to
speed the others up, but since O would probably be small and N not very
big either, this probably wouldn't be worth it.
I think limiting the size of the pool to 160 bits is an amazingly bad
idea. IMNSHO.
> It's very good that there are some size/speed tradeoffs for SHA-1. It is
> however a significant omission that RIPEMD-160 isn't supported.
> (RIPEMD-160 and SHA-1 have the same block and output size, so either can
> be used, and some people prefer RIPEMD-160 for political and technological
> reasons.)
Well, that could be done. Write Theodore T'so and suggest it to him.
(Oddly, his email address doesn't appear in the driver source. I think
he used to be on this list?)
David R. Conrad <drc@adni.net> PGP keys (0x1993E1AE and 0xA0B83D31):
DSS Fingerprint20 = 9942 E27C 3966 9FB8 5058 73A4 83CE 62EF 1993 E1AE
RSA Fingerprint16 = 1D F2 F3 90 DA CA 35 5D 91 E4 09 45 95 C8 20 F1
Note: Due to frequent spam abuse, I accept no email from *.da.uu.net.
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv
iQA/AwUBNsG7xYPOYu8Zk+GuEQKHAwCgltsrQuvjXzlDkvksLELSc7UiyFUAn2Fo
Si6XNnCUnF6d+jahfWPLX1aj
=Jf/4
-----END PGP SIGNATURE-----
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:18:27