Inline: On Wed, Jul 5, 2023 at 12:59 PM 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) > > https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-kem-ids So far I only see X25519Kyber768Draft00 ... https://datatracker.ietf.org/doc/draft-westerbaan-cfrg-hpke-xyber768d00/02/ I have no idea how to represent keys for this using JWK or COSE Key, but the current draft seems compatible with either "alg" or "sender info / hkc" approach. > 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. > > It's especially possible in the case that you meant "key serialization" as in "JWK" or "COSE Key". It remains better to be explicit, in case some variant of P-256 DHKem emerges in the future... which could happen, as soon as the HPKE registry takes an update (notice that the draft for x25519 + kyber hybrid scheme has already been added to the registry). There have been critical security bugs related to not validating key to algorithm bindings. I'm not asserting this kind of thing applies to DHKems, or composit / hybrid kems.... I don't know if it does, or if feeding different encapsulated keys that don't match the kem id does anything useful, other than error... (regardless of twisting or hybrid stuff used). https://crypto.stackexchange.com/questions/43132/is-elliptic-curve-diffie-hellman-ecdh-still-secure-if-i-use-the-public-key-mor > > > 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 don't follow... Can you restate what you mean here? > > > 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. > > Where are you getting the term "MLWE-KEM" from? > > -Ilari > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
