Live data from Hacker News

The PGP Problem

latacora.micro.blog

231–240 of 369 posts

Re: The PGP Problem

#231

Earlier quoted context omitted.

No, email is not bidirectional. You send an email, the recipient later opens it. Sure, the recipient's SMTP server might respond right away with an ephemeral key you can use to enjoy forward secrecy, but that server has to store the message for the recipient to retrieve later. You can't have full forward secrecy with email as it is used today. If you want forward secrecy with email, you need three emails sent in rapi…

> you need three emails sent in rapid succession This is partially correct, but they do not need to be in rapid succession, and therefore Bob does not need to be online.

Alice's ephemeral private key must be kept as long as the whole handshake. Bob's is a bit shorter (between the last two messages).

If the messages are slow to come, those ephemeral keys become less and less ephemeral, and could actually be stolen.

Re: The PGP Problem

#232

I understand that there are better tools for encryption, but is there anything that replaces the identity management of PGP? Having a standard format for sharing identities is necessary in my opinion. If I have a friend (with whom I already exchanged keys) refer me to some third friend, it would be nice if he can just send me the identity. Sending me the signal fingerprint isn't a solution for two reasons: - I don't…

The CA system is strictly better than PGP for identity management in every respect. People often think it must be the opposite but this is essentially emotional reasoning: the Web of Trust feels decentralised, social, "webby" un"corporate", free, etc. All things that appeal to hobbyist geeks with socialist or libertarian leanings, who see encryption primarily through the activist lens of fighting governments / existi…

The CA system as set up today is a bit fragile and much too limited, though. If it was all we needed, everybody would be using S/MIME with signed certs.

We need something more expressive than the current CA system, where you can make the choice to define your own trusted roots.

Re: The PGP Problem

#233

FYI, Robert J. Hansen's comment in gnupg-users@gnupg.org.[0] 0) https://lists.gnupg.org/pipermail/gnupg-users/2019-July/0623...

I don't understand how these represent "mistakes", let alone "serious mistakes". But I'm glad he liked it.

It's over my head, but I thought that a reference would be useful. Given that the mail list thread references HN.

Re: The PGP Problem

#234
post #115

The pass password manager uses PGP, what would be a better design?

Pass is an interesting case, because of how it's implemented. The easy, obvious answer would be "a version of pass that uses libsodium (or Jason's own crypto library) instead of pgp", but there's no command line for those tools, and the only other command line widely available for cryptography is OpenSSL's, which is horrible.

Re: The PGP Problem

#235

Earlier quoted context omitted.

Is it wrong to use openssl to encrypt files? 0. (Only once) generate key pair id_rsa.pub.pem, id_rsa.pem 1. Generate random key openssl rand -base64 32 > key.bin 2. Encrypt key openssl rsautl -encrypt -inkey id_rsa.pub.pem -pubin -in key.bin -out key.bin.enc 3. Encrypt file using key openssl enc -aes-256-cbc -salt -in SECRET_FILE -out SECRET_FILE.enc -pass file:./key.bin -- other side -- 4. Decrypt key openssl rsautl…

To start with, none of that encryption is authenticated.

So if I understand you correctly (Noob here), Alice would need to sign the pair (key.enc, file.enc) to authenticate that those files originated from her.

Without that, Bob could potentially receive any pair of (key,file), which would just decrypt into garbage data.

BTW, variations on that sequence appear all over the internet when searching for "openssl encrypt file with public key"...

Re: The PGP Problem

#236

So what do I use for encrypted messaging that can, like, replace email, then? Nobody seems to have provided any sort of satisfactory answer to this question. To be clear, an answer this has to not just be a secure way of sending messages, it also has to replicate the social affordances of email. E.g., things distinguishing how email is used from how text-messaging is used: 1. Email is potentially long-form. I sit dow…

I strongly agree with this; email is not instant messaging, and there is not yet any secure replacement for email.

We need a modern design for a successor protocol to email, and no one is working on it because they prefer instant messaging (or think other people do).

Re: The PGP Problem

#237

Whent talking about alternatives, Signal and WhatsApp get mentioned because they're easy to use. They are. Signal is pretty secure. WhatsApp probably is as well but we can't be sure. That is, until it isn't anymore. WhatsApp already has a key extraction protocol built right in for its Web interface. Signal has a web (Electron) interface as well, and a shitty one at that, where the messages also get decrypted. For Wha…

