On Mar 1, 2018, at 11:20 AM, Brian Dickson <brian.peter.dickson@gmail.com> wrote:
Most (or all) of the proposal use encryption as the anonymization technique.
To be exact, they use encryption for the mixing portion of the anonymization technique.
I wonder if the goals might be better achieved with some kind of crypto one-way hash instead.
Encryption and hash algorithms both mix equivalently well. For inputs smaller than 128 bits, encryption is a bit faster, but no one will notice the speed difference in the anonymization methods described here.
Selecting a common hash, and common salt or salting method, allows queries which are hashed with the same salt, at different root servers, to be matched up, which I think is a useful property.
It is a useful property to people using the anonymized data, and that property comes with the downsides to the RSOs listed in Section 2.1. So far, people have agreed that the downsides are reason enough not to pursue it. Are you saying otherwise?
Examples of a rotating salt (reducing the long-term identification problem by increasing the amount of work) might include: - daily UTC (or hourly, or whatever) - current (root) ZSK (rotates every N days, IIRC) - others?
This proposal assumes that all the RSOs could coordinate the rotating of the salt and keeping each salt secret forever. To me, both of those are daunting. On Mar 1, 2018, at 4:56 PM, Wessels, Duane <dwessels@verisign.com> wrote:
Yeah, I wouldn't mind seeing hashing as one of the options (for completeness if nothing else).
I would prefer to simply have text to the document that says that they are equivalent mixing functions for methods 3.1 and 3.2. The current text from Section 3 says: Mixing using encryption is typically done with AES-128; mixing using hashes is typically done with SHA-256. The mixing functions of both AES-128 and SHA-256 are considered completely secure. Because AES-128 is usually faster than SHA-256 for small inputs such as IP addresses, only mixing with AES-128 is described here. I don't think that doing 3.1 and 3.2 with hash functions that have the same effective output strength and speed will help readers understand.
I don't really know if efficiency will be a deciding factor. They might all be efficient enough.
They are, although AES wins by a bit.
As far as I can see, hashing's main advantage is irreversibility. One of the proposed methods (mixing full addresses with truncation) is irreversible, but only for IPv4. None of the techniques offers IPv6 irreversibility.
To be clear, both 3.1 and 3.2 are irreversible. In 3.2, every bit is mixed and then truncated, which makes it irreversible. Only 3.3 is reversible, and even then, only reversible if you know the key. The problem with 3.3 is that the key may be more easily discoverable than one would hope. --Paul Hoffman