On Thu, Jul 11, 2024 at 06:15:28PM +0530, tirumal reddy wrote: > Hi Illari, > > On Tue, 9 Jul 2024 at 21:05, Ilari Liusvaara <[email protected]> > wrote: >
> > "CipherText" is not valid input to Concat KDF. There is no need to > > bind ciphertext: ML-KEM is already IND-CCA and forwarding-resistant, > > which is enough for any ordinary encryption. > > > > MAL-BIND-K-CT or MAL-BIND-K-PK would require security proof that > > ML-KEM is safe to use in protocol. Which is not possible to prove, > > because MAL-BIND-K-CT or MAL-BIND-K-PK adversary can just trivially > > break all security. > > > > It is added to provide the same level of security properties as the HPKE > and Hybrid HPKE (draft-connolly-cfrg-hpke-mlkem). Both offer MAL-BIND-K-CT > and MAL-BIND-K-PK, whereas ML-KEM only provides MAL-BIND-K-PK. Those KEM properties are red herring, because neither COSE nor JOSE can use such properties. The reason is that the attacks are just too powerful to defend against. MAL-BIND-* stuff is worse than LEAK-BIND-* stuff, and that already allows compromising any private key, which already destroys both COSE and JOSE. > > Section 7.1. Single Recipient / One Layer Structure: > > > > COSE only allows one algorithm per layer, but there are two algorithms > > (bulk encryption and direct key agreement) so this design will not work. > > > > This needs to be done the same way as ECDH-ES is used in COSE: Have bulk > > encryption in layer0, and Direct Key Agreement in layer1. > > > > We are following the same approach specified for ECDH-ES in COSE (Section > 8.5.4 of RFC9052 and COSE HPKE) Using ECDH-ES in COSE requires two layers: One layer to generate a CEK and another to use CEK for bulk encryption. COSE HPKE has nothing to do with ECDH-ES. It is totally different mode, which is actually critical in making the thing work. > > Section 7.2. Multiple Recipients / Two Layer Structure: > > > > "and encrypted CEK in the encCEK structure" > > > > ... RFC9052 defines COSE_recipient to have "ciphertext" field for the > > layer ciphertext (which is the key wrap output in this case). > > > > Yes but I see COSE HPKE uses encCEK structure. In the end, both end up doing the same thing. > > Section 8. JOSE Ciphersuite Registration: > > > > What KDF hash do those algorithms use? > > > > The most aligned choice would be KMAC256 (as in NIST SP800-56Cr2), > > using 131 (the spec has off-by-one goof) byte all-zeroes salt and > > H_outputBits=L. > > > > Yes, KMAC256 sounds good. > > > > > > > > Section 9. COSE Ciphersuite Registration: > > > > Same as above, what KDF hash do those algorithms use? And the most > > aligned choice is the same. > > > > In case of COSE, HMAC with SHA-256 can be used as KDF. The C in COSE ultimately stands for "constrained", so it is even more important to align the KDF than in JOSE. Using SHA256 as KDF would require implmenting both SHA-2 and SHA-3 (ML-KEM requires SHA-3). Using KMAC256 as KDF would only require implementing SHA-3. -Ilari _______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
