Zeo Bartoli wrote:
>
> Hi,
> i am trying to parse a pkcs#5 encrypted pkcs#8 private
> key. it is B64 encoded, with -----BEGIN ENCRYPTED
> PRIVATE KEY----- as a name, but no header info, using
> the following command:
> openssl pkcs8 -in keyfile
>
> i am getting an error:
> Warning: broken key encoding: No Octet String in
> PrivateKey
>
> the code that is responsible for this is in
> apps/pkcs8.c
>
> if (p8inf->broken) {
> BIO_printf(bio_err, "Warning: broken key encoding:
> ");
> switch (p8inf->broken) {
> case PKCS8_NO_OCTET:
> BIO_printf(bio_err, "No Octet String in
> PrivateKey\n");
> break;
>
> .
> .
> . default:
> BIO_printf(bio_err, "Unknown broken type\n");
> break;
> }
> }
>
> namely, p8inf->broken has been set.
>
> now, to get here, the private key HAS been
> successfully decrypted in:
> if (!(pkey = EVP_PKCS82PKEY(p8inf)))
> (and i also parsed it by hand, and it is valid) i also
> use this key in an sslplus based app. its known to be
> valid.)
>
> so, does anyone know what this NO_OCTET stuff means
> and why p8inf is broken?
>
That error indicates that the private key format is invalid. In
particular it violates PKCS#8 in some way. Its a warning and OpenSSL
should still tolerate the key.
For some reason vendors use all manner of broken PKCS#8 formats and
OpenSSL has various work arounds to tolerate these.
This particular error is caused by invalid encoding of the
PrivateKeyInfo structure:
PrivateKeyInfo ::= SEQUENCE {
version Version,
privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
privateKey PrivateKey,
attributes [0] IMPLICIT Attributes OPTIONAL }
Version ::= INTEGER
PrivateKey ::= OCTET STRING
Attributes ::= SET OF Attribute
The contents octets of PrivateKey should be the encoding of an
RSAPrivateKey structure.
However in this invalid case the structure is encoded without the OCTET
STRING so you get:
PrivateKey ::= RSAPrivateKey
which is wrong.
This error was reported some time ago and a work around added. I believe
it was sslplus where this was first noticed. If I recall they fixed
their toolkit so it tolerated both forms but still left the sample keys
in the old broken form.
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]