GnuPG w Gentoo

1.  Wprowadzenie

Czego się można dowiedzieć z tego przewodnika

Przed przeczytaniem tego tekstu należy się zapoznać z podstawami szyfrowania przy użyciu klucza publicznego oraz pojęciem cyfrowego podpisu. Informacje na ten temat znajdują się w części zatytułowanej Szyfrowanie kluczem publicznym i w drugim rozdziale Podręcznika GnuPG. Po zapoznaniu się z podstawami można wrócić do tego tekstu.

Ten przewodnik pokaże jak zainstalować GnuPG, jak utworzyć parę kluczy, jak dodawać klucze do bazy, jak wysłać klucz publiczny na serwer kluczy i jak podpisywać, szyfrować, weryfikować lub deszyfrować otrzymywane lub wysyłane wiadomości. Dodatkowo wytłumaczymy jak należy szyfrować pliki na własnym komputerze by uniemożliwić innym odczyt ich zawartości.

Instalacja wymaganego oprogramowania

Na sam początek należy zainstalować GnuPG za pomocą polecenia emerge gnupg. Wiele programów ma obecnie pewnego rodzaju wsparcie dla gpg, tak więc posiadanie flagi crypt w zmiennej USE jest bardzo zalecane. Warto mieć program do obsługi poczty elektronicznej pozwalający na korzystanie z gnupg. Można w tym celu zainstalować pine (emerge pinepgp), mutt (emerge mutt), Mozilla Thunderbird (emerge mozilla-thunderbird, evolution (evolution jest wchodzącym w skład GNOME odpowiednikiem Microsoft Outlook) lub klienta poczty z KDE - KMail (KMail jest częścią pakietu kdepim).

Osoby korzystające z KDE może zainteresować Kgpg. Ten mały program umożliwia generowanie kluczy, importowanie kluczy z plików ASCII, podpisywanie zaimportowanych kluczy, eksportowanie kluczy oraz wiele innych rzeczy.

2.  Generowanie i dodawanie kluczy do publicznej bazy kluczy

Generowanie klucza

Aby wygenerować klucz, wpisujemy gpg --gen-key. Przy pierwszym uruchomieniu, zostanie stworzonych kilka katalogów. Aby wygenerować klucze należy ponownie wykonać polecenie:

$ gpg --gen-key gpg (GnuPG)
1.2.6; Copyright (C) 2004 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.

Please select what kind of key you want:
   (1) DSA and ElGamal (default)
   (2) DSA (sign only)
   (4) ElGamal (sign and encrypt)
   (5) RSA (sign only)
   Your selection? 1

Tutaj można wybrać rodzaj klucza którego chcemy używać. Większość użytkowników wybierze domyślne DSA i ElGamal. Następnie wybieramy długość klucza - należy pamiętać, że im dłuższy klucz tym lepszy, ale nie powinno się używać kluczy DSA i ElGamal dłuższych niź 2048. Generalnie 1024 to więcej niż potrzeba do normalnej poczty.

Po długości klucza pora na datę wygaśnięcia. Tutaj im mniej tym lepiej, jednakże większość użytkowników może wybrać 0 (klucz nigdy nie wygasa) lub jakieś 2 lub 3 lata.

DSA keypair will have 1024 bits.
About to generate a new ELG-E keypair.
              minimum keysize is  768 bits
              default keysize is 1024 bits
    highest suggested keysize is 2048 bitszwi
    What keysize do you want? (1024) 2048
Requested keysize is 2048 bits
Please specify how long the key should be valid.
         0 = key does not expire
 <n>= key expires in n days
 <n>w = key expires in n weeks
 <n>m = key expires in n months
 <n>y = key expires in n years
 Key is valid for? (0) 0
Key does not expire at all

Teraz pora na podanie danych osobowych użytkownika. Jeśli klucz ma być później wysłany do innych osób, należy podać prawdziwy adres email.

Is this correct (y/n)? y

You need a User-ID to identify your key; the software constructs the user id
from Real Name, Comment and Email Address in this form:
"Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"

Real name: John Doe
Email address: john@nowhere.someplace.flick
Comment: The Real John Doe
You selected this USER-ID:
"John Doe (The Real John Doe) <john@nowhere.someplace.flick>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
You need a Passphrase to protect your secret key.

Enter passphrase:

Należy dwukrotnie podać hasło. Zalecane jest użycie mocnego hasła. Jeśli ktokolwiek kiedykolwiek zdobędzie klucz prywatny i złamie to hasło, będzie mógł wysyłać wiadomości podpisane przez "nas" sprawiając że wszyscy będą wierzyć, że poczta jest od nas.

Teraz GnuPG wygeneruje klucz. Poruszanie myszką lub odtwarzanie w tle pliku mp3 pomoże przyśpieszyć ten proces, ponieważ generuje on losowe dane.

Generowanie certyfikatu unieważnienia

Po utworzeniu kluczy należy utworzyć certyfikat unieważnienia. Pozwoli to unieważnić klucz w przypadku gdy coś złego się z nim stanie (ktoś zdobędzie nasz klucz/hasło).

$ gpg --list-keys
/home/humpback/.gnupg/pubring.gpg
---------------------------------
pub  1024D/75447B14 2002-12-08 John Doe (The Real John Doe) <john@nowhere.someplace.flick>
sub  2048g/96D6CDAD 2002-12-08

$ gpg --output revoke.asc --gen-revoke 75447B14

sec  1024D/75447B14 2002-12-08   John Doe (The Real John Doe) <john@nowhere.someplace.flick>

Create a revocation certificate for this key? y
Please select the reason for the revocation:
  0 = No reason specified
  1 = Key has been compromised
  2 = Key is superseded
  3 = Key is no longer used
  Q = Cancel
(Probably you want to select 1 here)
Your decision? 1
Enter an optional description; end it with an empty line:
> Someone cracked me and got my key and passphrase
>
Reason for revocation: Key has been compromised
Someone cracked me and got my key and passphrase
Is this okay? y

You need a passphrase to unlock the secret key for
user: "John Doe (The Real John Doe) <john@nowhere.someplace.flick>"
1024-bit DSA key, ID 75447B14, created 2002-12-08

ASCII armored output forced.
Revocation certificate created.

Please move it to a medium which you can hide away; if Mallory gets
access to this certificate he can use it to make your key unusable.
It is smart to print this certificate and store it away, just in case
your media become unreadable.  But have some caution:  The print system of
your machine might store the data and make it available to others!

Polecenie gpg --list-keys wypisuje klucze należące do naszej bazy kluczy. Można dzięki niemu sprawdzić ID klucza co pozwoli na wygenerowanie certyfikatu unieważnienia. Teraz dobrym pomysłem będzie skopiowanie całego katalogu .gnupg oraz certyfikatu unieważniającego (w formacie ASCII - revoke.asc) na jakiś bezpieczny nośnik (dwie dyskietki lub płyta CD-R przechowywane w bezpiecznym miejscu). Trzeba pamiętać, że plik revoke.asc może być użyty do unieważnienia naszych kluczy, co sprawi, że staną się bezużyteczne.

Eksport kluczy

Aby wyeksportować klucz, należy wpisać gpg --armor --output john.asc --export john@nowhere.someplace.flick. Zawsze można użyć ID klucza lub czegokolwiek co go zidentyfikuje (tutaj użyliśmy adresu email). Teraz John posiada plik john.asc, który można wysłać znajomym lub umieścić na stronie internetowej tak, aby inni mogli się z nami bezpiecznie komunikować.

Importowanie kluczy

Aby dodać pliki do naszej bazy kluczy, należy je najpierw zaimportować, a następnie sprawdzić odcisk klucza. Po zweryfikowaniu odcisku klucza należy go potwierdzić.

Teraz dodamy klucz Luisa Pinto (naszego przyjaciela) do naszej bazy kluczy. Po zadzwonieniu do niego i zapytaniu o odcisk jego klucza (fingerprint), porównałem go z wynikiem polecenia fpr. Ponieważ klucz jest prawdziwy, dodałem go do publicznej bazy kluczy. W tym szczególnym przypadku klucz Luisa wygaśnie 2003-12-01, więc zostałem zapytany czy chcę by mój podpis jego klucza wygasł w tym samym czasie.

$ gpg --import luis.asc
gpg: key 462405BB: public key imported
gpg: Total number processed: 1
gpg:               imported: 1
$ gpg --list-keys
/home/humpback/.gnupg/pubring.gpg
---------------------------------
pub  1024D/75447B14 2002-12-08 John Doe (The Real John Doe) <john@nowhere.someplace.flick>
sub  2048g/96D6CDAD 2002-12-08

pub  1024D/462405BB 2002-12-01 Luis Pinto <lmpinto@student.dei.uc.pt>
uid                            Luis Pinto <lmpinto@dei.uc.pt>
sub  4096g/922175B3 2002-12-01 [expires: 2003-12-01]

$ gpg --edit-key lmpinto@dei.uc.pt
gpg (GnuPG) 1.0.7; Copyright (C) 2002 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.


gpg: checking the trustdb
gpg: checking at depth 0 signed=0 ot(-/q/n/m/f/u)=0/0/0/0/0/1
pub  1024D/462405BB  created: 2002-12-01 expires: 2003-12-01 trust: -/-
sub  4096g/922175B3  created: 2002-12-01 expires: 2003-12-01
(1)  Luis Pinto <lmpinto@dei.uc.pt>
(2). Luis Pinto <lmpinto@student.dei.uc.pt>

Command> fpr
pub  1024D/462405BB 2002-12-01 Luis Pinto <lmpinto@dei.uc.pt>
             Fingerprint: F056 3697 ADE3 CF98 B80B  8494 0AD3 E57B 4624 05BB
     Command> sign
Really sign all user IDs? y

pub  1024D/462405BB  created: 2002-12-01 expires: 2003-12-01 trust: -/-
             Fingerprint: F056 3697 ADE3 CF98 B80B  8494 0AD3 E57B 4624 05BB

     Luis Pinto <lmpinto@dei.uc.pt>
     Luis Pinto <lmpinto@student.dei.uc.pt>

This key is due to expire on 2003-12-01.
Do you want your signature to expire at the same time? (Y/n) Y
How carefully have you verified the key you are about to sign actually belongs
to the person named above?  If you don't know what to answer, enter "0".

   (0) I will not answer. (default)
   (1) I have not checked at all.
   (2) I have done casual checking.
   (3) I have done very careful checking.

   Your selection? 3
Are you really sure that you want to sign this key
with your key: "John Doe (The Real John Doe) <john@nowhere.someplace.flick>"

I have checked this key very carefully.

Really sign? y

You need a passphrase to unlock the secret key for
user: "John Doe (The Real John Doe) <john@nowhere.someplace.flick>"
1024-bit DSA key, ID 75447B14, created 2002-12-08

Command> check
uid  Luis Pinto <lmpinto@dei.uc.pt>
sig!3       462405BB 2002-12-01   [self-signature]
sig!3       75447B14 2002-12-08   John Doe (The Real John Doe) <john@nowhe
uid  Luis Pinto <lmpinto@student.dei.uc.pt>
sig!3       462405BB 2002-12-01   [self-signature]
sig!3       75447B14 2002-12-08   John Doe (The Real John Doe) <john@nowhe

3.  Wymiana kluczy z serwerami kluczy

Wysyłanie kluczy do serwerów kluczy

Teraz, kiedy mamy już nasz klucz, dobrym pomysłem będzie wysłanie go do ogólnodostępnego serwera kluczy. Na świecie jest wiele serwerów i większość z nich wymienia klucze między sobą. My wyślemy klucz Luisa do serwera subkeys.pgp.net. Użyjemy protokołu HTTP, więc jeśli używany jest serwer proxy dla ruchu HTTP należy pamiętać o jego konfiguracji (export http_proxy=http://proxy_host:port/). Polecenie do wysyłania klucza to: gpg --keyserver subkeys.pgp.net --keyserver-options honor-http-proxy --send-key 75447B14 gdzie 75447B14 to ID klucza. Jeśli nie jest używany serwer proxy można usunąć opcję --keyserver-options honor-http-proxy.

Na serwer można także wysłać podpisane przez nas klucze innych osób. Moglibyśmy wysłać klucz Luisa Pinto. W ten sposób ktoś kto nam ufa, może użyć naszego podpisu by zaufać kluczowi Luisa.

Pobieranie kluczy z serwerów

Poszukamy klucza Gustavo Felisberto i dodamy do bazy kluczy Johna Doe.

$ gpg --keyserver subkeys.pgp.net --keyserver-options honor-http-proxy --search-keys humpback@felisberto.net
gpg: searching for "humpback@felisberto.net" from HKP server subkeys.pgp.net
Keys 1-5 of 5 for "humpback@felisberto.net"
(1)Gustavo Felisberto (apt-get install anarchy) <humpback@felisberto.net> 1024
  created 2002-12-06, key B9F2D52A
(2)Gustavo Felisberto <humpback@altavista.net> 1024
  created 1999-08-03, key E97E0B46
(3)Gustavo A.S.R. Felisberto <humpback@altavista.net> 1024
  created 1998-12-10, key B59AB043
(4)Gustavo Adolfo Silva Ribeiro Felisberto <humpback@altavista.net> 1024
  created 1998-08-26, key 39EB133D
(5)Gustavo Adolfo Silva Ribeiro Felisberto <humpback@altavista.net> 1024
  created 1998-06-14, key AE02AF87
  Enter number(s), N)ext, or Q)uit >1
