Autor: Jan Stożek (jasio_at_nowhere.pl)
Data: Wed 03 Jan 2001 - 00:43:02 MET
On Tue, 2 Jan 2001 10:18:16 Grzegorz Szyszlo
<znik_at_avalon.wbc.lublin.pl> wrote:
> Jan Stożek wrote:
>
> > Dokładnie taki sam. Klient sprawdzając, czy klucz publiczny serwera
> > (który ma) pasuje do klucza prywatnego serwera potwierdza tożsamość
> > serwera,
> > systemy z kluczem publicznym są zbyt wolne do szyfrowania całości
> > transmisji.
>
> ja wiem czy zbyt wolny? cisco na laczu wan 128kbps sie wyrabia :)
A jesteś pewien, że to Cisco rzeczywiście stosuje szyfrowanie kluczem
prywatnym/publicznym, a nie np. 3des z utworzonym ad hoc hasłem? Bo
IPSec, o ile pamiętam, używa kluczy właśnie do potwierdzania
tożsamości, a nie do szyfrowania.
Zresztą - napisałem nieściśle. Oczywiście, można używać systemu
klucza publicznego do szyfrowania, ale ze względu na złożoność
obliczeniową może się okazać, że trzeba w tym celu dość radykalnie
skrócić klucz.
> co do potwierdzenia tozsamosci. niezupelnie jest tak. kucz nie tyle
> potwierdza tozsamosc,
Przecież dalej napisałeś, że jednak tak.... przeczytaj dokładnie.
> klucz prywatny jedynie szyfruje, do deszyfracji sie nie nadaje.
> klucz publiczny tylko deszyfruje, nie da sie nim szyfrowac.
Nadaje się i da się, bo to, który klucz jest prywatny, a który
publiczny to czysta umowa - dla algorytmu są one całkowicie wymienne.
Wiadomość zaszyfrowaną kluczem prywatnym będzie mógł odczytać każdy
posiadacz klucza publicznego "od kompletu" (czyli teoretycznie każdy)
- na tym przecież polega potwierdzenie tożsamości nadawcy (i podpis
elektroniczny, btw): szyfruje się dokument (albo jego wyciąg, żeby
było krócej) kluczem prywatnym, a pomyślne odszyfrowanie dokumentu
(wyciągu) kluczem publicznym oznacza, że nadawca jest tym, za kogo się
podaje. Natomiast wiadomość poufną szyfruje się kluczem publicznym
odbiorcy i tylko odbiorca - mając swój klucz prywatny - będzie mógł ją
odczytać. Chcąc mieć zaszyfrowaną wiadomość z potwierdzoną tożsamością
nadawcy szyfrujesz ją kluczem publicznym odbiorcy i własnym kluczem
prywatnym (to się chyba nawet daje zrobić w jednym kroku, po
zastosowaniu splotu czy jakiejś równie abstrakcyjnej operacji na
kluczach). Odbiorca odszyfrowuje wiadomość swoim kluczem prywatnym i
Twoim kluczem publicznym. Osoby postronne mogą użyć Twojego klucza
publicznego, ale z braku klucza prywatnego odbiorcy mogą Was pocałować
wiadomo gdzie.
> dlatego jesli dwa punkty IP nie sa wzgledem siebie autoryzowane
> np. w takim SSH, to probuja sciagac klucze publiczne od siebie
> nawzajem. tyle ze klient ssh pyta o potwierdzenie zgody, a serwer
> zgadza sie zwykle automatycznie, lub automatycznie sie nie zgadza
> (rzadziej).
A poza tym w czasie kolejnych sesji jeżeli klucz publiczny serwera
się zmieni albo zachowany klucz publiczny nie pasuje do klucza
prywatnego serwera, to klient podnosi wrzask i ponownie pyta o zgodę
na ściągnięcie klucza publicznego. Serwer chyba też może podjąć jakąś
akcję w rodzaju odmówienia zgody na połączenie jeżeli klient zmieni
swoje klucze. Tak przynajmniej jest w SSH (jest to element systemu
zabezpieczeń utrudniający podszywanie się).
> autoryzacja nie polega na ujawnieniu klucza, lecz na mozliwosci
> deszyfracji tego co przekazala druga strona :)
Czyli jednak są używane do potwierdzania tożsamości. A pisałeś, że
nie są. ;)
Ja nie pisałem w jaki sposób jest potwierdzana tożsamość - a w
szczególności o ujawnianiu klucza prywatnego - tylko że tożsamość jest
potwierdzana. Jest dla mnie oczywiste, że klucza prywatnego się nie
ujawnia, a komplementarność klucza prywatnego i publicznego jest
potwierdzana poprzez możliwość poprawnego odszyfrowania wiadomości
(szczegółowo opisał to Adam), a nie poprzez ujawnienie klucza
prywatnego.
Nota bene, ponieważ klucz prywatny różni się od publicznego, to nawet
jeżeli dysponuje się obydwoma kluczami, to żeby sprawdzić czy do
siebie pasują trzeba zrobić próbę szyfrowania (albo wykorzystać
zależności matematyczne pomiędzy nimi, ale nie pamiętam, czy to da
jakiś efekt). Ujawnienie klucza prywatnego po prostu nic nie daje.
-- Pozdrawiam, Jan. PS. Mój adres: nowhere = Polbox.
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 15:29:47 MET DST