"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.
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.
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.
"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.