Dnia Mon, 06 Feb 2006 15:33:50 +0100, Marek Guevara Braun <[EMAIL PROTECTED]> napisał:
> Są to blokowe algorytmy symetryczne (trzy pierwsze na pewno, RC4 pewnie > też) Arcfour (implementacja otwarta ukrywanego algorytmu RC4). RC4 jet szyfrem strumieniowym - miesza bity z pomieszanym kluczem. > Klucz symetryczny jakoś tam jest wymieniany między klientem a serwerem > (zakładam, że bezpiecznie) Diffie-Hellman? Uzgadnianie kluczy z założeniem, że atakujący ma dostęp do całośći transmisji - niezły bajer BTW. - żeby ktoś mógł odczytać transmitowane dane > musi mieć dostęp do klucza szyfrującego/deszyfrującego - zgadnąć go lub > przechwycić w momencie wymiany przy nawiązywaniu sesji (zakładam, że > sama wymiana jest szyfrowana asymetrycznie, gdzie rolę odgrywają > prywatne klucze serwera - jeśli masz dostęp do kluczy prywatnych serwera > SSH - a tak jest np. w przypadku bootowania systemu z płytki RescueCD - > wyciągnąć klucz symetryczny będzie pewnie łatwiej. Jeżeli uzgadniają klucz do późniejszego szyfrowania symetrycznego przy pomocy Diffiego-Hellmana, to nawet przy przehwyceniu wszystkich danych tej wymiany, klucz pozostaje dla atakującego nieznany. Bezpieczeństwo opiera się na niemożności rozkładu dużych liczb na składniki w postaci liczb pierwszych w czasie wielomianowym - czyli ta sama gwarancja, jaką mają szyfry asymetryczne (RSA o którym piszesz chociażby) > > Same algorytmy szyfrowania mogą być stosowane z różnymi funkcjami > mieszającymi - np ECB lub CBC dla AES-a - dla tej pierwszej dane są > szyfrowane blokami 128-bitowymi przy pomocy klucza lub wybranego/znanego > fragmentu klucza (dla kluczy 192 i 256 bitów) - jeśli mamy w danych np. > jednolite fragmenty, to będą one zaszyfrowane tak samo (ew. będzie można > wychwycić odpowiedni wzorzec) [*] - bodajże dwukrotnie wolniejszy > AES-CBC pozbawiony jest tej cechy, gdyż to czym szyfrowane są kolejne > bloki zależy od zaszyfrowanej postaci poprzedniego bloku - jednolite > obszary danych nie będą szyfrowane do tj samej postaci. E?? ECB i CBC to są tryby szyfrowania blokowego, to nie ma nic wspólnego z funkcją mieszającą (hashującą - to masz na myśli? funkcję skrótu?). OpenSSH na pewno implementuje MD5, które to ostatnio podobno jest łamane na PC-cie w ~15 minut, bodajrze SHA1, ale czy coś > 160 bitowego, to nie wiem. Na prawdę trzeba by się postarać, żeby złamanie tego coś dało - skrót zapewnia tylko integralność, czyli że nikt Ci nie wstrzyknie innych pakietów, a z czsem - niech i nawt będzie 5minutowym, to i tak gówno da, bo nie będzie w stanie proxować połączenia na bierząco. > > Podsumowując - przy transmisji SSH używaj wersji 2.0, sprawdzaj z kim > rozmawiasz - jak najwcześniej rób połączenie tak byś miał publiczny > klucz serwera u siebie, a przy nowym połączeniu sprawdź czy odcisk > klucza serwera, który wyświetli się w okienku PuTTY lub openssh > odpowiada kluczom serwera. Pilnuj kluczy prywatnych serwera oraz > generalnie zabezpiecz serwer :-) Ee - manualna robota. Rządać potwierdzeń certyfikatów przy nawiązywaniu połączenia SSL i automat sprawdzający certyfikaty sam zweryfikuje, czy rozmawiasz, z kim chcesz rozmawiać. SSH w ogóle implementuje wiele innych trików, typu ukrywanie sytuacji ułatwiającej łamanie, jak np. krótkie komunikaty, czy takie same znaki. Do tego renegocjuje klucz do szyfrowania symetrycznego co 1GB/1h (które wcześniej) i wiele innych tego typu tricków. Zdroofka [EMAIL PROTECTED] P.S. A to wszystko w świetle zalanego dziś egzamu z Ochrony Danych (podobnie jak 36 innych osób i tylko 3 zdały ;/), bo profesorowi nie podobała się sala ;/ _______________________________________________ pld-users-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
