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

[tirumal reddy <[e-mail]>]

On Thu, 11 Jul 2024 at 19:14, Ilari Liusvaara <[e-mail]>
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 <[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.
>

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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>