AES-NI-Interna standardmäßig aktiviert?

Oracle hat dies zu sagen über die Java 8 mit Bezug auf AES-NI:

Hardware-Interna Hinzugefügt wurden, verwenden Advanced Encryption Standard
(AES). Die UseAES und UseAESIntrinsics flags zur Verfügung, um
die hardware-basierte AES-Interna für Intel-hardware. Die hardware
muss 2010 oder neuer Westmere-hardware. Zum Beispiel, um
hardware-AES, verwenden Sie die folgenden flags:
-XX:+UseAES -XX:+UseAESIntrinsics
Zu deaktivieren Sie die hardware-AES verwenden Sie die folgenden flags:
-XX:-UseAES -XX:-UseAESIntrinsics

Aber es zeigt nicht an, wenn AES systeminterne Funktionen sind standardmäßig aktiviert (für Prozessoren, die dies unterstützen). Die Frage ist also einfach: wenn der Prozessor unterstützt AES-NI, sind AES-Interna verwendet?

Bonus-Frage: gibt es eine Möglichkeit zu testen, wenn die AES-NI verwendet wird? Ich denke, man kann erraten, basierend auf der Leistung, aber das ist nicht eine optimale oder sicher Feuer Möglichkeit zu testen.

Für Leser, die nicht vertraut sind mit AES-NI-Interna: es ersetzt byte-code, der mit der vor-kompilierten Maschinencode, mit dem AES-NI-Befehlssatz. Dies geschieht durch die JVM, so dass es nicht zeigen, bis in der API von der Java-Laufzeit-oder bytecode.

InformationsquelleAutor Maarten Bodewes | 2014-04-14

The flag ist standardmäßig auf true und wird false, wenn die Erkennung fehlschlägt, so können Sie einfach +PrintFlagsFinal um zu sehen, ob es verwendet wird:

Mein Laptop ohne AES-NI:

C:\>"C:\Program Files\Java\jdk1.7.0_51\bin\java" -XX:+PrintFlagsFinal -version | find "UseAES"
     bool UseAES                                    = false           {product}
     bool UseAESIntrinsics                          = false           {product}
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)

Gleiche auf dem Desktop - mit AES-NI:

C:\>"C:\Program Files\Java\jdk7\bin\java" -XX:+PrintFlagsFinal -version | find "AES"
     bool UseAES                                    = true            {product}
     bool UseAESIntrinsics                          = true            {product}

java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)

C:\>"C:\Program Files (x86)\Java\jre7\bin\java" -XX:+PrintFlagsFinal -version | find "AES"
     bool UseAES                                    = true            {product}
     bool UseAESIntrinsics                          = true            {product}

java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) Client VM (build 24.51-b03, mixed mode, sharing)

So, es funktioniert für x64 und i686 (WOW64) mit der neuesten Java-7. Die Funktion wurde eingeführt, mit https://bugs.openjdk.java.net/browse/JDK-7184394 und mehr auf 7u40 und 7u45.

Wichtig: AES-NI können nur auf der server VM.

Dies wurde bestätigt durch Oracle nach einen bug-report eingereicht wurde. Diese wichtige information fehlte, wenn Sie erstellt die Eigenschaften Liste von Java 8, wo es eingeführt wurde (später bekam zurück portiert auf 7 als auch). Die server-VM ist explizit definiert durch die Bereitstellung der -server option auf die java oder javaw Befehlszeile.

InformationsquelleAutor

4

