Live data from Hacker News

Bitmessage – Send messages without leaking metadata

bitmessage.org

51–60 of 67 posts

Re: Bitmessage – Send messages without leaking metadata

#51
post #48

From what I can tell, it would appear that this system is still vulnerable to some level of traffic analysis. Last I checked the messages are identical as they are sent around the network, so it should be possible to observe the origin of a message by observing the first node to transmit that binary string. A similar approach could be used to identify receivers if the acknowledge messages are enabled. While this does…

All users receive all messages. The only sort of traffic analysis you can do with this is to harvest all of the peers. You have no idea who is sending messages to whom.

Well if you can get a handful of nodes between the sender and receiver you can start to narrow down on which peers are sending what to whom. This is partly the same sort of traffic analysis that is use against TOR.

Re: Bitmessage – Send messages without leaking metadata

#52
post #51
post #48

Earlier quoted context omitted.

All users receive all messages. The only sort of traffic analysis you can do with this is to harvest all of the peers. You have no idea who is sending messages to whom.

Well if you can get a handful of nodes between the sender and receiver you can start to narrow down on which peers are sending what to whom. This is partly the same sort of traffic analysis that is use against TOR.

What? All peers receive all messages from everyone. There is no distinguishing senders and receivers.

Re: Bitmessage – Send messages without leaking metadata

#53
post #34

Earlier quoted context omitted.

...and "BOOM" the whole no-metadata thing as well. See also the craziness with tracking Bitcoins from wallet-to-wallet recently.

You must admit that even an imperfect setup that leaks a little bit of metadata is a lot less bad than storing your entire inbox in cleartext at the NSA, which is what regular email amounts to.

But he never argued against that, he is saying that bitmessage (aims to) provides a solution to a particular problem, and your proposal would absolutely dismantle that solution.

Whether the result would be better that another unrelated product is irrelevant.

  "here is a sugar-free pie !"
  "you should add sugar to solve the sour taste problem"
  "but, that would defeat the whole no-sugar thing ..."
  "You must admit that it's still a lot less bad than soyent though !"

Re: Bitmessage – Send messages without leaking metadata

#54
post #52
post #51

Earlier quoted context omitted.

Well if you can get a handful of nodes between the sender and receiver you can start to narrow down on which peers are sending what to whom. This is partly the same sort of traffic analysis that is use against TOR.

What? All peers receive all messages from everyone. There is no distinguishing senders and receivers.

Not at the exact same time they don't. You watch the propagation of the message.

Re: Bitmessage – Send messages without leaking metadata

#55
post #54
post #52

Earlier quoted context omitted.

What? All peers receive all messages from everyone. There is no distinguishing senders and receivers.

Not at the exact same time they don't. You watch the propagation of the message.

What does that tell you?

Re: Bitmessage – Send messages without leaking metadata

#56
post #53

Earlier quoted context omitted.

You must admit that even an imperfect setup that leaks a little bit of metadata is a lot less bad than storing your entire inbox in cleartext at the NSA, which is what regular email amounts to.

But he never argued against that, he is saying that bitmessage (aims to) provides a solution to a particular problem, and your proposal would absolutely dismantle that solution. Whether the result would be better that another unrelated product is irrelevant. "here is a sugar-free pie !" "you should add sugar to solve the sour taste problem" "but, that would defeat the whole no-sugar thing ..." "You must admit that it…

If you add a little sugar and all the other problems go away, it might be worth it. Email is not irrelevant.

Re: Bitmessage – Send messages without leaking metadata

#57

Earlier quoted context omitted.

It hasn't been studied as extensively as Tor.

Which is why we need to get it studied more.

Sure, but that's still the reason it isn't as widely used. And because research resources in the anonymous-networking field are so limited the marginalization of I2P tends to be self-reinforcing.

Re: Bitmessage – Send messages without leaking metadata

#58
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?

(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, just like you can create a new bitcoin address for each transaction

Pond seems interesting, but quite different from bitmessage, especially I like bitmessage because of its user-friendliness (the UI needs lots of improvement, but you just download it, create an identity and off you go... I doubt about the feasibility of getting the whole world to use TOR, especially people in China/Iran or "my parents")

Re: Bitmessage – Send messages without leaking metadata

#59
Now, if this is scalable as the authors claim, wouldn't this be a nice vehicle for a decentralized facebook? I can see at least an issue, which is that large files (i.e pictures, videos) can be transferred but they would have to be stored on the hard drive of anyone who wants to keep having access to it. What do you think?

Re: Bitmessage – Send messages without leaking metadata

#60
post #52
post #51

Earlier quoted context omitted.

Well if you can get a handful of nodes between the sender and receiver you can start to narrow down on which peers are sending what to whom. This is partly the same sort of traffic analysis that is use against TOR.

What? All peers receive all messages from everyone. There is no distinguishing senders and receivers.

Unless I'm mistaken if you can see all the traffic a sender can be identified by being the first node to produce a set cyphertext. As the delays seem to be fairly short for the acknowledge messages, there is some chance that the receiver can be identified in a similar way.

eg node A broadcasts C1 which has not been observed before nodes B,C,D propagate the cyphertext C1 node D broadcasts C2 shortly after receiving C1 nodes A,B,C propagate C2 etc

Of course seeing this pattern in practice might be hard, but it still seems like a possible attack vector given the current system.

Post reply on HN