gpg: requesting key B9F2D52A from HKP keyserver subkeys.pgp.net
gpg: key B9F2D52A: public key imported
gpg: Total number processed: 1
gpg:               imported: 1

Jak widać z odpowiedzi serwera, jest na nim kilka naszych kluczy, ale aktualnie używamy tylko B9F2D52A. Teraz John Doe może go pobrać i podpisać jeśli mu ufa.

4.  Używanie agenta GPG

Co to jest agent GPG?

Pracując z pewnymi aplikacjami z użyciem swojego klucza GPG dosyć często trzeba wpisywać wiele razy swoje hasło. Niektóre aplikacje pamiętają raz wpisane hasło by ułatwić życie użytkownikowi, co jednak nie pozwala na dzielenie tego zapamiętanego hasła z innymi aplikacjami.

Agent GPG jest osobnym programem używanym przez GPG to zapamiętywania wpisanych haseł w ustandardyzowany i bezpieczny sposób. Pozwala on aplikacjom używać GPG równolegle: jeśli podamy hasło pracując z jakąś aplikacją, inne mogą używać GPG bez ponawiania prośby o wpisanie hasła - oczywiście jeśli agent jest tak skonfigurowany by na to pozwalać.

Gentoo udostępnia kilka aplikacji agenta GPG. app-crypt/gnupg-1.9.* może być uważany za tego zalecanego i właśnie z niego będziemy korzystać w tym dokumencie.

