On Tue, Aug 24, 2004 at 12:44:53PM +0200, Danny De Cock wrote: > > (...) but the verification > of password hashes, such as used in pam, rely on the hash function's > oneway-feature rather than on its collision-resistance...
not sure I understand -- so, if someone would like to explain this aspect to the non-cryptographist, please go ahead :) I always thought that the oneway-feature is not particularly relevant when verifying passwords... In other words, if you can find (within a reasonable amount of time) any input string that produces the same given digest, then any password verification system will let you in, independently of whether you ever get to know the original password... In that case, I believe, you'd even have less constraints to satisfy, than when trying to find a collision for a message digest used to verify the integrity of some executable, for example (to protect against trojans, etc.). In the latter case, a large portion of the input would have to be identical (so the trojan will essentially do the same thing as the real program). This means you're only left with some smaller fraction of the binary to fiddle with in an attempt to yield the same message digest for both program versions (compensating for the modifications you made to the code). I'd suspect that the reduced degrees of freedom in the latter case would make it harder to find an appropriate collision. Or am I completely on the wrong track? Just wondering... Almut -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
