   #Start Contents

                         Jak nauczyc sie szyfrowania

   Na pewno kazdemu z Was zdarzylo sie kiedys wyslac e-maila, ktorego
   tresc powinna byc przeczytana wylacznie przez odbiorce. Mogl to byc
   list sluzbowy, zawierajacy wazne dane finansowe lub list bardzo
   prywatny. Na pewno nie chcielibyscie, by taki list byl przeczytany
   przez niewlasciwa osobe: szpiega przemyslowego, wscibskie rodzenstwo
   itd.

   Tymczasem, nawet jesli odbiorca chroni swoj program pocztowy haslem,
   to i tak Wasz list, zanim do niego trafi, przechodzi (w postaci
   jawnej) przez jakies 20-30 serwerow.

   Nie wierzycie? Wykonajcie polecenie traceroute
   smtp.wasz.serwer.pocztowy.pl (pod Windows jest tracert).

   To polecenie pokazuje, jaka droge przebywaja pakiety (a wiec i list),
   zanim dotra do Waszego serwera pocztowego. Potem jeszcze wasz list
   przechodzi od tego serwera do serwera pocztowego odbiorcy, a potem do
   niego samego. Dluga trasa, nieprawdaz? A do tego na kazdym
   skrzyzowaniu (routerze) czeka potencjalne zagrozenie.
   Ten krotki artykul uswiadomi Wam, jak latwo jest chronic swoja poczte
   przed nieodpowiednimi osobami oraz dac odbiorcy calkowita pewnosc, ze
   dany list pochodzi wlasnie od Was.

   Spis tresci:
     * Certyfikaty cyfrowe S/MIME
     * Klucze PGP (Pretty Good Privacy)
     * Szyfrowanie danych na dysku
     * Zabezpieczanie danych przesylanych przez siec
     * Jak to wszystko naprawde dziala
     _________________________________________________________________

