Comment by tptacek | Hacker News Reader

Comment by tptacek | Hacker News Reader

Parent Full thread

For simple operations like encrypting individual files or applying a signature to a document --- where the alternatives is already insecure --- PGP is fine, if clunky.

For modern message encryption, PGP is inferior to alternatives and generally should be avoided:

1. It lacks any native notion of forward secrecy or meaningful compromise recovery, which is table stakes for modern protocols.

2. Partly as a result of (1), it leaks meta-information; in particular, it's difficult to send deniable messages with it.

3. The most compatible subset of its protocols are built on 1990s cryptography, including non-AE bulk ciphers and RSA.

4. Its tooling is difficult to use, even more difficult to use with what we'd now consider adequate opsec, and far more difficult still for an ordinary person to use that way.

5. That tooling is of wildly variable quality; PGP sees somewhat routine vulnerabilities in its tools, which invariably get downplayed ("that's not a bug in PGP!").

6. Its most mainstream use is to attempt to layer modern message security on top of email, which is its own can of worms.

Generally, you should use Signal or maybe Wire (if you're a Signalphobe) in preference to PGP.

For an application where it really mattered, you'd want to see a signature system derived from SHA2 and Ed25519, with no backwards-compatibility towards archaic cryptography. There's nothing mainstream that really gives you this right now, but really there isn't much (outside of blockchainia, which is already hipster-deep in modern crypto esoterica) that really demands secure digital signatures.

I wish there was a more modern set of tools that implemented web of trust. I know that WoT will never be usable for the mainstream, but this does not mean that it is not useful at all. There are a lot of authentication situations where it is exactly what I want. Essentially the scenarios I want are: 1) I'm the guy you talked to last time and 2) I'm the guy that was talking to your friend. Having a central authority is inappropriate in a lot of cases, because the participants need to remain private (and it doesn't solve scenario #2).

For me PGP is problematic in that the protocol itself is really confusing with a lot imprecise concepts. Even the definition of a "key": is it the private key part, the public part, the public/private pair, a certificate, or all of the above? For me, this is where a lot of people get in trouble. You need to understand exactly how PGP works in order to use it effectively.

I don't really see either of these problems being fixed any time soon, unfortunately (for me, anyway ;-) ).

> I wish there was a more modern set of tools that implemented web of trust.

What would you use it for?

In another part of the thread, I kind of specified it a bit, but I'll try to give a realistic scenario here:

Imagine I am a remote worker who does contract work. I have never met my employer. We want to agree to a contract and show that the information we're working from hasn't been compromised by someone from the outside. Ideally, I want to authenticate messages from my employer, and they want to authenticate messages from me.

It's important to realise that encryption is not necessary here. We just want to show that nobody is injecting requirements. If it gets down to a he-said, she-said argument, we want to be able to clearly show who said what. Second, identification of the parties is not necessary. I don't care who the employer actually is. I just care that they give me requirements and pay my invoices. Similarly, the employer doesn't need to care who I am. They just care that the banking information I send is really from me, for instance.

Now imagine that the employer doesn't know all the details of the project. They have other engineers who know the details. The employer refers me to that other engineer. Again, I don't care who the engineer is. I just care that they are the person that the employer referred me to. Importantly, I don't care who Google, or any other authentication agency thinks that engineer is, or what organisation Google thinks they work for. I care that the employer is satisfied that the engineer is the correct person to talk to. If there is a dispute, then it would be nice to show that I talked to the person the employer told me to talk to.

That's really all I want. To be honest, it shouldn't be that hard to implement. I think it's just that OpenPGP's implementation of WoT is so screwy that people just abandoned WoT without realising that it has use cases.

The example I gave is pretty ordinary, but you can probably imagine situations where one contact (that you don't know) wants to refer you to another contact (who you also don't know) and it's important that you are 100% sure that you are talking to the right person. In some cases, you want to make sure that nobody else is involved in the transaction, because it leaks information. In those cases a CA is really, really bad.

Edit: grammar

> Imagine I am a remote worker who does contract work. I have never met my employer.

In your example, how did the remote worker discover the employer?

What are PGP alternatives for signing a document or encrypting individual files?

Signify: https://www.openbsd.org/papers/bsdcan-signify.html

"but really there isn't much (outside of blockchainia, which is already hipster-deep in modern crypto esoterica) that really demands secure digital signatures."

I won't argue the "there isn't much" part. That might be true. I will add trusted timestamps which were using hash chains before blockchains were invented. Surety is my goto example. Even they jumped on blockchain hype to score some money, though. (sighs)

https://en.wikipedia.org/wiki/Trusted_timestamping

http://www.surety.com

Disclaimer: No affiliation with Surety or endorsement of them. They were just best example I know of company doing this for a long time.

Also, logs and accounting records. Some older papers I saw talking signatures were wanting to keep records from being tampered with over time. Those two are examples where strong, signature technology could come in handy. They mostly defaulted on paper and people, though. Probably a better choice given how computer security played out.

Can you elaborate on what you mean by (1-2) leaking meta-information and making deniability difficult? Do you mean that even when choosing to encrypt but not sign I am leaking definite proof (like a signature) of my private key information in the encrypted message?

That seems hard to believe unless I am misunderstanding you, because my experience is that any private key use requires auth from my Yubikey and yet I can do encryption without my yubikey plugged in at all.

edit: If by deniability you're talking about PFS, then, well, don't sign something you want to be able to deny having signed. I feel your comment might be misinterpreted to be a critique of PGP encryption when really it's a critique of PFS of PGP signatures+encryption.

Your public key is always clear text, or at a minimum your public key finger print (which can be used via a key-server to find your personal information and public key).

So GnuPG to a degree makes it difficult to hide metadata about yourself as many tools will send your public key + data to a key server as soon as they create your key-pair. This is so when people verify you, your easier to find.

This creates a chicken-in-the-box metadata problem where for people to very your public GnuPG public-key is really you that info has to be public, but for anonymity it can't be .

This is all true, but is a different question from deniability when sending messages, and leaking metadata when sending information, which is what tptacek claimed:

> ...in particular, it's difficult to send deniable messages with it.

It's easy (unless tptacek is mentioning an attack I am unaware of) to ensure deniability -- encrypt but don't sign.

Not sure what OP was getting at (maybe the difficulty of deniability using GPG/GPG-encrypted mail defaults), but you'd still be sending to a recipient's long-lived public key.

That's practically different than a system like OTR that has forward secrecy by default.

Since anyone in the world can encrypt to a PGP public key, deniability is trivial. It is true that some systems (like enigmail) also encrypt to your own public key when sending messages, but this is also easily deniable.

You usually want the recipient to be able to verify the sender, but not be able to prove it to a third party. Throwing away authentication entirely is a pretty baby-with-the-bathwater solution to deniability.

I think the assumption is that authentication is bare minimum for a secure messaging system, so "just don't sign" isn't really an option.

Well okay but he said "message encryption"; everyone is reading into that to mean authentication as well but I don't know why we should extend that understanding when a plain reading of his post implies a harsher critique of PGP encryption than warranted. It's also amusing how many people downvoted me for disagreeing with tptacek.

GPG has supported Ed25519 signatures since v2.1

You successfully read half the sentence in which the term "Ed25519" appeared.

Reply on news.ycombinator.com