summaryrefslogtreecommitdiffstats
path: root/crypto/cmac.c
diff options
context:
space:
mode:
authorLukas Wunner <lukas@wunner.de>2024-09-10 16:30:28 +0200
committerHerbert Xu <herbert@gondor.apana.org.au>2024-10-05 07:22:05 +0200
commitb04163863caf599d4348a05af5a71cf5d42f11dc (patch)
tree6df4dac7100589e27c92e8153fbfd40fd32f7995 /crypto/cmac.c
parentcrypto: ecdsa - Move X9.62 signature size calculation into template (diff)
downloadlinux-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