Lächerlich schlechte Leistung mit OpenSSL AES/GCM auf Raspberry PI 2

Question

Ich entwickelte ein einfaches C++ - Programm, um die Leistung von OpenSSL AES/GCM-Aufrufe an die EVP-Schnittstelle Benchmarks. Er nimmt eine 1024-Byte-Zeichenfolge, verschlüsselt sie mit einem Schlüssel und verschlüsselt das Ergebnis dann mit demselben Schlüssel und immer wieder. Ich verwende inkrementelle 4-Byte-Initialisierungsvektoren.

Als ich es auf meinem MacBook Pro (Intel i7) getestet habe, war das Ergebnis ziemlich beeindruckend: Es dauerte genau eine Sekunde, um 1048576 Iterationen des obigen Verfahrens auf einem einzigen Kern auszuführen. Das ist 1 GB/s Verschlüsselungsgeschwindigkeit. 8 GB/s (mehr oder weniger) wenn wir alle Kerne gleichzeitig nutzen.

Jetzt habe ich den gleichen Benchmark auf einem Raspberry PI 2 portiert. Als ich es aber lief, dauerte es 0,16 Sekunden, um 1024 Iterationen zu machen. Das sind mehr oder weniger 6 MB/s auf einem einzelnen Kern.

Jetzt verstehe ich natürlich, dass es einen riesigen, riesigen Unterschied zwischen einem modernen, teuren i7-Prozessor und dem kleinen ARM-Prozessor gibt, der auf einem Raspberry läuft, aber immer noch 170 mal schneller. Also, bevor angenommen, dass Raspberry PI 2 ist wirklich so schlecht, ich wollte überprüfen, ob diese Parameter vernünftig sind.

Hat jemand eine Art Benchmark dazu gemacht? Sind Verschlüsselungsgeschwindigkeiten von 6 MB/s auf einem Raspberry vernünftig? Oder mache ich etwas falsch?

(Ich betreibe es über mein Macbook USB: könnte das so langsam sein, weil es nicht genug Strom bekommt? Das klingt definitiv nicht vernünftig. Es würde überhaupt nicht einschalten, richtig? Oder könnte es sein ein Downclocking-Mechanismus, um Energie zu sparen?)

UPDATE 1: Ich habe openssl -evp speed aes-256-cbc auf meinem Macbook und der Himbeere.

auf dem MacBook:

type    16 bytes  64 bytes 256 bytes 1024 bytes 8192 bytes 
aes-256-cbc  534591.95k 564057.62k 566522.81k 570717.87k 574876.33k 

Auf der Himbeere:

type    16 bytes  64 bytes 256 bytes 1024 bytes 8192 bytes 
aes-256-cbc  14288.53k 16653.74k 17165.31k 17298.43k 17337.00k 

Das ist immer noch ein Faktor 33, aber der Intel-Prozessor kann die Verwendung von Hardware macht beschleunigte AES nennt. Trotzdem, so weit ich weiß, sollte der GCM-Modus ziemlich schneller sein als CBC. Ich weiß nicht, warum, aber sieht aus wie es kein OpenSSL Benchmark Recht für GCM ist, aber selbst wenn sie durchführen identisch ich einen Faktor fehle 3.

UPDATE 2 Diese Seite überprüft: http://elinux.org/RPi_Performance#OpenSSL. Sieht so aus, als ob mir 10 MB/s mehr fehlen. Gesamtsumme: 27 MB/s mit AES/CBC (wie es sein sollte) vs 6 MB/s mit AES/GCM (wie es tatsächlich ist).

Answer 1

Wenn Sie es nicht bereits erklärt haben, warum sollte der Faktor 3 nicht mit dem Faktor von ungefähr 3 Unterschied in der Verarbeitungsleistung erklärt werden?

Raspberry Pi 2 hat einen 900 MHz Prozessor, und ein typischer i7-Prozessor hat 2,8 GHz, was dazu führt, dass der Pi etwa ein Drittel der Rechenleistung hat.

Auch ich weiß nicht, wo Sie die Schlussfolgerung erhalten, dass GCM unter diesen Umständen schneller als CBC sein sollte. CBC bietet keine Authentifizierung, so dass GCM alleine messbar langsamer sein sollte (obwohl vielleicht nicht der Faktor 4, den Sie sehen).

Natürlich, das geht aus dem Fenster, wenn Sie mehrere Kerne bringen, da CBC nicht parallelisiert werden kann und GCM kann.

Answer 2

Ihre Intel-CPU verfügt über dedizierte Hardware-Unterstützung mit der AESNI-Erweiterung. Wenn Sie ohne das kompilieren, erhalten Sie ca. 250MB/s Dieser Unterschied in der Leistung klingt vernünftig. (Und wie viel GHz eine CPU hat, sagt nichts über die Leistung, außer es ist genau der gleiche CPU-Typ nur mit anderen Takt)