From: Sergey Matveev Date: Fri, 11 Nov 2022 10:32:14 +0000 (+0300) Subject: My opinion on OpenPGP critique X-Git-Url: http://www.git.stargrave.org/?a=commitdiff_plain;h=refs%2Fheads%2Fenglish;p=stargrave-blog.git My opinion on OpenPGP critique >https://latacora.singles/2019/07/16/the-pgp-problem.html There are plenty of other articles like this, including the well-known Matthew Green cryptographer: https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-pgp/ https://words.filippo.io/giving-up-on-long-term-pgp/ https://secushare.org/PGP and some answers on that: https://pthree.org/2014/08/18/whats-the-matter-with-pgp/ https://articles.59.ca/doku.php?id=pgpfan:tpp And there are also many others. Some of them are just lame, because author treats OpenPGP only as a way to secure real-time (instant messaging, chats) communications. And they suggest something like Signal. They compare apples to oranges. Some of them, including latacora's one, just outdated from technical perspective. OpenPGP allows file encryption and file signing. That is basically all. And it allows sending encrypted/signed data to the remote side immediately: you gather (somehow) recipient's public key and, without any direct interaction with him beforehand, just sends him a message/file. All suggestions like Signal/OMEMO/whatever requires you to be online during conversation, to use interactive (from technical point of view) many round-trip protocol. That is why OpenPGP does not have forward secrecy property (no ephemeral keys are involved). That is why neither Signal, nor OMEMO can replace OpenPGP if you have no ability to stay online. Email is not interactive and online communication system. IMs are. Suggestion to replace email with IMs is just ridiculous. Those systems are for different tasks. It is like suggesting to stay at home to watch the movie, as an answer to the question "what automobile I should buy: electrical or gas one?". "signify" utility is indeed the great one. But it does not encrypt files. "age" utility to also good, but it does not sign/authenticate messages. Can you just signify age-encrypted files? Or maybe age-encrypt your signified file? https://words.filippo.io/dispatches/age-authentication/ tells us: If you encrypt and then sign, an attacker can strip your signature, replace it with their own, and make it look like they encrypted the file even if they don't actually know the contents. If you sign and then encrypt, the recipient can decrypt the file, keep your signature, and encrypt it to a different recipient, making it look like you intended to send the file to them. So those two utilities just can not replace so easily and transparently OpenPGP in that relatively simple task like "signcryption" (as filippo.io calls it). Maybe you do not need signcryption, just authentication/signing? Ok, signify is enough. Or actually now, in my opinion, it is better to use ssh-keygen from modern OpenPGP, that has built-in ability to sign/verify files using already existing OpenSSH keys. Maybe you need only encryption? Ok, age is enough for you. Maybe you are pretty ok with online real-time interactive communications for chatting? OpenPGP is definitely not the best tool there, because it is not forward secret. What if you really need that forward secrecy option? Then OpenPGP for chatting is definitely not satisfactory. ***Various*** tasks require various software. None of the software above is capable to fully replace anyone in every task. Next subject: trust management. Many articles tell us about complexity of OpenPGP key management. It is true. But only because trust and key management is *really* a complicated tasks. Most people can be satisfied with the third party for authentication, like X.509 PKI system works and "secures" our HTTPS connections. *Most* people are completely ok with "apt install letsencrypt" and automatically gaining X.509 certificate for their domain for free from Let's Encrypt company. But not *all* can be satisfied with that, because Let's Encrypt is just a single centralized USA-controlled point of authentication, that is just awful for many tasks. And for me it is completely unacceptable to allow USA full control over the authentication of my services. PKI is only the business model, it gives no *serious* security against more or less powerful adversaries, like USA government/forces for example. It secures about your neighbour connected to the same router/switch with you. http://www.stargrave.org/WhyNotLE.html Most people can treat the system as secure, if it is allowed to be MitMed by governments. Some people can not call it secure at all. So there are various attack threats, various definitions for acceptable security. Signal requires me to bind cellphone number to the account: that is *completely* unacceptable to me, but can be acceptable to many others. But I won't say that Signal is not secure. And nobody should call Signal's model as secure -- it is just different, it has different pros and cons, has different compromises. Acceptable to one people, not acceptable to others. So trust management in OpenPGP is complicated, because it tries to fitful everyone. You want completely manual trust setting for each key? Use manual model of trust. Someone is ok with WoT (Web-of-trust, when people sign other people's keys). Someone is completely not ok with WoT, because it leaks relations between the participants, it has privacy issues. Someone is ok with TOFU (trust on first use). There are so many options because there are so many various requirements in people. signify/age utilities does not have any kind of trust management except for manual setting of allowed keys. It is ok for 90%+ of users. As Let's Encrypt is ok for 90%+ of users. But OpenPGP technically can cover 100% of all users in that trust management field. Nothing prevents you to create the same X.509 PKI model in OpenPGP: just use WoT with some trusted third-party and tell that you fully trusts its decisions. OpenPGP just does not force you and bias to any kind of trust model, that is why it is more complicated and any complication unfortunately leads to user interface/experience complexity and burden. It is just more advanced and serious tool for wide field of tasks and trust models. Next subject: long term keys are bad. And the immediate question arises: for what task? If I am maintaining software and sign its packages, then hardly you could live without any kind of long-term identity. I know, I know -- many people have never ever verified any downloaded software, that is why so that many people deal with viruses, trojans, keyloggers and other malicious software. For me, life with untrusted malicious software on my computer is not acceptable, like it is for most people. That is why trust management and trust communication is something very necessary. Also most people are ok just to trust single entity, like Apple's software repository (AppStore), and they are ok with all that censorship they do in it and even their terms of use incompatible with free software definition: https://www.fsf.org/news/2010-05-app-store-compliance https://www.fsf.org/blogs/licensing/more-about-the-app-store-gpl-enforcement Is OpenPGP appropriate for IM and chatting? It can secure your channel, like now it secures our email conversation, but of course with neither deniability, nor with any forward secrecy. But why people suggesting to use Signal/whatever centralized solutions to that? Nearly twenty years ago appeared Off-The-Record (OTR) protocol, that is included in most IRC/XMPP/generic-chat clients I have seen out of box. I can use irssi IRC client with any existing IRC server and just use OTR messaging on top of it -- and deniable, forward secret channel is established. Ok, OTRv3 is kind a ancient nowadays: it uses huge and slow RSA keys, and shares them with each message, that can be noticeable on slow machines. But does it means that it is unappropriate for secure chatting? It is not ideal, but its support is widespread and is independent from the transport channel you use (use it on top of virtually anything that can exchange text messages). Why should I move to completely different software, servers, protocols and ecosystem, if OTR gives more than enough proven security? If you already use XMPP ecosystem and have got OMEMO-capable clients, then of course OMEMO is more preferable than OTR, just because of more efficiency (because of ECC keys). But using OTR is also nothing wrong. And using OpenPGP does not mean that you will definitely leak your keys and all your conversation will be disclosed and everything will be ruined. There are some risks, that can be accepted or not. Someone accepts X.509 PKI model, someone not. Someone accepts lack of forward secrecy, if there is no ability (or wish) to use online interactive real-time channels. By the way, I am aware that neither Signal, nor OMEMO does not require presence of the chat participants all the time, unlike OTR. They beforehand generate hundred of ephemeral keys and store them on the server. If somebody wants to chat with them, but they are offline, the server gives them one of those preloaded ephemeral keys. Good solution for most of users. But what if more than hundred of chats started? What if server is down or lost those keys? All of that are just tradeoffs. Completely clean solution without *any* server's knowledge of the protocol, like in OTR -- can be good, can be bad in some situations. Server's participation in Signal/OMEMO/whatever protocol and its bigger complexity -- can be bad, can be good tradeoff. There is no single evaluation of that. Next subject: cryptography algorithms and security. Many articles (including latacora's) tells about MDC and https://efail.de/. All of that is an olde bullshit already. For long time none of GnuPG versions do not accept MDC-less messages. EFAIL is a failure of MUAs, not OpenPGP itself. EFAIL is about how MUA developers made stupid insecure expectations from underlying cryptography library and failed there. Many people talk about huge RSA keys. For years GnuPG already ***by default*** uses ECC ed25519/cv25519 ones. Those short fast and secure algorithms are used already by default. Some people talk about MDC even more. But again, modern GnuPG versions supported AEAD encryption modes for years already. Personally I use OCB-mode and it is the fastest encryption speed I see on my hardware (with hardware accelerated AES). My current GnuPG is literally capable of precessing more than 1.2GiB/sec of data on a single core with VERY safe OCB mode, unlike the GCM one. Currently GnuPG is just state-of-the-art on algorithms selection. And some words about latacora's article more. Author writes about janky GnuPG's code. That is just ridiculous. Any software has CVEs. But can someone remember any catastrophic and fatal security issues with GnuPG and its libraries? I remember only one: when ***Debian*** maintainers patched it and completely broke its PRNG, so thousands of generated OpenPGP keys were completely insecure. But that was Debian's fail, not GnuPGs. And compare it with OpenSSL, that has many of fatal, catastrophic completely ruining bugs and problems like BEAST and Heartbleed: https://en.wikipedia.org/wiki/OpenSSL#Notable_vulnerabilities GnuPG (and its corresponding libraries code) is one of the best code by quality I have seen. When you (latacora) tell that some software is junky/bad, then it should means that most other software is better. GnuPG's software ecosystem is not perfect, but it is one of the highest quality one we had. And moreover, latacora advises to use ***online*** backup service. WAT? OpenPGP and GnuPG are not perfect, far from ideal, complex indeed (because solves many tasks and do not force to use single trust model for example) and have high entry barrier. All of that is right. Also they do not provide forward secrecy (although you can generate a new OpenPGP with each message and send it together -- and you achieve forward secrecy, nothing prevents you doing that in practice!). But personally I am pretty ok with lack of it, because that is acceptable risk for me (I really do not believe that my key will be leaked -- most likely I will fall somewhere, will hit my head and forget my passphrase). But at the same time, GnuPG has very high quality code, dozens of years of experience and proven technology software, and by default it is installed just our of box on most GNU/Linux distributions (do not know about nowadays, probably I am wrong, because each year GNU/Linux sucks more and more, transforming to yet another Windows/macOS). You *know* that you can send OpenPGP signed/encrypted data to someone on the other end and he will be able to process it. "signify" is installed neither on GNU/Linux nor on all BSD systems. "age" is not installed everywhere too. And moreover it is also far from being ideal: my gohpenc utility http://www.git.cypherpunks.ru/?p=gohpenc.git;a=summary can parallelize and is many times faster than age. They are not interchangeable, but age is far from being the fast one (GnuPG with OCB encryption mode completely outperforms it). Someone requires high performance. ---