[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/
