On Mon, Jul 22, 2024 at 09:35:54PM +0900, Ken Takayama wrote: > Ilari, > > > - So if it is combined KDF+KW, it is alg of this layer. > > - Otherwise, it is alg of next layer. > > It seems like section 4.6.2 of RFC 7518 "JSON Web Algorithms" > <https://datatracker.ietf.org/doc/html/rfc7518#section-4.6.2> > > In the Key Agreement with Key Wrapping case, Data is set to the octets of > the ASCII representation of the "alg" (algorithm) Header Parameter value. > > On the other hand, section 5.2 of RFC 9053 says, > > This field indicates the algorithm for which the key material will be > used. This normally is either a key wrap algorithm identifier or a content > encryption algorithm identifier. > That's why I'm still not convinced to use ECDH-SS+A256KW (-34) for > AlgorithmID in COSE.
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? However, that is not the only problem with algorithms -34 to -25. > > I’ve modified it to show some options to address the attack. > Thanks! I could update the chart. Since it is generated by the aasvg tool, > colors fade away... > > Your proposal is depicted [Rec], and fed into ContextR.open(aad=Rec, > ct=eCEK). > Does it mitigate lamps attack only with COSE-HPKE? Yeah, binding the next algorithm does mitigate the attack. 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. That is the reason why one needs the extra KDF step (marked as [Hannes] in the diagram below) in some cases. > ```aasvg > Direct Direct+KDF AES-KW Direct ECDH ECDH+AES-KW COSE-HPKE > > .---. .--. .---. .---. .---. .---. .---. .---. .---. > | PSK | | SS | | PSK | | pkS || skR | | pkS || skR | | pkS || skR | > '-+-' '-+' '-+-' '-+-' '-+-' '-+-' '-+-' '-+-' '-+-' > | | | v v v v v v > | | | +--+------+--+ +--+------+--+ .-+------+-. > | | | | ECDH | | ECDH | | ContextR | > | | | +-+----------+ +--+---------+ '-+--------' > | .-' | v v | > | | .---. | .--+--. .---. .--+--. .---. | .---. > | || CIS | | | DH SS || CIS | | DH SS || CIS | | | Rec | > | | '-+-' | '--+--' '-+-' '--+--' '-+-' | '-+-' > | v v | v v v v | .-' > | +-+---+-+ | +-+-------+-+ +-+-------+-+ | | > | | HKDF | | | HKDF | | HKDF | | | > | +---+---' .-' +-----+-----+ +---+-------+ | | > | | | .----. | | .----. | | .----. > | | || eCEK | | || eCEK | | || eCEK | > | | | '--+-' | | '--+-' | | '-+--' > | | v v | v v v v v > | | +-+----+-+ | +-+----+-+ +-+-+---+-+ > | | | Unwrap | | | Unwrap | | open | > | | +---+----+ | +---+----+ +----+----+ > v v v v v v > .-+------+-------+------------+----------------+-------------+---. > | Content Encryption Key (CEK) | > '---------------------+------------------------------------------' > | .----. > | | CIS? | > | '-+--' > v v > +-------------+----+--------+ .-----------------. > | HKDF if cek-hkdf [Hannes] | | Encrypted Payload | > +-------------+-------------+ '--------+--------' > v v > +----------------------+------------------------------+--------------+ > | Content Decryption with ce_alg = AES GCM, CCM, CTR, CBC, ... | > +---------------------------------+----------------------------------+ > v > .---------+--------. > | Plaintext Payload | > '------------------' > > PSK : Pre Shared Key > SS : Shared Secret > pkS : (Static or Ephemeral) sender's Public key > skR : recipient's Private key > CIS : COSE Context Information Structure > DH SS : DH-Shared Secret > Rec : Recipient_structure [Laurence] > eCEK : encrypted CEK in COSE message > ``` -Ilari _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
