Úvod do GPG

27.5.2020 20:48 | Přečteno: 4082× | Linux | | poslední úprava: 28.5.2020 09:59

V jednom z minulých zápisků jsem psal, že jsem pořídil několik Yubikey 5 a zkoumám jejich možnosti. Abych mohl používat OpenPGP, musel jsem to nastudovat. Jelikož mi přijde, že to je poněkud uživatelsky nepřítulná oblast, tak se podělím o zkušenosti, třeba se to bude někomu hodit.

Úvod

Dnes se podíváme jen na GnuPG, aplikace v Yubico bude až někdy příště.

Obor šifrování má obecně jeden velký problém. Lidi, kteří v něm dělají, vědí opravdu hodně. Takže když něco publikují, je to pro běžného smrtelníka příliš odborné, takže nečitelné. Naopak publikace pro běžného smrtelníka jsou velmi (ale opravdu velmi) zjednodušené. Člověk, který je znalostmi tak mezi oběma skupinami, aby informace s lampou pohledal.

Skromně si myslím, že jsem z té chytřejší části populace (jako ostatně většina zdejšího obecenstva) a přesto některé věci ne úplně chápu. Proto prosím, pokud napíšu nějakou blbost, ozvěte se.

Začněme s vysvětlením pojmů PGP, OpenPGP a GnuPG. PGP je aplikace, která zajišťuje šifrování. Je docela stará (rok 1991). OpenPGP je specifikace šifrovacího frameworku, za kterou stojí stejný tým lidí, jejichž cílem bylo mít specifikaci nezatíženou patenty. GnuPG (známo též jako GPG) je potom její (re)implementace.

Teď přeskočím základy asymetrické kryptografie, tu si prosím nastudujte sami (pojmy veřejný a soukromý=privátní klíč, šifrování, dešifrování, hash, podpis, certifikát). Už tak bude zápisek strašně dlouhý. Podklíče, Subkeys Jedna z pvních věcí, na kterou narazíte při studiu GPG, je pojem podklíč (subkey). V dokumentaci se dočtete:

Subkeys are keys to use in every day life. They are bound to your private key and are used for signing and decrypting.

