Ruská firma Operation Zero nabízí až $4 miliony za funkčí exploit komunikační platformy Telegram. Nabídku učinila na platformě X. Firma je známá prodejem exploitů ruské vládě a soukromým společnostem. Další informace na securityweek.com.
Po 9 týdnech vývoje od vydání Linuxu 6.13 oznámil Linus Torvalds vydání Linuxu 6.14. Proč až v pondělí? V neděli prostě zapomněl :-). Přehled novinek a vylepšení na LWN.net: první a druhá polovina začleňovacího okna a Linux Kernel Newbies.
Konference LinuxDays 2025 proběhne o víkendu 4. a 5. října v Praze v areálu ČVUT v Dejvicích na FIT.
Mapy.cz rostou a postupně přechází na Mapy.com. V plánu je vylepšení Map novými zahraničními uživateli.
Byl představen Raspberry Pi PoE+ Injector pro napájení Raspberry Pi po datovém síťovém kabelu (PoE). Cena je 25 dolarů.
Jakub Vrána napsal AI plugin sql-gemini pro nástroj pro správu databáze v jednom PHP souboru Adminer. Plugin dovoluje sestavovat SQL dotazy pomocí AI, konkrétně pomocí Google Gemini.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Byla vydána nová verze 0.4.15 (𝕏) svobodného operačního systému ReactOS (Wikipedie), jehož cílem je kompletní binární kompatibilita s aplikacemi a ovladači pro Windows. Přehled novinek i s náhledy v oznámení o vydání.
Byl představen rpi-image-gen, tj. oficiální nástroj pro vytváření vlastních softwarových obrazů pro zařízení Raspberry Pi.
Byla vydána nová major verze 8.0, aktuálně 8.0.1, softwaru pro správu elektronických knih Calibre (Wikipedie). Přehled novinek v poznámkách k vydání. Vypíchnuta je lepší podpora Kobo KEPUB formátu nebo integrovaný lokálně běžící engine Piper pro převod textu na řeč používaný pro čtení nahlas (již od verze 7.18).
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.
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, BZIP2Dozvě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 EOFKdyž začneme na prudko generovat klíče
tom@mike:~$ gpg --gen-keyNakonec 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.dA ještě je dobré omezit práva i na hlavním adresáři, aby si GnuPG nestěžoval.
tom@mike:~$ chmod 700 ~/.gnupgPř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> saveOpě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> saveTeď 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 = 1E810267D620D288961DEA34A08CE42932ACEE10Když 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.keyA 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>
gpg -s sifrovani.txtVytvoří 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í.
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.1Jenom 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.2Vý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.
Tiskni
Sdílej:
Ty role klíčů jsou čtyři:
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.
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
".
-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ý.
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):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: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?
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.
Jestli to dobře chápu, tak kromě jsou tam v podstatě tři výhrady:
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)."
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í.
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á...
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.
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í).
[...] 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ě.
square()
tam vrací vždy nulu (protože VCS aplikoval změnu c1 na špatnou funkci).
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í.
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ý.
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ý.)
Pokud chces ukazat, ze filosofie darcsu je lepsiNechci.
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).
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...
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.
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í.
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.
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.
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.
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.
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í.
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.
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í.
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é.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ý.
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.
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 MUAV č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.
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.
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ýš.
BTW: Spoustu těch odkazů máš blbě, protože ti tam vlezly nějaké uvozovky.Dík, co jsem našel, jsem opravil.
$ 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-28HOTOVO. 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").
Super zápis, díky.
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):
[A]
) subkey nebo přidat tuto funkci existujícímu.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.enable-ssh-support
" do ~/.gnupg/gpg-agent.conf
(pokukd neexistuje, vytvořit ho).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.)~/.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.ssh-add -l
" nebo "ssh-add -L
" klíč ukázat.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.
Díky. I za ostatní příspěvky. Dobrý zdroj informací.
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)
Ř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.
Samozřejmě mimo jiné. Já se vyjadřoval k mejlům.
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