Separate public and private key for EC

Question

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

After:

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?

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.