Instalacja i konfiguracja programów gpg-agent oraz pinentry

Należy zainstalować pakiet gnupg-1.9.*, zawierający program gpg-agent oraz pinentry, który jest pomocniczą aplikacją używaną przez agenta do zapytania o hasło w graficznym okienku. Posiada on trzy tryby pracy: może wyświetlić okienko używając biblioteki gtk+, Qt lub curses (w zależności od flagi USE podczas instalacji).

# emerge \>=gnupg-1.9.20 pinentry

Następnie należy utworzyć plik ~/.gnupg/gpg-agent.conf i wstawić następujące linie, które zdefiniują domyślny czas życia wpisanego hasła (np. 30 minut) oraz aplikację, której należy użyć w celu pobrania hasła za pierwszym razem (np. wersję Qt programu pineentry).

pinentry-program /usr/bin/pinentry-qt
no-grab
default-cache-ttl 1800

Teraz skonfigurujemy program GnuPG by używał agenta gdy zajdzie taka potrzeba. Należy otworzyć w edytorze plik ~/.gnupg/gpg.conf i dodać do niego następującą linię:

use-agent

Teraz system jest już (prawie) gotowy do użycia agenta GPG.

Automatyczne uruchamianie agenta GPG

Jeśli jako środowisko graficzne używane jest KDE, trzeba otworzyć plik /usr/kde/3.x/env/agent-startup.sh (ustawienia globalne systemu) lub ~/.kde/env/gpgagent.sh (ustawienia użytkownika) i dodać następujące polecenie by KDE automatycznie uruchomiło agenta przy starcie:

eval "$(gpg-agent --daemon)"

Jeśli używane jest inne środowisko graficzne, trzeba dodać taką samą linię do ~/.xinitrc (jeśli używane jest polecenie startx) lub ~/.xsession (jeśli używany jest XDM/GDM/KDM/...).

5.  Praca z dokumentami

Szyfrowanie i podpisywanie

Powiedzmy, że mamy plik, który chcemy wysłać Luisowi. Można go zaszyfrować, podpisać lub zaszyfrować i podpisać. Szyfrowanie oznacza, że tylko Luis będzie mógł go otworzyć. Podpis zapewni Luisa że to naprawdę my stworzyliśmy plik.

Kolejne trzy polecenia zaszyfrują i podpiszą plik.

$ gpg --output doc.gpg --encrypt --recipient lmpinto@dei.uc.pt doc_to_encrypt
$ gpg --output doc.gpg --sign --recipient lmpinto@dei.uc.pt doc_to_sign
$ gpg --output doc.gpg --encrypt --sign --recipient lmpinto@dei.uc.pt doc_to_encrypt_and_sign

Utworzone zostaną pliki binarne. Aby utworzyć pliki ASCII, trzeba dodać --clearsign na początku polecenia.

Deszyfrowanie i weryfikacja podpisów

Załóżmy że dostaliśmy plik, który jest zaszyfrowany. Polecenie do deszyfracji to gpg --output document --decrypt encrypted_doc.gpg. Rozszyfruje ono dokument i sprawdzi podpis (jeśli istnieje).

