No peer-to-peer encryption leads to de-anonymization

[godel9]

Maybe I'm wrong, but there doesn't seem to be any encryption between peers. If this is the case, then it's trivial to determine the public key associated with a given node. A passive observer can look at all incoming and outgoing traffic from a node and de-anonymize rather easily. Simply wait for the node to send out a pubkey object which was not sent in. Similarly, you can look for new getpubkey objects to determine who that node is talking to. Adding simple encryption between peers with Diffie-Hellman key exchange and AES or something similar would solve this problem.

[GeneralZero]

Read the Whitepaper
https://bitmessage.org/bitmessage.pdf

[godel9]

I have. Are you referring to the "passive operating mode" as the peer-to-peer encryption? The whitepaper gives the impression that having some members of the network using passive mode provides deniability for those who do not, but this is not the case. In fact, it paints a target on the back of anyone not using passive mode.

There is a simple way for a passive observer to determine if a node is in passive operating mode. Again, we monitor the incoming and outgoing traffic to locate new messages being created by that node. We can't determine the destination of that message, but we can determine the size of the content of that message. Since the pubkey, getpubkey, etc. objects are of fixed size, the size distribution messages coming from a node in passive operating mode will be biased towards those numbers (plus the overhead of an encrypted payload).

It's a lot simpler to just use inter-node crypto when forwarding messages, and helps reduce the overall bandwidth usage. But, if you really want to stick with the passive mode, make it compulsory and add random padding to the messages to evade traffic analysis.

[stevedekorte]

godel9, AFAICS the only way to protect the id of the source of a message from someone monitoring your ISP traffic is to use Tor.

[godel9]

stevedekorte: the Bitmessage homepage clearly says that Bitmessage "aims to hide 'non-content' data, like the sender and receiver of messages, from passive eavesdroppers." And its certainly possible: there are a wide variety of anonymous routing techniques available, including Tor, Freenet, I2P, Mixmaster, Mixminion, Tarzan, Crowds, etc. But if Bitmessage doesn't provide basic anonymity, I don't see the advantage in using it.

[stevedekorte]

godel9: how is anonymity (the geolocation of the source) not protected if Tor is used when posting a new message?

[godel9]

stevedekorte: Sure, using Tor there gives you anonymity. But then what's the point of using Bitmessage when I can just use Tor? And this project doesn't use Tor routing to send messages, so the claim that this program will, out of the box, provide anonymity is rather dishonest.

[stevedekorte]

godel9: I'm no expert here but some advantages I see are 1) Tor doesn't protect the endpoint 2) Tor doesn't solve the problem of receivers which are infrequently online or unreachable via sender initiated requests. Basically, Tor can't implement something like email/twitter/usenet/etc and BM can.

[godel9]

stevedekorte: Those are valid complaints for using Tor, and Tor isn't optimized for email-type applications. However, there are Mixnet protocols (namely Mixminion) which not only provide anonymous email (with endpoint protection/pseudonymous messaging and handling for infrequently online clients) but also have academic papers proving strong anonymity. And, Mixminion allows communication from a Mixminion pseudonym to simple SMTP, which isn't possible in BM. So why dick around with a protocol which has NO formal guarantees when we could just re-implement a proven system?

[stevedekorte]

godel9: I haven't looked at it but anything based on email sounds federated, not decentralized. Also, most other systems I've have seen fail to solve the spam problem (lack POW) or the incentives problem (require people to long term store data they don't care about). Also, does Mixminion hide the geolocation of the receiver like BM does? Does it support public channels like BM does?

[godel9]

stevedekorte: Mixminion is not truly federated, but is more along the lines of a two-tier structure like Tor. And it provides essentially everything BM does. Spam isn't as much of an issue because the entry mixes can just perform rate-limiting based on IP (though they also include a way for you to block addresses, preventing them from sending messages to you). As for public channels, that can be fairly easily accomplished using trivial secret sharing. Check out the whitepaper: http://mixminion.net/minion-design.pdf . (BTW, THAT is what a whitepaper should look like: formal guarantees, full threat analysis, and citations of actual academic papers, not NYT and Wired articles)

Actually, I'd be fairly interested to see if Mixminion could be augmented to include the idea that the address is the hash of the public key like in BM. It could very well simplify some things.

[tameit]

This problem is quite well known and even some work was started to implement it: dup of #264

[godel9]

tameit: Can you reference any pull requests or commits which implement secure sockets?

[tameit]

That would be commit 91c5c71
As I said, the work was only started. It stopped because of backward compability issues: no one would talk with an encrypted socket. Atheros offered to use a bitmessage service flag in the version message #264 (comment) but noone kept implementing it, although all agree that it would be very usefull.

Any way, I suggest to close this issue and continue discussing there.

[tameit]

After a very brief glance at mixminion I understand that it is both stalled and not operational. Furthermore it claims to be : "the standard implementation of the Type III anonymous remailer protocol, which lets you send very anonymous email."mixminion/mixminion@35b33d9 But if it just anonymises emails they are still not encrypted. And Bitmessage acknowledges that hiding meta-data is difficult but it succesfully encrypts messages with much more ease of use for the user than pgp (in my humble opinion).

[gits7r]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2/23/2014 1:27 PM, tameit wrote:

After a very brief glance at mixminion I understand that it is a
remail that Mixminion is both stalled and not operational.
Furthermore it claims to be : "the standard implementation of the
Type III anonymous remailer protocol, which lets you send very
anonymous email."mixminion/mixminion@35b33d9
mixminion/mixminion@35b33d9

But if it just anonymises emails they are still not encrypted. And
Bitmessage acknowledges that hiding meta-data is difficult but it
succesfully encrypts messages with much more ease of use for the
user than pgp (in my humble opinion).

— Reply to this email directly or view it on GitHub
#648 (comment).

If all this can be simply avoided by using encryption between peers
like AES with DH Key Exchange - why isn't it just implemented and that
is it. Obviously it cannot make anything worse if we will use
encryption between peers. All peers should upgrade to latest version
and talk encrypted to other peers.

I think this should be a milestone, for the next release.

---

PGP Public key: http://www.sky-ip.org/s7r@sky-ip.org.asc
ICQ #: 556561918
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJTCi5BAAoJEIN/pSyBJlsRe1kH/3iGLskyvUm0pLWiWgToPYSs
V0JaTDsmJRQUqoQg20t3fYE388MhKaBLsbJxebHoYs3f5GafRNAPSvMqDYFKXUpV
smsRkAF2Y4NzbxJEUuSmfCIhd+1vgd7+4Yjm0WtPERXPXts6SSwcda7gFeULRQGZ
SKSJSwmSOLxhzp75wOnf0HXA+CKAjFRvv1nAOM/rmrYorzxa2CzQHNzO2+wQSgMI
iv1PDp+lNoTKKkUJTQEZ8dTbG7hoq9g1uFy6vs+E0+YwVNzIzTqC7BvYxnSwwIYf
fSyBSpZ0D58jx67aJuIYGK059F/qTGXQzzcNvL8EM/9zER6MTlyMZ31hsn7t628=
=r7Ka
-----END PGP SIGNATURE-----