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