A Technical Look at BitMessage: Learning From a Dead Project | Hacker News Reader

A Technical Look at BitMessage: Learning From a Dead Project

zolagonano.github.io

73 pointsznano15 comments

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.

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

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

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

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.

Look up proof of stake

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

Hold my beer

In TechCrunch: AnonMailCoin announces ICO, seeks to provide the Web 4.0 of email

Imagine if you could stake private messages. If a node is proven to have cheated, all other nodes form a consensus and leak its private messages.

But nothing at stake, as is the case with most PoS.

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.

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

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

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

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.

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.

less secure indeed

Reply on news.ycombinator.com