Szyfrowanie i deszyfrowanie bez kluczy

Możliwe jest użycie haseł do szyfrowania plików. Hasło jako takie, funkcjonowało będzie jako klucz w postaci symetrycznego szyfru. Szyfrowanie odbywa się poprzez wydanie komendy gpg z opcją --symmetric. Deszyfrowanie odbywa się tak jak to zostało opisane wcześniej.

$ gpg --output document.gpg --symmetric document
(GnuPG poprosi o podanie hasła oraz o weryfikację tego hasła)

Zaawansowana funkcjonalność

GnuPG ma kilka przyjemnych zaawansowanych funkcji. Aby je odnaleźć, należy otworzyć plik ~/.gnupg/gpg.conf.

#keyserver x-hkp://subkeys.pgp.net
#keyserver-options auto-key-retrieve include-disabled include-revoked

Jeśli dwie powyższe linie zostaną odkomentowane, za każdym razem gdy GnuPG będzie musiał sprawdzić podpis a nie będzie mógł go znaleźć w lokalnej bazie kluczy skontaktuje się z serwerem subkeys.pgp.net i spróbuje go stamtąd pobrać.

Kolejne przyjemne polecenie to gpg --refresh-keys. Skontaktuje się ono z serwerem zdefiniowanym w pliku konfiguracyjnym i odświeży klucze publiczne z lokalnej bazy kluczy, szukając unieważnionych kluczy, nowych ID i nowych podpisów. To polecenie powinno być uruchamiane dwa razy w miesiącu tak aby być powiadomionym gdy ktoś unieważni swój klucz.

6.  Interfejsy do GnuPG

O podpisach w poczcie elektronicznej

W 95% GnuPG używany jest wraz z pocztą elektroniczną, podpisywania i szyfrowania wychodzącej poczty lub czytania podpisanych i zaszyfrowanych wiadomości. Tak więc napiszę o tym na samym początku.

Są dwa sposoby na podpisanie czy szyfrowanie poczty przy użyciu GnuPG, stary i nowy. W starym stylu wiadomości pojawiłyby się jako zwykły tekst, bez możliwości formatowania, a załączone pliki nie byłyby podpisane/szyfrowane. Oto przykład wiadomości podpisanej starym sposobem:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Test message

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use

iQA/AwUBP8461jMX0745gR7AEQIEOwCg011GbufXO3ED3FkLWXmfzg7xm1cAoJD0
0EU3Kd2EKNCqataEqM5qjpPs
=LchZ
-----END PGP SIGNATURE-----

Wiadomości tego rodzaju nie są dobre w dzisiejszym świecie, gdzie mamy ładne graficzne interfejsy i programy pocztowe akceptujące HTML.

Aby rozwiązać ten problem stworzono dodatek do MIME (Multipurpose Internet Mail Extensions). Dodaje on do wiadomości pole mówiące programowi pocztowemu, że cała zawartość wiadomości jest podpisana i/lub zaszyfrowana. Jedyny problem w takim rozwiązaniu to fakt, że nie wszystkie programy pocztowe je obsługują. Niektóre nawet zmieniają zawartość wiadomości, znanym przykładem programu nie współpracującego z tym rozwiązaniem jest Microsoft Outlook.

Kgpg

Kgpg to przyjemny interfejs do GnuPG. W głownym oknie można wklejać tekst, który ma byś podpisany lub szyfrowany, a także można wkleić tekst w formacie ASCII, który ma być rozszyfrowany.

Ilustracja 6.1

Na obrazku widać główne okno Kgpg z wklejonym zaszyfrowanym tekstem. Stąd można go rozszyfrować (trzeba będzie podać hasło), szyfrować inne pliki, wkleić nowy tekst do podpisania...

