Re: [Cfrg] Encrypt in place guidance

"Blumenthal, Uri - 0553 - MITLL" <> Tue, 31 March 2020 22:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B2F693A0C5F for <>; Tue, 31 Mar 2020 15:56:34 -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 yU2njgTbQRlr for <>; Tue, 31 Mar 2020 15:56:33 -0700 (PDT)
Received: from (LLMX2.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 D5F253A0C5A for <>; Tue, 31 Mar 2020 15:56:32 -0700 (PDT)
Received: from ( by (unknown) with ESMTPS id 02VMuPOn026536; Tue, 31 Mar 2020 18:56:25 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <>
To: Robert Moskowitz <>, Dan Brown <>, "" <>
Thread-Topic: [Cfrg] Encrypt in place guidance
Thread-Index: AQHWB4qF69TVJWSFL0ue+QmPsR+m6KhjZH8AgAASIAD//8S8gIAASL+A///MA4A=
Date: Tue, 31 Mar 2020 22:56:24 +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_3668525783_227469459"
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-2003310187
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: Tue, 31 Mar 2020 22:56:35 -0000

thank you for this.

My pleasure.

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

This indeed makes sense to me.

I will use ISO 29167-22 for the reference for starters.

And per Dan's comments about ECIES, I should call this a hybrid ECIES.

It doesn’t matter what you call it. What matters is that you aren’t likely to be able to use it, due to your message size constraints..

And I am open to any other considerations for dealing with this shoehorn problem.

OK, will say more later.



On 3/31/20 5:42 PM, Blumenthal, Uri - 0553 - MITLL wrote:
On 3/31/20, 17:15, "Cfrg on behalf of Robert Moskowitz" < on behalf of> wrote:
    > ECIES = Elliptic Curve Integrated Encryption Scheme, a public-key encryption scheme, 
    > i.e. with a functionality similar to RSA-OAEP, and various other PKEs.
    > Again, it is not clear to me that you are wholly using ECIES. Indeed, it is not exactly what your problem is.
    > Anyway, ECIES is for when the recipient has a static PK, but the sender does not.
    My situation.  I am even recommending that static PK not be static for 
    too long.  PCS protection thoughts.
No, it is not your case - because (as Dan explained) ECIES increases message size by auth tag, possibly encryption IV, and ephemeral public key of the sender. It's normal use case is messages/files larger than 8 bytes. ;-)
    > Well, ECIES has built-in message expansion, not only from the ECDH part
    > (which you mentioned) but also because it provides integrity, internally via a MAC tag.
    > To avoid message expansion from the MAC, you could truncate the part of the ECIES
    > ciphertext that corresponds to the MAC, but doing so would *modifies* the design
    > of ECIES and thereby introduces potentially serious attack such as chosen ciphertext attacks.
I would not do that without a security analysis.
    > Since your message is only 8 bytes, you could instead use a 64-bit block cipher. 
That is true - a very good idea. I'd be thinking Simon/Speck. Not DES in any case, and not FEAL ;)
    I can start a counter, but which counter value to use for a specific 
    received message.  Since these bytes are value only, there is no way to 
    check that decrypt worked by seeing a couple bytes having the expected 
I don't think you can rely on shared counter. Your IV/Nonce would have to have explicitly transmitted part.
    I have just recieved confirmation that the plaintext is going up, most 
    likely to 12 bytes in the next iteration of the standard because the FAA 
    and EASA want Altitude along with Long and Lat.
It doesn't matter all that much how big your plaintext is (within the reasonable constraint of your application - 8, 12, 24, who cares - it's not 2K). It matters a lot how many bytes you can dedicate/allocate for extra crypto (IV, auth tag, etc).

Cfrg mailing list