🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: pl.comp.os.os2
Article #20960

Re: SSH

#20960
From: Jan Stożek
Date: Wed, 03 Jan 2001 14:42
146 lines
7280 bytes
Hej,

On Wed, 3 Jan 2001 07:17:16 Grzegorz Szyszlo 
<znik@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.
Technical Details
Message-ID: <cHzDsd8YZYjY-pn2-dcZwwPkQp9o9@pc-js.polbox.pl>
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!pingwin.icm.edu.pl!warszawa.rmf.pl!news.rmf.pl!news.onet.pl!news.memax.krakow.pl!news.ceti.com.pl!news.polbox.pl!not-for-mail
References: <200101012015.VAA03149@kujawiak.man.lodz.pl> <cHzDsd8YZYjY-pn2-ojbz1SfMyzi4@pc-js.polbox.pl> <3A51AAE8.4D7D@avalon.wbc.lublin.pl> <cHzDsd8YZYjY-pn2-ZK317MwJhW39@pc-js.polbox.pl> <3A52D1FC.4DBE@avalon.wbc.lublin.pl>

Show Full Headers
Complete Article Headers
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!pingwin.icm.edu.pl!warszawa.rmf.pl!news.rmf.pl!news.onet.pl!news.memax.krakow.pl!news.ceti.com.pl!news.polbox.pl!not-for-mail
From: Jan Stożek <jasio@nowhere.pl>
Newsgroups: pl.comp.os.os2
Subject: Re: SSH
Date: 3 Jan 2001 14:42:46 GMT
Organization: Polbox On-Line Service Sp. z o.o.
Lines: 147
Message-ID: <cHzDsd8YZYjY-pn2-dcZwwPkQp9o9@pc-js.polbox.pl>
References: <200101012015.VAA03149@kujawiak.man.lodz.pl> <cHzDsd8YZYjY-pn2-ojbz1SfMyzi4@pc-js.polbox.pl> <3A51AAE8.4D7D@avalon.wbc.lublin.pl> <cHzDsd8YZYjY-pn2-ZK317MwJhW39@pc-js.polbox.pl> <3A52D1FC.4DBE@avalon.wbc.lublin.pl>
NNTP-Posting-Host: p134.ppp.polbox.pl
Mime-Version: 1.0
X-Trace: news.polbox.pl 978532966 4291 213.241.7.134 (3 Jan 2001 14:42:46 GMT)
X-Complaints-To: news@polbox.pl
NNTP-Posting-Date: 3 Jan 2001 14:42:46 GMT
X-Newsreader: ProNews/2 Version 1.50 ia093a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit