RE: DIGEST-MD5 and {nonce,cnonce}

[Booker Bense <bbense@networking.stanford.edu>]

On Mon, 25 Oct 1999, Howard Chu wrote:

> 
> 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.)

- I didn't say if and only if. However, as a rule of thumb, if your
entrophy device generates output over many trials that can be
compressed easily that certainly implies it's predictable. The fact
that it doesn't compress doesn't prove anything. It's a quick simple
easy test to at least let you know you're on the right track.  

> 
> 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. 

- OpenLDAP runs on NT as well as unix. I think the best solution would
use only POSIX calls if at all possible. If this code has to run on
the client side, I think making it setuid is a non-starter. 
( Note: I've lost track does this code only run on the server end? )  


>  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.

- I'm not convinced that this really gives you any significant
advantages that are worth the trouble. Most of the data in memory
is pretty structured, core files compress nicely. The counters 
might be useful, but then you'll need to write a seperate module
for each OS. The timing data used in the Matt Blaze routine seems
just as good to me and a whole lot simpler to implement. It's really
just a slightly different way to get numbers out of the same data.

- But, for someone not writing the code I've said far too much
already. 

- Booker C. Bense