Béton brut

Krótki wstęp do osobistej kryptografii

2013-06-14

Tu lepszy wstęp

Internet wydoroślał. Nie ma już w nim miejsca na zaufanie i nadzieję, że nikt nie czai się za ścianą z zamiarem dziabnięcia nas. Czasem tym kimś jest morderca nieświadomy swojej ofiary, skrypt, który szuka dziur, automat.

Na szczęście możemy się uzbroić.

Możemy użyć szyfrowania asymetrycznego! Ha, sama nazwa wystarczy, żeby nastoletniemu odpalaczowi skryptów zmiękły kolana. Niestety, jest to broń obosieczna, pistolet z dwoma lufami, granat z doczepioną gumką-recepturką; dobre narzędzie kryptograficzne jest po prostu skomplikowane. Wymaga nie tylko zrozumienia (choćby pobieżnego) kilku idei związanych z kryptografią, wymaga też odpowiedniej higieny: gdzie i jak przetrzymujemy swoje informacje, których programów używamy do szyfrowania informacji, kiedy, komu i będącemu gdzie ufamy.

Symetrycznie nie jest ślicznie

Może jednak nie warto się tyle kłopotać? Prawie każdy program do archiwizacji danych (ZIP, RAR, 7Zip, etc.) ma możliwość założenia hasła na utworzony plik. Wydawałoby się, że jest to wystarczająca ochrona dla informacji. I jest to prawda, o ile w archiwum czyhają jakieś krępujące materiały pornograficzne, wypożyczone z największej wypożyczalni na świecie pliki muzyczne czy kolekcja limeryków. Rzeczy, które – gdyby wyciekły – zażenowałyby znajomych. Może załatwiły wydanie jakiegoś tomiku wierszy. No wiecie: nic, czego potrzebujecie, ale też nic, co zniszczy Wam życie.

Hasło jest drugim co do słabości ogniwem w łańcuchu bezpieczeństwa. Pierwszym jesteś Ty, wymyślający hasło. Jedno wynika z drugiego. Przytoczę anegdotkę: pisałem kiedyś oprogramowanie dla pewnej firmy, która zażyczyła sobie poziomów dostępu dla swoich pracowników. W miarę standardowa robota: X może Y, Z nie może B. Kiedyś, podczas aplikowania zmian w bazie, moją uwagę przykuł pewien fakt – napisałem odpowiednie zapytanie, które zgrupowało mi skróty haseł: wszyscy pracownicy mieli takie same. Co oznaczało, że wszyscy mieli to samo hasło, będące numerem telefonu do biura. 1

Wyobraźmy sobie jednak sytuację w której autor archiwum poświęcił chwilkę na wymyślenie w miarę „ciężkiego”, unikalnego hasła. Teraz pozostaje nam przetransportowanie tak utworzonego pliku do celu. Dajemy go więc znajomemu na przenośnej pamięci USB lub wysyłamy e-mailem. Gotowe! A, chwileczkę, co z hasłem? Zadzwonić i powiedzieć przez telefon? Może wyślę drugim e-mailem hasło, będzie łatwiej?

Znów: załóżmy, że zrobiłeś najlepsze co mogłeś i wyszeptałeś odbiorcy hasło wprost do ucha. Jaką masz pewność, że nie zostanie zapisane na „przylepnej karteczce”? Praktycznie zerową, kontrola nad dostępem do hasła (czyli, de facto, zawartości pliku) została przekazana drugiej osobie.

„Dwie osoby są w stanie dochować tajemnicy o ile jedna z nich jest martwa.”

Teraz – naciągając naszą sytuację do ram fantastyki – przyjmijmy, że jesteście akurat dwiema najbardziej odpowiedzialnymi osobami na świecie, hasło nigdy nie zostało zapisane i siedzi tylko w Waszych głowach. Pozostaje nadal sprawa dostępu do pliku: plik może zostać wykradziony. Nie mówimy tu o nocnym ataku zakonu ninja, którego członkowie wpełzną po suficie i zwisając z elastycznych lin ukradną twardy dysk. Mówimy o kimś, kto wyśle go sobie e-mailem z Twojego komputera gdy będziesz w toalecie.

