
Bitmessage – Send messages without leaking metadata - 3pt14159
https://bitmessage.org
======
natch
Nice. One feedback for the maintainer of the OS X instructions: in the compile
from source section, instead of giving the command line for installing
homebrew (which by the way renders incorrectly with an emoticon on that wiki
page) the best practice is to provide a link to the homebrew project page,
because the command line may change, and because they don't want things like
typos or emoticons getting in the way of people getting brew installed.

~~~
SectioAurea
This is an excellent point. I know I've been guilty of the pattern: "provide
detailed directions for a poorly documented build, then spend years
maintaining them in blog post/comments".

Better would be to actually contribute to central project documentation, I
suppose.

------
ma_mazmaz
According to the white paper, "all users receive all messages." How, then is
the system scalable to a large network?

~~~
benregenspan
The whitepaper proposes to handle this by having nodes join separate clusters
once their databases reach a certain size.

~~~
synctext
Please consider this a security review by a tenured P2P professor:

The whitepaper describes a simple and focused system relying on partitioning
in an attempt to preserve scalability.

Bitmessage has many architectural similarities to Usenet and also offers no
valid response to spam. Using a proof-of-work system to combat spam is
proposed, but to-date science has not yet seen a working approach anywhere.
Details are missing on this vital element plus defenses against the Sybil
attack are missing from this design.