S/MIME (certyfikaty cyfrowe, identyfikatory cyfrowe)

   (przeskocz do PGP)

   Skrot S/MIME oznacza Secure Multipurpose Internet Mail Extensions.
   Jest to pewien standard, rozszerzajacy normalne MIME o mozliwosci
   szyfrowania. S/MIME opiera sie na certyfikatach cyfrowych, ktore
   zawieraja informacje o tym, kto jest wlascicielem certyfikatu, oraz na
   kluczach danej osoby: prywatnym i publicznym.

   Certyfikaty w standardzie PKCS, o ktorych tu mowa, NIE sa zgodne z
   kluczami w standardzie PGP/OpenPGP, ktore omowie pozniej.

   Klucz prywatny - sluzy do odszyfrowywania odebranych wiadomosci oraz
   do cyfrowego podpisywania wysylanych przez nas wiadomosci. Dzieki temu
   odbiorca wie, ze ich tresc nie zostala zmieniona po drodze oraz ze
   wiadomosc rzeczywiscie pochodzi od Was. Musi wiec byc dobrze
   chroniony!

   Klucz publiczny - moze byc dowolnie rozdawany, gdyz to on umozliwia
   innym wysylanie nam zaszyfrowanych wiadomosci oraz sprawdzania
   cyfrowego podpisu w wiadomosciach wyslanych przez nas. Musimy posiadac
   klucz publiczny (certyfikat publiczny) osoby, do ktorej chcemy wysylac
   zaszyfrowane wiadomosci.

   Aby moc wysylac odbiorcy zaszyfrowane wiadomosci, wystarczy posiadac
   jego certyfikat publiczny (ktory zawiera takze klucz publiczny).
   Samemu teoretycznie nie trzeba miec certyfikatu, ale wiekszosc
   programow pocztowych odmowi szyfrowania listow bez posiadania wlasnego
   certyfikatu, bo nie bedzie ich potem mozna odszyfrowac.

   Ze wzgledow bezpieczenstwa, nie mozna tez szyfrowac do odbiorcy,
   ktorego certyfikat stracil waznosc.

   A jak zdobyc dla siebie certyfikat? Jest kilka sposobow:
   (przeskocz sposoby)
     * wykupic w znanej firmie, na przyklad Verisign, Comodo, Thawte,
       GlobalSign. W Polsce certyfikaty wydaje na przyklad Unizeto
       Certum.
       Jesli certyfikat ma byc bardzo wiarygodny (a wiec i drozszy), to
       nalezy podac firmie duzo szczegolow o sobie. W zamian dostajemy
       certyfikat oznaczony duzym zaufaniem i rozpoznawany przez
       wiekszosc programow pocztowych.
     * dostac za darmo w znanej firmie, na przyklad CAcert, Comodo.
       Zazwyczaj taki certyfikat bedzie mial klucz sredniej dlugosci (a
       wiec i sredniej sile szyfrowania), na przyklad 512 bitow, zwykle
       nie bedzie w nim naszego imienia, tylko adres e-mail (ktory zawsze
       musi byc), a certyfikat (skoro nie podalismy zadnych danych
       pozwalajacych na identyfikacje) bedzie mial nizszy stopien
       zaufania i krotki okres waznosci. Dlatego polecam Comodo, gdyz
       mozna tam wpisac swoje imie i wybrac dlugosc klucza, a certyfikat
       bedzie wazny przez rok (co jest dosc dlugim okresem w porownaniu z
       innymi).
     * wyrobic sobie samemu - wystarczy dowolny system operacyjny z
       zainstalowanym pakietem OpenSSL na przyklad Linux (ale sa tez
       wersje OpenSSL dla Windows).
       Zalety takiego rozwiazania sa duze:
          + mozna wybrac klucz dowolnej dlugosci (na przyklad 4096
            bitow!)
          + certyfikat bedzie zawieral nasze imie i wszystkie dane, ktore
            chcemy umiescic
          + moze byc wazny nawet przez 30 lat!
       Jedyna wada bedzie to, ze nie bedzie zaufany przez zadna znana
       firme, ale z tym tez mozna sobie poradzic.

   Jako ze wyrobienie certyfikatu przez WWW trwa tylko kilka minut i jest
   dosc proste, nie bede sie tym zajmowal. Firmy wydajace posiadaja dosc
   dobre instrukcje, co nalezy wykonac.
   Zamiast tego opisze tutaj szczegolowo, co nalezy zrobic, aby wyrobic
   go sobie samemu.

   Wyrabianie certyfikatu z wykorzystaniem oprogramowania OpenSSL:
    1. Wykonanie certyfikatu podpisanego przez samego siebie, o
       2048-bitowym kluczu RSA (oficjalnie zalecana minimalna dlugosc to
       1024 bity), waznego przez okolo 30 lat:
       (przeskocz wyrabianie certyfikatu prywatnego)
       openssl req -x509 -days 10950 -newkey rsa:2048 -keyout
       cert1_key.pem -out cert1_cert.pem
       UWAGA: podany tu czas waznosci certyfikatu w dniach (10950) jest
       bliski gornemu limitowi (czy to limit OpenSSL, czy programow
       pocztowych, czy tez samego standardu). Przekroczenie tej liczby
       moze spowodowac, ze certyfikat bedzie rozpoznawany, ale
       bezuzyteczny!
       UWAGA: domyslne ustawienia OpenSSL moga spowodowac wygenerowanie
       certyfikatu, ktorego algorytm podpisu nie jest juz bezpieczny (np.
       MD5) i bedzie odrzucany np. przez programy pocztowe. Aby tego
       uniknac, mozna podac recznie nazwe algorytmu podpisu, np. SHA512.
       Prawidlowe rozpoznanie takiego certyfikatu zalezy jednak od
       mozliwosci oprogramowania (systemow operacyjnych, programow
       pocztowych), ktore ma go uzywac. Nalezy wiec najpierw upewnic sie,
       ze dany algorytm podpisu jest obslugiwany. Przyklad wyrabiania
       certyfikatu z algorytmem SHA512:
       (przeskocz wyrabianie certyfikatu prywatnego)
       openssl req -x509 -days 10950 -newkey rsa:2048 -sha512 -keyout
       cert1_key.pem -out cert1_cert.pem
       Nalezy podac tyle informacji o sobie, aby certyfikat byl
       wiarygodny. Zalecam wpisac:
          + adres e-mail (bez tego w ogole nie bedzie mozna korzystac z
            certyfikatu). Jesli posiadacie wiecej niz jeden adres e-mail,
            to na kazdy z tych adresow mozecie wyrobic osobny certyfikat
            lub skorzystac z Subject Alternative Names (SAN).
            Aby skorzystac z SAN, nalezy stworzyc kopie domyslnego pliku
            konfiguracyjnego (OpenSSL wyswietla, gdzie on sie znajduje),
            po czym otworzyc plik w edytorze tekstu i pod koniec sekcji
            usr_cert, a przed sekcja v3_req dodac liste swoich adresow
            e-mail:
        subjectAltName = @alt_names
        [ alt_names ]
        email.1   = adres1@domena1.com
        email.2   = adres2@domena2.com
        ...
            oraz powiedziec programowi openssl, aby skorzystal z tego
            pliku za pomoca opcji -config nasza_kopia_openssl.cnf
          + swoje pelne imie i nazwisko
          + miasto zamieszkania, region, kraj
       Aby cala zabawa miala sens, nasz klucz prywatny musimy ochronic
       dobrym haslem (czyli: co najmniej 8 znakow, litery duze i male,
       cyfry i znaki specjalne).
       Plik cert1_key.pem zawiera wasz klucz prywatny, musi wiec byc
       dobrze chroniony.
       Wasz klucz prywatny nigdy nie zostanie wyslany przez zaden
       wiarygodny program pocztowy wbrew Waszej woli.
    2. Wyeksportowanie naszego certyfikatu do formatu PKCS#12,
       przyjmowanego przez wiekszosc programow pocztowych:
       (przeskocz eksport certyfikatu)
       openssl pkcs12 -export -in cert1_cert.pem -inkey cert1_key.pem
       -out cert1.p12 -name "Moj certyfikat"
       W tracie wykonywania tego polecenia bedziemy poproszeni o haslo
       chroniace nasz klucz prywatny (to, ktore wpisalismy w kroku 1)
       oraz o nowe haslo eksportowe, chroniace caly plik P12, lacznie z
       kluczem prywatnym. Jesli nie zamierzacie po wszystkim skasowac
       pliku P12 (zachowujac pliki .pem), to w dalszym ciagu obowiazuja
       powyzsze reguly dobrego hasla.
       Plik cert1.p12 zawiera wasz klucz prywatny i publiczny, musi wiec
       byc dobrze chroniony.
       Instrukcje na temat tego, jak zainstalowac i korzystac z
       certyfikatu w swoim programie pocztowym powinniscie znalezc w
       zasobach pomocy do tego programu.
       Jesli korzystacie z Thunderbirda, to najpierw zainstalujcie plik
       DER (patrz nizej).
       Potem wybierzcie Edycja(Narzedzia)--> Preferencje--> Zaawansowane
       (lub Prywatnosc i Bezpieczenstwo)-->Menedzer certyfikatow (lub
       Zarzadzaj certyfikatami)--> Twoje certyfikaty (lub Uzytkownik)-->
       Importuj. Nalezy podac haslo chroniace plik P12 oraz haslo
       "Glownego Urzadzenia zabezpieczajacego" (Software Security
       Device). To drugie bedzie sluzyc do obslugi wszystkich
       certyfikatow (abyscie nie musieli pamietac wszystkich hasel do
       kluczy prywatnych).
       Jesli Thunderbird wyswietla, ze haslo jest nieprawidlowe, a do
       wygenerowania pliku P12 uzyliscie OpenSSL w wersji 3.0.0, nalezy
       do komendy eksportu dodac opcje -legacy:
       openssl pkcs12 -legacy -export ...
       Potem juz tylko Edycja--> Konfiguracja kont--> pod wybranym
       kontem: Zabezpieczenia (lub Szyfrowanie "end-to-end" i sekcja
       S/MIME)--> Wybierz certyfikat i "Podpisz wiadomosci cyfrowo
       (domyslnie)" (lub "Domyslnie dodawaj moj podpis cyfrowy").
       Mozemy juz cyfrowo podpisywac wiadomosci, ale nikt do nas nie
       bedzie szyfrowal, jesli nie rozdamy innym naszego certyfikatu
       publicznego.
    3. Niektore programy pocztowe beda wymagac, aby nasz certyfikat byl
       wystawiony przez znana im firme. Dlatego zainstalujemy im nasz
       certyfikat jako certyfikat firmy wystawiajacej (Certificate
       Authority, CA). Oto, co nalezy zrobic:
       (przeskocz wyrabianie certyfikatu wystawcy)
       openssl x509 -in cert1_cert.pem -outform DER -out cert1_cert.der
       Otrzymany plik DER instalujemy w programie pocztowym w miejscu
       przeznaczonym dla wystawcow certyfikatow, z pelnym zaufaniem i
       nasz certyfikat zdobywa zaufanie programu.
    4. Wyrobienie certyfikatu publicznego z pliku P12 odbywa sie tak:
       (przeskocz wyrabianie certyfikatu publicznego)
       openssl pkcs12 -in cert1.p12 -out cert1_pub.pem -nokeys -clcerts
       openssl x509 -in cert1_pub.pem -outform DER -out cert1_pub.cer
       openssl crl2pkcs7 -nocrl -certfile cert1_pub.pem -outform DER -out
       cert1_pub.p7b
       Otrzymane w ten sposob pliki PEM, CER i P7B zawieraja ten sam Wasz
       certyfikat PUBLICZNY (zawierajacy klucz publiczny), tylko w
       roznych formatach, odpowiednich dla roznych programow pocztowych.
       Jest to ten sam certyfikat, ktory byl w pliku cert1_cert.pem.
       Te pliki umieszczajcie wszedzie, gdzie to jest tylko mozliwe tak,
       by jak najwiecej osob mialo do nich dostep (na przyklad na swojej
       stronie WWW).
       Mozliwe jest, ze wraz ze swoim certyfikatem publicznym bedziecie
       musieli wysylac tez certyfikat wystawcy, utworzony punkt
       wczesniej.
       Dla bezpieczenstwa mozecie tez oprocz samych plikow certyfikatow,
       podawac tez ich skroty (odciski palcow). Wyciaga sie je w
       nastepujacy sposob:
       openssl x509 -in cert1_pub.pem -noout -fingerprint -md5
       openssl x509 -in cert1_pub.pem -noout -fingerprint -sha1
       w wyniku otrzymujac cos postaci:
       MD5 Fingerprint=76:7C:08:0C:55:3E:67:58:FF:15:88:D0:C5:D9:9D:8A
       SHA1
       Fingerprint=13:29:5D:79:D6:A5:B2:7A:A3:FD:A5:48:1D:E3:E0:EC:52:E0:
       63:0B
       Mozecie tez w ten sposob weryfikowac, czy pobraliscie prawidlowo
       certyfikaty innych osob.
    5. Wykonanie certyfikatu glownego do podpisywania innych.
       (przeskocz wyrabianie certyfikatu glownego)
       Jesli po wykonaniu powyzszych punktow dziala szyfrowanie,
       podpisywanie, importowanie waszych certyfikatow u odbiorcy (czyli
       wszystko jest w porzadku), to pomincie ten punkt.
       Moze sie zdarzyc ze mimo zaimportowania (Waszego) certyfikatu
       wystawcy, program pocztowy odbiorcy dalej uparcie nie chce
       zaimportowac Waszego certyfikatu publicznego. W takim przypadku
       nie kasujcie od razu tamtych plikow, tylko czytajcie dalej (jesli
       jednak skasowaliscie, mozecie sobie wyrobic od nowa, wedlug punktu
       1, lub od razu jako zadanie podpisania certyfikatu, pomijajac
       opcje -x509 w punkcie 1).
       Musicie sobie wyrobic mocny certyfikat glowny i uzyc go do
       podpisania certyfikatow, ktore wyrobiliscie na poszczegolne adresy
       e-mail.
       Certyfikat glowny to nic innego jak samopodpisany certyfikat, wiec
       powtarzamy czynnosci z punktow 1 i 3 powyzej. Jako ze certyfikatu
       glownego nie polecam do szyfrowania poczty, mozna pominac adres
       e-mail, oraz dac lepszy klucz (na przyklad 4096 bitow).
       Teraz certyfikaty na kazda skrzynke, ktore wyrobiliscie wczesniej,
       zamieniamy na zadania podpisania certyfikatu, dzieki czemu bedzie
       je mozna podpisac naszym swiezym certyfikatem glownym:
       openssl x509 -x509toreq -signkey cert1_klucz.pem -in
       cert1_cert.pem -out cert1_req.pem
       Tak utworzone zadanie podpisujemy naszym certyfikatem glownym:
       openssl ca -days 10000 -cert cert_glowny.pem -keyfile
       cert_glowny_klucz.pem -in cert1_req.pem -out cert_nowy.pem
       UWAGA: podany tu czas waznosci certyfikatu w dniach (10000) jest
       bliski gornemu limitowi (czy to limit OpenSSL, czy programow
       pocztowych, czy tez samego standardu). Przekroczenie liczby 10950
       moze spowodowac, ze certyfikat bedzie rozpoznawany, ale
       bezuzyteczny i zadne podpisane nim certyfikaty nie beda mogly byc
       importowane przez programy pocztowe!
       UWAGA: jesli certyfikat do podpisania zawiera inny algorytm
       podpisu niz domyslny, to aby go zachowac, nalezy powtorzyc go w
       poleceniu podpisania, np. dla SHA512:
       openssl ca -days 10000 -cert cert_glowny.pem -keyfile
       cert_glowny_klucz.pem -in cert2_req.pem -md sha512 -out
       cert_nowy.pem
       W celu zachowania Subject Alternative Names, nalezy ponownie uzyc
       opcji -config nasza_kopia_openssl.cnf z tym samym plikiem
       konfiguracyjnym.
       Z plikow cert_nowy.pem i cert2_klucz.pem (klucz bez zmian)
       tworzymy plik PKCS#12 (wedlug punktu 2) dla naszego programu
       pocztowego oraz certyfikaty publiczne dla odbiorcow naszej poczty,
       wedlug punktu 4. Odbiorcom naszej poczty dajemy swoj nowy
       certyfikat publiczny (na przyklad cert2.cer) i plik DER otrzymany
       z certyfikatu glownego wedlug punktu 3, ktory instalujemy tez u
       siebie jako wystawce certyfikatow (z pelnym zaufaniem).

   Wiekszosc programow pocztowych zaimportuje automatycznie Wasz
   certyfikat u odbiorcy, gdy po raz pierwszy otworzy on otrzymana od Was
   wiadomosc podpisana cyfrowo. Do cyfrowego podpisania wiadomosci
   uzywany jest klucz prywatny, ale podczas tej operacji sam klucz
   prywatny NIGDY nie jest wysylany, jest bezpiecznie przechowywany przez
   program pocztowy.

   Osoby majace Wasz certyfikat publiczny moga do Was szyfrowac. Abyscie
   i Wy mogli to robic, musicie miec certyfikat publiczny odbiorcy.
   Najprosciej jest poprosic tego kogos, aby przyslal Wam wiadomosc
   podpisana cyfrowo. Mozna tez wymienic sie certyfikatami publicznymi
   poprzez wyslanie ich jako zalacznikow do listow lub w dowolny inny
   sposob.

   Wazne, aby sprawdzic, czy odciski palcow certyfikatow zgadzaja sie z
   tymi u nadawcy.

   Od tej pory wasza korespondencja nie bedzie mogla byc przeczytana ani
   sfalszowana przez innych.

   UWAGA: Najlepiej wszystkie wytworzone pliki nalezy zachowac w kilku
   bezpiecznych miejscach (na przyklad na plycie CD-R, ktora potem
   starannie schowamy). Najwazniejsze sa cert1_key.pem i cert1_cert.pem,
   bo z nich da sie odtworzyc reszte.

   NIGDY nie nalezy umieszczac swoich kluczy prywatnych na zadnych
   publicznie dostepnych serwerach.

   Jesli chcecie do kogos recznie zaszyfrowac jakis plik, niekoniecznie
   wysylajac e-mail, mozecie to zrobic na jeden z nastepujacych sposobow.
    1. Szyfrowanie kluczem publicznym odbiorcy i swoim (aby moc to potem
       rozszyfrowac), nierozsadne bez podpisu:
       (przeskocz reczne szyfrowanie)
       openssl smime -encrypt -in dane.txt -out dane.aes -from
       adres@nadawcy -to adres@odbiorcy -subject "Tajna wiadomosc"
       -aes256 cert_publ_odbiorcy1.pem cert_publ_odbiorcy2.pem
       Powyzsza komenda ma byc w jednej linijce, a jako jeden z
       certyfikatow odbiorcow podaj swoj certyfikat publiczny!
       Wada tego podejscia jest to, ze wynik jest w postaci czesci (lub
       calej) gotowej wiadomosci e-mail, ale z tym tez mozna sobie
       poradzic.
       Opcja -encrypt oczywiscie wlacza szyfrowanie.
       Opcje -in i -out okreslaja pliki, z ktorych brac dane do
       zaszyfrowania i gdzie je po zaszyfrowaniu umiescic.
       Opcje -from, -to i -subject okreslaja odpowiednio: adres nadawcy,
       adres odbiorcy i temat wiadomosci (wynik tego polecenia mozna
       wyslac jak e-mail, na przyklad przez sendmail).
       Opcja -aes256 okresla typ uzytego szyfru: 256-bitowy AES.
       Odszyfrowanie odbywa sie tak:
       openssl smime -decrypt -in dane.aes -inkey nasz_klucz_pryw.pem
       -recip nasz_cert_publ.pem
       Opcja -recip okresla certyfikat publiczny odbiorcy (nasz).
    2. Szyfrowanie kluczem publicznym odbiorcy i swoim oraz cyfrowe
       podpisanie danych:
       (przeskocz reczne szyfrowanie z podpisem)
       openssl smime -sign -in dane.txt -signer nasz_cert_publiczny.pem
       -inkey nasz_klucz_pryw.pem | openssl smime -encrypt -out dane.aes
       -from adres@nadawcy -to adres@odbiorcy -subject "Tajna wiadomosc"
       -aes256 cert_publ_odbiorcy1.pem cert_publ_odbiorcy2.pem
       Powyzsza komenda ma byc w jednej linijce, a jako jeden z
       certyfikatow odbiorcow podaj swoj certyfikat publiczny!
       Zauwaz symbol potoku |, otrzymywany jako Shift+\.
       Podobnie jak wyzej, wynik jest w postaci gotowej wiadomosci
       e-mail.
       Opcja -sign powoduje cyfrowe podpisanie wiadomosci.
       Opcje -signer i -inkey pozwalaja wybrac certyfikat i klucz
       podpisujacy.
       Odszyfrowanie i weryfikacja odbywaja sie tak:
       (przeskocz weryfikacje i odszyfrowanie)
       openssl smime -decrypt -in dane.aes -inkey nasz_klucz_pryw.pem
       -recip nasz_cert_publ.pem | openssl smime -verify -CAfile
       plik_z_CA.pem -signer cert_publ_nadawcy.pem
       Opcja -CAfile pozwala okreslic plik z zaufanymi certyfikatami
       (czasem po prostu wystarczy cert_publ_nadawcy.pem).
    3. Szyfrowanie na haslo (szyfrem symetrycznym)
       (przeskocz szyfrowanie na haslo)
       Najpierw sprawdzamy, jakie szyfry symetryczne obsluguje nasz
       program openssl:
       openssl list-cipher-commands
       Potem wybieramy jeden z nich, na przyklad Blowfish (bf).
       Szyfrowanie odbywa sie tak:
       openssl enc -bf -a -salt -in dane.txt -out dane.txt.bf
       Opcja -bf wlacza szyfrowanie wlasnie algorytmem Blowfish.
       Opcja -salt wprowadza dodatkowa losowosc do klucza generowanego z
       hasla. Zalecane!
       Opcja -a wlacza kodowanie zaszyfrowanych danych algorytmem BASE64,
       zeby zamiast "krzaczkow", w pliku wyjsciowym byly normalne znaki
       ASCII.
       NIE polecam szyfrow: IDEA, RC2, RC4, RC5 i dalszych RC, gdyz sa
       one objete patentami.
       NIE polecam szyfrow: des-cbc, des, des-cfb, des-ofb, des-ecb ze
       wzgledu na slaba sile szyfrowania (klucz ma 56 bitow dlugosci, co
       na dzisiejsze standardy jest o wiele za malo).
       Wsrod szyfrow moze byc wymieniony takze "base64", ale UWAGA: to
       nie jest szyfr! To jest tylko rodzaj kodowania, jak alfabet
       Morse'a i kazdy moze to odczytac. Jest to po prostu zamiana danych
       w postaci binarnej (z "krzaczkami") wlasnie na postac tekstowa
       ASCII (litery i znaki drukowalne).
       Odszyfrowanie odbywa sie tak:
       openssl enc -bf -a -in dane.txt.bf -d -out dane
       Opcja -d sluzy wlasnie do odszyfrowywania.

   Moze sie zdarzyc, ze chcemy tylko cyfrowo podpisac jakis plik, aby na
   przyklad umiescic go na swojej stronie WWW i dac osobom go sciagajacym
   mozliwosc weryfikacji, ze rzeczywiscie pochodzi od nas.

   Aby utworzyc taki podpis, wystarczy sama komenda podpisywania z punktu
   1 lub 2 powyzej:
   openssl smime -sign -in dane.txt -inkey nasz_klucz_pryw.pem -signer
   nasz_cert_publ.pem -out dane.txt.sig
   Weryfikacja takiego podpisu:
   openssl smime -verify -in dane.txt.sig -CAfile
   cert_publ_podpisujacego.pem -signer cert_publ_podpisujacego.pem

   Jak widac, czasem trzeba powiedziec programowi openssl, jakim
   certyfikatom ufamy - w tym przypadku jest to certyfikat podpisujacy,
   ale moze byc tez nadrzedny.

   Jesli zamiast cyfrowego podpisu chcecie tylko otrzymac sume kontrolna
   z jakiegos pliku (zwana czasem "odciskiem palca"), to najpierw
   sprawdzcie, jakie macie dostepne funkcje skrotu w swoim openssl:
   openssl list-message-digest-commands

   Potem wystarczy wykonac na przyklad
   openssl md5 dane.txt
   i dostajemy:
   MD5(dane.txt)= 5bbd1174b345c17e9dac39e0da0002cd
   NIE polecam funkcji skrotu MD2, MD4, MD5 i SHA1, gdyz odkryto w nich
   pewne slabosci.
     _________________________________________________________________

