perl-embperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ed Grimm <>
Subject Re: Sessions get mixed up ?
Date Mon, 15 Nov 2004 23:09:49 GMT
On Mon, 15 Nov 2004, Pierre Etchemaite wrote:
> Le lun 15 nov 2004 18:24:06 CET, Ed Grimm <>
> a écrit :
>>> Apache::Session generates the id by doing a md5 hash on a random
>>> number (time () . {} . Rand() . $$) , maybe there are situation where
>>> it generates the same id (also this should normaly not happen).
>> MD5 hash collisions very well could have that frequency, at that volume.
>> How hard would it be to change the code to use a SHA or SSHA hash
>> instead?  (Admittedly, I'm picking a more cryptographically secure hash
>> at psuedo-random; there may be one that's more appropriate.)
> Collisions with a 128 bits digest are *very* unlikely. It's more likely the
> original pseudo random number that provides less than 128 bits of entropy.

Well, we have 32 bits of time, but only a few bits of entropy, plus 32
bits of entropy from Rand(), plus 16 bits of $$, but again only a few
bits of actual entropy.  This sounds like around 36-38 bits of entropy
to me.  This number, while much smaller than 128 bits, is still too
variable for there to be a duplication of the seed number in that

MD5 hashes are known to not be cryptographically secure, which is to
say that they do not necessarily preserve all the entropy which is fed
into them.  Providing more entropy should reduce the collision rate, but
given that time is a factor, I suspect it won't eliminate it - with the
number of logins per day quoted, I'd not expect there to be that many
people logging in during the same second.

Of course, if one wanted to go the other route, using Time::HiRes for
time() would increase the effective entropy bits on time by 15-19, and
should be a fairly drop-in change.  (Just add

    use Time::HiRes qw(time);

to the top of Apache/  Of course, this will only work if
your system recognizes subsecond time.

I personally have encountered checksum collisions in rsync, which uses a
128 bit MD4 hash; the files were the same size, but their content was
different.  I do not believe that I have yet performed rsync to update
files of the same length more than 300,000 times.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message