Re: [Cfrg] Encrypt in place guidance

"Blumenthal, Uri - 0553 - MITLL" <> Tue, 31 March 2020 21:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CD8123A093F for <>; Tue, 31 Mar 2020 14:42:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.005
X-Spam-Status: No, score=0.005 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p78YnV_KikZk for <>; Tue, 31 Mar 2020 14:42:13 -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 B1CAA3A0924 for <>; Tue, 31 Mar 2020 14:42:13 -0700 (PDT)
Received: from ( by (unknown) with ESMTPS id 02VLg74S028521; Tue, 31 Mar 2020 17:42:07 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <>
To: Robert Moskowitz <>, Dan Brown <>, "" <>
Thread-Topic: [Cfrg] Encrypt in place guidance
Thread-Index: AQHWB4qF69TVJWSFL0ue+QmPsR+m6KhjZH8AgAASIAD//8S8gA==
Date: Tue, 31 Mar 2020 21:42:06 +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_3668521325_130783688"
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-2003310176
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 21:42:19 -0000

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