Re: [Cfrg] Encrypt in place guidance

Dan Brown <> Tue, 31 March 2020 20:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C244C3A02BE for <>; Tue, 31 Mar 2020 13:09:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e6on-0nU5EYg for <>; Tue, 31 Mar 2020 13:09:30 -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 A444D3A0143 for <>; Tue, 31 Mar 2020 13:09:28 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id 02VK48Hv127700; Tue, 31 Mar 2020 16:09:20 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : subject : date : message-id : references : in-reply-to : content-transfer-encoding : mime-version : content-type; s=corp19; bh=p25tNJeFKjpbZSxIYVT8PUCnUDLmlNlVkmZOT4tJHkU=; b=foboB9cqjOEzTulXQwToq4WAHmUx+jjUQjkFYC0CvbQXt8tSbwkxFylQNEHsVCRWw4+q z1rDHhrQt3Qw9UWseFUVfA755tm+6ibC+U/XJYzrisQ9eQtBOCwRwBcsDWuQO8lB/AcK Sg6RYbOli6jSlnKS3oM8aBc2eMA7maIXHxWlFi7ibLe1B1voDkzCHsKfLxcYu0oeV1m2 4ZoYRrMbiAokQl3KieVc9tQ2LKtnWBIKyWKZMRTtoNuDUdBUScGv3ee/CiDKOiQDjTBv bm9F/QqkfofOb8d4kWCxl2r9HdtoMNyqV9kYpb2v4Sxco4mYl9ZL8mHDZWuOZOeNzF6E cA==
Received: from ( []) by with ESMTP id 303v5yj6p0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 31 Mar 2020 16:09:20 -0400
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 31 Mar 2020 16:09:20 -0400
Received: from ([fe80::81ca:ad34:fc3:5ce8]) by ([fe80::81ca:ad34:fc3:5ce8%5]) with mapi id 15.01.1913.007; Tue, 31 Mar 2020 16:09:20 -0400
From: Dan Brown <>
To: Robert Moskowitz <>, "" <>
Thread-Topic: [Cfrg] Encrypt in place guidance
Thread-Index: AQHWB4p464714KoYhkKB52zCy51fjqhjFSHQ
Date: Tue, 31 Mar 2020 20:09:20 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Transfer-Encoding: base64
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
Content-Type: text/plain; charset="utf-8"
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 20:09:34 -0000

> -----Original Message-----
> From: Cfrg <> On Behalf Of Robert Moskowitz

> ... there are 8 bytes of
> sensitive ... Information that I want to encrypt.  I can get a shared
> secret via the PK mechanism in ECIES.

It sounds like "PK mechanism in ECIES" refers to basic ECDH and you want to know about symmetric-key encryption modes.

I will first talk about ECIES as a whole, then I will try to talk about modes, even though I know very little.


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.

Do both sides have static public keys?  Yes, I should read the DRIP documents ...

Anyway, ECIES is for when the recipient has a static PK, but the sender does not.

I think there are CFRG proposals or work items that extend ECIES to "Hybrid ..." and that add features like mutual authentication, etc. 

> The challenge is in encrypting, then decrypting these 8 bytes.
> There is no room for expansion in the message.  All we have are these 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 review, most versions of ECIES are hybrid, combining ECDH with a symmetric key stuff, but they generally drop the IV from the symmetric key mode, informally because ECDH (1) already serves the randomization role of IV, and (2) the symmetric key shared secret is only used once.  In other words, the usual IV (randomization) does not contribute to the message expansion of ECIES.

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.  

If you are not worried about these attacks, for some reason, such as have an alternative authentication mechanism, then you might consider with the truncation.

In ECIES as specified in SEC1, v.2.0, there are several choices of symmetric key encryption mode that operate like Vernam's one-time pad, and thus permit any number of bytes in the message: XOR ( = KDF(ECDH-secret) xor MSG), and also AES-CTR.  

The problem with Vernam's one-time pad is that without the MAC, then the adversary can XOR any delta into the cipher, to XOR the same delta into the plaintext, which is usually very insecure - unless you have some other security against this.  In ECIES (and many other systems, e.g. TLS), this is not a big problem, because of a MAC detects such tampering.

Since your message is only 8 bytes, you could instead use a 64-bit block cipher.  Here, if adversary can modifies the cipher, the plaintext should become garbled.  (Is this called implicit authentication? See * below)  The SEC1 version of ECIES allows the old TDES-CBC which could work if you are willing to use a very old cipher.  I do not recall whether there are other reputable 64-bit block ciphers.  Did Rijndael have such a variant? Do some of block cipher submitted to the NIST LWC allow 8-byte blocks?

I believe that there are yet other symmetric encryption modes that may help here. For example, the one I remember is Rivest's All-or-Nothing-Transform, or package transform (which is keyless but can be applied prior to modes like CTR), but I do not recall if it can work on 8 byte messages.  I would not be surprised if there were newer, or better, schemes.  

* If I had to name this goal, I would call it implicit authentication, but I would not be surprised if it has been properly formalized under some different name(s), e.g. in AONT research or block cipher research.

This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.