Re: Re: Fwd: little request :)

Hi all, On Thu, Feb 6, 2014 at 11:24 PM, Solar Designer <solar@openwall.com> wrote: > @mik235 pointed out that Python 3.4+ already does something similar for > the == operator all the time, by using SipHash and, if I understood > correctly, caching SipHash values along with the strings (just like it's > also done for the lengths). There's no attempt at not leaking the > length. I haven't looked at the code, so this is merely my current > understanding based on @mik235's tweets. > I thought the same thing for hash_compare(). Although I'm all for better security, I have mixed feeling whether we should take performance trade off for ==/===. For example, SHA, even MD5, is not a performance monster. Even if it made to be as efficient as possible, it requires lots of CPU time. If these are used for ==/===, I bet these hash will take much of CPU time. That's the reason why Python uses SipHash, Ext3/4 fs use half MD4/Tea for htree, etc. For hash_compare(), rehashing seems too much to me. This is the reason why I didn't propose this. It may assume parameters are always hash string. For secure string comparison for general use, we may have str_compare() which simply hash parameters (we may use SipHash. For 64 bit platform, xxhash would be good enough) and compare. This might be the way to go. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net