Die Reinitialisierung der Chiffre ist nicht so langsam. Das Erstellen des Schlüssels selbst ist wegen der Iterationszahl langsam.
Außerdem wird der Iterationszähler ignoriert und niemals bei der Verschlüsselung selbst verwendet, sondern nur bei der Schlüsselgenerierung. Die JCE API ist je nach gewähltem Algorithmus irreführend.
Da Kryptographie in Java ziemlich ... kryptographisch ist, kämpfe ich um einige Optimierungen. Im funktionalen Aspekt funktioniert diese Klasse sehr gut und ich hoffe, sie dient als Beispiel für die Verwendung der AES-Verschlüsselung
Ich habe ein Leistungsproblem beim Verschlüsseln und Entschlüsseln von Daten mit AES-Implementierung von BouncyCastle (ich vergleiche das nicht, das ist die einzige Implementierung, die ich getestet habe). Eigentlich ist dieses Problem generisch für jede Chiffre, die ich verwenden möchte.
Das Hauptproblem ist: Kann ich die vollständige Neuinitialisierung der beiden Chiffren pro Verschlüsselungs- / Entschlüsselungsanruf vermeiden? Sie sind zu teuer
Beachten Sie bitte, dass im folgenden Code die Ausnahmebehandlung entfernt wurde und viele Vereinfachungen vorgenommen wurden, um den Fokus auf das Problem zu richten. Die synchronisierten Blöcke sind da, um die Thread-Sicherheit zu gewährleisten
Übrigens, Feedbacks zu irgendeinem Teil des Codes sind willkommen
Thx
%Vor%Die Reinitialisierung der Chiffre ist nicht so langsam. Das Erstellen des Schlüssels selbst ist wegen der Iterationszahl langsam.
Außerdem wird der Iterationszähler ignoriert und niemals bei der Verschlüsselung selbst verwendet, sondern nur bei der Schlüsselgenerierung. Die JCE-API ist je nach gewähltem Algorithmus irreführend.
Über das Salz: Das Hinzufügen eines Salzes zur einfachen Nachricht ist völlig unnötig. Was ich wirklich verwenden sollte, um Zufälligkeit bei jeder Verschlüsselung zu erreichen, ist die Verwendung eines zufälligen Initialisierungsvektors, der nach der Verschlüsselung wie der Salz an den Chiffretext angehängt oder vorangestellt werden kann.
Sie haben kein Glück. Wenn Sie jedes Mal ein neues Salz auswählen, bedeutet dies, dass Sie jedes Mal einen neuen Schlüssel für die Verschlüsselung / Entschlüsselung verwenden, was bedeutet, dass Sie jedes Mal init aufrufen müssen.
Wenn Sie etwas schneller wollen, salzen Sie einfach Ihre Nachricht:
%Vor%Auf diese Weise verwenden Sie jedes Mal denselben Schlüssel, sodass Sie ihn nicht erneut initialisieren müssen. (Verwenden Sie nicht PBE, verwenden Sie einfach 128 Bit AES / CBC). Es ist schwer zu wissen, ob dies für Ihre Bedürfnisse angemessen ist, ohne zu wissen, wie Sie diese Verschlüsselung in der realen Welt anwenden möchten.
ps. ITERATIONS == 120000? Kein Wunder, dass es so langsam ist.
Wenn Sie nur Daten übertragen und diese im Flug verschlüsselt werden müssen, verwenden Sie TLS / SSL. Sein Weg schneller und wird nicht brechen.
Stellen Sie sicher, dass Sie eine Authentifizierung für Ihren Chiffretext verwenden. Verwenden Sie entweder einen MAC oder besser AES im GCM- oder CCM-Modus. Ansonsten ist die Verschlüsselung unsicher.
Was Ihre Frage angeht: Ja, es ist reparierbar. Erzeugen Sie den Schlüssel einfach einmal und verwenden Sie ihn erneut. AES kann verwendet werden, um mehrere Nachrichten mit demselben Schlüssel zu senden. Also leite einfach den Schlüssel / Cipher ab und benutze ihn weiter.
Stellen Sie sicher, dass Sie für jede Nachricht eine neue IV verwenden.
Tags und Links java performance cryptography salt aes