From: Christophe R. <cs...@ca...> - 2005-05-13 14:55:49
|
"R. Mattes" <rm...@mh...> writes: > Hmm, so now we have a small but important semantic difference between > sb-md5:md5sum-sequence and md5:md5sum-sequence.=20 Who is the maintainer of md5:md5sum-sequence, and do they know the implications of multiple string representations? > And, since (typep "string" 'sequence) is true it makes conditional > code rather more elaborate than necessary. What's the design > rationale behind this? After all strings _are_ sequences.=20 Strings are sequences, but the md5 algorithm is defined over octets, not characters. As such, the name md5sum-sequence is a little misleading, but is a relic of the days when sbcl only knew about 256 characters, and did not have any idea that there might be more than one possible encoding. The sb-md5:md5sum-string entry point acknowledges the existence of multiple encodings for character data, and the sb-md5:md5sum-sequence entry point will shortly no longer accept general strings to prevent the user from shooting themselves in the foot. Just to put this on a concrete footing, let me throw the question back to you: what, if md5sum-sequence works on strings, should=20 (md5sum-sequence "=A4" return) [ where the character in the string is a euro sign ] > The "mysterious" thing is that md5sum-sequence does provide a result > (and doesn't throw a condition) - just a strange one. Probably it has been compiled with a low safety setting relative to speed, so that the usual checks are not performed. > Given the use of md5 in security relevant code i'm a bit worried. md5 in security-relevant code should probably be avoided, as it has "only" 128 bits of hash, which wouldn't be a problem were it not for the fact that it has been broken fairly comprehensively. Cheers, Christophe |