Re: [Cfrg] Encrypt in place guidance

[Robert Moskowitz <[e-mail]>]

On 3/31/20 4:09 PM, Dan Brown wrote:
>> -----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 ...

This will be a new, exciting (ahem) document.  You have to spend time 
looking at the work done todate on Unmanned Aircraft Tracking by people 
that think they need cybersecurity but don't know how that impacts their 
designs which are already set in regulations...

So you may not want to pollute your mind.  :)

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

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

Here the direct parties:  USS and Operator are already authenticated.  
The 3rd party, the UA is not and will be blasting out private 
information about the Operator that really should be protected (Hey, the 
guy that is controlling me is a block thata way!)  But the Operator 
controls what the UA reveals about the operator, so there is hope if I 
can encrypt the content.  (I try not to confuse about all the different 
channels for communication here)

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

Dan,

thank you for all this information.

This is not a one-time encryption of a string with a key derived from 2 
PK.  If the operator is mobile, the data is constantly changing and 
messages WILL be lost so both CTR and CFB are in trouble so to speak.

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

ECB would actually be better, as the key is only used for a 'few' blocks 
(4 hr flight, messages every 10s = 1,440 encrypted blocks).

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.

Of course that means support 8 bytes in ver 1.0 and 12 bytes in ver 1.1.


I need to burn more brain cells on this one.

3DES-ECB on 8 bytes, but what on 12?  I hope they don't decide on 5 
bytes for alt...


It always seems so simple when you first start out, but then when you 
line up all the real requirements, it gets hard.