Live data from Hacker News

Modern Alternatives to PGP

blog.gtank.cc

251–260 of 261 posts

Re: Modern Alternatives to PGP

#251
post #244
post #239

Earlier quoted context omitted.

The point is anyone can encrypt to your public key, thus, anyone could create a "backup". They won't be able to decrypt it, only you, but still having a backup that you think was created by you but wasn't can be problematic.

Why would you be taking backups created by someone else, of your things? As soon as you've done that, you are already trusting that entity with your items before they did the backup. Would it matter what any metadata is? Consider, you are still in the game I was talking about. Did they encrypt using a secret you know (your public key) or not. If not, it doesn't decrypt. If so, it does. But you still know nothing abou…

Responding to the entire conversation here.

Thread has gone off the rails perhaps because I didn't explain how backup with PGP works. It's very simple: you have a public/private key pair. You encrypt and sign your data with that keypair as both sender AND recipient.

I am confused by the ideas that you would only encrypt without signing. I had assumed that integrity, authentication, and encryption would all be a core part of any secure backup system.

You can verify backup integrity as long as you have the public key. This is useful for monitoring systems. You wouldn't want to stick your private key, unencrypted, on some monitoring system somewhere. Performing a backup requires the private key. That's the price.

Having built this system, I can say that much of what PGP does is saddle you with pointless keychain management on top of what is, conceptually, very simple. PGP authors are actively hostile to enabling people to do things like specify keys that aren't part of your keychain. That, and PGP comes with a bunch of configurable knobs and levers that only serve to sabotage any security that you might have in a more coherent system. It reminds me a lot of using the OpenSSL command-line tools, which everyone would hide behind scripts. Unfortunately, PGP is less scriptable than OpenSSL and you have to resort to wrapping PGP in higher-level language code like Python or Go just so you can extract the status output from a separate file descriptor, because GPG doesn't even have the basic courtesy of providing useful output in its output or status codes. (Look up the --status-fd option for GPG... it's necessary any time you want to do even the most basic operation with GPG.)

Then, if you have systems where you want to do automated backup, you can give them their own keypair. If they are individually compromised they can only compromise their own backups, going forwards.

> So, you are ultimately back to a web of trust. There is almost certainly no getting around that.

I don't even remotely understand this argument. If you could spell out, from start to finish, why web of trust is necessary, then maybe I could understand what you are trying to say.

Re: Modern Alternatives to PGP

#252

Earlier quoted context omitted.

How many people in the industry you know (besides Tech), who use an e-mail client that is neither OS X's Mail or a web mail client?

The most popular email client is outlook. If you don't know that you are already pretty detached from reality.

Just going to leave this here: https://emailclientmarketshare.com/

Also Outlook does not support e-mail encryption out of the box.

It's amazing you had to use a throwaway just to make that statement.

Re: Modern Alternatives to PGP

#253

Earlier quoted context omitted.

Which is now a paid upgrade.

The source is still published and you can build it from source without paying.

I highly doubt non-techie people will want to (or be able to) find the source, install the deps, compile and install it though.

Re: Modern Alternatives to PGP

#254
post #244

Earlier quoted context omitted.

Why would you be taking backups created by someone else, of your things? As soon as you've done that, you are already trusting that entity with your items before they did the backup. Would it matter what any metadata is? Consider, you are still in the game I was talking about. Did they encrypt using a secret you know (your public key) or not. If not, it doesn't decrypt. If so, it does. But you still know nothing abou…

Responding to the entire conversation here. Thread has gone off the rails perhaps because I didn't explain how backup with PGP works. It's very simple: you have a public/private key pair. You encrypt and sign your data with that keypair as both sender AND recipient. I am confused by the ideas that you would only encrypt without signing. I had assumed that integrity, authentication, and encryption would all be a core…

Basically, what you are describing sounds somewhat nonsensical. When you encrypt and sign data to be transmitted to someone else, 4 keys are involved. You encrypt with the receivers public key so that they can decrypt using their private key. Then, you sign with your private so that they can verify it was you with your public.

For this to work, you had to have a way to securely transmit your public key to the receiver and their public key to you. That is what the web of trust facilitates.

If you are in complete control of all locations, then you don't need to do the counter signing. Just indicate what key did the encryption on the other side. When you get it, either you can successfully decrypt, or you cannot. That is, never transmit your private key.

Now, you could self sign, I suppose. Such that you transmit another key to sign against to the remote. But what does that accomplish? If your backup system is compromised, they will have both keys on the remote. The one to encrypt, and the one to sign.

The reason I mentioned private encryption before is there is no need for authentication of data you created. Specifically the key. If you are the only one that knows the pair, then just make sure to keep one side secured. If you are worried it will ever get compromised, just make a new one every time.

Re: Modern Alternatives to PGP

#255

Earlier quoted context omitted.

The most popular email client is outlook. If you don't know that you are already pretty detached from reality.

Just going to leave this here: https://emailclientmarketshare.com/ Also Outlook does not support e-mail encryption out of the box. It's amazing you had to use a throwaway just to make that statement.

So I was correct. Thanks. Indeed outlook is the first desktop client in your list.

Re: Modern Alternatives to PGP

#256
post #152
post #39

Earlier quoted context omitted.

Yes, as the article says, it's a 1990s-style ultra-configurable do-everything design which, in practice, almost always gets deployed in a lowest-common-denominator set of constructions that are themselves mired in 1990s crypto. No modern cryptographic engineer looking at any problem PGP solves would design a system that looked like PGP. PGP used to make some sense as a simple at-rest storage format, but in the era of…

tptacek - What would you consider a good modern way to replace encrypting large text files to multiple PGP keys? That's my main automated use case for OpenPGP in Go. If there is a simpler, more modern way, I'd like to try it... thanks. Edit: We do this, then push the files to a S3 bucket and users can get the files and decrypt them without having to deal with remembering/forgetting static passwords.

Replying to myself... I think I could actually use nacl/box to accomplish this. I'd just have to take care and break the large files into smaller chunks and find a way for users to easily generate and manage keys. OpenPGP sort of makes key mgt easy.

Re: Modern Alternatives to PGP

#257
post #10

As far as I can tell none of these "alternatives" implement what is at least for me the most interesting feature of PGP: web of trust and key servers. It would be really nice to see a modern take on this. > No one was sending you encrypted emails anyway I actually use PGP for e-mailing quite often, for instance: how am I supposed to report security issues without gpg? (please don't suggest Whatsapp...)

>how am I supposed to report security issues without gpg? I’ve never understood this obsession with using PGP to deliver security reports (even a lot of pen testing firms do it). We trust TLS to secure all sorts of remarkably sensitive data, why do we need to add an extra layer of encryption to security reports? It just seems like an unnecessary barrier to delivering the report to me, and the user experience is terri…

Wrong layer? PGP is for person to person(s) communications, TLS is for client to server. Sometimes you can use the latter as a substitution, but not always.

Re: Modern Alternatives to PGP

#258
post #243

Earlier quoted context omitted.

Hm. So you think that libsodium is going to dry up and disappear from the internet in "5 years' time"? Bear in mind that its first GitHub import was in 2013 and that it is used, and supported, by lil' guys like...uh...lemme look at this..."Google". While it's drying up and disappearing, is it going to take with it things like rbnacl which both use it transitively, package it for their environments, and also have some…

> Hm. So you think that libsodium is going to dry up and disappear from the internet in "5 years' time"? Bear in mind that its first GitHub import was in 2013 and that it is used, and supported, by lil' guys like...uh...lemme look at this..."Google". I didn't write about libsodium. I wrote about tools I can actually use to access my data — while writing my own utilities to decode my stuff is fun, it is not necessaril…

> I didn't write about libsodium

You wrote about NaCl and "those fancy 'nacl/box' thingies?", of which libsodium is an implementation; if it's still around, "nacl/box thingies" aren't a problem. Further, libsodium is not by "HN celebrities". This is the modern standard recommended by every single crypto/security professional I know.

Please don't externalize this junk onto other people who may be impressionable.

Re: Modern Alternatives to PGP

#259

Earlier quoted context omitted.

Of your list, the alternatives that George provided check off: - offline encryption - digital signatures - batch processing - no server - offline infrastructure - "hidden recipient" (which, ironically, is a command line flag to mitigate a flaw in PGP, and not in fact a feature of PGP) - multiplatform - easy to integrate - copying and pasting ciphertext - open source and well-tested - not bound to phones - not being a…

My frustration is that a lot of the solutions provided are raw libraries rather than end-user tools. For offline encryption, how do I encrypt a file with a password (or a keyfile)? The solutions provided are a few Go libraries, saltpack (which I think is only a spec? I couldn't find an executable), and then the Keybase service. None of these work as a simple no-strings-attached end-user replacement for `gpg -c`. This…

And https://github.com/postboy/cpwd is a full password manager that uses tarsnap's scrypt. O:-) So at least we know it can be done. The scrypt utility describes itself as a demo with some rough edges, ymmv.

Re: Modern Alternatives to PGP

#260
post #254

Earlier quoted context omitted.

Responding to the entire conversation here. Thread has gone off the rails perhaps because I didn't explain how backup with PGP works. It's very simple: you have a public/private key pair. You encrypt and sign your data with that keypair as both sender AND recipient. I am confused by the ideas that you would only encrypt without signing. I had assumed that integrity, authentication, and encryption would all be a core…

Basically, what you are describing sounds somewhat nonsensical. When you encrypt and sign data to be transmitted to someone else, 4 keys are involved. You encrypt with the receivers public key so that they can decrypt using their private key. Then, you sign with your private so that they can verify it was you with your public. For this to work, you had to have a way to securely transmit your public key to the receive…

The system performing the backup and the system storing the backups can (and often should) be in different locations.

What (I believe) klodolph is describing is that you can self-sign an encrypted backup and give it to an untrusted third party. When you later retrieve the backup you know that it had not been tampered by the untrusted third party.

In this case you have direct access to all private keys involved, so no web of trust is needed. In this scenario you trust a key only if you have created it yourself.

Post reply on HN