Re: [Cfrg] Analysis of ipcrypt?

Martin Thomson <> Fri, 23 February 2018 00:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9F24912D93E for <>; Thu, 22 Feb 2018 16:46:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YdI3w98UVWz0 for <>; Thu, 22 Feb 2018 16:46:25 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c0f::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E1735124D37 for <>; Thu, 22 Feb 2018 16:46:24 -0800 (PST)
Received: by with SMTP id s4so6360860oth.7 for <>; Thu, 22 Feb 2018 16:46:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=MaQ9tGCtgPodyVebJfclKRrBkRPW2jg6jZNSnBxkjAo=; b=BfA/MD7ZVkv4pYuyeh1jhAWCrY420z41f/fwpl49X8Fs8I3SWGTL5i7+vtXA/9Ygnl KqUZsTTitZr1W4Ssudav2olDUCdaulDm+m01uT8S0gghnKwC9Tu4sxuYCS5+8h7j7XUv 3VJzi29JpEN9xq9ZcDLYI9XXMl94wAoifMMeiqw4IIfZrJ66dOEljUYLcQrLN2rGYaoU CcKdG+kF33lnsWHEgT74e+ndSb6SIiCJDf8+2CH2XL9AGjAaI3zwJtOaREp9mvsUT56c /PN/OFHxSnMF088YzBunJp5QSZias1tqZb6r/DHBRznUoeMzfSPP536ucGmmnnJiYAAX PkMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=MaQ9tGCtgPodyVebJfclKRrBkRPW2jg6jZNSnBxkjAo=; b=mFO/uhwZMj5838RaoZsLj5qLhnnKj74GGooId6PsBqcd4OeU+3xQ2K/6hrPCUzkYJG PKZaFRMpKRttGy4nI2fVt9TYFzdBbZnRYpfzTsFaHgIRNvdkTPZ/kTKXSYhDwT7Velx3 4uNe7Y6OytbBIL3d2ivlxSXCrzawp1doGBC31TrE2kcCMX6KBPISy/RXmWKWDA5ii0nN RoVgylpjCj/cglMuAhwX6HEoe325lBE7Op/v8pIKncFFfI9laCAs7PXnBK1Zgw4yDwim 5smw2yKcNLMA2UAKNzV7N3TzyiVWd1nYU6mtaBJEsClyH9YeSQFaLNCVV0GQEHuXCgJh gFww==
X-Gm-Message-State: APf1xPDKGNfC9g4QEHB3pCCBAHUvkEeTT+IKrELUtBdQ+gil73LPeWT7 BJY3Vd0N6PNP+UqThrxfVbn+hrcLOGh+ophcoH0=
X-Google-Smtp-Source: AH8x225TubkKAC9zToRjbHW8mp/OkKrQHW+QuwmG2EiFJf/AqaIf+0fIj4Mq9uZpv5NGfvFOUUI8CGZhARhFuJdbLFM=
X-Received: by with SMTP id e3mr6895464otf.15.1519346784095; Thu, 22 Feb 2018 16:46:24 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 22 Feb 2018 16:46:23 -0800 (PST)
In-Reply-To: <>
References: <>
From: Martin Thomson <>
Date: Fri, 23 Feb 2018 11:46:23 +1100
Message-ID: <>
To: Paul Hoffman <>
Cc: "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Cfrg] Analysis of ipcrypt?
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 23 Feb 2018 00:46:27 -0000

Have you looked at FFX?  That has much stronger claims than those for
ipcrypt and it doesn't suffer the problem DKG described with Russ'
simple scheme.  It's a fair bit more computationally expensive though
- it uses a Feistel network with a decent number of iterations, which
means that the PRF (typically AES) needs to be run more often than you
might think.

On Thu, Feb 22, 2018 at 1:03 PM, Paul Hoffman <> wrote:
> 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
> _______________________________________________
> Cfrg mailing list