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:29:21 +0200 [thread overview]
Message-ID: <aGaFsaUOuNd1xs8m@zx2c4.com> (raw)
In-Reply-To: <aGaCTOJ30KNPOBIC@zx2c4.com>
On Thu, Jul 03, 2025 at 03:14:52PM +0200, Jason A. Donenfeld wrote:
> 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.
I went looking for reference implementations and came across this
"GmSSL" project and located:
https://github.com/guanzhi/GmSSL/blob/master/src/sm2_sign.c#L271
which uses some routines from
https://github.com/guanzhi/GmSSL/blob/master/src/sm2_z256.c
I have no idea what the deal actually is here -- is this any good? has
anybody looked at it? is it a random github? -- but it certainly
_resembles_ something more comfortable than the MPI code. Who knows, it
could be terrible, but you get the idea.
Jason
next prev parent reply other threads:[~2025-07-03 13:29 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
2025-07-03 13:29 ` Jason A. Donenfeld [this message]
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=aGaFsaUOuNd1xs8m@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).