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.