Pretty Good Privacy (PGP) / GNU Privacy Guard (GPG)

   (przeskocz do szyfrowania plikow)

   Pretty Good Privacy i jego darmowy i wolny odpowiednik - GNU Privacy
   Guard - GPG (wersja dla Windows: gpg4win.org) rowniez opieraja sie na
   parze kluczy: publicznym i prywatnym. Wszystkie zasady ochrony sa
   takie same, jak wczesniej. Ale:
     * Rozni sie sposob wyrabiania kluczy.
     * Klucze wyrobione w standardzie PGP/OpenPGP NIE sa zgodne z
       certyfikatami PKCS, omowionymi wczesniej (z zadnym ich rodzajem,
       mimo iz na przyklad tu i tu sa klucze RSA)

   Wyrabianie kluczy przy uzyciu PGP:

   Jesli macie program PGP dla Windows (jest tez wersja calkowicie
   darmowa: PGP Freeware), to wszystko mozna zrobic przy uzyciu myszy, a
   sam program wspolpracuje z wiekszoscia programow pocztowych i
   automatycznie podpisuje, sprawdza i szyfruje wiadomosci. Nie bede sie
   wiec zajmowal dalszym jego opisem.

   Jesli korzystacie z roznych graficznych nakladek na gpg, to wyrobienie
   kluczy jest kwestia kilku klikniec, wiec nie bede sie tym zajmowal
   (tym bardziej ze takich interfejsow jest wiele). Pokaze za to, jak
   wyrabiac klucze samym programem gpg:

   Nalezy wydac polecenie gpg --gen-key, a GPG dalej nas sam poprowadzi.
   W zasadzie nalezy wybierac to, co jest domyslne (default), czyli
   ciagle wciskac Enter. Jedynie mozna sobie wybrac dluzszy klucz (na
   przyklad 2048 bitow) zamiast domyslnych 1024 bitow.

   Po zakonczeniu tworzenia kluczy, mozemy wyswietlic ich liste: gpg
   --list-keys

   Klucz prywatny - sluzy do odszyfrowywania odebranych wiadomosci oraz
   do cyfrowego podpisywania wysylanych przez nas wiadomosci. Dzieki temu
   odbiorca wie, ze ich tresc nie zostala zmieniona po drodze oraz ze
   wiadomosc rzeczywiscie pochodzi od Was. Musi wiec byc dobrze
   chroniony!

   Klucz publiczny - moze byc dowolnie rozdawany, gdyz to on umozliwia
   innym wysylanie nam zaszyfrowanych wiadomosci oraz sprawdzania
   cyfrowego podpisu w wiadomosciach wyslanych przez nas. Musimy posiadac
   klucz publiczny osoby, do ktorej chcemy wysylac zaszyfrowane
   wiadomosci.

   Po wyrobieniu kluczy, nalezy dla bezpieczenstwa (na przyklad aby moc
   je odzyskac w razie awarii) wyeksportowac swoj klucz prywatny i
   publiczny:
   (przeskocz eksport kluczy)
   gpg --output klucz_gpg_pryw.asc --textmode --export-secret-keys
   --armor AABBCCDD
   gpg --output klucz_gpg_publ.asc --textmode --export --armor AABBCCDD
   (w miejsce AABBCCDD nalezy wstawic numer swojego klucza uzyskany
   komenda gpg --list-keys).

   Tak przygotowany plik klucz_gpg_publ.asc, zawierajacy klucz publiczny,
   mozna rozsylac poczta i umieszczac na publicznych serwerach, stronach
   WWW itp., by jak najwiecej osob mialo do niego dostep.

   Dla bezpieczenstwa mozecie tez oprocz samych plikow kluczy, podawac
   tez ich skroty (odciski palcow). Wyciaga sie je w nastepujacy sposob:
   gpg --fingerprint 1C56DA1E
   w wyniku otrzymujac cos postaci:
