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

31–40 of 67 posts

Re: Bitmessage – Send messages without leaking metadata

#31

Post by wcummings »

Atheros wrote: post #25
Ihmahr wrote: post #9

Earlier quoted context omitted.

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)

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

Re: Bitmessage – Send messages without leaking metadata

#32

Post by Ihmahr »

Atheros wrote: post #25
Ihmahr wrote: post #9

Earlier quoted context omitted.

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)

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.

Re: Bitmessage – Send messages without leaking metadata

#33

Post by Pavitra »

derefr wrote: post #24
dmunoz wrote: post #21

Earlier quoted context omitted.

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 p…

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

Re: Bitmessage – Send messages without leaking metadata

#34

Post by al2o3cr »

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.

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

Re: Bitmessage – Send messages without leaking metadata

#35

Post by [deleted] »

synctext wrote: post #5
benregenspan wrote: post #4

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]

Re: Bitmessage – Send messages without leaking metadata

#36

Post by SectioAurea »

natch wrote: post #3

Nice. 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…

This 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.

Re: Bitmessage – Send messages without leaking metadata

#37

Post by walden42 »

slashdotaccount wrote: post #12
infruset wrote: post #10

I 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)

Bitmessage 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.

> They are even being broadcasted to the P2P network when you create them.

What is the purpose of this?

Re: Bitmessage – Send messages without leaking metadata

#38

Post by liamzebedee »

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…

Although I agree with your premise that clear designs are essential, I'd say that it's important nonetheless to implement them. Having an implementation is a marker of whether the design does/does not work. A whitepaper can theoretically show this, but an application is always (in my experience) more effective.

For example, when Satoshi first published the whitepaper for Bitcoin, there was talk on the crypto mailing list that it wouldn't scale due to its gossip-based protocol. Satoshi's design showed it did, and laid the foundations for future cryptocurrencies (Namecoin, Peercoin).

P.S. I've been following your work with Tribler, excellent stuff!

Re: Bitmessage – Send messages without leaking metadata

#39

Post by sadclown »

Natanael wrote: post #29
slashdotaccount wrote: post #18

Earlier quoted context omitted.

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.

My understanding of tribler is that it is going to use onion style routing and use some internal cryptocurrency to incentivize users to provide bandwidth. They hope that with proper incentives people will provide enough bandwidth to enable speeds that are high enough to stream high def video anonymously. They hope to prevent spam by enabling anonymous wiki editing of torrent channels and voting of torrent quality.

Re: Bitmessage – Send messages without leaking metadata

#40

Post by sadclown »

Natanael wrote: post #14
synctext wrote: post #5

Earlier quoted context omitted.

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…

What do you think of Bote mail in I2P, which uses DHT for relaying mail? It is set to hold mail in the DHT for 100 days or until fetched by the recipient. It also uses public keys as addresses (ECDSA and NTRU are the options), and all mail is encrypted. I2P provides traffic anonymization, and Bote mail supports letting mails be relayed with random delays to further anonymize the sender by removing time correlation. h…

I would love to see someone give i2p-bote a good analysis. I tried using it a couple of times but wasn't able to ever receive messages successfully. They are advertixing some pretty awesome features though; no content or metadata leakage; it is secure against a global passive adeversary if you use delays between relay hops; parties don't have to be online at the same time to communicate.
Post reply on HN