Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bitmessage – Send messages without leaking metadata

bitmessage.org

Post reply on HN
Print view View original

21–30 of 67 posts

Re: Bitmessage – Send messages without leaking metadata

#21

Post by dmunoz »

p4bl0 wrote: post #17

I read a while back that BitMessage's security is easily breakable. See http://secupost.net/3240982275/bitmessage-security .

This relied on being able to send lots of messages, and having the user visit a link contained in them. The first issue can be fixed by upping the proof of work required to send a message, although this will not stop a determined attacker who has lots of cycles to throw at the problem. As for the second issue, users should not be visiting links from addresses they do not trust. As with most anonymity systems, it is only as good as you treat it.

Re: Bitmessage – Send messages without leaking metadata

#23

Post by berdario »

Ihmahr wrote: post #9
ma_mazmaz wrote: post #2

According to the white paper, "all users receive all messages." How, then is the system scalable to a large network?

They have some vague ideas for scalability that they do not know how to implement. Also they have some major security issues that I pointed out to them, but they simply ignored. I am sure bitmessage will never be a success because it is fundamentally broken.

I've read some criticism of bitmessage sometimes, but it's been quite scarce (as with all interesting feedback) as of now...

care to link to the bug report/forum post/blog post where you wrote the security issues you mentioned?

Re: Bitmessage – Send messages without leaking metadata

#24

Post by derefr »

dmunoz wrote: post #21
p4bl0 wrote: post #17

I read a while back that BitMessage's security is easily breakable. See http://secupost.net/3240982275/bitmessage-security .

This relied on being able to send lots of messages, and having the user visit a link contained in them. The first issue can be fixed by upping the proof of work required to send a message, although this will not stop a determined attacker who has lots of cycles to throw at the problem. As for the second issue, users should not be visiting links from addresses they do not trust. As with most anonymity systems, it is o…

> The first issue can be fixed by upping the proof of work required to send a message, although this will not stop a determined attacker who has lots of cycles to throw at the problem.

Could you implement something like IRC's "flood prevention" in a proof-of-work based consensus algorithm -- so sending messages closer together costs prohibitively more?

The network could require, say, the work in a transaction to be proportional to ∑(1/message dt) for the messages signed by the transaction.

Re: Bitmessage – Send messages without leaking metadata

#25

Post by Atheros »

Ihmahr wrote: post #9
ma_mazmaz wrote: post #2

According to the white paper, "all users receive all messages." How, then is the system scalable to a large network?

They have some vague ideas for scalability that they do not know how to implement. Also they have some major security issues that I pointed out to them, but they simply ignored. I am sure bitmessage will never be a success because it is fundamentally broken.

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)

Re: Bitmessage – Send messages without leaking metadata

#26

Post by Atheros »

Paperweight wrote: post #15

Have a messaging system that implements per-MB fees in order to support the network. The transaction has to be signed by the sender, receiver, and burdened nodes. BOOM no spam.

No one is willing to pay money to send messages. I even proposed Satoshi Nakamoto's idea (possibly other earlier peoples' idea) to require paying to send a message but receiving money to receive a message and no one would accept even that idea.

Re: Bitmessage – Send messages without leaking metadata

#27

Post by richardlblair »

synctext wrote: post #13
richardlblair wrote: post #11

Earlier quoted context omitted.

I appreciate the write up, it's why I popped into the thread. That said, at least these folks are trying to protect against the NSA. What do you purpose we all do? Lay down and accept that they watch everything we do? Fuck that. Let's continue to build tools as a community. They may have a lot of people, but our community is bigger. So, fuck them. People should continue to experiment, and try new things until we come…

Indeed, we should not roll over and declare privacy an illusion. A lot of people are experimenting with designs that will never work. It's just wasting programming resources, while projects like Tor starve for volunteers. My research team is currently merging Tor and Bittorrent ( http://forum.tribler.org/viewtopic.php?f=2&t=5128&p=8585#p85... ). Clear designs (and lots of them) are more important then experimental co…

Experimental code increased the understanding of these complex systems across a greater population of developers.

If we are going to come out on top, then we need to play the long game. In that case, experimental code has a lot of value.

Re: Bitmessage – Send messages without leaking metadata

#28

Post by synctext »

slashdotaccount wrote: post #18
Natanael wrote: post #16

Earlier quoted context omitted.

Doesn't I2P fit better, considering the design requirements? Tor would require very significant changes to scale better for high volume traffic, but I2P already handles it reasonably well.

I wonder why I2P is getting so small amount of love. I've read somewhere that for some reason it's popular only in Russia. It has two working email systems, working Bittorrent and much more. Maybe it lacks a native (C or C++) implementation?

I2P is slow, it has no incentive system like T4T.

Try installing it, search for files and watch download speeds. Onion routing and tunnels cost bandwidth. The crowd that is used to Bittorrent speeds (in combo with VPN safety) is not interested in 2 Kbit/sec speeds. Plus the user interface is hard to understand without having attended crypto courses.

Re: Bitmessage – Send messages without leaking metadata

#29

Post by Natanael »

slashdotaccount wrote: post #18
Natanael wrote: post #16

Earlier quoted context omitted.

Doesn't I2P fit better, considering the design requirements? Tor would require very significant changes to scale better for high volume traffic, but I2P already handles it reasonably well.

I wonder why I2P is getting so small amount of love. I've read somewhere that for some reason it's popular only in Russia. It has two working email systems, working Bittorrent and much more. Maybe it lacks a native (C or C++) implementation?

@synctext: you can't have traffic anonymity without routing. And I2P is mainly slow because the shared bandwidth is low.

Also, it isn't a hard as you claim. It is mainly a matter of setup.

Re: Bitmessage – Send messages without leaking metadata

#30

Post by wcummings »

infruset wrote: post #20
Paperweight wrote: post #15

Have a messaging system that implements per-MB fees in order to support the network. The transaction has to be signed by the sender, receiver, and burdened nodes. BOOM no spam.

then couldn't we just use the Bitcoin protocol for sending messages?

Yes, but this would be frowned upon and even actively resisted by the BTC community because it clutters up the blockchain
Post reply on HN