Re: [Cfrg] Encrypt in place guidance

[Dan Brown <[e-mail]>]

> -----Original Message-----
> From: Cfrg <[e-mail]> 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.