Teraz między nim a dostępem do Twoich danych stoi tylko hasło.

Jak widzicie proste metody ukrywania informacji stają się skomplikowane gdy tylko zaczniemy brać bezpieczeństwo na poważnie. Dodatkowo wszystkie procedury zabezpieczające wykorzystują elementy, które prawie zawsze padają jako pierwsze.

Podsumujmy więc problemy z tradycyjnym modelem „przesyłam Ci archiwum z hasłem”:

  • pojedyncze hasło umożliwia uzyskanie dostępu do archiwum,
  • każdy może skopiować archiwum i próbować wymusić do niego dostęp,
  • archiwum można podmienić, a odbiorca nie będzie tego świadomy.

Przejdźmy do meritum tego tekstu – jak poprawić bezpieczeństwo naszych danych i jak zmniejszyć szanse na wpadnięcie ich w niepowołane ręce. Zanim jednak rozpoczniemy zabawę z pakietem GPG musimy pomówić trochę o teorii.

Czy hasło to tylko znaki?

Zanim przejdziemy do kluczy prywatnych i publicznych porozmawiajmy przez chwilę o hasłach. Co jest takiego złego w prostych hasłach, jak się je zwykle zapisuje i na jakie problemy z tym możemy się natknąć w systemach informatycznych?

Każdego dnia logujemy się do wielu systemów. Od poczty, przez intranetowy system w pracy, kończąc na Facebooku. Większość z tych czynności sprowadza się do podania identyfikatora (zwykle adresu e-mail lub nazwy użytkownika) i hasła. Te wartości są sprawdzane w bazie danych i jeżeli para się zgadza, system zaczyna udostępniać dane.

Dobrą (jedyną!) praktyką jest składowanie tzw. skrótu hasła, matematycznie wyliczonej wartości przedstawionej najczęściej w zapisie szesnastkowym o stałej „długości”. Powodem używania tej metody jest ograniczenie dostępu do samego hasła zarówno dla administratorów, jak i w przypadku włamania do systemu.

Co to znaczy, że skrót jest wyliczany? Zróbmy własny, okrutnie zły i niepraktyczny skrót; jego koszmarne założenia pozwolą mi zademonstrować jeszcze jeden problem, ale po kolei.

Jeżeli A = 1, Ą = 2, B = 3, C =4, to Z = 35, jasne? Nie rozróżniamy wielkości liter. Teraz zapiszmy wyraz:

EMIL = 
  E[7] + 
  M[17] + 
  I[12] + 
  L[15] = 
  51 = 
  0x33

Czyli nasz „algorytm” to dodawanie wartości pozycji liter w alfabecie. Teraz, gdy ktoś będzie się próbował zalogować hasłem EMIL, mogę policzyć skrót hasła i sprawdzić, czy w bazie mam zapisane 0x33. „Nikt” nie wie, czym jest ten ciąg i hasło jest „bezpieczne”.

Czy potraficie zgadnąć jaki jest z nim problem?

GOAAAAAL = 
  G[10] + 
  O[20] + 
  A[1] + 
  A[1] + 
  A[1] + 
  A[1] + 
  A[1] + 
  A[1] + 
  L[15] = 
  51 = 
  0x33

Jak to? Co to znaczy, że EMIL = GOAAAAAAL? Tak, nazywamy to konfliktem w skrócie, czyli takim wypadku, gdy więcej niż jeden ciąg generuje tą samą wartość skrótu. Ktoś, kto widzi 0x33 i zna metodę liczenia może przygotować hasło, które nie jest hasłem użytkownika a mimo to można go używać do logowania.

Płynie z tego pewna nauka: jeżeli myślisz, że możesz napisać sobie własne „skracanie” to mylisz się (o ile nie jesteś jednym z dwustu-trzystu matematyków, którzy zajmują się tym zawodowo). Jeśli jesteś jednym z tych matematyków to bardzo mi przyjemnie, że czytasz ten tekst!

