RE: DIGEST-MD5 and {nonce,cnonce}

["Howard Chu" <hyc@highlandsun.com>]

> > - Very wise, If you're really interested in the why's and wherefore's
> > of how to generate entrophy, I suggest you read Bruce Schneier's
> > Applied Cryptography.
>
> Actually, I did, right after it came out.  I skipped over the parts about
> PRNG's and entropy, since I do not implement cryptographic systems meant
> to be highly secure.
>
> For most of my purposes, to generate cryptographic hashes, I feed a string
> composed of the user's login, password, and the output of time() to MD5.
> It's not random, but it's generated on the server, so you have to know
> what time it is to the second on the server to be able to do anything with
> it.  Not insurmountable, of course, but by the time an attacker could
> retrieve a login/password pair, the hash has been regenerated (the hash is
> regenerated by the server every few minutes or whenever the page is
> reloaded, whichever comes first).

Getting the time of day from a typical unix box is as easy as "telnet <host>
daytime". If you're smart enough to have that port shut off, good, but I
wonder if you also have ntp enabled or not. This was a fatal flaw in the AFS
kdc, that it invoked srand() before generating every private key, and it
used time() as the seed. Generally AFS is used with ntp, and anyone could
use either daytime or ntp to retrieve the server's notion of the time, with
at least accuracy down to the second. (The AFS kdc was also vulnerable
because everyone knew that it used srand, but that's a separate issue.)

re: the notion that random data is inherently incompressible - surely you
must realize that this is not an axiom. You could toss a set of perfectly
balanced, perfectly random dice, and generate all 1s. The odds are very much
against it, but it would certainly be a random sequence, and it would be an
easily compressible sequence. Conversely, it's possible to construct a
highly patterned sequence that cannot be compressed by gzip, if the logic
behind the sequence exceeds the parameters of gzip's data dictionary. (For
example, the Fibonacci sequence. Another contrived example would be a
representation of pi - if you know this is the sequence in use, it is 100%
predictable.)

re: the requirement to be superuser to read swap space - we're talking about
a Unix system here, and we're talking about securing an authentication
mechanism for a critical system service. I think it's fair to demand special
privileges to support such an environment. As for swap itself - probably it
would be more interesting to read /dev/mem or /dev/kmem. It shares some of
the weaknesses of other methods that rely on ps output or other sequences of
Unix commands. On a very quiescent machine, a very idle server, the total
content of physical memory might be fairly constant. But on a system with at
least two or three actively running processes, you should be able to pull
fairly unpredictable values out of the heap, stack, and program counters, as
well as any other state that is maintained during context switches.