I think the real problem is that nobody has ever created a decent PKI, and I doubt a sufficiently secure PKI is even possible. CAs require you to trust people that aren’t supposed to be party to the communication (trust both not to be hostile, and not to be insecure themselves). All other forms of PKI offer entirely impractical authentication mechanisms. With signal and the like, your options are 1) Verify keys by be…

Signal PKI doesn't really work for me, conceptually. I mean, Signal is great work, but the approach to key management and federation seems like it undermines the regular security of the approach.

The problem is the key servers are run by the same people who control the app. This helps if the key server specifically gets compromised and the target is verifying, but for many attacks people worry about it's actually not the key servers specifically that get popped, it's an employee laptop or the employee themselves via subpoena, policy change etc. And for those cases nothing stops the app itself being changed to show you a false safety number, possibly by Apple without the app vendor even knowing.

So we end up with a rather curious and fragile threat model that only really helps in the case of a classical buffer overflow or logic error that grants an adversary the ability to edit keys and not much else. It's very far from "you don't have to trust the providers of Signal" which is what people tend to think the threat model is.

And honestly, a technique that combats very specific kinds of infrastructure compromise are too low level IMO to bother advertising to users. The big tech firms have all sorts of interesting security techniques in place to block very specific kinds of attacks on servers but they generally don't advertise them as primary features. If you have to trust the service provider, and with both Signal and WhatsApp you do, then are you really getting much more than with bog standard TLS? After all forward secrecy achieves nothing if the router provider is diligently deleting messages after forwarding them to the receiving device - the feature only has value if you assume the provider is recording all messages to disk and lying about it, in the hope of one day being able to break the encryption of ... their own app. Hmmm.

Re: The PGP Problem

#238
post #47

Earlier quoted context omitted.

Signal does a great job of supporting activists. That's basically its intentional product focus. Everything an open source proponent engineer might want to promote is secondary. The focus on activism and trying to deal with large actors definitely looks like #1. Everything else about their product is secondary to that. Signal's product focus has been at best un-encouraging to those who want to use it for anything els…

> Signal does a great job of supporting activists. I don’t think it practically achieves this. Even now, Signal is an unreliable platform to communicate with. One can’t be sure if the message will reach in a timely manner (like a few seconds or several seconds) or even reach at all. The UX and feature set are also far behind something like Wire. I’ll accept that Signal has a strong and reputed protocol, and has take…

Signal is beholden to the whims of Google due to their reliance upon the google cloud messaging stack. All messages are delivered based upon something outside of their control (whether Google decides they have enough priority to wake the modem). If you are on your phone all the time and have signal open it is usually instantaneous but say your phone is usually dormant it can be hours before a notification pops up. I'm not sure how different the situation is on iOS or if this is even avoidable with the current mobile duopoly. I find that the unreliability of signal precludes exclusive use of it so I tend to route a lot of communication through SMS via signal or double send. This is not high security stuff. It does seem like a relic of our age that chat is considered the preeminent form of communication. I think long form and long lasting texts like e-mail are valuable but maybe I'm just long-winded.

Re: The PGP Problem

#239

Earlier quoted context omitted.

I don't understand how these represent "mistakes", let alone "serious mistakes". But I'm glad he liked it.

It's over my head, but I thought that a reference would be useful. Given that the mail list thread references HN.

Oh, no, sorry, I'm glad you posted this; I wouldn't have known where to look. Thank you!

Re: The PGP Problem

#240

Earlier quoted context omitted.

To start with, none of that encryption is authenticated.

So if I understand you correctly (Noob here), Alice would need to sign the pair (key.enc, file.enc) to authenticate that those files originated from her. Without that, Bob could potentially receive any pair of (key,file), which would just decrypt into garbage data. BTW, variations on that sequence appear all over the internet when searching for "openssl encrypt file with public key"...

No, the problem is that the AES encryption step uses bare AES-CBC. An attacker can flip bits in the ciphertext to make targeted changes to the plaintext. What you want is an authenticated encryption mode, but I don't know that the OpenSSL cli supports any of them.
Post reply on HN