Re: [Cfrg] Encrypt in place guidance

Uri,

thank you for this.

I will write the draft using Speck for 64 bit block.  That will get the 
draft out and open up for discussion.

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.

Thanks all that have helped on this.

And I am open to any other considerations for dealing with this shoehorn 
problem.

On 3/31/20 5:42 PM, Blumenthal, Uri - 0553 - MITLL wrote:
> On 3/31/20, 17:15, "Cfrg on behalf of Robert Moskowitz" <cfrg-bounces@irtf.org on behalf of rgm-sec@htt-consult.com> 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
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg