On Mon, Oct 31, 2022 at 11:45:51AM -0700, Laurence Lundblade wrote: > > On Oct 31, 2022, at 2:50 AM, Ilari Liusvaara <[email protected]> > > wrote: > > > > On Sun, Oct 30, 2022 at 11:29:46PM -0700, Laurence Lundblade wrote: > >> Jumping into this… hopefully I’m up to speed enough to not say > >> something dumb…. > >> > >> The pkE starts out on the sender side represented in the internal > >> data structure that the crypto library likes. It has to be because > >> it is input the the DH function. This is neither a COSE_Key nor the > >> byte string serialized format that is the output of SerializePublicKey(). > >> It might be an MbedTLS key handle or whatever OpenSSL uses. > > > > HPKE does _not_ guarantee that pkE even exists. Note that it is defined > > in section 4.1, which concerns how to turn Diffie-Hellman function into > > a KEM. > > The only KEM defined in 9180 is DHKEM. For an RFC 9180 implementation > you do have to have a pkE in some form, right? > > I could see how a KEM defined outside of 9180 might have something > else instead of a pkE (note that 9180 is my main source of info about > HPKE so far).
It seems to me that: - RFC 9180 was designed to use generic KEM with unified API. - DHKEM was defined in order to construct KEM from ECDH. - There are no ready-to-use dedicated KEMs with benefits over using ECDH as KEM, so RFC 9180 did not define any. - However, in the future there are expected to be KEMs not based on DHKEM. - Those are to be usable without any API changes. - E.g., Kyber1024 or Kyber/ECDH hybrids. > > When pkE exists, it starts as public Diffie-Hellman key, generated for > > each encapsulation. It SHOULD be generated using the method described > > in HPKE specification, but using any non-broken keygen works (other > > than some test vectors). > > > > In my HPKE implementation, for NIST curves, pkE is actually byte string > > in output format, and SerializePublicKey() is identity. > > That’s because the input to your DH algorithm API/library can work on a > serialized pkE, right? Actually, it is because DHKEM does not do anything with pkE except to serialize it. It is the private part that is used in DH operation. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
