On Tue, Jul 9, 2024 at 10:58 AM Ilari Liusvaara <[email protected]> wrote:
> On Mon, Jul 08, 2024 at 09:05:58PM -0500, Orie Steele wrote: > > > > I'd love to learn the history of why ECDH-ES+A128KW is not > ECDH-ES+A128GCM > > ... but this ship has sailed, "ECDH-ES+A128KW" is mixed into the concat > kdf. > > ... the logical equivalent of that happens internally to HPKE, here: > > https://datatracker.ietf.org/doc/html/rfc9180#section-5.1-9 > > That is because AES-GCM requires a nonce and breaks badly if it is reused, > making it not great for key wrapping. Whereas AES-KW does not even need an > IV. > > JOSE does have the (rather broken) A*GCMKW algorithms, which perform Key > Wrapping using AES-GCM. > > The easiest way to get around the GCM nonce issue is to generate both key > and nonce together using KDF. > > > > The difference is that HPKE doesn't give a different algorithm name for > > A128KW and A128GCM... it treats them as both 0x0001 see > > https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-aead-ids > > HPKE never uses AES-KW. HPKE always uses AES in GCM mode. It gets around > the problem with nonce as said above. > > > HPKE doesn't know if it's encrypting a content encryption key or not... > > If you want to ensure that in higher order systems this distinction is > > authenticated, you need to use setup info or aead aad, see > > > https://datatracker.ietf.org/doc/html/rfc9180#name-auxiliary-authenticated-app > > > > This leads us back to the current proposal... > > > > - alg: HPKE-P256-SHA256-A128GCM ... enc: A128GCM // in separate headers > -> > > key encryption > > - alg: HPKE-P256-SHA256-A128GCM, enc: A128GCM // in the same header > -> > > integrated encryption > > This does not work because JWE unions recipient headers. > Which part would you change? > > > hpke-info = empty > > hpke-aad = protected (.aad) // how the distinction is authenticated > > ... And this does the wrong thing with Key Encryption (and causes > implementation problems). > What would you set HPKE AAD to be for Key Encryption? What would you set HPKE AAD to be for Integrated Encryption? > > > An alternative proposal: > > > > - alg: HPKE-P256-SHA256+A128KW ... enc: A128GCM // -> key encryption > > - alg: HPKE-P256-SHA256, enc: A128GCM // -> integrated > encryption > > > > This doubles the registrations and does not appear to do anything useful. > > ... unless these different alg values are used as hpke-info to force > > different key schedules: > > https://datatracker.ietf.org/doc/html/rfc9180#section-5.1-10 > > ... similar to how ECDH-ES and ECDH-ES+A128KW work in concat kdf today. > > This is also prohibited by draft-ietf-jose-fully-specified-algorithms > (It requires what alg to be independent of enc). > Drafts can only be cited as work in progress... it's also in conflict with RFC7518: See also: https://datatracker.ietf.org/doc/html/rfc7518#section-4.6.2 For "ECDH-ES", this is the length of the key used by the "enc" algorithm. For "ECDH-ES+A128KW", "ECDH-ES+A192KW", and "ECDH-ES+A256KW", this is 128, 192, and 256, respectively. So as you can see... "alg" and "enc" are already dependent, as specified in RFC7518. We could write: For "HPKE-P256-SHA256-A128GCM", the length of the content encryption key is the length of a key used by the "enc" algorithm, note that "HPKE-P256-SHA256-A128GCM" can be used to encrypt an A256GCM key. ... or someone can propose alternative text that explains how HPKE "alg" and "enc" values are related. > > > > -Ilari > > _______________________________________________ > jose mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