Ilustracja 6.2

Tak wygląda okno zarządzania kluczami. Widać w nim znany nam klucz Johna Doe. Dwa zaufane klucze Gustavo i Luisa i niezaufany klucz Daniela Robbinsa (nadal nie zadzwoniłem do niego by sprawdzić jego odcisk :) ).

Seahorse

Seahorse ma być docelowo interfejsem do GnuPG przeznaczonym dla środowiska Gnome. To oprogramowanie rozwija się bardzo szybko, jednakże nadal brakuje mu wielu ważnych funkcji, które można znaleźć w Kgpg lub wersji uruchamianej z wiersza poleceń.

Enigmail

Enigmail to dodatek do klientów opartych na Mozilli takich jak Thunderbird czy Seamonkey. Jest stosunkowo prosty w konfiguracji. W Seamonkey wystarczy wejść do menu Preferences -> Privacy & Security -> Enigmail i tam wpisać wszystkie niezbędne informacje. Aby korzystać z Enigmail w Thunderbird, należy najpierw go zainstalować (emerge enigmail). Następnie można ustawić wszystkie niezbędne opcje w menu Edit -> Account Settings -> OpenPGP Security.

Przychodzące wiadomości które zawierają inny niż zaufany podpis będą oznaczone złapanym piórem. Pozostałe z zaufanym podpisem będą oznaczone ładnym prostym piórem. Enigmail potrafi także pobierać klucze z serwerów, jednak jeśli napotka jakieś problemy wypisuje bardzo dziwne komunikaty (ale nadal pamiętamy jak użyć narzędzia z wiersza polecenia, zgadza się?).

KMail

Jeśli zmienna USE zawiera flagę crypt, KMail będzie skompilowane ze wsparciem dla gpg i będzie miał możliwość automatycznego szyfrowania i deszyfrowania wiadomości w starym formacie PGP, a także szyfrowania wiadomości w formacie OpenPGP/MIME. Jeśli program ma deszyfrować wiadomości OpenPGP/MIME (czego zapewne chcemy) należy użyć agenta GPG (Używanie agenta GPG).

Można sprawdzić czy KMail jest poprawnie skonfigurowany wchodząc w Settings, Configure KMail, Security, Crypto Backends. Na liście powinien znajdować się wpis GpgME-based i możliwość zaznaczenia pola OpenPGP. Jeśli wpis znajduje się na liście, ale pole jest nieaktywne, należy kliknąć przycisk Rescan. Jeśli GpgME-based nadal jest nieaktywne, oznacza to, że KMail nie działa poprawnie.

Jeśli kmail wciąż odmawia współpracy, radzimy skorzystać z dokumentu KMail PGP HowTo.

Claws-Mail

Ten program pocztowy jest bardzo szybki przy dużych skrzynkach pocztowych. Posiada wszystkie przydatne funkcje, jakie można sobie wymarzyć i bardzo dobrze współpracuje z gpg. Jedynym problemem jest to, że ma problemy z działaniem ze starymi sygnaturami PGP, więc po otrzymaniu takiej korespondencji, sygnatury trzeba sprawdzać samemu.

Aby użyć gpg z programem Claws-Mail wystarczy wejść w konfigurację konta i wybrać zakładkę prywatność. Po czym należy wybrać klucz, który będzie używany. Prawdopodobnie większość użytkowników zostawi domyślnie wybrany klucz.

7.  Kryptografia przy użyciu klucza publicznego

Podstawy szyfrowania przy użyciu klucza publicznego

