PS: Photon hosting private keys is, to me, a nonstarter. It makes their entire platform and investment in GPG pointless.

It's not an important rule if security is your primary concern. Because if you "don't break shit", the first thing any adversary will do is to try downgrade things until an old, insecure state.

The way to counteract that is to refuse to downgrade, which obviously breaks shit if one of the sides can't speak the new protocol.

The whole format for encapsulating PGP data is extremely complex and in some parts insecure. That's an excellent reason to rethink the problem.

In my understanding, this is not about "adding bits" or changing algorithms, it's about the level above. The packet format that says "This is the algorithm, this is the hash being used, this is the data, etc, etc".

"The PGP MDC can be stripped off messages –– it was encoded in such a way that you can simply chop off the last 22 bytes of the ciphertext to do that. To retain backwards compatibility with insecure older messages, PGP introduced a new packet type to signal that the MDC needs to be validated; if you use the wrong type, the MDC doesn’t get checked. Even if you do, the new SEIP packet format is close enough to the insecure SE format that you can potentially trick readers into downgrading; Trevor Perrin worked the SEIP out to 16 whole bits of security .

And, finally, even if everything goes right, the reference PGP implementation will (wait for it) release unauthenticated plaintext to callers, even if the MDC doesn’t match."

TL;DR, the packet format has "${DATA}${SIGNATURE}", in such a way that you can strip $SIGNATURE, do whatever you like with $DATA, and it'll go through because this is a backwards compatibility mechanism. Former versions didn't have $SIGNATURE, so any attacker can just get rid of it, and problem solved.

This is I repeat not a case of "maybe there's some PHD level math we're unaware of", but absolutely glaring issues.

You don't need a genius to write a formal proof of why allowing people to strip signatures is a bad thing.

And it's a problem solvable by throwing out the compatibility scheme and adding a hard requirement.

I would humbly propose that before you go telling everyone to stop using gpg, implement something that works, builds, and that doesn't break after 6 months or so. I've been using gpg for what, 20 years now? And recently (as in, three or four years ago) started using it with private keys stored on YubiKeys (using drduh's excellent guide). I also use it for symmetric encryption. It works. It doesn't break. It gets things done, and while I'm not secure from state-sponsored hackers, all this is infinitely better than no encryption.

Rage for example, is not in that category — I added it to my ansible automation as a test, and it broke after several months.

[0] https://moxie.org/2015/02/24/gpg-and-me.html

Incidentally, Signal is another example of an impractical solution being pushed without consideration for practical requirements. Signal will LOSE ALL YOUR DATA if your phone (iOS) dies. There is no way to backup your chat history and images. It's been like that for years and we get silly features instead of this fundamental thing.

Yes, I know many people like it this way — you are in the minority, and there should be a configuration switch saying "do not backup my data". Most people do not expect that their entire history will be gone one day. Phones die, phones get stolen, and you expect you'll get your history and photos back when restoring from an (encrypted!) backup. Not so with Signal. So the next time you tell people to use Signal over WhatsApp, don't forget to tell them that Signal will lose everything one day, while WhatsApp will not.

Back to my original point: before anyone knocks "old obsolete" apps, consider carefully if the new shiny thing really does everything that the "old obsolete" app did, is it reliable, maintained, and will it stay around for 10+ years.

I'm seeing this often on HN.

While it's a pain, it is not impractical. Most people don't care about this. They don't come back in time in the conversations.

If you really care about this. Like, you care that much. Just pair Signal Desktop and make a regular backup of your profile. All your messages and attachments are there. If your Signal ever gets borked, you can always put your machine offline and open Signal-Desktop on this backed-up folder. You can also open the db with sqlcipher and access all you data with it, the scheme is not too complicated to grasp.

Ask me how I know.

And since Signal is open source, you can always read its code in case of doubt. Someone could build a convenient UI to display or export the messages and attachments in a user-friendly format. This can happen after the backup is done and Signal breaks.

All this said, people may expect privacy when using Signal, so make sure your backups are well protected. This is the hard part, actually.

I can tell you that my daughter cared about this. She cried for a long time when her phone just suddenly died (while charging, no reason, total loss) and her Signal history wasn't restored. I couldn't explain why Signal was the only app that didn't get backed up.

I can tell you that my friend's parents cared about this. The photos of their grandkids were suddenly gone. My fried couldn't explain the reason for this, all the other data did get backed up.

And sure, between us geeks we will keep saying "well ACTUALLY they SHOULD HAVE kept the photos elsewhere", and we'll say "this is good because it makes us more secure" and we'll say "most people don't care about this". We'll all "well actually" ourselves, while patting ourselves on the backs.

And they'll just switch to WhatsApp.

I don't think I am. A practical answer is: "Install Signal Desktop".

And I still think we are few who care about chat history. I'm sure there are people who care. I'm such a person.

It's also only a missing feature for iOS user, so that makes it: "of the few people who care about chat history, the minority of people who use iOS are only covered by installing Signal Desktop". A pain for these users, but they have at least two workable solutions. Using Android or installing Signal Desktop somewhere. (yes, caveat, you need to do that before losing your phone)

By yes, I agree that it would be better to have the backup feature.

IMHO this is not always practical. Signal Desktop can easily get out of sync if you change versions and the only proper way to fix it is to clear all the local data, including your chat/contact database. AFAIK, the only source of truth is your phone.

"These users" don't even have a desktop computer :-)

"These users" will just use WhatsApp. It works it doesn't lose data, and everyone around them uses it anyway.

https://support.signal.org/hc/en-us/articles/360007059752-Ba...

"There's a technical issue with email encryption, but we have a solution: don't use email! instead, use this different protocol, that doesn't work with email clients or email addresses, but instead uses a telephone number as an identifier!"

I've never tried Signal, because I don't want my telephone number used as my identifier.

A bug in email encryption can be fixed by fixing the bug; proposing a completely different protocol/application isn't fixing that bug, it's just saying that this other protocol/application doesn't have the same bug. It's not a solution; at least, not for me.

GPG doesn't really do much for security, because a lot can be told from simply who communicates with who and when, and GPG does absolutely nothing there.

Email just fundamentally isn't encryptable; the protocol and the way it actually works in practice (hi, antispam!) requires that important parts of the email not be encrypted, and things like asynchronous communication make it difficult to do encryption to the gold standard of quality. Also, turning on encrypted email also disables several email features from the perspective of the user (hope you didn't want to search your emails!). The end result is that email encryption is, as someone else put it, LARPing rather than security.

