Re: [Cfrg] Encrypt in place guidance

"Blumenthal, Uri - 0553 - MITLL" <> Wed, 01 April 2020 01:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 72EBF3A0F01 for <>; Tue, 31 Mar 2020 18:10:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.282
X-Spam-Status: No, score=0.282 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uHWBkZ-TSJmo for <>; Tue, 31 Mar 2020 18:10:23 -0700 (PDT)
Received: from (LLMX3.LL.MIT.EDU []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 06AC93A0EF9 for <>; Tue, 31 Mar 2020 18:10:22 -0700 (PDT)
Received: from ( by (unknown) with ESMTPS id 0311AC6o021557; Tue, 31 Mar 2020 21:10:12 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <>
To: "Salz, Rich" <>, Robert Moskowitz <>, Dan Brown <>, "" <>
Thread-Topic: [Cfrg] Encrypt in place guidance
Thread-Index: AQHWB4qF69TVJWSFL0ue+QmPsR+m6KhjZH8AgAASIAD//8S8gIAASL+AgAAf9ID//9FwAA==
Date: Wed, 1 Apr 2020 01:10:11 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3668533810_2150692251"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-03-31_07:2020-03-31, 2020-03-31 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002250000 definitions=main-2004010008
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 01:10:25 -0000

I will write the draft using Speck for 64 bit block.  That will get the draft out and open up for discussion. 

You’d probably write a draft requiring a 64-bit block cipher, proposing SPECK as one that fits the requirements, both block-size-wise and key-size-wise.

And if I had a 2 byte IV, I could get AES-CTR working to protect 2^16-1 messages.  More than enough for a mission.

In fact, if you have two bytes for crypto expansion – you could do better than CTR.

This will be up to ASTM and the regulators with us advising.

I don’t even know what ASTM is. ;-)

Simon and speck are controversial, and almost nobody believed that they weren’t deliberately crippled.  It hasn’t been proven.  But there were enough concerns that ISO rejected them.  See


Count me among those “almost”. 


Also, I wasn’t much impressed by those slides.


I mention all this because I am sure using Speck will be controversial, and you need to be sure that you are willing to take on that battle.


Depends on the customer. I’m sure FAA, DOT, or other US govt entity would have no problem with SPECK.