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