On Fri, 11 Jan 2002 11:42:53 +0100, Christian Recktenwald said: (Lots of good analysis omitted - I was going to say the same things myself) > rand() is defined to return an integer value, which is 16 bit > on most systems. Therefore it ranges from 0-65535 - not enough > for security concerns. Call rand() 8 times, (or get 16 byte from > another good entropy source) you'll get 128 bits. Calling rand() 8 times does *NOT* give you 128 bits worth of entropy. In fact, giving me 8 16-bit rand() values will quite probably leak enough of the internal state that I can *fully* predict the future behavior. > These are practically unpredictable and so you don't need > to mangle them with MD5 to hide how your session id is created. > (this would be the only benefit MD5 could have here). Hashing with MD5 will also hide most of the state information leaked by 8 calls to rand() ;) Something to consider as well - you may wish to take several bytes of each MD5-hashed value and feed them back into the next calculation. This will help for all the usual chaining-mode encryption reasons. In particular, it makes predictive attacks MUCH harder - since each session-id value will depend on *all* the previously generated ones. So an attacker can't just make one connection, and use that session-ID to seed and predict the next ID generated (since he in general won't have access to all the previously created session-IDs. > But all this would be useless, if you don't take care > of what is done with this session id, where it is transmitted > and stored (esp. in web applications) Very true. -- Valdis Kletnieks Operating Systems Analyst Virginia Tech
This archive was generated by hypermail 2b30 : Fri Jan 11 2002 - 14:37:07 PST