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

Paul Hoffman <paul.hoffman@icann.org> Fri, 23 February 2018 00:19 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 4D9C512D873 for <cfrg@ietfa.amsl.com>; Thu, 22 Feb 2018 16:19:05 -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 FrackV1sFZ1B for <cfrg@ietfa.amsl.com>; Thu, 22 Feb 2018 16:19:03 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9890124D37 for <cfrg@irtf.org>; Thu, 22 Feb 2018 16:19:03 -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; Thu, 22 Feb 2018 16:19:01 -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; Thu, 22 Feb 2018 16:19:01 -0800
From: Paul Hoffman <paul.hoffman@icann.org>
To: Greg Rose <ggr@seer-grog.net>
CC: "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Topic: [Ext] Re: [Cfrg] Analysis of ipcrypt?
Thread-Index: AQHTq4FV84DWjG/sGkWrR5RTwD6BUKOwqWKAgABT0wCAAKYqAIAAAlsAgAABLQA=
Date: Fri, 23 Feb 2018 00:19:01 +0000
Message-ID: <A17CCC93-1AEE-47E3-B1A3-CA2791AA3AE0@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>
In-Reply-To: <149857F4-859F-45C8-AA6E-E1F72342B988@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=_1CBA7A22-556C-40E5-BD61-7B8FF9B0511C"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/BuEUBio2IhBLzOVsyIuUEN0O-8Q>
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 00:19:05 -0000

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