Re: Plan B for fixing 5.8.2 binary API
According to Nicholas Clark:
> Whereas if we adopt plan A, and all that we get wrong is that it's not a
> very strong defence against hashing attacks, we are no worse off than
> 5.8.0
IMO, high-quality hash seeding is more important than XS binary
compatibility. Seeding is a security feature, and security trumps
just about anything else[*]. If we can't make any plan for seeding
*with* bincompat work right -- though I'm confident that we can --
then we should break the binary API in a way that requires
recompilation of XSs that use PERL_HASH(). Weak hash seeding is
simply Not OK. IMO.
On the other hand, I don't have enough crypto(ish) experience to
either write or approve of a hashing algorithm, especially one that
tries to sequeeze every last bit of entropy out of small data. So:
> IIRC the paper had exploit code. I think it's time to play with that.
If you feel confident in your ability to come up with a good hash,
please be my guest. (No sarcasm.) But Plan B *is* within my skill
set; to my eyes, it's looking like a lower risk than Plan A.
[*] "A Smith & Wesson beats four aces."
--
Chip Salzenberg - a.k.a. - <chip@pobox.com>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
Reply to: