A Technical Look at BitMessage: Learning From a Dead Project

https://zolagonano.github.io/blog/posts/a-very-technical-look-at-bitmessage

by znano • 2 years ago

73 15 2 years ago

zolagonano.github.io

nullc2• 2 years ago

This writeup has imagined flaws, e.g

"This scheme, by today’s standards, isn’t that secure. The CBC mode adds a lot of complications and insecurities because it doesn’t have authentication of messages, and self-implementation of them leaves room for many errors and mistakes. A better scheme by today’s standards would use X25519 to exchange the keys and generate the shared secrets. X25519 is based on Curve25519, which is faster and more secure than ECDH."

When X25519 is ECDH (just with a particular set of parameters) and when bitmessage used pretty standard mac authenticed encryptions while many popular AEAD's have serious IV reuse fragility problems. You could easily make bitmessage worse by trying to "fix" this nonissue.

Meanwhile, Bitmessage does have a serious cryptographic flaw that this article doesn't notice and seems to endorse:

Because Bitmessage address hash the public keys instead of being a few bytes longer, in a kind of cargo-culty copy of Bitcoin, it means that you cannot send a message to a recipient without them first replying to a message with their public key.

This is a huge hit to the privacy model because it forces receivers who would otherwise be completely passive and undetectable to transmit. ... and they have to transmit to arbitrary key resolution requests without knowing who is trying to contact them and why (e.g. if it's worth blowing their passive protection). It also generates superfluous network traffic and makes it slightly less reliable.

It would be much better to increase the address size from 160 to 256 bits.

viralpoetry• 2 years ago

This was actually solved by another address protocol version. I believe v3 solved this by using pubkey instead of hash. Similar to late btc addresses

hcfman• 2 years ago

is this the nullc otherwise known as Greg Maxwell ? Just wondering.

Ah yes, I see from your submissions it is. Love your audio work!!

fire_lake• 2 years ago

They never had a convincing solution for scale in my view.

nullc2• 2 years ago

In what sense? In terms of additional peerings wasting bandwidth proportional to the number of messages? That can be addressed with techniques like erlay ( https://arxiv.org/abs/1905.10518 ) though the erlay paper's settings are tuned for lower latency than something like Bitmessage would want.

In terms of the fact that it is just a global broadcast? Not everything needs to "scale" to handling all messaging for the world. Bitmessage style broadcast can support occasional small messaging for tens to hundreds of thousands of users (maybe even millions) without using outrageous amounts of bandwidth.

Not everything needs to be or should be the next twitter replacement.

Rhapso3• 2 years ago

The point kinda was to optimize for security over scalability. It wasn't the goal. Go make a messaging system on TOR if you want a less secure more scalable tradeoff point.

oldgregg• 2 years ago

less secure indeed

Rhapso3• 2 years ago

Bitmessage is a wonderful example of turning the scalability vs privacy dial all the way to the right.

The primitives are all due an update. Proof of Work sucks. But otherwise, all-to-all epidemic broadcast is the path to minimal message metadata leaking.

hanniabu• 2 years ago

Look up proof of stake

Rhapso3• 2 years ago

ha, no thanks. it also can't work for bitmessage, there is no coin to stake.

bawolff• 2 years ago

I mean, if you really want the scalability vs privacy dial all the way to the right, i assume you would use dining cryptographer nets.

Much older than proof of work, and literally as private as theoretically possible.

evbogue• 2 years ago

It's been more than ten years since I used Bitmessage but wasn't message flooding what caused its downfall?

Scoundreller• 2 years ago

Sounds like the first iteration of gnutella: https://en.m.wikipedia.org/wiki/Gnutella

A Technical Look at BitMessage: Learning From a Dead Project

Related Stories