I am testing, trying to load the following RSA Key with BouncyCastle:
RSA Key (pem file attached):
-----BEGIN RSA PRIVATE KEY-----
This Key was generated and saved with Eldos library SecureBlackBox in a Delphi app. When I try to load it with OPENSSL it works perfectly.
In BouncyCastle, i use the PEMParser.readObject(), code:
PEMParser pemParser = new PEMParser(new FileReader("private_key_delphi.pem"));
keyPair = pemParser.readObject();
I am getting the following error:
org.bouncycastle.openssl.PEMException: problem creating RSA private key: java.lang.IllegalArgumentException: failed to construct sequence from byte: corrupted stream detected
Is there something wrong with the Key? Is there something I can do in the load method to fix this?
Any help is deeply appreciated, thanks in advance,
private_key_delphi.pem (2K) Download Attachment
The public exponent is encoded as:
You can see this from an openssl ASN.1 dump as it shows as the number as having a length of 4, when it only needs to be 3.
I'm not sure why openssl accepts it, it's a bug, but at any rate the encoding is not valid which is why you are seeing the error. You might be able to get openssl to re-encode it correctly, but it would really be better if the originating application was encoding integers correctly.
On 11/05/17 09:33, Luis Arenal Mijares wrote:
How did you get the public exponent through OpenSSL?
Could you share us the command for the openssl ASN.1 dump?
Is there something we can do for demonstration purposes to Secure Black Box product owner about this bug in their library?
Luis's afirmation is correct: Why OpenSSL can load the key?
El 10 may. 2017 9:15 PM, "David Hook" <[hidden email]> escribió:
openssl asn1dump < file.pem
where file.pem contains the private key below.
OpenSSL can load the key because it is failing to validate an ASN.1 Integer is properly encoded. It is a bug in OpenSSL's ASN.1 parser (easy mistake to make, we certainly did...)
With the original product developers, you can direct them to ISO/IEC 8825-1:2003 (E), Section 8.3, specifically 8.3.2 which says
If the contents octets of an integer value encoding consist of more than one octet, then the bits of the first octet
and bit 8 of the second octet:
a) shall not all be ones; and
b) shall not all be zero.
There is a version of the standard available at:
On 11/05/17 14:38, Juan Francisco Alvarez Urquijo wrote:
openssl asn1dump < private_key_delphi.pem
openssl:Error: 'asn1dump' is an invalid command.
asn1dump doesn´t exist did you mean asn1parse?
Juan Francisco Alvarez Urquijo
Ingeniero de Software Senior.
Escuela Superior de Cómputo - Instituto Politécnico Nacional
Comprometidos con el cuidado del medio ambiente.
2017-05-10 23:55 GMT-05:00 David Hook <[hidden email]>:
On May 11, 2017, at 11:04 AM, Juan Francisco Alvarez Urquijo <[hidden email]> wrote:
Yes, as openssl itself told you, you mean/want “openssl asn1parse”.
In reply to this post by Juan Francisco Alvarez Urquijo
Yes, as Uri pointed out asn1parse - sorry, I mixed my commands...
268:d=1 hl=2 l= 4 prim: INTEGER :010001
The 4 should be a 3.
Yes, the signature has not been calculated correctly, the bigger problem it also means the data in it can be reordered without detection, while this doesn't make it trivial to forge an input to a signature, it does make it a lot easier. So be sparing how you use it - if someone is in the habit of sending you correct signatures and you suddenly get an incorrect one that verifies it is better to assume something is wrong. For people who do not get it right as a habit you'll need to use the fallback approach, although it would good idea if you can get them to mend their ways.What do you mean by "Be careful how you use this one, technically needing it means the signature is really invalid." Do you say that the signature is invalid, although MyRightSignerInformation.verify() returns true because of mistakes during the signature calculation?
On 12/05/17 01:04, Juan Francisco Alvarez Urquijo wrote:
|Free forum by Nabble||Edit this page|