Hi Laurence,
thanks for the feedback. A few remarks below:
The ECDH key agreement in 6.3 are very close to HPKE and the ones in
6.4 are even closer. It looks to me like Jim did implement these. He
certainly did implement AEADs.
There are examples / test data of this here:
https://github.com/cose-wg/Examples/tree/master/ecdh-wrap-examples. I
didn’t check them to confirm how Enc_Recipient works, but we can.
Section 6.3 of RFC 9053 specifies a content key distribution with direct
key agreement. The DH-derived key is fed into a key derivation function
and the resulting key is then used as a content encryption key. Hence,
there is no AES computation as part of the recipient layer.
Section 6.4 of RFC 9053 goes one step further and uses a content key
distribution with key agreement plus key wrap. Here the DH-derived key
is fed into the key derivation function and then serves as a KEK to
encrypt a CEK with AES-KW. AES-KW is not an AEAD cipher and has no
public parameters that vary on a per-invocation basis. COSE does not
specify other key wrap algorithms other than AES-KW.
FWIW an example of the mechanism described in Section 6.4 is shown in
Appendix B of RFC 9052.
Jim implemented AEADs but not in the way we use it.
Instead, Section 5.3 of RFC 9052 talks about
authenticated data structure in context of the AEAD cipher used at the
lowest level -- the COSE_Encrypt and COSE_Encrypt0 structure rather than
the recipient structures.
The Enc_structure becomes the additional authenticated data for the
AEAD. I also took a (very) brief look at Jim's code and I couldn't find
the place where he puts the Enc_structure into the AAD of the recipient
layer.
Look for COSE_Encrypt_Build_AAD() called in COSE_Recipient_encrypt().
The Externally Supplied Data comes in through a someone global context.
I’m about 80% convinced from looking at Jim’s code.
I looked at this function and to me it seems he is using it for content
encryption.
What information is passed to the HPKE information at the recipient
layer should be kept flexible, as it is currently the case in the
COSE-HPKE draft (with the info structure) and as it is also done in RFC
9053 since the content is application dependent. Here is what Section
5.2 of RFC 9053 says about the information structure:
"
The context information structure is used to ensure that the derived
keying material is "bound" to the context of the transaction.
"
Specifications using COSE-HPKE know about the context and will have to
populate the fields accordingly.
In COSE the extra info to be bound into the integrity protection goes
in protected header parameters or in Externally Supplied Data — the
AAD input to COSE at the top level. To allow input directly into the
key agreement algorithm would be disruptive to the COSE ecosystem and
implementations because not all key agreement algorithms may support
that. It wouldn’t really even be compliant with the COSE standard.
I will admit that it does seem like the use of Enc_Recipient is a
little degenerate and could be viewed as unnecessary.
Enc_structure = [
context : "Encrypt" / "Encrypt0" / "Enc_Recipient" /
"Mac_Recipient" / "Rec_Recipient",
protected : empty_or_serialized_map,
external_aad : bstr
]
The external_aad is already protected at level 0, so it’s presence
here is a little redundant. That leaves only the protected headers and
the context string. One might think that this could have been simpler
by just giving the protected headers to the AEAD. I suspect it is so
for consistency and because the binding to “Enc_Recipient” helps with
some attacks.
Personally, I don’t see HPKE as that big an increment over what is
there in the key agreement algorithms that COSE already defined. The
problem with integrating HPKE with COSE is not that COSE didn’t
anticipate stuff like this, it’s more that both COSE and HPKE see
themselves as the dog, not the tail.
The more I look, the more I think Jim did a huge amount of work and
was way ahead of the rest of us — may he rest in peace.
LL
As you explained in another email thread, the COSE specification is a
toolbox. It gives applications using those cryptographic primitive ways
to include extra information. That approach has strengths and
weaknesses. The strength is the flexibility and the weakness is that a
developer needs to think about the parameters that go into those primitives.
It is fine if not everything was already envisioned at the time the
initial COSE RFC was published. There is a lot of other work ongoing
that probably wasn't envisioned either, for example the PQC algorithms
or the privacy mechanisms that are currently being discussed.
With the COSE mechanisms today, ignoring HPKE for a moment, a developer
has to provide the following information for an ephemeral-static
Diffie-Hellman content key distribution using AES-GCM as content
encryption algorithm:
* Enc_structure for the content encryption layer utilizing AES-GCM,
which includes the external AAD.
* Info structure for the key derivation function used at the recipient
layer to generate the KEK, which is then used to encrypt the CEK via AES-KW.
With HPKE we still have to provide the info structure (which goes into
SealBase). Since we are not using AES-KW but an AEAD cipher via HPKE we
need to provide an additional AAD. We can put the Enc_structure there
with a different context string, as you suggest, but leave the
external_aad as nil. This would give HPKE the same "interface" as the
ephemeral-static DH content key distribution algorithm.
Ciao
Hannes
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