There are a few very narrow use cases for which encrypted email may make sense (largely in cases where you're not concerned about hiding the existence of communication channels, just message contents, and you can do out-of-band public key communication). But notice that those use cases don't include "I want to message someone else securely," and it's definitely not someone that would work if you tried to let regular users do it.

I agree. Thing is, asynchronous communication is a killer feature. My primary communications channel is email, but I don't use encrypted email.

I do use GPG, but not for email.

Although that said, and while not disagreeing about its flaws, I still can't let entirely go by:

>the protocol and the way it actually works in practice (hi, antispam!)

But anti-spam works fine with encrypted email (putting aside practicalities of no forging making spam harder anyway).

>asynchronous communication make it difficult to do encryption to the gold standard of quality

Nobody gives a shit. Asynchronous communication is well worth it.

>hope you didn't want to search your emails!

lol wut? If I go into Mail and searching something it can include encrypted emails the same as whatever else, why wouldn't it?

https://news.ycombinator.com/item?id=17066986

You can read through that if you want, frankly it kind of surprises me how nothing at all has changed since then. It's impossible not to respect Thomas immensely in this field overall, or most of his commentary. Which is why I was and remain genuinely befuddled by his replies on this specific topic. So it goes?

The idea that there isn’t an obvious replacement for email in the encrypted text communications space is a wild assertion. Brain wormy even.

Identity is the core of the matter and that is invariant of the modes of transport. On top of that comes key management. On top of that you can build your secure application on whatever platform.

Total end to end encryption can only be built on top of identity and never (ever) on a specific channel. And TE2E should be the social goal.

Those alternatives have different use cases compared to (open)PGP. So, Moxie said GPG is too complicated? If Signal goes down, how long will it take you to spin up your instance of server and clients, ready for delivery? How much would cost running reliably that infra? For email and GPG, I can get everything in 15-20 minutes, including registering the DNS name, DKIM, and SPF. I can also sign documents, images, and invoices with GPG; in short, I can do business. What can I do with Signal: chat, send nice emojis, and make calls?

Proper security and encryption isn't a toy, and let's not kid ourselves by skinning apps with shiny buttons and cool claims that everything people have done before sucks.

[0] https://www.adobe.com/sign/hub/how-to/how-banks-use-electron...

This is evasive and dismissive. When your parent is talking about the issue, there's a good chance he is already using it. Telling him what "the real world" does is irrelevant. He has a use case already, and needs a solution for his use case, not for the rest of the world.

[0] https://xkcd.com/1172/

1. Many, many people used it, and continue to do so.

2. The anti GnuPG crowd keeps coming and touting alternatives, and then complain when the people in the prior bullet point out the impracticality of the alternatives for their use case.

We get that GnuPG has issues. We get that sometimes the alternatives are better. We can coexist with them. People simply don't understand that for a number of tasks, GnuPG is totally appropriate, and solves the problem with little pain.

In your real world, probably. In actual real world, people use MS Word/Excel (or LibreOffice) and images a lot, beside PDF. Good luck using e-signatures with that :)