Nicht kommentieren (SO dumm Regeln mehr als 50 credits erforderlich!). Dieser mailthread von openjdk sagt, alle AES systeminterne Funktionen sind standardmäßig aktiviert. Obwohl ich nicht sicher bin, wie viel von der Oracle core-VM-code Aktien mit openjdk.
Wenn du den ganzen thread durchgelesen, auch Sie diskutieren über die Herausforderungen, die auf 32-bit-VMs, das erklärt wahrscheinlich dein problem mit deinem zweiten Testlauf.
- Über Ihre test (sorry, kann nicht Kommentar), Sie glaube nicht, dass die Unterschiede der CPUs, einen großen Unterschied machen? Core i7 sind quadcore und bessere Taktraten im Allgemeinen. Wäre das nicht einen Unterschied gemacht ? Ich denke, dass die Verschiebung von 21s (core i5, 32bitVM, AES-NI off) an 8s (core i7, 64bitVM, AES-NI off") wird der Unterschied zwischen i5 und i7.
- Die Verbesserung von 8s bis 3s, zwar nicht um das 7-fache, ist in der Tat Wert, ein "Yipes'! 🙂
- Bezüglich der detection-Mechanismus - es scheint nicht, eine einfache Möglichkeit. Die JVM wirft eine Warnung aus "AES-Interna nicht verfügbar für diese CPU", wenn Sie aktiviert die Flaggen, und wenn Sie nicht finden können, die AES-Unterstützung - laut diesem bug-report.
- AES-CBC ist streng linear in der Natur, so dass mehrere Kerne spielen keine Rolle (und natürlich habe ich die Ausführung mit einem task-scheduler oder oben aktiviert). Darüber hinaus ist der i5 kann ich deutlich sehen, dass es keinen Unterschied im Hinblick auf die performance, aktiviert oder deaktiviert werden. Schließlich scheint es, dass die alte Suche nach zusätzlichen CPU-Anweisungen gefixt wurde der bug-report. Ich sehe nicht, etwas schlüssig zu erkennen, warum die ältere CPU nicht unterstützt. Mit der 7-fache zu erhöhen: das war Java 8 läuft auf i5, 32-bit und neueren i7-bit. Noch enormen Zuwachs für die gleiche Klasse Byte 🙂
- Ach ja, und der i7 zu führen schien etwa 2x die Geschwindigkeit des i5 für normale Anwendungen (getestet hab ich die C++ - Kompilierung speziell), das ist viel schneller, aber nicht eine 7-fache Lücke, indem es ein langer Weg. Beachten Sie, dass 64-bit-Anwendungen optimiert möglicherweise erhalten Sie eine zusätzlichen beschleunigen. Diese neueren CPU ' s einen Unterschied machen, denke ich.
- Okay. Macht Sinn. In meinen eigenen tests, wird der AES-flags scheint nicht geehrt werden. Keine Frage, die ich aktivieren oder deaktivieren des flags, der Ausführungszeiten, sind die gleichen. Wenn wir also brauchen, ist der eigentliche Unterschied eingeführt, durch die CPU-Unterstützung, vielleicht brauchen wir identische CPUs mit deaktiviert, AES-NI und andere aktivierte. Ein Mann hier hat einige interessante Ergebnisse (nicht java), mit kernel deaktivieren von AES-NI : ask.fedoraproject.org/en/question/29298/... Seine Ergebnisse sind sehr ähnlich (7x in vielen Fällen)
- Mir ist auch aufgefallen, dass java 8 bringt einige Verbesserungen in der Krypto-Bibliotheken. Für kleine tests (1k -, 2k-gepufferte AES-256-Verschlüsselung), die Ausführungszeiten sind 2x als im Vergleich zu java 7.
- Es gibt einen bug-report, dass die Ziele AES-init unter Verwendung der gleichen Schlüssel - wenn der gleiche Schlüssel verwendet, dann ist es nicht erforderlich, um eine Neuberechnung der key-schedule für AES. Aber ich dachte, dass man integriert wurde früher - es würde jedoch erklären, den Unterschied in den Geschwindigkeiten mit Bezug auf zu kleine Puffer - man konnte spielen, um mit Cipher.getInstance() und sehen, ob es einen Unterschied macht, wenn die gleiche Instanz verwendet wird oder nicht.
InformationsquelleAutor user30622

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.