Separa la chiave pubblica e privata per CE

3

I nostri architetti stanno provando a utilizzare la crittografia asimmetrica non standard utilizzando la crittografia. Vogliono che le chiavi pubbliche e private siano private. Significa che abbiamo 2 sistemi: 1 ° sistema che funziona solo sulla crittografia dei dati e 2 ° - funziona solo sulla decrittografia dei dati. Entrambi i sistemi hanno una parte diversa della chiave. In base abbiamo EC alg e sistemi su JAVA.

Algoritmo asimmetrico, significa che crittografate con una chiave pubblica e decifrate con il privato. Ma nel keystore non possiamo memorizzare la chiave privata senza il pubblico. (Pubblico senza privato va bene, è come il truststore). Ho provato a convertire il keystore in p12 e fare openssl pkcs12 -in yourP12File.p12 -nocerts -out privateKey.pem

Dopo:

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 questa chiave privata vedo la chiave pubblica (riflessione) e posso estrarla. Anche il comando openssl ec -in privkey.pem -pubout > key.pub funziona bene. Un modo, che vedo, se leggiamo la chiave privata da jks, non contiene il pubKey. E possiamo serializzarlo su Serializable java e salvarlo. È un buon metodo per salvare separatamente la chiave pubblica e privata?

    
posta Ilya K. 26.01.2016 - 20:50
fonte

1 risposta

5

È molto rischioso utilizzare in modo non standard le funzioni di crittografia. Tutti i tipi di problemi sottili tendono a insinuarsi; i problemi con gli strumenti esistenti sono solo alcuni di essi.

Presumibilmente, questo design è stato scelto per garantire sia la riservatezza che l'autenticità. Una soluzione migliore sarebbe avere due coppie di chiavi: una appartenente all'origine dei dati, l'altra al destinatario. Ciascuno dovrebbe condividere la propria chiave pubblica e mantenere la propria chiave privata segreta. Durante la creazione dei dati, il mittente crittografa con la chiave pubblica del destinatario e quindi firma i dati crittografati con la propria chiave privata. Il ricevitore dovrebbe prima verificare la firma e quindi decrittografare.

Questa soluzione fornirà sia riservatezza che autenticità mentre funziona perfettamente con gli strumenti e le aspettative esistenti.

    
risposta data 26.01.2016 - 21:02
fonte

Leggi altre domande sui tag