The MAC of a PGP message is the SHA-1 of its plaintext appended to the message.
There are coherent ways to downplay today's announcement, but "PGP isn't broken" isn't one of them. The best you can do is "PGP is broken but we already knew that".
Yes. But unless I've missed something no one has bothered to even attempt any modernized, improved replacement, so we continue to muddle along. I've certainly heard complaints about existing secure email technologies for well over a decade, but at the same time the cryptography field has never offered an upgrade. Instead it's always been "completely give up on the concept of email (which in no way needs to be insecure) for these modern hip non-federated often proprietary clunky slow kitchen sink instant messenger things instead". To which the answer has and continues to be "no".
Maybe we live in a world where the creation and upgrading of a technology like email is no longer feasible and that's just how it is. If so though I foresee email as it is existing into the foreseeable future, and in turn it'll be useful to have some sort of crypto bolted on top, as a marginal improvement vs entirely plain text. Hopefully there will be enough security oxygen that OpenPGP could at least modernize the foundations a little even if it meant some breaking changes to old implementations.
That is not contrary to what I'm saying, that is exactly what I'm saying. Much of the world, both corporate and private, do not want "messaging", they want "email". I use scare quotes for the latter because I want to distinguish between email as in existing technical standards dating all the way back to RFC 561 and email as-in that kind of information transfer service and format, distinct from messaging. Messaging has its place too, but there is clearly a desire for an electronic version of sending a piece of mail. It fits human and cultural psychology. It produces a different kind of consideration and formatting, which has both its merits and demerits. But messaging is not a replacement for email. You can insist that it is but I don't think you will be successful, and you should know better then most that security which isn't used isn't useful security.
>Don't send secrets over email
Back here on Planet Earth sending all sorts of secrets over email and using it for authentication of incredibly important accounts is the regrettable rule, not the exception. Like use of passwords. It is the reality in which we live. I see no sign of it changing either unless there is a direct in-place upgrade available. Which there is not.
>replace email with this thing that requires a phone number and is not like email
No.
>replace email with this thing that didn't even bother to add e2e crypto until 2016, claims to be agpl/gplv3 but then adds a bunch of other random crap on top, etc. Also not email.
No.
Just stop using email to deliver secrets.
At the least I'm not sure this is legally feasible under ERISA electronic delivery requirements, to name a single one amongst a host of other often incredibly complex regulations. It might be ok under the UETA, but either way that wouldn't be my call.
I am 100% sure that it wouldn't be ok with coworkers, customers, and in turn bosses, so demanding to cease all usage of email would get me fired. I mean, even entirely plain text email isn't sufficient to get anyone to stop using it to deliver secrets. It's been a real improvement just to have the MUA<>Server connection be encrypted, and even that is probably still not universal!
But at its core, the promise of pgp/gpg is the promise of encrypted and authenticated file transfer.
The file might come from ftp, samba/cifs, Dropbox/Google drive/etc, from tape or HD backup - or come attached to an email.
It may come from yourself, or from a friend.
But the promise is that between the encryption and signing - and the verification and decryption - the file remain the same. The zip file is as (Un)safe to extract, the font as (Un)safe to render - the installer or the executable as (Un)safe.
If you have (authenticated) file encryption, you have encrypted email.
If you want to use authenticated file encryption as a secure messaging platform, you should probably invest in a more sane format for your plaintext file than email. And a better wrapping transport than email.
The fundamental problems with email+pgp as a secure messaging platform isn't pgp alone - but the intersection of email-the-format, email-the-protocol mixed with the mail user agents and their 80s trusting file handling (ok, that's unfair to the 80s, we're still too trusting when it comes to files in general and transclusion in particular).
In short, I don't think we should give up all of pgp as such (open, secure, authenticated file encryption and Web of trust).
But it's probably true that newer protocols are better for "real-time" messaging, and perhaps usenet is better for hold-and-forward.
[ed: I'd love to hear some current informed discussion about: https://saltpack.org/ mentioned in this discussion here. From the previous hn discussion it seems reasonable; a sane format (message pack), authenticated encryption primitives - but I worry a bit about public key handling - is there Web of trust/certificate support - and if so, is it sane? I'm not saying pgp/gpg wot is sane. But neither is ssh (certs) in practice. I'd much prefer wot - were for some applications I could choose arbitrary key/certs as authorative CAs and give out short-lived "certs" (signed public keys with valid from-to).]
Doesn't Signal require you to publish your actual phone number, which reveals your RL identity in the network pretty much completely controlled by government?
The desk phone at your office.
A free Google Voice phone number, if you live in the United States (this is what I do).
Any phone number from any online calling service, like Skype.
A cheap pre-paid SIM card for a few dollars a month (and temporarily put it on your phone to register your second Signal number).
Twilio, a cloud service that allows developers to write software that makes and receives phone calls and SMS messages.
Obviously, each of those still requires registration within government-controlled phone network, and additionally also may require you to entrust your security to a third party - such as your employer, Google, Microsoft or Twilio. So in fact, you refutation of my assertion "you need to publish a phone number" is "you can have two phone numbers". This is not serious.
Signal, and the Signal server operators, malicious or not, do not know the phone numbers of people you are communicating with (presuming the secure enclave on the server isn't cracked). Signal does know your phone number, so someone could figure out if you use Signal. If you're worried about that, or personal sharing of your number, you could falsify information to create an anonymous phone number, or you can just use Matrix or Wire.
At least with GPG I can factory reset all of my computers and phones and not have to re-establish trust if I take the right steps to preserve the secret key information.
Even if I don't preserve that correctly, people change computers less often than phones.
On the other hand, I'll admit that my GPG key is newer than my Signal number (which I've owned for 15 years), due to upgrading crypto algorithms.
I perform the safety number verifications in exchange for forward and backward secrecy. GPG isn't enough to establish a truly confidential communication channel, I think. (Unless you erase keys after every sent message, maybe.)
I'm not happy with Signal's dependence on a phone. Ideally I'd like to use a pocket-sized SBC for secure messaging. Come to think of it, that sounds rather like a phone. Just, uh, without the cellular hardware, and with a user-installed OS.
Taking something like megolm [1] and running it over SMTP is such an obvious answer that, eventually, somebody will give it a go. Until then, we get to keep having this argument on the internet every few weeks...
No PFS, though
Now that I think about it there is also a modest effort to simply enhance the UI of the whole deal through transparent embedding vs as an attachment. I think modest efforts of that nature that are evolutionary vs revolutionary around existing installed base will like it or not continue to serve an important practical role.
Do you mean that gpg is broken for non email use cases as well? Eg. encrypting tarball with backups using gpg and then storing it on some cloud service?
Long term, we really need an upgrade that breaks compatibility with old unfixable clients
No they don't. Also PGP works just fine. It could use some improvements, but it's doing well.