Prywatność więcej niż niezła

Ochrona poczty elektronicznej w Internecie

Internet służy do przesyłania informacji - stwierdzenie takie jest truizmem. Informacje jednak bywają różne. Prócz informacji publicznych, umieszczanych na stronach WWW bądź rozsyłanych do grup newsowych, które przeczytać może (a w założeniu nadawcy takiej informacji nawet powinien) każdy, istnieją informacje prywatne - przeznaczone tylko dla określonego odbiorcy bądź grupy odbiorców. Te przesyłamy na ogół prywatnymi listami.

Jawne i tajne

Duża część informacji prywatnych ma charakter jawny - tzn. ich ewentualne poznanie przez osoby postronne nie stanowi szkody dla nadawcy ani odbiorcy. Gdy piszemy w liście do cioci Zosi, że Krzysiek właśnie poszedł do wojska, a Jaś znowu dostał dwójkę z matematyki, jest to przykład takiej właśnie informacji jawnej - na ogół nie zastrzegamy w liście, aby ciocia nie przekazywała tych nowin sąsiadom i znajomym, i nie stanie się nam żadna krzywda, jeżeli w istocie to zrobi. Przesyłanie tego rodzaju wiadomości e-mailem nie nastręcza rzecz jasna żadnego kłopotu.

Obok informacji jawnych istnieją jednak informacje o mniejszym lub większym stopniu tajności. Nie muszą to być od razu dane wywiadowcze o rozmieszczeniu rakiet strategicznych - np. listy miłosne od ukochanej(-ego) zwykle traktujemy jako tajemnicę i nie mamy ochoty pozwalać komukolwiek na ich czytanie. Z przesyłaniem informacji tajnych możemy mieć do czynienia także w przypadku innych usług sieciowych niż e-mail - klasycznym przykładem jest tu dokonywanie zakupów za pośrednictwem WWW, gdzie aby zapłacić, musimy zwykle w przedstawionym przez serwer formularzu wpisać (tajny) numer naszej karty kredytowej. Jako informację prywatną, a nawet tajną możemy też traktować np. cały przebieg połączenia telnetowego z naszym kontem na jakimś odległym komputerze. Tajną, gdyż w trakcie tego połączenia przesyłane jest przez sieć "otwartym tekstem" m.in. nasze hasło!

Bezpieczeństwa i niebezpieczeństwa Internetu

Przekazywanie takich informacji poprzez Internet (a ogólnie rzecz biorąc, za pomocą jakichkolwiek publicznych środków łączności!) jest już pewnym problemem, jako że nie możemy mieć żadnej gwarancji, że odbędzie się ono w sposób bezpieczny. Niebezpieczeństwo ma w tym przypadku dwa aspekty: po pierwsze - możliwość podsłuchu, czyli poznania treści przekazywanych informacji przez kogoś "po drodze". Łatwo sobie wyobrazić skutki np. poznania przez osobę nieuprawnioną hasła administratora systemu, podawanego podczas zdalnego logowania przez telnet! Drugim - nieco rzadziej dostrzeganym - zagrożeniem jest możliwość zafałszowania przez intruza treści przesyłanej przez nas informacji (tak że odbiorca otrzyma co innego niż my wysłaliśmy), albo w ogóle podszycia się kogoś pod nas i wysłania w naszym imieniu całkowicie dowolnej wiadomości, o czym my nic nie będziemy wiedzieć! (dopóki nie wspomni nam o tym ktoś z jej odbiorców).

Popularne jest przekonanie o całkowitym braku bezpieczeństwa informacji w Internecie. Mówi się, że nie powinno się przesyłać przez Internet żadnych takich treści, których nie chciałoby się zobaczyć na najbliższym słupie ogłoszeniowym - czyli, innymi słowy, wysłanie czegokolwiek "w sieć" jest równoznaczne z natychmiastowym udostępnieniem tej informacji każdemu, kto tylko będzie chciał. Tradycyjny telefon czy faks uważany jest przez wiele firm za medium bezpieczniejsze - stąd np. niektóre firmy umożliwiające zamawianie towarów za pośrednictwem WWW wymagają jednak podania najważniejszej informacji - czyli numeru karty kredytowej - środkami tradycyjnymi.

Pogląd ten zdaje się być przesadzony. Podsłuch w Internecie jest mniej więcej tak samo trudny (albo nietrudny...), jak podsłuch zwykłego telefonu. Jedno i drugie nie jest całkowicie trywialne i wymaga od "podsłuchiwacza" pewnych umiejętności i wyposażenia - rzecz jasna jednak, że jedno i drugie nierzadko się zdarza. Pewnym argumentem na rzecz przekonania o większym niebezpieczeństwie Internetu może być natomiast fakt, że tutaj podsłuchiwać można o wiele skuteczniej (czyli przechwytywać większą ilość informacji i łatwiej je analizować), przy tym praktycznie bez pozostawiania żadnych śladów. Całkowicie natomiast nieodporny jest Internet - ze względu na brak jakichkolwiek mechanizmów tzw. autentykacji użytkownika (czyli potwierdzenia jego tożsamości) - na próby podszywania się pod inne osoby: wysłanie np. listu elektronicznego w czyimś imieniu, z fałszywym adresem zwrotnym, nie stanowi żadnego problemu.

Szyfrowanie - sposób na podsłuch

Sposób na to, jak przez niepewny kanał łączności przesłać tajną informację, znany jest od czasów starożytnych - informację tę należy zaszyfrować, czyli przekształcić ją do niezrozumiałej postaci, możliwej do odczytania tylko dla osoby posiadającej tajny klucz do szyfru. Chyba każdy jako dziecko bawił się w szyfry i kodowanie za ich pomocą "tajnych" wiadomości do kolegów. Zwykle jako dzieci nie zastanawiamy się nad bezpieczeństwem tych szyfrów i trudnością ich złamania, choć nierzadko sami do złamania szyfru przeciwnej "paczki" nieświadomie stosujemy elementarne metody kryptoanalizy (czyli nauki o łamaniu szyfrów) - np. tzw. atak ze znanym tekstem jawnym (known plaintext attack), czyli porównanie tekstu zaszyfrowanego z uzyskanym skądinąd (wywiad...) tym samym tekstem - lub jego fragmentem - w postaci jawnej, czyli niezaszyfrowanej. Wszelkie "dziecięce" szyfry na ogół natychmiast "padają" pod takim atakiem, jeżeli tylko dysponujemy dostatecznie długim tekstem do porównania.

