Hm. Seems to me you've expended a lot of time attacking my opinion.

All I've done is spend a little downtime politely and respectfully responded to your inflammatory comments.

Oh sigh. Your very first post on this topic made an unevidenced assertion that the hash-related security fixes done in 5.18.0 were both unnecessary and may have significantly slowed the perl interpreter. All I have done is patiently and politely tried to demonstrate that your assertions were incorrect. And it seemed to me to be important to correct this assertion as (assuming I was right), people could be mislead into thinking something insecure was secure.

Somehow that is inflammatory.

Yes, you can use knowledge of the seed to construct a set of keys that could induce pathological behaviour if used to construct a hash, but you simply omitted to address the problem of how are you going to persuade the server to construct a hash from the set keys you've generated.
That's utterly trivial. You send a HTTP request to the server with a bunch of headers or parameters containing the generated keys. If the server creates a hash from the input, you've done it. Or you could supply some JSON to a server that processes JSON input. Etc etc.

And remember that most of the recent discussion above has been about servers leaking the hash seed. That isn't the only (or main) thing fixed in 5.18.0. The biggie was that if you supplied a suitable small set of keys in a request (no need to know the server's seed) you could force the perl process to allocate Gb's worth of memory. Also I think there were issues with the existing way algorithmic complexity was protected against, but I don't remember the details now.

And this is isn't just about HTTP servers. Any perl process that gets hash keys from untrusted input used to be vulnerable to algorithmic complexity attacks. Think of a spam filter that reads an email's headers into a hash for one hypothetical example of many.

addressed in a clumsy and over-engineered fashion.
Patches welcome....

Dave.

In reply to Re^12: Our perl/xs/c app is 30% slower with 64bit 5.24.0, than with 32bit 5.8.9. Why? by dave_the_m
in thread Our perl/xs/c app is 30% slower with 64bit 5.24.0, than with 32bit 5.8.9. Why? by Anonymous Monk

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.