Bitmessage – Send messages without leaking metadata • Hacker News Board

Re: Bitmessage – Send messages without leaking metadata

#41

Post by fundamental » Sat, Dec 07, 2013, 11:25 PM UTC

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

Re: Bitmessage – Send messages without leaking metadata

#42

Post by foobarqux » Sat, Dec 07, 2013, 11:35 PM UTC

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?

It hasn't been studied as extensively as Tor.

Re: Bitmessage – Send messages without leaking metadata

#43

Post by foobarqux » Sat, Dec 07, 2013, 11:38 PM UTC

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)

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

Re: Bitmessage – Send messages without leaking metadata

#44

Post by mahyarm » Sat, Dec 07, 2013, 11:53 PM UTC

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

Re: Bitmessage – Send messages without leaking metadata

#45

Post by Natanael » Sat, Dec 07, 2013, 11:59 PM UTC

sadclown wrote: post #40

Natanael wrote: post #14

Earlier quoted context omitted.

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.

I've never had problems with receiving messages with it. Had I2P been running for at least 20 minutes or so to be able to establish enough connections? Bote can tell you how many Bote nodes it is connected to.

Re: Bitmessage – Send messages without leaking metadata

#46

Post by Natanael » Sun, Dec 08, 2013, 12:02 AM UTC

foobarqux wrote: post #42

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?

It hasn't been studied as extensively as Tor.

Which is why we need to get it studied more.

Re: Bitmessage – Send messages without leaking metadata

#47

Post by Natanael » Sun, Dec 08, 2013, 12:06 AM UTC

walden42 wrote: post #37

slashdotaccount wrote: post #12

Earlier quoted context omitted.

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?

The addresses is a hash of a public key, not a public key itself.

Re: Bitmessage – Send messages without leaking metadata

#48

Post by chongli » Sun, Dec 08, 2013, 12:24 AM UTC

fundamental wrote: post #41

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.

Re: Bitmessage – Send messages without leaking metadata

#49

Post by Paperweight » Sun, Dec 08, 2013, 12:33 AM UTC

Atheros wrote: post #26

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.

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

Re: Bitmessage – Send messages without leaking metadata

#50

Post by Paperweight » Sun, Dec 08, 2013, 12:47 AM UTC

al2o3cr wrote: post #34

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.

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.