crypto: ecdsa - Move X9.62 signature decoding into template
authorLukas Wunner <lukas@wunner.de>
Tue, 10 Sep 2024 14:30:25 +0000 (16:30 +0200)
committerHerbert Xu <herbert@gondor.apana.org.au>
Sat, 5 Oct 2024 05:22:04 +0000 (13:22 +0800)
commitd6793ff974e07e4eea151d1f0805e92d042825a1
tree2bb28bfcfbbcacab3b3eedef1f63779912240b23
parent3b0565c703503f832d6cd7ba805aafa3b330cb9d
crypto: ecdsa - Move X9.62 signature decoding into template

Unlike the rsa driver, which separates signature decoding and
signature verification into two steps, the ecdsa driver does both in one.

This restricts users to the one signature format currently supported
(X9.62) and prevents addition of others such as P1363, which is needed
by the forthcoming SPDM library (Security Protocol and Data Model) for
PCI device authentication.

Per Herbert's suggestion, change ecdsa to use a "raw" signature encoding
and then implement X9.62 and P1363 as templates which convert their
respective encodings to the raw one.  One may then specify
"x962(ecdsa-nist-XXX)" or "p1363(ecdsa-nist-XXX)" to pick the encoding.

The present commit moves X9.62 decoding to a template.  A separate
commit is going to introduce another template for P1363 decoding.

The ecdsa driver internally represents a signature as two u64 arrays of
size ECC_MAX_BYTES.  This appears to be the most natural choice for the
raw format as it can directly be used for verification without having to
further decode signature data or copy it around.

Repurpose all the existing test vectors for "x962(ecdsa-nist-XXX)" and
create a duplicate of them to test the raw encoding.

Link: https://lore.kernel.org/all/ZoHXyGwRzVvYkcTP@gondor.apana.org.au/
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
crypto/Makefile
crypto/asymmetric_keys/public_key.c
crypto/ecdsa-x962.c [new file with mode: 0644]
crypto/ecdsa.c
crypto/testmgr.c
crypto/testmgr.h
include/crypto/internal/ecc.h