61–70 of 369 posts
Earlier quoted context omitted.
what's wrong with an online system managing the secrets? KMS is great, and makes it easy to separate decrypt from encrypt permissions. (KMS is not the only option! I'm just trying to eke out why you think that's valuable. For example, I think age, mentioned in the blog post, is a direct replacement?)
How do you turn on the online system?
Earlier quoted context omitted.
I don't get what's insecure about normal unencrypted email. It's sent over https, isn't it? It's not like I can read your emails unless I break into Google's servers, no? And even if I do, they probably aren't even stored in plaintext. I just don't get the encrypted email obsession. It's impossible for an individual to withstand a targetted cyber attack so it seems pointless to go above and beyond to ultra encrypt ev…
Are you assuming everyone uses Gmail or do you not know how SMTP works?
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 don't get what's insecure about normal unencrypted email. It's sent over https, isn't it? It's not like I can read your emails unless I break into Google's servers, no? And even if I do, they probably aren't even stored in plaintext. I just don't get the encrypted email obsession. It's impossible for an individual to withstand a targetted cyber attack so it seems pointless to go above and beyond to ultra encrypt ev…
Earlier quoted context omitted.
What specific problem are you trying to solve with PGP? If it's "encrypting files", why are you encrypting those files? What's the end goal? I acknowledge that there are cases that boil down to "encrypt a file", but believe they are a lot narrower than people assume they are.
We encrypt files: - For offsite backups (disaster recovery), mirroring object stores and filesystems to cheap cloud storage. - For encrypting secrets needed for maintaining IT systems (eg. all those shared passwords we never seem to be able to get rid of) - For encrypting sensitive documentation for transfer (email attachment, shared via filesystem, shared via HTTP, shared via pastebin even) Despite the awful UI, Gnu…
But they aren't the same thing. That's the whole point the article is making. Yes, if all you have is a tool that does "encrypt+sign a file", then all crypto problems will look like "encrypt+sign a file" problems.
For backups, tools like restic provide deduplication and snapshots as well as key rotation (and restic works flawlessly with dumb S3-like storage). You can't do that with PGP without reimplementing restic on top of it. Same with TarSnap. For talking to people, you want perfect forward secrecy and (usually) deniability. PGP actively works against you on both fronts. For sending files, there are also other considerations that Wormhole handles for you (though to be honest I haven't used it in anger).
While you can "solve" these problems with one tool, the best way of solving them is to have separate tools. That's the point the article is making.
I would suggest using restic over TarSnap for encrypted backups -- it gives you more flexibility with where your backups will be stored since TarSnap is pretty integrated with Colin Percival's online service and is also unfortunately not free software. But it's also an as-simple-as-possible cryptosystem. Filippo did a quick lookthrough and said that it seemed sane from a crypto perspective[1]. [1]: https://blog.filip…
If you do, "export GOGC=20" can help a little, but it'll still use a lot of memory.
Earlier quoted context omitted.
I don't get what's insecure about normal unencrypted email. It's sent over https, isn't it? It's not like I can read your emails unless I break into Google's servers, no? And even if I do, they probably aren't even stored in plaintext. I just don't get the encrypted email obsession. It's impossible for an individual to withstand a targetted cyber attack so it seems pointless to go above and beyond to ultra encrypt ev…
In modern practice, email is sent over TLS sockets already. Any good email client should prohibit you from using SMTP, POP, or IMAP with TLS, and for the past few years, even the MX-MX transfers in the backend have started to become protected (albeit mostly opportunistically at this point, I believe) with TLS. So the only people who can read email are you, your counterparty, your ESP, and your counterparty's ESP, ass…
One further note is that you can know post-hoc if an email was delivered to Gmail via TLS by the presence or absence of a red lock in the Gmail app or web UI.
Earlier quoted context omitted.
> E-mail is fundamentally terribly positioned to do secure messaging E-mail is fundamentally a way to send a sequence of bytes somewhere (untrusted) so they can be picked up later by someone (trusted). That’s also literally what Signal is built on so I think you’re overstating the difference.
Secure messaging is much more complex, but here’s a simple example of how that’s not true: TCP is bidirectional and email is one message, fire and forget. That immediately affects your ability to have forward and backward secrecy.
E-mail is store-and-forward just like TCP is; how do you think an IP router works? TCP is fully duplex; a tx doesn’t wait behind an rx, exactly like an e-mail reply not waiting behind an e-mail receive. The only difference is that a router will typically use volatile memory to store messages before they are sent but e-mail will typically use disk.
If your security model relies on this difference then your security model is broken. It’s worth noting that Signal does NOT rely on this difference. It relies on participants being mostly online to permit frequent rekeys and not having to retain old keys indefinitely.
Earlier quoted context omitted.
Are you assuming everyone uses Gmail or do you not know how SMTP works?
You might be surprised just how many mail providers support STARTTLS for email, at least opportunistically. https://www.fastmail.com/help/technical/ssltlsstarttls.html
the problems with email are that, no matter how sure you are that the connection between you and your mail server, and your local and server storage, are secure, the parties you may be interacting with are not. And then, as is talked about in the article, your recipient forwards the mail as plaintext...
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…