pub   1024D/1C56DA1E 2004-11-06
      Odcisk klucza = E91E 699F 1026 D0EF 745E  EC3B 353A D368 1C56 DA1E

   Mozecie tez w ten sposob weryfikowac, czy pobraliscie prawidlowo
   klucze innych osob.

   Plik klucz_gpg_pryw.asc zawiera wasz klucz prywatny, musi wiec byc
   dobrze chroniony.

   UWAGA:
   Klucz prywatny nalezy zachowac w kilku bezpiecznych miejscach (na
   przyklad na plycie CD-R, ktora potem starannie schowamy). NIGDY nie
   nalezy umieszczac swoich kluczy prywatnych na zadnych publicznie
   dostepnych serwerach.

   Wiekszosc roboty (import kluczy, sprawdzanie podpisow, szyfrowanie)
   beda wykonywac za nas programy pocztowe. Niektore maja wbudowana
   obsluge GPG (na przyklad Sylpheed lub nowy Thunderbird), do niektorych
   potrzebne sa zewnetrzne moduly, ktore tez beda automatycznie
   wykonywaly robote (na przyklad pine-pgp do PINE'a, czy Enigmail do
   starszych wersji Thunderbirda).

   Aby moc uruchomic szyfrowana korespondencje, nalezy wymienic sie z
   odbiorca kluczami publicznymi, na przyklad
     * dostac osobiscie od tej osoby (na dyskietce, plycie, ...)
     * poprosic go o wyslanie nam wiadomosci z zalacznikiem w postaci
       klucza w pliku .asc, ktory sami zaimportujemy.
     * sciagnac ze strony WWW tej osoby i zaimportowac recznie: gpg
       --import plik_z_kluczem.asc
     * sciagnac z jednego z serwerow kluczy (jesli znamy numer klucza, a
       wlasciciel umiescil go na serwerze): gpg --keyserver
       wwwkeys.pgp.net --recv-keys AABBCCDD

   Od tej pory wasza korespondencja nie bedzie mogla byc przeczytana ani
   sfalszowana przez innych.

   Jesli chcecie do kogos recznie zaszyfrowac jakis plik, niekoniecznie
   wysylajac e-mail, mozecie to zrobic na jeden z nastepujacych sposobow.
   Odbiorce mozecie podac z nazwiska, numeru klucza lub adresu e-mail.
    1. szyfrowanie kluczem publicznym odbiorcy i swoim (aby moc to potem
       rozszyfrowac), nierozsadne bez podpisu:
       (przeskocz szyfrowanie PGP bez podpisu)
       gpg -a -e -r odbiorca1 -r odbiorca2 dane.txt (jeden z odbiorcow to
       Wy - podajecie swoj e-mail lub numer klucza).
       Potem dajecie odbiorcom plik dane.txt.asc, ktory mozna
       rozszyfrowac tak: gpg dane.txt.asc Opcja -a powoduje, ze w pliku
       wyjsciowym beda tylko normalne znaki ASCII, zadnych "krzaczkow".
       Gdybysmy nie podali -a, program gpg utworzylby ten sam plik, ale w
       postaci binarnej: dane.txt.gpg, zawierajacy "krzaczki".
       Opcja -e oznacza wlasnie szyfrowanie (domyslne dzialanie gpg to
       rozszyfrowywanie).
       Po opcji -r podajemy odbiorce.
       Dzieki opcji -R odbiorca2 (nie pokazanej tutaj) pozwala ukryc
       informacje, ze wiadomosc zostala zaszyfrowana takze do innych osob
       (odbiorca2), niz glowny odbiorca.
       Dzieki opcji --multifile (nie pokazanej tutaj) mozna szyfrowac
       wiecej niz jeden plik na raz. Dotyczy to takze dalszych punktow.
    2. szyfrowanie kluczem publicznym odbiorcy i swoim oraz cyfrowe
       podpisanie danych:
       (przeskocz reczne szyfrowanie PGP z podpisem)
       gpg -a -e -s -r odbiorca1 -r odbiorca2 dane.txt
       Rozszyfrowanie jak poprzednio, ale tutaj dodatkowo otrzymacie
       informacje o podpisie.
       Opcja -s wlacza cyfrowe podpisywanie danych. Upewni to odbiorce,
       ze wiadomosc nie zostala sfalszowana.
    3. szyfrowanie na haslo (szyfrem symetrycznym)
       (przeskocz szyfrowanie PGP na haslo)
       Najpierw sprawdzamy, jakie szyfry symetryczne obsluguje nasz
       program gpg: gpg --version (ogladamy liste "Symetryczne" lub
       "Cipher", w zaleznosci od wersji jezykowej programu).
       Potem wybieramy jeden z nich, na przyklad Blowfish. Szyfrowanie
       odbywa sie tak:
       gpg -a --cipher-algo blowfish -c dane.txt
       Opcja -c wlacza szyfrowanie algorytmem symetrycznym.
       Opcja --cipher-algo pozwala wybrac algorytm szyfrowania.
       Dla lepszego zabezpieczenia, mozna polaczyc ten sposob z
       powyzszymi. Dostaniemy wtedy plik, ktory mozna odszyfrowac zarowno
       haslem, jak i kluczem.

   Czesto widac na stronach WWW, ze obok roznych plikow do sciagniecia,
   sa ich podpisy cyfrowe w osobnych plikach. Zrobienie takiego pliku nie
   jest trudne:
   gpg -a -b dane.txt

   Opcja -b powoduje wlasnie utworzenie takiego oddzielnego pliku
   dane.txt.asc z podpisem dla pliku dane.txt. Sam plik dane.txt nie jest
   szyfrowany!
   Gdybysmy nie podali -a, program gpg utworzylby ten sam plik z
   podpisem, ale w postaci binarnej: dane.txt.sig, zawierajacy krzaczki.

   Sprawdzenie takich podpisow jest tez latwe:
   (przeskocz weryfikacje dobrego podpisu)