Oficiální dokumentace Debianu o podklíčích říká (https://wiki.debian.org/Subkeys):

OpenPGP further supports subkeys, which are like the normal keys, except they're bound to a master key pair ... In other words, subkeys are like a separate key pair, but automatically associated with your main key pair.

Ale co znamená 'bound to'? Po delším hledání jsem našel aspoň nějakou odpověď ve smyslu, že subkey je podpesaný hlavním klíčem (https://superuser.com/questions/1113308/what-is-the-relationship-between-an-openpgp-key-and-its-subkey). Taky je o tom zmínka v https://gnupg.org/faq/subkey-cross-certify.html. Která část klíče je podepsaná? Asi veřejný klíč, u soukromého by to nedávalo smysl. Tím si vlastně každý ze sebe vyrobí certifikační autoritu.

Což má za následek, že když někdo podepíše cizí veřejný klíč, může někoho uvést v omyl, že tento klíč patří někomu jinému, než kdo ho vydal. (https://nullprogram.com/blog/2019/07/10/, článek datovaný July 10, 2019). V diskusi ke článku uživatel zaarn nebral servítky a na adresu GPG doslova napsal (ač nedoplněno emotikony, každý v tom jistě cítí sarkasmus):

Man, where would we be without the people that defend GPG? Possibly in a world with easy-to-use mail cryptography solutions but who wants that?

(https://news.ycombinator.com/item?id=20401758). Tato diskuse kupodivu nepochází z doby krypotografického pravěku, ale je 10 měsíců stará (přesné datum tam u příspěvků nepíší, což mě taky pěkně se. štve. Není to jediný případ, kdy se u příspěvků nepíše přesný údaj, obzvláště nasí.ací je to třeba ve firemním ticketovacím trackeru, kde se místo přesného data zalogování problému dozvím jenom 'a month ago'). V téže diskusi jsem našel odkaz na dokumentaci GPG, kde se to snaží nějak vyřešit (https://gnupg.org/faq/subkey-cross-certify.html). Četl jsem to pozdě večer a nepochopil jsem to, musím si to přečíst ještě jednou, až se pořádně vyspím.

Názor, že GPG není úplně dokonalý program, je vcelku rozšířený. Opět cituji z oficiální dokumentace Debianu (https://wiki.debian.org/Subkeys):

Unfortunately, GnuPG's user interface is not entirely fun to use.

K tématu bych ještě citoval první větu z release notes ke GnuPG verze 2.1 (https://www.gnupg.org/faq/whats-new-in-2.1.html):

GnuPG version 2.1 (now known as 2.2) comes with ...

Tak si říkám, že ty stížnosti jsou asi opodstatněné.

Pojďme dále. Ve všech návodech se píše, že si máte vygenerovat hlavní klíč (master key) a k němu potom 2 podklíče (subkey). Jeden na podepisování, druhý na šifrování. V souvislosti s tím jsem našel zmínku, že některé algoritmy umí jenom podepisovat a jiné jenom šifrovat. To už mi hlava nebere, když uvážím, že podepsat znamená zašifrovat hash. Ale možná to tak mají jenom některé šifry (myslím že RSA to tak má). Pozadí této rady je jednoduché. Není nic špatného používat na běžnou práci master key (pokud tedy dobře víte, co děláte), množství podpesaných dokumentů nepomůže útočníkovi lousknout soukromý klíč. Ale musíte ho mít pořád u sebe, na disku, flashce nebo i na nějakém security tokenu. Problém je, že nějakou chybou můžete svůj klíč kompromitovat (nechtěně ho někam nakopírujete, ztratíte flashku apod.). Klíč můžete stáhnout (revocate), tím ovšem přijdete o svoji identitu, což je nemilé.

Řešení je tedy v podklíčích. Hlavní klíč (master key) si vygenerujete někde ve velmi bezpečném prostředí - třeba offline počítač, může to být klidně stará šunka, o výkon nejde. Potom si ke klíči vygenerujete podklíče a teprve ty si přenesete do počítače na běžné používání. Podle míry paranoi můžeme diskutovat o tom, jaký přenos je bezpečný a jestli offline počítač je opravdu offline a bezpečný.

Doporučuje se používat jiný klíč na šifrování a jiný na podepisování. Je to pro případ, aby vás někdo nevmanipuloval do situace, kdy zašifrujete soukromým klíčem hash nějaké zprávy. To by totiž fakticky znamenalo, že jste tu zprávu podepsali, protože to přesně je digitální podpis. V základním nastavení to asi amatér nedokáže, ale pokud vám někdo pošle příkazy, které jenom odpálíte, tak se může stát leccos. Opět připomínám, opravte mě, pokud to je blbost.

Generování klíčů

A teď se vrhneme na GPG. Dokumentace Debianu je na https://wiki.debian.org/GnuPG. Všechny ukázky jsou na Debianu 9.1.

Příprava. Jen pro informaci, můj počítač se jmenuje mike podle postavy ze seriálu Breaking Bad.

tom@mike:~$ gpg --version
gpg (GnuPG) 2.1.18
libgcrypt 1.7.6-beta
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/tom/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

Dozvěděli jsme, že mám GPG verze 2.1 Teď pojedeme podle návodu na Debianu. Vytvoření konfigurace:

tom@mike:~$ mkdir ~/.gnupg
tom@mike:~$ cat >> ~/.gnupg/gpg.conf <<EOF
personal-digest-preferences SHA256
cert-digest-algo SHA256
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
EOF

Když začneme na prudko generovat klíče

tom@mike:~$ gpg --gen-key

Nakonec skončíme s chybou

gpg: agent_genkey failed: No such file or directory
Key generation failed: No such file or directory

Řešením je, aspoň u mně, vytvořit adresář na soukromé klíče

tom@mike:~$ mkdir -p ~/.gnupg/private-keys-v1.d
tom@mike:~$ chmod 700 ~/.gnupg/private-keys-v1.d

A ještě je dobré omezit práva i na hlavním adresáři, aby si GnuPG nestěžoval.

tom@mike:~$ chmod 700 ~/.gnupg

Přistoupíme ke generování. V Debianu se automaticky vytváří podklíč na šifrování, proto se bude dvakrát ptát na heslo (vyskočí okno, není vidět ve výpisu), dávám bez hesla.

tom@mike:~$ gpg --gen-key
gpg (GnuPG) 2.1.18; Copyright (C) 2017 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.

gpg: keybox '/home/tom/.gnupg/pubring.kbx' created
Note: Use "gpg --full-generate-key" for a full featured key generation dialog.

GnuPG needs to construct a user ID to identify your key.

Real name: Example First
Email address: example.first@example.example
You selected this USER-ID:
    "Example First <example.first@example.example>"

Change (N)ame, (E)mail, or (O)kay/(Q)uit? o
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: /home/tom/.gnupg/trustdb.gpg: trustdb created
gpg: key 4703A5B671B96E4D marked as ultimately trusted
gpg: directory '/home/tom/.gnupg/openpgp-revocs.d' created
gpg: revocation certificate stored as '/home/tom/.gnupg/openpgp-revocs.d/153130ED26CA404C8B29795B4703A5B671B96E4D.rev'
public and secret key created and signed.

pub   rsa2048 2020-05-24 [SC] [expires: 2022-05-24]
      153130ED26CA404C8B29795B4703A5B671B96E4D
      153130ED26CA404C8B29795B4703A5B671B96E4D
uid                      Example First <example.first@example.example>
sub   rsa2048 2020-05-24 [E] [expires: 2022-05-24]

To nejsme moc šťastní, protože klíče jsou jen 2048bitové. Navíc se GPG ani neptal, jaké klíče vlastně chceme. Nápověda je na začátku výpisu – použijeme –full-generate-key.

tom@mike:~$ gpg --full-generate-key
gpg (GnuPG) 2.1.18; Copyright (C) 2017 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.

Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
Your selection? 1
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 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) 
Key does not expire at all
Is this correct? (y/N) y

GnuPG needs to construct a user ID to identify your key.

Real name: Example Second
Email address: example.second@example.example
Comment: Second
You selected this USER-ID:
    "Example Second (Second) <example.second@example.example>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: key 942AFD64430801F7 marked as ultimately trusted
gpg: revocation certificate stored as '/home/tom/.gnupg/openpgp-revocs.d/E2066568A1FB5723B550410D942AFD64430801F7.rev'
public and secret key created and signed.

pub   rsa4096 2020-05-24 [SC]
      E2066568A1FB5723B550410D942AFD64430801F7
      E2066568A1FB5723B550410D942AFD64430801F7
uid                      Example Second (Second) <example.second@example.example>
sub   rsa4096 2020-05-24 [E]

Tohle by už šlo, mohl jsem si zvolit druh klíče i jeho délku.

Zkusím ještě zkusit něco jiného, než defaultní volbu

tom@mike:~$ gpg --full-generate-key
gpg (GnuPG) 2.1.18; Copyright (C) 2017 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.

Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
Your selection? 4
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 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) 
Key does not expire at all
Is this correct? (y/N) y

GnuPG needs to construct a user ID to identify your key.

Real name: Example Third
Email address: example.third@example.example
Comment: Third
You selected this USER-ID:
    "Example Third (Third) <example.third@example.example>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: key DD41A31BA28D0199 marked as ultimately trusted
gpg: revocation certificate stored as '/home/tom/.gnupg/openpgp-revocs.d/40DB1E1705A9B52E3EFBB29EDD41A31BA28D0199.rev'
public and secret key created and signed.

Note that this key cannot be used for encryption.  You may want to use
the command "--edit-key" to generate a subkey for this purpose.
pub   rsa4096 2020-05-24 [SC]
      40DB1E1705A9B52E3EFBB29EDD41A31BA28D0199
      40DB1E1705A9B52E3EFBB29EDD41A31BA28D0199
uid                      Example Third (Third) <example.third@example.example>

Tady se mi povedlo vytvořit klíč bez podklíče, takže pokud nechcete podklíče vytvářet automaticky, nemusíte.

Výpis klíčů:

tom@mike:~$ gpg --list-keys
gpg: checking the trustdb
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   3  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 3u
gpg: next trustdb check due at 2022-05-24
/home/tom/.gnupg/pubring.kbx
----------------------------
pub   rsa2048 2020-05-24 [SC] [expires: 2022-05-24]
      153130ED26CA404C8B29795B4703A5B671B96E4D
uid           [ultimate] Example First <example.first@example.example>
sub   rsa2048 2020-05-24 [E] [expires: 2022-05-24]

pub   rsa4096 2020-05-24 [SC]
      E2066568A1FB5723B550410D942AFD64430801F7
uid           [ultimate] Example Second (Second) <example.second@example.example>
sub   rsa4096 2020-05-24 [E]

pub   rsa4096 2020-05-24 [SC]
      40DB1E1705A9B52E3EFBB29EDD41A31BA28D0199
uid           [ultimate] Example Third (Third) <example.third@example.example>

Příkaz má několik voleb, kterými se dají ovlivnit vypisované informace. Ale na první pohled vidíte, že bez příručky se v tom výstupu nevyznáte. Všimneme se, že třetí klíč nemá podklíč (neobsahuje položku sub).

Jako další cvičeníčko vytvoříme další podklíč pro první klíč.

tom@mike:~$ gpg --edit-key 153130ED26CA404C8B29795B4703A5B671B96E4D
gpg (GnuPG) 2.1.18; Copyright (C) 2017 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.

Secret key is available.

sec  rsa2048/4703A5B671B96E4D
     created: 2020-05-24  expires: 2022-05-24  usage: SC  
     trust: ultimate      validity: ultimate
ssb  rsa2048/F1C6AE6DAF3AE8BF
     created: 2020-05-24  expires: 2022-05-24  usage: E   
[ultimate] (1). Example First <example.first@example.example>

gpg> addkey
Please select what kind of key you want:
   (3) DSA (sign only)
   (4) RSA (sign only)
   (5) Elgamal (encrypt only)
   (6) RSA (encrypt only)
Your selection? 4
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 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) 
Key does not expire at all
Is this correct? (y/N) y
Really create? (y/N) y
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.

sec  rsa2048/4703A5B671B96E4D
     created: 2020-05-24  expires: 2022-05-24  usage: SC  
     trust: ultimate      validity: ultimate
ssb  rsa2048/F1C6AE6DAF3AE8BF
     created: 2020-05-24  expires: 2022-05-24  usage: E   
ssb  rsa4096/8F2D5825D5689DE1
     created: 2020-05-24  expires: never       usage: S   
[ultimate] (1). Example First <example.first@example.example>

gpg> save

Opět výpis

tom@mike:~$ gpg --list-keys
/home/tom/.gnupg/pubring.kbx
----------------------------
pub   rsa2048 2020-05-24 [SC] [expires: 2022-05-24]
      153130ED26CA404C8B29795B4703A5B671B96E4D
uid           [ultimate] Example First <example.first@example.example>
sub   rsa2048 2020-05-24 [E] [expires: 2022-05-24]
sub   rsa4096 2020-05-24 [S]

pub   rsa4096 2020-05-24 [SC]
      E2066568A1FB5723B550410D942AFD64430801F7
uid           [ultimate] Example Second (Second) <example.second@example.example>
sub   rsa4096 2020-05-24 [E]

pub   rsa4096 2020-05-24 [SC]
      40DB1E1705A9B52E3EFBB29EDD41A31BA28D0199
uid           [ultimate] Example Third (Third) <example.third@example.example>

Teď zkusíme přidat podklíč k třetímu klíči (ten je zatím bez podklíčů) a nastavit mu krátkou dobu expirace

tom@mike:~$ gpg --edit-key 40DB1E1705A9B52E3EFBB29EDD41A31BA28D0199
gpg (GnuPG) 2.1.18; Copyright (C) 2017 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.

Secret key is available.

sec  rsa4096/DD41A31BA28D0199
     created: 2020-05-24  expires: never       usage: SC  
     trust: ultimate      validity: ultimate
[ultimate] (1). Example Third (Third) <example.third@example.example>

gpg> addkey
Please select what kind of key you want:
   (3) DSA (sign only)
   (4) RSA (sign only)
   (5) Elgamal (encrypt only)
   (6) RSA (encrypt only)
Your selection? 5
ELG keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 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) 2w
Key expires at Sun 07 Jun 2020 10:35:07 PM CEST
Is this correct? (y/N) y
Really create? (y/N) y
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.

sec  rsa4096/DD41A31BA28D0199
     created: 2020-05-24  expires: never       usage: SC  
     trust: ultimate      validity: ultimate
ssb  elg4096/291D42343D4209C2
     created: 2020-05-24  expires: 2020-06-07  usage: E   
[ultimate] (1). Example Third (Third) <example.third@example.example>

gpg> save

Teď si klíče zase zobrazíme a zkusíme, k čemu je dobrý přepínač --with-keygrip

tom@mike:~$ gpg --list-keys --with-keygrip 
/home/tom/.gnupg/pubring.kbx
----------------------------
pub   rsa2048 2020-05-24 [SC] [expires: 2022-05-24]
      153130ED26CA404C8B29795B4703A5B671B96E4D
      Keygrip = 377C02935881630C7F4BA0807C8D753B6635CB90
uid           [ultimate] Example First <example.first@example.example>
sub   rsa2048 2020-05-24 [E] [expires: 2022-05-24]
      Keygrip = 383B2ACADA9228E29820F89A1C4A4F4D18408562
sub   rsa4096 2020-05-24 [S]
      Keygrip = E186137C42342AA7D3588183CC4B1FB6ED590E61

pub   rsa4096 2020-05-24 [SC]
      E2066568A1FB5723B550410D942AFD64430801F7
      Keygrip = 8590A9CA8F1385AD2984DD1ED501B1EDA947C90C
uid           [ultimate] Example Second (Second) <example.second@example.example>
sub   rsa4096 2020-05-24 [E]
      Keygrip = 541540C36217BEED3F9147261B050026CB93166B

pub   rsa4096 2020-05-24 [SC]
      40DB1E1705A9B52E3EFBB29EDD41A31BA28D0199
      Keygrip = D6C7F494928F6EA71BE53DA60BDEBFA0FCBC6DB2
uid           [ultimate] Example Third (Third) <example.third@example.example>
sub   elg4096 2020-05-24 [E] [expires: 2020-06-07]
      Keygrip = 1E810267D620D288961DEA34A08CE42932ACEE10

Když si zobrazíme soubory se soukromými klíči, tak je tasné, co to ten grip je.

tom@mike:~$ ls .gnupg/private-keys-v1.d/
1E810267D620D288961DEA34A08CE42932ACEE10.key
377C02935881630C7F4BA0807C8D753B6635CB90.key
383B2ACADA9228E29820F89A1C4A4F4D18408562.key
541540C36217BEED3F9147261B050026CB93166B.key
8590A9CA8F1385AD2984DD1ED501B1EDA947C90C.key
D6C7F494928F6EA71BE53DA60BDEBFA0FCBC6DB2.key
E186137C42342AA7D3588183CC4B1FB6ED590E61.key

A to jsme ještě nevyzkoušeli přepínač --expert. Přibude nám možnost Authenticate. Klíč, který má tuto schopnost (capability), použijeme pro autentifikaci v SSH.

tom@mike:~$ gpg --full-generate-key --expert
gpg (GnuPG) 2.1.18; Copyright (C) 2017 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.

Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
   (7) DSA (set your own capabilities)
   (8) RSA (set your own capabilities)
   (9) ECC and ECC
  (10) ECC (sign only)
  (11) ECC (set your own capabilities)
Your selection? 8

Possible actions for a RSA key: Sign Certify Encrypt Authenticate 
Current allowed actions: Sign Certify Encrypt 

   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection? s

Possible actions for a RSA key: Sign Certify Encrypt Authenticate 
Current allowed actions: Certify Encrypt 

   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection? e

Possible actions for a RSA key: Sign Certify Encrypt Authenticate 
Current allowed actions: Certify 

   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection? a

Possible actions for a RSA key: Sign Certify Encrypt Authenticate 
Current allowed actions: Certify Authenticate 

   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection? q
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 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) 
Key does not expire at all
Is this correct? (y/N) y

GnuPG needs to construct a user ID to identify your key.

Real name: Example Fourth
Email address: example.fourth@example.example
Comment: Authenticate
You selected this USER-ID:
    "Example Fourth (Authenticate) <example.fourth@example.example>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: key E815C1EA446EE732 marked as ultimately trusted
gpg: revocation certificate stored as '/home/tom/.gnupg/openpgp-revocs.d/46C4F15BF45B274B155F9E08E815C1EA446EE732.rev'
public and secret key created and signed.

Note that this key cannot be used for encryption.  You may want to use
the command "--edit-key" to generate a subkey for this purpose.
pub   rsa4096 2020-05-24 [CA]
      46C4F15BF45B274B155F9E08E815C1EA446EE732
      46C4F15BF45B274B155F9E08E815C1EA446EE732
uid                      Example Fourth (Authenticate) <example.fourth@example.example>

Ještě jednou pro kontrolu výpis klíčů

tom@mike:~$ gpg -k
/home/tom/.gnupg/pubring.kbx
----------------------------
pub   rsa2048 2020-05-24 [SC] [expires: 2022-05-24]
      153130ED26CA404C8B29795B4703A5B671B96E4D
uid           [ultimate] Example First <example.first@example.example>
sub   rsa2048 2020-05-24 [E] [expires: 2022-05-24]
sub   rsa4096 2020-05-24 [S]

pub   rsa4096 2020-05-24 [SC]
      E2066568A1FB5723B550410D942AFD64430801F7
uid           [ultimate] Example Second (Second) <example.second@example.example>
sub   rsa4096 2020-05-24 [E]

pub   rsa4096 2020-05-24 [SC]
      40DB1E1705A9B52E3EFBB29EDD41A31BA28D0199
uid           [ultimate] Example Third (Third) <example.third@example.example>
sub   elg4096 2020-05-24 [E] [expires: 2020-06-07]

pub   rsa4096 2020-05-24 [CA]
      46C4F15BF45B274B155F9E08E815C1EA446EE732
uid           [ultimate] Example Fourth (Authenticate) <example.fourth@example.example>

Podpis

Zkusíme něco podepsat. Máme soubor sifrovani.txt s prvním nástřelem textu.

gpg -s sifrovani.txt

Vytvoří se soubor sifrovani.txt.gpg

Která identita se použila? To zjistíme při verifikaci podpisu.

tom@mike:~$ gpg --verify sifrovani.txt.gpg
gpg: Signature made Tue 26 May 2020 10:56:26 PM CEST
gpg:                using RSA key 5ABA0105F9EEDE9BD0021DC08F2D5825D5689DE1
gpg: Good signature from "Example First <example.first@example.example>" [ultimate]

Vidíme, že se použila první identita. Ale nevím, jestli se použil master key nebo subkey. Po pravdě, nevím, co znamená ten šílený výraz 5ABA0105F9EEDE9BD0021DC08F2D5825D5689DE1.

Kdybychom chtěli použít jinou identitu, použijeme přepínač -u nebo –local-user, přičemž do argumentu může přijít prakticky cokoliv unikátního z metadat. Bere se první klíč, který vyhovuje.

tom@mike:~$ gpg -u second -s sifrovani.txt 
File 'sifrovani.txt.gpg' exists. Overwrite? (y/N) y
tom@mike:~$ gpg --verify sifrovani.txt.gpg
gpg: Signature made Tue 26 May 2020 11:13:03 PM CEST
gpg:                using RSA key E2066568A1FB5723B550410D942AFD64430801F7
gpg:                issuer "example.second@example.example"
gpg: Good signature from "Example Second (Second) <example.second@example.example>" [ultimate]

Třeba v následujícím příkazu se chytne na kousek emailu:

tom@mike:~$ gpg -u e.t -s sifrovani.txt 
File 'sifrovani.txt.gpg' exists. Overwrite? (y/N) y
tom@mike:~$ gpg --verify sifrovani.txt.gpg
gpg: Signature made Tue 26 May 2020 11:15:40 PM CEST
gpg:                using RSA key 40DB1E1705A9B52E3EFBB29EDD41A31BA28D0199
gpg:                issuer "example.third@example.example"
gpg: Good signature from "Example Third (Third) <example.third@example.example>" [ultimate]

Teď zkusíme kulišárnu:

tom@mike:~$ gpg -u fourth -s sifrovani.txt 
gpg: skipped "fourth": Unusable secret key
gpg: signing failed: Unusable secret key

Čtvrtý klíč totiž nemá podklíč na podepisování.

Šifrování

Teď ještě cvičně něco zašifrujeme

tom@mike:~$ gpg -o sifrovani.txt.1 -e  sifrovani.txt 
You did not specify a user ID. (you may use "-r")

Current recipients:

Enter the user ID.  End with an empty line: second

Current recipients:
rsa4096/8805963B89C93FE1 2020-05-24 "Example Second (Second) <example.second@example.example>"

Enter the user ID.  End with an empty line: 
tom@mike:~$ ls -l sifrovani.txt*
-rwxrwxrwx 1 tom tom 23148 May 24 23:11 sifrovani.txt
-rw-r--r-- 1 tom tom  6878 May 26 23:28 sifrovani.txt.1

Jenom ta malá velikost mě zaráží, asi je tam nějaká komprese

Rozšifrujeme

tom@mike:~$ gpg -o sifrovani.txt.2 -d  sifrovani.txt.1
gpg: encrypted with 4096-bit RSA key, ID 8805963B89C93FE1, created 2020-05-24
      "Example Second (Second) <example.second@example.example>"
tom@mike:~$ ls -l sifrovani.txt*
-rwxrwxrwx 1 tom tom 23148 May 24 23:11 sifrovani.txt
-rw-r--r-- 1 tom tom  6878 May 26 23:28 sifrovani.txt.1
-rw-r--r-- 1 tom tom 23148 May 26 23:30 sifrovani.txt.2

Výsledek je stejný, zkontrolováno pomocí cmp i diff.

A opět kulišárna

tom@mike:~$ gpg -u fourth -o sifrovani.txt.1 -e  sifrovani.txt 
You did not specify a user ID. (you may use "-r")

Current recipients:

Enter the user ID.  End with an empty line: 
gpg: no valid addressees
gpg: sifrovani.txt: encryption failed: No user ID
tom@mike:~$ gpg -o sifrovani.txt.1 -e  sifrovani.txt 
You did not specify a user ID. (you may use "-r")

Current recipients:

Enter the user ID.  End with an empty line: fourth
No such user ID.

Current recipients:

Enter the user ID.  End with an empty line: 
gpg: no valid addressees
gpg: sifrovani.txt: encryption failed: No user ID

Čtvrtý klíč totiž nemá ani podklíč na šifrování.

Podle dokumentace byste měli zálohovat master key (tady jich máme několik) na bezpečné místo a z původního umístění ho smazat.

Tímto končí exkurze do světa GPG. Pokud bude nějaké příště, tak se podíváme na to, jak s tím zacházet v souvislosti s Yubico.        

Komentáře

[Michal Kubeček]

Ty role klíčů jsou čtyři:

• C (certify) - podepisování klíčů (vlastních nebo cizích)
• S (sign) - podepisování souborů, dokumentů, mailů …
• E (encrypt) - šifrování souborů, dokumentů, mailů, …
• A (authenticate) - autentizace, např. při použití s ssh

Defaultně gpg vyrobí master [SC] a subkey [E], ale lze to kombinovat i jinak, např. mít jeden master klíč pro všechny čtyři (to se moc nedoporučuje) nebo naopak čtyři různé (master [C], subkeys [S], [E] a [A]). Je možné i mít víc klíčů se stejnou rolí, např.

mike@lion:~> gpg --list-keys --list-options show-unusable-subkeys 329DD07E
pub   rsa4096 2011-11-07 [SC]
      DE0E66E32F1FDD0902666B96E63EDCA9329DD07E
uid           [  full  ] Konstantin Ryabitsev <konstantin@linuxfoundation.org>
uid           [  full  ] Konstantin Ryabitsev <mricon@kernel.org>
uid           [  full  ] Konstantin Ryabitsev (Fedora) <icon@fedoraproject.org>
uid           [  full  ] [jpeg image of size 2774]
uid           [ unknown] Konstantin Ryabitsev <icon@mricon.com>
uid           [ unknown] Konstantin Ryabitsev <hbic@paranoidbeavers.ca>
sub   rsa4096 2011-11-07 [E] [revoked: 2012-01-27]
sub   rsa3072 2012-01-26 [S] [revoked: 2014-06-03]
sub   rsa2048 2012-01-26 [E] [revoked: 2014-06-03]
sub   rsa2048 2014-06-03 [A] [revoked: 2018-05-02]
sub   rsa2048 2014-06-03 [S] [expired: 2015-11-03]
sub   rsa4096 2015-11-02 [S] [expired: 2018-05-09]
sub   rsa4096 2015-11-02 [A]
sub   ed25519 2018-02-09 [S]
sub   cv25519 2018-05-02 [E]
sub   rsa2048 2018-05-02 [A]
sub   rsa2048 2012-01-26 [A] [expired: 2015-11-03]
sub   rsa2048 2014-06-03 [E] [expired: 2015-11-03]
sub   rsa4096 2015-11-02 [E] [expired: 2018-05-09]

Jediné, čím si nejsem jistý, jestli vůbec lze, je mít [C] u subkey. Tahle role je nejdůležitější, je potřeba ke kritickým operacím jako podepsání klíče nebo identity, přidání nebo revokace identity, změna expirace atd. Proto se doporučuje master key (tedy tajný klíč od něj) vůbec nemít na běžně používaném počítači, ale typicky na nějakém dobře chráněném vyměnitelném médiu se šifrovaným filesystémem.

Dobrý popis je např. tady nebo tady.

[Michal Kubeček]

Vidíme, že se použila první identita. Ale nevím, jestli se použil master key nebo subkey. Po pravdě, nevím, co znamená ten šílený výraz 5ABA0105F9EEDE9BD0021DC08F2D5825D5689DE1.

Je to hash (SHA-1) toho klíče (někde v dokumentaci by se dalo najít, z čeho přesně se počítá). Podle toho, jak moc unikátní identifikátor chcete, se používá buď celý hash, posledních šestnáct číslic nebo posledních osm číslic, tj.

  D2CB120AB45957B721CD9596F4554567B91DE934
                          F4554567B91DE934
                                  B91DE934

identifikují stejný klíč.

Fingerprinty všech klíčů (včetně subkeys) si můžete zobrazit např. takhle:

mike@lion:~> gpg --list-keys --with-subkey-fingerprint B91DE934
pub   rsa4096 2020-05-14 [C]
      D2CB120AB45957B721CD9596F4554567B91DE934
uid           [ultimate] Michal Kubecek <mkubecek@suse.cz>
uid           [ultimate] Michal Kubecek <mkubecek@suse.com>
uid           [ultimate] Michal Kubecek <mike@mk-sys.cz>
uid           [ultimate] Michal Kubecek <mkubecek@suse.de>
sub   rsa2048 2020-05-14 [S]
      58DDE3DDB89E566A76EA628EE77F2C1BF2D17695
sub   rsa2048 2020-05-14 [E]
      13B2B514E8EDD8702D4A9DEB094C2AAB78F838CB
sub   rsa2048 2020-05-14 [A]
      44392E315CF737665DBF98AA0FB671160C864DA3

Ve vašem případě jde určitě o subkey, protože master by byl "153130ED26CA404C8B29795B4703A5B671B96E4D".

[Michal Kubeček]

Ještě jedna poznámka k podepisování souboru: v praxi se spíš než "-s" (--sign) používá volba "-b" (--detach-sign), která nechá podepisovaný soubor jak je a vytvoří samostatný soubor s podpisem. Většinou se navíc přidává volba "-a" ("--armor"), aby byl soubor s podpisem textový.

[Bherzet]

Super blog a dodatky v diskuzi. Díky.

[Bystroushaak]

Lehce offtopic:

Což má za následek, že když někdo podepíše cizí veřejný klíč, může někoho uvést v omyl, že tento klíč patří někomu jinému, než kdo ho vydal. (https://nullprogram.com/blog/2019/07/10/, článek datovaný July 10, 2019). V diskusi ke článku uživatel zaarn nebral servítky a na adresu GPG doslova napsal (ač nedoplněno emotikony, každý v tom jistě cítí sarkasmus):

Man, where would we be without the people that defend GPG? Possibly in a world with easy-to-use mail cryptography solutions but who wants that?

Já jsem si poslední dobou několikrát všiml, že je v módě kopat do GPG / PGP, jako že je to moc složité a nahovno. Přijde mi, že je to poslední dobou nějaký hipster hnutí, akorát když se v těch diskuzích zeptáš čím to teda nahradit, tak vytáhnou nějakou blbost, která často ani není asymetrická a začnou ti jí cpát s naprosto očividným nepochopením k čemu se asymetrická kryptografie běžně používá.

Zase to samé z toho na nullprogramu:

Why only a signing key? Nobody should be using OpenPGP for encryption anymore. Use better tools instead and retire the 20th century cryptography. If you don’t have an encryption subkey, nobody can send you OpenPGP-encrypted messages.

Jasně, určitě, ale co? Tam dává odkaz, který se odkazuje na What’s the matter with PGP?, což taky nedává žádné odpovědi.

Asi jediné, co jsem viděl že by mohlo nahradit část funkcionality gpg je signify.

BTW: Spoustu těch odkazů máš blbě, protože ti tam vlezly nějaké uvozovky.

[Michal Kubeček]

Jestli to dobře chápu, tak kromě jsou tam v podstatě tři výhrady:

1. web of trust
2. absence PFS
3. staré/slabé algoritmy

1. To je opravdu problém, pokud chceme podepisování a šifrování komunikace i mimo komunitu technických nadšenců. Prostý uživatel nechce věcem rozumět a už vůbec o nich nechce přemýšlet. Koncept web of trust ale tohle po uživateli vyžaduje. Je to vidět i z těch rantů - těm lidem je cizí představa, že by měli rozlišovat mezi "mám něčí veřejný klíč" a "mám jeho dodstatečně ověřený veřejný klíč" a chovat se podle toho. Proto se v komerčních produktech prosadila spíš řešení založená na konceptu PKI (S/MIME pro e-mail), a to ještě implementovaná tak, aby si uživatel nemusel (a někdy ani nemohl) dělat management certifikátů sám. Tam není potřeba přemýšlet, prostě mám certifikáty podepsané autoritami a kterým autoritám mám věřit, to mi řekne Microsoft, Google nebo Mozilla Foundation. Ono už to slovo "autorita" vzbuzuje důvěru, jen nebezpeční anarchisti přece nevěří autoritám. :-)

2. Tohle je asi jediný problém, se kterým se dá souhlasit, ale autor sám přiznává, že u e-mailu to už z principu jde řešit jen částečně.

3. Tohle je zcela obecný problém, nijak specifický pro openpgp. Jedno možné "řešení" je udělat to jako wireguard, tj. zafixovat konkrétní "bezpečnou" sadu algoritmů a parametrů a když (nebo spíš "až") se ukáže, že už nestačí, tak se přejde na novou, zpětně nekompatibilní verzi protokolu. Kde je problém tohoto řešení, to asi nemusím dlouze vysvětlovat. Stačí se podívat po diskusích, jak se pokaždé, když v openssl nebo openssh odstraní podpora nějakého zastaralého algoritmu nebo kombinace, začnou admini chytat za hlavu: "Ale to mi nebude fungovat s (nějaká roky neaktualizovatelná krabička)."

[Michal Kubeček]

Bod 1 asi nejlépe ilustruje tenhle komentář z tamní diskuse:

Believe me, I know about X.509, and I have spent far too long staring at the output of `openssl x509 -text -noout`. It's still better than PGP, because the web PKI model makes sense to people who aren't cryptogeeks (“I trust Verisign, and Verisign verifies me, and Firefox trusts Verisign to verify me”), and the tools are usable by people who aren't cryptogeeks.

You never even have to understand X.509 or PKI to get a HTTPS web server up and running which provides reasonable security guarantees. Every CA will tell you exactly how to generate a reasonable cert and how to install it in your web server of choice.

Pro lidi, kteří uvažují takhle (a obávám se, že jich je většina), openpgp opravdu není.

[kralyk z abclinuxu]

Pro lidi, kteří uvažují takhle (a obávám se, že jich je většina), openpgp opravdu není.

No jo, ale co tedy navrhuješ? Aby lidi přestali být blbci?

Já se přiznám bez mučení, že PGP a GPG taky moc nerozumim a děsí mě představa, že to budu muset začít řešit (což asi budu muset), zabřednout do toho celého bordelu popsaného v blogu, v diskusi a jinde a strávit tim kdovíkolik hodin času jenom proto, abych získal jakous takous podprůměrnou schopnost s tou věcí pracovat...

Jo a pak ve výsledku stejně narazim na nějakej absurdně hloupej problém, jakože např. pgp.mit.edu je směšně poddimenzovaný server, který 98% požadavků dropne a submitnout klíč se tam prakticky nedá...

[Michal Kubeček]

No jo, ale co tedy navrhuješ? Aby lidi přestali být blbci?

Ještě to tak, přijít o konkurenční výhodu. :-)

