Re: [CFRG] [Technical Errata Reported] RFC9180 (7790)

[Neil Madden <[e-mail]>]

I feel that people are getting a bit side-tracked here. Neither the HPKE RFC nor the erratum report mention either JOSE or multiple recipients. I bought that up in reply to another message as an example of *an* issue that can occur due to lack of Insider-Auth security. The issue under discussion is whether the RFC 9180 fairly characterises the security analysis that it cites. The RFC says HPKE "fulfills these notions", whereas the paper it cites says the following (section 5.1):

"[...] Insider-Auth security in infeasible both for the APKE construction used in HPKE (see section 5.4), and the instantiation of AKEM proposed in HPKE (see end of section 6.1)."

And the following (section 5.4):

"For any AKEM, KS, and AEAD, the construction APKE[AKEM, KS, AEAD given in Listing 8 is not (n,q_e,q_d)-Insider-Auth secure. The inherent reason for this construction to be vulnerable against this attack is that the KEM ciphertext does not depend on the message. Thus, the KEM ciphertext can be reused and the DEM ciphertext can be exchanged by the encryption of any other message."

And section 6.1:

"[T]he DH-AKEM construction does not even achieve KCI security, a relaxation of Insider-Auth security[...]".

Thus, HPKE does *not* fulfil this notion of security and shouldn't imply that it does. That's it. That's the erratum. Send tweet.

-- Neil

> On 8 Apr 2024, at 19:11, Thad Thompson <[e-mail]> wrote:
> 
> Hey Neil,
> For what it's worth, as an Internet rando (non-cryptographer) implementing a scheme very similar to the one you're suggesting, my understanding from the RFC was that the target security property of KEM authentication rather explicitly only covers two parties:
> 
> > 5.1.3.  Authentication Using an Asymmetric Key
> >
> >   This variant extends the base mechanism by allowing the recipient to
> >   authenticate that the sender possessed a given KEM private key.  This
> >   is because AuthDecap(enc, skR, pkS) produces the correct KEM shared
> >   secret only if the encapsulated value enc was produced by
> >   AuthEncap(pkR, skS), where skS is the private key corresponding to
> >   pkS.  In other words, at most two entities (precisely two, in the
> >   case of DHKEM) could have produced this secret, so if the recipient
> >   is at most one, then the sender is the other with overwhelming
> >   probability.
> 
> Am I not understanding that correctly? I assume that limitation is part of the reason MLS relies on asymmetric signatures for authentication.
> 
> However, I would agree that the limitations of KEM based authentication feel maybe a bit out of place. Besides the fact that it only proves authentication in a two-participant system, it also becomes fiddly when moving to PQ KEMs. You either wind up with a halfway 'quantum safe key exchange but NOT quantum safe authentication' scheme like Signal's PQXDH, or it is dropped entirely, like in X-Wing. In any case, it seems like the authenticated KEM modes in HPKE take up a large space in the standard for what turns out to be rather limited functionality with caveats. I wonder if HPKE 2.0 would include such modes at all?
> 
> Cheers!
> - Thad