in reply to Re^4: monastery mark-upedness (display IPs)
in thread monastery mark-upedness

...my plan was to make the hash so that, for example, if the first three octets of the IP match, then the first three chunks of the hash would match

That sounds like a nice goal, but one thing to be wary of is making brute force attacks too easy. If you publish a hash of only the first three octets of an IP address, that's a somewhat smaller range of numbers I have to plough through to guess what the original numbers are. I get an even bigger advantage if I check only the blocks that I know are registered to some organization and look first at blocks from English speaking countries, etc.

Just a thought.

  • Comment on Re^5: monastery mark-upedness (brute force)

Replies are listed 'Best First'.
Re^6: monastery mark-upedness (brute force)
by Fletch (Bishop) on Mar 21, 2008 at 16:23 UTC

    Quite right; at worst a naive dictionary of md5s for the entire 32 bit IPv4 range would be 64G ( ( 16 * 2**32 ) / ( 2**30 ) ) which would fit on a keychain these days (not to mention winnowing out multicast and unroutable addresses would shrink it from there). You'd want to toss in some sort of not-public salt so Eve can't do a dictionary attack (and maybe the salt used for anonomonks could move periodically so that it's constant over the life of a thread but varies unpredictably month-to-month).

    The cake is a lie.
    The cake is a lie.
    The cake is a lie.

      Who said I was going to announce the hashing algorithm used?

      Yes, that is right, I'm talking about security through obscurity!

      I was going to obscure the hashing algorithm used just like Fletch proposes obscuring the "not-public salt". But I considered that too obvious to mention since using a known hash on something as tiny as an IP address would be silly to the point of being stupid, no?

      Thanks for mentioning that, Fletch. That interpretation would have likely never occurred to me. :)

      - tye        

Re^6: monastery mark-upedness (brute force)
by tye (Sage) on Mar 21, 2008 at 16:23 UTC

    I wasn't going to only display the first 3 octets. And if you have the resources to post anonymous nodes from any IP address you want to, then I probably have more to fear from you than you figuring out what IP addresses anonymous postings to PerlMonks come from.

    - tye        

      I'm not concerned about someone forging an IP address. I'm talking about just figuring out where it is. Some of our monks my want to retain the privacy of not having their IP address available to others. If the scheme for hiding IP addresses is vulnerable to a brute force attack, we might as well just publish them in the clear.

      Admittedly, my thoughts on this are based on a design that's not completely defined, so this may all be gnashing for nothing.

        And my point was how do you "brute force" an algorithm that is only run on the IP address that an anonymous node at PerlMonks is posted via?

        All security is relative and has the potential to be broken. So by your logic, we should just abanodon all of it.

        If somebody can spoof TCP from arbitrary IP addresses, I doubt they'll be wasting their considerable resources trying to sniff out the IP address of some "anonymous" poster to PerlMonks.

        A more realistic privacy concern is somebody realizing that some other anonymous poster is posting through their same corporate firewall. Which would simply be another reason to post "anonymously" by registering as "codejunkie" via some gmail account.

        So, no, I don't consider "brute force" a big concern for an anonymous posting IP addressing hash function. But privacy concerns certainly should be raised before something like this is implemented (something I only give moderate odds of ever happening).

        - tye