wake-up-neo.net

Java-Standard-Crypto/AES-Verhalten

Weiß jemand, wofür das Standardverhalten von Java-Krypto gilt:

SecretKeySpec localSecretKeySpec = new SecretKeySpec(arrayOfByte, "AES");
Cipher localCipher = Cipher.getInstance("AES");

Insbesondere möchte ich verstehen, wie diese Klassen die IV generieren, und wie der Standardverschlüsselungsmodus ist, wenn Sie einfach "AES" angeben. Vielen Dank.

30
wuntee

Für Oracle JDK 7 (getestet) ist AES/ECB/PKCS5Padding die Standardverschlüsselung für AES. Die Java-Sicherheitsdokumentation erwähnt dies jedoch nicht (http://docs.Oracle.com/javase/6/docs/technotes/guides/security/StandardNames.html#algspec). Um dies herauszufinden, müssen Sie einige JUnit-Tests durchführen .

31
bratan

Diese Angaben sind anbieterspezifisch und die Verwendung des Standardmodus und der Auffüllung kann sehr gefährlich sein. Wenn Sie an den Werten interessiert sind, die der Standardanbieter derzeit mit Java gebündelt hat, müssen Sie den Quellcode für den betreffenden Algorithmus ermitteln. Die Standardwerte, die es für den RSA-Algorithmus verwendet, sind beispielsweise hier . Das Referenzhandbuch Java ™ Cryptography Architecture (JCA) enthält einige Informationen, die einige andere Fragen beantworten könnten.

10
laz

Die Details sind anbieterspezifisch. Das JCA-Referenzhandbuch sagt Folgendes:

(Erstellen eines Cipher-Objekts) Wenn kein Modus oder Auffüllen angegeben ist, werden anbieterspezifische Standardwerte für den Modus und das Auffüllschema verwendet. Beispielsweise verwendet der SunJCE-Anbieter ECB als Standardmodus und PKCS5Padding als Standardauffüllschema für DES-, DES-EDE- und Blowfish-Chiffren. Dies bedeutet, dass im Fall des SunJCE-Providers Cipher.getInstance ("DES") und Cipher.getInstance ("DES/ECB/PKCS5Padding") äquivalente Anweisungen sind.

Ich würde immer die vollständige Form (Algorithmus/Modus/Padding) verwenden, nicht nur, weil ich der Meinung bin, dass das Auslassen solcher "Details" bei der Implementierung eine schlechte Praxis ist, sondern auch, um einen vom ausgewählten Anbieter unabhängigen Chiffretext zu erreichen verschlüsselt für die Speicherung/Übertragung, dann kann man nicht sicher sein, dass derselbe Provider später/am anderen Ende verwendet wird.

9
Javier

Das hängt von den Anbietern ab. Unterschiedliche Anbieter können unterschiedliche Standardparameter haben. Dies ist der Link zu Java 8. 

https://docs.Oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SUNProvider

Die Factory-Methode Der Methode javax.crypto.Cipher.getInstance (String transformation) generiert Chiffren mithilfe von Transformationen der Form Des Algorithmus/mode/padding. Wenn der Modus/das Padding weggelassen wird, verwenden die SunJCE-Provider Und SunPKCS11 die EZB als Standardmodus und PKCS5Padding Als Standardauffüllung für viele symmetrische Chiffren.

Es wird empfohlen, Transformationen zu verwenden, die den Algorithmus, den Modus und das Auffüllen von Vollständig angeben, anstatt sich auf die Standardwerte zu verlassen.

Hinweis: Die EZB funktioniert gut für einzelne Datenblöcke und kann Parallelisiert werden, sollte aber im Allgemeinen nicht für mehrere Blöcke von Daten verwendet werden.

Daher sollten Sie nicht nur AES verwenden, sondern den Modus und das Auffüllen angeben. Obwohl die getInstance-Methode einen anderen Parameter für den Provider enthalten kann, wird dies nicht empfohlen, da 

anwendungen sind an bestimmte Anbieter gebunden, die bei anderen Java-Implementierungen möglicherweise nicht verfügbar sind

0
Qiuxiang Dong