Re: [Cfrg] Encrypt in place guidance

Robert Moskowitz <rgm-sec@htt-consult.com> Wed, 01 April 2020 14:48 UTC

Return-Path: <rgm-sec@htt-consult.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 2DF693A10A0 for <cfrg@ietfa.amsl.com>; Wed, 1 Apr 2020 07:48:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 u2k9TCM3lATn for <cfrg@ietfa.amsl.com>; Wed, 1 Apr 2020 07:48:26 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AAC93A1088 for <cfrg@ietf.org>; Wed, 1 Apr 2020 07:48:26 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 063E56213F; Wed, 1 Apr 2020 10:48:25 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Nx1hwzwHavYJ; Wed, 1 Apr 2020 10:48:18 -0400 (EDT)
Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 4444262136; Wed, 1 Apr 2020 10:48:16 -0400 (EDT)
To: Leo Perrin <leo.perrin@inria.fr>
Cc: cfrg <cfrg@ietf.org>
References: <83571efb-a32f-6a59-a496-de56716f07da@htt-consult.com> <a16dcbe63aa745e482a3f435aa8e0470@blackberry.com> <f5e4c7a3-e039-ec7d-59b7-0c581d9022e6@htt-consult.com> <9ACD4ECA-CFBF-40DC-8CB8-BB7DAEFBB42D@ll.mit.edu> <d4383234-d452-dad8-52dc-dd35dbecbb8a@htt-consult.com> <4d64bcce-7f9e-9ec4-e73b-45e2c57d5de6@cs.tcd.ie> <1938299699.23565911.1585728427697.JavaMail.zimbra@inria.fr> <96a4b21c-2ba2-ac2f-e84d-9a13a5c24d69@htt-consult.com> <2035303591.24133736.1585748191997.JavaMail.zimbra@inria.fr>
From: Robert Moskowitz <rgm-sec@htt-consult.com>
Message-ID: <bf65d2a7-5621-1907-5e24-f2501e0dd8b8@htt-consult.com>
Date: Wed, 1 Apr 2020 10:48:12 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <2035303591.24133736.1585748191997.JavaMail.zimbra@inria.fr>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/MsYAHtfPADkqb3G3CxcEKPAauOA>
Subject: Re: [Cfrg] Encrypt in place guidance
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
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: Wed, 01 Apr 2020 14:48:28 -0000


On 4/1/20 9:36 AM, Leo Perrin wrote:
>> So I am looking for both a 64 bit and 96 bit block cipher.  I figured
>> out that if there is no 96 bit, I can do this by first encrypting the
>> 1st 64 bits and then the last 64 bits.  The middle 32bits are double
>> encrypted, but I not seeing that as a problem. But then I am not a
>> cryptographer, only a crypto-plumber.
> I would advise you *not* to do this: this effectively creates a 96-bit block cipher with at least one significant flaw.

This is why I know to ask on this list.

> Suppose that your plaintext is (A,B,C), where each word is 32-bit long, and that you use a block cipher E_k operating on 64 bits. Then you would first obtain (W,X) = E_k(A,B), and then (Y,Z) = E_k(X,C), so that the encryption of (A,B,C) is (W,Y,Z). The problem with this approach is that W does not depend on C. A similar behaviour exists for decryption (C does not depend on W). As a consequence, this 96-bit block cipher does not provide full diffusion!

Ah.

> It is better to use a dedicated 96-bit block cipher. There are not many of them but they exist:
> - BKSQ, from the AES designers (essentially a 96-bit AES);
> - SEA,
> - EPCBC.
> The references for these are in our survey.

Good.  Thanks for the pointers.

> If you really need to turn a 64-bit block cipher into a 96-bit one, then you would need to do at least 3 iterations of the 64-bit cipher instead of 2 as you suggested:
>
> (A, B, C) ---(E_k, Id)---> (W, X, C)
> (W, X, C) ---(Id, E_k)---> (W, Y, Z)
> (W, Y, Z) ---(E_k, Id)---> (T, U, Z)
>
> Still: from a security stand-point, I would much prefer a dedicated 96-bit cipher if I were in your position.

I would also prefer a real 96 bit cipher than tricking a 64 bit to do 
the job, but it is good to know the proper construct.

Thanks

Bob

> Cheers,
>
> /Léo
>
>