Re: [Cfrg] Encrypt in place guidance

Robert Moskowitz <> Wed, 01 April 2020 12:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3851D3A0D1D for <>; Wed, 1 Apr 2020 05:16:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JV3djjY5h0bq for <>; Wed, 1 Apr 2020 05:16:11 -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 C9DD63A0D1B for <>; Wed, 1 Apr 2020 05:16:11 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id F30446213F; Wed, 1 Apr 2020 08:16:09 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id WgKmomQnOARC; Wed, 1 Apr 2020 08:16:03 -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 B65DE62136; Wed, 1 Apr 2020 08:16:00 -0400 (EDT)
To: Leo Perrin <>, Stephen Farrell <>
References: <> <> <> <> <> <> <>
From: Robert Moskowitz <>
Message-ID: <>
Date: Wed, 1 Apr 2020 08:15:56 -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 12:16:13 -0000


Thank for this paper. I will investigate the various ciphers in it.

I suspect that after Apr 9 (next ASTM meeting), I will need to encrypt 
96 bits as they address the lack of Operator altitude in the message.  I 
cannot attend the meeting, as it schedule during Passover.  Oh well, my 
colleagues will be there to put forth my position.

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.

Again thank you for your assistance.


On 4/1/20 4:07 AM, Leo Perrin wrote:
> Hi,
>>> Speck
>> Hmm. Were the design criteria for that algorithm
>> ever published in the end? (I've not followed it,
>> so they may have been.)
> The authors of SPECK put something on eprint [1] but it merely lists public results and claims they already knew about the corresponding attacks. I personally don't find this document convincing at all since it came *after* a public analysis. In my opinion (and it is not a controversial one in the academic symmetric crypto community), if the designers of a cipher did not publish their security analysis along with its specification then you should not even consider using the corresponding cipher. Of course, there is also the elephant in the room: SPECK was designed by the same entity as the backdoored DUAL_EC.
> By the way, there are many (many!) 64-bit block ciphers in the literature---see Table 6 of [2]. Full disclosure: I am a co-author of this survey. If you have questions about it, feel free to ask!
> [1]
> [2]
> Cheers,
> /Léo
> _______________________________________________
> Cfrg mailing list