ECDSA key parsing in crypto drivers

ECDSA key parsing in crypto drivers

[Paul Louvel]

Hi,

I am currently working on upstreaming the ECDSA part of a Public Key
Accelerator.
I have a question regarding which ASN.1 schema should I use when decoding the
buffer passed by the .set_pub_key() and .set_priv_key() callbacks in struct
sig_alg.
The documentation only mentions that the callbacks should "know how to decode
and interpret the BER encoded public key and parameters."

The kernel software implementation of ECDSA only supports verifying signatures,
and thus only implements the .set_pub_key() callback. In this callback, the
buffer should contain an ECC key as defined by RFC5480 section 2.2 [1].

In the downstream driver I am currently upstreaming, it expects a BER encoded
ASN.1 schema of SubjectPublicKeyInfo as defined in RFC5480 section 2 [2]. The
driver defines its own .asn1 file containing the ASN.1 schema of this sequence,
and uses the kernel's ASN.1 compiler/decoder to decode the buffer.

Because the PKA can be used to sign messages, there is a .set_priv_key()
callback that expects a BER encoded ASN.1 schema as defined in RFC5915 section
3 [3]. The same remark applies to the public key: a .asn1 file is present and
defines the ASN.1 schema described by the RFC.

My question is: which ASN.1 schema should be used? Should a client of the
crypto API know in advance which format the driver expects? Also, for RSA,
there are helpers for parsing private and public keys: rsa_parse_priv_key() and
rsa_parse_pub_key(). These helpers use the kernel's ASN.1 decoder. Would it
make sense to have such helpers for ECDSA?

Thank you,

[1] RFC5480 Section 2.2 - ECC Key Format
https://tools.ietf.org/html/rfc5480#section-2.2

[2] RFC5480 Section 2 - SubjectPublicKeyInfo
https://tools.ietf.org/html/rfc5480#section-2

[3] RFC5915 Section 3 - Private Key Format
https://tools.ietf.org/html/rfc5915#section-3

-- 
Paul Louvel, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: ECDSA key parsing in crypto drivers

[Paul Louvel]

Adding Herbert Xu and David S. Miller as recipient.

On 8/31/26 11:09 AM, Paul Louvel wrote:
> Hi,
>
> I am currently working on upstreaming the ECDSA part of a Public Key
> Accelerator.
> I have a question regarding which ASN.1 schema should I use when decoding the
> buffer passed by the .set_pub_key() and .set_priv_key() callbacks in struct
> sig_alg.
> The documentation only mentions that the callbacks should "know how to decode
> and interpret the BER encoded public key and parameters."
>
> The kernel software implementation of ECDSA only supports verifying signatures,
> and thus only implements the .set_pub_key() callback. In this callback, the
> buffer should contain an ECC key as defined by RFC5480 section 2.2 [1].
>
> In the downstream driver I am currently upstreaming, it expects a BER encoded
> ASN.1 schema of SubjectPublicKeyInfo as defined in RFC5480 section 2 [2]. The
> driver defines its own .asn1 file containing the ASN.1 schema of this sequence,
> and uses the kernel's ASN.1 compiler/decoder to decode the buffer.
>
> Because the PKA can be used to sign messages, there is a .set_priv_key()
> callback that expects a BER encoded ASN.1 schema as defined in RFC5915 section
> 3 [3]. The same remark applies to the public key: a .asn1 file is present and
> defines the ASN.1 schema described by the RFC.
>
> My question is: which ASN.1 schema should be used? Should a client of the
> crypto API know in advance which format the driver expects? Also, for RSA,
> there are helpers for parsing private and public keys: rsa_parse_priv_key() and
> rsa_parse_pub_key(). These helpers use the kernel's ASN.1 decoder. Would it
> make sense to have such helpers for ECDSA?
>
> Thank you,
>
> [1] RFC5480 Section 2.2 - ECC Key Format
> https://tools.ietf.org/html/rfc5480#section-2.2
>
> [2] RFC5480 Section 2 - SubjectPublicKeyInfo
> https://tools.ietf.org/html/rfc5480#section-2
>
> [3] RFC5915 Section 3 - Private Key Format
> https://tools.ietf.org/html/rfc5915#section-3
>
-- 
Paul Louvel, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: ECDSA key parsing in crypto drivers

[Herbert Xu]

On Mon, Aug 31, 2026 at 02:08:02PM +0200, Paul Louvel wrote:
>
> > My question is: which ASN.1 schema should be used? Should a client of the
> > crypto API know in advance which format the driver expects? Also, for RSA,
> > there are helpers for parsing private and public keys: rsa_parse_priv_key() and
> > rsa_parse_pub_key(). These helpers use the kernel's ASN.1 decoder. Would it
> > make sense to have such helpers for ECDSA?

The driver needs to match the generic C implementation of the
same algorithm.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: ECDSA key parsing in crypto drivers

[Paul Louvel]

Hi Herbert,

On 9/2/26 10:35 AM, Herbert Xu wrote:
> On Mon, Aug 31, 2026 at 02:08:02PM +0200, Paul Louvel wrote:
>>> My question is: which ASN.1 schema should be used? Should a client of the
>>> crypto API know in advance which format the driver expects? Also, for RSA,
>>> there are helpers for parsing private and public keys: rsa_parse_priv_key() and
>>> rsa_parse_pub_key(). These helpers use the kernel's ASN.1 decoder. Would it
>>> make sense to have such helpers for ECDSA?
> The driver needs to match the generic C implementation of the
> same algorithm.
>
> Cheers,

By "generic C implementation", do you mean the implementation in ecdsa.c ? For
verify operation, this is clear. But signing is not implemented, so there is no
callback for setting the private key.

Best regards,

-- 
Paul Louvel, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: ECDSA key parsing in crypto drivers

[Herbert Xu]

On Wed, Sep 02, 2026 at 01:58:33PM +0200, Paul Louvel wrote:
>
> By "generic C implementation", do you mean the implementation in ecdsa.c ? For
> verify operation, this is clear. But signing is not implemented, so there is no
> callback for setting the private key.

Right, in order for an algorithm/function to be added to the API,
there has to be an in-kernel use-case.  Right now there is no in-kernel
user of signing so that's why this is not implemented in the
generic code.

Until it's implemented in the generic code, drivers should not
expose this function (at least not via the Crypto API) either.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt