linux-modules.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: David Howells <dhowells@redhat.com>
Cc: linux-crypto@vger.kernel.org,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Petr Pavlu <petr.pavlu@suse.com>,
	Daniel Gomez <da.gomez@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	"Jason A . Donenfeld" <Jason@zx2c4.com>,
	Ard Biesheuvel <ardb@kernel.org>,
	Stephan Mueller <smueller@chronox.de>,
	Lukas Wunner <lukas@wunner.de>,
	Ignat Korchagin <ignat@cloudflare.com>,
	keyrings@vger.kernel.org, linux-modules@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/4] lib/crypto: Add ML-DSA verification support
Date: Fri, 21 Nov 2025 22:23:09 +0000	[thread overview]
Message-ID: <20251121222309.GA3300186@google.com> (raw)
In-Reply-To: <3067069.1763761171@warthog.procyon.org.uk>

On Fri, Nov 21, 2025 at 09:39:31PM +0000, David Howells wrote:
> Eric Biggers <ebiggers@kernel.org> wrote:
> 
> > > > +	if (memcmp(ws->ctildeprime, ctilde, params->ctilde_len) != 0)
> > > > +		return -EBADMSG;
> > > 
> > > Actually, this should return -EKEYREJECTED, not -EBADMSG.
> > 
> > Who/what decided that?
> 
> I did.  When I added RSA support in 2012 for module signing.  Note that it
> was originally added as part of crypto/asymmetric_keys/ and was not covered by
> a crypto API.  The RSA code has since been moved to crypto/ and is now
> accessed through the crypto API, but it has retained this error code and this
> is also used by other public key algos.
> 
> > A lot of the crypto code uses -EBADMSG already.
> > crypto_aead uses it, for example.
> 
> ecdsa.c:60:	return -EKEYREJECTED;
> ecrdsa.c:111:		return -EKEYREJECTED;
> ecrdsa.c:139:		return -EKEYREJECTED;
> ecrdsa.c:239:		return -EKEYREJECTED;
> rsassa-pkcs1.c:293:		return -EKEYREJECTED;
> rsassa-pkcs1.c:295:		return -EKEYREJECTED;

crypto/aegis128-core.c:442:             return -EBADMSG;
crypto/aegis128-core.c:499:             return -EBADMSG;
crypto/algif_aead.c:313:                        if (err == -EIOCBQUEUED || err == -EBADMSG || !ret)
crypto/authenc.c:223:           return -EBADMSG;
crypto/authencesn.c:220:                return -EBADMSG;
crypto/ccm.c:336:                       err = -EBADMSG;
crypto/ccm.c:384:               return -EBADMSG;
crypto/chacha20poly1305.c:90:           return -EBADMSG;
crypto/dh.c:207:                                ret = -EBADMSG;
crypto/dh.c:221:                                ret = -EBADMSG;
crypto/dh.c:242:                ret = -EBADMSG;
crypto/ecdsa.c:37:              return -EBADMSG;
crypto/ecrdsa.c:101:            return -EBADMSG;
crypto/gcm.c:471:       return crypto_memneq(iauth_tag, auth_tag, authsize) ? -EBADMSG : 0;
crypto/krb5enc.c:259:           return -EBADMSG;
crypto/rsa.c:150:               ret = -EBADMSG;
crypto/rsa.c:189:               ret = -EBADMSG;
crypto/rsassa-pkcs1.c:275:              return -EBADMSG;
crypto/rsassa-pkcs1.c:282:              return -EBADMSG;
crypto/rsassa-pkcs1.c:286:              return -EBADMSG;
crypto/rsassa-pkcs1.c:288:              return -EBADMSG;
crypto/testmgr.c:90:     * algorithm might result in EINVAL rather than EBADMSG, due to other
crypto/testmgr.c:2179:      (err != vec->crypt_error && !(err == -EBADMSG && vec->novrfy))) {
crypto/testmgr.c:2183:              vec->crypt_error != 0 && vec->crypt_error != -EBADMSG)
crypto/testmgr.c:2184:                  sprintf(expected_error, "-EBADMSG or %d",
crypto/testmgr.c:2187:                  sprintf(expected_error, "-EBADMSG");
include/crypto/aead.h:37: * operation is that the caller should explicitly check for -EBADMSG of the
include/crypto/aead.h:39: * a breach in the integrity of the message. In essence, that -EBADMSG error
include/crypto/aead.h:375: * Return: 0 if the cipher operation was successful; -EBADMSG: The AEAD

That list actually includes the same three files that use -EKEYREJECTED.
It looks like if the signature verification fails "early" it's -EBADMSG,
whereas if it fails "late" it's -EKEYREJECTED?  I'm skeptical that
that's a meaningful difference.  And it's not like this is documented
either; crypto_sig_verify() just says "error code in case of error".

- Eric

  reply	other threads:[~2025-11-21 22:23 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-20  0:36 [PATCH 0/4] lib/crypto: ML-DSA verification support Eric Biggers
2025-11-20  0:36 ` [PATCH 1/4] lib/crypto: Add " Eric Biggers
2025-11-20  0:36 ` [PATCH 2/4] lib/crypto: tests: Add KUnit tests for ML-DSA Eric Biggers
2025-11-20  2:29   ` Elliott, Robert (Servers)
2025-11-20  0:36 ` [PATCH 3/4] lib/crypto: tests: Add ML-DSA-65 test cases Eric Biggers
2025-11-20  0:36 ` [PATCH 4/4] lib/crypto: tests: Add ML-DSA-87 " Eric Biggers
2025-11-20  8:11 ` [PATCH 0/4] lib/crypto: ML-DSA verification support David Howells
2025-11-21  6:16   ` Eric Biggers
2025-11-20  8:14 ` [PATCH 1/4] lib/crypto: Add " David Howells
2025-11-21  2:15   ` Eric Biggers
2025-11-20  9:10 ` David Howells
2025-11-21  0:09   ` Eric Biggers
2025-11-20 13:55 ` David Howells
2025-11-21  0:50   ` Eric Biggers
2025-11-21 12:41   ` David Howells
2025-11-21 17:14     ` Eric Biggers
2025-11-21 17:41     ` David Howells
2025-11-21 21:39   ` David Howells
2025-11-21 22:23     ` Eric Biggers [this message]
2025-11-21 22:29       ` Lukas Wunner
2025-11-21 22:48         ` Eric Biggers

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=20251121222309.GA3300186@google.com \
    --to=ebiggers@kernel.org \
    --cc=Jason@zx2c4.com \
    --cc=ardb@kernel.org \
    --cc=da.gomez@kernel.org \
    --cc=dhowells@redhat.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=ignat@cloudflare.com \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=mcgrof@kernel.org \
    --cc=petr.pavlu@suse.com \
    --cc=samitolvanen@google.com \
    --cc=smueller@chronox.de \
    /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 NNTP newsgroup(s).