Co jeszcze? Kolejną dobrą praktyką jest „solenie” skrótu. Oznacza to, że do hasła dodawane jest jeszcze coś, tajemnica pozwalająca na zmianę standardowego skrótu. Czemu się to robi? Hakerzy to sprytne bestie, wzięli słownik i przepuścili go przez popularne metody skracania uzyskując wieeeelką tablelę ze skrótami. Teraz, w przypadku nieposolonych skrótów, wykradziona baza danych z użytkownikami o hasłach takich jak „kot”, „pies” i„herbata” jest czytelna niemal automatycznie. Wystarczy porównać tabelkę już przeliczonych skrótów z tymi w bazie, hop i już mamy! Stąd tylko krok do wypróbowania haseł w innych serwisach.

Kiedy posolimy hasło „pies” naszą T4J3MN1C0M, skrót wyliczony z ciągu „piesT4J3MN1C0M” nie ma nic wspólnego ze skrótem ciągu „pies” i unikamy możliwości łatwego odkrycia hasła.

Klucz prywatny, klucz publiczny

Widzieliście pewnie jakiś film o piratach. W filmach o piratach chodzi głównie o to, kto pierwszy odkopie skrzynię ze skarbami. I czy ma do niej klucz, a jeśli nie klucz, czy skrzynia wytrzyma uderzenia łopatą. Taka skrzynia reprezentuje szyfrowanie symetryczne. Jest skrzynia (archiwum) i klucz (hasło) w którego posiadanie może wejść każdy: na drodze rozboju, dziedziczenia czy też fantastycznego zbiegu okoliczności. Jest też ostra część łopaty, która służy za metaforyczny dostęp nieautoryzowany.

Właśnie zdałem sobie sprawę, że strzeliłem sobie w stopę piracką metaforą. Z armaty. Szyfrowanie symetryczne nie ma łatwej analogii w rzeczywistym świecie, a wynika to właśnie z natury fizyczności; każdy dostatecznie skomplikowany zamek ma liczbę n łopat, która go wreszcie rozwali.

Niech będzie, że nasi piraci poza korsarskim rzemiosłem parają się też czarną magią. I skrzynia jest magiczna. (Jęczenie, które teraz słyszycie, to analogia rozciągana jak guma w starych gaciach).

Ojej, z przykrością zawiadamiam, że piraci nie żyją. Wypadek przy pracy. Nie wiedzieli, że armata jest załadowana. Zginęli w słusznej sprawie. Dzięki ich śmierci mogą uniknąć dalszego męczenia tej anegdoty!

Kryptografia asymetryczna sprowadza się do posiadania pary kluczy; treści zaszyfrowane jednym z nich można odszyfrować tylko drugim i odwrotnie. Jeden z tych kluczy nazywamy prywatnym i w jego posiadaniu jesteśmy wyłącznie my (a każda z osób, z którymi przychodzi nam się wymieniać zaszyfrowanym informacjami, jest w posiadaniu własnego); drugi nazywamy publicznym i udostępniamy reszcie świata. Jeżeli ktoś chciałby przekazać mi plik dostępny tylko dla mnie, musiałby pobrać mój klucz publiczny i dodać do swojego „pęku kluczy”. Podczas szyfrowania archiwum wskazałby mój klucz publiczny, i tylko ja byłbym w stanie odszyfrować zabezpieczone archiwum (bo odszyfrować je można tylko moim kluczem prywatnym).

Klucz prywatny i publiczny tworzą nierozłączoną parę, która umożliwia osobom będącym w posiadaniu naszego klucza publicznego wygenerować zaszyfrowane informacje dostępne tylko dla nas. Nie musimy się umawiać „na hasło”, nie musimy się nawet widzieć czy też uprzednio informować o fakcie. Każdy, kto ma mój publiczny klucz może przysłać mi swoje tajemnice z pewną dozą pewności, że nikt postronny nie będzie mógł z łatwością dostać się „do środka”. Klucz prywatny jest (a przynajmniej: powinien być) dodatkowo zabezpieczony hasłem, tak więc odkodowanie informacji od nadawcy wymaga nie tylko posiadania specjalnego pliku w postaci klucza prywatnego, ale także znania hasła.

