Eric Rescorla wrote:
The hashed random above is generated using SecureRandom. (Apparently) for added security, the resulting byte array is then hashed, replaced with the (truncated down to 16 bytes) hash and converted to a hex string. Some attempt is made to make the original seed used by SecureRandom hard to recover, so one could ask why the hash needs to be applied at all. While hashing blows away the more or less guaranteed long period of the random number generator, the result should still have very good dispersion properties making it remarkable that people are reporting collisions. Makes you wonder if there is something else going on...."Schnitzer, Jeff" <[EMAIL PROTECTED]> writes:Yes that's true if the monotonically increasing value is added to the random number _before_ the hash... and even worse, there is nothing that guarantees that two numbers won't hash to the same value so we're back to the duplicate session id problem. What I was suggesting is adding the integer to the session id _after_ hashing: ASDFASFDASFDASF000000012 [hashed random][counter] This would guarantee that every session id is unique, and wouldn't require any synchronization (operator ++ on any integer smaller than a long is guaranteed atomic, right?).The standard fix for this is to use a cryptographic pseudo-random number generator, such as Java's SecureRandom. SecureRandom automatically seeds itself from allegedly random system data. the probability that two sufficiently long random numbers (e.g. 16 bytes) will collide is vanishing. (E.g. with a 16-byte session ID, you'd have to generate > 2^60 session IDs to have a reasonable chance of collision. -Ekr
I agree with Jeff that it would certainly be cleaner to dedicate a segment of the session ID to guarantee uniqueness than to check for collisions after the fact. One way to do this would be to encyrpt (not hash) host/JVM identifer + a time stamp or counter + random bytes from SecureRandom and use this (padded as necessary) as the session ID. Encryption will preserve both uniqueness and dispersion. The encryption key could be randomly generated at server startup time.
-Phil
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
