Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book
Diffie-Hellman fail – NSA łamie 2/3 globalnego ruchu VPN i 1/4 połączeń SSH?
Algorytm Diffie-Hellman key exchange – to jeden z głównych asymetrycznych algorytmów kryptograficznych wykorzystywanych choćby w HTTPS, IPsec, czy SSH.
W skrócie, algorytm umożliwia dwóm stronom komunikacji na uzgodnienie bezpiecznego klucza sesji (symetrycznego) i szyfrowanie dalej tym kluczem.
Niedawno okazało się, że sam algorytm (czy raczej popularny sposób jego implementacji w połączeniu z często domyślnym 1024 bitowym kluczem) ma poważne wady. [Gładkie wprowadzenie tutaj, pełna praca tutaj]. Jak piszą autorzy cytowanej wyżej pracy:
Breaking a single, common 1024-bit prime would allow NSA to passively decrypt connections to two-thirds of VPNs and a quarter of all SSH servers globally. Breaking a second 1024-bit prime would allow passive eavesdropping on connections to nearly 20% of the top million HTTPS websites.
Koszt takiej maszyny łamiącej badacze szacują na kilkaset milionów dolarów. Ale jednorazowa inwestycja tego typu umożliwia łamanie ww. ilości ruchu niemal w trybie rzeczywistym…opłaca się?
–Michał Sajdak
Zwróci się po roku.
Przeliczyłem, break-even wyszedł mi po 8 miesiącach.
Nie doliczyłeś kosztów utrzymania trefnego warzywniaka…
https://zaufanatrzeciastrona.pl/post/bruce-schneier-zmienil-dlugosc-klucza-pgp-my-tez-powinnismy/
Ja już od dawna korzystam z kluczy ponad 4k bit :)
8k jeszcze spoko, ale przy 16k również odbierający wiadomość musi mieć zmodyfikowany GPG :) Domyślne ustawienia nie przewidują alokacji tak dużej ilości pamięci :)
Przydałby się tutorial jak sprawdzić ile bitów mają klucze oraz jak wygenerować lepsze klucze i ich używać.
Bardzo proszę:
$ openssl rsa -in .ssh/klucz.key -text -noout | grep Private-Key
Private-Key: (4048 bit)
Ale to RSA, nie DH ;)
Raczej np. openssl dhparam -out dhparam.pem 2048
Kilka tygodni temu NIST wydał publikacje o zbliżającej się konieczności przejścia na ECC. W świetle tego newsa nie ma co czekać…
Hola, czy przypadkiem ECC nie opiera bezpieczeństwa na doborze kliku kluczowych stałych? I czy „przypadkiem” tych stałych nie ustaliło NIST, ściśle przecież współpracujące z NSA?
I czy „zupełnie hipotetycznie” NSA nie mogłoby dobrać takich stałych, w których leży tylko im znana słabość, pozwalająca na łatwiejsze łamanie szyfru? :>
Tak wspominają duży problem z zahardkodowaniem stałych liczb pierwszych do DH w b. wielu miejscach (implementacjach). Łamiesz jeden raz i działasz do oporu…
Najpopularniejsze obecnie krzywe, tj P-256 i P-384 (NSA Suite B) faktycznie nie są zbyt wysokiej jakości i jest spora szansa, że są exploitowalne przez NSA. Ale na horyzoncie mamy Curve25519 i Curve448 (wymienione w kilku draftach IETF), w których dotychczasowe analizy żadnych słabości nie wykazały.
Więcej info:
https://tools.ietf.org/html/draft-ietf-tls-curve25519-01
https://tools.ietf.org/html/draft-irtf-cfrg-curves-11
http://safecurves.cr.yp.to/
Z krzywymi eliptycznymi jest chyba tak, że patent na przytoczone przez Ciebie algorytmy posiada BlackBerry
E tam, żadna sensacja i w zasadzie można łatwo wywnioskować z tego, o czym mówią dostawcy – jednym z dowodów może być np. FAQ dla przeglądarek w mobilnych. Laura wyraźnie o tym mówi i ostrzega… :)