3 ms·

> Currently, there are numerous competing and non-interoperable standards and variants for hybrid encryption … Sure, let’s create another one and expect it bei

> Currently, there are numerous competing and non-interoperable standards and variants for hybrid encryption … Sure, let’s create another one and expect it being used by all othe those who use existing stabdards. It would be great to understand the exact specific motive which drives it instead of converging on an existing standard.

eqvinox 2y ago
Yes, both of these things are kinda what the IETF (and by extension IRTF) does…?
ramchip 2y ago
https://mailarchive.ietf.org/arch/msg/cfrg/3SXM0I9jVs5i38SyahhMF1Q4fBc/ https://mailarchive.ietf.org/arch/msg/cfrg/3SXM0I9jVs5i38Sya... The idea here is to write a clean, easy-to-use spec for hybrid public-key encryption. (We're using the name "ECIES", but as the draft notes, the idea is clearly more general.) This primitive has come up in IETF work on MLS and ESNI [0][1], and in several other protocols, e.g., through the NaCl "box" API [2]. The hope here is to have a single spec that unifies these ideas and can be the target of formal verification. I admit that there's a little bit of XKCD#927 here [3], but I think there's good work to do here in terms of addressing some more modern use cases (e.g., streaming / multiple encryptions from a single DH) and possibly enabling better post-quantum support by generalizing to KEM instead of DH.
tptacek 2y ago
This is a CFRG document. CFRG is the cryptographic research community working group within the IRTF. The IRTF does enabling building-block standards work for future standards; they don't publish standards that you, a generalist engineer, are expected to use. The idea here is simply that the IETF is going to need to do asymmetrically encrypted message exchanges in future standards, and CFRG's job is to make sure there's a well-vetted, carefully designed construction they can pull off the shelf to do that. There is not, in 2024, an existing reference point for this construction that IETF WGs could use, if only because of PQC. You have to wait for an IETF WG to actually use HPKE before you get to complain about the standards proliferation; it'll be that "customer" (of CFRG) standard that will need to be judged on whether further standardization is a good idea. It doesn't make much sense to dunk on the actual cryptographers at IRTF, who are more or less just explaining to the IETF WGs how to do cryptography properly. (I say this as someone who considers themself an opponent of all cryptographic standards bodies).
- dadrian 2y ago
  It's not clear to me that this is something that should be genericized, nor that providing a generic HPKE to IETF WGs and then tweaking it as needed is any less work than just composing the correct primitives for each WG use case. As it stands already, IETF WGs are relying on properties that, e.g. DH-KEM only provided by accident. In practice, HPKE is not something you can just use off the shelf, and I personally wouldn't try to write an IRTF standard like it is.

eqvinox 2y ago

Yes, both of these things are kinda what the IETF (and by extension IRTF) does…?

ramchip 2y ago

https://mailarchive.ietf.org/arch/msg/cfrg/3SXM0I9jVs5i38SyahhMF1Q4fBc/ https://mailarchive.ietf.org/arch/msg/cfrg/3SXM0I9jVs5i38Sya... The idea here is to write a clean, easy-to-use spec for hybrid public-key encryption. (We're using the name "ECIES", but as the draft notes, the idea is clearly more general.) This primitive has come up in IETF work on MLS and ESNI [0][1], and in several other protocols, e.g., through the NaCl "box" API [2]. The hope here is to have a single spec that unifies these ideas and can be the target of formal verification. I admit that there's a little bit of XKCD#927 here [3], but I think there's good work to do here in terms of addressing some more modern use cases (e.g., streaming / multiple encryptions from a single DH) and possibly enabling better post-quantum support by generalizing to KEM instead of DH.

tptacek 2y ago

This is a CFRG document. CFRG is the cryptographic research community working group within the IRTF. The IRTF does enabling building-block standards work for future standards; they don't publish standards that you, a generalist engineer, are expected to use. The idea here is simply that the IETF is going to need to do asymmetrically encrypted message exchanges in future standards, and CFRG's job is to make sure there's a well-vetted, carefully designed construction they can pull off the shelf to do that. There is not, in 2024, an existing reference point for this construction that IETF WGs could use, if only because of PQC. You have to wait for an IETF WG to actually use HPKE before you get to complain about the standards proliferation; it'll be that "customer" (of CFRG) standard that will need to be judged on whether further standardization is a good idea. It doesn't make much sense to dunk on the actual cryptographers at IRTF, who are more or less just explaining to the IETF WGs how to do cryptography properly. (I say this as someone who considers themself an opponent of all cryptographic standards bodies).

dadrian 2y ago
It's not clear to me that this is something that should be genericized, nor that providing a generic HPKE to IETF WGs and then tweaking it as needed is any less work than just composing the correct primitives for each WG use case. As it stands already, IETF WGs are relying on properties that, e.g. DH-KEM only provided by accident. In practice, HPKE is not something you can just use off the shelf, and I personally wouldn't try to write an IRTF standard like it is.