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. 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. 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). > 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. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
