[HN Gopher] A Technical Look at BitMessage: Learning From a Dead...
___________________________________________________________________
A Technical Look at BitMessage: Learning From a Dead Project
Author : znano
Score : 36 points
Date : 2024-08-25 10:38 UTC (1 days ago)
(HTM) web link (zolagonano.github.io)
(TXT) w3m dump (zolagonano.github.io)
| nullc wrote:
| 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 wrote:
| 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
| fire_lake wrote:
| They never had a convincing solution for scale in my view.
| nullc wrote:
| 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.
| Rhapso wrote:
| 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.
| Rhapso wrote:
| 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 wrote:
| Look up proof of stake
| Rhapso wrote:
| ha, no thanks. it also can't work for bitmessage, there is no
| coin to stake.
| freeqaz wrote:
| _Hold my beer_
|
| In TechCrunch: AnonMailCoin announces ICO, seeks to provide
| the Web 4.0 of email
| therein wrote:
| 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.
| bawolff wrote:
| 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.
___________________________________________________________________
(page generated 2024-08-26 23:00 UTC)