gpg --verify dane.txt.asc
gpg: Signature made sob 25 mar 2006 14:27:21 CET using DSA key ID 1C56DA1E
gpg: Good signature from "Bogdan Drozdowski <xxxx@yy.pl>"

   Tutaj podpis jest prawidlowy (slowo Good). Oznacza to, ze plik nie
   ulegl zmianom od chwili jego podpisania.

   Gdyby ktos go specjalnie zmienil (lub na przyklad wystapil blad w
   transmisji), podpis bedzie nieprawidlowy (slowo BAD):
   (przeskocz weryfikacje zlego podpisu)
gpg --verify dane.txt.asc
gpg: Signature made sob 25 mar 2006 14:27:21 CET using DSA key ID 1C56DA1E
gpg: BAD signature from "Bogdan Drozdowski <xxxx@yy.pl>"

   Jesli zamiast cyfrowego podpisu chcecie tylko otrzymac sume kontrolna
   z jakiegos pliku (zwana czasem "odciskiem palca"), to najpierw
   sprawdzcie, jakie macie dostepne funkcje skrotu w swoim gpg: gpg
   --version (ogladamy liste "Skrotow" lub "Hash", w zaleznosci od wersji
   jezykowej programu).

   Potem wystarczy wykonac na przyklad
   gpg --print-md sha512 dane.txt
   i dostajemy:
   (przeskocz przyklad sumy kontrolnej)
