Speaking of the need for a more secure email, I just want to share an anecdote that blew my mind recently. I was trying to pay for something with a major tech company but they were having problems with my card, so they emailed me my card details to check they were correct!
I'd be tempted to name and shame them, but it's not really their fault as much as it is the specific person, because I find it hard to believe people aren't trained not to do that. Makes me think that all customer support emails should be regex'd for credit card numbers and if they're found their mail servers shouldn't allow them to be sent...
In any case, the whole institution of email is a security nightmare. I doubt this is the solution, but there certainly needs to be one, and as much for "normal" people as anyone else. We all have information that needs to be kept secure.
I've been trying to get some identity documents (birth certificate, marriage certificate) translated recently. Every place I've contacted wanted me to just email them scans of the documents, that will presumably sit on their ISP's server in plaintext indefinitely.
I definitely think there's something to a messaging protocol that's simply not able to be insecure.
In the era of automatic payment processing I can't think of any reason why a member of staff should have access to anything other than the last 4 digits, name and address for verifying it's the correct card
So this allows potential crackers to save every copy of every encrypted email, allowing them to be cracked in the future when there is increased computer power and more advanced cracking techniques/rainbow tables?
On the positive side, it's unlikely "everyone" who isn't a government agency with billions of dollars of taxpayer money to waste has the time, storage, and compute resources to mount the kind of attack you're talking about.
I know NSA is the topic of the day, but they're kind of a special case here. They're the single most powerful and well funded adversary the average crypto user will face.
The difference is when your ex releases your key and you are using this system then everybody can read your email instead of just the NSA and the recipient.
So, what you are saying is that nobody else, but you, should ever have access to your private key, right? I'm pretty sure that's PKI 101, which I think was Karunamon's point; and, I'm pretty sure the solution to your proposed 'weakness' in this system is not technical.
> If meta data is concealed, how would the crackers which email is valuable?
From the protocol doc: "When an email is sent then the email’s hash is added to the DHT in the key that matches the recipient’s address; the mail is then transferred in a BitTorrent like fashion."
How does that conceal metadata? If you dont have plaintext From: and To: fields, it doesnt mean the metadata is concealed. Metadata is not whats IN the communication, it is the data that you collect OBSERVING the communication.
Without special measures to provide anonymity, it is no different than an OTR-encrypted chat or PGP email.
It seems like it would be relatively easy to perform traffic analysis of this protocol. If you can see the traffic of a reasonable number of nodes (as I'm sure the NSA can) then can't you just watch the messages being inserted and retrieved and work out who the sender and recipient is?
Obviously this doesn't help with the content of the message, but in many cases just knowing who's talking to whom is a good part of what you want to keep secret.
You can pretend reading ,say 1M, emails passed by. I mean you can only understand those you can encrypted. But there is no way to analysis which emails have you encrypted through traffic analysis.
The best way to get invisible is to get into the crowd :)
This seems very similar to bitmessage, which has a functioning client and 1000's of active nodes. Why would I wait for this instead of using bitmessage?
Read the Bitmessage white paper and you'll know why you should avoid Bitmessage: Every node will have a copy of every single message sent across the entire network. I believe the meme to use here is "Fail".
This is an erroneous assertion, sending every message to every client on the network was a valid design choice. By delivering every message to every client it is ensured that envelope information (to whom, from whom, etc.) isn't leaked. Even if you can see all of the BitMessage network traffic, you still can't deduce who sent and received a particular message.
They do have an acknowledgement mechanism that may make some level of envelope leaking possible but it's optional on the client side.
If you trust that the messages are properly encrypted, there's no reason to fear distributing those encrypted messages as widely as possible.
Message security is actually quite good with Bitmessage -- the issue is scaling the network and correspondingly, its vulnerability to traffic analysis.
Yes, it's not scalable. Even the Bitmessage creator acknowledges this. They've been at an impasse for quite a while trying to come up with a better system with which to scale.
I realize not reading Bitmessage's documentation is lazy, but could you explain the inability to scale such a system? Is it simply the chicken or the egg dilemma of nobody using it currently (and so, pretty much the same issue BitTorrent originally had)? Or is it some technical reason?
I get that completely. It's just...I don't believe using 4k bit keys would expose the system anytime in my lifetime. I, obviously, could be wrong. But, I think I would take that chance. I was just hoping someone could convince me that I should't (now that I think about it).
These guys are complaining about disk space and bandwidth, not message security.
Even so, the current network can probably handle 100,000 messages a day, and the bottleneck there is some side channel timing attack mitigation code that causes the client to sleep while syncing with a peer. If you separate out the message syncing from the decryption process and eliminate the timing attack potential, the network can easily scale to a million messages a day or more.
At that point, the messages will need to be broken into 'streams' so that you can partition the traffic. The protocol supports this, but punts on the implementation details, so there's no easy way to implement multiple streams at this point in time.
But I would hardly describe that as full-on 'fail'. Everyone-shares-everything is a design feature to preserve anonymity. It's more difficult to tell who sent a message, who received it (if anyone), who was able to read it (if anyone), etc.
Reading more on this software, it seems like they try to solve the capacity/bandwidth problem by using a distributed hash table, but now the protocol requires a lot of handshaking with specific machines that has potential to remove some anonymity, and also potentially makes it easier to prevent a user from getting messages. Block enough traffic at the Great Firewall and you might not be able to get messages. [Take the above listed weaknesses with a grain of salt, I haven't done an in-depth look at the protocol.]
But in general it's probably premature to worry too much about scaling, since the bitmessage network can already handle several more orders of magnitude than the current traffic levels:
BTW, what is wrong with just hiding real activity with an artificial traffic made of random bits sent to random addresses? The only thing I can think of is that bulk senders may get uncovered, but this is actually good for fighting spam.
I've read chunks of the site, but I'm still not entirely clear on what advantage this scheme has over RSA encryption of standard SMTP mail (via PGP/MIME on the local machine, say).
Is the main advantage that a given identity isn't tied to a specific server here? Is that a big enough gain to justify an entirely new protocol and ecosystem of clients? I assume I'm missing some other benefits.
P2P reduces points of failure. Sure, you can encrypt email to your heart's content, but can you trust the server you dropped it with to deliver it? "Why would anyone want to prevent you emailing people?" you ask. Lots of reasons, the biggest of which seems to me to be that if you can't trust encrypted mail to arrive, perhaps you'll abandon it.
If yourserver.com is connecting to friendsserver.com on port 25... there is some metadata. I mean if three-letter-agencies are monitoring the internet they'll figure out what just happened.
Isn't that still an issue for this new protocol? My skim through the site gave me the impression that this system essentially addresses messages to a specific RSA signing identity. I can just as easily choose to do that over SMTP, right? (I'm imagining sending to an SMTP email address encoded in the public signing key.)
This is a nice try. I would like to see some incremental improvements in mail. For example in the header we could display a rating of how secure the mail is. Based use of TLS, etc. If client programs displayed this it would encourage infrastructure improvements.
Thanks for mentioning retroshare, it is a VERY decent system. Still, I reckon there's quite a bit of mileage in doing -one thing- right; retroshare's fix-it-all-in-one-package may not appeal to everybody.
If I understand correctly, there is a key in the DHT that is effectively a list of pointers to all your mail?
If so, an attacker could control your inbox by starting a bunch of nodes around that key, couldn't they?
To disable a persons mail, you would start up some altered nodes around the address space you want to attack, have them respond normally until you control enough or all of the nodes covering the target address.
Then flip a switch that makes them all start saying that inbox is empty. Then start backing off your nodes, and replacement regular nodes would replicate your altered state.
Would this be possible? Or am I missing something?
I've been looking at similar ideas lately, but I simply do not know how to defeat the Sybil attack =/ A centralized certificate authority is necessary to keep a functioning system, as far as I can see.
Not really - setting up a mail server is actually pretty easy if you ignore spam detection algorithms.
Email/SMTP is a very fault-tolerant protocol, which means it's very forgiving to a whole number of different errors that you can make while setting it up.
The problem comes when you account for the facts such as (1) some ISPs block ports commonly used for email; (2) some email providers will mark email from self-hosted email servers as spam.
But none of that is about email/SMTP specifically (and could theoretically apply to any P2P solution that catches on).
I'd be tempted to name and shame them, but it's not really their fault as much as it is the specific person, because I find it hard to believe people aren't trained not to do that. Makes me think that all customer support emails should be regex'd for credit card numbers and if they're found their mail servers shouldn't allow them to be sent...
In any case, the whole institution of email is a security nightmare. I doubt this is the solution, but there certainly needs to be one, and as much for "normal" people as anyone else. We all have information that needs to be kept secure.