P2P, Encrypted Email Protocol
flowingmail.com
flowingmail.com
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.
It was frustrating because it would occasionally catch license keys or foreign phone numbers, but probably a good idea for some groups.
I definitely think there's something to a messaging protocol that's simply not able to be insecure.
It is not prevented by SMTP and not by this p2p approach.
On the upside, it gives every user a good incentive to use good encryption.
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.
As long as it is not possible to crack a proportion of the total traffics, I think it is safer this way.
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.
With a test suite.
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.
The best way to get invisible is to get into the crowd :)
The wording is misleading:
"FlowingMail is the name of a new decentralized messaging protocol, while FlowingMail Client is an email client that uses the protocol."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:
I would love to be corrected since I do like the idea.
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.
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.
http://retroshare.sourceforge.net/ does encrypted p2p for "email"/chat/VOIP/file sharing/forums/etc.
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?
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).