Hi Laurence, It is true that HPKE has been selected in favor over Ephemeral-Static (ES) DH already defined in COSE. The claimed benefits of using HPKE are described in Section 1 of RFC 9180:
Here is a copy: “ Currently, there are numerous competing and non-interoperable standards and variants for hybrid encryption, mostly variants on the Elliptic Curve Integrated Encryption Scheme (ECIES), including ANSI X9.63 (ECIES) [ANSI<https://datatracker.ietf.org/doc/html/rfc9180#ref-ANSI>], IEEE 1363a [IEEE1363<https://datatracker.ietf.org/doc/html/rfc9180#ref-IEEE1363>], ISO/IEC 18033-2 [ISO<https://datatracker.ietf.org/doc/html/rfc9180#ref-ISO>], and SECG SEC 1 [SECG<https://datatracker.ietf.org/doc/html/rfc9180#ref-SECG>]. See [MAEA10<https://datatracker.ietf.org/doc/html/rfc9180#ref-MAEA10>] for a thorough comparison. All these existing schemes have problems, e.g., because they rely on outdated primitives, lack proofs of indistinguishable (adaptive) chosen-ciphertext attack (IND-CCA2) security, or fail to provide test vectors. “ We had this discussion in the SUIT group in the early days of adoption the firmware encryption draft. Ephemeral-Static (ES) DH cannot be used out of the boxes – it has to be profiled for a specific use case, which we could have done in SUIT. To my knowledge nobody has implemented this functionality in any COSE library. COSE comes with a lot of different variants and I suspect that no library will implement all of them (or any of them). Regarding your implementation-specific questions: As you know, my approach was to add HPKE to Mbed TLS anticipating that it will be needed in the future as part of the Encrypted Client Hello draft anyway. The same is true for OpenSSL. Putting the HPKE code tentatively into t_cose is also fine for me. Ciao Hannes From: COSE <[email protected]> On Behalf Of Laurence Lundblade Sent: Sunday, October 30, 2022 9:57 PM To: cose <[email protected]> Cc: Richard Barnes <[email protected]>; [email protected]; [email protected]; [email protected] Subject: [COSE] ECDH vs HPKE for COSE public key encryption This is a bit of an implementation question, not so much a standards question, so apologies for taking up some bandwidth here up front and feel free to ignore. :-) I’m a bit confused about HPKE vs ECDH for encryption given that ECDH was just published yet we seem to be moving on from it to HPKE. HPKE has momentim HPKE seems to be where the momentum is so that should be implemented even though there will be challenges to arrive quickly at commercial implementation because the widely deployed versions of OpenSSL and MbedTLS don’t support it. Can’t say I’ve seen a good description of why HPKE is better. Would have been nice to put such in an appendix in RFC 9810. The main thing I can see is that you can do both encryption and authentication at once without the need for two layers of COSE. There’s probably some other attacks it mitigates too. ECDH is OK, right? I haven’t seen anyone say there is anything wrong with ECDH encryption in RFC 9053 (e.g. ECDH-ES + HKDF-256 ID -25.) Seems like it is OK to me. The move to HPKE is not because of a problem in ECDH. Some people might use ECDH instead of HPKE because it is a published standard now, better supported in libraries and maybe takes less object code. That is OK, right? It is probably a lower priority than HPKE, but a complete COSE implementation should probably support it. Sound right? It’s kind of a shame that ECDH in the just-published RFC 9053 is kind of obsolete already. Actually implementing HPKE My understanding is that HPKE is built on top of existing cryptographic algorithms and is NOT a new algorithm. It is built on Diffie-Helman and common hashes and symmetric ciphers. These make up the KDF, AEAD and such parts used by HPKE. I can see work is underway to add it to MBedTLS and OpenSSL, but it is not official supported yet and it will be years before it is in the OpenSSL and MbedTLS libraries bundled with OS’s, Linux distros that people use day-day. I want t_cose to work out of the box in those places. Probably what is best is for t_cose to support HPKE, but have it off by default so users get a good out-of-box experience. Then if they want HPKE they go get a more recent version of OpenSSL or MbedTLS and turn it on. Another option is to put HPKE right into t_cose and rely on the crypto libraries only for what they are known to broadly support. This is possible because no new crypto algs are required for HPKE. The good thing about this is that it can be enabled by default in t_cose. This is of course a lot more work. There are several downsides to this. When HPKE is in a shared OpenSSL or MBedTLS library, t_cose won’t take advantage of it, an issue on small devices. Another is that eventually this code will probably be thrown out in favor of what is in the popular crypto libraries. Another choice here is about curves and key formats. Flexibility would of course be nice, but that is work (particularly for a quality commercial library rather than a prototype for demonstration). Thanks for any feedback! Send it to me privately if you want to keep list traffic down. 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