Jest to pewien szczególny wypadek „two factor authenitcation”, modelu autoryzacji który polega na „tym co wiesz” (tu: haśle do klucza prywatnego) i „tym, co masz” (tu: pliku zawierającego klucz prywatny). W podobny sposób działają tokeny, które niektórzy z Was otrzymali z banków. Autoryzacja odbywa się na podstawie skrótu RSA generowanego algorytmicznie („to, co masz”) i hasła („to, co wiesz”).

Starczy może suchej teorii. Może to niewielka dawka, ale kto próbował zjeść łyżkę cynamonu ten wie, że nawet niewielkie dawki czasem ciężko przełknąć.

W części praktycznej zainstalujemy pakiet GNU Privacy Guard, który jest otwartym odpowiednikiem PGP. GPG jest oczywiście dostępny na większość systemów operacyjnych, tych płynących w głównym nurcie jak i tych hobbistycznych. Potęga otwartego kodu.

W tekście posługuję się klientem terminalowym. Jest on wspólny dla wszystkich wersji, a i dużo łatwiej uczyć się wydając świadomie polecenia, a nie klikając guziory w interfejsie graficznym. Gdybym miał władzę nad światem to zabroniłbym w ogóle guzików. OK, może grafikom bym pozwolił, ale reszta z Was może zapomnieć. Na wasze szczęście moje dyktatorskie zapędy stępiłem grając w The Sims 2, gdzie prowadziłem postać powoli starzejącego się faceta, który pracował jako programista i czasami mdlał ze zmęczenia w kałuży własnego moczu. Lubię odmianę.

Rozkład zajęć:

  1. Wygenerowanie własnej pary kluczy
  2. Import klucza publicznego dostępnego na stronie
  3. Import klucza z serwera
  4. Eksport własnego klucza publicznego
  5. Podpisanie pliku i weryfikacja sygnatury
  6. Szyfrowanie pliku i jego odszyfrowanie
  7. Szyfrowanie symetryczne

Wygenerowanie własnej pary kluczy

gpg --gen-key [ref]Wytłuszczam komendy i klawisze[/ref]

gpg (GnuPG) 2.0.19; Copyright (C) 2012 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Proszę wybrać rodzaj klucza:
  (1) RSA i RSA (domyślne)
  (2) DSA i Elgamala
  (3) DSA (tylko do podpisywania)
  (4) RSA (tylko do podpisywania)

Klucze RSA będą miały od 1024 do 4096 bitów długości.
Jakiej długości klucz wygenerować? (2048)

Żądana długość klucza to 2048 bitów.

Okres ważności klucza.

        0 = klucz nie ma określonego terminu ważności
       = termin ważności klucza upływa za n dni
     w = termin ważności klucza upływa za n tygodni
     m = termin ważności klucza upływa za n miesięcy
     y = termin ważności klucza upływa za n lat
Okres ważności klucza? (0) 2y

Klucz traci ważność sob, 13 cze 2015, 16:35:36 CEST

Czy wszystko się zgadza (t/N)? t

Odpalenie gpg z parametrem —gen-key rozpoczyna procedurę generowania klucza. W pierwszym kroku wybieramy domyślną pozycję, tj. parę kluczy RSA, dzięki czemu możemy szyfrować i podpisywać informacje.

Długość klucza jest wprost proporcjonalna do jego “siły”. Możemy przez to rozumieć jego odporność na najbardziej prymitywne (ale często zaskakująco skuteczne) metody łamania haseł. Długość klucza wpływa też na czas, który będzie potrzebny na zaszyfrowanie/odszyfrowanie wiadomości. Dla większości zastosowań można spokojnie wybrać maksymalną długość.

Okres ważności klucza to czas po którym klucz stanie się bezużyteczny. Teoretycznie, gdyż informację tę możemy zmienić w dowolnej chwili edytując klucz. Pole to służy bardziej jako element higieny.

GnuPG musi utworzyć identyfikator użytkownika do identyfikacji klucza.

Imię i nazwisko: Emil Oppeln-Bronikowski
Adres poczty elektronicznej: emil@adrespoczty.pl
Komentarz: Testowa parka
Twój identyfikator użytkownika będzie wyglądał tak:
    "Emil Oppeln-Bronikowski (Testowa parka) "
