On Tue, May 8, 2012 at 4:33 PM, Dave Thompson <dthomp...@prinpay.com> wrote:
>>From: owner-openssl-us...@openssl.org On Behalf Of Adrian Manuel Vázquez
> Betancourt
>>Sent: Tuesday, 08 May, 2012 15:21
>
>>I have a p12 certificate file and I would like to extract the private
>>key from it and export it as a pem file in plain pkcs#1 format.
>
>>openssl pkcs12 -in test.p12 -out testkey.pem -nodes -nocerts
>
>>openssl rsa -in testkey.pem -out testkey_pkcs1.pem
>
>>Now when I open the file testkey_pkcs1.pem from a ASN.1 Editor
>>some private key's elements (modulus, p, q, ...) have a 0 byte
>>value at the beginning of the number and others don't.
>
>>Why is it like that? Is there any padding rule that must be
>>consider for INTEGER types in ASN.1?
>
> Yes. ASN.1 INTEGER in BER/DER is signed two's-complement.
> It needs an 'extra' octet to get the sign correct if
> the high bit of the highest octet would be the wrong sign,
> in particular if the high bit of a positive number is set.
> BER allows an extra octet, or several, even if not needed;
> DER has it only if needed.
>
> 7F is 127
> 80 is -128
> 00 80 is +128
> FF 7F is -129
>
> RSA primes and moduli are usually chosen to exactly fill
> a round (binary) number of bits like 1024 1536 2048,
> and are positive, so they need an 'extra' 00.
>
>>The point is that I am trying to do the same decodification
>>with another tool and I am getting some mismatch between the
>>.pem file generated by openssl and the one generated by the
>>other tool and the diference are only those zeros.
>
> If the other tool isn't putting 00s where ASN.1 requires it,
> that tool is wrong.
GnuTLS used to have a similar encoding bug. Apparently its pretty common....
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