Though yes... it's more secure than SMS.

> they don’t just knock PGP, they very often mention alternatives

What alternatives do they mention?

They've used some cipher, was it IDEA, than then got removed. So then I had to hunt down years old versions in order to be able to extract my old backups.

Or was that more of a PGP than GPG problem, and I misremember?

You wrote: "I would humbly propose that before you go telling everyone to stop using gpg, implement something that works, builds, and that doesn't break after 6 months or so."

Keybase did some stuff and got tons of users. It even had a command-line client. It was all open source, too. Is there any reason that the crypto old guard hasn't just shamelessly copied Keybase? The most important being: its CLI (the design, not necessarily the implementation) and the overall "shape" of the project organization/structure. Why hasn't gpg been "uplifted" into a Keybase-shaped "shell" for people to interact with? I.e. at both the tool level and at the collaborative project level?

RMS came from the AI lab working on Lisp machines. Despite this, he recognized that a UNIX-shaped project was the correct vehicle for his vision, given its growing popularity. Why haven't the GPG folks given up on trying force people to do things their traditional way and attached their cart to a horse that has legs?

That is perhaps what all of these replacement schemes fail to realize.

I really wish "Login with PGP" was a thing and use a subkey for each website, with optional ability to hide the identity of a particular website in my own keychain. You know, sorta like passkeys, but I don't have to have Google/Apple/etc involved and I can actually inspect the magic behind the scenes.

How well would such sites handle PGP subkey revocation? What about PGP key revocation?

Revocation is very important if your key is compromised.

I haven't seen any really maintained pgp keyserver or service in general that didn't directly or indirectly (by user/agent mistake) fail spectacularly since https://evil32.com/ was released and contaminated the 32bit key id space.

Strong words, but why?

PGP doesn't do this: PGP key has a claimant identity, but actually verifying that claimant is left to the end user. That's why the WoT and strong set were important (before they violently collapsed, revealing that they weren't load bearing after all).

Other schemes do realize this, and it's why they make tradeoffs around trusted parties (CAs in the Web PKI performing domain validation, EV for code-signing, etc.).

I hadn't heard they violently collapsed; do you have any links where I can learn more about this?

https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d695...

Also, as someone who went to a few signing parties: the strong set was probably never as strong as some people thought.

Just yesterday I was frustrated that gpg didn't work very well in my terminal for some reason (the barrier between entering the data and the password was weirdly permeable, i.e. sometimes some of my password ended up in the data, and more often a lot of what I pasted ended up in the password prompt).

So I found openpgp.js and made a little website where i can encrypt and decrypt my secrets.

I used that particular library because it feels safe that the things I have encrypted can be decrypted with a tool that is accessible everywhere... as long as I can remember the passwords :)

But I wonder, are the defaults for symmetric encryption in openpgp not considered safe anymore, or how should i interpret some of the other comments here?

That would be AES. The traditional OpenPGP authenticated encryption (OCFB-MDC) is secure. There has been some widespread misunderstanding, I wrote a rambling editorial against the idea of superseding the block cipher mode:

* https://articles.59.ca/doku.php?id=pgpfan:no_new_ae

What's that?

I've been using PGP for decades at this point and I'm still somewhat surprised when I encounter security professionals that either can't figure out how to use PGP or just ignore it because "its too complicated, and I already have Signal". I have no beef with encrypted messenger services but it's not the same use case as PGP for email and other needs.

This also hints at a separate cultural divide. Young people only know email as that thing you need in order to setup other accounts. They use IM for the bulk of their real communication and at best consider email something they only use for work. Only old farts think of email as something they use for personal correspondence. And frankly, most of the people I interact with are younger than me so most of my communication has shifted to where the people are that use it, which is IM services.