Ale teď vážně: samozřejmě si nemyslím, že openpgp je model rozumně použitelný pro široké masy nepoučených (a nepoučitelných) uživatelů. Jen zásadně nesouhlasím s tvrzením, že to znamená, že je celý ten model špatně navržený. V rámci komunity dostatečně fundovaných uživatelů (a zase až tak hluboké znalosti k tomu potřeba nejsou) funguje naopak mnohem lépe než ten PKI model preferovaný širokou veřejností. Když zjistím, že se závodní speciál nehodí k ježdění po polních cestách nebo popojíždění v kolonách na magistrále, tak z toho taky nevyvodím, že je k ničemu.

[kralyk z abclinuxu]

Mně to trochu připomíná git, akorát z druhý strany. git mam v oblibě a troufnu si tvrdit, že s nim celkem umim (i když znám lidi, kteří mu rozumí ještě mnohem víc do hloubky). A to CLI mi přijde celkem fajn, až na nějaké drobnosti. Nepoužívám žádný gui kromě vestavěných GUI utilit. Ale vim o spoustě (inteligentních) lidí, kterým to CLI přijde zmatený, nemaj to rádi, nevyznaj se v tom. Pro mě jsou jejich problémy těžko pochopitelný, nicméně když tu situaci srovnám s něčím jako je gpg, tak to začínám chápat...

