Bitmessage: a decentralized, encrypted, trustless communications protocol | Hacker News Reader

Bitmessage: a decentralized, encrypted, trustless communications protocol

en.wikipedia.org

70 pointsCapacitorSet26 comments

I highly recommend not using this, it has a variety of weaknesses and vulnerabilities. https://bitmessage.org/forum/index.php?topic=1666.0 is a pretty thorough analysis. The biggest problem IMO is that there is no encryption when passing messages between peers, so a passive adversary can easily determine who's sending what message.

There's over 30 years of papers and academic research on anonymous mailing systems and Bitmessage incorporates not one of those concepts

The author of the audit claims to be working on competing software, so I wonder if there is any alternative to bitmessage that achieves some anonymity.

Regardless of implementation details, the purpose of bitmessage is interesting and any secure alternative would make a great communication software.

If you run PyBitmessage over tor you should be fine.

Actually, not against certain attacks. If a passive adversary knows you use BitMessage and want to determine your Bitmessage identity they can simply watch your traffic, and can determine any message you send out that you did not receive must have come from you. This can be used to determine which messages you sent, and if you respond to a request for your public key your identity will be revealed. Because the inter-peer connections are not encrypted, this is all trivial, and using Tor changes nothing.

So no, you are not necessarily fine.

But isn't the traffic between me and the entry node completely encrypted? How can a passive observer even detect I'm sending/receiving a specific message.

Timing, maybe?

Iirc, a difference in bitmessage from other protocols is that it has 'receiver anonymity,' in that since a message is received by all parties, the receiver's metadata is not leaked. This is possibly a benefit over some existing protocols, although it has obvious performance / scaling side-effects.

Bitmessage is just a broadcast protocol implemented with floodfill.

Anonymity protocols are mostly divided into 3 classes: broadcast (dining cryptographers, buses, bitmessage), mixes/rerouting (mixmaster, mixminion, tor) and private information retrieval (dissent and followups).

After decades of work in the field [1], bitmessage implements broadcast in the most naive way: floodfill. Global passive adversary can simply find out where the message appeared first. If the message is encrypted with a key which is only known to the receiver (i.e., message is not for chan), everything is ok. But in this case bitmessage is not better than alt.anonymous.messages.

If messages can be linked together, active non-global adversary can measure time and exploit dynamic topology of the network to reconnect closer to the sender. Bitmessage offers no protection against it. With alt.anonymous.messages the solution is remailers, and bitmessage offers no alternative.

[1] http://freehaven.net/anonbib/

The receiver anonymity tidbit was something I recalled from this summary http://fanti.web.engr.illinois.edu/ciss2016.pdf which for some reason was in my crypto / chat papers folder..

btw thanks for the link - quite extensive citation helper

Bitmessage is mostly used for "chans" and they are insecure. Basically, when you send a message to chan, everyone who knows about this chan can decrypt the message. So the message is essentially not encrypted.

Streams are not implemented, so bitmessage does no scale.

As you can request a list of neighbors from anyone you can easily attack network by constantly reconnecting closer to the message sources. For example, you can track down all active users of some particular chan.

Freenet project did a lot of work to protect against opennet attacks, and bitmessage completely ignores it.

Well, the name of the chan is the key, so assuming you use a relatively strong password-style name and then keep that name secure, the chan will also be secure.

Isn't the point more about concealing who is sending the message in the first place?

Bitmessage is essentially a floodfill algorithm. You just need to request neighbor list from your neighbor which delivered the message to you before others. Then, you connect to them and you are one step closer to the sender. Repeat it until you are connected to the original sender and all its neighbors. So Bitmessage does not protect you if you use the same sender identity multiple times.

Bitmessage requires a professional security audit: https://github.com/Bitmessage/PyBitmessage/issues/381

Full stop.

I would be very weary of this product. I used it a while ago on a project for a course I was taking. During my research, I found a FAQ where the creator stated that if ever asked to place a back door in it, he would.

I don't think any creator of any "secure" messaging product would claim something like this.

But, given the possibility of something like this happening either way, this is why clean open protocols are more important for decentralized software, than reference clients.

Could I burden you for a link to that, if possible?

I browsed the tubes for a bit and couldn't find anything but the following, which is a Feature Request comment under Backend[1] mentioning a "controlled backdoor", possibly added by this contrib[2]. It reads as follows:

at the cost of getting scorned, but dead serious: a controlled backdoor, with an automatic audit trail, to be used by lawful agencies for keeping us safe. Bitcoin by design supports criminal activities, which undermine the community. A community messaging system should have a way of cleaning itself.

1. https://bitmessage.org/wiki/Feature_request_list#Backend

2. https://bitmessage.org/wiki/Special:Contributions/14skywalke...

Probably not the example mentioned by Parent, though.

[ Citation Needed ]

puzzled look

No one has ever asked if I would backdoor it. I certainly wouldn't; that would defeat the purpose. Someone below linked to a random user requesting this feature:

https://bitmessage.org/w/index.php?title=Feature_request_lis...

Perhaps that is what you remember reading.

BitMessage is very useful for receiving notifications from Dark Net markets.

If you are the receiver, it is ok. Simply connect to the network and offer you identity to the sender, then wait for message. As you do nothing else besides connecting to the network, there is no difference between you and other users.

What is questionable is the security of the sender.

The amount of FUD that bitmessage is receiving is strange. It's both easy to use tool and powerful. It's shortcomes are obvious so you rely on your opsec (mainly managing your multiple identities) which is the only way to be anonymous anyway. I'll continue using it and bet on the future of bitmessage

I was excited about it once, but this project doesn't seem to get a traction, so probably it's not worth to use it for real secure messaging. Awesome concept, though. I hope, it'll reborn somewhere. Spam problem is a huge problem and most other messaging systems don't bother.

Look at the Freenet Message System. It even offers the captcha.

I doubt proof-of-work can really help against determined attacker. Spammers will happily calculate proof-of-work to send spam. Spamming chans is really easy and all chans will be flooded with spam once it is worth the effort.

Reply on news.ycombinator.com