On Thu, 11 Jul 2024 at 19:14, Ilari Liusvaara <[email protected]> wrote:
> 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. > Please elaborate on why the attack cannot be mitigated. > > 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. > Got it, we will update the draft. > > > > > 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. > Yes, updated draft to use "ciphertext" instead of "encCEK" > > > > > 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. > For COSE, KMAC256 sounds good to me. Cheers, -Tiru > > > > > > -Ilari > > _______________________________________________ > jose mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
