Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Re^13: Hash order randomization is coming, are you ready?

by demerphq (Chancellor)
on Dec 04, 2012 at 07:45 UTC ( [id://1007024]=note: print w/replies, xml ) Need Help??


in reply to Re^12: Hash order randomization is coming, are you ready?
in thread Hash order randomization is coming, are you ready?

but not reasoning for changing the hash algorithm itself

Sure it is. A strong hash function is harder to attack.

why you would do it on a hash-by-hash basis rather than a per-process basis.

Concerns over information exposure of key order to an attacker.

I don't get the reluctance to share this information?

If there is any reluctance it is purely that of me wanting to avoid a long dialog repeating what has already been said elsewhere. I have a lot of demands on my time these days.

---
$world=~s/war/peace/g

Replies are listed 'Best First'.
Re^14: Hash order randomization is coming, are you ready?
by Anonymous Monk on Dec 04, 2012 at 08:14 UTC

    If there is any reluctance it is purely that of me wanting to avoid a long dialog repeating what has already been said elsewhere. I have a lot of demands on my time these days.

    Great, link?

        I have much respect for you and p5p, I mean no disrespect with my comments, I'm grateful for perl, but please listen to the stinkers now while its early :) sometimes they have points, even if they don't understand the topic thoroughly

        :) I came up with those links (after I noticed my earlier "What?" got --), and its lacking a lot of details -- I guess I just don't get it. I'm not quite ready to call it garbage like BrowserUk , but I'm certainly thinking about it :) new smells aren't pleasant

        I'm thinking this change is one of those things I think should be delayed for at least another 5 years until warnings can warn you about it, and the docs contain something more demonstrative , and aren't set to permanent limbo mode (forgive my lack of precision in my wording)

        "Don't depend on this" is beginning to chafe, grate even :) why not a hash pragma so it DWIMs (whatever that would be)?

        Also, when claims are made about performance in the docs, link to it, for example Switch perl's hash function to MurmurHash-32 (v3) and hash randomization by default. « perl5-porters « ActiveState List Archives

        I thought we had "per process hash randomization" from 5.8.1, and nothing I linked earlier describes something new/different -- this thread makes it sound its more random than that -- yup, I don't get it, docs aren't clear

        Reading that PERL_HASH_SEED now takes a hex value instead? Code parsing this output, should it exist, must change to accomodate the new format. ? Change for the sake of change?

        Yup, I hate that variable now :) ${magic variables}-- I think I'm onto something with the hash pragma idea and delaying introduction -- improve the docs/interface while its new and you know what its all about

        I have much respect for you and p5p, I mean no disrespect with my comments, I'm grateful for perl, but please listen to the stinkers now while its early :) sometimes they have points, even if they don't understand the topic thoroughly

Re^14: Hash order randomization is coming, are you ready?
by BrowserUk (Patriarch) on Dec 04, 2012 at 08:24 UTC
    but not reasoning for changing the hash algorithm itself -- Sure it is. A strong hash function is harder to attack.

    With respect, that is garbage. The way the original algorithmic complexity attack was constructed, was to simply hash a mess of random strings of a given length and see which one's hashed to the same value. As soon as anyone gets their hands on the release that contains a different hashing function, the "strength of the hashing function" -- a totally meaningless measure in this context -- is completely negated.

    Only the reliability of the randomised seed provides any protection whatsoever.

    why you would do it on a hash-by-hash basis rather than a per-process basis. -- Concerns over information exposure of key order to an attacker.

    Unfounded (and illogical) concerns. If the "attacker" has sufficient access to be able to determine the per-process seeding, they have sufficient access to have far simpler and more effective attack vectors.

    Like fitting an anchor to a car or an air brake to a submarine, the extra prophylactic serves no purpose.

    If there is any reluctance it is purely that of me wanting to avoid a long dialog repeating what has already been said elsewhere.

    I see. So we users of this modification shouldn't be concerning our simple selves with the difficult details of this change huh?

    Would copy/pasting taking so much timeand effort? Even a link to the existing discussion would have sufficed.

    But fear not, I'm not asking you to argue your case here. I've already heard enough to realise that this is tinkering for it's own sake, rather than justifiable development.


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

    RIP Neil Armstrong

      With respect, that is garbage

      With respect I think you are under informed. See SipHash and the documented attacks on various hash functions. A strong hash does not allow one to predict the hash value of a given string even if one knows the hash value of any other string assuming one does not know the seed.

      . If the "attacker" has sufficient access to be able to determine the per-process seeding

      Exposing key order provides an attacker information that can be used to eventually deduce the seed. Randomizing per hash means that this information is useless. We know that much code exposes key order without realizing it.

      Would copy/pasting taking so much timeand effort?

      Would *reading* what has been written be so much time and effort? I don't mind explaining if you genuinely do not understand what has been said, but the impression I have is that you are unwilling to read what has already been written and would prefer to interrogate me about the same points while being offensive in the process. Eg, using big bold to repeat things I already said, ignoring what has been said (such as "per process randomization") and accusing me of talking garbage.

      ---
      $world=~s/war/peace/g

        See SipHash

        Thank you. That's all I've been asking for. (Shame I had to goad it out of you.)


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.

        RIP Neil Armstrong

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1007024]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others scrutinizing the Monastery: (2)
As of 2024-03-19 06:08 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found