dane.txt: DB1B46EE C66D6574 ABE6FC48 7EA40F63 B148DAB8 9F9F7142 BDC5E9F6
          55B2924B 71D5C017 04945C48 0EEC28CC E0A7F41B 2BBAEB5A 7DADC7FD
          E0B47FCE 3529F58B

   NIE polecam funkcji skrotu MD5 i SHA1, gdyz odkryto w nich pewne
   slabosci.
     _________________________________________________________________

Szyfrowanie danych na dysku

   (przeskocz do zabezpieczania transmisji)

   Nawet jesli nie musicie szyfrowac poczty, to czesto jest potrzeba
   zaszyfrowania samych danych na dysku (informacji poufnych, sciagnietej
   niezaszyfrowanej poczty, historii przegladanych stron internetowych,
   tresci prowadzonych rozmow). Jest na to wiele sposobow.
    1. Szyfrowanie na haslo.
       Powyzej podalem dwa sposoby szyfrowania na haslo. Niestety, jesli
       chcemy szyfrowac w ten sposob wiele plikow, to te czynnosci staja
       sie nudne, czasochlonne i latwo sie pomylic. Najwygodniej jest na
       przyklad spakowac wszystkie poufne pliki w jedno archiwum. Jesli
       wybierzemy format ZIP lub 7zip, szyfrowanie mozna wlaczyc juz w
       czasie pakowania. Inne spakowane archiwa mozna recznie zaszyfrowac
       na haslo jednym z podanych sposobow. Dzieki temu haslo jest
       wpisywane tylko raz.
       Ma to jednak pewna wade: po skorzystaniu z plikow nalezy je
       ponownie spakowac i usunac z dysku. Jak wiemy, samo usuniecie
       pliku nie wystarcza, gdyz tak naprawde jest usuwana informacja o
       samym istnieniu pliku, zas jego zawartosc nadal pozostaje na
       dysku. Taka zawartosc mozna odzyskac nawet po 2-3 zamazaniach.
       Dlatego niezbedne jest bezpieczne usuwanie plikow (jednym z wielu
       dostepnych darmowych programow, na przyklad shred w Linuksie) i
       zamazanie wolnego miejsca na dysku raz na jakis czas.
    2. Szyfrowanie partycji, calego dysku twardego lub urzadzen
       wymiennych.
       Zamiast ciagle pakowac i rozpakowywac archiwum z tajnymi plikami,
       wygodniejsze moze byc zalozenie sobie szyfrowanej partycji dysku
       twardego (lub nawet calego dysku) lub calego urzadzenia
       przenosnego (na przyklad dysk wymienny na USB). Po podaniu hasla
       takie urzadzenie byloby widoczne w systemie jak normalny dysk
       twardy, z pelna mozliwoscia kopiowania, zapisywania i usuwania
       danych.
       Pod Linuksem sa co najmniej dwa narzedzia oferujace taka
       funkcjonalnosc: losetup oraz cryptsetup-luks, ale ja zalecam
       otwarty program VeraCrypt (nastepce programu TrueCrypt), ktory
       dziala pod Linuksem i Windows, a jest dosc latwy w obsludze - pod
       Windows ma nawet interfejs graficzny, pod Linuksem wystarczy
       uruchomic veracrypt --create, a program dalej poprowadzi
       uzytkownika.
       Pod Linuksem stworzone pliki VeraCrypt montowac nalezy poprzez
       veracrypt -u plikTrueCrypt katalogMontowania, zas sam program
       truecrypt powinien moc byc uruchamiany z prawami administratora
       przez zwyklego uzytkownika. W starszych wersjach programu
       wystarczylo ustawic bit suid komendami wydanymi jako root:
       chown root.root /sciezka/do/veracrypt
       chmod +s /sciezka/do/veracrypt
       chmod o+x /sciezka/do/veracrypt
       Nowsze wersje jednak bardziej dbaja o bezpieczenstwo i bit suid
       juz jest zabroniony. Zamiast tego, VeraCrypt powinien moc sam sie
       uruchomic uzywajac komendy suid. Aby na to zezwolic, jako root
       wydajemy komende visudo. Otwiera ona plik /etc/sudoers w trybie
       edycji i sprawdzania skladni przy wyjsciu (bardzo wazne). Nalezy
       dodac nastepujace linijki:
