> You really can't use yarrow to implement /dev/random as it is.  Even
> waiting for reseeds doesn't cut it.  The issue is that everything goes
> through the yarrow output function, which restricts yarrow to offering
> computational security with at worst 2^n work factor to break because
> it offers known plaintext the 0 block as the first output is E_k( 0 ).

OK; what then? The existing MD5 based system is very attackable, and
protects itself very poorly.

My approach to this (and this is the first time I am stating this in
such a wide forum) is to provide another device (say /dev/srandom) for
folk who want to do their own randomness processing. This would provide
a structure of data including the entropy, the system nanotime and the
source, so the user can do his own hard work when he needs to, and the
folk simply needing a stream of "good" random numbers can do do from

> > I am against the blocking model, as I believe that it goes against
> > what Yarrow is trying to do. If the Yarrow authors argued otherwise,
> > I'd listen.
> Niels and John Kelsey were against it to initially, on the grounds
> that computational security (160 bits -- or whatever the parameter is
> with the ciphers you have plugged in) is in fact "good enough" in
> practice even for 1024 bit RSA key generation.
> (The argument has some validity; in practice a brute force attack
> against RSA 1024 takes significantly less than 2^160 operations,
> though the memory requirements are higher).

I've heard that that is down to like 2^90 or a lot less...

> However it is not fair to impose that view on someone.  People can
> have legitmate reasons to need more entropy.  Another very concrete
> example is: say someone is using a yarrow-160 (3DES and SHA1)
> implementation and they want to use an AES cipher with a 256 bit key
> -- without the /dev/random API, you can't get 256 bit security, with
> it you can.

Sooner or later someone is going to come up with a requirement for
M-bit randoness on Yarrow-N, where M > N. What then?

> OTPs and some algorithms offer information theoretic security, or you
> may be using a larger key space symmetric construct than the yarrow
> output size (using 256 doesn't solve that -- then they want a 512 bit
> key).  Worse people may already be using /dev/random for these
> assumptions, so you risk breaking existing code's security by
> replacing /dev/random with yarrow.

I can't help broken applications, but if we provide a better API, and
get folk to use it, that everyone wins.

> > If I construct a specific hash function, is this still a problem?
> No.  Note my other comments on list about CBC-MAC are confused -- I
> misread your code.  It appears to be a keyless hash function, and as
> Joeren noted it has some similarities to Davies-Meyer, but it's not
> quite the same for the reasons he noted.

I fixed that and made it Davies-Meyer.

> The main argument is against not using constructs which haven't
> received lots of peer-review -- most crypto constructs are very
> fragile to small design changes.


> | So given that, it doesn't seem quite fair to pull the rug from under
> | /dev/random users and replace it with a PRNG with quite different
> | security assumptions.  Users would have similar reasons to be upset if
> | someone removed their /dev/random and symlinked it to /dev/urandom.

...unless we can somehow get /dev/random to be "secure enough".

> and after more arguments, more formally argued:
> | Even if I have a mechanism to wait for a reseed after each output and
> | reserve that output for me, I get at best R*2^160 bits for R reseeds,
> | rather than the 2^{R*160} bits I wanted.
> | 
> | Note the yarrow-160 API and design doesn't allow me to wait for and
> | reserve the output of a reseed in a multi-tasking OS -- /dev/random
> | does.

Hmm. Most convincing argument I have heard so far. How much of a
practical difference does that make, though. With ultra-conservative
entropy estimation (eg, I am stirring in nanotime(9), but not making
any randomness estimates from it, so the device is getting some "free"

PC's are pretty low-entropy devices; users who need lots of random
bits (as opposed to a steady supply of random numbers) are arguably
going to need to go to extraordinary lengths to get them; their
own statistical analysis is almost certainly going to be required.

Software that I am (partially) aware of that uses /dev/random usually
doesn't trust it too much anyway (qv PGP) (OpenSSH is an exception),
and programmers often come up with elabrate schemes to compel the
os to provide their requisite bits.

Folk who are generating OTP's for anything other than personal use
would be insane to use anything other than custom hardware such as
the ubiquitous geiger-counter or zener noise generator.

Mark Murray
Join the anti-SPAM movement: http://www.cauce.org

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to