From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Gu Bowen <gubowen5@huawei.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
David Howells <dhowells@redhat.com>,
David Woodhouse <dwmw2@infradead.org>,
Lukas Wunner <lukas@wunner.de>,
Ignat Korchagin <ignat@cloudflare.com>,
"David S . Miller" <davem@davemloft.net>,
Jarkko Sakkinen <jarkko@kernel.org>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
Eric Biggers <ebiggers@kernel.org>,
Ard Biesheuvel <ardb@kernel.org>,
Tianjia Zhang <tianjia.zhang@linux.alibaba.com>,
Dan Carpenter <dan.carpenter@linaro.org>,
keyrings@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-crypto@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
Lu Jialin <lujialin4@huawei.com>,
GONG Ruiqi <gongruiqi1@huawei.com>
Subject: Re: [PATCH RFC 0/4] Reintroduce the sm2 algorithm
Date: Thu, 3 Jul 2025 15:14:52 +0200 [thread overview]
Message-ID: <aGaCTOJ30KNPOBIC@zx2c4.com> (raw)
In-Reply-To: <20250630133934.766646-1-gubowen5@huawei.com>
Hi,
On Mon, Jun 30, 2025 at 09:39:30PM +0800, Gu Bowen wrote:
> To reintroduce the sm2 algorithm, the patch set did the following:
> - Reintroduce the mpi library based on libgcrypt.
> - Reintroduce ec implementation to MPI library.
> - Rework sm2 algorithm.
> - Support verification of X.509 certificates.
>
> Gu Bowen (4):
> Revert "Revert "lib/mpi: Extend the MPI library""
> Revert "Revert "lib/mpi: Introduce ec implementation to MPI library""
> crypto/sm2: Rework sm2 alg with sig_alg backend
> crypto/sm2: support SM2-with-SM3 verification of X.509 certificates
I am less than enthusiastic about this. Firstly, I'm kind of biased
against the whole "national flag algorithms" thing. But I don't know how
much weight that argument will have here. More importantly, however,
implementing this atop MPI sounds very bad. The more MPI we can get rid
of, the better.
Is MPI constant time? Usually the good way to implement EC algorithms
like this is to very carefully work out constant time (and fast!) field
arithmetic routines, verify their correctness, and then implement your
ECC atop that. At this point, there's *lots* of work out there on doing
fast verified ECC and a bunch of different frameworks for producing good
implementations. There are also other implementations out there you
could look at that people have presumably studied a lot. This is old
news. (In 3 minutes of scrolling around, I noticed that
count_leading_zeros() on a value is used as a loop index, for example.
Maybe fine, maybe not, I dunno; this stuff requires analysis.)
On the other hand, maybe you don't care because you only implement
verification, not signing, so all info is public? If so, the fact that
you don't care about CT should probably be made pretty visible. But
either way, you should still be concerned with having an actually good &
correct implementation of which you feel strongly about the correctness.
Secondly, the MPI stuff you're proposing here adds a 25519 and 448
implementation, and support for weierstrauss, montgomery, and edwards,
and... surely you don't need all of this for SM-2. Why add all this
unused code? Presumably because you don't really understand or "own" all
of the code that you're proposing to add. And that gives me a lot of
hesitation, because somebody is going to have to maintain this, and if
the person sending patches with it isn't fully on top of it, we're not
off to a good start.
Lastly, just to nip in the bud the argument, "but weierstrauss is all
the same, so why not just have one library to do all possible
weierstrauss curves?" -- the fact that this series reintroduces the
removed "generic EC library" indicates there's actually not another user
of it, even before we get into questions of whether it's a good idea.
Jason
next prev parent reply other threads:[~2025-07-03 13:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-30 13:39 [PATCH RFC 0/4] Reintroduce the sm2 algorithm Gu Bowen
2025-06-30 13:39 ` [PATCH RFC 1/4] Revert "Revert "lib/mpi: Extend the MPI library"" Gu Bowen
2025-07-03 9:18 ` Xi Ruoyao
2025-06-30 13:39 ` [PATCH RFC 2/4] Revert "Revert "lib/mpi: Introduce ec implementation to " Gu Bowen
2025-07-02 15:18 ` Ignat Korchagin
2025-06-30 13:39 ` [PATCH RFC 3/4] crypto/sm2: Rework sm2 alg with sig_alg backend Gu Bowen
2025-06-30 13:39 ` [PATCH RFC 4/4] crypto/sm2: support SM2-with-SM3 verification of X.509 certificates Gu Bowen
2025-06-30 19:41 ` [PATCH RFC 0/4] Reintroduce the sm2 algorithm Dan Carpenter
2025-07-01 3:49 ` Gu Bowen
2025-07-03 13:14 ` Jason A. Donenfeld [this message]
2025-07-03 13:29 ` Jason A. Donenfeld
2025-07-03 13:33 ` Ignat Korchagin
2025-07-11 2:14 ` Gu Bowen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aGaCTOJ30KNPOBIC@zx2c4.com \
--to=jason@zx2c4.com \
--cc=alexandre.torgue@foss.st.com \
--cc=ardb@kernel.org \
--cc=dan.carpenter@linaro.org \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=dwmw2@infradead.org \
--cc=ebiggers@kernel.org \
--cc=gongruiqi1@huawei.com \
--cc=gubowen5@huawei.com \
--cc=herbert@gondor.apana.org.au \
--cc=ignat@cloudflare.com \
--cc=jarkko@kernel.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=lujialin4@huawei.com \
--cc=lukas@wunner.de \
--cc=mcoquelin.stm32@gmail.com \
--cc=tianjia.zhang@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).