[dns-operations] IP address encryption: pseudonymization

[Jim Hague]

On 25/02/2018 15:59, Paul Hoffman wrote:
> If only it was that simple. As you can see from the thread on CFRG,
> there are other methods that do not have the inherent limitations of
> ipcrypt: instead, they have different ones.
> 
> The easiest one to describe is
> truncate_to_32_bits(aes_128(message=padded_ipv4, key=128_bit_random)).
> You cannot determine the key even with a huge number of known pairs.
> However, you get collisions in the output. So, if you have 4 million
> unique input addresses, about .1% of the output addresses will look like
> one source of input when in fact they are two sources mixed together.

Going for the above scheme while retaining the straightforward AES-128
for IPv6 (as used in ipcipher) would mean that you can reverse the IPv6
pseudo-anonymisation given knowledge of the key, but you can't reverse
IPv4. This seems a little asymmetrical, and I imagine is the reason for
the selection of ipcrypt in ipcipher. Or, in other words, how desirable
a property is reversibility when considering pseudo-anonymisation schemes?

>From an implementor's PoV, the above description would need some
fleshing out - how exactly does one pad and truncate? Does one pad with
0 values? Random values? Where is the padding inserted - more
significant or less significant bytes? Similarly, which bytes are
selected during truncation?

Not being a crypto specialist, I am more concerned as to whether any
variations in the methods of padding and truncation would affect the
security properties, and whether there are hidden traps awaiting the naive.
-- 
Jim Hague - jim at sinodun.com          Never trust a computer you can't lift.