Hi Ilari,
Below. > 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). > > 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? > For X* stuff, > pkE is byte array, and SerializePublicKey() is trivial byte string > conversion. If I were to add compact NIST curves, SerializePublicKey() > would be nontrivial (substring extraction). > > >> The library-format key has to be converted to the byte string >> serialized format for SerializePublicKey() by the sender as that is >> needed as input to make the kem_context as part of implementing >> Encap(). > > Assuming pkE exists. > > >> It then has to be put on the wire to be sent and there are two choices: >> >> 1) COSE_Key — This requires some code to take the pkE in library >> format and output it COSE_Key format. This is work, but not that much >> because that function probably already exists in a COSE library. > > This breaks down when pkE does not exist. > > And even when pkE exists, uncompressed NIST curves are probably the > only ones where such conversion could be in any way useful. > > >> 2) Serialized byte string — No work here. Just output the same thing >> you fed into making the kem_context. > > And this byte string is actually guaranteed to exist. > > >> So serialized byte string wins on the sending side. What about the >> receiving side? >> >> 1) COSE_Key — You have to decode the COSE_Key format and turn it >> into the structure the crypto library uses. Probably you have a >> function to do it so not too much work, but it is something. > > In my COSE-HPKE implementation, this is actually substantial amount > of code (many hundreds of lines, but I could reuse code I had earlier > written for a different purpose). > > >> 2) Serialized byte string — This needs a deserialize function to >> take the bytes off the wire and turn it into the structure for the >> crypto library. Looks like it is needed nowhere else in RFC 9180, >> but you probably still have it around because it is not uncommon >> to do this and the format is standard for a key type. > > The kem_context is also present on decapsulation side, so one needs > the serialized byte string anyway (and in cases where pkE does not > exist, the KEM consumes the serialized byte string directly). Yes. I missed that. That leans the the receiving side to byte string too. > >> Looks like a draw on the receiving side. >> >> That kind of means serialized byte string wins overall from this >> particular line of thinking, but I don’t think it’s a large victory. > > Serialized byte string is also more forward compatible, because there > will be KEMs (Kyber, anyone?) that only have serialized byte string > form and no pkE at all. Thanks for your comments. LL > > > > -Ilari > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
