On Fri, Jun 30, 2023 at 07:36:37PM +0000, lgl island-resort.com wrote: > > > > On Jun 30, 2023, at 12:15 PM, Ilari Liusvaara <[email protected]> > > wrote: > > > > On Fri, Jun 30, 2023 at 06:32:42PM +0000, lgl island-resort.com wrote: > >> Still trying to keep this to objective facts and not express any opinion > >> of mine. > >> > >> > >>> On Jun 30, 2023, at 10:53 AM, Ilari Liusvaara <[email protected]> > >>> wrote: > >>> > >>> Yes, one can also do ECDH as follows: > >>> > >>> * COSE_Encrypt bulk alg, e.g. AES-GCM > >>> * COSE_Recipient alg, e,g, A128KW > >>> * ECDH alg, e.g., ECDH-ES + SHA256 > >>> * Curve which comes from the key, e.g. NIST P-256 > >>> > >>> 3 algs, plus key subtype... > >> > >> Yes, that is described in Appendix B of RFC 9052, but ECDH-ES + A128KW > >> (-29) is a short-cut for it. There’s no point in using that particular > >> 3-layer structure. > > > > What about using a stronger key? All the integrated key wraps have > > SHA-256 KDF, which fails to reach nominal strength of stronger key > > exchange (even if I can not come up with an attack). > > Then you define a new aggregate algorithm ID or use the 3-layer > structure. That’s kind of a future speculative thing that you can > always bring up. I don’t think it changes the factual summary that > I’m trying to establish.
I regard the two-layer version as optimization on three-layer one. The size savings are rather sizeable (unlike with HPKE, where one could save a few bytes at best). (That's not true in JOSE: JOSE only has one or two layers. There integrated key wrap is mandatory for multi-recipient ECDH.) > >> I also would say that there is no kind of vector, tuple, array or map > >> in COSE or JOSE that is akin to “hkc”. There is nothing in to COSE or > >> JOSE that does the kind of disaggregation in “hkc”. COSE-HPKE had to > >> invent a new structure for it. > > > > COSE-HPKE did not need to invent "hkc". COSE-HPKE itself is defined by > > draft-ietf-cose-hpke which does not mention "hkc". The COSE-HPKE > > prototype code I have written does not support "hkc" at all. > > > > "hkc" only appears in the HPKE keys draft, where the only place where > > it is not optional is using it for subtyping hpke keys, which I think > > is a very bad idea (and mixes really badly with key fingerprints > > draft). > > > > And "hkc" is a new kind of capability, so it is not surprising that > > there is nothing like that currently in COSE nor JOSE. > > I was sloppy with my terminology. I should have said HPKE_sender_info. > > You got me on the technicallity here, but the factual summary I’m > after is still pretty much accurate if you substiute HPKE_sender_info > for “hkc”. Right? ECDH-ES in COSE has ephemeral key structure, which is an object, and can get somewhat hairy. Even the easiest cases, x25519 and x448 are comparable to HPKE SI in complexity. And EC2 is quite a bit more complex than that. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
