> > Can you expand the CDDL / example above, and provide a concrete example of > using Enc_structure with both the "alg" and "hkc" approaches for comparison?
The protected headers for the "alg" approach and the "hkc"(sender_info) approach would be as follows. <"alg" approach> alg: "HPKEv1-Base-DHKEM(P-256, HKDF-SHA256)+HKDF-SHA256+AES-128-GCM", encapsulated_key: "xxxxxxx..." // alg approach also needs to send an encapsulated key. <"hkc"(sender_info) approach> alg: "HPKEv1-Base", hpke_sender_info: [0x0010, 0x0001, 0x0001, "xxxxxxx..."], // kem, kdf, aead and encapsulated_key As Ilari pointed out, there is no difference. The information applied to AEAD is the same. As mentioned in the previous email, this HPKE information in the protected header is already bound to the transaction in the internal HPKE key derivation process (KEM+KDF). Regardless of which approach is chosen, it actually results in redundant bindings, so But I am interested in if there are cases where we don't want this binding, > cases where nothing regarding "alg" or "hkc" is in the protected header, > are those cases worth supporting, or are they dangerous? They are not dangerous. Best, Daisuke 2023年7月5日(水) 23:19 Ilari Liusvaara <[email protected]>: > On Wed, Jul 05, 2023 at 08:33:41AM -0500, Orie Steele wrote: > > Inline > > > > On Sun, Jul 2, 2023 at 10:49 PM AJITOMI Daisuke <[email protected]> > wrote: > > > > I agree regarding "pure HPKE" that it should not matter, but for COSE, I > am > > not sure if there is really no preference, or if there are "better" or > > "worse" ways to do it. > > > > Can you expand the CDDL / example above, and provide a concrete example > of > > using Enc_structure with both the "alg" and "hkc" approaches for > comparison? > > > > The thing I am trying to focus on here is: > > > > What information from the protected header is applied to aead? > > > > Regardless of *how* that information is represented in the protected > header. > > There is no difference. > > - Tampering with algorithm information causes key mismatch. > - Tampering with other protected fields causes ad mismatch. > > Where there would be difference is if info was used for header > protection. Then either tampering algorithm information or protected > fields would cause key mismatch. > > This is forced by internal structure of HPKE. > > > > Does knowing that AES-128-gcm is "used" in the aead process change > opinions > > on if it should or should not be in the header? > > > > What about the other components of "alg" ? > > > > For example, imagine a header that used the "alg": "DHKEM(P-256, > > HKDF-SHA256) + HKDF-SHA256 + AES-128-GCM" > > > > My understanding is that these would all be bound to the aead encryption > > process. > > Say an attacker tampers that to P-256/SHA-256/Chacha20. The result is > key mismatch regardless of if HPKE "ciphersuite" info is embedded in > alg, or disaggregated in HPKE sender info. > > > > Imagine a different "alg" values: "DHKEM(P-256, HKDF-SHA256) + > HKDF-SHA256" > > ... does it matter that "AES-128-GCM" is left off? > > Only that it must be communicated somewhere else. > > > > As you said, let's ignore the "alg" part of the keys for now, focusing > only > > on "alg" in a protected header... > > > > To me, it seems odd that the protected header might not be "in agreement" > > with the aead process used, for example: > > > > I might learn that a recipient supports everything possible. > > > > I might encrypt to them using "DHKEM(P-256, HKDF-SHA256) + HKDF-SHA256 + > > AES-128-GCM", but the envelope header only says "DHKEM(P-256, > HKDF-SHA256) > > + HKDF-SHA256" > > > > How does the recipient know which aead was used, and does the *sender* > need > > to communicate that information in some tamper evident way? > > > > It seems like the answer should be yes, regardless of *how* that > > information is represented. > > The answer is that it needs to be communicated somehow, but otherwise > no. > > > > But I am interested in if there are cases where we don't want this > binding, > > cases where nothing regarding "alg" or "hkc" is in the protected header, > > are those cases worth supporting, or are they dangerous? > > Those are not dangerous, since HPKE cryptographically prevents such > binding anyway. > > > > > -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
