Re: [Cfrg] Encrypt in place guidance

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

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" <[e-mail] on behalf of [e-mail]> 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 
    content.
 
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
[e-mail]
https://www.irtf.org/mailman/listinfo/cfrg