Zmienić (I)mię/nazwisko, (K)omentarz, adres (E)mail, przejść (D)alej,
czy (W)yjść z programu? d

Musisz podać długie, skomplikowane hasło aby ochronić swój klucz prywatny.

[...]

Musimy wygenerować dużo losowych bajtów. Dobrym pomysłem aby pomóc komputerowi
podczas generowania kluczy jest wykonywanie w tym czasie innych
działań (pisanie na klawiaturze, poruszanie myszką, odwołanie się do dysków);
dzięki temu generator liczb losowych ma możliwość zebrania odpowiedniej ilości
entropii.

gpg: sprawdzanie bazy zaufania
gpg: potrzeba 3 marginalnych, 1 pełnych, model zaufania PGP
gpg: poziom: 0 poprawnych:   1 podpisanych:   0 zaufanie: 0-,0q,0n,0m,0f,1u
gpg: następne sprawdzanie bazy odbędzie się 2015-06-13

pub   2048R/EFB571A3 2013-06-13 [wygasa: 2015-06-13]
      Odcisk klucza = 6D42 0F8B E9EA 0100 A5A8  5F82 F0F6 7FBF EFB5 71A3
uid                  Emil Oppeln-Bronikowski (Testowa parka) 
sub   2048R/693FF3FC 2013-06-13 [wygasa: 2015-06-13]

W tym kroku nie ma niczego magicznego, podajemy dane idetyfikacyjne i czekamy, aż generator liczb losowych zdobędzie się na odwagę wygenerowania dla nasz kluczy. Kiedy wreszcie gpg odda kontrolę konsoli możemy zacząć zabawę w szyfrowanie.

Import klucza publicznego dostępnego na stronie

Zacznijmy od zaimportowania mojego klucza, dostępnego na serwerze HTTP.

 wget http://bronikowski.com/emil.gpg
--2013-06-13 16:41:40--  http://bronikowski.com/emil.gpg
Translacja bronikowski.com (bronikowski.com)... 46.248.176.108
Łączenie się z bronikowski.com (bronikowski.com)|46.248.176.108|:80... połączono.

Żądanie HTTP wysłano, oczekiwanie na odpowiedź... 200 OK

Długość: 2170 (2,1K) [text/plain]
Zapis do: `emil.gpg'

[...]

2013-06-13 16:41:40 (52,5 MB/s) - zapisano `emil.gpg' [2170/2170]
 gpg --import < emil.gpg
gpg: klucz 96769184: klucz publiczny ,,Emil Oppeln-Bronikowski '' wczytano do zbioru
gpg: Ogółem przetworzonych kluczy: 1
gpg:          dołączono do zbioru: 1
Pobrany plik zawiera mój klucz publiczny. Parametr --import odpowiada za dopięcie mojego klucza do pęku twoich kluczy.

 gpg --list-keys

pub   2048R/EFB571A3 2013-06-13 [wygasa: 2015-06-13]
uid                  Emil Oppeln-Bronikowski (Testowa parka) 
sub   2048R/693FF3FC 2013-06-13 [wygasa: 2015-06-13]
pub   1024D/96769184 2011-05-10
uid                  Emil Oppeln-Bronikowski 
uid                  Emil Oppeln-Bronikowski 
sub   2048g/F8FE0300 2011-05-10

Import klucza z serwera

Dzięki —list-keys możesz zobaczyć detale swojego pęku kluczy i dowiedzieć się, że mój odpowiada za dwa adresy e-mail. No dobrze, masz mój klucz bo ci powiedziałem gdzie dokładnie jest. Co w przypadku ludzi, których znasz tylko z nazwiska lub znasz ich adres e-mail? Na szczęście klucze można wysłać do specjalnego serwera zajmującego się ich dystrybucją. Klucz umieszczony w katalogu można odnaleźć bez większego problemu przy pomocy parametrów —keyserver i —search—keys

gpg --keyserver pgp.mit.edu --search-keys marks@ubuntu.com

gpg: poszukiwanie ,,marks@ubuntu.com'' z serwera hkp pgp.mit.edu

(1)     Martin M Marks (sobankiithsa@UBUNTU.CASTER) 
       Mark Shuttleworth 
       Mark Shuttleworth 
       Mark Shuttleworth 
       Mark Shuttleworth 
       Mark Shuttleworth 
         1024 bit DSA key D54F0847, utworzono: 2004-02-18
Keys 1-2 of 2 for "marks@ubuntu.com".  Wprowadź numer(y), N)astępny lub Q)uit > 2

gpg: zapytanie o klucz D54F0847 z serwera hkp pgp.mit.edu
gpg: klucz D54F0847: klucz publiczny ,,Mark Shuttleworth '' wczytano do zbioru
gpg: potrzeba 3 marginalnych, 1 pełnych, model zaufania PGP
gpg: poziom: 0 poprawnych:   1 podpisanych:   0 zaufanie: 0-,0q,0n,0m,0f,1u
gpg: następne sprawdzanie bazy odbędzie się 2015-06-13
gpg: Ogółem przetworzonych kluczy: 1
gpg:          dołączono do zbioru: 1gpg --list-keys

pub   2048R/EFB571A3 2013-06-13 [wygasa: 2015-06-13]
uid                  Emil Oppeln-Bronikowski (Testowa parka) 
sub   2048R/693FF3FC 2013-06-13 [wygasa: 2015-06-13]
pub   1024D/96769184 2011-05-10
uid                  Emil Oppeln-Bronikowski 
uid                  Emil Oppeln-Bronikowski 
sub   2048g/F8FE0300 2011-05-10
pub   1024D/D54F0847 2004-02-18
uid                  Mark Shuttleworth 
uid                  Mark Shuttleworth 
uid                  Mark Shuttleworth 
uid                  Mark Shuttleworth 
uid                  Mark Shuttleworth 
uid                  Mark Shuttleworth 
sub   1024g/9DE743C9 2004-02-18

I już, Mark Shuttleworth został odnaleziony a jego publiczny klucz umieszczony w naszym pęku. Zanim przejdziemy dalej: aby wyeksportować klucz (w przykładzie poniżej: mój publiczny) możemy użyć parametry —export i idetyfikatora klucza. Opcja -armor powoduje, że wyeksportowany plik ma formę pliku ASCII, a nie jak standardowo, binarną.

 gpg --export -armor emil@adrespoczty.pl >/tmp/emil-at-adrespoczty.gpg

I już. Plik /tmp/emil-at-adrespoczty.gpg mogę wysłać komuś e-mailem, umieścić na serwerze lub wydrukować. 2

Podpisanie pliku i weryfikacja sygnatury

Termin „podpis elektroniczny” jest wam z pewnością znany, prawda? Zwykle myślimy o kwalifikowanym podpisie elektronicznym, który jest równoznaczy z podpisem i pozwala nam na załatwianie spraw drogą elektroniczną.

Podpisanie dokumentu to procedura w której użytkownik używając swojego klucza prywatnego (który znajduje się na karcie przy podpisie kwalifikowanym) tworzy unikalny skrót z dokumentu co pozwala nam, odbiorcom, potwierdzić:

  • że podpisujący znał hasło do klucza prywatnego użytkownika (czyli „był nim” lub „bił go aż zdradził”),
  • że dokument od tego czasu nie uległ modyfikacji (modyfikacja psuje skrót),
  • datę podpisu.

Podpiszmy więc Code of Conduct.

 xhtml2pdf http://www.ubuntu.com/about/about-ubuntu/conduct

Converting www.ubuntu.com-about-about-ubuntu-conduct to /home/emil/www.ubuntu.com-about-about-ubuntu-conduct.pdf...

Zrobimy sobie z tej strony dokument PDF, a następnie, używając —sign, podpiszemy go.

 gpg --sign www.ubuntu.com-about-about-ubuntu-conduct.pdf

Musisz podać hasło aby odbezpieczyć klucz prywatny użytkownika:

,,Emil Oppeln-Bronikowski (Testowa parka) ''
długość 2048 bitów, typ RSA, numer EFB571A3, stworzony 2013-06-13

 l www.ubuntu.com-about-about-ubuntu-conduct.pdf*

-rw-r--r-- 1 emil users 19596 06-13 17:10 www.ubuntu.com-about-about-ubuntu-conduct.pdf
-rw-r--r-- 1 emil users 11244 06-13 17:10 www.ubuntu.com-about-about-ubuntu-conduct.pdf.gpg

Do wygenerowanego dokumentu dołączony został podpis. Każdy, kto otrzyma tę parę plików może zweryfikować ich autora i czas powstania.

 gpg --verify www.ubuntu.com-about-about-ubuntu-conduct.pdf.gpg

gpg: Podpisano w czw, 13 cze 2013, 17:10:42 CEST kluczem RSA o numerze EFB571A3
gpg: Poprawny podpis złożony przez ,,Emil Oppeln-Bronikowski (Testowa parka) ''

Szyfrowanie pliku i jego odszyfrowanie

Czas wreszcie się zakonspirować. Mam dokument, który chcę przekazać temu innemu sobie (z prawdziwym kluczem). Podaję więc parametr -e (szyfruj) i -r, po którym podaję listę odbiorców, a na końcu sam plik, który ma zostać zaszyfrowany.

gpg -e -r emil@fuse.pl ubuntu.com.pdf

gpg: F8FE0300: Nie ma żadnej pewności, czy ten klucz należy do tej osoby
pub  2048g/F8FE0300 2011-05-10 Emil Oppeln-Bronikowski

Odcisk klucza głównego: 820F D398 6D48 4BF3 3F3F  23CF 4276 4910 9676 9184
      Odcisk podklucza: 74BA 5DEF A968 0D74 0C4D  3197 76A2 538A F8FE 0300

NIE MA pewności, czy klucz należy do osoby wymienionej w identyfikatorze.
Jeśli nie masz co do tego żadnych wątpliwości i *naprawdę* wiesz co robisz,
możesz odpowiedzieć ,,tak'' na następne pytanie.

Użyć tego klucza pomimo to? (t/N)

Przyznam, że sam byłem zaskoczony tą wiadomością. Oczywiście zaraz strzeliłem się w czoło i przypomniałem sobie o tym, o czym nigdy nie chcę pamiętać: o poświadczaniu posiadania klucza. Widzicie, każdy może stworzyć sobie dowolny klucz i użyć w nim danych jakich mu się podoba. Nic nie stoi na przeszkodzie żebym wygenerował sobie klucz z fałszywymi informacjami i namówił ludzi do zaimportowania takiego klucza do ich systemów.

Jeżeli ktoś zaimportuje mój klucz, który mówi, że jestem billg@microsoft.com to w komunikacji z taką osobą mogę nie tylko udawać Billa, mogę używać tego klucza jako podpisu pod plikami.

Aby prawidłowo poświadczyć autentyczność pary klucz/osoba należałoby umówić się z drugą osobą na piwo, mieć przy sobie wydrukowany odcisk swojego klucza publicznego, wymienić się swoimi wydrukami, potwierdzić tożsamość i po stwierdzeniu poprawności, powrocie do domu i kacu wyedytować zaimportowany klucz i zwiększyć (lub zmiejszyć jeśli współpiwoszowi źle z oczu patrzyło) zaufanie do jego klucza, po czym ostatecznie podpisać jego klucz publiczny swoim kluczem prywatnym.

To chyba najgorsza część tej całej zabawy. Jeżeli na serio chcemy pewność korespondencji nie możemy po prostu zaufać elektronicznym drogom komunikacji. Zdaję sobie sprawę, że chodzenie z wydrukiem heksów i zmuszanie przyjaciół do składania na nich podpisów stawia nas pomiędzy zwolennikami teorii o tym, że Żydzi wysadzili WTC, a ludźmi którzy odbierają radio AM dzięki plombom. Kryptografia jest bardzo łatwa póki nie jest ciężka.

gpg --edit-key emil@fuse.pl

gpg> trust

pub  1024D/96769184  utworzono: 2011-05-10  wygasa: nigdy       użycie: SC  
                    zaufanie: marginalne    poprawność: nieznany

