Hi Laurence, You are right that the two options are not substantially different from the implementation point of view. Somewhere in the libraries you have to make the conversations.
Here are the two approaches we have been looking into right now: * https://datatracker.ietf.org/doc/html/draft-ietf-cose-hpke-02 (COSE Key Version) * https://github.com/cose-wg/HPKE/pull/9 (revised proposal; not complete yet) The main arguments (as far as I can see it) is about the integration of PQC algorithms in the future. Ciao Hannes From: COSE <[email protected]> On Behalf Of Laurence Lundblade Sent: Monday, October 31, 2022 7:30 AM To: cose <[email protected]> Subject: [COSE] Format of pkE/enc in HPKE 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. 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(). 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. 2) Serialized byte string — No work here. Just output the same thing you fed into making the kem_context. 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. 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. 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. LL IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
