On Wed, Jul 24, 2024 at 12:10:24AM +0900, Ken Takayama wrote:
> Ilari,
>
> > Is there even a guarantee that corresponding dedicated key wrap
> > algorithm exists? Currently all the registered algorithms have a
> > corresponding dedicated key wrap, but could one register an algorithm
> > that does not?
> Right. AES Key Wrap algorithms are happily registered but there is no
> guarantee into the future.
E.g., if there are KAwKW algorithms using combined-key AES-GCM (or
Chacha20-Poly1305) for key wrap, those do not have KW equivalents,
because combined-key AES-GCM is totally broken as standalone key wrap
(and likewise for Chacha20-Poly1305).
> That's why I want to update section 5.2 of RFC 9053 like
> "This is the algorithm identifier of *just the upper (or next) layer*,
> normally a content encryption algorithm identifier or a key wrap algorithm
> identifier."
> For example, when a COSE message have { layer0.alg : A128GCM, layer1.alg :
> ECDH-ES+A128KW},
> a content encryption algorithm identifier A128GCM should be the value of
> COSE_KDF_Context.AlgorithmID for ECDH-ES+A128KW.
Are there any implementations? What do those do?
And changing what algorithm id to use for context pretty much requires
new algorithms.
> For triple-layer example in RFC 9052 <
> https://datatracker.ietf.org/doc/html/rfc9052#name-two-layers-of-recipient-inf
> >,
> which has { layer0.alg : A128GCM, layer1.alg : A128KW, layer2.alg :
> ECDH-ES+HKDF-256 },
> a key wrap algorithm identifier A128KW should be the value of
> COSE_KDF_Context.AlgorithmID for ECDH-ES+HKDF-256.
> However, the latter case doesn't prevent the lamps attack because the same
> CEK will be derived also for { layer0.alg : A128CBC, layer1.alg : A128KW,
> layer2.alg : ECDH-ES+HKDF-256 } .
Yup, there is no binding across layers.
> I think we have several options:
> a) Hannes's approach that surely derives the final CEK using a content
> encryption algorithm identifier
> b) Laurence's approach that feeds new structure, Recipient_structure, to
> both ContextR.open() and HKDF() functions, with updating section 5.2 of RFC
> 9053
> c) Updating section 5.2 of RFC 9053 with "This is the algorithm identifier
> of *the top layer*, normally a content encryption algorithm identifier."
> Option b and c may not be the perfect mitigation for lamps attack, because
> they don't care about key distribution methods without KDF, Direct and
> AES-KW.
> Even though, I think that we are in the same thought that section 5.2 of
> RFC 9053 is not good for security nor interoperability, and that it is
> better for us to clarify it.
Only a) works for all the stuff.
Deriving the final CEK would also be useful for Direct Encryption. Right
now there does not seem to be a safe way to do DE (because all the
algorithms have short nonces and fail badly if nonce is repeated).
The context information could include:
- Layer number.
- Layer algorithm.
- Key or IV?
- Needed length
- Layer salt header value.
> > However, I noticed that the diagram is missing RSA-OEAP, which is key
> > transport mode. That one has no facility to bind the next algorithm.
> Indeed... But forgive me, the diagram is going to exceed the limit of the
> width of I-D, 72 characters.
> OAEP itself actually doesn't have an identifier, but RSA-OAEP seems not to
> take COSE_KDF_Context as a parameter, right?
The description is unclear, but I think RSA-OEAP does not bind anything
and just encrypts the raw CEK (which is the worst-case scenario).
-Ilari
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]
