Opracowałem prosty program w C++ do testowania wydajności wywołań AES/GCM OpenSSL do interfejsu EVP. To, co robi, to pobranie łańcucha o długości 1024 bajtów, zaszyfrowanie go za pomocą klucza, a następnie zaszyfrowanie wyniku za pomocą tego samego klucza i znowu i znowu. Używam inkrementalnych 4-bajtowych wektorów inicjalizacyjnych.Śmiesznie kiepska wydajność z OpenSSL AES/GCM na Raspberry PI 2
Kiedy testowałem to na moim MacBooku Pro (Intel i7), wynik był imponujący: wykonanie jednej operacji 104676 iteracji powyższej procedury zajęło dokładnie sekundę. To szybkość szyfrowania 1 GB/s. 8 GB/s (więcej lub mniej), jeśli wykorzystamy wszystkie rdzenie jednocześnie.
Teraz przeportowałem ten sam test porównawczy na Raspberry PI 2. Kiedy go uruchomiłem, wykonanie 1024 iteracji zajęło 0,16 sekundy. To mniej więcej 6 MB/s, na jednym rdzeniu.
Teraz rozumiem, że istnieje ogromna różnica między nowoczesnym, kosztownym procesorem i7 a małym procesorem ARM, który działa na Raspberry, ale wciąż jest 170 razy szybszy. Tak więc przed założeniem, że Raspberry PI 2 jest naprawdę, że źle, chciałem sprawdzić, czy te parametry są uzasadnione.
Czy ktoś zrobił coś w tym rodzaju? Czy szybkość kodowania 6 MB/s jest rozsądna w przypadku Raspberry? Czy robię coś złego?
(Zasilam go przez mój Macbook USB: czy to może być takie powolne, ponieważ nie otrzymuje wystarczającej mocy?) To z pewnością nie brzmi rozsądnie, w ogóle by się nie włączało, prawda? mechanizm downclockingu, aby zaoszczędzić energię?)
UPDATE 1: Zrobiłem openssl -evp speed aes-256-cbc
zarówno na moim MacBooka, jak i Raspberry.
Na 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
Na Malina:
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-256-cbc 14288.53k 16653.74k 17165.31k 17298.43k 17337.00k
To jeszcze czynnik 33, ale procesor Intel może wykorzystać sprzętowej akceleracji AES nazywa. Mimo to, o ile wiem, tryb GCM powinien być znacznie szybszy niż CBC. Nie wiem dlaczego, ale wygląda na to, że nie jest wyznacznikiem prawo openssl do GCM, ale nawet zakładając, że wykonują identycznie Brakuje mi czynnik 3.
UPDATE 2 sprawdzone strony: http://elinux.org/RPi_Performance#OpenSSL. Wygląda na to, że brakuje mi 10 MB/s więcej. Suma całkowita: 27 MB/s przy AES/CBC (tak jak powinno być) vs 6 MB/s przy AES/GCM (tak jak jest).
Znalazłem to szukając sposobu na zwiększenie wydajności SSH/SCP pi2 . Czy kiedykolwiek uzyskałeś lepszą wydajność? Znalazłem http://www.psc.edu/index.php/hpn-ssh, ale jeszcze do niego nie wpadłem. Chciałbym znaleźć coś niskiego zasilania (nie musi to być pi), aby dać mi SSH wystarczająco szybko, aby przesyłać nisko do średniej defektów z NAS do mojego telefonu. – Nanook
@Naook Naprawdę przepraszam, ale nie zagłębiłem się w to, jeśli dobrze pamiętam. Nie sądzę, żebym kiedykolwiek zdołał osiągnąć ten wynik wyżej, ale nie mam dobrej pamięci. Powodzenia z tym! –
"Nadal, o ile mi wiadomo, tryb GCM powinien być szybszy niż CBC" jest to niepoprawne. CBC potrzebuje tylko X obliczeń szyfrowania, jeśli posiadasz bloki X, podczas gdy GCM potrzebuje (2 * X) + 1 obliczenia blokowe plus trochę matematyki na polach Galouis w międzyczasie. – Shnatsel