Live data from Hacker News

Bitmessage – Send messages without leaking metadata

bitmessage.org

61–67 of 67 posts

Re: Bitmessage – Send messages without leaking metadata

#61
post #25

Earlier quoted context omitted.

Hello, I'm not sure what questions you have asked in the past but I would be happy to answer them here. -Atheros / Jonathan (creator of Bitmessage)

Have you seen this post ( https://news.ycombinator.com/item?id=6866972 ), and what do you think of it? I'm interested in bitmessage but it being unvetted / not heavily reviewed gives me pause. Do you have any doubts about the design (that can't be easily solved)? Cheers, wc

Regarding the link, The proof of work requirement exists to keep the network from being flooded too easily. It has the side benefit that it may make sending spam uneconomic. That said, any attacker with a good GPU without a financial incentive could send a very inconvenient number of messages through the network as has happened before. About the paper "On the Sybil-Proofness of Accounting Mechanisms", I'm not sure of its relevance as Bitmessage uses neither accounting nor reputation. The stream branching algorithm will indeed require a good group size estimation algorithm. My current best thought is to use child streams whenever there are a certain number of messages already going through each of one's current streams per unit time. "So how group consensus is formed to do a break-up is difficult and prone to attacks." Luckily using child streams doesn't require consensus; one can decide for one's self. To join a child stream, all one does is say that they are a member of that stream in version messages, create Bitmessage addresses with that stream number imbedded therein, and advertise the node's existence in the parent stream from time to time. But malicious attackers could cause problems by flooding a stream and getting others to make a bad decision about when to start using a child stream. "I have seen no mechanism to prevent it's users broadcasting Blueray rips. This would bring down the system, one cluster at a time." The proof of work mechanism is supposed to prevent that. Broadcasting torrent files in Bitmessage broadcasts would require much less computing resources for the sender. "Please check this work, it shows how to bring this type of P2P networks down..". Which attack specifically? And why hasn't anyone used it to take down Bitcoin?

Regarding your last question, if someone throws an FPGA at the PoW algorithm, they could flood the network with a lot of data and that concerns me. And, as mentioned above, deciding when to use child streams in the context of a hostile environment remains and open question.

-Atheros

Re: Bitmessage – Send messages without leaking metadata

#62

Earlier quoted context omitted.

Is it forward secure yet? Why is this better than Pond?

(I'm just a guy interested in BM, not involved with development, yet) forward secrecy is helped by 2 things: you cannot know who is the recipient of a message, so if you want to store the messages to be able to decrypt them in the future when you'll have obtained their private key, you'd have to store all the network messages If you're worried by such an attacker, you can just create a new identity for each message,…

That's not forward secrecy. Usenet with encryption is not forward secret either.

> If you're worried by such an attacker [...]

Uh, shouldn't everyone be at this point?

> you can just create a new identity for each message

Key exchange and management is hard. That's why you try not to do it often. You could claim PGP e-mail was forward secret: All you need to do is use a new private key every time.

Re: Bitmessage – Send messages without leaking metadata

#63
post #32
post #25

Earlier quoted context omitted.

Hello, I'm not sure what questions you have asked in the past but I would be happy to answer them here. -Atheros / Jonathan (creator of Bitmessage)

I wrote the libertymail proposal. You said you'd read it but you never commented on it. It is mainly a summation of attacks that are possible on bitmessage, and provides solutions on how to prevent such attacks. I also propose a solution for scaling, one that could actually be implemented.

Bitmessage's solution for scaling can be implemented.

I found your paper here: https://anonfiles.com/file/849506ebab91aa0ab90e98fc539446a2

It lacks a "summation of attacks that are possible on bitmessage" or "solutions on how to prevent such attacks."

I like that you tried to add a feature where users could choose their own anonymity/usability balance. "Users should be able to choose to remain anonymous or to disclose (partial) address information and be a ’light’ client." 200MB a day just for headers is a little bit much for a mobile 'light' client. If the protocol supports sending only headers based on a filter then why bother supporting headers? The "seeding" node could just supply a list of body messages to download that pass a filter. This would also mean that no one ever has to sync headers.

Re: Bitmessage – Send messages without leaking metadata

#64
post #25

Earlier quoted context omitted.

Hello, I'm not sure what questions you have asked in the past but I would be happy to answer them here. -Atheros / Jonathan (creator of Bitmessage)

Is it forward secure yet? Why is this better than Pond?

It isn't yet. It may never be as it requires a round-trip to establish a session. The Pond design appears to be good.

Re: Bitmessage – Send messages without leaking metadata

#65
post #63
post #32

Earlier quoted context omitted.

I wrote the libertymail proposal. You said you'd read it but you never commented on it. It is mainly a summation of attacks that are possible on bitmessage, and provides solutions on how to prevent such attacks. I also propose a solution for scaling, one that could actually be implemented.

Bitmessage's solution for scaling can be implemented. I found your paper here: https://anonfiles.com/file/849506ebab91aa0ab90e98fc539446a2 It lacks a "summation of attacks that are possible on bitmessage" or "solutions on how to prevent such attacks." I like that you tried to add a feature where users could choose their own anonymity/usability balance. "Users should be able to choose to remain anonymous or to disclos…

Seriously,

To just take two examples:

-Every bitmessage user can be mitm'd by their ISP. (yes, I know about tor).

-Every bitmessage user could have only bad peers connecting to them when peers aggressively try to connect to their client.

These are two examples of attacks that work on bitmessage, that are addressed in the libertymail proposal, and for which a possible solution is given.

Re: Bitmessage – Send messages without leaking metadata

#66

Earlier quoted context omitted.

(I'm just a guy interested in BM, not involved with development, yet) forward secrecy is helped by 2 things: you cannot know who is the recipient of a message, so if you want to store the messages to be able to decrypt them in the future when you'll have obtained their private key, you'd have to store all the network messages If you're worried by such an attacker, you can just create a new identity for each message,…

That's not forward secrecy. Usenet with encryption is not forward secret either. > If you're worried by such an attacker [...] Uh, shouldn't everyone be at this point? > you can just create a new identity for each message Key exchange and management is hard. That's why you try not to do it often. You could claim PGP e-mail was forward secret: All you need to do is use a new private key every time.

I know, that's why I wrote "forward secrecy is helped", it's not something that you get out of the box with bitmessage

moreover, since the keypair and the BM identity is one-and-the-same the key exchange and management comes for free, once you got the first message sent to your recipient... changing identity is much easier than creating a new gpg keypair and sending it to the other guy, and on top of that you'll get some added anonimity

Re: Bitmessage – Send messages without leaking metadata

#67
post #5

Earlier quoted context omitted.

The whitepaper proposes to handle this by having nodes join separate clusters once their databases reach a certain size.

Please consider this a security review by a tenured P2P professor: The whitepaper describes a simple and focused system relying on partitioning in an attempt to preserve scalability. Bitmessage has many architectural similarities to Usenet and also offers no valid response to spam. Using a proof-of-work system to combat spam is proposed, but to-date science has not yet seen a working approach anywhere. Details are mi…

[deleted]
Post reply on HN