4 ms·

Huh? Hashing an IP address protects anonymity? Against who? You do realise an IP address is 4 bytes? You could brute force guess the thing in a few minutes, an

by sho 18y ago

Huh? Hashing an IP address protects anonymity? Against who? You do realise an IP address is 4 bytes? You could brute force guess the thing in a few minutes, and generate a rainbow table for the whole possible set in an hour or two, much less if you had a lot of memory. It's no protection whatsoever.

axod 18y ago
Surely that would require you to know the hash and the IP :/ If you only have a hash, how can you brute force it? How do you know when you got back to the correct IP? If a system is only spewing out a stream of hashed IPs, it doesn't seem too easy a problem to deduce the original IPs.
- sho 18y ago
  It depends on who you're trying to protect against. I immediately assumed the government trying to find out who searched for $STRING, implying they have full access to everything else as well. Seeing that you have the hashed IPs, I assumed you have access to the database and probably physical access to the machine. In that case you would just look at the code, or subpoena a programmer, for the hashing algorithm. It wouldn't be anywhere near as easy if you were dealing with some custom algorithm, especially if it were salted, but I can't really think of a situation where you'd have the records but not the rest. Why would hackers be trying to find out which IP searched for what? It's a government thing, surely.
  - axod 18y ago
    Oh sure point taken, if you have the hashes and the hashing algorithm, as you say - it's only a 4 byte input, wouldn't be too hard. You could make the hashing algorithm change over time, which would make things a little harder to reverse. Perhaps my original comment was a little knee jerk, just seems like a problem that has been solved.
    - sho 18y ago
      Solved problem? Sorry to harp on about this but I'll go all out and say it's an _unsolvable_ problem. If you store IP addresses, in any form whatsoever, and you have a process that can take an IP and consistently convert it to the form in your store for lookup - without which, of course, there is no point storing them at all - then because of the small possible set of IPv4 addresses, that system can be quickly and easily brute-forced and the records recovered in full. The only way to store IP addresses such that they cannot be recovered with sufficient leverage (ie, govt) is to not store them at all. Even storing them in memory is not safe - just ask TorrentSpy. The article is light on details but I have a strong suspicion that the ground-breaking "technological development" they are referring to is otherwise known as the "cookie".
      - axod 18y ago
        Well. Storing anything securely depends on some 'secret' information. If you're assuming the 'secret' information can be made public, then of course, it's an unsolvable problem - you can never store anything securely.
        sho 18y ago
        I think we're talking about different things : ) When I consider a search engine obscuring the IP addresses for its search records, I assume the "enemy" is the government. It's governments who want to know who's been searching for child porn and bomb-making instructions. They want the IPs, and they can get the algorithm. Now if you're talking about someone with less resources, who can get the obfuscated records but not everything else, your arguments make perfect sense, but I can't imagine who'd be interested other than governments.
- matthavener 18y ago
  I think he's saying that if you know the hash function, building a reverse lookup table for every IP address is feasible... just look at all the web accessible reverse md5 tables
  - axod 18y ago
    Sure :) I wasn't imagining anyone would md5/sha1 without salt etc
    - sho 18y ago
      All the salt means is that you can't use a so-called rainbow table. Assuming the salt is known, and it must be for the system itself to be able to look up its own records, you can simply recreate the salted string and start from the beginning with that. There are 4 billion possible combinations. A single nVidia 9800GX2 can try 608 million of those* per second. You do the math. Sorry to pick on you mate : ) * md5, http://www.elcomsoft.com/lhc.html http://www.elcomsoft.com/lhc.html
      - axod 18y ago
        "Assuming the salt is known" Look. For the last time. I'm assuming there is some secret information that is not known. I shall stop posting to this thread because that bit doesn't seem to be getting across well :)
        sho 18y ago
        That is your prerogative of course, but your understanding of what a salt is is flawed. It is not an encryption key. It is a layer of defence to frustrate automated attacks, and is almost always stored right next to the hash in the same table. In security design, it is assumed that if the hash is known, the salt is also known. I am kind of scratching my head trying to imagine what kind of setup you are envisaging. If the salt isn't stored in the DB, where is it stored?! Maybe a sysadmin, manually entering the secret password from memory on every request? ;)

