Re: [Cfrg] Encrypt in place guidance

Robert Moskowitz <> Wed, 01 April 2020 14:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2DF693A10A0 for <>; Wed, 1 Apr 2020 07:48:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u2k9TCM3lATn for <>; Wed, 1 Apr 2020 07:48:26 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4AAC93A1088 for <>; Wed, 1 Apr 2020 07:48:26 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 063E56213F; Wed, 1 Apr 2020 10:48:25 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id Nx1hwzwHavYJ; Wed, 1 Apr 2020 10:48:18 -0400 (EDT)
Received: from (unknown []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4444262136; Wed, 1 Apr 2020 10:48:16 -0400 (EDT)
To: Leo Perrin <>
Cc: cfrg <>
References: <> <> <> <> <> <> <> <> <>
From: Robert Moskowitz <>
Message-ID: <>
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: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [Cfrg] Encrypt in place guidance
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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!


> 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.



> Cheers,
> /Léo