IMO the objective is to define as few as we can. “what if… “ and “what about…” will lead us astray.
What I proposed has 3 for NIST fans and 4 for Bernstein fans. But, given that Mbed TLS (a major crypto lib) doesn’t support Edwards yet and 9053 doesn’t define any Edwards for encryption, makes me wonder if we should just do the 3 for NIST fans. LL > On Jul 5, 2023, at 10:57 AM, Ilari Liusvaara <[email protected]> wrote: > > On Wed, Jul 05, 2023 at 05:03:28PM +0000, lgl island-resort.com wrote: >> Here’s the 7 non-PQ COSE-HPKE algs I’d like to see in the COSE-HPKE draft: >> >> <snip list> >> > > Why does that list not have Chacha with P-384, X448 and P-521? Chacha > is nominally 256-level, not 128-level (well, there is 128-level version, > but nobody sane uses it). > > And another problem is that implementing all those 7 or 10 algorithms > already carries all the complexity of implementing all the 5x3x3 > combinations. > > And profiling down would also cut the combinations rapidly. It is > not difficult for this to end up with only one combination. > > >> It’s hard for me to see how this doesn’t cover most use cases. It’s >> pretty similar to the fan out in RFC 9053 (and note that the 9053 >> (and JOSE) fan out problem is pretty much the same as for HPKE). > > Well, it is not going to cover most usecases if HPKE adds compact > curves. That would add further 6 algs. > > And there could be other additions to HPKE that result in a lot > more algorithms. New AEAD would add like half dozen at least. > > >> I don’t know much about PQ algs, but it seems we’re doing it wrong if >> there’s more than five or ten. Seems much better to give non-expert >> people (like me) a few good choices they can’t go wrong with. > > There would currently be 2. Little idea about what happens in the > future. I would imagine there will be at least: > > - X25519+MLWE-KEM-768 > - P-384+MLWE-KEM-1024 > - X448+MLWE-KEM-1024 > - MLWE-KEM-1024 (CNSA2) > > Each would pair with either AES-256-GCM or Chacha20Poly1305, plus > maybe with whatever 256-bit AEADs get added in meantime (except maybe > the last with only AES-256-GCM). > > So that's 7, plus 3 for each new AEAD. > >> This is strong evidence for me that argument that the fan out will >> be 100+ is not very strong. > > I don't think anybody constructed a scenario where fan out would be 100. > Dozens, yes. And that gets quite annoying. > > >> I think you can also infer the bulk content encryption algorithm >> pretty easily. Make it AES-GCM of the same strength as AEAD. It’s >> pretty likely that most receivers will support most AES-GCM strengths. >> AES-GCM is PQ-safe so we’re not likely to change it out anytime soon. > > Nitpick: AES-256-GCM is PQ-safe (assuming one measures all inputs), as > is Chacha20Poly1305 (again asssuming all inputs are measured). > > And yes, currently all the HPKE AEADs have COSE equivalents (1 -> 1, > 2 -> 3, 3 -> 24). > > >> Note that all of these also specify the EC curve (unlike 9053 alg >> registrations) so you do NOT need additional info from the key to >> know the algorithm. The integer alg ID works better for COSE-HPKE >> than it does for the 9053 algs. > > I do not think that is a good thing. Having to fetch additional info > makes it more difficult to have bugs where keys get used with wrong > algorithms. There have been critical security bugs of that kind. > > And while inferring KEM from key is regarded as too complex, I think it > is technically possible. > > >> There’s a lot of flexibility if this doesn’t suit your use case. >> The COSE IANA alg registry ranges from the private use (less than >> -65536) that has no requirements to a full IETF standard. Note >> that the recent Chinese algorithm registration was content with >> specification required. > > I much rather have these _not_ have a specification, as that would > make it possible for there to be a special snowflakes, which would > cause a lot of pain for anyone implementing those. > > >> I would expect final agreed-upon HPKE PQ algorithms would come in >> as informational RFCs since HPKE and RFC 9053 are informational. >> For something as important as this, I would think the informational >> RFC process is about the right level. There should be a good public >> discussion and agreement. > > There is already Kyber I-D, that is intended to serve as precursor to > MLWE-KEM (or whatever it is). For asymmetric encryption, it essentially > says "Use HPKE". Intended status is informational RFC. > > It forms the basis of current post-quantum algorithm in HPKE. > > > > > -Ilari > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
