[jose] Re: [COSE] Re: Fwd: New Version Notification for draft-reddy-cose-jose-pqc-kem-02.txt

[Ilari Liusvaara <[e-mail]>]

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 <[e-mail]>
> 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