CVS update: samba/source
Jeremy Allison
jallison at whistle.com
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
change.
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,
Cheers,
Jeremy.
--
--------------------------------------------------------
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