Re: [RFC] ra_svn::make_nonce: how to cope with entropy shortages?

[Daniel Shahaf]
> Something tells me that when a cryptographic protocol calls for
> random numbers then a quasiconstant or known value wouldn't do
> instead. It might still provide some security guarantees but I
> wouldn't assume it would provide all guarantees of the
> correctly-executed protocol.

It doesn't call for random numbers. It calls for a nonce. The nonce
is not secret - it is passed in plaintext to the client - it just has
to be different every time, to prevent replay. Given the nature of
cryptographic hashes, it doesn't even have to be _very_ different to be
useless to an attacker. To attack the challenge in CRAM, you have to
attack _two_ checksums, outer and then inner. Even one bit of entropy
scrambles the inner checksum, and _that_ scrambles the outer.

apr_time_now() has microsecond resolution. There's no way a single
svnserve process will handle two connections in the same microsecond.
(I note that even at gigabit speeds, two adjacent network packets will
be about a microsecond apart.)

That leaves multiple processes calling apr_time_now in the same
microsecond. So I think I'll add a getpid() in there somewhere.
(The Debian patch, I mean. Probably not useful here.)

> > Would some other simple fix (e.g., calling
> > "lrand48") make sense and be generally useful?

Well, rand() and friends have to be seeded _somehow_, usually from time
of day, so that doesn't seem much better than apr_time_now().

> No objection here, but doesn't APR already use lrand48() if it's available?

If that's true, we shouldn't even be having this conversation at all.
The problem is that /dev/random was being exhausted.

-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/