W "prawdziwych" współczesnych szyfrach oczywiście nie koduje się informacji ręcznie - w zetknięciu z profesjonalną kryptoanalizą nie miałyby żadnych szans. To skomplikowane algorytmy komputerowe, przekształcające szyfrowany tekst w ciąg bajtów pozornie bez żadnego sensu, wyglądających na zupełnie przypadkowe i nie wykazujących żadnego uchwytnego podobieństwa do tekstu w postaci jawnej - przynajmniej na pierwszy rzut oka. Ich złamanie jest niezwykle trudne, a w przypadku najlepszych szyfrów wydaje się być wręcz niemożliwe przy współczesnym stanie techniki - nawet dla agencji wywiadowczych. (Zainteresowanych "na poważnie" szyframi warto w tym miejscu zaprosić do grupy newsowej sci.crypt, a zwłaszcza do przeczytania jej FAQ, dostępnego pod adresem ftp://ftp.cyf-kr.edu.pl/pub/mirror/usenet/news.answers/cryptography-faq/)

Zastosowanie takich szyfrów do ochrony poczty elektronicznej, czy innych informacji przesyłanych przez Internet, wydawałoby się zatem oczywiste. Jest jednakże jeden problem: wszystkie tradycyjne systemy szyfrowania, od starożytności do dnia dzisiejszego, opierają się na jednej podstawowej zasadzie - istnienia wspólnego, tajnego klucza do szyfru, który musi być używany przez obie porozumiewające się strony - z jednej strony do zaszyfrowania wiadomości, z drugiej do jej odszyfrowania. Ogranicza to w sposób istotny możliwość stosowania takiego szyfru do osób bądź instytucji, które nawzajem się znają i mają możliwość przekazania sobie w sposób bezpieczny (najlepiej "z ręki do ręki" przy osobistym spotkaniu) klucza do szyfru. O powszechnym korzystaniu z szyfrów w Internecie nie ma w takiej sytuacji nawet co marzyć - w jaki sposób mam uzgadniać ze wszystkimi, z którymi się będę kontaktował, klucze do szyfru? Mogą oni wszak znajdować się na innym kontynencie (i bardzo często się znajdują), a Internet może być moją jedyną drogą komunikacji z nimi.

Klucz publiczny

Rozwiązaniem tego problemu jest wynaleziona w 1976 r. metoda szyfrowania z kluczem publicznym (public key cryptography), zwanej przez niektórych metodą podwójnego klucza. W tej metodzie nie ma jednego, wspólnego dla obu komunikujących się stron klucza: każdy z korespondentów posiada dwa klucze, ściśle związane ze sobą. Jeden z kluczy jest kluczem publicznym - ten możemy, a nawet powinniśmy rozpropagować w sieci jak najszerzej. Każdy, kto będzie chciał wysłać do nas zaszyfrowany list, musi znać ten klucz. Drugi z kluczy to klucz prywatny - tego nie potrzebujemy, a nawet nie możemy nikomu udostępniać. Wręcz przeciwnie, musimy pilnować go jak oka w głowie: nie powinien on nigdy opuszczać naszego komputera.

Algorytm szyfrowania z kluczem publicznym skonstruowany jest tak, że to, co zostanie zaszyfrowane kluczem publicznym, może być odszyfrowane jedynie kluczem prywatnym z tej samej pary. Zatem każdy, kto zna mój klucz publiczny, może wysłać do mnie zaszyfrowany list - i listu tego nie będzie mógł odczytać nikt poza mną. Udało się zatem uzyskać bezpieczną metodę komunikacji, bez problemów z przekazywaniem tajnego klucza.

Algorytm działa również w odwrotną stronę: to, co zostanie zaszyfrowane moim kluczem prywatnym, może być odszyfrowane przez każdego, kto zna mój klucz publiczny. Na co jednak przydać się może taki szyfr, który każdy może odczytać? Otóż fakt, że wiadomość daje się odszyfrować moim kluczem publicznym, stanowi dowód, że w istocie musi ona pochodzić ode mnie - gdyż tylko ja posiadam klucz prywatny, niezbędny do jej zaszyfrowania (zakładając, że nikt mi go nie ukradł...), wyklucza więc możliwość podszycia się pode mnie kogokolwiek. "Odwrócone" szyfrowanie staje się zatem elektronicznym podpisem - w odróżnieniu od zwykłego podpisu na papierowym dokumencie niemal całkowicie niepodrabialnym.

Algorytm RSA

Szyfrowanie z kluczem publicznym zdaje się zatem być niemal idealnym lekarstwem na problemy z bezpieczeństwem komunikacji Internetowej, opisywane powyżej. Nic więc dziwnego, że w istocie metoda ta jest powszechnie stosowana. Istnieje kilka algorytmów szyfrowania z kluczem publicznym, jednak bezapelacyjnie najpopularniejszym i stanowiącym faktyczny standard jest - stworzony w 1977 r. przez Rona Rivesta, Adi Shamira i Leonarda Adlemana, podówczas pracowników Masachussetts Institute of Technology - algorytm nazwany od nazwisk jego twórców RSA. Na rynku dostępna jest obecnie wielka liczba programów stosujących ten algorytm: z najważniejszych należy tu wymienić przeglądarki WWW stosujące protokół "bezpiecznych" połączeń SSL - przede wszystkim Netscape Navigator i Microsoft Internet Explorer (a także współpracujące z tym protokołem serwery), program Secure Shell (SSH), używany jako bezpieczny odpowiednik połączeń telnetowych oraz sesji X-Window, a wreszcie - stanowiący główny temat niniejszego artykułu - program PGP, przeznaczony do utajniania poczty elektronicznej.

W praktyce jednak szyfrowanie całej przesyłanej wiadomości algorytmem RSA nie jest stosowane w żadnym z tych programów - algorytmem ten jest bowiem zbyt powolny. Faktycznie za pomocą RSA szyfruje się jedynie... klucz dla innej, tradycyjnej (czyli wykorzystującej pojedynczy klucz) metody szyfrowania. Klucz ten, zwany kluczem sesji, jest losowo generowany dla każdego połączenia i w bezpieczny sposób (bo z wykorzystaniem RSA) przekazywany drugiej stronie. Cała dalsza transmisja jest już szyfrowana tradycyjnie przy pomocy tego klucza. Do tradycyjnych szyfrów najczęściej stosowanych w oprogramowaniu Internetowym należą: amerykański federalny standard ochrony danych DES (Data Encryption Standard), uważany za praktycznie "niełamalny" szwajcarski algorytm IDEA (International Data Encryption Algorithm), napisany w ETH w Zurychu (ten właśnie algorytm wykorzystywany jest w PGP *) oraz szyfry RC2 i RC4, zaprojektowane przez Rona Rivesta - jednego z twórców RSA - już dla nowej firmy RSA Data Security Inc. (te z kolei stosowane są w przeglądarkach WWW).

PGP - co to jest?

Mimo ogromnej obecnie popularności przeglądarek WWW, ich funkcje szyfrujące - choć niewątpliwie istotne dla osób chcących dokonywać przez sieć transakcji finansowych - dla większości użytkowników mają jednak znaczenie marginalne. Podstawowym polem zastosowania kryptografii w Internecie pozostaje jednak poczta elektroniczna. Dla niej istnieją w tej chwili dwa konkurencyjne standardy szyfrowania: PEM (Privacy Enhanced Mail) oraz PGP. W zasadzie mówienie o konkurencji jest tu niezbyt zasadne - PEM, chociaż jest proponowanym formalnym standardem Internetowym (dokumenty RFC 1421-1424), ma znikomo małą popularność w porównaniu z PGP. To właśnie PGP jest w chwili obecnej faktycznym standardem ochrony poczty elektronicznej (trwają również prace nad przygotowaniem formalnego dokumentu RFC na jego temat).

Program PGP (Pretty Good Privacy), napisany na początku lat dziewięćdziesiątych przez Phila Zimmermanna, był programem, który wprowadził kryptografię "pod strzechy". Do chwili jego powstania dostęp do zaawansowanych technik szyfrowania miały tylko służby specjalne oraz bogate firmy. PGP udostępniło je każdemu użytkownikowi Internetu. Wobec wykorzystania dwóch bardzo wysokiej klasy algorytmów szyfrujących - RSA i IDEA - nazwa "całkiem niezła prywatność", którą "ochrzcił" swoje dzieło Phil Zimmermann, wydaje się być nadmierną skromnością, albo... świadomą złośliwością pod adresem potencjalnych "podsłuchiwaczy" wiadomości zakodowanych przez PGP. Ochrona zapewniana przez użycie tego programu jest bowiem daleko lepsza niż tylko "niezła".

Patentowo-eksportowa kołomyjka

PGP ma dosyć burzliwą historię, w której mieści się i dochodzenie kryminalne przeciwko jego autorowi, i oskarżenia o naruszenie praw patentowych... Niezbyt to dziwi w przypadku narzędzia tak drażliwego dla służb specjalnych - wiadomości zaszyfrowanych przez PGP wydaje się nie być w stanie rozkodować nawet amerykańska NSA (Narodowa Agencja Bezpieczeństwa), mająca prawdopodobnie do dyspozycji najpotężniejsze środki kryptoanalityczne na świecie. Z powodu tych wydarzeń związanych z PGP wiele osób ma wątpliwości co do legalności użycia tego programu (co oczywiście tylko powoduje wzrost jego popularności...). W istocie jednak użycie PGP jest całkowicie legalne (rzecz jasna z wyjątkiem państw, które explicite zakazują stosowania jakiegokolwiek szyfrowania, jak np. Rosja), należy tylko użyć właściwej wersji programu - z tym jest bowiem istotnie pewne zamieszanie.

Po pierwsze, algorytm RSA jest w USA opatentowany. Właścicielem patentu jest firma RSA Data Security Inc. (wcześniej Public Key Partners), założona przez twórców algorytmu wkrótce po jego opublikowaniu. Nikt zatem nie ma prawa używać tego algorytmu bez zgody wspomnianej firmy. Firma RSA Inc. zezwala jednak na bezpłatne używanie algorytmu do celów niekomercyjnych, pod warunkiem że wykorzystywane będą wyłącznie oryginalne procedury firmy RSA, udostępniane specjalnie na ten cel w postaci biblioteki o nazwie RSAREF. Wcześniejsze wersje PGP nie używały biblioteki RSAREF, lecz procedur napisanych własnoręcznie przez Phila Zimmermanna, w istocie łamały więc prawa patentowe RSA Inc. Po porozumieniu autora programu z firmą RSA obecna wersja PGP używa już biblioteki RSAREF.

Patent firmy RSA nie obowiązuje poza USA, tak więc wersja "międzynarodowa" PGP, przeznaczona do użytku poza USA, może swobodnie używać (i w istocie używa) własnych procedur Phila Zimmermanna. Tu jednak pod adresem autora pojawiło się oskarżenie o wiele poważniejsze: złamanie amerykańskich ograniczeń dotyczących eksportu broni (ITAR), za co grożą bardzo wysokie kary - do 10 lat więzienia oraz miliona dolarów grzywny. Co ma oprogramowanie szyfrujące do eksportu broni? Otóż prawo amerykańskie traktuje każde urządzenie, bądź program komputerowy, zawierające funkcje szyfrowania, analogicznie jak broń, i zakazuje ich eksportu bez specjalnego pozwolenia. O oczywistym bezsensie tego przepisu świadczy fakt, że np. kod źródłowy tego samego programu szyfrującego wydrukowany w książce - i to do tego specjalną czcionką pozwalającą na łatwe wczytanie go do komputera przy pomocy skanera - analogicznym restrykcjom eksportowym nie podlega i książka taka może być swobodnie sprzedawana poza USA. Inną "ciekawostką" jest to, że przepis ten stosuje się on także do oprogramowania pochodzącego spoza USA, które zostało do USA sprowadzone, a następnie ktoś chciałby je wysłać z powrotem za granicę!

Faktem jest jednakże, że taki przepis istnieje i program Phila Zimmermanna niewątpliwie mu podlega. Faktem było także, że w jakiś sposób program zawędrował poza USA - a bo to trudno, gdy dostępny jest w Internecie? Nie da się ustalić, kto pierwszy "wyeksportował" PGP - najprawdopodobniej ktoś z zagranicy "ściągnął go" z jakiegoś amerykańskiego serwera, niemniej jednak oskarżono o to jego autora (po długim dochodzeniu sprawę wreszcie umorzono w styczniu 1996 r.) Jednak niezależnie od ewentualnej nielegalności czynu, jakim jest eksport programu poza granice USA, późniejsze używanie wyeksportowanego w ten sposób programu jest już czynnością całkowicie legalną - zatem używając PGP otrzymanego ze źródła znajdującego się poza USA nie łamie się żadnego prawa.

W efekcie istnieją obecnie trzy wersje PGP *:

Ostatnią już kwestią prawną związaną z używaniem PGP jest fakt, że w niektórych krajach opatentowany jest z kolei stosowany w tym programie algorytm IDEA - jego użycie do celów niekomercyjnych jest bezpłatne, ale na użytkownaie komercyjne trzeba wykupić licencję od będącej właścicielem patentu szwajcarskiej firmy Ascom-Systec AG.

Start do PGP

Na szczęście w Polsce ani nie zakazano (póki co) stosowania kryptografii, ani nie obowiązuje patent na algorytm IDEA - tak więc PGP (ma się rozumieć w wersji międzynarodowej) można używać bez żadnych przeszkód prawno-finansowych. Istnieje nawet polska wersja językowa PGP, przetłumaczona przez zespół pod kierunkiem Pawła Krawczyka z Politechniki Krakowskiej - twórcy polskiej strony WWW na temat PGP (http://www.ceti.com.pl/~kravietz/pgp/). Ze strony tej można sobie także ściągnąć sam program, niestety tylko w wersji DOS-owej. Inne wersje znaleźć można na głównej stronie poświęconej międzynarodowej wersji PGP - http://www.pgpi.org/. Dostępne są wersje dla DOS-u, Unixa, OS/2, Amigi i wielu innych systemów. PGP jest programem typowo tekstowym i nie ma specjalnej wersji "okienkowej" - istnieje wprawdzie 32-bitowa wersja przeznaczona dla Windows 95/NT, ale działa ona w oknie tekstowym i nie różni się niczym (może poza szybkością) od DOS-owej. Dostępne są jednak liczne nakładki, ułatwiające obsługę PGP z poziomu "okienek", w tym także integrujące program z najpopularniejszymi aplikacjami pocztowymi (Eudora, Pegasus Mail) - informację o nich znaleźć można również na wspomnianej międzynarodowej stronie PGP *.

Pierwszą czynnością, którą musimy wykonać po zainstalowaniu PGP, jest wygenerowanie naszej pary kluczy - prywatnego i publicznego. Dokonujemy tego, wydając komendę (jednakowo w DOS-ie i w Unixie):

     pgp -kg
Po wydaniu tej komendy, program pyta o długość klucza. Im dłuższy klucz, tym wyższy poziom bezpieczeństwa zapewniany przez szyfr. Można wybrać jedną ze standardowych długości (512 bitów - "niski poziom komercyjny", 768 - "wysoki poziom komercyjny", 1024 - "poziom wojskowy") lub własną, z przedziału 504-2048 bitów. Firma RSA Inc. uważa, że szyfr o długości klucza 512 bitów jest już obecnie niezbyt bezpieczny; zaleca używanie klucza co najmniej 768-bitowego, która to długość powinna zapewniać bezpieczeństwo do około roku 2004.

Po podaniu długości klucza pojawia się pytanie o identyfikator użytkownika, który powinien jednoznacznie określać właściciela klucza. Zwykle podaje się go w postaci imienia i nazwiska oraz adresu e-mail, zapisanych w sposób podobny do poniższego:

     Jan Kowalski <kowalski@gdzies.w.sieci.pl>
Klucz prywatny może być chroniony hasłem, co uniemożliwi skorzystanie z niego osobom postronnym, nawet gdyby dostał się on w ich ręce. Hasła należy używać zawsze wtedy, gdy istnieje niebezpieczeństwo, że do naszego klucza prywatnego może mieć dostęp ktoś inny (np. gdy przechowujemy go na naszym koncie w systemie wielodostępnym, takim jak Unix, wówczas ma do niego dostęp administrator systemu - w zasadzie jednak nie jest to najlepsze miejsce do przechowywania swojego klucza prywatnego). Kolejne pytanie zadawane przez program odnosi się właśnie do tego hasła. Wpisywane hasło - jak to zwykle bywa w takich przypadkach - nie pojawia się oczywiście na ekranie, i należy wpisać je dwukrotnie w celu weryfikacji. Nie wolno go rzecz jasna zapomnieć - nie ma żadnej możliwości jego odtworzenia, a klucz prywatny bez hasła jest bezużyteczny. Ponieważ PGP nie dysponuje praktycznie żadnym skutecznym mechanizmem unieważniania kluczy (jest to jedna z nielicznych wad tego programu), sytuacja taka jest niezwykle nieprzyjemna, gdyż nasi korespondenci wciąż będą mogli pisać do nas listy szyfrując je naszym kluczem publicznym, a my (ani nikt inny) nie będziemy w stanie ich odczytać. Jeżeli nie chcemy hasła (wskazane jedynie w przypadku, gdy klucz przechowujemy na prywatnym komputerze, do którego nikt poza nami nie ma dostępu), przyciskamy sam klawisz ENTER.

Następnie program prosi o wpisanie kilkudziesięciu znaków dowolnego tekstu. Istotny tu jest nie sam tekst, ale odstępy czasowe między naciśnięciami klawiszy, które służą jako źródło liczby losowej, użytej następnie do tworzenia klucza. W ten sposób PGP uzyskuje praktyczną niepowtarzalność kluczy. Wygenerowanie klucza - w zależności od jego długości i od szybkości komputera - może trwać od kilku-kilkunastu sekund nawet do kilku minut. Po zakończeniu tego procesu utworzone zostaną dwie bazy kluczy (key rings), zawierające na razie tylko nasze własne klucze: baza kluczy publicznych znajdzie się w pliku o nazwie pubring.pgp, zaś baza kluczy prywatnych - w pliku secring.pgp. Ta druga baza zwykle zawierać będzie zawsze tylko jeden klucz - nasz własny (aczkolwiek możliwe jest posiadanie kilku kluczy prywatnych - np. jednego do użytku prywatnego, drugiego służbowego, albo jednego 512-bitowego do korespondencji o mniejszym znaczeniu, a drugiego 2048-bitowego do korespondencji ściśle tajnej), do pierwszej natomiast - w miarę korzystania z programu - dodawać będziemy klucze publiczne naszych korespondentów.

Warto tu jeszcze raz podkreślić, że korzystanie z PGP nie zapewni nam żadnego bezpieczeństwa, jeżeli nie zadbamy o należytą ochronę naszego klucza prywatnego. Zdecydowanie niewłaściwym miejscem do jego przechowywania byłby niezabezpieczony niczym dysk twardy komputera klasy PC, do którego dostęp ma jeszcze ktoś poza nami! (np. w pracy). Nieco lepsze jest konto w systemie Unix czy podobnym, choć - jak już powiedziano wyżej - w tym przypadku dostęp do naszego klucza ma (przynajmniej) administrator systemu. Teoretycznie najbardziej wskazanym sposobem przechowywania klucza prywatnego jest dyskietka, noszona przy sobie lub trzymana w zamknięciu, ewentualnie dysk twardy komputera dostępnego tylko właścicielowi.

Klucz publiczny należy natomiast jak najszerzej rozpropagować. W tym celu z reguły będzie nam potrzebna jego postać tekstowa, "wyciągnięta" z pliku pubring.pgp. Dokonujemy tego komendą

     pgp -kxa użytkownik plik.txt
gdzie "użytkownik" jest dowolnym fragmentem identyfikatora użytkownika, którego klucz chcemy uzyskać (a więc w naszym przykładzie może to być np. "kowalski"), a "plik.txt" - nazwą pliku, do którego ma być zapisany klucz. Przekształcony do postaci tekstowej klucz naszego Jana Kowalskiego wyglądać może następująco:

   -----BEGIN PGP PUBLIC KEY BLOCK-----
   Version: 2.6.3i

   mQBNAzNyFhEAAAECAL33pur76v7YLJXpOFd5XG0GpeqJKF9OWlVW5Rb0/tFaSUu5
   2MB7vPyU9Ls8HHdSjc3pdeRMhI7KV2u8rc4/tAUABRG0KUphbiBLb3dhbHNraSA8
   a293YWxza2lAZ2R6aWVzLncuc2llY2kucGw+iQBVAwUQM3IWEldrvK3OP7QFAQGZ
   cQIAg8vgTWdut8AvjR1tzNXhGIjfPB7uqlqvIQz4loSE56lFxcZnq1fW3V58uVgc
   hHdc+m5aCi5sTzKHBuTbdIs2Zw==
   =eQ8+
   -----END PGP PUBLIC KEY BLOCK-----
Taki klucz możemy umieścić np. na swojej stronie WWW, w treści informacji o naszym koncie wyświetlanej przez komendę "finger" (na kontach Unixowych jest to plik .plan w prywatnym katalogu użytkownika), czy też rozesłać go wszystkim znajomym e-mailem.

Szyfrowanie i podpisywanie

Załóżmy teraz, że mając już zainstalowane PGP chcemy wysłać zaszyfrowany list do innego użytkownika. Najpierw musimy zdobyć klucz publiczny tej osoby. Następnie dodajemy go do swojej bazy kluczy komendą

     pgp -ka plik.txt
(plik.txt jest oczywiście nazwą pliku zawierającego klucz). W tym momencie program pokaże nam identyfikator użytkownika, do którego należy wprowadzany klucz, a następnie zada nam jakieś niezbyt zrozumiałe pytania na temat wiarygodności tego użytkownika i naszej chęci podpisania jego klucza - zajmiemy się tym jeszcze dalej, a na razie na wszelki wypadek odpowiedzmy "nie".

Gdy mamy już klucz publiczny adresata w swojej bazie kluczy, możemy przystąpić do zaszyfrowania listu. Piszemy jego treść w jakimkolwiek edytorze ASCII (np. tym zawartym w Norton Commanderze), i po zapisaniu pliku na dysku wydajemy komendę

     pgp -ea plik.txt użytkownik
na przykład "pgp -ea tajne.txt Malinowski", czego efekt będzie następujący:

   Pretty Good Privacy(tm) 2.6.3i -- Kryptografia publiczna dla mas.
   (c) 1990-96 Philip Zimmermann, Phil's Pretty Good Software. 1996-01-18
   Wersja miedzynarodowa - do uzytku poza USA. Nie wykorzystuje RSAREF.
   Aktualny czas: 1997/05/08 18:57 GMT


   Do szyfrowania zostanie uzyty klucz(e) publiczny odbiorcy.
   Uzytkownik: Antoni Malinowski <malin@gdzie.indziej.pl>
   Klucz 512-bitowy numer 7CCA4E71, stworzony 1997/05/08
   .
   Szyfrogram w opakowaniu ASCII: tajne.asc
Jak widać, utworzony zostanie plik o takiej samej części głównej nazwy, co oryginalny list, i rozszerzeniu .asc. Teraz ten plik możemy wczytać do naszego programu pocztowego (większość programów ma taką możliwość) i wysłać do adresata. Zaszyfrowany list wyglądać może w taki oto sposób:

   -----BEGIN PGP MESSAGE-----
   Version: 2.6.3i

   hEwDTi8VD3zKTnEBAf97rXWRGbfQJMOWKAAmuFxl0jw1NaA0riumPIrH2FaDwTFV
   ezrYuavaehFWqAUbvnDcVVw7HsOauX17GDnuhncypgAAAMdvm7lmazIk3TXiJWiN
   oBOTJo6r0QIX3PS62BIPe/ur1krk5gNkKRs/j4Vk3UJPevspyt7xvC5RZbDZKYIj
   Cnn5gdNUh4Ke5VpNrv8pOHs+/kCUn9bp3s11TznR/9/8iH0gwi9JjEqBwLm8RNiB
   +eAu2V/ggyin03QrmWLia181a7p74VEs3l1h+6aZt0DYUinjZ1X4SX2N0rixLJs1
   zds6rCKCjHxzIGLLLCNmGbdMxL61STUnDOvc0wjHH0wlLCSHtQofauwm
   =vDWq
   -----END PGP MESSAGE-----
Odbiorca takiego listu wydaje - po zapisaniu go do pliku - po prostu komendę pgp nazwa_pliku, a program sam rozpozna, co w tym pliku się znajduje, odszuka w naszej bazie kluczy odpowiedni klucz prywatny i zdekoduje list:

   Pretty Good Privacy(tm) 2.6.3i -- Kryptografia publiczna dla mas.
   (c) 1990-96 Philip Zimmermann, Phil's Pretty Good Software. 1996-01-18
   Wersja miedzynarodowa - do uzytku poza USA. Nie wykorzystuje RSAREF.
   Aktualny czas: 1997/05/08 18:58 GMT

   Plik jest zaszyfrowany. Do rozszyfrowania potrzebny jest tajny klucz.
   Uzytkownik: Antoni Malinowski <malin@gdzie.indziej.pl>
   Klucz 512-bitowy numer 7CCA4E71, stworzony 1997/05/08

   Uwaga: Twoj tajny klucz nie jest chroniony przez haslo!
   Chwileczke......
   Nazwa wynikowego pliku jawnego: list
Zgodnie z tym, co mówiliśmy na wstępie, "odwrócone" szyfrowanie - tzn. kluczem prywatnym zamiast publicznego - daje w wyniku podpis elektroniczny. Wiadomość wprost zaszyfrowana naszym kluczem prywatnym będzie jednak wyglądać równie niezrozumiale, co ta powyżej, choć oczywiście za pomocą PGP da się odczytać bez trudu. W sytuacjach, w których potrzebny jest podpis elektroniczny, bardziej wskazane jest jednak, aby podpisywany list zapisany był tekstem jawnym, czytelnym bez stosowania dodatkowych programów, a PGP niezbędne było tylko do weryfikacji podpisu, a nie do odczytania samej wiadomości (choć oczywiście, jeżeli istnieje taka potrzeba, list może być zarówno podpisany - kluczem prywatnym nadawcy, jak i zaszyfrowany - kluczem publicznym odbiorcy). List taki wygląda podobnie do poniższego (uzyskuje się to komendą pgp -sta plik.txt):

   -----BEGIN PGP SIGNED MESSAGE-----

   Jan Kowalski
   ul. Niczyja 7
   Krakow

   Niniejszym zamawiam i prosze o przyslanie na moj adres 10 sztuk dyskow
   twardych Maxtor 7020A.
   Naleznosc zobowiazuje sie uregulowac przelewem z mojego konta do 7 dni
   po otrzymaniu faktury.

   -----BEGIN PGP SIGNATURE-----
   Version: 2.6.3i
   Charset: noconv

   iQBVAwUBM3IbiFdrvK3OP7QFAQGUHgH/QIXAoJjEEsuW9AUTMNNSNhAs8EOd5zeE
   OeLY0Pe13VqJmb/GvucQVFhLOqV/F3VYq3goz2xlcpuJ/aMPMW8tpw==
   =OiNw
   -----END PGP SIGNATURE-----
Aby uzyskać tego rodzaju elektroniczny podpis, szyfrowaniu kluczem prywatnym nie podlega cała wiadomość, lecz jej tzw. skrót (message digest) - kilku-kilkunastobajtowa wartość, obliczona na podstawie treści wiadomości (od linii "BEGIN PGP SIGNED MESSAGE" do "BEGIN PGP SIGNATURE") za pomocą specjalnej tzw. funkcji mieszającej (hash function). Funkcje takie mają tę właściwość (w podobny sposób liczone są tzw. sumy kontrolne, używane do weryfikacji nienaruszalności plików w programach antywirusowych lub w programach kompresujących takich jak PKZIP), że praktycznie niemożliwe jest skonstruowanie dwóch wiadomości, które dawałyby identyczny wynik funkcji mieszającej - stąd nadrobniejsza nawet zmiana w treści listu daje inną wartość skrótu, a zatem i inny elektroniczny podpis. Sprawdzenie podpisu w takim liście (podobnie jak w przypadku rozszyfrowywania, komendą pgp nazwa_pliku) spowoduje wyświetlenie następującej informacji:

   Pretty Good Privacy(tm) 2.6.3i -- Kryptografia publiczna dla mas.
   (c) 1990-96 Philip Zimmermann, Phil's Pretty Good Software. 1996-01-18
   Wersja miedzynarodowa - do uzytku poza USA. Nie wykorzystuje RSAREF.
   Aktualny czas: 1997/05/08 18:58 GMT

   Plik jest opatrzony sygnatura. Do jej sprawdzenia wymagany jest klucz
   publiczny autora tej sygnatury .
   .
   Dobra sygnatura: "Jan Kowalski <kowalski@gdzies.w.sieci.pl>".
   Sygnatura stworzona 1997/05/08 18:29 GMT, 512-bitowym kluczem numer CE3FB405

   Nazwa wynikowego pliku jawnego: zamkowal
Mamy zatem niemożliwy do podrobienia (i do wyparcia się) dowód, że autorem tego listu jest Jan Kowalski. Niestety, podpisy elektroniczne (nie tylko stworzone przez PGP, ale i jakiekolwiek inne oprogramowanie) nie są w chwili obecnej w Polsce uznawane prawnie, aczkolwiek mimo to istnieją np. firmy, które honorują je w kontaktach handlowych. Najwyższy czas na zmianę przepisów...

Czy Kowalski to Kowalski, czyli o certyfikowaniu kluczy

Powiedzieliśmy powyżej: mamy dowód, że autorem tego listu jest Jan Kowalski. Czy jednak na pewno? Czy fakt, że po sprawdzeniu podpisu w liście pojawia się identyfikator "Jan Kowalski <kowalski@gdzies.w.sieci.pl>" gwarantuje nam, że użyty do podpisania klucz jest autentyczny - należy faktycznie do Jana Kowalskiego?

Sęk w tym, że identyfikator związany z kluczem, podawany przez użytkownika w chwili jego tworzenia, może być zupełnie dowolny! Nic nie stoi na przeszkodzie, aby ktokolwiek np. wygenerował klucz publiczny (i tym samym posiadał odpowiadający mu klucz prywatny) o identyfikatorze:

     Bill Clinton <president@whitehouse.gov>
Jeżeli ktoś da się nabrać i będzie używał fałszywego klucza (akurat w powyższym przypadku jest dość powszechnie wiadome, że właściciel tego konta nie używa PGP), będzie weryfikował sfałszowane listy jako poprawne. Próba zaś użycia tego klucza do zaszyfrowania listu spowoduje, że prawowity adresat nie będzie mógł go odczytać (będzie go mógł odczytać natomiast właściciel fałszywego klucza, gdyby jakimś sposobem list ten dostał się w jego ręce). Po co zatem ten cały raban z kluczami publicznymi, skoro i tak nadal nie wiadomo, czy wskazana na kluczu osoba jest faktycznie tą, za którą się podaje? Abyśmy mogli być tego pewni, musimy uzyskać jej klucz publiczny z wiarygodnego źródła. Najlepiej byłoby oczywiście otrzymać go bezpośrednio od tej osoby, ale raczej nie e-mailem - pamiętajmy, jak łatwo jest sfałszować adres zwrotny elektronicznego listu! Nieprzypadkowo do udostępniania kluczy publicznych wykorzystuje się najczęściej komendę "finger". Pomimo jej prostoty (a może właśnie dzięki temu) jest ją raczej trudno "ogłupić" tak, aby pobrała informację z niewłaściwego miejsca. Jeżeli zatem znamy adres e-mail, z którego interesująca nas osoba zwykle pisze listy, i po sięgnięciu pod ten adres komendą "finger" odnajdujemy klucz publiczny, to z dużym prawdopodobieństwem możemy sądzić, że jest on autentyczny. Z kluczami umieszczonymi na stronach WWW może być już gorzej, bo adres strony WWW może być czasami bardzo różny od adresu pocztowego użytkownika, i wcale nie musimy mieć pewności, czy zamiast prawdziwej strony WWW danej osoby nie oglądamy "podstawionej" strony należącej rzekomo do niej, której adres (fałszywy) został nam podany w sfałszowanym e-mailu (ejże, czy to aby nie brzmi jak lekka paranoja?)

Tego typu wątpliwościom zaradzić ma certyfikowanie kluczy. Certyfikowanie klucza to po prostu potwierdzenie jego autentyczności (czyli tego, że klucz faktycznie należy do osoby, której nazwisko na nim widnieje) przez inną osobę, do której (a właściwie do której klucza) mamy zaufanie. Tutaj mamy do czynienia z diametralną różnicą pomiędzy PGP i wspomnianym wcześniej systemem PEM. W PEM certyfikowanie kluczy jest wybitnie sformalizowane: system ten zakłada całą hierarchię tzw. urzędów certyfikacyjnych (certification authorities - CA), poczynając od najwyższego w hierarchii, poprzez kolejne niższe stopnie, aż do tych wystawiających bezpośrednio certyfikaty użytkownikom (identycznie zresztą zorganizowany jest system certyfikatów używanych przez SSL w przeglądarkach WWW). Trudności w stworzeniu takiej sieci CA są też zapewne jedną z przyczyn małej popularności tego standardu. W przeciwieństwie do PEM, w PGP nie ma żadnych urzędów certyfikacyjnych - każdy może certyfikować klucz publiczny każdego. Każdy może również wedle własnej woli uznawać lub nie uznawać certyfikatów wystawionych przez określonych użytkowników. Kiedy dodajemy nowy klucz publiczny do swojej bazy kluczy, program sprawdza posiadane przez ten klucz certyfikaty. Jeżeli klucz nie posiada żadnego wiarygodnego certyfikatu - tzn. albo nie posiada certyfikatu w ogóle, albo certyfikat został wystawiony przez użytkownika(ów), którego nie ma w naszej bazie kluczy, bądź też jest, ale uznaliśmy go za niewiarygodnego - program pyta się, czy chcemy sami certyfikować ten klucz. Zróbmy to tylko wtedy, jeżeli naprawdę jesteśmy pewni, że jest to autentyczny klucz należący do danej osoby!

Jeżeli zdecydujemy się certyfikować czyjś klucz, musimy jeszcze odpowiedzieć na pytanie, jak będziemy traktować certyfikaty wystawione innym użytkownikom przez posiadacza tego właśnie klucza - do wyboru są cztery stopnie zaufania, od całkowicie niewiarygodnego do całkowicie wiarygodnego. Brzmi to wszystko dosyć skomplikowanie i wymaga pewnego "oswojenia się", jednakże na początek, przy wprawianiu się w używaniu PGP, można się problemem certyfikatów nie przejmować - ustawiony poziom zaufania do danego użytkownika można zawsze potem zmienić przy pomocy odpowiednich opcji programu.

W niniejszym tekście omówiono oczywiście tylko najbardziej podstawowe funkcje programu PGP. Chcący poznać więcej możliwości mogą sięgnąć do dostępnego w sieci tekstu Szymona Sokoła [1], bądź - najlepiej - od razu do samej dokumentacji programu (jest dostępna również w języku polskim!).

Kilka słów o bezpieczeństwie

Na zakończenie nie sposób nie zastanowić się nad bezpieczeństwem oferowanego przez PGP szyfru. Metoda złamania szyfru RSA - czyli odtworzenia klucza prywatnego, mając dany klucz publiczny - jest teoretycznie oczywista: problem sprowadza się do rozłożenia na czynniki liczby, będącej iloczynem dwóch dużych liczb pierwszych. Bezpieczeństwo szyfru płynie stąd, że przy użyciu wszystkich aktualnie znanych metod matematycznych operacja rozkładu dużej liczby (rzędu 150 i więcej cyfr) na czynniki pierwsze trwa niezwykle długo - przykładowo, złamanie 512-bitowego klucza RSA wymaga (wg [5]) 1 roku pracy komputera o szybkości 30000 MIPS (milionów operacji na sekundę), lub odpowiednio krótszego czasu pracy komputera szybszego - skądinąd takie moce obliczeniowe nie są już dzisiaj wcale nierealne (zob. dalej). Nie zostało jednak matematycznie udowodnione, że faktoryzowanie (rozkład liczby na czynniki pierwsze) musi być tak trudne, stąd też teoretycznie możliwe jest w każdej chwili pojawienie się nowej metody matematycznej, pozwalającej na faktoryzację w czasie radykalnie krótszym. Opracowanie takiej metody spowodowałoby oczywiście bezużyteczność szyfru RSA i potężne zamieszanie w kryptografii (niektórzy twierdzą co prawda, że taka metoda została już dawno opracowana, ale NSA utrzymuje ją w tajemnicy i nie pozwala na jej publikację, mogąc sama dzięki temu łamać wszelkie zakodowane transmisje - większość kryptologów uważa jednak to przypuszczenie za nieprawdopodobne). Z drugiej strony, w każdej chwili możliwe jest również to, że jakiś matematyk przeprowadzi dowód tego, iż faktoryzowanie musi być skomplikowane: wówczas szyfr RSA byłby bezpieczny "na zawsze". Póki co jednak, klucze o długości co najmniej 768 bitów uważane są za bezpieczne.

Aby rozszyfrować zakodowaną wiadomość, nie trzeba jednak koniecznie łamać RSA! Treść wiadomości jest przecież w istocie szyfrowana - jak wiemy - "klasycznym" szyfrem z tajnym kluczem. "Wystarczy" złamać ten klucz... Tu sytuacja wydaje się jednakże jeszcze gorsza (rzecz jasna, dla osoby chcącej złamać szyfr, nie dla jego użytkownika) - współczesne algorytmy szyfrowania "tradycyjnego" osiągnęły taki poziom doskonałości, że praktycznie nie poddają się żadnym typowym metodom kryptoanalizy - porównaniu z tekstem jawnym itp. Jedyną szansą ich złamania - realną dzięki znacznemu wzrostowi mocy obliczeniowej komputerów - pozostaje atak typu "brute force" (czyli "na siłę"), tzn. wypróbowanie po kolei wszystkich możliwych kluczy. Najistotniejszą rolę odgrywa w tym przypadku rzecz jasna długość klucza - im jest on dłuższy, tym więcej możliwości do wypróbowania, a zatem tym bezpieczniejszy szyfr. Na początku 1996 r. ukazał się ciekawy raport opracowany przez grupę kryptologów dla Business Software Alliance [6], podający przybliżone czasy łamania szyfrów o różnych długościach klucza przez różne kategorie atakujących. Okazuje się, że szyfry o kluczach 40-bitowych, stosowane w "eksportowych" wersjach np. przeglądarek WWW (jest to obecnie w praktyce największa długość klucza, jaka uzyskuje licencję eksportową USA), nie zapewniają praktycznie żadnej ochrony - nawet pojedynczy hacker, wykorzystujący do obliczeń "jałowy" czas kilku komputerów, np. na uczelni (gdy nie wykonują one żadnych użytecznych prac użytkowników), może złamać ten szyfr w przeciągu ok. tygodnia. Jeżeli ten sam hacker jest w stanie zainwestować 400 dolarów w komputer z kartą FPGA (pozwalającą wykonywać pewne specyficzne rodzaje obliczeń ok. 1000 razy szybciej niż na zwykłym PC), wynik otrzyma po pięciu godzinach. W przypadku dużych firm, mogących zainwestować znacznie większe sumy w specjalizowane komputery, czasy łamania szyfru 40-bitowego mierzy się już w sekundach, a nawet ich ułamkach - w przypadku agencji wywiadowczej, którą zdaniem autorów raportu stać na zainwestowanie 300 milionów dolarów w sprzęt do łamania szyfrów, czas ten wynosi 0,0002 sekundy! Zastosowanie szyfru DES, z 56-bitowym kluczem, niewiele poprawia bezpieczeństwo: złamanie szyfru jest teraz wprawdzie raczej poza zasięgiem indywidualnego hackera (38 lat), a nawet małej firmy (ok. 1,5 roku), ale już średniej wielkości firmie (sprzęt za 300 tys. dolarów) zajmie to 3 godziny, a agencji wywiadowczej - zaledwie 12 sekund.

O złamaniu tą metodą szyfru 128-bitowego, jakim jest IDEA, nie ma jednak co marzyć - trwałoby to 272 razy dłużej niż dla szyfru 56-bitowego, a więc nawet agencji wywiadowczej zajęłoby... 100 bilionów lat! (obecny wiek Wszechświata szacuje się na "zaledwie" ok. 10 miliardów lat). Ciekawe natomiast może być obliczenie na podstawie tych danych przewidywanych czasów łamania (faktoryzacji) klucza RSA. Wg danych z [5], faktoryzacja 512-bitowego klucza RSA wymaga mniej więcej tyle czasu, co łamanie 64-bitowego klucza "zwykłego" szyfru metodą brute force. Można zatem obliczyć, że średnia firma jest w stanie złamać taki klucz w ciągu miesiąca, duża firma - w ciągu jednego dnia, a agencja wywiadowcza - w 59 minut. W przypadku klucza 768-bitowego (równoważnego 80-bitowemu kluczowi "zwykłego" szyfru) jakieś szanse ma jedynie agencja wywiadowcza: 6,5 roku. Klucz 1024-bitowy - przy założeniu, iż nie nastąpią jakieś przełomowe, jakościowe zmiany w teorii liczb albo w technologii komputerowej - powinien zapewniać nam absolutne bezpieczeństwo: jego faktoryzacja wymaga od agencji wywiadowczej poświęcenia 6,5 miliona lat.

Cały ten przydługi wywód wskazuje na to, że póki co możemy spokojnie używać PGP do ochrony naszej poczty. Chyba, że jakieś władze zechcą "zrobić z tym porządek" i zakażą stosowania szyfrowania, bądź też zezwolą na nie jedynie pod warunkiem udostępnienia służbom specjalnym wszystkich kluczy prywatnych - jak to już wielokrotnie w wielu krajach próbowano uczynić, a w niektórych nawet doprowadzono do skutku. Wówczas tylko przestępcy będą mogli swobodnie korzystać z PGP...


Literatura.

1. Szymon Sokół, Opis systemu PGP dla laika, http://galaxy.uci.agh.edu.pl/~szymon/pgp_opis.html
2. Adam Back, PGP Timeline, http://www.cypherspace.org/~adam/timeline/
3. Stale Schumacher, International PGP FAQ, http://www.pgpi.org/doc/faq/pgpi/
4. RSA Labs FAQ on Cryptography, http://www.rsasecurity.com/rsalabs/faq/
5. PGP Attack FAQ, http://axion.physics.ubc.ca/pgp-attack.html
6. Matt Blaze et al., Minimal Key Lengths for Symmetric Ciphers..., http://theory.lcs.mit.edu/~rivest/bsa-final-report.ascii


* Stan opisywany w artykule dotyczy wersji 2.x programu PGP i był aktualny w maju 1997 r.; obecne wersje programu PGP mają inne warunki licencjonowania, stosują inne szyfry i pracują w środowisku Windows - więcej informacji można znaleźć tutaj. Wielu użytkowników jednak nadal używa wersji 2.x z uwagi na kompatybilność.
** Obecnie część firmy Network Associates Inc.


Jarosław Rafa 1997. Tekst udostępniony na licencji Creative Commons (uznanie autorstwa - użycie niekomercyjne - bez utworów zależnych). Kliknij tutaj, aby dowiedzieć się, co to oznacza i co możesz z tym tekstem zrobić. W razie jakichkolwiek wątpliwości licencyjnych bądź w celu uzyskania zgody na rozpowszechnianie wykraczające poza warunki licencji proszę o kontakt e-mailem: raj@ap.krakow.pl.

Wersja HTML opracowana 25.06.97, uzupełnienie 22.07.99, ostatnia aktualizacja adresów 1.06.2000.


Powrót do wykazu artykułów o Internecie Statystyka