[CFRG] Fixing the multi-shot API of HPKE

[Dan Harkins <[e-mail]>]

   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:

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

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