On Mon, 15 Nov 2004, Pierre Etchemaite wrote: > Le lun 15 nov 2004 18:24:06 CET, Ed Grimm <[EMAIL PROTECTED]> > 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 interval. 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/Session.pm.) 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. Ed --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]