Re: [Cfrg] Analysis of ipcrypt?

Russ Housley <housley@vigilsec.com> Fri, 23 February 2018 21:11 UTC

Return-Path: <housley@vigilsec.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 9C136124207 for <cfrg@ietfa.amsl.com>; Fri, 23 Feb 2018 13:11:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.308
X-Spam-Level:
X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592] autolearn=no 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 1glIRm01SBF4 for <cfrg@ietfa.amsl.com>; Fri, 23 Feb 2018 13:11:26 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A8761241F5 for <cfrg@irtf.org>; Fri, 23 Feb 2018 13:11:26 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 41FD73009FF for <cfrg@irtf.org>; Fri, 23 Feb 2018 16:11:24 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DR7rNS3ynByq for <cfrg@irtf.org>; Fri, 23 Feb 2018 16:11:21 -0500 (EST)
Received: from new-host-7.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 0273130041E; Fri, 23 Feb 2018 16:11:20 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <87a7w0h8zq.fsf@fifthhorseman.net>
Date: Fri, 23 Feb 2018 12:05:42 -0500
Cc: Paul Hoffman <paul.hoffman@icann.org>, Samuel Neves <sneves@dei.uc.pt>, IRTF CFRG <cfrg@irtf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <02CB8B1F-116B-4D3E-AE93-34705442278F@vigilsec.com>
References: <18C83761-E442-45D9-BDBF-71DC7F751007@icann.org> <CAHmME9r3awwZxjEU-HWnOCyARhBx54VOcUOFJB4opmneKdZsyA@mail.gmail.com> <D13E3BE0-45AB-481B-885A-35853EFE2A86@vigilsec.com> <87a7w0h8zq.fsf@fifthhorseman.net>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/w5Xa0HHZGFjzz9AloznMQZfQbIE>
Subject: Re: [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: Fri, 23 Feb 2018 21:11:27 -0000

DKG:
> 
> On Thu 2018-02-22 18:30:36 -0500, Russ Housley wrote:
>> 
>> It sounds like you want a simple and straightforward way to obfuscate IPv4 addresses.
>> 
>> AES is very widely implemented.  You can find libraries for every platform.  So, something like this may do it for you:
>> 
>> 	k = rand()  /* 128 bits; fresh key for each dataset */
>> 
>> 	for each ipv4addr in dataset:
>> 		plain = ipv4addr || ipv4addr || ipv4addr || ipv4addr
>> 		obfuscated_ipv4addr = trunc32(AES_128_Encrypt(k, plain))
> 
> This approach doesn't allow inverting the address if needed.  aiui, the
> use case for ipcrypt and other format-preserving encryption is attack
> detection and mitigation via anomaly detection, based on packet
> captures, but with phased destruction of the IP addresses.

Paul's description did not say that inversions was a requirement.  And, if you know the AES key, the work factor is _at_most_ 2^32 AES block operations.  That is within reach on my laptop.

The FF1 and FF3 solutions are fine solutions.  If the number of times that one has to remove the obfuscation is very low, then the lower encrypt cost of the above algorithm may be desirable.

Russ