User_Alias         VeraCrypt = nazwa_uzytkownika1, nazwa_uzytkownika2, ...
Defaults:VeraCrypt !authenticate
VeraCrypt          localhost = (root) /usr/bin/veracrypt
       Wpisujac oczywiscie prawidlowe nazwy uzytkownikow i sciezke do
       VeraCrypt.
       Po skonczeniu pracy szyfrowana partycje w Linuksie nalezy
       odmontowac poleceniem veracrypt -d katalogMontowania
       Jeszcze jedna uwaga: nie wolno normalnie przenosic plikow na
       zaszyfrowana partycje. Przeniesienie plikow moze spowodowac ich
       skopiowanie, po czym normalne usuniecie na dysku zrodlowym (dzieki
       czemu mozna byloby je odzyskac). Nalezy zamiast tego skopiowac te
       pliki, po czym bezpiecznie je usunac z dysku zrodlowego.
       Troche informacji o szyfrowaniu partycji jest tez w dokumencie o
       zabezpieczaniu serwera Tor. O samym programie Tor czytaj ponizej,
       w sekcji o zabezpieczaniu transmisji.
    3. Szyfrowanie pliku lub partycji wymiany (swap).
       Moglibyscie spytac, po co to. Zalozmy, ze wlasnie macie
       uruchomiony program pracujacy na ktoryms z poufnych plikow. Za
       chwile uruchomicie inny duzy program (pakiet biurowy,
       przegladarke, ...). Spowoduje to, ze na wszystkie uruchomione
       programy nie wystarczy pamieci w komputerze. System operacyjny w
       takiej sytuacji przeniesie czesc waszego waznego programu (a
       pewnie i czesc owych poufnych danych) na dysk, do pliku wymiany,
       co jest zupelnie normalnym dzialaniem. Teraz poufne dane leza
       niezaszyfrowane na dysku i kazdy moze je odczytac. Za jakis czas
       te dane zostana stamtad usuniete (moze dopiero po kolejnym
       wlaczeniu komputera?), ale nie jest to usuwanie bezpieczne.
       Oryginalne dane dalej moga sobie byc na szyfrowanej partycji, ale
       w niezaszyfrowanej postaci mozna je odzyskac z dysku.
       Jak sie przed tym bronic? Zalozyc szyfrowana pamiec wymiany.
          + Windows: przeczytaj odpowiednia sekcje dokumentu o
            zabezpieczaniu serwera Tor. O samym programie Tor czytaj
            ponizej, w sekcji o zabezpieczaniu transmisji.
          + OS X: przeczytaj odpowiednia sekcje dokumentu o
            zabezpieczaniu serwera Tor. O samym programie Tor czytaj
            ponizej, w sekcji o zabezpieczaniu transmisji.
          + OpenBSD: w opcjach systemowych /etc/sysctl.conf ustaw
            vm.swapencrypt.enable=1. Przeczytaj tez odpowiednia sekcje
            dokumentu o zabezpieczaniu serwera Tor. O samym programie Tor
            czytaj ponizej, w sekcji o zabezpieczaniu transmisji.
          + Szyfrowana pamiec wymiany we FreeBSD. Przeczytaj tez
            odpowiednia sekcje dokumentu o zabezpieczaniu serwera Tor. O
            samym programie Tor czytaj ponizej, w sekcji o zabezpieczaniu
            transmisji.
          + Linux: skorzystac z programu losetup, cryptsetup-luks lub ze
            skryptow CryptoSwap.
            Przykladowe wykorzystanie cryptsetup: w pliku startowym
            zawierajacym uruchamianie pamieci wymiany (na przyklad
            /etc/rc.sysinit), tuz PRZED linia uruchamiajaca pamiec
            wymiany (linia z komenda swapon), dopiszcie:
            cryptsetup -c blowfish -d /dev/urandom create swap /dev/hdXY
            mkswap /dev/mapper/swap > /dev/null
            zamieniajac, rzecz jasna, /dev/hdXY na Wasza partycje wymiany
            lub nazwe pliku wymiany. Po tych zmianach nalezy otworzyc
            plik /etc/fstab i zmienic urzadzenie wymiany, na przyklad z
            /dev/hdXY swap swap defaults 0 0
            na
            /dev/mapper/swap swap swap defaults 0 0
            W pliku uruchamianym przy zamykaniu systemu i odpowiedzialnym
            za wylaczenie pamieci wymiany (na przyklad
            /etc/rc.d/init.d/halt), tuz PO linii wylaczajacej pamiec
            wymiany (linia z komenda swapoff) nalezy dopisac: cryptsetup
            remove swap
            Po ponownym uruchomieniu systemu pamiec wymiany bedzie
            szyfrowana wybranym algorytmem i za kazdym razem innym,
            losowym kluczem.
            Dla bezpieczenstwa mozna aktualna partycje wymiany zamazac
            poleceniem shred (najlepiej robic to, gdy jest nieuzywana, na
            przyklad gdy system zostal uruchomiony tylko w trybie
            tekstowym lub po komendzie telinit 3):
            swapoff /dev/hdXY
            shred /dev/hdXY
            Oczywiscie, po tej operacji nie ma juz partycji wymiany, wiec
            najlepiej wykonac ja juz po powyzszych zmianach w plikach
            systemowych, po czym ponownie uruchomic system.
            Przeczytaj tez odpowiednia sekcje dokumentu o zabezpieczaniu
            serwera Tor. O samym programie Tor czytaj ponizej, w sekcji o
            zabezpieczaniu transmisji.
     _________________________________________________________________

