Re: [CFRG] Classic McEliece

[John Mattsson <[e-mail]>]

D. J. Bernstein wrote:

> prohibited from speculating

Seems like a nice SDO ... :)

> The ISO style file inserted an incorrect ISO copyright notice

That ISO systematically commit copyfraud does certainly not make
me like their paywalled security risk standards better. Copyfraud is a
huge problem. Unfortunately, authorities mostly ignore this crime.

> what it'll do, but why should speculation about future >standardization by
> NIST and/or ISO enter into CFRG decisions regarding this draft?

> We're already seeing McEliece deployment in Mullvad, for example, and in
> Rosenpass.

I am aware of several other commercial implementations as well.
European governments are recommending Classic McEliece or
FrodoKEM for European national security systems. I am sure
there are or will be many more implementations.

I am strongly in favor of one or more (NIST and/or CFRG) publicly
available specifications of Classic McEliece. I will make sure to send
this as an official comment to NIST as well.

>There is no NIST specification for the McEliece cryptosystem. If you
>mean "potential future NIST specification", please say that clearly.

Yes. I am talking about a potential future NIST standard. Based on the
latest comments from NIST I would even speculate that such a standard
is likely.

> It's normal for CFRG to document cryptographic primitives in
> use on the Internet.

> _Of course_ a future NIST specification, if one happens, should not
> deviate from the careful Classic McEliece design. I'm not seeing how
> this future possibility is relevant to Simon's draft.

I think both a future NIST and CFRG specification could deviate from the
current non-standardized specification if needed for security or performance.
If adopted, CFRG decides. I don’t think too much consideration should be given
to existing implementations or paywalled SDOs like ISO. I think it is bad security
practice to deploy both paywalled standards and non-standardized algorithms.

IETF/CFRG is typically a hesitant to overlap to much with other non-paywalled
SDOs. It is a waste of everybody’s time. That said, I think a public RFC or FIPS
specifying Classic McEliece is very much needed. Given the uncertainty that
NIST will standardize Classic McELiece, I think work on this should proceed in CFRG.

Cheers,
John

From: CFRG <[e-mail]> on behalf of D. J. Bernstein <[e-mail]>
Date: Wednesday, 18 October 2023 at 15:52
To: [e-mail] <[e-mail]>
Subject: Re: [CFRG] Classic McEliece
Peter C writes:
> if the CRFG wants a specification to use as an alternative to an ISO
> standard

I don't understand this framing.

First of all, there is no ISO standard on this topic. ISO actors are
permitted by ISO policy to reveal that ISO is _considering_ McEliece
standardization, but are prohibited from speculating that those
discussions will produce an ISO standard; that's a future decision for
ISO to make. If you mean "potential future ISO standard", please say
that clearly.

NIST's statements regarding Classic McEliece similarly allow NIST to
make either decision. Obviously NIST doesn't prohibit speculation about
what it'll do, but why should speculation about future standardization
by NIST and/or ISO enter into CFRG decisions regarding this draft?

We're already seeing McEliece deployment in Mullvad, for example, and in
Rosenpass. It's normal for CFRG to document cryptographic primitives in
use on the Internet.

> this is not the way to go about it.

Simon said he took the latest public spec from the Classic McEliece team
and based his draft on that. (That spec happens to have been prepared
for ISO. The ISO style file inserted an incorrect ISO copyright notice;
as one of the authors, I can confidently state that ISO does not own
copyright. Regarding the notion that ISO needs a copyright transfer, see
the quote from the ISO Directives earlier in the thread.)

If there are specific tweaks needed for IETF/IRTF then of course those
should happen, but overall the process here is exactly the right way to
go. The sharing of text simplifies review.

John Mattsson writes:
> Yes, non-public paywalled ISO algorithms should not be used at all,
> they are a cybersecurity risk.

The cost of buying ISO standards definitely reduces the amount of review
that those standards receive. However, all documents under discussion
here are, as Peter C put it, "almost" verbatim copies of each other.
Obviously this doesn't rule out the possibility of future changes, and
from a security perspective one has to be very careful with the word
"almost", but I'm not seeing how this is relevant to Simon's draft.

> I don’t care about ISO, but a CFRG publication should not differ from
> a publicly available NIST specification.

There is no NIST specification for the McEliece cryptosystem. If you
mean "potential future NIST specification", please say that clearly.

_Of course_ a future NIST specification, if one happens, should not
deviate from the careful Classic McEliece design. I'm not seeing how
this future possibility is relevant to Simon's draft.

---D. J. Bernstein (speaking for myself)