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

[Dan Harkins <[e-mail]>]

   Hi Karthik,

On 2/13/21 3:10 AM, Karthikeyan Bhargavan wrote:
> 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.

   It's not an issue of misuse, it's an issue of the sender and
receiver contexts getting out of sync through entirely normal
network behavior and becoming unusable.

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

   AES-GCM-SIV requires a nonce (although reuse is not tragic in the
way it is for GCM) so there still needs to be some guarantee that the
nonce plugged into the receiver is the same as the one plugged into
the sender when the ciphertext was created. This is a proposal for
AES-SIV (defined by Rogaway and Shrimpton) which can do deterministic
AEAD (it can also be passed a nonce to be more like a traditional AEAD
mode, albeit slower, but that's not what I'm proposing here). No nonce
so nothing to worry about getting out of order.

   Regarding the correct order, for a streaming application yes that's
true. The correct order would still be needed and whatever technique
you use to ensure that decrypted packets get ordered correctly could
probably be used to ensure that packets are decrypted in order. But
there are other interesting applications of HPKE that are not streaming
and each message can be thought of as self-contained. Imagine a sensor
obtaining some environmental data and then sending it off to a server
for correlation and processing every <time slice>. It would be quite
easy for such a sensor and server to get their HPKE contexts out of
sync and that would be a real PITA.

   regards,

   Dan.

> -Karthik
>
>
>
>> On 13 Feb 2021, at 00:29, Dan Harkins <[e-mail]> 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
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/cfrg

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