8 ms·
Bitmessage – Send messages without leaking metadata
- ma_mazmaz 13y agoAccording to the white paper, "all users receive all messages." How, then is the system scalable to a large network?
- benregenspan 13y agoThe whitepaper proposes to handle this by having nodes join separate clusters once their databases reach a certain size.
- synctext 13y agoPlease 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 missing on this vital element plus defenses against the Sybil attack are missing from this design. Mechanisms such as the "averageProofOfWorkNonceTrialsPerByte" in this system only slow down attacks and do not stop them. Check the impossibility proof by Harvard to see that systems like Bitmessage which react to any message cannot build an effective Sybil defense: http://dash.harvard.edu/handle/1/4907301 http://dash.harvard.edu/handle/1/4907301 So this is known as a hard unsolved problem. Further diving into the scalability issue is this project thread on their forum: https://bitmessage.org/forum/index.php?PHPSESSID=8cl6qeafitkac363ufcqma3tp5&topic=3391.0 https://bitmessage.org/forum/index.php?PHPSESSID=8cl6qeafitk... It would be great if the partitioning concept and algorithms could be explained in detail. It's again a hard problem, even group size estimation in a hostile environment is already non-trivial. So how group consensus is formed to do a break-up is difficult and prone to attacks. This design is not incentive compatible. TOR has over 50% Bittorrent traffic, it's difficult to stop users from using(abusing?) TOR like that. Systems like Bittorrent and Bitcoin have some incentives, but Bitmessage with broadcasts and proof-of-work might even have a negative incentive for participation. I have seen no mechanism to prevent it's users broadcasting Blueray rips. This would bring down the system, one cluster at a time. Please check this work, it shows how to bring this type of P2P networks down: www.christian-rossow.de/publications/p2pwned-ieee2013.pdf Publicity like "Bitmessage Sends Secure, Encrypted, P2P Instant Messages" might be nice. It creates a false sense of safety. If you want to protect against NSA snooping, you're up against a real army of crypto experts with decades of experience each. Nice to see that this project has such an active Github community, 480 closed issues and 1159 commits. But, in my opinion it's back to the drawing boards... Sorry. Disclaimer: working for 8 years on Tribler, a streaming Bittorrent client.
- awt 13y agoBitmessage's POW concept is not only proposed but implemented and being used in practice.
- berdario 13y agomy2c: The common meme in the bitmessage community is that the POW helps mitigate flooding, but it's not quite there for spam prevention
- richardlblair 13y agoI 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 up with various way to protect against the god damn NSA.
- synctext 13y agoIndeed, 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#p8585 http://forum.tribler.org/viewtopic.php?f=2&t=5128&p=8585#p85...). Clear designs (and lots of them) are more important then experimental code I believe.
- Natanael 13y agoDoesn'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.
- slashdotaccount 13y ago
- berdario 13y agoThere are a bunch of different proposals for scaling bitmessage (with and without "streams") https://bitmessage.org/forum/index.php?topic=2550.msg5271 https://bitmessage.org/forum/index.php?topic=2550.msg5271
- Ihmahr 13y agoThey 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.
- berdario 13y agoI'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?
- Atheros 13y agoHello, 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)
- wcummings 13y agoHave you seen this post (https://news.ycombinator.com/item?id=6866972 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
- Atheros 13y agoRegarding 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
- natch 13y agoNice. One feedback for the maintainer of the OS X instructions: in the compile from source section, instead of giving the command line for installing homebrew (which by the way renders incorrectly with an emoticon on that wiki page) the best practice is to provide a link to the homebrew project page, because the command line may change, and because they don't want things like typos or emoticons getting in the way of people getting brew installed.
- SectioAurea 13y agoThis is an excellent point. I know I've been guilty of the pattern: "provide detailed directions for a poorly documented build, then spend years maintaining them in blog post/comments". Better would be to actually contribute to central project documentation, I suppose.
- infruset 13y agoI just installed it. How do you give an address to people without disclosing it to the whole world if they don't have PGP? This is one of my addresses, I feel lonely HN :-) BM-2cUHuH7sJdt3GchrqSikvzWP4w7Vm2cjhK (so much for not disclosing to the whole world, but this is just for fun)
- slashdotaccount 13y agoBitmessage addresses aren't secret. They are even being broadcasted to the P2P network when you create them. Of course, one can keep in secret (by not announcing it) that he/she owns a particular Bitmessage address but the addresses themselves are not secret.
- infruset 13y agoYes, that's what I meant, thanks for the clarification! I'm receiving messages from HN, this is awesome! I guess if people want to keep using my address to test it, I don't mind. [edit]: Judging from the success, I should have put a bitcoin address as well: 12CM3uBur4wxsj46BoMgoLqMMyUHqcPEWH :-)
- walden42 13y ago> They are even being broadcasted to the P2P network when you create them. What is the purpose of this?
- Natanael 13y agoThe addresses is a hash of a public key, not a public key itself.
- Paperweight 13y agoHave 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.
- infruset 13y agothen couldn't we just use the Bitcoin protocol for sending messages?
- wcummings 13y agoYes, but this would be frowned upon and even actively resisted by the BTC community because it clutters up the blockchain
- Atheros 13y agoNo 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.
- Paperweight 13y agoWho cares if some people don't accept an idea at first if it's backward compatible? Make a client that checks if the recipient isn't found in the encrypted network and gives you the option to fall back to regular email, even without the benefits of anonymity and privacy. Besides that, the idea is to attach two "stamps" to an encrypted message. One goes to the recipient and one goes to the mail server, but only in tandem. That pays the mail server for storing the message until the recipient goes online to pick it up. And it also stops people from running their own fake mail server that just skims stamps and throws away the messages. It's basically a throwaway dropbox. I'm dreaming and have no idea how to implement it, but I've kicked it around for years ever since pondering the Your Idea Won't Work "form" (http://craphound.com/spamsolutions.txt http://craphound.com/spamsolutions.txt)
- al2o3cr 13y ago
- p4bl0 13y agoI read a while back that BitMessage's security is easily breakable. See http://secupost.net/3240982275/bitmessage-security http://secupost.net/3240982275/bitmessage-security.
- dmunoz 13y agoThis 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.
- derefr 13y ago> 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.
- Pavitra 13y ago> 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? This seems easily circumvented by creating lots of identities. Though maybe creating an identity could be costly?
- 3pt14159 13y agoNot really security, more like spam prevention and idiots clicking links.
- fundamental 13y agoFrom 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 doesn't get you the content of the messages it does leak some information about the sender and receiver which bitmessage should be hiding. This level of traffic analysis might seem unrealistic, but there doesn't seem to be a good way to detect 'evil' clients which could watch a large portion of the total network without too much resources (in theory). There are some recommendations on the other forums about using tor to make this information less useful, but that is not what the system uses by default.
- chongli 13y agoAll 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.
- w-ll 13y agoWell 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.
- mahyarm 13y agoBitmessage is not mobile practical due to the hash cash requirements, unless you have a main 'mail' server and use the mobile client as a thin client.
- infruset 13y agoNow, 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?