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

[Richard Barnes <[e-mail]>]

Hi Dan,

HPKE is not intended to be a full network protocol; it is supposed to be
embedded in an application that assures properties such as those you
mention.  Section 8.6, "External Requirements / Non-Goals" [1] has some
text on this.  If you think we can be clearer in these disclaimers,
suggested text / PRs would be welcome.

--Richard

[1] https://tools.ietf.org/html/draft-irtf-cfrg-hpke-07#section-8.6


On Sat, Feb 13, 2021 at 7:29 AM Dan Harkins <[e-mail]> wrote:

>
>    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
>
> _______________________________________________
> CFRG mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
>