sub  2048g/F8FE0300  utworzono: 2011-05-10  wygasa: nigdy       użycie: E   
[    nieznane   ] (1). Emil Oppeln-Bronikowski 
[    nieznane   ] (2)  Emil Oppeln-Bronikowski

Zastanów się jak bardzo ufasz temu użytkownikowi w kwestii sprawdzania
tożsamości innych użytkowników (czy sprawdzi on odciski kluczy pobrane
z różnych źródeł, dokumenty potwierdzające tożsamość, itd.).
 1 = nie wiem albo nie powiem
 2 = NIE ufam
 3 = mam ograniczone zaufanie
 4 = mam pełne zaufanie
 5 = ufam absolutnie
 m = powrót do głównego menu

Twoja decyzja? 3

pub  1024D/96769184  utworzono: 2011-05-10  wygasa: nigdy       użycie: SC  
                    zaufanie: marginalne    poprawność: nieznany
sub  2048g/F8FE0300  utworzono: 2011-05-10  wygasa: nigdy       użycie: E   
[    nieznane   ] (1). Emil Oppeln-Bronikowski 
[    nieznane   ] (2)  Emil Oppeln-Bronikowski 
gpg> sign

Czy na pewno podpisać wszystkie identyfikatory użytkownika? (t/N) t
pub  1024D/96769184  utworzono: 2011-05-10  wygasa: nigdy       użycie: SC  
                    zaufanie: marginalne    poprawność: nieznany

Odcisk klucza głównego: 820F D398 6D48 4BF3 3F3F  23CF 4276 4910 9676 9184
    Emil Oppeln-Bronikowski 
    Emil Oppeln-Bronikowski

Czy jesteś naprawdę pewien, że chcesz podpisać ten klucz
swoim kluczem ,,Emil Oppeln-Bronikowski (Testowa parka) '' (EFB571A3)

Czy na pewno podpisać? (t/N) t

Po tym jak wyedytowałem klucz i zadeklarowałem do niego pewne zaufanie, a ostatecznie podpisałem go swoim, wcześniej występujący komunikat nie powinien się już pojawiać.

 touch tajnydokument
 gpg -r emil@fuse.pl -e tajnydokument
 l tajnydokument*

-rw-r--r-- 1 emil users   0 06-13 17:20 tajnydokument
-rw-r--r-- 1 emil users 603 06-13 17:20 tajnydokument.gpg

Szyfrowanie symetryczne

Jeżeli po przeczytaniu tego całego tekstu poczułeś nienawiść do ludzi, którzy próbują skomplikować ci życie — nie rozpaczaj — GPG/PGP potrafi szyfrować też pliki „na hasło”, wystarczy, że użyjeszcz parametru -c i podasz unikalne hasło, które dowolny inny użytkownik, bez względu czy jest w posiadaniu twojego klucza, czy też nie może odszyfrować używając hasła.

 gpg -c test.pdf

Koniec

Tekst ten przeleżał kwartał na dysku i właściwie miał już nigdy nie trafić do edytora, ale ostatnie doniesienia o tym, że amerykańskie służby szpiegowskie szpiegują wystraszyły niemało ludzi, którzy używają wszędzie tego samego hasła i pomyślałem, że to czas żeby poodcinać trochę kuponów od nowej fali paranoi.

Mówiąc już zupełnie serio. Jeżeli używacie komputerów tak jak ja to są duże szanse, że macie na dyskach wiele ważnych dokumentów. Dokumentów, które może wkładacie do Dropboksa? Albo trzymacie na pulpicie? Wystarczy, że wygenerujecie dla siebie tę parę kluczy i zaczniecie przepuszczać te pliki przez gpg -e -r . Bams. Nie musicie się z nikim wymieniać kluczami prywatnymi, nie musicie ustawiać swoich klientów pocztowych, po prostu od czasu do czasu zaszyfrujcie „sami na siebie” ten dump bazy danych.

Dodatkowo

Piotr Szotkowski, który robił mi kurektę, poleca także następujące teksty:

  1. Co nie powinno się zdarzyć. Działo się to dawno temu kiedy jeszcze nie wiedziałem o czymś, co nazywamy „soleniem haseł”.
  2. wydrukować? Tak, o tym trochę później