Pomysł szyfrowania przy użyciu klucza publicznego został wymyślony przez Whitfielda Diffie i Martina Hellmana w 1976 roku. Kiedy po raz pierwszy usłyszałem słowa "klucz publiczny" i "kryptografia" w tym samym zdaniu w roku 1993 pomyślałem, że niemożliwe by coś takiego dało się zrobić. W tamtych czasach nie było Internetu (właściwie to już był, ale nie dla mnie), więc udałem się do publicznej biblioteki i zapytałem o książki poświęcone kryptografii. Muszę przyznać, że miałem wtedy 16 lat, więc bibliotekarz spojrzał na mnie ze zdumieniem i przyniósł mi książkę dla dzieci o szyfrowaniu przez podstawianie (to takie, w których zamienia się literę na jakąś inną jak w znanym Szyfrze Cezara lub ROT-13 (Tragbb emnqmv, mncenfmnzl qb qnyfmrw yrxghel grtb grxfgh. Gnx, mnfmlsebjnyvfzl gb cbabjavr bq abjn ceml gyhznpmravh, pb cbgjvreqmn anfmn pubebor cflpuvpman). (program rotix pomoże w odszyfrowaniu powyższej wiadomości). Byłem bardzo zawiedziony i zacząłem szukać szerszych informacji. W takich wypadkach dobrze jest mieć w rodzinie matematyka, po rozmowie z nim szybko otworzył się przede mną nowy, fascynujący świat.

A teraz troszkę matematyki:

Definicje:

1- Liczba pierwsza to dodatnia liczba całkowita większa od jedynki która jest
podzielna tylko przez 1 i samą siebie (reszta z dzielenia wynosi 0).
Pierwszych 8 liczb pierwszych to 2,3,5,7,11,13,17,19

Twierdzenie (bez dowodu)
1- Każdą dodatnią liczbę złożoną (czyli taką, która nie jest liczbą pierwszą)
można rozbić na iloczyn liczb pierwszych i ten iloczyn jest unikalny.
4=2*2
6=2*3
8=2*4=2*2*2
10=2*5
12=2*6=2*2*3

"Fakty":
1- Z matematycznego punkty widzenia łatwo jest pomnożyć dwie duże liczby
całkowite.
2- Ciężko jest znaleźć czynniki pierwsze danej liczby całkowitej.

Jeśli wezmę liczbę 35 i powiem, że ta liczba jest iloczynem dwóch liczb pierwszych, łatwo zgadnąć, że te liczby to 5 i 7. Ale jeśli powiem to samo o liczbie 1588522601, trzeba poświęcić dużo czasu (lub cykli procesora) by odgadnąć że to 49811*31891. Jeśli ta liczba jest bardzo duża to zadanie staje się "niewykonalne". Tak więc jeśli dam światu moją wielką liczbę, która jest iloczynem dwóch liczb pierwszych, wiem coś o tej liczbie, czego nikt inny nie wie.

To jest podstawą dzisiejszych implementacji kryptografii przy użyciu Klucza Publicznego. Jako przykład, dam komuś swoją liczbę której będzie używał do szyfrowania wiadomości do mnie. Każdy może zobaczyć zaszyfrowaną wiadomość, ale tylko ja znam skrót do jej przeczytania, pozostali musieliby najpierw "rozbić" tę wielką liczbę by móc przeczytać wiadomość, a faktem jest, że tego się nie da zrobić w krótkim czasie (dzisiejsze metody i najszybsze komputery na świecie do wykonania tego potrzebują tysiące lat). W tej konfiguracji dwie wielkie liczby pierwsze byłyby nazwane KLUCZEM PRYWATNYM, a wielka liczba złożona jest KLUCZEM PUBLICZNYM.

W praktyce to nie jest w 100% zgodne z rzeczywistością, ale daje dobre wyobrażenie dla nowicjusza. Więcej informacji można znaleźć w artykule o protokole Diffie-Hellmana. Jeszcze więcej informacji można znaleźć w publicznej bibliotece w książce "Podręcznik Kryptografii Stosowanej" Alfreda J. Menezesa, Paula C. van Oorschota i Scotta A. Vanstone'a, ta książka jest także dostępna on-line na wyżej podanej stronie.

Konsekwencją powyższego jest to, że jeśli się szyfruje dla kogoś wiadomość i zgubi się oryginalny tekst, nie ma możliwości odzyskania go z zaszyfrowanej wersji.

Podpisy

Już się dowiedzieliśmy w jaki sposób ktoś może wysłać nam zaszyfrowaną wiadomość jeśli ma nasz klucz publiczny. Ale jak możemy sprawdzić że autor wiadomości jest rzeczywiście tym za kogo się podaje? Innymi słowy: Jeśli otrzymam od kogoś wiadomość skąd naprawdę mogę wiedzieć że jest od niego, a nie kogoś innego?

Pamiętacie jak powiedziałem że Kryptografia Kluczem Publicznym nie jest taka prosta jak mówię? Pomysł jest taki, że kiedy się szyfruje wiadomość podpisuje się ją swoim kluczem prywatnym, tak że kiedy ktoś ją dostanie najpierw używa naszego publicznego klucza do sprawdzenia podpisu, a następnie swojego prywatnego klucza do rozszyfrowania wiadomości. Jak widać nie da się tego zrobić w konfiguracji jaką wcześniej opisałem.

Kolejną ważną rzeczą jest to, że nie trzeba szyfrować wiadomości którą chcemy podpisać. Tak więc można tworzyć "podpisane" wiadomości które każdy będzie mógł przeczytać. Co więcej jeśli jakakolwiek litera zostanie zmieniona możliwe będzie natychmiastowe wykrycie tego faktu.

Serwery kluczy i podpisane klucze

Powiedzmy że nigdy wcześniej nie kontakowałem się z kimś kto mi wysyła wiadomość, skąd mam wziąć jego klucz publiczny i skąd mam wiedzieć że należy on na pewno do niego?

Aby rozwiązać ten problem stworzone zostały Serwery Kluczy. Gdy się tworzy swoją parę kluczy (Publiczny i Prywatny) wysyła się swój klucz publiczny do serwera. Od tego momentu każdy może stamtąd otrzymać nasz klucz. To rozwiązuje problem znalezienia czyjegoś klucza. Ale skąd mam na pewno wiedzieć że klucz jest kluczem autora? Do tego musi powstać kolejne rozwiązanie i to jest właśnie podpisywanie kluczy:

Jeśli jesteśmy pewni autentyczności klucza publicznego pewnej osoby (na przykład przyjaciela), możemy ten klucz podpisać i wysłać na serwer. W ten sposób oznajmia się innym użytkownikom, że dany klucz naprawdę należy do osoby, która jest w jego posiadaniu. Dzięki temu osoby posiadające mój publiczny klucz i ufające mi, mogą użyć tego zaufania by zaufać innym kluczom.

To może być czasami mylące więc zobaczmy jak to działa w prawdziwym świecie

Wyobraźmy sobie 3 osoby: Johna, Mary i Lisę. John jest dobrym przyjacielem Mary, ale nie zna Lisy; Lisa jest dobrą przyjaciółką Mary, ale nie zna Johna. Pewnego dnia Lisa wysyła Johnowi podpisaną wiadomość. John pobierze klucz Lisy z publicznego serwera i sprawdzi wiadomość. Jeśli wszystko dobrze pójdzie zobaczy on, że ktokolwiek podpisał wiadomość, także wygenerował ten klucz. Ale skąd wiedzieć, że to na pewno jest osobą, za którą się podaje?

Wtedy John widzi że ten klucz jest podpisany przez Mary, którą może sprawdzić ponieważ posiada jej klucz i mu ufa. Z tego kręgu zaufania wyciąga wniosek że ta wiadomość na pewno została napisana przez Lisę.

Teraz jesteśmy gotowi do przeczytania tego przewodnika, można wrócić do pierwszego rozdziału i nauczyć się korzystać z gpg.

8.  Końcowe przemyślenia i podziękowania

Pewne problemy

Miałem problemy ze zdjęciami w kluczach. Należy sprawdzić wersję której się używa. Jeśli używane jest GnuPG 1.2.1-r1 wszystko prawdopodobnie jest w porządku, ze starszymi wersjami mogły być problemy. Także większość serwerów nie lubi kluczy ze zdjęciami, więc lepiej ich jednak nie dodawać.

Najnowsze wersje gpg zdają się nie działać z poleceniem gpg --send-keys, które było użyte do wysłania wszystkich posiadanych kluczy do serwera.

Czego brakuje w tym tekście

gpg to bardzo rozbudowane narzędzie, pozwala zrobić dużo więcej niż tu napisałem. Ten przewodnik jest dla nowych użytkowników GnuPG. Po więcej informacji należy wejść na stronę domową GnuPG.

Nie pisałem o innych narzędziach niż pgp4pine, gpgpine, evolution i być może programach dla Windows, ale prawdopodobnie rozszerzę ten dokument w przyszłości.

Podziękowania

Dla Johna Michaela Ashleya za Podręcznik GnuPG, który jest bardzo dobrą pozycją dla początkujących.

Dla Swifta (Svena Vermeulena) za zmuszenie mnie do przepisania tego tekstu.

Wszystkim z ekipy #gentoo-doc - chłopaki, rządzicie!

Dla Tiago Serra za wprowadzenie mnie w tematy dotyczące prywatności.

Zawartość tego dokumentu jest rozpowszechniana na podstawie licencji Creative Commons - Attribution / Share Alike.