CVS update: samba/source

Jeremy Allison jallison at
Wed Apr 22 02:55:02 EST 1998

Andrew Tridgell wrote:

> Hmmm, there is a more fundamental flaw. It returns a 32 bit int, and
> the generation of the new machine password is deterministically based
> on this result.

Yes, I was worried about that.

> That means with a 9GB disk you could easily hold a complete lookup
> table of all possible passwords. Not very good ...

Ah yes - thanks for looking at the code :-).

> The bottleneck is calling srandom() with a 32 bit secret key then
> getting everything from ramdom(). Maybe we should instead keep the
> nice 128 bit result from md4 in do_reseed() and use that to generate
> the random buffer? Calling md4 on it's own output will be a reasonable
> way of generating each block in turn.

Hmmm. Looking at the mods you have not made
md4_buf a static in generate_random_buffer().

Surely it must be to retain the 'good' randomness
after do_reseed() ? I will change it to be
a static and checkin - please lookover the

The other thing that worries me is that
the random stream is now deterministic
based on the first output from the md4_buf.

Remember, these random numbers may be
externally exposed (the challenge in
a negprot reply). Doesn't this give
an attacker enough info to re-create
the random stream ? Should we *always*
re-seed ?

Thanks a lot for the work on this code,



Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.

More information about the samba-cvs mailing list