> On Oct 31, 2022, at 1:51 AM, Hannes Tschofenig <[email protected]> > wrote: > > 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. > “
Yeah, I read that like three times. Also this paper by C. Woo <https://blog.cloudflare.com/hybrid-public-key-encryption/>d. Didn’t really find them particularly informative. - They don’t mention ECDH defined in RFC 9053 - Lack of test vectors is not a reason to invent new stuff - They don’t mention the combined encryption and authentication - Why are the primitives outdated and why does it matter? - Are the proofs impossible or has no one done them? I’m not questioning whether HPKE is the way to go or not, just saying that coming in fresh to this as I am, these explanations weren’t that compelling and there probably could be better ones that would have avoided me writing this message. > 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). So there’s no EC-based implementation-ready interoperable encryption specification for COSE today even after year of work and two rounds of published RFCs (then why I was beat up for EAT profiles?). It is what it is. I’m happy to pitch in and make HPKE work in t_cose. :-) > > 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. Good to understand. Thx. LL > > Ciao > Hannes > > From: COSE <[email protected] <mailto:[email protected]>> On Behalf > Of Laurence Lundblade > Sent: Sunday, October 30, 2022 9:57 PM > To: cose <[email protected] <mailto:[email protected]>> > Cc: Richard Barnes <[email protected] <mailto:[email protected]>>; > [email protected] <mailto:[email protected]>; > [email protected] <mailto:[email protected]>; [email protected] > <mailto:[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
