David Dyer-Bennet wrote: > Peter Rothermel <[EMAIL PROTECTED]> writes: > > > Stas Bekman wrote: > > > > > Peter Rothermel wrote: > > > > > > > > > > > PerlChildInitHandler Apache::foo->loadkey > > > > > > > > Will the genkey method get execute at the > > > > initialization of each thread? > > > > > > Apache doesn't provide such a hook yet. May be in the future. > > > > > > child_init is for child process init, not threads. > > > >http://perl.apache.org/release/docs/2.0/user/handlers/handlers.html#PerlChildInitHandler > > > > > > what are you trying to do? > > > > I'm encrypting/decrypting data within cookies that are holding session keys > > for authentication purposes. I decrypt the session key within the cookie data, > > whenever I get an http request that has a cookie in the header. > > What's the benefit of encrypting the session keys in the cookie? If > they're randomly chosen from a very large space, the probability of > guessing a valid session key can be made exactly equal to the > probability of guessing the encryption key. >
I am using the term "session key" in the context of the the Apache::AuthCookie module that is maintained by Michael Schout. In my system, the session key holds some group membership and access rights information that is returned by an authentication server when the user provides credentials (username, password,..) via a login page. The session key is not very large or randomly selected. > > In particular, if the *result* of the encryption is, say, a 32-bit > encrypted session key, is that any more secure than simply picking a > random 32-bit session key to begin with? Even with a 2048-bit > encryption key, there are actually only 32 bits of space to search for > a hit. (So you don't need to have a 2048-bit session key space to > match the security of a 2048-bit encryption key applied to a 32-bit > session key space; a 32-bit session key space alone is just as safe.) > > And of course the key generation, encryption, and decryption take CPU > power, *and* require additional code that could have bugs, which could > be security problems. > > I've seen people (including one client) *very* committed to this > "encrypted session key" concept before, and I've never been able to > understand what benefit it buys them. I ask because I'm NOT yet > totally convinced I'm right; though I'm convinced enough that the > sites I design depend on it. > > (One obvious answer is "there are big wins for us in having session > keys that *aren't* randomly chosen"). > -- > David Dyer-Bennet, [EMAIL PROTECTED] / New TMDA anti-spam in test > John Dyer-Bennet 1915-2002 Memorial Site http://john.dyer-bennet.net > Book log: http://www.dd-b.net/dd-b/Ouroboros/booknotes/ > New Dragaera mailing lists, see http://dragaera.info
