Re: [Cfrg] [Ext] Re: Analysis of ipcrypt?

A “non-invertible” construction based on truncated AES will yield many
collisions if format-preserving (hashing to a 32-bit space), and it’ll
likely become partially invertible with sufficiently many known in-out
pairs.
On Sat, 24 Feb 2018 at 16:31, Paul Hoffman <paul.hoffman@icann.org> wrote:

> On Feb 24, 2018, at 6:41 AM, Greg Rose <ggr@seer-grog.net> wrote:
> >
> >
> >> On Feb 23, 2018, at 23:34 , Jean-Philippe Aumasson <
> jeanphilippe.aumasson@gmail.com> wrote:
> >>
> >> Seconding David. We're talking tokenization more than encryption. In
> the context where I created ipcrypt we just needed to obfuscate the PII
> data (such as IP addresses) in a deterministic and format-preserving way.
> >
> > Now I'm confused. Is there a requirement for invertability or not? The
> problem, if it isn't invertible, is that it will act as a hash, and you can
> expect collisions after only about 60k entries. Are there consequences to
> that?
>
> This is a problem that is being debated by the users of the system.
>
> - Invertability is a great feature if we can get it without concern that
> it lets an attacker with a lot of known pairs recover the key so they can
> then deanonymize all the pairs.
>
> - Non-invertable (current proposal is truncate32(AES128(32_bit_address,
> 128_bit_random_key))) causes collisions, but those collisions only affect
> researchers looking over a dataset who are trying to determine why party X
> sent a particular stream of messages. When there are collisions, two
> parties' streams get merged; however, with mix-and-truncate, there the
> attacker cannot determine the key from lots of known pairs.
>
> There is a difficult balance: the party anonymizing the data has a much
> higher cost if the data is deanonymized than the benefit that is going to
> the party reading the data. One safe way to anonymize the addresses is to
> set them all to 0.0.0.0, but that makes them useless to the readers. The
> question is how far beyond that simple safe mechanism the anonymizing party
> should go, and at what cost. That's not a question that can be handled in
> CFRG (and it's not clear we will handle it well in the DNS operators fora).
>
> --Paul Hoffman_______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>