Was ist falsch mit IBM JCE-provider?
Ich habe eine JCE-test, der funktioniert mit allen Sun-JDKs, habe ich versucht, scheitert aber mit verschiedenen IBM-J9 JDKs (z.B. 1.6.0 build pwi3260sr8-20100409_01(SR8)). Die Ausnahme unten passiert, wenn der cipher initialisiert wird in den verschlüsseln Modus. Warum können die IBM JCE nicht mit seinem eigenen privaten Schlüssel? Bin ich etwas fehlt in meinem code?
public void testBasicKeyGeneration() throws NoSuchAlgorithmException,
NoSuchPaddingException, InvalidKeyException, IllegalBlockSizeException,
BadPaddingException, NoSuchProviderException, SignatureException {
KeyPairGenerator generator = KeyPairGenerator.getInstance( "RSA" );
generator.initialize( 2048 );
KeyPair pair = generator.generateKeyPair();
String data1 = "123456789012345678901234567890123456789012345678901234567890";
Cipher cipher = Cipher.getInstance( "RSA" );
cipher.init( Cipher.ENCRYPT_MODE, pair.getPrivate() );
byte[] encrypted = cipher.doFinal( data1.getBytes() );
cipher.init( Cipher.DECRYPT_MODE, pair.getPublic() );
byte[] decrypted = cipher.doFinal( encrypted );
String data2 = new String( decrypted );
assertEquals( "en/decryption failed", data1, data2 );
}
Hier ist der stack trace:
java.security.InvalidKeyException: Private key cannot be used to encrypt.
at com.ibm.crypto.provider.RSA.engineInit(Unknown Source)
at javax.crypto.Cipher.a(Unknown Source)
at javax.crypto.Cipher.a(Unknown Source)
at javax.crypto.Cipher.init(Unknown Source)
at javax.crypto.Cipher.init(Unknown Source)
at test.Test.testBasicKeyGeneration(LicenseHelperTest.java:56)
Einfach nur neugierig, was passiert, wenn man Schalter um und tun das verschlüsseln mit dem öffentlichen Schlüssel und die Entschlüsselung mit dem privaten Schlüssel? Normalerweise muss man das nicht verschlüsseln mit Ihrem privaten Schlüssel, weil jeder mit dem public-key entschlüsseln konnte. Es würde mich nicht Wundern, wenn IBM davon ausgegangen, eine Politik zu verschlüsseln, die nur mit einem öffentlichen Schlüssel signieren mit dem privaten Schlüssel und dann einbetten, dass in Ihrem code. Long shot, aber neugierig, was Sie finden.
Funktioniert wie ein Charme, wenn ich das tun, was Sie vorgeschlagen. Ich denke, meine Logik habe gewechselt, weil ich verschlüsseln Lizenzen und nicht wollen, um die privaten Schlüssel in der software ausgeliefert. Wenn Sie setzen, dass in einer Antwort, die ich akzeptieren kann.
C: Wäre das nicht gerade als effektiv erwiesen, indem er eine Nachricht verschlüsselt wurde mit dem öffentlichen Schlüssel? (Zugegeben, es kann immer noch sein vor-definierte Protokolle, die es tun, wie du beschreibst...)
Funktioniert wie ein Charme, wenn ich das tun, was Sie vorgeschlagen. Ich denke, meine Logik habe gewechselt, weil ich verschlüsseln Lizenzen und nicht wollen, um die privaten Schlüssel in der software ausgeliefert. Wenn Sie setzen, dass in einer Antwort, die ich akzeptieren kann.
C: Wäre das nicht gerade als effektiv erwiesen, indem er eine Nachricht verschlüsselt wurde mit dem öffentlichen Schlüssel? (Zugegeben, es kann immer noch sein vor-definierte Protokolle, die es tun, wie du beschreibst...)
InformationsquelleAutor FelixM | 2011-02-02
Du musst angemeldet sein, um einen Kommentar abzugeben.
Ich weiß nicht, dies für sicher, aber ich glaube, dass der JCE hat eine integrierte Politik der Begrenzung der Verschlüsselung den öffentlichen Schlüssel und die Entschlüsselung der private Schlüssel.
In der Beispiel-code war die Verschlüsselung erfolgt mit dem privaten Schlüssel. Dies würde erfordern, die öffentlichen Schlüssel zu entschlüsseln, was bedeutet, dass jeder mit dem öffentlichen Schlüssel auf die verschlüsselten Daten. Obwohl dieser es nutzt, es ist nicht akzeptierten Muster und die IBM-Implementierung kann "Schutz" Sie von versehentlich erstellen von verschlüsselten Daten, die öffentlich lesbar.
Die Tatsache, dass es getestet richtig, wenn diese rückgängig gemacht wurden tendenziell bestätigen meinen Verdacht, aber ich habe noch keine gefunden, die ein offizielles Dokument besagt, wie viel.
InformationsquelleAutor T.Rob
Gibt es eine Lösung, siehe http://www-01.ibm.com/support/docview.wss?uid=swg1IV18625
mit der Eigenschaft
können Sie verwenden private Schlüssel zum verschlüsseln von Daten.
InformationsquelleAutor Peter Heuchert
IBM besteht der private Schlüssel können nicht verwendet werden für die Verschlüsselung und öffentliche Schlüssel können nicht verwendet werden, für die Entschlüsselung, so dass Sie entweder sehen diese künstliche Beschränkung als feature, oder ist jemand ernsthaft verwirrt hier.
Hier ist, wie ich gearbeitet, um dieses problem:
Im wesentlichen habe ich eine public-key-Objekt mit dem private key der crypto-material. Sie müssen Umgekehrt Vorgehen und erstellen Sie eine private key-Objekt mit public-key - Krypto-material, das zu entschlüsseln mit public key-wenn Sie möchten, um zu vermeiden, die "Public-key kann nicht verwendet werden, zu entschlüsseln" Ausnahme.
InformationsquelleAutor Val
Ich habe vor kurzem lief in das gleiche problem. Diese wurde letztendlich gelöst, indem Sie die Hüpfburg Umsetzung und hinzufügen dieser Zeile in java.Sicherheit Datei
Sicherheit.Anbieter.1=org.bouncycastle.jce.Anbieter.BouncyCastleProvider
InformationsquelleAutor bacon
@T. Rob bemerkte, dass Sie vielleicht einen Fehler gemacht haben, in die Verschlüsselung mit dem privaten Schlüssel. Wenn "jeder" kennt den öffentlichen Schlüssel, dann kann jeder entschlüsseln Sie Ihre Datei. IBM JCE Verhalten ist somit der Schutz des Menschen vor diesem Fehler.
Ich kann die Logik.
Allerdings kann es Fälle geben, in denen Sie wirklich brauchen, zu verschlüsseln mit dem privaten Schlüssel; z.B. als Teil eines Protokolls, muss beweisen, dass Sie wissen, dass den privaten Schlüssel entsprechend einer veröffentlichten öffentlichen Schlüssel.
Ob es wirklich das ist, was Sie tun möchten, müssen Sie wahrscheinlich verwenden Sie eine aktuelle Sun JCE-Implementierung (ältere Sun-JCEs nicht umsetzen RSA), oder Hüpfburg.
Ich würde sagen, es ist eine absichtliche Funktion.
C - ich bin damit einverstanden, dass es absichtlich ist, aber es könnte noch ein bug 😉
Gegeben, dass sowohl IBM API-doc ist nur eine Kopie von Sonne und beide angeben, dass Cipher.init() nimmt einen Wert vom Typ Key (im Gegensatz zu PrivateKey oder PublicKey) ich bin Neigung in Richtung bug als auch. Wenn es nicht dokumentiert und es funktioniert nicht wie angegeben...
senden Sie eine bug-Bericht. Wenn IBM stimmt, ist es ein Fehler und behebt Sie, dann haben Sie etwas erreicht. Aber ich bezweifle, dass Sie werden.
InformationsquelleAutor Stephen C
@Stephen C /@FelixM: IBM scheint zu sein, völlig ahnungslos darüber, wie RSA-Kryptographie funktioniert und wie es verwendet werden soll. Im Grunde beide Operationen (verschlüsseln /entschlüsseln) verfügbar sein muss, für den öffentlichen UND privaten Schlüssel.
Verschlüsseln mit public key benötigt wird, zu übertragen, der client-seitige Teil des pre-master-secret SSL/TLS handshakes. Muss der server entschlüsselt mit seinem privaten Schlüssel. Aber wenn Sie verhandeln so etwas wie ECDHE_RSA der server benötigt, um die ZEICHEN teilen der handshake mit dem privaten Schlüssel, das verschlüsseln mit PrivateKey. Umgekehrt muss der client entschlüsselt mit dem öffentlichen Schlüssel aus dem Zertifikat des Servers überprüfen, der hash-Wert der Signatur. (Nachweis der Authentizität der Nachricht)
Also, wenn ich versuche zu laufen ECDHE_RSA (server-side) auf den neuesten IBM JDK 7 passiert Folgendes:
Wie Sie sehen können wir mit Hilfe der "Signatur" und rufen Sie "initSign", das erfordert in der Tat ein PrivateKey. Dies beweist, dass IBM als ahnungslos über diese Tatsache und offensichtlich ist Sie gar nicht
gültige regression tests!
Verwenden Sie ein anderes crypto provider und glaube nicht, dass IBM bis Sie Ihre Meinung ändern.
Beste Grüße,
Christian
InformationsquelleAutor Christian Kahlo