Zabezpieczanie transmisji

   (przeskocz do odnosnikow do algorytmow)

   Szyfrowanie danych na dysku nic nie da, jesli sa one wysylane przez
   siec w postaci jawnej. Nie mowie tutaj o poczcie, ktora po lekturze
   poprzednich sekcji umiemy juz szyfrowac. Mowie tu o takich sprawach
   jak: hasla do poczty i na inne strony WWW, rozmowy w komunikatorze,
   oraz same odwiedzane strony internetowe. Jesli polaczenie jest
   nieszyfrowane, kazdy moze zobaczyc Wasze hasla, przeczytac tresc
   rozmow i dowiedziec sie, jakie strony ogladacie. Jak sie przed tym
   bronic? Nalezy szyfrowac wszelkie wysylane dane. Zobaczmy, co mozna
   zrobic w tej kwestii.
    1. Przegladanie WWW (w tym poczty).
       Jesli serwer, z ktorym sie laczycie, ma obsluge SSL/ TLS, to od
       tej pory uzywajcie bezpiecznych polaczen, wpisujac HTTPS zamiast
       HTTP w pasku adresu w przegladarce. Protokolu SSL/TLS nalezy
       bezwzglednie korzystac w czasie korzystania z bankowosci
       elektronicznej oraz (jesli mozliwe) poczty.
       Aby sprawdzic, czy serwer to obsluguje, wpisz HTTPS zamiast HTTP w
       polu adresu i sprawdz, czy przegladarka sie polaczy normalnie.
    2. Poczta w programach pocztowych
       Dobre skrzynki pocztowe oferuja polaczenia szyfrowane POP3+SSL/TLS
       (port 995/110) i SMTP+SSL/TLS (port 25). Nalezy bezwzglednie
       wlaczyc je w swoim programie pocztowym. Polaczenie SSL jest
       czasami nazywane "bezpiecznym polaczeniem", a TLS "bezpiecznym
       uwierzytelnianiem (hasla)".
       Jesli serwer pocztowy tego nie obsluguje, mozna rozwazyc
       przesiadke na inny. Jesli skrzynka to obsluguje, a program nie,
       nalezy koniecznie zmienic program na bardziej bezpieczny. Polecam
       Thunderbirda.
    3. Komunikator
       Jesli uzywasz popularnego "sloneczka", to wiedz, ze wprowadzenie
       szyfrowania jest w trakcie... juz od dluzszego czasu. Stan
       wprowadzenia ani stopien zabezpieczenia sa nieznane. Szyfrowanie
       od odbiorcy do nadawcy mozna wprowadzic, ale jest to sprzeczne z
       regulaminem. Pomysl o zmianie komunikatora i czytaj dalej.
       Jesli uzywasz Tlenu, mozesz czuc sie polowicznie bezpieczny. Twoje
       rozmowy sa szyfrowane na drodze od Ciebie do serwera i od serwera
       do odbiorcy wiadomosci. Na serwerze mozna je jednak zobaczyc w
       postaci jawnej. Ale i tak znacznie lepiej niz "slonko". Tlen jest
       z rodziny Jabbera (czytaj nizej), ale wlasciciel zdecydowal sie
       samolubnie go zamknac i rozszerzac, nie dzielac sie osiagnieciami
       ze spolecznoscia, od ktorej otrzymal Jabbera. Zamkniecie protokolu
       zawsze wprowadza pewna niepewnosc.
       Jesli uzywasz Jabbera , mozesz czuc sie jeszcze bezpieczniejszy.
       Protokol Jabbera jest miedzynarodowy, otwarty i ma wbudowane
       zabezpieczenia. Twoje rozmowy sa szyfrowane na drodze od Ciebie do
       serwera i od serwera do odbiorcy wiadomosci. Na serwerze mozna je
       jednak zobaczyc w postaci jawnej.
       Jabber ma jednak wspaniala ceche: wbudowana obsluge PGP - tego
       samego, ktorego wczesniej sie uczylismy w celu zabezpieczenia
       poczty. Po wlaczeniu SSL i PGP Twoje rozmowy sa szyfrowane na
       drodze do serwera jednym kluczem, na drodze od serwera do odbiorcy
       - innym i na drodze od nadawcy do odbiorcy - kluczem PGP. Jesli
       wiadomosc musi byc przechowana na serwerze, to jest tam
       zaszyfrowana kluczem PGP i niemozliwa do odczytania.
       Jabber z wlaczonymi SSL i PGP gwarantuje najwieksze bezpieczenstwo
       rozmow.
    4. Anonimowosc
       Czasem samo szyfrowanie przesylanych tresci nie wystarcza.
       Przegladarka i tak zdradzi, z jakim serwerem chcemy sie polaczyc
       oraz nasz adres IP, a komunikator zdradzi nasz adres IP. Czasem
       sama wiedza o tym, z jakimi stronami WWW sie laczymy pozwala
       wyciagnac o nas wnioski (w ktorym banku mamy konto, na ktorym
       serwerze skrzynke, na ktore forum piszemy). Na szczescie i przed
       tym mozna sie bronic.
       Rozwiazaniem sa rozne programy anonimizujace nasze dzialania w
       sieci. Jednym z takich programow jest darmowy i otwarty Tor
       (torproject.org), wspierany przez Electronic Frontier Foundation,
       ktora broni praw czlowieka w sieci. Zasada dzialania jest prosta:
       zamiast laczyc sie bezposrednio z serwerem docelowym, nasze
       programy najpierw lacza sie z zainstalowanym u nas Torem, a ten
       przez siec serwerow na calym swiecie przekierowuje nasz ruch do
       serwera docelowego. Caly ruch, az od ostatniego wezla do serwera
       docelowego, jest szyfrowany (jesli laczysz sie przez SSL lub TLS,
       caly ruch jest szyfrowany). Serwerowi docelowemu wydaje sie, ze
       laczysz sie z innego adresu niz naprawde. I o to chodzi.
       Instalacja Tora jest prosta, konfiguracja programow, by go uzywaly
       - tez. Polecam.
     _________________________________________________________________

Jak to wszystko naprawde dziala

   O tym, czym sa te dziwne nazwy (MD5, SHA, RSA, DSA, El-Gamal, PKCS),
   mozecie sie dowiedziec na przyklad stad:
     * Kategoria kryptologii na Wikipedii
     * Podrecznik Kryptografii Stosowanej (po angielsku).

   Spis tresci off-line (klawisz dostepu 1)
   Spis tresci on-line (klawisz dostepu 2)
   Ulatwienia dla niepelnosprawnych (klawisz dostepu 0)
