Ilari, > Are there any implementations? What do those do? There are some example binaries in the github.com/cose-wg repository, and they are different from what my thought is.
ECDH-ES+A128KW (-29) & A128GCM (1) example uses A128KW (-3). See the Context_hex here. < https://github.com/cose-wg/Examples/blob/master/ecdh-wrap-examples/p256-wrap-128-01.json#L45C30-L45C32 > [-3, [null, null, null], [null, null, null], [128, << {1: -29} >>]] ECDH-SS+HKDF-256 (-27) & A128GCM (1) example uses A128GCM (1). < https://github.com/cose-wg/Examples/blob/master/ecdh-direct-examples/p256-ss-hkdf-256-01.json#L45C30-L45C32 > [1, [null, h'02D1F7E6F26C43D4868D87CEB2353161740AACF1F7163647984B522A848DF1C3C9CF4DF2FE6C632BF7886413F76E88523A8260B857D70B350027FD842B5E5947', null], [null, null, null], [128, << {1: -27} >>]] direct+HKDF-AES-128 (-12) & AES-CCM-16-64-128 (10) example uses AES-CCM-16-64-128 (10). < https://github.com/cose-wg/Examples/blob/master/hkdf-aes-examples/hmac-aes-128-01.json#L36C30-L36C32 > [10, [null, null, null], [null, null, null], [128, << {1: -12} >>]] ECDH-ES+HKDF-256 (-25) & A128KW (-3) & A128GCM (1) example uses A128KW (-3). < https://github.com/cose-wg/Examples/blob/master/RFC8152/Appendix_B.json#L55C36-L55C38 > [-3, [null, null, null], [null, null, null], [128, << {1: -25} >>]] Implementations using these examples as test vector would use a key wrap algorithm identifier if the key distribution methods are ECDH+AES-KW or combination of ECDH+HKDF & AES-KW, and a content encryption algorithm identifier for other methods. In other words, a key wrap algorithm identifier if the key distribution method is ECDH+AES-KW, and the algorithm identifier in the next layer for other methods. It's not good because RFC doesn't tell enough and examples outside RFC become the specification, and ECDH+AES-KW is treated too much specially. > Yup, there is no binding across layers. You may notice that each algorithm id of the key distribution method, -29, -27, -12, -25, is inside of the context information structure (`protected` part), so they definitely derive the keys binding across layers. In a bad case, however, the protected part can be empty, see < https://datatracker.ietf.org/doc/html/rfc9053#section-5.2-7.8.2.4>. The alg of the key distribution method may be inside unprotected header of layer1. I don't want to accept such COSE message as a self-protective recipient because layers are not bound in such case. Best, Ken 2024年7月24日(水) 1:08 Ilari Liusvaara <[email protected]>: > 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] >
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
