diff options
author | Lukas Wunner <lukas@wunner.de> | 2024-09-10 16:30:28 +0200 |
---|---|---|
committer | Herbert Xu <herbert@gondor.apana.org.au> | 2024-10-05 07:22:05 +0200 |
commit | b04163863caf599d4348a05af5a71cf5d42f11dc (patch) | |
tree | 6df4dac7100589e27c92e8153fbfd40fd32f7995 /crypto/cmac.c | |
parent | crypto: ecdsa - Move X9.62 signature size calculation into template (diff) | |
download | linux-b04163863caf599d4348a05af5a71cf5d42f11dc.tar.xz linux-b04163863caf599d4348a05af5a71cf5d42f11dc.zip |
crypto: ecdsa - Support P1363 signature decoding
Alternatively to the X9.62 encoding of ecdsa signatures, which uses
ASN.1 and is already supported by the kernel, there's another common
encoding called P1363. It stores r and s as the concatenation of two
big endian, unsigned integers. The name originates from IEEE P1363.
Add a P1363 template in support of the forthcoming SPDM library
(Security Protocol and Data Model) for PCI device authentication.
P1363 is prescribed by SPDM 1.2.1 margin no 44:
"For ECDSA signatures, excluding SM2, in SPDM, the signature shall be
the concatenation of r and s. The size of r shall be the size of
the selected curve. Likewise, the size of s shall be the size of
the selected curve. See BaseAsymAlgo in NEGOTIATE_ALGORITHMS for
the size of r and s. The byte order for r and s shall be in big
endian order. When placing ECDSA signatures into an SPDM signature
field, r shall come first followed by s."
Link: https://www.dmtf.org/sites/default/files/standards/documents/DSP0274_1.2.1.pdf
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Diffstat (limited to 'crypto/cmac.c')
0 files changed, 0 insertions, 0 deletions