Hacker News new | past | comments | ask | show | jobs | submit login
P2P, Encrypted Email Protocol (flowingmail.com)
97 points by gbrindisi on Oct 9, 2013 | hide | past | web | favorite | 66 comments

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.

I've actually worked for someone who had a company-wide email filter for credit card numbers and SSNs.

It was frustrating because it would occasionally catch license keys or foreign phone numbers, but probably a good idea for some groups.

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?

How would you prevent this?

It is not prevented by SMTP and not by this p2p approach.

This puts your email in everyone's hands, it's just encrypted so it probably can't be read without the key (yet). Regular email does not do this.

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.

Until you break up and your ex decides to publish your key in revenge. Unlike a password, you can't change a key and revoke access.

Why on earth would you let someone who is not you anywhere near your private key? No security system in the world can fix user fail.

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.

He edited his post and my reply doesn't make sense in context now

Since people share passwords with (at the time) trusted people quite frequently, it seems like a scenario one should plan for.

So its "everyone" for p2p vs "many secret services" for SMTP.

On the upside, it gives every user a good incentive to use good encryption.

But there would be millions of emails. If meta data is concealed, how would the crackers which email is valuable?

As long as it is not possible to crack a proportion of the total traffics, I think it is safer this way.

> 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.

I'm moving on until I see a link to some open-source code.

With a test suite.

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 :)

Unless you're using your real name this should not be a problem. Also many will use this client with VPN/Proxy.

In that respect it's not much better than just anonymously signing up for gmail via a VPN.

This is just an encryption scheme. It does not provide anonymity. Truly anonymous email would not be good for spam.

So it's like Bitmessage, but without an implementation?

I also thought they already had a working client.

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."

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.

Bitmessage messages are encrypted IIRC. I read that bitmessage would fail a security audit but it's still designed to be encrypted.

Message security is actually quite good with Bitmessage -- the issue is scaling the network and correspondingly, its vulnerability to traffic analysis.

Is http://tox.im/ better in this aspect?

and I guess that in x years the encryption will be trivial to crack. then everyone can read everyone else's messages.

I would love to be corrected since I do like the idea.

Care to explain why you think it is a fail?

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?

Every node has a copy of every message. If the whole internet used this, everyone would have a copy of every (encrypted) email.

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:


How much email do you think is sent worldwide each day? How big is your hard drive?

Also the proof of work requirements makes sending messages a battery eating exercise with 5 minute latencies on mobile devices.

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.

That is what Pond does, the client sends a fixed-sized databurst periodically which may or may not contain messages.

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.

SMTP leaks metadata.

Only if the servers aren't using SMTPS. Which in practice many don't but there really is no reason why that cannot be changed.

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.

How does this p2p approach avoid that?

You still need a way to exchange the RSA encryption keys with each sender and receiver.

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.

Is this about re-inventing the wheel again?

http://retroshare.sourceforge.net/ does encrypted p2p for "email"/chat/VOIP/file sharing/forums/etc.

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?

If xmpp would be more secure, it would be a good replacement for email. Using multiple xmpp servers would give a comparable advantage to p2p email.

I wasn't aware XMPP wasn't secure? It supports TLS, SSL, OTR and more. Are there known issues?

The only problem is, that the server can see all messages. OTR solves this problem, but who use it? OTR would even solve the e-mail issue.

XMPP supports signing of messages, and for push notifications OTR is great.

I was under this impression too. I really like Jingle for encrypted voice calls, but if that is vulnerable I'd want to know!

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.

If it's P2P then I'm back to running my own server - and if you run your own server then email is already P2P.

But setting up a mail server is more difficult than firing up a piece of P2P software.

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).

True. But servers have advantages, like being able to get to my email from anywhere. I remember the dark days of POP...

Any proof of concept source code yet?

Retroshare already do that.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact