Re: SSH

Autor: Jan Stożek (jasio_at_nowhere.pl)
Data: Wed 03 Jan 2001 - 15:42:46 MET


Hej,

On Wed, 3 Jan 2001 07:17:16 Grzegorz Szyszlo
<znik_at_avalon.wbc.lublin.pl> wrote:

> Nastapilo wiele niedomowien, ktore niestety we wszystkich sa
> utwierdzane takze przez dokumentacje. Wiekszosc tego postu
> dotyczy klotni na temat:
> 1. co to znaczy klucz prywatny i publiczny. terminy klucz szyfrujacy
> i deszyfrujacy nie budza watpliwosci, bo w przypadku sesji
> szyfrowania partnerowi dawany jest jeden klucz, a w przypadku
> podpisu elektronicznego (autentykacji) drugi klucz.
> 2. co to znaczy autentyfikacja przez klucze. otoz przez domniemanie
> przyjmuje sie, ze klucze sluza do autentykacji. okazuje sie ze
> autentykacja jest efektem ubocznym mozliwosci zdeszyfrowania
> przychodzacej wiadomosci.

        Może i jest skutkiem ubocznym, ale właśnie w tym celu się ją stosuje.
Zresztą popatrz, co znalazłem na stronie RSA:

---------------- --------------

Public-key cryptography is the technology first identified
by Diffie and Hellman [DH76] in which encryption and
decryption involve different keys. The two keys are the
public key and the private key, and either can encrypt or
decrypt data. A user gives his or her public key to other
users, keeping the private key to himself or herself. Data
encrypted with a public key can be decrypted only with the
corresponding private key, and vice versa.

A public-key algorithm is an algorithm for encrypting or
decrypting data with a public or private key. A private key
is typically used to encrypt a message digest (see Section
2.3); in such an application, the public-key algorithm is
called a message-digest encryption algorithm. A public key
is typically used to encrypt a content-encryption key (see
Section 2.2); in such an application, the public-key
algorithm is called a key-encryption algorithm.

---------------- --------------

> do potwierdzenia tozsamosci takze jest uzywany 3des. poza tym o ile
> mi wiadomo, 3des posluguje sie wlasnie idea klucza
> publicznego/prywatnego.

        To albo ja nie rozumiem 3-desa albo Ty. Zawsze mi się zdawało, że
3DES to jest DES zastosowany trzykrotnie w celu prostego wydłużenia
długości klucza. A DES _nie_ jest systemem szyfrowania z kluczem
publicznym (ze strony RSA):

---------------- --------------

Secret-key cryptography is the technology in which
encryption and decryption involve the same key, a secret
key. Pairs of users share a secret key, keeping the key to
themselves. Data encrypted with a secret key can be
decrypted only with the same secret key.

(...)

The Data Encryption Standard (DES) is the standard federal
secret-key algorithm, described in FIPS PUB 46-1. Cipher-
Block Chaining (CBC) is a mode of DES, described in FIPS PUB
81.

---------------- --------------

        Owszem, do 3DES-a są stosowane dwa klucze, ale są to dwa tajne klucze
DES:

C = DES_K1(DES_K2^-1(DES_K1(M)))

        Czyli tekst jest szyfrowany kluczem 1, "odszyfrowywany" kluczem 2 i
ponownie szyfrowany kluczem 1. Odszyfrowanie oczywiście wymaga
operacji odwrotnych.

        Zresztą można to wydedukować na podstawie analizy długości klucza.
Klucz prywatny i publiczny są związane poprzez pewne zależności
pomiędzy dużymi liczbami pierwszymi. W RSA stosowane są klucze po 1K,
2K, 4K itp. Najkrótszy klucz w PGP miał bodaj 768 bitów i jest uważany
za słaby. Tymczasem DES ma efektywny klucz 56 bitów, a 3DES - 112
bitów. To trochę za mało żeby operować na naprawdę dużych liczbach.

> i tak faktycznie jest. przy generowaniu pary kluczy sesyjnych, procesor
> routera sie bardzo mocno obciaza. w czasie transmisji takze jest
> niezle obciazony (przy 3des bo przy 1des jest spoko). wlasnie do tego
> jest modul VPN ktory ma procesor zajmujacy sie
> szyfrowaniem/deszyfrowaniem,
> aby zdjac obciazenie z procesora glownego.

        Bo szyfrowanie 3DES-em jest trzykrotnie bardziej obciążające od DES.

> > > co do potwierdzenia tozsamosci. niezupelnie jest tak. kucz nie tyle
> > > potwierdza tozsamosc,
> >
> > Przecież dalej napisałeś, że jednak tak.... przeczytaj dokładnie.
>
> o jedny........ potwierdzenie tozsamosci jest efektem ubocznym braku
> mozliwosci zdekodowania wiadomosci.

        Ale w tym właśnie celu się to stosuje, bo szyfrowanie np. RSA jest
zbyt czasochłonne żeby nim szyfrować całość transmisji.

> uech...... kluczem prywatnym nie da sie deszyfrowac wadomosci.
> te klucze
> wzgledem siebie sa niewymienne i maja scisle okreslone przeznaczenie.

        RSA ma na ten temat inne zdanie. Sorry, ale wolę polegać na RSA. ;)

> > 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
>
> no i tez sobie przeczysz :))) wczesniej napisales ze to umowa ktory jest
> prywatny. a faktycznie tylko prywatnym szyfrujesz.

        Wcale sobie nie przeczę. Jeżeli wygeneruję klucze K1 i K2, to mogę
rzucić monetą i jeden z nich udostępnić (będzie to klucz publiczny), a
drugi zamurować w podłodze (i to będzie klucz prywatny). Natomiast ich
funkcja (szyfrowanie i deszyfrowanie) jest całkowicie wymienna. Jedyne
ograniczenie to to, że wiadomość zaszyfrowaną kluczem K1 odszyfrowuje
się kluczem K2, a wiadomość zaszyfrowaną K2 odszyfrowuje się K1. Tako
rzecze RSA.

> > Ujawnienie klucza prywatnego po prostu nic nie daje.
>
> jak to nic nie daje? daje innym mozliwosc wygladania tak, jak
> prawowity wlasciciel klucza, czyli wlasciciel traci autentycznosc.

        Nie mówiliśmy o osobach trzecich, bo ich korzyść z ujawnienia klucza
prywatnego jest oczywista. Natomiast ujawnienie klucza prywatnego nic
nie daje w kontekście potwierdzania komplementarności kluczy bo i tak
trzeba wykonać próbę szyfrowania - a tę można wykonać również
dysponując tylko jednym kluczem, oczywiście pod warunkiem współpracy
obydwu stron.

--
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