[Michal Kubeček]

Ano, to je, myslím, velice dobrý příklad. Git má taky svou filosofii a model, který když pochopíte a akceptujete, tak je to všechno (no, většina) logické a dává to dobrý smysl. Pokud k tomu ale někdo přistupuje tak, že ho žádná filosofie a vnitřní logika nezajímá, je dost pravděpodobné, že mu spousta věcí dávat smysl nebude a bude se s tím prát. A pokud k tomu bude přistupovat s tím, že je to navržené od základu špatně, je to téměř jisté.

[kralyk z abclinuxu]

Pokud k tomu ale někdo přistupuje tak, že ho žádná filosofie a vnitřní logika nezajímá, je dost pravděpodobné, že mu spousta věcí dávat smysl nebude a bude se s tím prát. A pokud k tomu bude přistupovat s tím, že je to navržené od základu špatně, je to téměř jisté.

No jo, nicméně to, že ty (nebo já, to je jedno) jsi tu vnitřní filosofii vstřebal, neznamená, že je skutečně dobrá a dobře pochopitelná pro ostatní lidi. Já sice aktuálně neznám lepší nástroj než git na VCS, ale nejsem úplně přesvědčen, že filosofie gitu je a) skutečně dobrá a b) dobře uchopitelná pro "kohokoli", i když "kohokoli" zúžím na lidi jako jsou programátoři, admini, linux nerdi apod.

Třeba v darcsu nebo Pijulu si myslí, že filosofie gitu je špatná:

What’s wrong with existing, widely-used, mature solutions?

Some things are really wrong, like using three-way merge for version control in general: there are examples (even real-world ones) where Git, Mercurial and SVN just do the wrong thing. See this article for more details.

Less objectively, our experience with patch-based tools make us believe that this is possibly the simplest way to control versions.

Případně, méně vážně, viz xkcd ...

Umim si představit, že s gpg to může být podobné, případně horší než s gitem (gpg asi zná míň lidí).

[Josef Kufner]

[...] See this article for more details.

Ten příklad je prostě jen nejednoznačný a různé nástroje ho vyřeší různě. Ani jedna varianta není špatně.

[kralyk z abclinuxu]

Nemyslim si. Mrkni se i na tu verzi s C kódem. Tam je vidět, že ta verze vyprodukovaná SVN je prostě špatně, funkce square() tam vrací vždy nulu (protože VCS aplikoval změnu c1 na špatnou funkci).

[Josef Kufner]

To sice je, ale z pohledu struktury kódu je ten three-way merge správně. Ta změna C říká, že ve funkci square bude na začátku y = 0. Když by kód té funkce vypadal trochu jinak, tak by byla špatně darcs verze. Merge prostě nemůže vědět, jestli se ten kus kódu opravdu přesunul, nebo jen na chvíli zmizel (např. revertnutý commit). Three-way merge je alespoň předvídatelnější.

[kralyk z abclinuxu]

Ta změna C říká, že ve funkci square bude na začátku y = 0.

To ale programátor píšící změnu C zřejmě nechtěl... Resp. chtěl by, aby ta změna se s přesunem a přejmenováním te funkce také přesunula.

Když by kód té funkce vypadal trochu jinak, tak by byla špatně darcs verze.

Ano, ten příklad tam taky je popsanej, ale je oproti tomu příkladu, kdy git to má špatně, je příšerně vykonstruovaný a nereálně vypadající, musí se tam v podstatě "správným" způsobem náhodou potkat dva různé bugfixy, aby to git měl ve výsledku správně.

Merge prostě nemůže vědět, jestli se ten kus kódu opravdu přesunul, nebo jen na chvíli zmizel (např. revertnutý commit).

Ano, merge to vědět nemůže, ale VCS založené na patch theory tohle právě vědí.

Tohle je přesně ten problém, o kterým mluvim a proč jsem git zmínil: Lidi, kteří do $technologie investovali čas, rozumí jí a jsou na ni zvyklí, mají tendenci automaticky předpokládat, že ta filosofie té věci je správná a že ten, kdo ji kritizuje, to nejspíš dělát protože jí nedostatečně rozumí.

[xxx]

No muzete tady jeste chvili mavat umelymi priklady ale realite je takova, ze tricestnej merge, kdyz se potka v jednom souboru, nebo dokonce v jedne funkci, je vzdycky o pruser. Bez porozumneni zmenam z obou vetvi stejne nejde udelat.

[Michal Kubeček]

Realita… je taková, že žádný algoritmus pro merge vám nezaručí, že za kterýchkoli okolností vyprodukuje správný výsledek nebo aspoň zahlásí konflikt, který je potřeba vyřešit ručně. (Tedy kromě triviálního, který zahlásí neřešitelný konflikt pokaždé.) Zkuste si představit něco tak jednoduchého (a naprosto realistického) jako třeba větev A o jednom patchi, který přidá funkci další parametr (a upraví všechna volání), a větev B o jednom patchi, který přidá nové volání té funkce do souboru, kde předtím žádné nebylo. A to ještě budete mít štěstí, že na to přijdete hned při překladu; pokud by se té funkci jen změnilo chování nebo třeba interpretace parametru nebo návratové hodnoty, může z toho vzniknout bug, který se projeví jen za specifických okolností.

To ale samozřejmě nebrání autorům VCS provozovat podobné soutěže "kdo vejš", konstruovat příklady, které ten jejich vyřeší dobře a konkurenční ne, a dohadovat se, čí příklad je více nebo méně umělý.

[kralyk z abclinuxu]

Není tohle prostě akorát klasický argument "nejde to vyřšit dokonale, tudíž by nikdo neměl zkoušet to vyřešit lépe"?

[Michal Kubeček]

Proto jsem přidal i ten druhý odstavec, kde jsem napsal, co si myslím o tom "lépe".

Ze své zkušenosti ani z ohlasů ve svém okolí nemám pocit, že by úspěšnost a spolehlivost merge algoritmu gitu byla tím, co by vývojáře nějak zásadně trápilo. S problémy toho typu, že backport nefunguje správně kvůli tomu, že se mezi místem, odkud se backportuje, a místem, kam se backportuje, něco změnilo, se setkávám častěji. (To je samozřejmě cherry pick a ne merge, ale problém je stejný.)

[kralyk z abclinuxu]

Ale ono to není jenom o merge algoritmu, ale o tom, že celá ta filosofie jiná, a v důsledku toho i workflow, například ty nástroje nemusí obsahovat rebase command (není tam ta dichotomie mezi merge a rebase) atd.

