Our architects are trying to use non-standard using asymmetric cryptography. They want both the public and private keys kept private. It means we have 2 systems: 1st system working only on encrypting data, and 2nd - working only on decrypting data. Both systems have a different part of the key. In base we have EC alg and systems on JAVA.

Asymmetric algorithm, means than you encrypt with a public key, and decrypt with the private. But in keystore we can not store the private key without the public. (Public without private is fine, it's like truststore). I tried convert the keystore to p12 and do openssl pkcs12 -in yourP12File.p12 -nocerts -out privateKey.pem


PEMParser pemParser = new PEMParser(new FileReader(privateKeyFile));
    Object object = pemParser.readObject();
    InputDecryptorProvider pkcs8Prov = new JceOpenSSLPKCS8DecryptorProviderBuilder().build("password".toCharArray());
    JcaPEMKeyConverter converter = new JcaPEMKeyConverter().setProvider("BC");
    PrivateKey privateKey = null;
    if (object instanceof PKCS8EncryptedPrivateKeyInfo) {
        final PrivateKeyInfo privateKeyInfo = ((PKCS8EncryptedPrivateKeyInfo) object).decryptPrivateKeyInfo(pkcs8Prov);
        privateKey = converter.getPrivateKey(privateKeyInfo);

In this private key I see public key (reflection), and I can extract it. The command openssl ec -in privkey.pem -pubout > key.pub works fine too. One way, that I see, if we read private key from jks, it doesn't contain the pubKey. And we can serialize it to java Serializable and save it. Is this a good method to save the public and private key separately?

  • Hi Ilya, I cleaned up your post's grammar and wording. I assumed parts of what you meant, so if I got something wrong, feel free to edit it again or ask for help :)
    – Ohnana
    Commented Jan 26, 2016 at 19:59
  • sun.security.ec.ECPrivateKeyImpl (or org.bouncycastle.jce.provider.JCEECPrivateKey for BC) from a keystore doesn't expose publickey on the API but it is in the object, and it is there when serialized. But fundamentally this can't work for EC, or any dlog. Even if you create an object with only the privatekey value, the publickey is easily recreated with one point mult, just like a Z_p^* group is with one modexp. This scheme sounds like someone learned a little bit about RSA, where it kind-of-works-but-not-well, and was too clever by more than half. Commented Jan 28, 2016 at 9:09
  • Under the hood I have org.bouncycastle.jcajce.provider.asymmetric.ec.BCECPrivateKey privateKey implementation. In this impl we have field: private transient DERBitString publicKey;
    – Ilya K.
    Commented Jan 28, 2016 at 19:24

1 Answer 1


It is very risky to make non-standard use of encryption functions. All sorts of subtle problems tend to creep in; problems with existing tools being just some of them.

Presumably, this design was chosen to ensure both confidentiality and authenticity. A better solution would be to have two key pairs: one belonging to the originator of the data, the other to the receiver. Each would share their public key and keep their private key secret. When creating data the originator would encrypt with the receiver's public key and then sign the encrypted data with their own private key. The receiver would first verify the signature and then decrypt.

This solution will provide both confidentiality and authenticity while working just fine with existing tools and expectations.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .