[Cfrg] Analysis of ipcrypt?

Paul Hoffman <paul.hoffman@icann.org> Thu, 22 February 2018 02:03 UTC

Return-Path: <paul.hoffman@icann.org>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id AABB8126CC4 for <cfrg@ietfa.amsl.com>; Wed, 21 Feb 2018 18:03:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id tL2tffDf2G_v for <cfrg@ietfa.amsl.com>; Wed, 21 Feb 2018 18:03:32 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 621DF126C83 for <cfrg@irtf.org>; Wed, 21 Feb 2018 18:03:32 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org ( by PMBX112-W1-CA-2.pexch112.icann.org ( with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 21 Feb 2018 18:03:30 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([]) with mapi id 15.00.1178.000; Wed, 21 Feb 2018 18:03:30 -0800
From: Paul Hoffman <paul.hoffman@icann.org>
To: "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Topic: Analysis of ipcrypt?
Thread-Index: AQHTq4FVsuo4dcsJg0eN6RT04Ck8yg==
Date: Thu, 22 Feb 2018 02:03:29 +0000
Message-ID: <18C83761-E442-45D9-BDBF-71DC7F751007@icann.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_99C54FAD-A360-4509-A63F-AC42CF2E9F19"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/PcU98zjzYg6ti74VWK-RnFL2cXc>
Subject: [Cfrg] 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: Thu, 22 Feb 2018 02:03:33 -0000

Greetings. ipcrypt is a format-preserving cipher for IPv4 addresses. It has a 32-bit blocksize for input and output, and 128-bit blocksize for the key. It was developed by Jean-Philippe Aumasson and is described at:
There doesn't appear to be any formal paper describing the algorithm, but the Python and Go code is trivial to follow.

This algorithm is now being considered by a few different projects that want to obfuscate IPv4 addresses. Has anyone analyzed the algorithm? I could not find analyses, but certainly could have missed them.

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?

(Note that there are other options for this use case, which have different positive and negative features. What we'd like to know is how good is ipcrypt if we chose it.)

--Paul Hoffman