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

"David McGrew (mcgrew)" <mcgrew@cisco.com> Fri, 23 February 2018 14:26 UTC

Return-Path: <mcgrew@cisco.com>
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 56ADC127201 for <cfrg@ietfa.amsl.com>; Fri, 23 Feb 2018 06:26:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 anHNk_MpHFdC for <cfrg@ietfa.amsl.com>; Fri, 23 Feb 2018 06:25:58 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F7DD120047 for <cfrg@irtf.org>; Fri, 23 Feb 2018 06:25:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3654; q=dns/txt; s=iport; t=1519395958; x=1520605558; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Eg88HwELUU6ayZcmVVdWmUI2HA4A10jEU5h5AFa1WO0=; b=OnPhcxRO/1uQb2MYcHaQZSLoiPGbWA/ztK2oFVEcdtEo8iregrRoXvRf CqtagRoJqejN28nqh4ipOD5YJZCPTjaS2E++MdrNUSa9VJ8Ye0B0R8SBi 6LDsD+CaacMD+BEaOJl9clxSrpfiREDH9IzyHhpr67yh9u7csveH6MwbE k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DcAgBZI5Ba/5RdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMeMYFWKAqDXpghggKBFpZRghYKhTMCGoIeVRcBAgEBAQEBAQJ?= =?us-ascii?q?rKIUkAQUjEUUQAgEIGAICJgICAjAVEAIEAQ0FiiOrZIInhQCDd4IeAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBHYEPhAmCJ4Nmgk42hHoRgy0xgjQFkmeRWwkCi2JNiV+?= =?us-ascii?q?CH4Ypi32XfgIRGQGBOwEhATaBUXAVZAGCGIJUHIIGeIoDgTSBGQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.47,383,1515456000"; d="scan'208";a="74911462"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Feb 2018 14:25:57 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id w1NEPvXJ021541 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 23 Feb 2018 14:25:57 GMT
Received: from xch-aln-004.cisco.com (173.36.7.14) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 23 Feb 2018 08:25:56 -0600
Received: from xch-aln-004.cisco.com ([173.36.7.14]) by XCH-ALN-004.cisco.com ([173.36.7.14]) with mapi id 15.00.1320.000; Fri, 23 Feb 2018 08:25:57 -0600
From: "David McGrew (mcgrew)" <mcgrew@cisco.com>
To: Paul Hoffman <paul.hoffman@icann.org>, Greg Rose <ggr@seer-grog.net>
CC: "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Topic: [Cfrg] [Ext] Re: Analysis of ipcrypt?
Thread-Index: AQHTrDvvGyNym6kRFkaPvgvVe4EwUqOyHLmA
Date: Fri, 23 Feb 2018 14:25:57 +0000
Message-ID: <6063D40B-F8A8-4C63-92EB-53EF4DB64975@cisco.com>
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>
In-Reply-To: <A17CCC93-1AEE-47E3-B1A3-CA2791AA3AE0@icann.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.15.1.160411
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.8.27]
Content-Type: text/plain; charset="utf-8"
Content-ID: <691DE4171C93EF49BADA0890198E2617@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/CDdURGJhZwGT0ldqF9yTTSxWb0I>
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: Fri, 23 Feb 2018 14:26:00 -0000

Hi Paul,

Besides the particulars of the cipher, it is important to realize that deterministic encryption of addresses, or any other identifier, provides a limited amount of security against a dedicated attacker.  You surely know this already, but it is a point worth raising in this thread.  Deterministic encryption of addresses is worth using, in my opinion, but it is important that end users understand the limitations.

The best example of the security limitation is the following.   Suppose that you have a set of (source address, destination address, port, protocol, time) tuples for a corporation, where source addresses (but not destination addresses) have been anonymized through deterministic encryption of addresses.  Your goal is to find the traffic of the CEO, and you start by gathering intelligence about that individual (alma mater, state of origin, etc.) then construct a set of server addresses that the target is likely to visit.  With this data, you now have enough to achieve “robust deanonymization of large, sparse datasets” (as per Narayanan and Shmatikov).   If, on the other hand, the destination addresses are anonymized, the deanonymization challenge is harder (and the data set is less useful).  

For the record, I’ve used deterministic encryption of IPv4 addresses using a single AES-128 invocation, using the simple approach of padding out the 32-bit address to a 128-bit plaintext, then making room for the ciphertext.  In my application, the addresses are stored as JSON, so the expansion is not hard to accomodate.

best

David


On 2/22/18, 7:19 PM, "Cfrg on behalf of Paul Hoffman" <cfrg-bounces@irtf.org on behalf of paul.hoffman@icann.org> wrote:

>On Feb 22, 2018, at 4:14 PM, Greg Rose <ggr@seer-grog.net> wrote:
>> Anyone who wants to do 32-bit encryption with a key longer than 80 bits already needs to have their threat model reviewed ;-).
>
>OK, so please review what I said at the top of the thread:
>
>For a project I'm on, ipcrypt is attractive if an attacker cannot derive the 128-bit random key without a lot (maybe 2^80ish) effort. For cases in common use, assume that the attacker has 2^24 known plaintext/ciphertext pairs under a single 128-bit random key. For additional ciphertexts, how much effort must the attacker expend to get the key in order to decrypt additional unknown ciphertexts?
>
>The threat model then is that an attacker with 2^24 known plaintext/ciphertext pairs wants to determine the 128-bit random key that was used so that the attacker can de-anonymize addresses that are not in their current set.
>
>Why is that threat model worth a smiley?
>
>--Paul Hoffman