Chcemy spełnić pewne wysokie wymagania dotyczące bezpieczeństwa w naszym projekcie i musimy wykonać bardzo wydajne szyfrowanie.Jaka jest różnica wydajności pKI do szyfrowania symetrycznego?
Myślę, że wiem, że PKI jest znacznie wolniejsza i bardziej złożona niż szyfrowanie symetryczne, ale nie mogę znaleźć liczb, które potwierdzają moje uczucia.
Tak, czysto szyfrowanie asymetryczne jest znacznie wolniejszy niż szyfrowaniu symetrycznym (jak DES lub AES), dlatego rzeczywiste aplikacje używają hybrid cryptography: drogie publicznego kluczowe operacje są wykonywane tylko do szyfrowania (i wymiany) klucza szyfrowania dla symetryczny algorytm, który będzie używany do szyfrowania prawdziwej wiadomości.
Problem związany z kryptografią klucza publicznego polega na tym, że nie istnieje żaden wspólny klucz tajny. Dzięki szyfrowaniu symetrycznemu musisz zaufać wszystkim zaangażowanym stronom, aby utrzymać klucz w tajemnicy. Ten problem powinien być znacznie poważniejszy niż wydajność (co można złagodzić za pomocą podejścia hybrydowego).
Użyj polecenia OpenSSL speed, aby przetestować algorytmy i przekonać się samemu.
[[email protected] ~]$ openssl speed aes-128-cbc
Doing aes-128 cbc for 3s on 16 size blocks: 26126940 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 64 size blocks: 7160075 aes-128 cbc's in 3.00s
...
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128 cbc 139343.68k 152748.27k 155215.70k 155745.61k 157196.29k
[[email protected] ~]$ openssl speed rsa2048
Doing 2048 bit private rsa's for 10s: 9267 2048 bit private RSA's in 9.99s
Doing 2048 bit public rsa's for 10s: 299665 2048 bit public RSA's in 9.99s
...
sign verify sign/s verify/s
rsa 2048 bits 0.001078s 0.000033s 927.6 29996.5
Podobno jest 1000 razy gorszy. (http://windowsitpro.com/article/articleid/93787/symmetric-vs-asymmetric-ciphers.html). Ale dopóki naprawdę nie przejmiesz wielu danych, nie będzie to miało znaczenia. Możesz użyć asymetrycznego szyfrowania do wymiany symetrycznego klucza szyfrowania.
Praktyczne systemy szyfrowania oparte na PKI używają szyfrowania asymetrycznego do szyfrowania klucza symetrycznego, a następnie symetrycznego szyfrowania za pomocą tego klucza do szyfrowania danych (powiedziawszy, że ktoś wskaże przykładowy przykład).
Tak więc dodatkowy narzut nakładany przez asymetryczne algorytmy kryptograficzne na algorytm symetryczny jest stały - nie zależy od wielkości danych, tylko od wielkości klucza.
Ostatnim razem, gdy testowałem to, sprawdzanie poprawności łańcucha 3 lub więcej certyfikatów X.509 [edytuj, aby dodać: i dane, które podpisywali] zajmowało ułamek sekundy na ARM działającym z częstotliwością 100 MHz (uśrednione) w wielu powtórzeniach, oczywiście). Nie pamiętam, jak małe - nie znikome, ale dobrze poniżej sekundy.
Niestety nie pamiętam dokładnych szczegółów, ale podsumowanie jest takie, że jeśli nie jesteś w bardzo ograniczonym systemie lub nie używasz dużej ilości szyfrowania (np. Jeśli chcesz przyjąć jak najwięcej połączeń SSL na sekundę) Zatwierdzone przez NIST asymetryczne metody szyfrowania są szybkie.
Być może możesz dodać trochę szczegółów na temat swojego projektu, aby uzyskać lepszą jakość odpowiedzi. Co próbujesz zabezpieczyć? Od kogo? Jeśli potrafisz wyjaśnić wymagania swojego bezpieczeństwa, otrzymasz znacznie lepszą odpowiedź. Wydajność nie znaczy wiele, jeśli mechanizm szyfrowania nie chroni tego, co Twoim zdaniem jest.
Na przykład certyfikaty X509 są standardowym sposobem zabezpieczania punktów końcowych klientów/serwerów. Opancerzenie PGP może być użyte do zabezpieczenia plików licencji. Dla uproszczenia, łączenie bloków kodu z Blowfish (i wieloma innymi szyframi) jest łatwe w użyciu w Perlu lub Javie, jeśli kontrolujesz oba punkty końcowe.
Dzięki.
Na Macbookach z systemem OS X 10.5.5 i wersją magazynu OpenSSL, zegary "prędkości otwierania" AES-128-CBC przy 46 000 1024 bitowych blokach na sekundę. Ta sama skrzynka rejestruje 1024-bitowy RSA z 169 sygnaturami na sekundę. AES-128-CBC to "podręcznikowy" algorytm szyfrowania bloków, a RSA 1024 to "podręcznikowy" algorytm klucza publicznego.To jabłka do pomarańczy, ale odpowiedź brzmi: RSA jest znacznie, dużo wolniej.
Jednak nie powinieneś używać szyfrowania z kluczem publicznym. Oto prawdziwe powody:
operacje na kluczach publicznych kryptograficzne nie są przeznaczone do szyfrowania danych surowych. Algorytmy takie jak Diffie-Hellman i RSA zostały opracowane jako sposób wymiany kluczy do algorytmów kryptograficznych blokowych. Tak więc, na przykład, użyjesz bezpiecznego generatora liczb losowych do wygenerowania 128-bitowego losowego klucza dla AES i zaszyfrujesz 16 bajtów za pomocą RSA.
Algorytmy takie jak RSA są znacznie mniej "przyjazne dla użytkownika" niż AES. Za pomocą losowego klucza blok tekstu jawnego, który wysyłasz do AES, będzie losowy dla każdego bez klucza. Tak naprawdę nie jest tak w przypadku RSA, które jest - bardziej niż AES - tylko równanie matematyczne. Oprócz prawidłowego przechowywania kluczy i zarządzania nimi, musisz być bardzo ostrożny przy formatowaniu bloków zwykłego tekstu RSA lub w przypadku luk.
Klucz publiczny nie działa bez kluczowej infrastruktury zarządzania. Jeśli nie masz schematu do weryfikacji kluczy publicznych, napastnik może zamienić własne klawisze na prawdziwe, aby uruchomić ataki "człowiek w środku". Właśnie dlatego SSL zmusza Cię do przejścia przez rigamarole certyfikatów. Blokowanie algorytmów kryptograficznych, takich jak AES do również cierpi z powodu tego problemu, ale bez PKI, AES jest nie mniej bezpieczna niż RSA.
Operacje kryptograficzne z kluczem publicznym są podatniejsze na więcej luk w implementacji niż AES. Na przykład obie strony transakcji RSA muszą uzgodnić parametry , które są liczbami podawanymi do równania RSA. Istnieją złe wartości, które atakujący mogą zastąpić, aby cicho wyłączyć szyfrowanie. To samo dotyczy Diffie Hellman, a jeszcze bardziej Elliptic Curve. Innym przykładem jest usterka podpisu RSA Signature Forgery, która miała miejsce 2 lata temu w wielu implementacjach SSL o wysokiej jakości.
Korzystanie z klucza publicznego jest dowodem na to, że robisz coś "niezwykłego". Niezwykły jest dokładnie to, co, , nigdy nie chce być z kryptografią; poza zwykłymi algorytmami, crypto projekty są kontrolowane i testowane przez lata, zanim zostaną uznane za bezpieczne.
Do naszych klientów, którzy chcą korzystać z kryptografii w swoich aplikacjach, wykonujemy dwa zalecenia:
dla "danych w spoczynku" użyj PGP. Naprawdę! PGP zostało pobite przez ponad dekadę i jest uważane za bezpieczne od głupich błędów w implementacji. Istnieją jego otwarte i komercyjne warianty.
Dla "danych w locie" użyj TLS/SSL. Żaden protokół bezpieczeństwa na świecie nie jest lepiej zrozumiany i lepiej przetestowany niż TLS; instytucje finansowe wszędzie akceptują to jako bezpieczną metodę przenoszenia najbardziej wrażliwych danych.
Here's a decent writeup [matasano.com] ja i Nate Lawson, profesjonalny kryptolog, napisał nawet kilka lat wstecz. Obejmuje on te punkty bardziej szczegółowo.
Wygląda na to, że Twój link do zapisu nie działa. – skiwi