Re: [CFRG] Fixing the multi-shot API of HPKE

Hi Dan,

I don’t fully understand the problem you are alluding to.

>    "It is up to the application to ensure that encryptions and
>     decryptions are done in the proper sequence, so that encryption
>     and decryption nonces align.”

The HPKE stateful API guarantees that nonces cannot be misused, even if you use AES-GCM or Chacha-Poly. (Of course, you could also add a SIV ciphersuite.)
Furthermore, it guarantees that the stream of plaintext messages received by the decryptor is a prefix of the stream of plaintext messages sent by the encryptor.

In the current design, if two ciphertexts are decrypted out-of-order, both decryptions will fail.
So the problem alluded to in the text above is one of functionality; the application has to ensure (using some meta-data) that it is calling decrypt in the right order.
The application usually has to do something like this anyway to put the plaintext stream together.

I do not see how using AES-GCM-SIV is going to solve the above issue; yes, it would allow you to decrypt the plaintext in any order, but  the HPKE receiver would not be able to authenticate the correct order.
Am I missing something?

-Karthik

> On 13 Feb 2021, at 00:29, Dan Harkins <dharkins@lounge.org> wrote:
> 
> 
>   Hello again,
> 
>   The HPKE spec defines a single shot API for doing things like key-wrapping.
> You pass in the recipient's public key and some plaintext and get back a
> ciphertext. And that's it. One and done.
> 
>   There is also (what I'll call for lack of a better word) a multi-shot API.
> The idea here is that there's a single asymmetric crypto operation involving
> the recipient's pubic key to derive some state that resides in an opaque HPKE
> context and then multiple calls to encrypt distinct plaintexts. The state
> created includes a base nonce and a sequence number (initialized to zero).
> Each call to another encryption (decryption) increments the sequence number
> which is xor'd with the base nonce and passed to the AEAD algorithm. The HPKE
> APIs take a plaintext, and AAD, and produce a ciphertext, and vice versa.
> 
>   This multi-shot API is fine if your world is Guaranteed In Order Delivery
> of Packets but that's not the world we all live in. As such, it'll only
> be a matter of time before the sender and receiver are out of sync. The
> HPKE draft alludes to this problem this way:
> 
> 
> 
> Well that's a pain! One of the nice things about HPKE is that one doesn't
> need to worry about the nitty gritty of crypto state management anymore,
> it's all hidden. The API is nice and clean-- pass in a plaintext and get a
> ciphertext, pass in a ciphertext and get a plaintext.
> 
>   If there was an AEAD mode that did not require a nonce it could be used
> in HPKE's multi-shot API without need for the application to manage state
> and guarantee the parties stay in sync. Thankfully there is such an AEAD
> mode: AES-SIV (RFC 5297).
> 
>   When I brought this up earlier (and also on github) in the context of
> misuse resistance the response was, there's an export-only API that will
> give you a secret and you can go do any AEAD mode you feel like, including
> AES-SIV, issue closed.
> 
>   While that is technically true, it applies equally to the AEAD functions
> that HPKE already defines-- you can export a secret and do AES-GCM-256
> outside of HPKE while managing the necessary state yourself. Yet HPKE
> defines AEAD functions whose state resides in an opaque context so there
> is obviously value in having that functionality. I just want to get that
> value-- a clean, multi-shot API where I don't need to worry about managing
> state or guaranteeing people remain in sync-- for people who don't live
> in the world of Guaranteed In Order Delivery of Packets.
> 
>   So I'd like to ask the group whether they see value in having a nonce-less
> AEAD mode in HPKE. If so I'll be happy to resurrect the text changes I
> proposed and will be happy to contribute test vectors from my HPKE
> implementation which already does AES-SIV.
> 
>   One issue is that there are different security properties for a
> deterministic authenticated encryption scheme than for a probabilistic
> scheme. This is discussed in [1] and the security considerations would
> have to mention this. But I don't see that as a formidable problem.
> 
>   regards,
> 
>   Dan.
> 
> [1] Rogaway and Shrimpton, "Deterministic Authenticated Encryption",
>     EUROCRYPT, 2006
> 
> -- 
> "The object of life is not to be on the side of the majority, but to
> escape finding oneself in the ranks of the insane." -- Marcus Aurelius
> 
> _______________________________________________
> CFRG mailing list
> CFRG@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg