I highly doubt that any commercial company is going out of their way to store encrypted conversations and working on quantum computing to break those conversations in order to train AI. There is no way that this is a cost effective way to train AI, and there is no way that this will be more legal or considered more ethical than scraping public facing websites (even if those websites request not to be scraped).
That said, of course “capture now, decrypt later” attacks are a concern! I would probably bet against companies planning to do that for the purpose of training AI, but I would not bet against governments doing that for other reasons :). This is why post-quantum cryptography is being rolled out now (albeit slowly, it’s still rare). As an example OpenSSH defaults to using post-quantum algorithms for key exchange ever since the 9.0 release. It uses a mix of the NTRU Prime + X25519 ECC algorithm for key exchange, so it is guaranteed to not be weaker than normal ECC cryptography, even if the NTRU Prime lattice cryptography proves to be horribly broken. Once the key is exchanged the symmetric cipher used for the connection is also assumed to be quantum resistant. If quantum computing becomes a serious concern you will have to retire your old RSA / ECC SSH keys, but they are only used for authentication at the moment (so it doesn’t matter if this cryptography is broken in the future), not for encrypting any of the “real” content between devices — all of that is likely quantum resistant as of more than a year ago. Most of what you do on the internet, however, is still vulnerable and could be captured to be decrypted later… But I suspect we will slowly see things move over to post quantum cryptography transparently over the years.
It is not known when or even if we will have quantum computers capable of breaking RSA at common key sizes. There are concerns about whether it will ever be viable, and if it is who knows what the cost to run it will be (it may only be viable for targeted attacks, and not decrypting all internet traffic ever… If it’s expensive and takes hours or days to break a single key it might not even be super effective for decrypting old messages in protocols where keys are renegotiated frequently, like with Signal). I wouldn’t be terribly surprised if we never have quantum computers effective at this (though I’d probably bet for it to happen rather than against it), and I wouldn’t be terribly surprised if there already is one somewhere kept secret (though I’d probably bet against this being effective for decrypting an entire population’s messages?). I don’t actually have much insight over the feasibility of large scale quantum computers, though, so take that with a grain of salt. At any rate… You probably don’t have to worry too much about it as a looming threat right now, there are likely far easier ways to attack you now.
The guarantees in cryptography are super weird. It’s kind of odd, but in all of the cryptographic algorithms we use today… We don’t actually know how hard the problems are? Symmetric ciphers are generally thought to be more secure than public key cryptography, but it’s a bit easier to see how hard public key cryptography is to break (at least in my opinion). With RSA for instance you know that if you can factor large numbers efficiently you can break apart the keys, but with AES we kind of just hope we mixed things up good enough that it’s hard to reverse without the key. But what’s kind of funny is that we just think that factoring large numbers is hard, but we don’t even know if it’s an NP-complete problem — it’s probably an easier problem, and even if P≠NP it could be the case that there’s an efficient polynomial-time algorithm to factor large numbers. It’s not entirely out of the realm of possibility that there is just some math waiting to be discovered that would break these algorithms on a classical computer, and there’s a non-zero chance that it is already known and kept secret (though this is probably unlikely).
I’m not sure I’d consider it a losing battle at all. It’s certainly possible for there to be weaknesses in modern day cryptography, but in general it has stood up remarkably well over quite a long period of time so far. The possibility of quantum computers makes things like RSA and ECC a little dicey in the long term, but we’re already working on post-quantum cryptography and are starting to deploy it. Assuming that those algorithms hold up there’s a good chance that if quantum computing is ever practical we will be ready for it. There’s a good chance that you are even using post-quantum cryptography now in certain situations (e.g., recent versions of SSH uses post-quantum cryptography for key exchange).
Most people do not decide what cryptography they are using. I’m not really worried that in 50 years I’ll be using something dated for most stuff as long as I’m using modern software. The most likely case where this could matter is for something like SSH or PGP where you are manually managing your own keys… When RSA and ECC keys are no longer considered secure that will be pretty big news, and you’ll probably hear about it, but there’s also a good chance that the software will be updated and provide warnings that you should generate new keys too?
Yeah. There’s an attack that roughly halves the effectiveness of AES, but symmetric encryption is thought to be safe overall. If it’s not we’re super fucked.
Fair enough! I always get the ECC and lattice stuff mixed up too. ECC isn’t really all that different from RSA. The key sizes can be smaller for the same strength and it’s more efficient, though. This mostly benefits servers that will be handling a lot of encrypted connections AFAIK.
I’ve been running nsd and it’s great. So sick of using web interfaces to manage DNS records. I think you need a bit of extra magic for dynamic dns with nsd, though.
If you’re at the point where you’re hosting your own server / VPS with a static public ip, though, you might be better off setting up a VPN like wireguard to connect to your local servers, and if you want things exposed to the public internet you can always proxy over the wireguard connection on the VPS. Then you wouldn’t need dynamic DNS at all, and you can limit the exposure of your services to the internet if you so choose.
Okay, I got curious and looked into it… These are the relevant files for the “RAM shredding”
- https://github.com/mollyim/mollyim-android/blob/d7997fceb68696582fea0cbf3f8dd0e0af64e8b2/app/src/main/java/org/thoughtcrime/securesms/service/WipeMemoryService.java#L102
- https://github.com/mollyim/mollyim-android/blob/2f2b603faaa2f6db20cd9e654b5ac1635b9a9353/jni/utils/org_thoughtcrime_securesms_service_WipeMemoryService.c
I’m not an Android dev, but at first glance it looks like all this does is try to allocate all of the free memory in the system, and walks through the pages and uses rand() to fill in all of the bytes. Technically it’s possible for the pages returned by malloc to contain old data, but only if it was allocated by your process in the first place (maybe that’s not the case on Android?)… So I guess the idea is that if Molly itself is compromised and an attacker is able to allocate memory in the Molly process they could conceivably get an old page from memory and that page might contain secrets from the Molly app itself… But at that point, surely you’re fucked anyway, and the attacker can presumably read all of the currently allocated memory which is certainly far more of a security concern anyway? I just don’t think it’s worth the cycles.
The RAM shredding feature seems kind of silly to me, but I don’t know the details. Ideally the operating system should clear pages before giving them to other applications… While I can see the appeal in also doing it in the application, it seems kinda wasteful, and I wouldn’t trust the application to do a good job of that anyway. If the point is to prevent the app itself from leaking private keys on a buffer overflow or whatever… I guess I can see the value of that, but I’d rather see mitigations for the buffer overflows highlighted instead. I guess this just makes me a little suspicious of the actual value provided by the app.
Relying on a centralized service can still be problematic. If nothing else it’s a central point of failure, even if you don’t have any particular privacy concerns due to the usage of end-to-end encryption. Signal also relies on Intel SGX for some of their privacy features on the server, which is somewhat dubious. AFAIK this is currently mostly used for contact discovery, which would otherwise be an even worse situation, but it has seemed in the past like they were interested in expanding this, though maybe that’s just all speculation. Regardless, my main concern with signal being centralized is that you have a lot less control over your chat. Signal can change on a moments notice and it’s all just gone.
Okay, so I did some research to confirm my previous understanding and for the sake of completeness I just wanted to throw this information into this thread… Neither DNSSEC/DANE nor MTA-STS is required. AFAIK none of the huge e-mail providers like Gmail, Outlook, or iCloud implement DNSSEC/DANE, but protonmail and tutanota both do. Of those everybody implements MTA-STS, except for iCloud.
In the case of e-mail both of these aim to alleviate a big security flaw in e-mail, which is that when Alice is trying to send you an e-mail, Alice’s mail server has no clue whether or not your e-mail server supports TLS (e-mail is older than TLS, so it’s bolted on in an opportunistic fashion)… As a result if somebody can get in the middle of Alice’s mail server and your mail server they can say “hey, I don’t support TLS”, and then Alice’s mail server will just say “okay, fine, here’s the e-mail unencrypted”. Obviously such a downgrade attack is BAD, so DNSSEC/DANE and MTA-STS are attempts to prevent this from happening.
DNSSEC/DANE solves this problem because it guarantees that DNS records are legitimate and it can guarantee whether or not a DNS record that says “hey the mailserver supports TLS” does or doesn’t exist. The disadvantage of this is just that it relies on DNSSEC, which has its own caveats.
MTA-STS attempts to mitigate the problem… With MTA-STS you add some DNS records that say “hey, look up the MTA-STS policy from this HTTPS server”, and the HTTPS server provides a file that says whether or not the mail server requires TLS connections to prevent downgrades. This always bothered me, though, because if somebody can attack DNS this arguably gives you very little… And if somebody is in the position to block HTTPS traffic they can prevent the policy from being fetched as well. Theoretically this doesn’t provide much of a guarantee, but I guess in practice it’s probably a decent mitigation because if a policy has been fetched before there will be a cached version available, so you’d need a sustained or well-timed attack to break MTA-STS, and on the plus side they can’t generate a bogus policy file to disable TLS connections to the mail server unless they can get a valid TLS certificate for your domain.
Either way, both of these things are pretty much entirely about receiving e-mail, and aren’t spam mitigation measures, so they shouldn’t have anything to do with your ability to send e-mail (which is the harder part). It matters for sending in the sense that you don’t want e-mail that you send to other mail servers to get downgraded from TLS when it shouldn’t either, which means your mail server should validate MTA-STS + DNSSEC/DANE for mail servers that you are sending mail to. Ideally you would set up DNSSEC/DANE and MTA-STS in order to prevent this class of attacks on your personal e-mail, though it’s not strictly necessary. MTA-STS is pretty trivial to set up as long as you already have an HTTP server on hand to serve up the policy file (which you probably do). DNSSEC may be a heavier ask for people depending on TLD support, registrar support, nameserver support, and software support (a lot of the DNSSEC signing software coughldnscough seems to choke on certain RRs -_-), but this may be easy for many people to implement.
No you’re right, I shouldn’t discourage, just wanted to warn it’s not the same as most other self hosting projects, where often you just need to spin up a docker container.
Yeah, this is very fair! I just wanted to also provide the other perspective. Self hosting e-mail is very doable, and I think there are some things like mailcow / mail-in-a-box that make setting up the software on the server a lot easier (I haven’t used these, but I’ve heard good things)… But you’re probably still going to have to double check your rDNS and make sure to add the appropriate DNS entries… And you might not even realize that you have to do that, and then you’re like “why the hell can’t I send e-mail to anybody”, and it’s not the easiest thing to debug (especially if you haven’t set up DMARC entries for getting reports from other mail servers). Plus… If you get the DNS entries wrong it can be a pain to wait for the TTL to expire to make changes. The setup definitely isn’t without its headaches and hassles, but it’s not impossible and once it’s good to go you probably won’t have to change anything.
FWIW hasn’t DNSSEC/DANE been added to the prerequisites these days or is that still optional?
This is currently optional afaik. I believe you can use this to establish that your e-mail server accepts TLS so other mail servers can know not to downgrade to an unencrypted connection. Admittedly, I’m not super up to date on this, and I’m slightly confused about the differences between MTA-STS and DANE. Also fwiw, I think both of these solutions mainly impact receiving mail, and shouldn’t make much of a difference if any for you sending mail to the big providers.
I think if somebody does want to self host email we really shouldn’t discourage them. It’s a bit more complicated than somebody might expect going in, but you really don’t need that much to get everything in a working state, and it’s something that will get better the more people do it because more people will write tools and guides and make saner defaults, and large mail companies will have to take independent mail servers more seriously.
Totally cool if it isn’t for you of course, and people should be aware that it’s important to set up rDNS, dkim, DMARC, and SPF (most of these are just simple DNS entries that you need that help with interacting with other mail servers), because otherwise their emails are going to be sent to the spam zone… But these are not insurmountable obstacles if you really do want to do it!
These days almost every mail server will send mail over tls, but it’s not a guarantee which is a little unfortunate. Like you say there’s always privacy concerns with email, unfortunately.
I think in terms of privacy it really depends what you care about and what you’re using it for. If you care about Google reading your inbox, then self hosting can in theory help (at least for emails where the other party isn’t on Google or whatever)… Personally I like the idea of Google not knowing every company that I have an account with and everything I order online, which is information that’s definitely in your inbox. If you care about obscuring who you are to services that you sign up for with email, then arguably self hosting is not ideal because you’ll be the only one using that domain for email, and you might be better obscuring yourself through something like Apple’s “hide my email” service (which of course means you trust Apple to see those emails instead).
If you have more serious concerns and are having conversations that you don’t want anybody other than the recipient to know about email is probably the wrong choice for that conversation, but PGP is a decent option in these cases, albeit too clunky for most people. You may consider other services like protonmail or tutanota, but there are concerns with these services as well (eg, protonmail gets some flack for not encrypting metadata like message subjects, which is a big deal) and again there aren’t necessarily good guarantees for anybody you’re talking to on gmail or whatever.
Personally I like self hosting my email because of the flexibility that it offers and the price. It’s nice to be able to have as many email accounts as I want and it’s cheap to host, and I enjoyed learning about it and setting it up. My personal inbox is out of the hands of giants, but obviously if I’m emailing normal people it’s probably going to be available in the clear to Google or Microsoft (which is likely the case regardless of your solution). That’s not ideal, but it’s the reality right now with email. I kind of think of email more like a Twitter account or something at this point. It’s a semi-public way for random people to get in touch with you and a lot of conversations might be kind of explicitly public like on mailing lists, or something more akin to talking to a colleague in a public space — not super private, but a convenience, I guess?
I’d still recommend that people do try to self host their email if they’re thinking about this. Independent mail servers seem like a healthy thing for the web and learning more about it will give you a better sense of how secure / private your emails really are. Things like protonmail seem to have some advantages, but I also get some weird vibes from them and I’m not sure how much of a privacy increase they really give if you aren’t talking to other protonmail users and stuff anyway.
I consider marketing something as “for free thinkers” as a huge red flag.