Aby bylo jasno: Já s těma nástrojema jako darcs nebo Pijul nemam zkušenost na netriviálním projektu (zkoušel jsem to jen trochu, nemam na to moc času) a nevim, jestli jsou reálně lepší nebo ne a ani mi v tomhle threadu o to nejde, v tom není ta pointa. Ta pointa je v tom ukázat ten efekt, kdy lidi, kteří jsou roky investovaní v $technologii automaticky považují tu technologii za dobrou, mají bias proti její kritice a proti alternativám a alternativy automaticky považují za přinejlepším nepodstatně lepší nebo rovnou horší. A reakce tvoje a dalších to zcela potvrzuje.

Nebo ti křivdim a máš za sebou zevrubnou evaluaci darcs a reálně víš, že skutečně ta filosofie gitu je lepší?

Přijde mi, že to je podobný pattern jako v naší diskusi o Rustu. (Akorát s tim rozdílem, že tam tu alternativní technologii znám a vim, že má netriviální benefity.)

Přitom vim z vlastní zkušenosti, že to UI gitu při mergování/rebasingu/řešení konfliktů není zrovna dvkrát skvělý / intuitivní. Např. ta terminologie "ours" a "theirs" mi přijde dost nicneříkající. Případně že si člověk musí nastavit diff3 conflictstyle, aby při konfliktu viděl "base", atd., což z nějakého nepochopitelného důvodu není default a nově příchozí má malou šanci se o tom dozvědět...

[xxx]

Pokud chces ukazat, ze filosofie darcsu je lepsi, pak by jsi to mel ukazat na nejakem relevantnim prikladu. Coz to co jsi odkazal rozhodne neni.

Reseni square() v b2 a c1 je zcela odlisne (jedno je fix, druhe je prepsani), a pokud se je nejaky nastroj snazi spojit (coz cini oba), pak je to chyba. Pokud by mel byt jeden z tech nastroju lepsi, pak by mel v takovem pripade chybu oznamit. To, ze v nejakych pripadech dopadne pro darcs lepe, je sice hezke, ale je to reseni problemu na nespravnem miste.

Nicmene chybou neohlasi ani jeden, a je ji treba resit o level vyse. Pricmez git toho na reseni o "level vyse" nechava opravdu hodne. Darcs bude v definovani workflow mnohem omezenejsi. Ktery z pristupu je lepsi, to nevim.

[kralyk z abclinuxu]

Pokud chces ukazat, ze filosofie darcsu je lepsi

Nechci.

pak by jsi to mel ukazat na nejakem relevantnim prikladu. Coz to co jsi odkazal rozhodne neni.

Ten příklad IMO celkem jasně ukazuje určitou převahu darcsu a souhlasim s autorem tý stránky, že ten protipříklad, kdy v gitu to dopadne lépe, na tom nic nemění, vzhledem k tomu, jak uměle je zkonstruovaný a jak příšerně ten kód v něm vypadá (oproti tomu ten pro-darcs příklad je celkem normální kód). Stejnětak si nemyslim, že by na tom cokoli měnil Kubečkovo příklad, ve kterém dopadnou špatně oba.

Jestli celkově - nejen co se týče mergingu - je filosofie darcsu/Pijulu lepší, to je mnohem širší otázka a odpověď neznám. To bych musel darcs nebo Pijul aktivně používat na netriviálním projektu, ideálně souběžně s gitem.

Jak už jsem napsal v pdůvodním příspěvku, neznám aktuálně vhodnější software na VCS než git. Co ale nechci je povýšit neznalost jiných přístupů k VCS na tvrzení, že filosofie gitu je nejlepší (kde ta neznalost být může způsobená mj. i tím, že ten lepší přístup třeba ještě nikdo nevymyslel/nenaimplementoval).

[kralyk z abclinuxu]

Jestli celkově - nejen co se týče mergingu - je filosofie darcsu/Pijulu lepší, to je mnohem širší otázka a odpověď neznám. To bych musel darcs nebo Pijul aktivně používat na netriviálním projektu, ideálně souběžně s gitem.

Konkrétně např. darcs nemá branche a místo toho zřejmě se tam dělají klony do různých adresářů. Jestli to je dobrý/špatný přístup, to fakt nevim. (Default u člověka zvyklýho na git je říct, že to je špatně, ale nevyzkoušel jsem si to, takže těžko říct.) Je pravda, že v gitu u větších projektů používám workdirs, což bych asi v případě darcsu nemusel řešit a měl bych to tak rovnou. Pijul branche má, ale nevim, jak přesně fungují / jakou mají sémantiku...

[xxx]

O proti-prikladu se vubec nebvaim. Ale to, ze v nejakem trivialnim prikladu ma darcs kliku (ackoliv teda autor tvrdi, ze to neni klika), za ukazku prevahy nepovazuju.

Kdyby squre() v b2 vypadal (return y - x):

int square(int x) {
	int y = x;
	/* Update y to equal the result. */
	/* Question: what is the order of magnitude of this algorithm with respect to x? */
	for (int i = 0; i < x; i++) y += x;
	return y - x;
}

tak jsou v haji oba.

[kralyk z abclinuxu]

Nerozumim, jakým způsobem příklad, ve kterém selžou oba, rozporuje tu převahu darcsu.

[Michal Kubeček]

Migrovat cokoli na jiný VCS je moc komplikovaná věc na to, aby se to dělalo jen proto, že je ten nový nástroj v něčem o chloupek lepší - což tady navíc není ani zdaleka jisté, protože tady máte v ruce jeden vykonstruovaný testcase a tvrzení (z ne zrovna nezaujatého zdroje), že neexistuje realistický testcase, kde by to bylo naopak. A to se pořád bavíme jen o zlomku toho, co git nabízí. Půjde v tom darcsu stejně efektivně pracovat s desítkami nebo stovkami větví a tagů? Co jsem se díval na ten model, tak to vypadá, že větve ani tagy nejsou v tomhle modelu ani zdaleka tak "levné" a praktické jako v gitu.

Nový nástroj musí být výrazně lepší než stávající široce rozšířený, aby to vývojáře přimělo na něj přejít. Často dokonce ani to nestačí a je navíc potřeba určitá míra nespokojenosti s tím stávajícím. Je mi líto, ale tady nevidím ani jedno. On i takový přechod ze subversion na git u některých projektů trval dost dlouho, přestože byly výhody gitu očividné a nevýhody bylo potřeba hledat opravdu pečlivě. A třeba migrací projektů mezi gitem a mercurialem je minimum, protože tam v podstatě jediná opravdu výrazná výhoda je "používají (a znají) to skoro všichni" (ve prospěch gitu).

Může vám to připadat nespravedlivé, ale podle mne je to dobře. Čas vývojářů je totiž omezený zdroj a když se ho moc spotřebuje na neustálé sledování a vyhodnocování nových cool nástrojů a migrování mezi nimi, hrozilo by, že nebudou mít čas na projekt samotný.

Také bych rád upozornil, že jsem nemluvil o potřebě filosofii gitu milovat nebo ji považovat za skvělou, nejlepší nebo dokonce jedinou dobrou. Mluvil jsem jen o potřebě ji chápat a rozumět jí - a o tom, že apriorní přístup "je to celé úplně blbě navržené" vede logicky ke špatným výsledkům. To je hodně podstatný rozdíl.

A konečně: tahle větev diskuse se rozvinula v něco, co je ještě více off-topic než ta větev, se kterou jsem se rozhodl skončit včera, takže se pokusím dále nepokračovat i v ní.

[kralyk z abclinuxu]

Migrovat cokoli na jiný VCS je moc komplikovaná věc na to, aby se to dělalo jen proto, že je ten nový nástroj v něčem o chloupek lepší

Ano, však taky používám víceméně spokojeně git, migrovat se necyhstám a ani jsem k tomu nikoho nenabádal

Může vám to připadat nespravedlivé, ale podle mne je to dobře. Čas vývojářů je totiž omezený zdroj a když se ho moc spotřebuje na neustálé sledování a vyhodnocování nových cool nástrojů a migrování mezi nimi, hrozilo by, že nebudou mít čas na projekt samotný

Přímo v komentáři, na který reaguješ, píšu tohle:

Aby bylo jasno: Já s těma nástrojema jako darcs nebo Pijul nemam zkušenost na netriviálním projektu (zkoušel jsem to jen trochu, nemam na to moc času)

Nevim, co k tomu víc říct...

Také bych rád upozornil, že jsem nemluvil o potřebě filosofii gitu milovat nebo ji považovat za skvělou, nejlepší nebo dokonce jedinou dobrou. Mluvil jsem jen o potřebě ji chápat a rozumět jí - a o tom, že apriorní přístup "je to celé úplně blbě navržené" vede logicky ke špatným výsledkům. To je hodně podstatný rozdíl.

To je těžký. Na jednu stranu máš pravdu v tom, že jsou lidi, který prostě řeknou "je to celý úplně blbě" a aniž by se zajímali to smetou ze stolu. To souhlasim, že je špatně. Na druhou stranu když nemalé množství lidí včetně lidí inteligentních a pracovitých má s nějakou technologií problém a/nebo ta technologie způsobuje nemalé problémy, tak se nedá tak úplně vyloučit, že na ní opravdu je něco špatně, a to třeba i dost podstatně. Je to příliš heretická / neakceptovatelná / děsivá myšlenka? Asi ano.

[kralyk z abclinuxu]

Sakra, zapomněl jsem na povinný disclaimer: Nechci tím říct, že by měli všichni přejít na $novou_technologii a za rok znova. To fakt ne. Jen to, že když někdo řekne, že $tradiční_technologie je špatná a snaží se hledat nové cesty, tak to nemusí vždy znamenat, že je ten člověk úplnej blbec...

[Michal Kubeček]

Stejně jako u openpgp, ani o gitu si nemyslím, že by to bylo nejlepší řešení pro všechny. Koneckonců je pořád dost projektů, které spokojeně používají třeba subversion. Nebo aspoň ne dost nespokojeně, aby je to motivovalo ke změně. :-)

Mně prostě ze všech těch výkřiků, jak je openpgp (gpg) špatně navržené, čiší logika "když to nevyhovuje mně pro můj use case, tak je to prostě blbost". Ale to je logika, kterou považuju za zvrácenou. Ony ty nástroje, které se snaží být (jakž takž) použitelné na cokoli, často končí tak, že se opravdu dobře nehodí na nic.

[Gilhad]

Ono je zase na druhou stranu potreba poznamenat, ze git byl vymyslen a vyvijen nikoli pro "kohokoli", ale konkretne Linusem pro Linuse a konkretni bandu lidi okolo nej a to za ucelem vyvoje linuxoveho kernelu.

A zjevne tomuto ucelu slouzi dost dobre, takze v ramci jeho zadani je jeho filosofie dobra (ci aspon lepsi nez cehokoli jineho dostupneho) a dostatecne uchopitelna pro cilovou skupinu.

Ze se nahodou hodi i na spoustu jinych veci, a pouziva ho i spousta jinych lidi, je tak trochu jen prijemny vedlejsi efekt. (Podobne jako zniceni Windows

[deda.jabko]

Git má taky svou filosofii a model, který když pochopíte a akceptujete, tak je to všechno (no, většina) logické a dává to dobrý smysl.

Neni to jen o znalosti te filozofie. Kdyz si vybavim uplne prvni verze gitu, bylo to na ovladani opravdu hodne neprijemne.

[j]

"PKI model preferovaný širokou veřejností"

Ehm ... lol ... siroky verejnosti ne nejaky PKI uplne urite. Jim vadi, kdyz jim v browseru vyskakujou sileny hlasky o tom, jak je web se selsign klicem s DANE strasne nebezpecnej.

A nemuze za to ta verejnost, muzou za to dementni tvurci!

---

Dete s tim guuglem dopice!

[Filip Jirsák]

Prostý uživatel nechce věcem rozumět a už vůbec o nich nechce přemýšlet.

Ono nejde ani tak o to,jestli o tom chce nebo nechce přemýšlet prostý uživatel. Ono jde především o to, jestli vy chcete, aby o tom ten uživatel přemýšlel. Asi byste nechtěl, abyste jeden měsíc poslal hlášení k DPH podepsané PGP a úředník by vám to bez problémů přijal, protože vašemu klíči věří, a za měsíc byste poslal další hlášení podepsané tímtéž klíčem, ale jako odpověď by vám přišla pokuta, že jste hlášení nepodal – protože to přijal jiný úředník, který vašemu klíči nevěří.

Nebo byste se hlásil na vysokou školu, ale nevzali by vás, protože referentka na studijním oddělení nevěří PGP klíči ředitele vašeho gymnázia, který podepsal vaše maturitní vysvědčení.

Zkrátka to, že se nad ověřováním klíčů nepřemýšlí, ale používá se předvídatelný a reprodukovatelný formální postup, má své dobré důvody, a umožňuje PKI fungovat mimo komunitu – tedy i ve společnosti, která je tak velká, že se její členové ani zprostředkovaně neznají.

PGP je použitelné mimo komunitu technických nadšenců, ale není použitelné mimo komunitu (jakoukoli).

Výhodou PGP naopak je to, že je tam mnohem víc vidět to, že jde pořád jen o klíče, a mnohem víc se pracuje s těmi klíči – a teprve k nim je nějak navěšená důvěra. Kvůli té fixaci PKI na certifikáty pak máme pořád takový nesmysl, jako jsou DV certifikáty, kdy se certifikační autority zaručují za doménové jméno, za které se ale nijak zaručit nemohou. Přitom důležité je jenom to, že nějaký klíč patří k dané doméně – a to dnes může být bezpečně uložené v DNS.

[Michal Kubeček]

Ono nejde ani tak o to,jestli o tom chce nebo nechce přemýšlet prostý uživatel. Ono jde především o to, jestli vy chcete, aby o tom ten uživatel přemýšlel. Asi byste nechtěl, abyste jeden měsíc poslal hlášení k DPH podepsané PGP a úředník by vám to bez problémů přijal, protože vašemu klíči věří, a za měsíc byste poslal další hlášení podepsané tímtéž klíčem, ale jako odpověď by vám přišla pokuta, že jste hlášení nepodal – protože to přijal jiný úředník, který vašemu klíči nevěří.

To není moc dobrý příklad, protože přestože státní správa sice používá PKI infrastrukturu, ale používá ji způsobem, který je vlastně implementací web of trust: pro oficiální komunikaci se státní správou je totiž potřeba mít certifikát přímo podepsaný jednou z poměrně malého počtu autorit, kterým stát věří. A to je něco, co by šlo stejně (ne)snadno implementovat i nad openpgp.

To, co jsem zpochybňoval, je způsob, jakým se PKI běžně používá ve webových prohlížečích a pravděpodobně i mainstreamových MUA: vendor mi software (nebo rovnou OS) dodá s docela dlouhým seznamem "důvěryhodných" autorit, do kterého by se klidně vešel i Honest Achmed, kdyby byl jen o chloupek méně upřímný. Ale uživatel vidí zelený zámeček, přečetl si, že zámeček je dobře, tak je happy.

Celý problém je podle mne v tom, že těch situací, kdy požadavky bezpečnosti a pohodlí nejsou protichůdné, je poměrně málo. A je chyba předstírat, že to tak není.

[Filip Jirsák]

Nejde jen o komunikaci se státní správou – kvalifikované podpisy mají stejnou platnost jako vlastnoruční podpisy v rámci celé jurisdikce EU. Nejde tedy o to, že by se stát rozhodl, komu důvěřuje – ale on nařídil i vám, že těm autoritám musíte důvěřovat. Těch autorit jsou v rámci EU desítky, nevím, jestli bych to nazýval „poměrně malý počet“. Navíc jsou tam jasně daná pravidla, když je splní další autorita, seznam autorit se rozšíří. Pořád je to tedy tak, že to nezávisí na něčí libovůli, ale jsou daná jasná pravidla, chová se to předvídatelně.

S prohlížeči je to podobné – lidstvo je už příliš velké na to, aby mohlo fungovat jako komunita. Abyste každý web znal přes nejvýš přes jednoho nebo dva lidi. Pravděpodobně by tam platilo pravidlo sedmi kroků, a přenášet důvěru přes sedm lidí nejde.

Nemyslím si, že bezpečnost a pohodlí jsou tak často v protikladu – ve spoustě případů je to jen lenost vymyslet to řešení pořádně. A bezpečnost v žádném případě neznamená, že si všechno budu dělat sám – zrovna ta delegace ověřování identity na certifikační autority v drtivé většině případů bezpečnost zvyšuje.

[Michal Kubeček]

To je všechno hezké, ale pořád to není nijak v rozporu s mým tvrzením, že (1) fungování kvalifikovaných certifikátů (nebo jak přesně to právníci nazvali) je hodně odlišné od toho, jak se PKI běžně používá v prohlížečích a MUA a (2) to, že se openpgp model nehodí pro široké masy, ani zdaleka neznamená, že je špatně navržený; prostě je jen navržený pro jiné účely a jiné prostředí, kde funguje naopak výrazně lépe.

Nemyslím si, že bezpečnost a pohodlí jsou tak často v protikladu – ve spoustě případů je to jen lenost vymyslet to řešení pořádně.

Obávám se, že takdy se prostě neshodneme, protože zrovna ten příklad, který jste sám vybral, to ilustruje dost názorně: srovnejte si třeba, jak náročné je získat kvalifikovaný certifikát ve smyslu zákona a jak náročné je získat ho třeba u Let's encrypt nebo některé jiné "pohodlné" autority. A doufám, že mi nebudete tvrdit, že je důvěryhodnost takových certifikátů na stejné úrovni nebo že snad na tom ty druhé budou lépe.

Samozřejmě se najdou i případy, kdy je jedno řešení bezpečnější i pohodlnější než druhé; příkladem může být třeba autentizace pomocí klíčů místo hesel u ssh. Ale moc časté to rozhodně není.

zrovna ta delegace ověřování identity na certifikační autority v drtivé většině případů bezpečnost zvyšuje

Tato věta je obsahově prázdná, pokud neřeknete, oproti čemu ji má zvyšovat. Oproti tomu, když se identita nebude ověřovat vůbec, rozhodně ano, ale to není moc vysoko nastavená laťka. Oproti web of trust modelu provozovanému dostatečně informovanými a zodpovědnými uživateli… ani náhodou.

[Josef Kufner]

Ale oproti web of trust modelu provozovanému běznými uživateli …

[Michal Kubeček]

Myslel jsem, že tu panuje shoda, že "běžný uživatel" to provozovat nechce a nebude. :-)

[Josef Kufner]

A to je právě ukázka toho, že to je opravdu špatně udělané. Například HTTPS používá každý a většina uživatelů tak nějak chápe/tuší, že když tam je zámeček, že to je nějak zabezpečené a asi je vše v pořádku i když neví proč.

Teoreticky je sice Web of Trust bezpečnější a v mnoha ohledech lepší, ale k čemu to je, když to skoro nikdo nepoužívá? Reálně se pomocí GPG jen podepisují balíčky a různá vydání softwaru (tagy, repozitáře a tak). Web of Trust se ale nepoužívá a klíče se prostě při prvním použití nakopírují bez zabezpečení.

Aby GPG bylo použitelné, tak by prostě muselo fungovat stejně, jako třeba HTTPS. Někde v GUI by byl zelený zámeček a implicitní mechanismy (např. TOFU) by poskytly nějaké rozumné zabezpečení pro každodenní použití s tím, že by bylo možné nějaké další ověření, pokud je k tomu důvod. Třeba "Like" na Facebooku by mohl zahrnovat podepsání klíče, pokud už se dané entity znají (např. provedeným nákupem v e-shopu). Nebo třeba při předání kontaktu pomocí NFC (kdyby to opravdu fungovalo). Ale ty nástroje by musely být opravdu jednoduché a přirozené, aby jejich použití bylo velmi snadné a probíhalo třeba i na pozadí bez zásahů uživatele.

[Filip Jirsák]

Teoreticky je sice Web of Trust bezpečnější

Vycházíte z předpokladu, že nejbezpečnější je to, co si člověk udělá sám. Ten předpoklad je ovšem mylný.

Aby GPG bylo použitelné, tak by prostě muselo fungovat stejně, jako třeba HTTPS. Někde v GUI by byl zelený zámeček a implicitní mechanismy (např. TOFU) by poskytly nějaké rozumné zabezpečení pro každodenní použití s tím, že by bylo možné nějaké další ověření, pokud je k tomu důvod. Třeba "Like" na Facebooku by mohl zahrnovat podepsání klíče, pokud už se dané entity znají (např. provedeným nákupem v e-shopu). Nebo třeba při předání kontaktu pomocí NFC (kdyby to opravdu fungovalo). Ale ty nástroje by musely být opravdu jednoduché a přirozené, aby jejich použití bylo velmi snadné a probíhalo třeba i na pozadí bez zásahů uživatele.

Tohle by sice bylo dotažení toho, jak se dnes web of trust používá, ale zároveň by to bylo ještě další oslabení bezpečnosti. Už dneska je ověření identity při podepisování v rámci web of trust žádné nebo velmi slabé (slabší než u běžných PKI autorit a podstatně slabší, než u těch opravdu důvěryhodných, např. akreditovaných). Takže je zřejmé, že u toho tvrzení „teoreticky je web of trust bezpečnější“ v té teorii něco podstatného chybí.

[Josef Kufner]

Teoreticky je sice Web of Trust bezpečnější

Vycházíte z předpokladu, že nejbezpečnější je to, co si člověk udělá sám. Ten předpoklad je ovšem mylný.

Citation needed.

Pokud bude Web of Trust o nulové velikosti, tak degraduje na prosté TOFU, což je sice na první připojení horší než certifikační autority, ale na každé dalsí spojení mnohem bezpečnější.

Web of Trust si vynucuje ověřování a řešení důvěryhodnosti. Oproti tomu certifikační autority jsou za důvěryhodné považovány všechny, takže se důvěryhodnost konkrétního klíče/certifikátu neřeší a kdokoliv mi může kdykoliv cokoliv podvrhnout, jen musí napřed navštívit nějakou mizernou autoritu.

Dobrý příklad je SSH. Tam se to při prvním spojení zeptá zda sedí fingerprint a pak to nadává, pokud se klíč změní. Pokud by ten fingerprint byl na začátku uložen v DNS a/nebo podepsán autoritou, tak by to zlepšilo důvěryhodnost i při prvním připojení. Techniky jako certificate pinning se snaží TOFU dostat i do HTTPS, ale stále to je v plenkách a není to moc rozšířené.

[Filip Jirsák]

Pokud bude Web of Trust o nulové velikosti, tak degraduje na prosté TOFU, což je sice na první připojení horší než certifikační autority, ale na každé dalsí spojení mnohem bezpečnější.

