Re: [Cfrg] Analysis of ipcrypt?

[Tim Hollebeek <[e-mail]>]

Why use a low security toy cipher, when there are high security FPE algorithms available, which provide full strength and are reasonably efficient?  A number of them are being standardized as part of the work by ANSI ASC X9F1.

 

In particular, output sizes that are 2^n lead to very efficient implementations of most FPE algorithms.  They’re basically just Feistel structures over 32-bit blocks, using AES or something similar as the round function.

 

-Tim

 

From: Cfrg [mailto:[e-mail]] On Behalf Of Jean-Philippe Aumasson
Sent: Wednesday, February 21, 2018 11:55 PM
To: Paul Hoffman <[e-mail]>
Cc: [e-mail]
Subject: Re: [Cfrg] Analysis of ipcrypt?

 

Hi!

I designed ipcrypt as a low-security toy cipher to encrypt IPv4 addresses for some log analysis application. It may be good enough for this purpose, however it has very low security:

 

* because of 32-bit blocks, a chosen-plaintext codebook attack will work in time 2^32 (or much less for specific IP ranges)

 

* known-plaintext codebook attacks will work similarly but in O(n log n), or 2^37 (coupon collector problem)

 

* there is a generic ~2^16 distinguisher that works by looking for a collision in a sequence of blocks

 

* worse, Jason just found a high-probability differential that seems detectable with fewer than 2^24 chosen-plaintext pair, and which may speed up key recovery

 

 

 

On Thu, 22 Feb 2018 at 03:03, Paul Hoffman <[e-mail] <mailto:[e-mail]> > 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:
   https://github.com/veorq/ipcrypt
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
[e-mail] <mailto:[e-mail]> 
https://www.irtf.org/mailman/listinfo/cfrg