2017-02-22 3 views
-1

EDIT: Die zweite Frage wird nicht mehr benötigt. Das Problem war ein Ergebnis von Auffüllungsproblemen; Das Ändern der Parameter des Cipher zu "RSA/ECB/PKCS1Padding" hat es behoben, das bereits in den anderen verwendeten Ciphers implementiert wurde.Wie verschlüssele ich und sende DES Schlüssel mit RSA privaten Schlüssel und dann öffentlichen Schlüssel in Java?

Für eine Schulaufgabe muss ich zwei Programme in Java erstellen (ein Client und ein Server), die die asymmetrische RSA-Verschlüsselung verwenden, um einen Sitzungsschlüssel zu erstellen und zu vereinbaren, der die DES-Verschlüsselung verwendet. Die letzte Nachricht in der Vermittlungsstelle enthält einen vom Client generierten Schlüssel, der vom privaten Schlüssel des Clients verschlüsselt und anschließend mit dem öffentlichen Schlüssel des Servers erneut verschlüsselt wird. Der Server kann dann die Nachricht unter Verwendung seines privaten Schlüssels entschlüsseln und dann erneut mit dem öffentlichen Schlüssel des Clients entschlüsseln, um den DES-Schlüssel zu erhalten. Die erste Verschlüsselung führt jedoch zu einem Byte-Array der Größe 256, und die zweite Verschlüsselung erfordert ein Byte-Array, das kleiner ist. Gibt es eine Möglichkeit, die Daten so zu manipulieren, dass ich den Schlüssel zweimal verschlüsseln kann, wie in der Aufgabe angegeben? Beachten Sie, dass dies eine Voraussetzung ist, da der DES-Algorithmus für den Sitzungsschlüssel verwendet wird.

Darüber hinaus, abgesehen von der zweiten Verschlüsselung, dass der nächste Teil der Zuordnung, der Client und Server ermöglicht, verschlüsselte Nachrichten an einander zu senden, ein anderes Problem erzeugt. Derzeit wickelt der Client den Schlüssel mithilfe des öffentlichen Schlüssels des Servers um. Anschließend entpackt der Server ihn mithilfe seines privaten Schlüssels. Das Auspacken des Sitzungsschlüssels auf der Serverseite erzeugt jedoch eine InvalidKeyException; Die unverpackte Schlüssellänge beträgt 256 Bytes, was völlig falsch ist.

Auf der Server-Seite, die ich habe:

 byte[] m4 = new byte[256]; 
     datIn.read(m4); 
     cUwp.init(Cipher.UNWRAP_MODE, myKey); 
     ks = (SecretKey)cUwp.unwrap(m4, "DES", Cipher.SECRET_KEY); 
     System.out.println("Recieved key:\n" + ks); 
     try{ 
      Cipher desCipher = Cipher.getInstance("DES"); 
      desCipher.init(Cipher.DECRYPT_MODE, ks); 
     } 
     catch(NoSuchPaddingException|InvalidKeyException e){ 
      System.out.println("Error: " + e); 
     } 

Auf der Clientseite:

 KeyGenerator keygen = KeyGenerator.getInstance("DES"); 
     SecretKey key = keygen.generateKey(); 
     cWrp.init(Cipher.WRAP_MODE, theirKey); 
     byte[] m4 = cWrp.wrap(key); 
     datOut.write(m4); 
     ks = key; 
     try{ 
      Cipher desCipher = Cipher.getInstance("DES"); 
      desCipher.init(Cipher.DECRYPT_MODE, ks); 
     } 
     catch(NoSuchPaddingException|InvalidKeyException e){ 
      System.out.println("Error: " + e); 
     } 

Ich bin keine Größe Diskrepanzen in anderen Teilen meines Codes bekommen; Alle anderen entschlüsselten Nachrichten haben die richtige Größe, aber keiner von ihnen verwendet die Methode wrap(), da es sich um Strings und nicht um SecretKeys handelt. Gibt es etwas, das ich vermisse?

+1

Ich weiß nicht, wer das lehrt, aber DES ist unsicher, PKCS # 1 ist unsicher (wenn Padding-Angriffe zum Beispiel während Transportsicherheit gelten), und Verschlüsselung mit dem privaten Schlüssel - obwohl ähnlich - ist keine Signaturerzeugung. –

Antwort

4

Sie tun das völlig falsch. Die Verschlüsselung muss mit dem Schlüssel public und der Entschlüsselung mit dem privaten Schlüssel erfolgen. Sonst kann es jeder entschlüsseln.

Werfen Sie alles weg und verwenden Sie TLS.

+0

Sie missverstehen. Die Zuweisung besagt explizit, die Nachricht zweimal zu verschlüsseln, einmal mit dem privaten Schlüssel des Absenders und dann mit dem öffentlichen Schlüssel des Empfängers und dann mit dem privaten Schlüssel des Empfängers und dann dem öffentlichen Schlüssel des Absenders zu entschlüsseln. Die erste Verschlüsselung dient als Signatur und die zweite Verschlüsselung bietet die Sicherheit. Darüber hinaus ist TLS keine Option gemäß den Zuweisungsspezifikationen. – Sean

+3

Die Antwort ist richtig. Sie erwähnen, dass Sie mit dem privaten Schlüssel des Clients verschlüsseln und anschließend den öffentlichen Schlüssel des Clients entschlüsseln. So funktioniert RSA nicht. Dies bietet keine Sicherheit. Vielleicht möchten Sie es mit dem privaten Schlüssel des Clients unterschreiben und dann die Signatur mit dem öffentlichen Schlüssel überprüfen? – jackgu1988

Verwandte Themen