[botan-devel] import openssl pkcs8 ecdsa key with Botan 1.10.1

tobeki at gmx.de tobeki at gmx.de
Mon Jul 9 15:08:41 EDT 2012


Thank's Jack,

>However that is not the case for the 5915 extensions,
>they are for data we already have or can easily rederive, so they can
>be safely ignored.

parameters [0] ECParameters {{ NamedCurve }} OPTIONAL
publicKey  [1] BIT STRING OPTIONAL

so this optional parameters in 5915 are just needed for performance reasons?


-----Ursprüngliche Nachricht----- 
From: Jack Lloyd
Sent: Monday, July 09, 2012 2:48 PM
To: Botan development list
Subject: Re: [botan-devel] import openssl pkcs8 ecdsa key with Botan 1.10.1

On Sun, Jul 08, 2012 at 10:22:11AM +0200, tobeki at gmx.de wrote:

> for some testing I created an ecdsa key with openssl and converted it to
> pkcs8 compatible. Then I was trying to import the key with Botan
> PKCS8::load_key as shown below.
> But this causes an invalid state exception. Can someone point me out what 
> to
> do/configure to get this working?

It appears that RFC 5915 specifies extra fields for the ECPrivateKey
structure which the current code is not expecting to exist but which
OpenSSL is including:

  d= 2, l= 107:   SEQUENCE
  d= 3, l=   1:    INTEGER                         :1
  d= 3, l=  32:    OCTET STRING
  d= 3, l=  68:    cons [1] context    <- this thing
  d= 4, l=  66:     BIT STRING

That final BIT STRING is the public key associated with the private
key. It doesn't appear like there is any way to tell OpenSSL's command
line tool to not include these fields.

As a short term local hack you could edit
src/pubkey/ecc_key/ecc_key.cpp and remove the call to verify_end.
This will cause the unneeded parameters to be ignored. This is safe;
the whole point of the verify_end call was because the original
definition of the ECPrivateKey structure had no fields besides the
version and private key, and if things changed I wanted it to fail
loudly in case the new data was in some way critical
information. However that is not the case for the 5915 extensions,
they are for data we already have or can easily rederive, so they can
be safely ignored.

I've opened bug 209 [http://bugs.randombit.net/show_bug.cgi?id=209]
for adding support for actually using the public key value if it is
available since that does save us having to recompute it, so that
reading keys like this will work out of the box in future versions.

-Jack

_______________________________________________
botan-devel mailing list
botan-devel at randombit.net
http://lists.randombit.net/mailman/listinfo/botan-devel 




More information about the botan-devel mailing list