[CFRG] Re: Chempat: Generic Instantiated PQ/T Hybrid Key Encapsulation Mechanisms

[Simon Josefsson <[e-mail]>]

Hi

Are you talking about registering pure Classic McEliece for HPKE, or
registering some hybrid Classic McEliece mode for HPKE as in Chempat?

Chempat carefully only registers hybrid mceliece6688128f with X448, to
reduce the combinatorical complexity of options:

https://datatracker.ietf.org/doc/html/draft-josefsson-chempat-00#name-chempat-x448-mceliece668812

Is the HPKE interface safe to use naively with Classic McEliece?

The Classic McEliece draft intentionally do not register anything for
HPKE because I was not convinced it makes sense to use Classic McEliece
directly in non-hybrid mode.  The extra size and computational cost to
do a X25519 or X448 call and resulting hash combination is tiny compared
to the cost of doing Classic McEliece.

There were some discussion about the need to bind public keys and
ciphertexts for Classic McEliece too.  A pure Classic McEliece HPKE
definition could use a non-hybrid but Chempat-like combiner H(ss_PQ ||
H(ct_PQ) || H(pk_PQ), context) in the Encapsulate/Decapsulate API's.
This is not a naive mapping of Classic McEliece to HPKE, but it seems
safer.  Maybe this is a useful addition to an update of
draft-josefsson-mceliece.

/Simon

John Mattsson <john.mattsson=[e-mail]> writes:

> Hi,
>
> I think it makes a lot of sense to register Classic McEliece for use
> in HPKE. HKPE uses a static encapsulation key for encryption to a
> single reciever. This is a use case Classic McEliece is perfect
> for. As the ciphertexts are small (96-208 bytes), the total message
> overhead is lower than for ML-KEM after just at few hundred
> encryptions. Futhermore encapsulation is very fast and memory usage
> can be very low. It is an excellent complement to ML-KEM.
>
> The draft registers too many options. I would like to see category 1, 3, 5
>
> mceliece348864
> mceliece460896
> mceliece6688128
>
> While you can arguee that lattice-based cryptography needs some
> margin, Classic McEliece is a very conservative choice. I don't see a
> need for big security margins.
>
> I don't see the need for three category 5 parameters. I noticed that
> BSI recommends 6688128 and not 6960119. 8192128 just seems overkill.
>
> Cheers,
> John
>
> From: CFRG <[e-mail]> on behalf of Ilari Liusvaara <[e-mail]>
> Date: Friday, 23 February 2024 at 14:46
> To: [e-mail] <[e-mail]>
> Subject: Re: [CFRG] Chempat: Generic Instantiated PQ/T Hybrid Key Encapsulation Mechanisms
> On Fri, Feb 23, 2024 at 12:49:09PM +0100, Simon Josefsson wrote:
>>
>> This seems like a approach worth considering further.  Especially if we
>> could somehow get a merge of X-Wing and Chempat as a unified result.
>> While I like reducing complexity, I see at least two challenges:
>
> I don't see any realistic way to do that.
>
>
>>  1) How to provide instantiated variants?  The document could suggest
>>  that a particular way to form "context" is required for use with that
>>  particular identified variant.  This approach add complexity to
>>  describe and understand.
>
> One idea I had was to assign OIDs for the optimized fixed-parameter
> KEMs, and then use byte-reversed ASN.1 DER encoding of that as context
> in combiner based on NIST SP 800-56Cr2 one-step (using some suitable
> SHA-2 or SHA-3 as hash).
>
>
>>  2) More rope to hang protocol designers.  Allowing designers to pick
>>  and chose what to include will more likely lead to security failures
>>  than simply always including everything.  This especially will happen
>>  of X-Wing is used as a example instance that doesn't include certain
>>  fields.
>
> Allowing designers to pick and choose anything will lead to very nasty
> results. Same goes for protocol designers optimizing anything, no matter
> how obviously unnecessary the thingy that got optimized out is.
>
> And the best way to prevent optimization is to preempt it. And no, I
> don't think X-Wing is fully optimized.
>
>
>
>
> -Ilari
>
> _______________________________________________
> CFRG mailing list
> [e-mail]
> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-0bfecc828a399e56&q=1&e=07c97a3c-8942-4985-a693-1689df7fbaff&u=https%3A%2F%2Fmailman.irtf.org%2Fmailman%2Flistinfo%2Fcfrg
> _______________________________________________
> CFRG mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>