[CFRG] Re: Progressing NTRUPrime/Classic McEliece drafts

[Thom Wiggers <[e-mail]>]

Hi all,

Thanks for everyone who came forward with use cases; let me clarify that I never intended to suggest that McEliece should not be standardized, it’s just that its dramatic trade-off makes it a bit niche. I’m very interested in seeing if this trade-off can be properly exploited :-) 

Cheers,

Thom 

> Op 29 jan 2025, om 03:25 heeft Eric Rescorla <[e-mail]> het volgende geschreven:
> 
> 
> 
> On Tue, Jan 28, 2025 at 1:41 AM Simon Josefsson <simon=[e-mail] <mailto:[e-mail]>> wrote:
>> "Martin Thomson" <[e-mail] <mailto:[e-mail]>> writes:
>> 
>> > On Mon, Jan 27, 2025, at 20:02, Thom Wiggers wrote:
>> >> For Classic McEliece, I think it would be helpful if people come 
>> >> forward with concrete applications in which they're actually 
>> >> wanting/trying to deploy Classic McEliece.
>> >
>> > I think that it would be very useful to have McEliece available for
>> > both Oblivious HTTP and (maybe) ECH.  We have a few cases where the
>> > number of times that public keys transit the network are far fewer
>> > than the number of ciphertexts.  Obviously, a hybrid with X25519 is
>> > probably where I'd want to go with that.
>> 
>> I have specified a hybrid between X448+X2559 and Classic McEliece here:
>> 
>> https://datatracker.ietf.org/doc/html/draft-josefsson-chempat-02#name-chempat-with-classic-mcelie
>> 
>> FWIW, I think the CFRG should be able to publish crypto primitive
>> specifications if there are people interested in working on them.
> 
> I agree that the CFRG should be able to publish crypto specifications.
> I think the CFRG should focus its limited energy on specifications
> which are likely to be used by IETF protocols.
> 
>  
>> Defering authority on crypto primitives to NIST is implied by many
>> suggestions made IETF-wide right now.
> 
> i haven't seen anyone suggest that CFRG should not publish its own
> specifications regardless of what NIST does. That's certainly not
> my position. That would be an odd position to take as CFRG has
> already done this a number of times.
> 
> -Ekr
> 
>> 
>> /Simon
>> 
>> 
>> >
>> > With a 240 byte ciphertext (I had trouble finding a specific value, so
>> > this might be incorrect), that's quite a lot smaller than ML-KEM-768.
>> > The ~800 bytes of saving per message means that you need to clear
>> > ~1200 messages for each public key transfer before the overall
>> > transfer cost is neutral.  But the likelihood that messages fit in a
>> > single packet is a huge gain that has value far beyond what a simple
>> > tally might suggest.
>> >
>> > I mentioned ECH, though I suspect that we'd need to do some work
>> > there.  That is, both to get 1MB keys into DNS reliably (ECH configs
>> > are currently 71 bytes typically) as well as to improve caching and
>> > reuse so that the 1200:1 ratio could be realized.  Right now, I
>> > suspect that the ratio for ECH is closer to OHTTP can easily reach
>> > that sort of ratio, which makes McEliece a viable option there.
>> >
>> > _______________________________________________
>> > CFRG mailing list -- [e-mail] <mailto:[e-mail]>
>> > To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
>> _______________________________________________
>> CFRG mailing list -- [e-mail] <mailto:[e-mail]>
>> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
> _______________________________________________
> CFRG mailing list -- [e-mail] <mailto:[e-mail]>
> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>