Hi all,
On Thu, Feb 6, 2014 at 11:24 PM, Solar Designer <[email protected]> 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
[email protected]