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
