RE: DIGEST-MD5 and {nonce,cnonce}

[Mihai Ibanescu <misa@necomm.ro>]

On Mon, 25 Oct 1999, Booker Bense wrote:

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

	I understood the meaning, IF it does compress THEN it's a weak
method.

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

	Nope, I need it on both sides. The server has to generate a nonce,
and the client must generate a cnonce. This is to avoid replay attacks. I
guess the time window is very small for an attacker to try and 'guess' the
password using a nonce. So really this discussion is more about writing a
good function, lutil_entropy, rather than this special case of DIGEST-MD5
authentication.

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

Cheers,
Misa