Below... > On Nov 1, 2022, at 2:21 AM, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > > On Mon, Oct 31, 2022 at 11:45:51AM -0700, Laurence Lundblade wrote: >>> On Oct 31, 2022, at 2:50 AM, Ilari Liusvaara <ilariliusva...@welho.com> >>> 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.
Makes sense. Agree that we want to think about this in the encoding of enc/COSE_HPKE_Sender, >>> 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. Right. On the sending side, pkE is only serialized put in the kem_context plus it is sent in the COSE message. On the receiver side it is put in the kem_context and is input to DH(). I’m pretty convinced that COSE_Key is not the right thing for the encoding of enc/COSE_HPKE_Sender. LL _______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose
