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

[Dan Ohnesorg]

Dne Thu, Mar 02, 2006 at 01:04:20PM +0100, Miroslav BENES napsal:

> 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ě.

Urcite, kdysi se pro kompatibilitu s pgp muselo vybirat RSA, ale myslim ze
dneska uz PGP umi i DSA.


> 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.

No nevim, ja mam jen jeden, skoro to vypada jako byste jej editovat v
nejakem editoru. Nebo proste gpg je tak chytre, ze udelalo zalohu.

> - 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í ?!?

Je protoze pubring je RING verejnych klicu - databaze kde jich muze byt
hodne. exportem jeden vyexportujete, takze uz nema hlavicku.

> - 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) ?

Podle me dokonce obecne lepsi, protoze u ascii souboru nehrozi tolik jeho
poskozeni, napr. pri vymene mezi platformami.

> # 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.

Podle me export mozny neni - neni implementovan. Nicmene bezne prenasim
secring.gpg a zadny problem pri to nevznika.

> - 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 ?

Je, to oznaceni nic neznamena, je to jen poznamka pro obsluhu, jak je ten
klic duveryhodny, kdyz jste si ho prenesl sam tak zrejme bude absolutne
duveryhodny.

> - 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ý ...

Ciste teoreticky ano. Klic ma 2048 nebo vice bitu, ID 32. Nicmene pokud
nebudete overovat citelnost zaloh, tak existuji mnohem jednodussi postupy
jak to provest, napr. vnutit tam uplne jiny klic s jinym ID a upravit jeho
kontrolu. A pokud budete overovat citelnost, tak na to ze proti sobe nesedi
privatni a verejny klic prijdete raz dva.

> - dá se na "původním" stroji vyexportovat veřejný klíč tak, aby byl 
> hned po importu důvěryhodný ?

Na duveryhodnost je otazka prijemce, ten si ji musi zvolit sam. Existuje si
duvery, kde si mohou uzivatele sve nazory na duveryhodnost sdilet, ale
rozhodnuti pri importu musi udelat kazdy sam za sebe.

> 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) ?

GPG neni o podepisovani baliku, ale obecne o vymene dat mezi lidmi. A prave
moznost nastavovat jak klici duverujete umoznuje takove veci jako
podepsiovani klicu jinych lidi a tim budovani site duvery bez potreby
centralni CA jako je tomu u PKI. V davce se to provest da, je to v
dokumentaci gpg, kdysi jsem to cetl.

> 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 ?

prenese se secring.gpg

> - 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 ?

Temer jiste ne. 

Ale muzete pouzit USB token jako mass storage s sifrovanym souborovym
systemem a nebo verit pasphrase na klici, ta by take nemela byt snadno
hodnutelna.

> 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!

Neda.

> 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).

Ano to se tak proste dela.

zdravim
dan