Mechanisms such as the "averageProofOfWorkNonceTrialsPerByte" in this system
only slow down attacks and do not stop them. Check the impossibility proof by
Harvard to see that systems like Bitmessage which react to any message cannot
build an effective Sybil defense:
[http://dash.harvard.edu/handle/1/4907301](http://dash.harvard.edu/handle/1/4907301)
So this is known as a hard unsolved problem. Further diving into the
scalability issue is this project thread on their forum:
[https://bitmessage.org/forum/index.php?PHPSESSID=8cl6qeafitk...](https://bitmessage.org/forum/index.php?PHPSESSID=8cl6qeafitkac363ufcqma3tp5&topic=3391.0)
It would be great if the partitioning concept and algorithms could be
explained in detail. It's again a hard problem, even group size estimation in
a hostile environment is already non-trivial. So how group consensus is formed
to do a break-up is difficult and prone to attacks. This design is not
incentive compatible. TOR has over 50% Bittorrent traffic, it's difficult to
stop users from using(abusing?) TOR like that. Systems like Bittorrent and
Bitcoin have some incentives, but Bitmessage with broadcasts and proof-of-work
might even have a negative incentive for participation. I have seen no
mechanism to prevent it's users broadcasting Blueray rips. This would bring
down the system, one cluster at a time. Please check this work, it shows how
to bring this type of P2P networks down: www.christian-
rossow.de/publications/p2pwned-ieee2013.pdf‎

Publicity like "Bitmessage Sends Secure, Encrypted, P2P Instant Messages"
might be nice. It creates a false sense of safety. If you want to protect
against NSA snooping, you're up against a real army of crypto experts with
decades of experience each.

Nice to see that this project has such an active Github community, 480 closed
issues and 1159 commits. But, in my opinion it's back to the drawing boards...
Sorry.

Disclaimer: working for 8 years on Tribler, a streaming Bittorrent client.

~~~
richardlblair
I appreciate the write up, it's why I popped into the thread.

That said, at least these folks are _trying_ to protect against the NSA. What
do you purpose we all do? Lay down and accept that they watch everything we
do? Fuck that. Let's continue to build tools as a community. They may have a
lot of people, but our community is bigger. So, fuck them.

People should continue to experiment, and try new things until we come up with
various way to protect against the god damn NSA.

~~~
synctext
Indeed, we should not roll over and declare privacy an illusion.

A lot of people are experimenting with designs that will never work. It's just
wasting programming resources, while projects like Tor starve for volunteers.
My research team is currently merging Tor and Bittorrent
([http://forum.tribler.org/viewtopic.php?f=2&t=5128&p=8585#p85...](http://forum.tribler.org/viewtopic.php?f=2&t=5128&p=8585#p8585)).

Clear designs (and lots of them) are more important then experimental code I
believe.

~~~
Natanael
Doesn't I2P fit better, considering the design requirements? Tor would require
very significant changes to scale better for high volume traffic, but I2P
already handles it reasonably well.

~~~
slashdotaccount
I wonder why I2P is getting so small amount of love. I've read somewhere that
for some reason it's popular only in Russia. It has two working email systems,
working Bittorrent and much more. Maybe it lacks a native (C or C++)
implementation?

~~~
Natanael
@synctext: you can't have traffic anonymity without routing. And I2P is mainly
slow because the shared bandwidth is low.

Also, it isn't a hard as you claim. It is mainly a matter of setup.

~~~
sadclown
My understanding of tribler is that it is going to use onion style routing and
use some internal cryptocurrency to incentivize users to provide bandwidth.
They hope that with proper incentives people will provide enough bandwidth to
enable speeds that are high enough to stream high def video anonymously. They
hope to prevent spam by enabling anonymous wiki editing of torrent channels
and voting of torrent quality.

------
fundamental
From what I can tell, it would appear that this system is still vulnerable to
some level of traffic analysis. Last I checked the messages are identical as
they are sent around the network, so it should be possible to observe the
origin of a message by observing the first node to transmit that binary
string. A similar approach could be used to identify receivers if the
acknowledge messages are enabled. While this doesn't get you the content of
the messages it does leak some information about the sender and receiver which
bitmessage should be hiding. This level of traffic analysis might seem
unrealistic, but there doesn't seem to be a good way to detect 'evil' clients
which could watch a large portion of the total network without too much
resources (in theory).

There are some recommendations on the other forums about using tor to make
this information less useful, but that is not what the system uses by default.

~~~
chongli
All users receive all messages. The only sort of traffic analysis you can do
with this is to harvest all of the peers. You have no idea who is sending
messages to whom.

~~~
w-ll
Well if you can get a handful of nodes between the sender and receiver you can
start to narrow down on which peers are sending what to whom. This is partly
the same sort of traffic analysis that is use against TOR.

~~~
chongli
What? All peers receive all messages from everyone. There is no distinguishing
senders and receivers.

~~~
w-ll
Not at the exact same time they don't. You watch the propagation of the
message.

~~~
chongli
What does that tell you?

------
Paperweight
Have a messaging system that implements per-MB fees in order to support the
network. The transaction has to be signed by the sender, receiver, and
burdened nodes. BOOM no spam.

~~~
Atheros
No one is willing to pay money to send messages. I even proposed Satoshi
Nakamoto's idea (possibly other earlier peoples' idea) to require paying to
send a message but receiving money to receive a message and no one would
accept even that idea.

~~~
Paperweight
Who cares if _some_ people don't accept an idea at first if it's backward
compatible? Make a client that checks if the recipient isn't found in the
encrypted network and gives you the option to fall back to regular email, even
without the benefits of anonymity and privacy.

Besides that, the idea is to attach two "stamps" to an encrypted message. One
goes to the recipient and one goes to the mail server, but only in tandem.
That pays the mail server for storing the message until the recipient goes
online to pick it up. And it also stops people from running their own fake
mail server that just skims stamps and throws away the messages. It's
basically a throwaway dropbox.

I'm dreaming and have no idea how to implement it, but I've kicked it around
for years ever since pondering the Your Idea Won't Work "form"
([http://craphound.com/spamsolutions.txt](http://craphound.com/spamsolutions.txt))

------
mahyarm
Bitmessage is not mobile practical due to the hash cash requirements, unless
you have a main 'mail' server and use the mobile client as a thin client.

------
infruset
Now, if this is scalable as the authors claim, wouldn't this be a nice vehicle
for a decentralized facebook? I can see at least an issue, which is that large
files (i.e pictures, videos) can be transferred but they would have to be
stored on the hard drive of anyone who wants to keep having access to it. What
do you think?

------
infruset
I just installed it. How do you give an address to people without disclosing
it to the whole world if they don't have PGP?

This is one of my addresses, I feel lonely HN :-)
BM-2cUHuH7sJdt3GchrqSikvzWP4w7Vm2cjhK (so much for not disclosing to the whole
world, but this is just for fun)

~~~
slashdotaccount
Bitmessage addresses aren't secret. They are even being broadcasted to the P2P
network when you create them. Of course, one can keep in secret (by not
announcing it) that he/she owns a particular Bitmessage address but the
addresses themselves are not secret.

~~~
walden42
> They are even being broadcasted to the P2P network when you create them.

What is the purpose of this?

~~~
Natanael
The addresses is a hash of a public key, not a public key itself.

------
p4bl0
I read a while back that BitMessage's security is easily breakable. See
[http://secupost.net/3240982275/bitmessage-
security](http://secupost.net/3240982275/bitmessage-security).

~~~
dmunoz
This relied on being able to send lots of messages, and having the user visit
a link contained in them. The first issue can be fixed by upping the proof of
work required to send a message, although this will not stop a determined
attacker who has lots of cycles to throw at the problem. As for the second
issue, users should not be visiting links from addresses they do not trust. As
with most anonymity systems, it is only as good as you treat it.

~~~
derefr
> The first issue can be fixed by upping the proof of work required to send a
> message, although this will not stop a determined attacker who has lots of
> cycles to throw at the problem.

Could you implement something like IRC's "flood prevention" in a proof-of-work
based consensus algorithm -- so sending messages closer together costs
prohibitively more?

The network could require, say, the work in a transaction to be proportional
to ∑(1/message dt) for the messages signed by the transaction.

~~~
Pavitra
> Could you implement something like IRC's "flood prevention" in a proof-of-
> work based consensus algorithm -- so sending messages closer together costs
> prohibitively more?

This seems easily circumvented by creating lots of identities. Though maybe
creating an identity could be costly?

