Vlákno názorů k článku Chyba EFAIL umožňuje číst zprávy zašifrované pomocí PGP a S/MIME od kallsyms - Přijde mi to, že počet lidí, co z...

Přijde mi to, že počet lidí, co z toho šílí je více než 1000x počet lidí, co používá PGP/GPG na šifrování emailů.

Navíc ten threat model je neuvěřitelně nepraktický - potřebujete nejprve přístup do schránky odesílatele nebo cíle. Nebo man-in-the-middle na SMTP, co už je dnes přes TLS. Když k tomu přidáme fakt, je snad většina mailů je doručováno do gmailu (nezáleží jestli na gmail doméně nebo MX záznam na nasměrován na gmail), tak žádný útočník tohle v praxi nepoužije. Přitom nedávný bug v desktop verzi Signalu, který dělá z XSS RCE je na exploitování mnohem zajímavější cíl. (Vůbec Electron framework, kde XSS = RCE je mnohem horší architektonická volba pro aplikace zaměřené na bezpečnost). Tvrdit kvůli tomu, aby lidi nepoužívali Signal, je stejně hloupé, jako tvrdit, aby nepoužívali GnuPG.

Navíc hlavní použití GnuPG dnes je na podpisy balíčků, ne šifrování mailu (opět absolutní řádový nepoměr).

Když jsem se ptal, co by teda použili místo GnuPG na šifrování jednotlivých souborů nebo podpis zpráv, jediné doporučení jsem dostal minisign (https://github.com/jedisct1/minisign). Neviděl jsem nikoho, kdo by minisign používal (není to běžně ani v balíčcích distribucí). Navíc minisign neumí ekvivalent --clearsign u GnuPG (nemluvě o tom, že minisign postrádá všechnu další verzatilitu GnuPG).

Díval jsem se na zdrojáky a překvapilo mě pár podivností, které nevypadají úplně jako dobrý design. Z nějakého důvodu libsodium (která má pověst "užasného designu") používá několik nelogických věcí. Například místo toho, aby byla zvolena jedna podpisová schéma, jsou dvě - Ed25519 a Ed25519Ph. Ph je zkratka pro "pre-hashed" a má se používat pro soubory, které se nevejdou do paměti. Jediný důvod, proč to tak je z důvodu kompatibility - signify (https://github.com/aperezdc/signify) používá Ed25519. Dále je divný výběr hashovací funkce - Blake. Ne že by Blake byla špatná hashovací funkce, ale když že něco, tak proč ne Keccak (SHA-3 standard)?

Ten důvod s kompatibilitou uvádím kvůli tomu, že GnuPG kritizovali, že test integrity byl přidán později a jako důvod byla zpětná kompatibilita. Navíc GnuPG by default kontroluje integritu a dá warning.

K tomu všemu je jeden z kritiků je je Matthew D. Green, který tvrdí že GnuPG nemá "safe defaults" (není pravda), ale přitom jeho projekt Zcash má jako default "non-private" transparent transakce místo shielded transakcí. Množství hype a pokrytectví kolem tohoto bugu je neuvěřitelné.

Je to dost podobné jako BEAST attack - lidi z toho šíleli, Qualys SSL/TLS test z toho dlouhou dobu slintal a srážel skore, reálně BEAST ale nikdo nikdy nepoužil. Podobně jako nikdo nikdy nepoužije tento útok. To už je mnohem jednodušší trojan nebo jiný malware.

Navíc ten threat model je neuvěřitelně nepraktický - potřebujete nejprve přístup do schránky odesílatele nebo cíle. Nebo man-in-the-middle na SMTP, co už je dnes přes TLS.
Což je ale přesně to, proti čemu má šifrování e-mailů chránit. Nikdo z uživatelů, kdo věří, že jim stačí ochrana při přenosu pomocí TLS a na serveru už je e-mail v bezpečí, nemá potřebu e-maily šifrovat a tudíž se jich tento problém netýká.

Nesouhlasím s Vámi s tvrzením o nepraktičnosti threat modelu. Zapomínáte na motivaci vnitřních útočníků. Pokud budu admin, který spravuje mailserver, tak mám k dispozici VŠECHNY uložené šifrované maily svěřené organizace, nic nepotřebuji složitě zíkávat, ba co víc, můžu si krásně na základě Subjectu profiltrovat ty zajímavější maily.
Samozřejmě závěry některých médií "PGP (S/MIME) rozlousknut! Vypněte si šifrování!" je naprosté nepochopení jádra pudla a zbytečné zbulvarizování tématu.

„Dobrý den, já jsem administrátor GMail serveru a jenom vám sem jdu něco zapojit do USB. Vůbec si mně nevšímejte, jako bych tu nebyl. Vážně u vás ještě nikdo z GMailu nebyl? To je zvláštní, to my takhle uživatele obcházíme běžně.“

Jste mimo. Používám HW token, můžete mi do PC cvakat co chcete, odposlouchávat komunikaci mezi HW tokenem a PC a stejně se k privátnímu klíči nedostanete.
A druhý odstavec je také nesmysl. Jakmile mail dešifrujete, tak je pouze v paměti, na úložišti je vždy jen v zašifrovaném stavu.
Chce to trochu o tom něco vědět, než začnete plácat takové kokotiny.