NSA-proof email encryption? Cobblers, sniff German hackers German hackers have poured scorn on Deutsche Telekom's plan to offer "secure email", describing it as little more than a marketing gimmick. Deutsche Telekom and partner United Internet are rolling out SSL-encrypted connections between users’ computers and the companies' mail servers as part of the “Email made in Germany” offer …
No, you should never send critical data to other people using a computer. Always pass the message in person.
Back in 1997 I wrote an advanced tool in VB6 called DataEncryptor2000. To normal people or even the security services it looks like a normal email editor, but when you hit send it sends your message to the local printer not the internet, and also prints off a page with a set of randomly generated instructions of how to get the message securely to the recipient.
Eg:
Tomorrow take a train to Paddington Station. Get there for 3:20pm. You will wear a red cardigan. [Recipient's name] will hold a blue umbrella. You will say "where is the nearest post office?", they will say "cloudy with an outlook of rain". You will then hand them the data. The panic word will be "bamboozle".
Then you just have to email the instructions to the recipient. Or you can send it to them using DataEncryptor2000 for double encryption.
I was going to update the DataEncryptor2000 to .Net and release it as open source but then 9/11 happened and the Patriot Act was put in place leaving hackers like me to lay low for a few decades.
So, you encrypt your mail, print it on paper, have to go deliver it yourself to be secure, BUT you send the instructions to the secret via email, in clear. Or, you encrypt the instructions and . . . print them on a printer and get another set of instructions in clear.
In other words, you're in a crowded public area, handing a conspicuous brown envelope to some highly-visible person, loudly saying "TOMORROW'S PASSWORD IS . . . ".
Hmm. Somehow I think PGP is a better idea.
And if you really want secure, just go see the person face-to-face.
"...but when you hit send it sends your message to the local printer not the internet,"...
Might I suggest DataEncryptor2001, same idea but have the message sent directly to the local incinerator. Bullet proof encryption, unless the NSA is using my new SmokeSignalDecypt6000 that is.
Is an email scheme where the email is encrypted/decrypted at the client level and the bulk of the routing is done in a torrent style with random routing and forced splitting ( & routing) so that no one route handles the entire encrypted message.
What is the goal of this system?
1. To avoid the current level of NSA snooping? Because that's at the metadata level (i.e, the e-mail headers). Client-level encryption works on the body of the e-mail (because the headers need to be readable by all parties in order for the e-mail to be routed properly.) Split routing means nothing if the metadata is slurped at the sender's or receipient's server.
2. To avoid deeper searches, such as for stored messages? Client-level encryption is definitely what you need here, but split routing is superfluous. Let's assume for the moment that your encrypted message were consistently routed though a US e-mail server*. Now the NSA has a few hundred of your encrypted emails. How are they going to decrypt them? Well, if you used an up-to-date, well-tested encryption system, and didn't do something stupid like broadcast your private key or repeat several encrypted e-mails in plaintext, they won't.
So why do we need split routing?
* and also that the NSA actually wants to read your boring e-mails.
Maybe combine the split routing with the spam suggestion (AC 13th August 2013 13:47 GMT), which is really a form of chaff. The idea is that since one can't make the fact a message is being transmitted undetectable, at least make it complicated to detect and winnow the grain from the chaff
"Is an email scheme where the email is encrypted/decrypted at the client level....". If the NSA are interested in you then they have the computer resources to either decrypt your messages by brute force, or hack your client device to get the unencrypted message.
".....and the bulk of the routing is done in a torrent style with random routing and forced splitting ( & routing) so that no one route handles the entire encrypted message." I don't see how this helps when the first stage is the complete message going to your Internet gateway (your ISP) where it is promptly intercepted by the NSA. Or they can look at the header, see where it is going, and intercept it at the receivers ISP. And don't think for an instant that the German authorities won't be making use of the NSA's or GCHQ's capabilities when they want to.
But from what I understand the NSA were mainly recording the from and to fields, to see who was communicating, content has always been encoded by various means, codewords etc.
It'd be a bit hard to send a mail with encrypted To Field unless the servers were exchanging keys? this is not what they are doing. this will not stop the NSA seeing who is communicating with who.
"It'd be a bit hard to send a mail with encrypted To Field unless the servers were exchanging keys? this is not what they are doing"
They do exchange keys - most mail servers do talk to each other w/TLS (RFC 3207) - as long as they're set up to, and most are. Actually in a way the discussion is moot: client-server-server-client communication is almost always done with TLS, right now, today.
Here's where the issue is, and CCC have noted it. Whoever is handling your email for you probably stores them in the clear, and worse, is probably somebody like Google who will just hand them off like it's Christmas to the NSA, or the sort of middle scenario where given a warrant regardless of it's legitimacy will hand them over without telling you anyways.
There's actuall no good way to get round the current issue - even PGP crypto'd mail won't hide who you're sending to/when etc.
Spam.
Generate a 'fake' email address, with the username being the recipient's username and some other identifier (so 'bob_jones' becomes 'bob_jones2934'). Then encrypt the name with the recipient's email server's public key so it's nonsensical (x0fj38keo435f325).
Encrypt the body of the message as well, using the recipient's public key and perhaps hiding that in an attachment with stenography. Or linking to an image containing the message.
Then spam it out to a million servers worldwide.
The receiving server will look at it's 'junk mail' list and try to decrypt any nonsensical addresses with it's private key. It'll find the one you've sent coming from a now-sensible address, look up it's address book to find the intended recipient and pass it along to them. There are now 1 million people who've received your email, 999,999 of whom have ignored it assuming it's a Viagra offer. Only one can read it.
By applying other obfuscation methods the NSA would have to try and crack every spam email. They'd have to track down every meaningless or meaningful combination of symbols that could possibly be combined in a way known only to the end user. Follow every single link, and parse those links looking for clues as to whether this even WAS a message hiding something. If they DID find it, they'd need to crack what should be an infeasible-to-crack sized key.
The only thing that could ruin this is behaviour analysis- if you find that 2 nodes are bouncing spam back and forward 10 times an hour it's possibly an email conversation. But again they'd need to know to look for at least one of the servers. With random email addresses at the destination you'd only be able to narrow it down to a per-server level, too. So multiple secure conversations could be taking place.
You know, given the number of spam emails I get anyway, this probably already happens.
Spam. Generate a 'fake' email address...
So stenography for the key with a lot of collateral damage thrown in for good measure. Pretty amusing.
I haven't seen any discussion of peer-to-peer e-mail. I know less about the vulnerabilities and risks involved, but it would seem on the face of it to be a solution to many of the issues using services owned by someone else. What are the drawbacks to such an approach? Would they outweigh the advantages of doing away with an untrusted e-mail provider?
"I haven't seen any discussion of peer-to-peer e-mail. I know less about the vulnerabilities and risks involved, but it would seem on the face of it to be a solution to many of the issues using services owned by someone else. What are the drawbacks to such an approach? Would they outweigh the advantages of doing away with an untrusted e-mail provider?"
Email already is peer-to-peer (at least for Linux/UNIX systems) in theory. If your local machine can speak SMTP and is smart enough to look up the destination's MX record, it can talk directly to the destination (there's no "routing" above the IP level). If you and I both run email servers on our local networks, the only way the spooks will see if is if they're logging all 25/tcp traffic thru the internet (they may well be doing this, I haven't followed this in-depth). The solution to this is to use IPSEC or SSL between the mail systems, which works for a few systems but isn't really a solution for general email-anyone usage because you have to negotiate and trust keys. The other wrinkle is due to spam (or so they say), consumer ISPs started blocking outgoing 25/tcp long ago so you have to send mail thru their SMTP gateway.
Realistically, it's fairly easy to set up a system where you can communicate with a few people rather securely (think https (with the right options) web forum, SSH to a single Linux system, SSL/IPSEC mail as mentioned above, etc.)), but a secure system to communicate with anyone is really difficult.
My experience running SMTP servers on desktops with dynamic IP addresses such as those belonging to cable providers is that a huge portion of recipient systems (all the one's correctly configured, I'd argue) will view the desktop as a spambot and refuse connections from it. The fallback that one has to set in the desktop's SMTP server to get to run correctly in that case is to have the desktop's SMTP server route through the cable provider's SMTP server. That of course, defeats the "Peer-to-Peer" behavior.
For the purposes of the NSA et al they are not (initially at least) interested in your content, they are interested in your communications profile in terms of emails and any or all other use of the internet, If you raise a flag that fits a particular profile you will attract closer scrutiny, if you continue to fit whatever profiles they are looking for then through subsequent levels of scrutiny you will eventually be given free room and board on a Carribean island where much more than just your content will be gone through.
I did some time in the Army during the Cold War, we then had a radio system that frequency hopped and provided reasonably secure open speech.
What it did not do was prevent an enemy detecting our transmissions and then using triangulation to lob a few mortars or other interesting explosives at us within a minute of pressing the button.
This is similar to the NSA, GCHQ etc, at minimum they know where you are and your usage, frequency, volume etc.
Also don't forget it is not just the cloud and emails that are vulnerable drop box use and anything like it is interesting too.
Its not hard doing a client-client encrypted Mail Service, I have been working on a project like this for a while, doing the encryption, connection and address management is really easy, actually.
The BIG problem is the implementation of your encryption, its incredibly easy to overlook a slight mistake in your implementation and your system is WIDE open for abuse. You have heard of Hemlis? Thats one of those candidates, they try to convey the message of security to their users, when in reality they have about as much experience with cryptography as a dog.
They're bound to make mistakes, just like BitMessage or that other one who's name I keep forgetting. If you're unlucky, you don't find the mistake yourself, but someone else finds it, never tells it and sells the 0-Day exploit and makes some money of your now insecure service.
I will probably start again with my project at some point, but thinking that doing cryptography right is easy, is just bollocks.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