I think perhaps what you mean to say is that experts like the x509 PKI. Which again, isn't quite true. You'll find plenty of experts pointing out that major parts of x509 and the PKI ecosystem, and of TLS and HTTPS, are garbage: ASN.1 parsing is a trashfire, protocol/cipher negotiation has had numerous critical flaws, things like compression have allowed traffic to be decrypted.

What I think is more accurate to say is that experts have invested heavily in finding ways to augment web infrastructure to remove broad categories of these, and the result is a generally recommendable system. This includes things like moving to TLS 1.3, enforcing that CAs participate in Cert Transparency logs, delisting CAs that misbehave, and adjusting browser behavior to avoid security pitfalls like mixed content that compromise users.

The problem with doing that for GPG is partly that its fundamental nature is not well aligned with making those kinds of changes, and partly that (as we see in the original post) GnuPG is resistant to making changes that would leave behind users of insecure codepaths and cryptography.

It's getting really hard to take you seriously. You hate gpg, you hate pki and you always claim to know better than industry standards without providing any details whatsoever.

I'm pretty comfortable with who does and doesn't take me seriously, for what it's worth. You don't have to if you don't want to.

> I'm pretty comfortable with who does and doesn't take me seriously, for what it's worth. You don't have to if you don't want to.

Cool. Happy for you bro.

It might be useful to wait three months and revisit LibrePGP and the OpenPGP WG and see what progress has been made.

https://news.ycombinator.com/item?id=38554943

What is the alternative KM architecture in a distributed system? Remember that for e-mail there is no central authority to handle assigning keys to individuals, unless perhaps you want Gmail and Outlook.com to handle that.

The other e-mail security system is S/MIME (which uses X.509).

Sure if someone knocks over TLS then your email encryption will be in trouble, but you will also have plenty of other problems at that point.

This is actually possible for OpenPGP, with WKD ("Web Key Directory"): https://datatracker.ietf.org/doc/html/draft-koch-openpgp-web...

It's an expired draft, but is relatively widely supported: https://wiki.gnupg.org/WKD#Implementations

It should have been in mail systems forever. Whenever you create an account the first email should have been the server sending you your private key in some format that every email client understands and would then prompt you to automatically install it in your client for that server.

    Welcome to your new email account!  
    
    Your private key is attached in the standard format.  

    When your client asks you to install the key say "Yes", and allow it to automatically sign your email using that key for this account.

    Don't forget to check the box to automatically encrypt mail when possible.

Even before that, there were other mechanisms proposed for this, such as https://datatracker.ietf.org/doc/html/draft-shaw-openpgp-hkp... (from 2003). Unfortunately it didn't catch on; I agree it would've been nice to have such a mechanism earlier.

We've implemented this at Proton: https://proton.me/support/key-transparency (although it's still in beta, and opt-in for now - but obviously the aim is to enable it by default).

There's also a (relatively new) working group at the IETF, to work on standardizing (a version of) this: https://datatracker.ietf.org/wg/keytrans/about/.

Really paranoid folks could set up services online that check for this, but I kind of doubt it would happen very often because it would be a major stink for that email service if they were caught, and catching them isn't that hard.

The problem with existing keyservers is that there are several of them and you never know which one someone's public key might be living in. There may even be multiple potential keys for a single email address across the different servers. They are effectively useless for email encryption in their current form. It's a very rare email client that will even query the most popular ones looking for someone's key. In fact I don't know of a single email client that does.

Certificates in DNS, 2006: https://www.rfc-editor.org/info/rfc4398

That said, I agree with jandrese's point about key management -- low-security key management solutions shouldn't prevent people from taking a high-security approach. Seems like the ideal situation would be if the really paranoid people end up naturally testing the low-security infrastructure as a side effect of doing their paranoia stuff. E.g. if the gpg client was set up to automatically report discrepancies between a user's personal web of trust and a presumed-authoritative keyserver.

That said, it's unclear to me why Signal wouldn't have worked for Snowden -- interested to explore details here.

(via https://news.ycombinator.com/item?id=38554943, but we merged most of those comments hither)

I wonder up to which extent this has to do with the Mochizuki v. Scholze and Stix disagreement?

I say this because as far as I know: elliptic curves are the state of the art in crypto,

and the IUT theory (mochizuki's) has a lot to do with elliptic curves

Assurances that, don't worry, it's all gonna be backward compatible, are neither here nor there, from that perspective.

This kind of governance issues make it pretty clear that won't ever happen