TOFU samozřejmě můžete použít i s PKI. Při použití TOFU je každé další spojení stejně bezpečné, jako to první – tím, že se připojíte podruhé, se bezpečnost logicky nemůže nijak zvýšit.

Web of Trust si vynucuje ověřování a řešení důvěryhodnosti.

Jak si to vynucuje? Co mi zabrání bez rozmýšlení podepsat nějaký klíč?

Oproti tomu certifikační autority jsou za důvěryhodné považovány všechny, takže se důvěryhodnost konkrétního klíče/certifikátu neřeší a kdokoliv mi může kdykoliv cokoliv podvrhnout, jen musí napřed navštívit nějakou mizernou autoritu.

Nestačí mizernou autoritu navštívit, je potřeba od ní získat certifikát. Standardy i těch nejhorších certifikačních autorit jsou pořád mnohem vyšší, než standardy běžných uživatelů PGP. A to nemluvím o akreditovaných certifikačních autoritách, ty jsou na tom ještě o hodně lépe.

Dobrý příklad je SSH. Tam se to při prvním spojení zeptá zda sedí fingerprint a pak to nadává, pokud se klíč změní. Pokud by ten fingerprint byl na začátku uložen v DNS a/nebo podepsán autoritou, tak by to zlepšilo důvěryhodnost i při prvním připojení.

Ano, SSH je dobrý příklad. Kolik procent lidí si ty otisky reálně kontroluje? Pokud je otisk na začátku uložen v DNS a/nebo podepsán autoritou, nezlepší to důvěryhodnost jen při prvním připojení, ale při všech. Protože důvěryhodnost všech následujících připojení je závislá na důvěryhodnosti toho prvního připojení.

Techniky jako certificate pinning se snaží TOFU dostat i do HTTPS, ale stále to je v plenkách a není to moc rozšířené.

Web of trust, certifikační autority a TOFU jsou tři konkurenční modely – někdy se mohou doplňovat a někdy si naopak překáží. TOFU se hodí tam, kde se komunikuje s omezeným okruhem adresátů. Pokud máte jeden SSH server a přidáváte jednoho klienta ročně, není problém jednou za rok ten otisk pečlivě zkontrolovat. Když budete mít ty servery někdo v cloudu a vznikne jich několik denně, už to žádná výhra nebude. Mimochodem, všimněte si, jak je to v OpenSSH implementováno – zobrazí vám otisk klíče a nechá vás to potvrdit. Takže to můžete odmáčknout bez jakékoli kontroly – a počítá se s tím, že to tak spousta lidí bude dělat. Přitom by bylo triviální vynucovat ověření klíče – prostě byste musel ten otisk odněkud opsat, klient by vám ho nezobrazil. Jen by to,co jste napsal, s otiskem porovnal. To by bylo podstatně bezpečnější – akorát o to skoro nikdo nestojí.

V případě HTTPS komunikujete každou chvíli s novým serverem, takže je TOFU nepoužitelné. Certificate pinning se nidky ani moc nerozšíří, protože to je přesně ten případ, kdy jde TOFU proti těm dvěma konkurenčním modelům (web of trust i certifikační autority). Oba dva modely totiž počítají s tím,že důvěřujete něčemu jinému, než koncovému klíči – takže ty klíče se mohou snadno měnit. Nastartuje nový server v cloudu a vygeneruje si nový klíč. Server se ukončí a klíč se zahodí. Certificate pinning je pak k ničemu, protože budete akorát pořád ověřovat nové klíče.

[j]

Nikolivek, drtiva vetsina lidi netusi, zjevne vcetne tebe, ze to s bezpecnosti nema naprosto nic spolecnyho. Jediny co to rika, ze ta komunikace, s vi buh kym, je nejak aspon castene, vi buh jak, sifrovana.

Naprosto bez potizi ti ukazu, jak budu mit pro stejnou domenu v jeden cas dva platny "duveryhodny" certifikaty od dvou ruznych CA. A takovy cert muze ziskat kdokoli, staci k tomu mit na dany domene trebas mail, nebo sedet nekde na siti vedouci k webu, nebo mit moznost zmenit dns ... pripadne mit pristup primo k ty CA.

Pokud by to totiz melo mit neco spolecnyho s bezpecnosti, tak bys musel mit ten proces pod kotrolou, a to samozrejme vcetne toho, cemu duverujes s cemu ne.

A tim se dostavame k DANE, ktery je radove duvehodnejsi, vyrazuje totiz z toho procesu celou radu prostredniku a tim radove snizuje rizika. Coz je presne ten duvod, proc ho nikdy guugl a jeho pobocka chrozilla neimplementujou.

A az tu zas zacne nekdo blabolit o dnsec, tak bez toho klidne i uplne nesifrovanyho a nezabezpecenyho DNS se stejne nijak nikam nepripoji, takze tomu kupodivu at chce nebo ne, duverovat stejne musi. Neexituje tudiz zadnej duvod, proc by nemel verit klicum z dns, kdyz veri ip.

[Filip Jirsák]

fungování kvalifikovaných certifikátů (nebo jak přesně to právníci nazvali) je hodně odlišné od toho, jak se PKI běžně používá v prohlížečích a MUA

V čem se to hodně liší? V obou případech mi někdo nadiktoval seznam autorit, kterým musím věřit. Rozdíl je jenom v tom, že v tom prohlížeči nebo MUA si ten seznam můžu upravit, kdybych chtěl.

to, že se openpgp model nehodí pro široké masy, ani zdaleka neznamená, že je špatně navržený; prostě je jen navržený pro jiné účely a jiné prostředí, kde funguje naopak výrazně lépe.

Já jsem nikde nepsal, že je model web of trust špatně navržený. Polemizuju s tím, že není vhodný pro široké masy. Problém není v širokých masách, problém je v tom, že se ten model hodí jen do nějaké komunity. PGP klidně mohou používat zahrádkáři, a vůbec bych se nedivil, kdyby existovaly komunity mimo IT, kde se PGP používá.

Obávám se, že takdy se prostě neshodneme, protože zrovna ten příklad, který jste sám vybral, to ilustruje dost názorně

Já jsem ovšem nepsal, že každé bezpečnější řešení je automaticky i pohodlné. Psal jsem jen to, že ta bezpečná řešení se často dají udělat mnohem pohodlnější. Jenomže je obvykle vymýšlejí experti na bezpečnost, kteří ovšem vůbec neberou v úvahu chování lidí. Pak z toho vznikají takové nesmysly, jako nutnost pravidelné změny hesla. Což je zrovna příklad toho, co píšu – když nutnost pravidelné změny hesla zrušíte, dostanete podstatně pohodlnější řešení, a je stejně bezpečné, možná o fous bezpečnější, protože bude menší tlak na uživatele, aby si volili slabá hesla. Další příklad jsou správci hesel – je to pohodlnější, než si hesla pamatovat, a podstatně bezpečnější. Podobně třeba přihlašování tokenem, čipovou kartou nebo U2F.

Tato věta je obsahově prázdná, pokud neřeknete, oproti čemu ji má zvyšovat. Oproti tomu, když se identita nebude ověřovat vůbec, rozhodně ano, ale to není moc vysoko nastavená laťka. Oproti web of trust modelu provozovanému dostatečně informovanými a zodpovědnými uživateli… ani náhodou.

Myslel jsem si, že je jasné, že porovnáváme ověření identity certifikační autoritou a ověření identity jednotlivcem. Ano, pokud budou web of trust provozovat dostatečně informovaní a zodpovědní lidé, bude to stejně bezpečné, jako když to ověřuje akreditovaná certifikační autorita. Ti lidé musí být například informovaní o tom, jak správně ověřit doklady totožnosti. A zároveň si musí být jistí, že stejně dobře postupují i ti, jejichž podpisům věří. Víte, jak početná je síť takových uživatelů? Přesně 0 osob.

[Michal Kubeček]

V čem se to hodně liší?

Jak v tom, jak důkladně se ověřuje identita žadatele, tak v tom, jak komplikované je takový certifikát získat. Ono to pak totiž najednou už není podstatně jednodušší než získat podpisy pro web of trust. (Pokud to vůbec je jednodušší - pro každého určitě ne.)

Pak z toho vznikají takové nesmysly, jako nutnost pravidelné změny hesla.

Což už skuteční experti - včetně oficiálních organizací - nějaký ten pátek nedoporučují.

Další příklad jsou správci hesel – je to pohodlnější, než si hesla pamatovat, a podstatně bezpečnější.

Pro méně důležitá hesla ano. Ta opravdu důležitá bych takovému správci nesvěřil.

Podobně třeba přihlašování tokenem, čipovou kartou nebo U2F.

Už sama potřeba si takový token nebo kartu pořídit (úplně zadarmo to není), na jedné straně ho mít po ruce, když je potřeba, a na druhé dávat pozor, aby se nedostal do nepovolaných rukou, to pohodlí do značné míry eliminuje. Takže za opravdu pohodlnější bych si to troufl označit až od takové míry nároků na bezpečnost, která se většiny uživatelů netýká.

Myslel jsem si, že je jasné, že porovnáváme ověření identity certifikační autoritou a ověření identity jednotlivcem. … Přesně 0 osob.

Jak jsem řekl, na tomhle se prostě neshodneme. Pro mne je třeba web of trust kolem linuxového jádra podstatně důvěryhodnější než ta šílená sada "důvěryhodných" certifikačních autorit, kterou mi Mozilla Foundation nasypala do Firefoxu.

Celkově je mi ale především moc smutno z toho, že je to v krátké době už druhý blog, u kterého byla diskuse místo technických témat a praktických zkušeností, které by mohly být leckomu užitečné, hijacknuta na neplodný flame na téma "je to vlastně vůbec k něčemu?" Tímto se omlouvám za svůj podíl a pokusím se v tom dále nepokračovat.

[vencour]

Ok, kdybych byl autor zápisku, přidam nějakou anketu ve smyslu

• toto znám a používám, nuda, nic nového jsem tu neviděl
• nějak je mi to povědomé, viděl jsem to, základ používám
• to jsi to autore zamotal ještě víc
• konečně mi to někdo vysvětlil
• na tohle mam lidi
• cože to je, to se k něčemu používá?

[Filip Jirsák]

Což už skuteční experti - včetně oficiálních organizací - nějaký ten pátek nedoporučují.

Ano, akorát se to v oboru drželo přes dvacet let. A u těch oficiálních organizací se to dá opravdu počítat na pátky, kdy to přestaly doporučovat.

Pro méně důležitá hesla ano. Ta opravdu důležitá bych takovému správci nesvěřil.

To je další z problémů počítačové bezpečnosti. Pokud už se tím někdo trošku začne zabývat, obvykle hrozně přeceňuje sám sebe a podceňuje vše ostatní. Pak z toho vznikají takové bludy, jako že web of trust je teoreticky bezpečnější než certifikační autorita nebo že pamatovat si heslo je bezpečnější, než používat správce hesel.

Už sama potřeba si takový token nebo kartu pořídit (úplně zadarmo to není), na jedné straně ho mít po ruce, když je potřeba, a na druhé dávat pozor, aby se nedostal do nepovolaných rukou, to pohodlí do značné míry eliminuje. Takže za opravdu pohodlnější bych si to troufl označit až od takové míry nároků na bezpečnost, která se většiny uživatelů netýká.

