Bill Frantz writes:
The http://cryptome.org/usage-logs.htm URL says:
Low resolution data in most cases is intended to be sufficient for marketing analyses. It may take the form of IP addresses that have been subjected to a one way hash, to refer URLs that exclude information other than the high level domain, or temporary cookies.
Note that since IPv4 addresses are 32 bits, anyone willing to dedicate a computer for a few hours can reverse a one way hash by exhaustive search. Truncating IPs seems a much more privacy friendly approach.
This problem would be less acute with IPv6 addresses.
I'm skeptical that it will even take "a few hours"; on a 1.5 GHz
desktop machine, using "openssl speed", I see about a million hash
operations per second. (It depends slightly on which hash you choose.)
This is without compiling OpenSSL with processor-specific optimizations.
That would imply a mean time to reverse the hash of about 2100 seconds,
which we could probably improve with processor-specific optimizations
or by buying a more recent machine. What's more, we can exclude from our
search parts of the IP address space which haven't been allocated, and
optimize the search by beginning with IP networks which are more
likely to be the source of hits based on prior statistical evidence. Even
without _any_ of these improvements, it's just about 35 minutes on average.
I used to advocate one-way hashing for logs, but a 35-minute search on
an ordinary desktop PC is not much obstacle. It might still be
helpful if you used a keyed hash and then threw away the key after a
short time period (perhaps every 6 hours). Then you can't identify or
link visitors across 6-hour periods. If the key is very long,
reversing the hash could become very hard.
The logging problem will depend on what server operators are trying to
accomplish. Some people just want to try to count unique visitors;
strangely enough, they might get more privacy-protective (and comparably
precise) results by issuing short-lived cookies.
--
Seth David Schoen