by sho 18y ago

axod 18y ago

Surely that would require you to know the hash and the IP :/ If you only have a hash, how can you brute force it? How do you know when you got back to the correct IP? If a system is only spewing out a stream of hashed IPs, it doesn't seem too easy a problem to deduce the original IPs.

sho 18y ago
It depends on who you're trying to protect against. I immediately assumed the government trying to find out who searched for $STRING, implying they have full access to everything else as well. Seeing that you have the hashed IPs, I assumed you have access to the database and probably physical access to the machine. In that case you would just look at the code, or subpoena a programmer, for the hashing algorithm. It wouldn't be anywhere near as easy if you were dealing with some custom algorithm, especially if it were salted, but I can't really think of a situation where you'd have the records but not the rest. Why would hackers be trying to find out which IP searched for what? It's a government thing, surely.
- axod 18y ago
  Oh sure point taken, if you have the hashes and the hashing algorithm, as you say - it's only a 4 byte input, wouldn't be too hard. You could make the hashing algorithm change over time, which would make things a little harder to reverse. Perhaps my original comment was a little knee jerk, just seems like a problem that has been solved.
  - sho 18y ago
    Solved problem? Sorry to harp on about this but I'll go all out and say it's an _unsolvable_ problem. If you store IP addresses, in any form whatsoever, and you have a process that can take an IP and consistently convert it to the form in your store for lookup - without which, of course, there is no point storing them at all - then because of the small possible set of IPv4 addresses, that system can be quickly and easily brute-forced and the records recovered in full. The only way to store IP addresses such that they cannot be recovered with sufficient leverage (ie, govt) is to not store them at all. Even storing them in memory is not safe - just ask TorrentSpy. The article is light on details but I have a strong suspicion that the ground-breaking "technological development" they are referring to is otherwise known as the "cookie".
    - axod 18y ago
      Well. Storing anything securely depends on some 'secret' information. If you're assuming the 'secret' information can be made public, then of course, it's an unsolvable problem - you can never store anything securely.
      - sho 18y ago
        I think we're talking about different things : ) When I consider a search engine obscuring the IP addresses for its search records, I assume the "enemy" is the government. It's governments who want to know who's been searching for child porn and bomb-making instructions. They want the IPs, and they can get the algorithm. Now if you're talking about someone with less resources, who can get the obfuscated records but not everything else, your arguments make perfect sense, but I can't imagine who'd be interested other than governments.
matthavener 18y ago
I think he's saying that if you know the hash function, building a reverse lookup table for every IP address is feasible... just look at all the web accessible reverse md5 tables
- axod 18y ago
  Sure :) I wasn't imagining anyone would md5/sha1 without salt etc
  - sho 18y ago
    All the salt means is that you can't use a so-called rainbow table. Assuming the salt is known, and it must be for the system itself to be able to look up its own records, you can simply recreate the salted string and start from the beginning with that. There are 4 billion possible combinations. A single nVidia 9800GX2 can try 608 million of those* per second. You do the math. Sorry to pick on you mate : ) * md5, http://www.elcomsoft.com/lhc.html http://www.elcomsoft.com/lhc.html
    - axod 18y ago
      "Assuming the salt is known" Look. For the last time. I'm assuming there is some secret information that is not known. I shall stop posting to this thread because that bit doesn't seem to be getting across well :)
      - sho 18y ago
        That is your prerogative of course, but your understanding of what a salt is is flawed. It is not an encryption key. It is a layer of defence to frustrate automated attacks, and is almost always stored right next to the hash in the same table. In security design, it is assumed that if the hash is known, the salt is also known. I am kind of scratching my head trying to imagine what kind of setup you are envisaging. If the salt isn't stored in the DB, where is it stored?! Maybe a sysadmin, manually entering the secret password from memory on every request? ;)