IETF Logo Mail Archive

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

Paul Hoffman <paul.hoffman@icann.org> Sat, 24 February 2018 15:31 UTC

Return-Path: <paul.hoffman@icann.org>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 610C01270FC for <cfrg@ietfa.amsl.com>; Sat, 24 Feb 2018 07:31:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGfsfzwOQXoR for <cfrg@ietfa.amsl.com>; Sat, 24 Feb 2018 07:31:08 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA04F12025C for <cfrg@irtf.org>; Sat, 24 Feb 2018 07:31:08 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 24 Feb 2018 07:31:07 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Sat, 24 Feb 2018 07:31:07 -0800
From: Paul Hoffman <paul.hoffman@icann.org>
To: "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Topic: [Cfrg] [Ext] Re: Analysis of ipcrypt?
Thread-Index: AQHTrUH0MeO6VVxatU2H2XlK7gdaSqO0JsgAgAANyIA=
Date: Sat, 24 Feb 2018 15:31:06 +0000
Message-ID: <752714BA-FC71-4B37-8685-7E44A68989B5@icann.org>
References: <18C83761-E442-45D9-BDBF-71DC7F751007@icann.org> <CAHmME9r3awwZxjEU-HWnOCyARhBx54VOcUOFJB4opmneKdZsyA@mail.gmail.com> <72BE956C-7D0F-41BE-88DE-C7C2063A7FED@seer-grog.net> <877er4h8n5.fsf@fifthhorseman.net> <149857F4-859F-45C8-AA6E-E1F72342B988@seer-grog.net> <A17CCC93-1AEE-47E3-B1A3-CA2791AA3AE0@icann.org> <6063D40B-F8A8-4C63-92EB-53EF4DB64975@cisco.com> <CAGiyFdddeUkqhMxQLH079syiHuV3KgY3_Ko2pVxYhjd+jEUMLA@mail.gmail.com> <E04CDD47-DCB3-456E-A8A6-EE93B63442B0@seer-grog.net>
In-Reply-To: <E04CDD47-DCB3-456E-A8A6-EE93B63442B0@seer-grog.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
Content-Type: multipart/signed; boundary="Apple-Mail=_BCE47EDB-C214-424E-AE3F-650091F293AF"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/_abm_4S6sHi5BMNt-z9-lJQ2CFs>
Subject: Re: [Cfrg] [Ext] Re: Analysis of ipcrypt?
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Feb 2018 15:31:10 -0000

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

v2.23.0 | Report a Bug | By Email