gpg - šifrování záloh veřejným klíčem (dlouhé)

[Miroslav BENES]

Přeji krásný den !

Nastavuji tu zálohovací skripty, které by měly svá data šifrovat před 
odesláním dál. Používám na to gpg. Jako zdroj informací posloužla 
manuálová stránka a článek o gpg na root-ovi.
Popíšu svůj postup. který proložím dotazy, předem děkuji za vaše odpovědi.

SW : FC3/FC4, gnupg-1.4.2-0_29.rhfc3.at / gnupg-1.4.2-0_29.rhfc4.at


a) na svém stroji vygeneruji klíče příkazem "gpg --gen-key". Z 
nabízených možností

(1) DSA a ElGamal (implicitní)
(2) DSA (pouze pro podpis)
(5) RSA (pouze pro podpis)

.. jsem vybral (1), protože se nebude používat jen na podepisování. 
Doufám, že je to správně.

Po vygenerování vznikly soubory :
pubring.gpg
pubring.gpg~
secring.gpg
trustdb.gpg

Dotazy :
# veřejný klíč
- proč je tam veřejný klíč 2x ? Obsah těch souborů (binární smetí) je na 
pohled prakticky stejný. Mají ale různé kontrolní součty.
- když provedu export veřejnho klíče pomocí "gpg --export >pubring.exp", 
dostanu soubor, který se opět oběma veřejným klíčům podobá, ale je o 8 B 
kratší. Je to normální ?!?
- pokud se exportuje v čitelné podobě (parametr "-a"), bude použitelnost 
takového souboru stejná jako u jeho binární podoby (tj. bez ohledu na 
verzi gpg a platforomu) ?
# soukromý klíč
- jak se dá vyexportovat soukromý klíč ? Zkusil jsem postup podle 
dokumentace "gpg --export-secret-keys", ale nedopadlo to dobře :
gpg: exportování tajného klíče není povoleno
gpg: VAROVÁNÍ: nebylo nic vyexportováno

Kde se povoluje export privátního klíče ? Prošel jsem si všechny 
možnosti příkazu "gpg --edit-key", ale nic příhodného tam nevidím.


b) vyexportovaný veřejný klíč jsem naimportoval na druhém stroji, kde se 
bude používat pro šifrování :
# gpg --import /tmp/pubring.txt
...
gpg: key 99999999: public key "...." imported
gpg: Total number processed: 1
gpg:               imported: 1


Zkusil jsem s ním zašifrovat jeden soubor :
# gpg -er 99999999 /tmp/test.txt
gpg: 88888888: There is no assurance this key belongs to the named user

pub  2048g/88888888 2006-03-02 ....
Primary key fingerprint: 3333 3333 ...
     Subkey fingerprint: 4444 444 ...

It is NOT certain that the key belongs to the person named
in the user ID.  If you *really* know what you are doing,
you may answer the next question with yes.

Use this key anyway? (y/N)

.. což je naprd, protože se to takto nedá používat neinteraktivně v 
dávkách.
Nastavil jsem tedy tomut klíči důvěru :
gpg --edit-keys 99999999
Command> trust
...
 1 = I don't know or won't say
 2 = I do NOT trust
 3 = I trust marginally
 4 = I trust fully
 5 = I trust ultimately
 m = back to the main menu

Zvolil jsem "5".

Dotazy :
- není toto nastavení (absolutní důvěra) nebezpečné ? Mohlo by se stát, 
že by s tím v budoucnu mohly být problémy ?
- dal by se (čistě teoreticky) pod stejným ID vnutit jiný klíč ? 
Předpokládám že ne, ale docela mě tato představa děsí  - tj. že by se 
(po zásahu "vtipálka") šifrovalo veřejným klíčem, ke kterému nebude 
existovat soukromý ...
- dá se na "původním" stroji vyexportovat veřejný klíč tak, aby byl hned 
po importu důvěryhodný ?
Upřimně řečeno jsem z tohoto postoje gpg poněkud zmaten. Pokud si např, 
naimportuji veřejný klíč k ověřování RPM balíčků, pak takovému klíči bud 
důvěřuji (což platí pro použití s rpm) a další nastavování důvěry nemá 
smysl - nebo takovému klíči nedůvěřuji a nemá cenu abych ho importoval a 
používal. V této úvaze vycházím z předpokladu, že s gpg začínám "s 
čistým stolem" bez jakýchkoliv certifikátů, takže žadný klíč "zvenku" 
nemám proti čemu ověřit.
- je použitý postup "zdůvěryhodnění" klíče správný ?
- dá se tento prok provést neinterativně (v dávce) ?


c) rozšfrování dat na jiném stroji
Zkusil jsem data rozšifrovat na dalším stroji (na němž se ani 
negenerovaly klíče ani se nešifroval testovací soubor). Pro tento úkon 
by ale bylo potřeba importovat soukromý klíč. Jelikož se mi nepovedl 
jeho export na začástku pokusu, zkusil jsem importovat data ze souboru 
secring.gpg :
# gpg --import /tmp/secring.gpg
gpg: importing secret keys not allowed
gpg: Total number processed: 1
gpg:       secret keys read: 1

Dotazy :
- jak se povoluje import soukromého klíče ?
- dá se pro uložení soukromého klíče použít "USB token" ? Máme tu k 
dispozici Rainbow iKey2032. Pro podobné modely (iKey 3000) je podpora v 
projektu OpenSC, ale o tomto typu jsem se dozvěděl :

"OpenSC does not support iKey 2032 in any way - there is no 
documentation for the smart card inside, so we can't support it and won't."

Tato informace je z mailové konfernce o OpenSC a je z května minulého 
roku. Nevíte někdo, jestli se od té doby hnuly ledy ?


d) použití gnupg2
Pokud se pokusím stejné kroky udělat s gpg2, chová se to stejně s 
drobným rozdílem : gpg2 provede export/import soukromého klíče.

Dotazy :
- dá se na gpg2 spolehnout ? Podle popisu je to ještě ve vývoji, takže 
mám trochu obavy o kompatibilitu (jak budoucí tak i napříč platformami)
- export soukromého klíče jsem provedl takto :

$ gpg2 --export-secret-key -a >/tmp/sec.key
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: WARNING: This version of gpg is not very matured and
gpg: WARNING: only intended for testing.  Please keep using
gpg: WARNING: gpg 1.2.x, 1.3.x or 1.4.x for OpenPGP

Obsah souboru sec.key je následující :
$ cat /tmp/sec.key
-----BEGIN PGP PRIVATE KEY BLOCK-----
Version: GnuPG v1.9.16 (GNU/Linux)

lQG7BEQ...
... (25 řádků vynecháno) ...
URHpDcAGIFp3JoTclA==
=j2dl
-----END PGP PRIVATE KEY BLOCK-----

Podle selského rozumu tento soubor obsahuje soukromý klíč.
Po jeho naimportovíní se ovšem ve výpisu objeví i veřejný, který tedy je 
k soukromému "přibalen". To jen tak pro zajímavost (debata na toto téma 
viz archiv).





Děkuji za pozornost a za váš čas, když už jste se dobrali až nakonec 
tohoto příspěvku.