I am attempting to use bouncy castle to generate ECDSA keys. The code seems to work fine from the Java perspective; but, when I dump the file and try to validate the data, OpenSSL does not like the format of the data.
After some research, I figured that bouncy castle is encoding the private key as public key.
Here is my Java code:
public class Test {
public static void main(String[] args) {
Security.addProvider(new BouncyCastleProvider());
System.out.println("Starting...");
String name = "prime256v1";
try {
KeyPairGenerator kpg = KeyPairGenerator.getInstance("ECDSA", BouncyCastleProvider.PROVIDER_NAME);
kpg.initialize(new ECGenParameterSpec(name));
KeyPair keyPair = kpg.generateKeyPair();
FileOutputStream writer = new FileOutputStream("private.key");
writer.write(keyPair.getPrivate().getEncoded());
writer.close();
} catch(Exception e) {
e.printStackTrace();
}
}
}
The file private.key
is generated in valid DER format; however, when I run the following command to see the ASN.1 structure of the key:
$ openssl asn1parse -inform DER -in /my/path/private.key
0:d=0 hl=3 l= 147 cons: SEQUENCE
3:d=1 hl=2 l= 1 prim: INTEGER :00
6:d=1 hl=2 l= 19 cons: SEQUENCE
8:d=2 hl=2 l= 7 prim: OBJECT :id-ecPublicKey
17:d=2 hl=2 l= 8 prim: OBJECT :prime256v1
27:d=1 hl=2 l= 121 prim: OCTET STRING [HEX DUMP]: <hex data>
For comparison, if I run the following commands to generate a ECDSA key using OpenSSL, I get the following ASN.1 structure:
$ openssl ecparam -name prime256v1 -genkey -noout -outform DER -out private.key
$ openssl asn1parse -inform DER -in private.key
0:d=0 hl=2 l= 119 cons: SEQUENCE
2:d=1 hl=2 l= 1 prim: INTEGER :01
5:d=1 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]: <hex data>
39:d=1 hl=2 l= 10 cons: cont [ 0 ]
41:d=2 hl=2 l= 8 prim: OBJECT :prime256v1
51:d=1 hl=2 l= 68 cons: cont [ 1 ]
53:d=2 hl=2 l= 66 prim: BIT STRING
So, I guess my questions are
- Is there anything I am missing?
- Or is this a known bug?
- Is there anyway to get around it?