Dostupnost se bude postupně zlepšovat, teď jsme úplně na začátku. Dávat pozor, aby se nedostal do nepovolaných rukou, je snazší, než u hesla – resp. u hesla to skoro nikdo neřeší nějak aktivně, stejně tak to nebudou aktivně řešit lidé u tokenů a U2F. A pasivní bezpečnost (že to vyloženě někomu nestrkám pod nos) je u tokenů a U2F na mnohem vyšší úrovni. Oproti přihlašování heslem, které si uživatel pamatuje, je používání tokenu nebo U2F určitě pohodlnější.

Pro mne je třeba web of trust kolem linuxového jádra podstatně důvěryhodnější než ta šílená sada "důvěryhodných" certifikačních autorit, kterou mi Mozilla Foundation nasypala do Firefoxu.

Lidé kolem linuxového jádra jsou pořád komunita. A upřímně řečeno, odolnost téhle komunitu proti náhodnému útočníkovi, je podstatně menší, než odolnost i těch nejhorších certifikačních autorit ve Firefoxu. Problém toho seznamu certifikačních autorit jsou různé čínské a podobné autority, které budou mít problémy s útoky svých vlád. Což mne v současné situaci nemusí tolik trápit (ano, je to sobecké).

Celkově je mi ale především moc smutno z toho, že je to v krátké době už druhý blog, u kterého byla diskuse místo technických témat a praktických zkušeností, které by mohly být leckomu užitečné, hijacknuta na neplodný flame na téma "je to vlastně vůbec k něčemu?" Tímto se omlouvám za svůj podíl a pokusím se v tom dále nepokračovat.

Nemyslím si, že bychom v tomhle vlákně diskutovali o tom, zda je to vůbec užitečné. Diskutujeme o tom, jaké to má vlastnosti a k čemu to tedy užitečné je a k čemu už ne. Za mne je PGP užitečné v tom, že je to hezký systém na výměnu klíčů, přičemž důvěryhodnost klíčů není zabudována přímo v tom systému – což je podle mne klíčová vlastnost a je chyba tvářit se, že je tam zabudovaná. Ale ve spoustě případů stačí TOFU, ve spoustě případů se dá klíč bezpečně předat jiným způsobem (což je třeba případ nejčastěji používaných asymetrických klíčů – pro DV certifikáty, kde se kvůli PKI provozuje drahý byznys tam, kde by stačilo zveřejňovat klíče v DNS). Ale web of trust bych rozhodně nevyzdvihoval jako přednost PGP, protože je to z hlediska bezpečnosti velmi přeceňované a reálná bezpečnost je na úrovni TOFU, možná o kousínek výš.

[j]

Cely problem je pouze v tom, ze ta verejnost nechape, ze zadna duveryhodna autorita neexistuje. Ani jedna jedina. A ve skutocnosti prave importem vsemoznych CA at uz do systemu nebo browseru dochazi k tomu, ze ani ten kdo chce, neni schopen si zcela libovolnou bezpecnost zaridit.

Protoze i kdyby si nekam chtel ulozit zcela konkretni klice kterym duveruje, treba proto, ze je ziskal osobne, tak je mu to houby platny, protoze jeho aplikace se smiri i s klicem uplne jinym, od jedny z tech CA.

Ve skutecnosti je specielne na webu idea jakykoli anonymni bezpecnosti totalni hovadina, protoze ziskat ten "duveryhodny" klic umi kdokoli.

---

Dete s tim guuglem dopice!

[Tomáš]

BTW: Spoustu těch odkazů máš blbě, protože ti tam vlezly nějaké uvozovky.

Dík, co jsem našel, jsem opravil.

[elenril]

Poslední dobou si říkám že by bylo hezké kdyby někdo napsal kryptovátko nad SSH klíči. Ty každý má, všichni jim tak nějak rozumí, navíc ed25519 klíče se vejdou na ne moc dlouhý řádek.

GPG je opravdu dumster fire. Celý ten systém je extrémně překomplikovaný (opět srovnej s SSH). Základní koncepty nejsou nikde pořádně vysvětlené. Nemá rozumnou použitelnou knihovnu, GPGME je AFAIU jen wrapper nad execve("gpg"), což snad mluví samo za sebe. Opět pro srovnání - existuje několik nezávislých implementací SSH protokolu, z nichž jedna je knihovna v Pythonu.

Say no to GPG, kids.

[bukowski]

Neexistuje nahodou neco jako seed u BTC na zalohovani master private key?

[vencour]

Přidal jsem do výběru.

[plostenka]

Tohle je dalsi z clanku, ktere zbytecne GPG demonizuji. Proc autor na zacatku zmatkuje s vytvarenim adresaru, kdyz i v livecd Mintu (takze asi rovnou po instalaci GPG) staci napsat 1, slovy JEDEN prikaz a ostatni se stane samo?

$ gpg --gen-key
gpg (GnuPG) 1.4.20; Copyright (C) 2015 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.

gpg: directory `/home/mint/.gnupg' created
gpg: new configuration file `/home/mint/.gnupg/gpg.conf' created
gpg: WARNING: options in `/home/mint/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `/home/mint/.gnupg/secring.gpg' created
gpg: keyring `/home/mint/.gnupg/pubring.gpg' created
Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
Your selection? 1
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 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
Is this correct? (y/N) y

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

Real name: plostenka
Email address: 
Comment: test
You selected this USER-ID:
    "plostenka (test)"

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

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
...+++++

Not enough random bytes available.  Please do some other work to give
the OS a chance to collect more entropy! (Need 202 more bytes)

gpg: /home/mint/.gnupg/trustdb.gpg: trustdb created
gpg: key A6241D0C marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
pub   4096R/A6241D0C 2020-05-28
      Key fingerprint = 75C2 C03C 1B3E 61B8 E606  47F5 BBFE D597 A624 1D0C
uid                  plostenka (test)
sub   4096R/5E65E357 2020-05-28

HOTOVO. A muzu klic pouzivat. Bezny uzivatel nepotrebuje rozlisovat podklice, chce jen posilat maily/soubory tak, aby je nemohla precist treti strana (zasifrovanim klicem prijemce), a nebo aby prijemce vedel kdo je autor (podepsanim vlastnim klicem). Mutt/Thunderbird/Evolution GPG podporuji, neni problem. A jak rika predrecnik, neexistuje alternativa ktera by nevynucovala duveru k master klici, ktery nemam pod kontrolou (PKI a webove "autority").

[N]

Uvod bych si predstavoval vice srozumitelneji treba jako tento

[Petr Fiedler]

Super zápis, díky.

[Xerces]

Dík za zápis zajímavou diskuzi. My jsme GNUPG používali ve firmě cca 15 let zpátky v kombinaci s KMail ještě v dobách KDE3, kde to fungovalo bezvadně a pohodlně. Po překopání KDE na verze 4 a 5 a zakomponování slavného Akonadi jsem se ke KMail už nevrátil, takže nevím jak a jestli to tam je implementováno i teď. Každopádně je mi ten koncept mnohem bližší, než "slavné" certifikáty.

[Michal Kubeček]

Tak ještě nápověda pro ty, kdo by chtěli vyzkoušet použití gpg klíče pro ssh autentizaci a podle návodů na webu (např. [1], [2], [3]) to nefunguje. Zdá se, že většina návodů je psaných pro starší verze gpg a nepočítá s user friendly prostředími typu KDE, kde se gpg-agent spouští globálně pro celé prostředí.

Takhle mi to funguje s openSUSE Leap 15.2 (gpg 2.2.5):

1. Vygenerovat autentizační ([A]) subkey nebo přidat tuto funkci existujícímu.
2. Pomocí "gpg --export-ssh-key <id>" vyexportovat veřejný klíč v ssh kompatibilním formátu a řádek přidat na server do authorized_keys; jako <id> lze použít id autentizačního klíče, id master klíče (stejně se exportuje autentizační) nebo třeba e-mail.
3. Přidat řádek "enable-ssh-support" do ~/.gnupg/gpg-agent.conf (pokukd neexistuje, vytvořit ho).
4. Teď je v návodech něco o přidání nastavení SSH_AUTH_SOCK do ~/.bashrc a restartu gpg-agent (tedy kill a buď spustit ručně nebo doufat, že se to udělá automaticky); pokud máte gpg-agent spuštěný při startu desktopového prostředí, nemusí to fungovat dobře, takže se mi spíš osvědčilo ukončit session a přihlásit se znovu. (Tohle všechno se stejně dělá jen jednou.)
5. A teď ta část, kterou jsem našel jen tady (a to až poté, co jsem na to přišel sám): v ~/.gnupg by se měl objevit soubor sshcontrol, do kterého je potřeba přidat řádek s gripem každého klíče, který se bude používat pro autentizaci ("gpg --list-keys --with-keygrip <id>"). Všechny ostatní totiž bude gpg-agent ignorovat.
6. Teď už by měl "ssh-add -l" nebo "ssh-add -L" klíč ukázat.
7. …a ssh klient by ho měl být schopen pooužít tam, kde je na serveru v authorized_keys

Celé to má smysl hlavně pokud je openpgp klíč v tokenu nebo kartě, jinak je obvykle jednodušší použít nativní ssh klíč a ssh-agent.

[Petr Fiedler]

Díky. I za ostatní příspěvky. Dobrý zdroj informací.

[kolcon]

tak jako GPG je cool a vsechno, ale pokud mi za 20 let neprisel jediny mail zasifrovany mym verejnym klicem, tak pouzitelnost pro email v praxi nulova...

ze muzu mail podepsat svym klicem je super, kdyby to bylo v praxi jak overit...

zasifrovane soubory ani nemuzu jednoduse sdilet, protoze to 99.9x% populace neotevre

na sifrovani souboru na disku jsou pohodlnejsi varianty, treba LUKS pro cely filesystem

 

k cemu to GPG vlastne *prakticky* je? (chapu, ze ty body nahore nejsou vina toho programu)

[Filip Jirsák]

V open source světě se pomocí GPG podepisují aplikace nebo distribuční balíčky. Jinak web of trust, na které je založeno PGP, může reálně fungovat jen v komunitách. Pokud nejste v žádné komunitě používající PGP, je bláhové se domnívat, že vám jen tak někdo z internetu pošle e-mail a bude mít váš veřejný klíč.

Šifrování souborů se hodí třeba na zálohy. Nechcete to s nikým sdílet, nechcete šifrovat celý souborový systém, jenom chcete zašifrovat soubor asymetrickou šifrou a privátní klíč mít někde bezpečně uložený.

[kolcon]

Ano, podepisuju tim git commity.

[Petr Fiedler]

Řekl bych, že je to pro rozumné a zasvěcené lidi, kteří mezi sebou chtějí komunikovat bez ztráty soukromí. Ale takových je málo. Většina je líná se něco učit a někteří z nich na FB fotí i to, co večeřeli.

[Petr Fiedler]

Samozřejmě mimo jiné. Já se vyjadřoval k mejlům.

[vencour]

Opravdu nepřišel? Opravdu nevíte?
Možná jste dostal vše jinou cestou? Nebo možná to dostal kolega jako spolehlivější člověk a Vám to jen utrousil na obědě?
Nebo je vše ... jinak.

[Blabolak]

No hezký, a už to ve stabilní verzi umí ty eliptické curvy? Nevíte kdokoliv?

[Michal Kubeček]

Jak ty "zlé", tak ty "hodné":

mike@lion:~> gpg --version
gpg (GnuPG) 2.2.5
libgcrypt 1.8.2
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/mike/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2