Multiple addresses and anonymity

BM-2cXdecLTPcGsRi81UkiN9jgzwpDmp4ZeZG
Jan 11 14:16 [raw]

It just occurred to me that one can apparently check at any moment if any given bitmessage address is online. Is that true? It would imply that if you have several activated bitmessage addresses, they could all be linked -- with some degree of likeliness -- as belonging to one specific person, as all those addresses would all appear offline or online at once each time the bitmessage node in question would get connected to the network or disconnected from it. So, in order to have several truly independent addresses, would it be sufficient for one to make sure to have only 1 activated address at once? (Not only during startups and shutdowns of the node, but at any given moment, since your internet connection could randomly drop any time and make all your activated addresses disconnect at the same time.) I know Tor can be used with Bitmessage, thus at least not exposing all addresses as belonging to the same IP. But, still, there are cases in which it would be preferable not to know that all addresses are from the same node, regardless of Tor use or not.

BM-2cXdecLTPcGsRi81UkiN9jgzwpDmp4ZeZG
Jan 11 14:23 [raw]

Finally, am I right to assume that "disabling" and address (in the PyBitmessage user interface) makes it unreachable -- as if offline? Or is it just a cosmetic local thing, so that the user stops seeing new messages that arrive to this address?

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Jan 11 16:27 [raw]

Hello, > It just occurred to me that one can apparently check at any moment > if any given bitmessage address is online. Is that true? It is partially true. You can send a message to an address and watch for the ack to come back, and analyse propagation of the ack or of addr commands. You cannot somehow query a node directly, or at least I'm not aware of such a method. Furthermore, ack measuring can't be done stealthily anymore, the target will always see that someone is sending him/her messages. In the past, pre-0.6.0, there were certain types of messages that were invisible in the UI even though they acknowledged receipt, but that's been fixed, about 2 years ago. Furthermore there are methods available to protect against this, one of them (dandelion++) is new and should be soon on by default, I just have to do some minor fixes and tests to make sure it works correctly. > It would imply that if you have several activated bitmessage > addresses, they could all be linked -- with some degree of > likeliness -- as belonging to one specific person, as all those > addresses would all appear offline or online at once each time the > bitmessage node in question would get connected to the network or > disconnected from it. Again, it's possible with the same constraints as listed above. But both extremes are probably difficult to check. If you're connected 24/7, they mix with the others that are also online 24/7, and if you're only connected very shortly, your address may not even propagate, or you may not even connect directly to the attacker at all. Dandelion++ should make a statistical analysis of propagation much more difficult, so then the attacker is stuck with measuring when is which node online, and I don't think that it has a high degree of accuracy. I can probably fiddle around with this to make it more fuzzy. > So, in order to have several truly independent addresses, would it > be sufficient for one to make sure to have only 1 activated address > at once? (Not only during startups and shutdowns of the node, but at > any given moment, since your internet connection could randomly drop > any time and make all your activated addresses disconnect at the > same time.) This may work. > I know Tor can be used with Bitmessage, thus at least not exposing > all addresses as belonging to the same IP. But, still, there are > cases in which it would be preferable not to know that all addresses > are from the same node, regardless of Tor use or not. You don't really know that, as I said, you can't query nodes if they have addresses directly, you can only analyse it indirectly through propagation/online status monitoring. Peter Surda Bitmessage core developer

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Jan 11 16:32 [raw]

> Finally, am I right to assume that "disabling" and address (in the > PyBitmessage user interface) makes it unreachable -- as if offline? > Or is it just a cosmetic local thing, so that the user stops seeing > new messages that arrive to this address? It is not only cosmetic, disabling an address prevents it from receiving any messages. However, that means messages to the address downloaded while it's disabled will get lost. So it may be distinguishable from an address that is offline and then receives the message later. Maybe there could be an option when enabling it if it wants to retry decrypting downloaded objects. It's probably best if a researcher looks at this and does a more formal analysis. Peter Surda Bitmessage core developer

[chan] bitmessage
Jan 11 16:35 [raw]

Also you can run many nodes with same address set. If one node goes offline the others still available.

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Jan 11 16:39 [raw]

> Also you can run many nodes with same address set. If one node goes > offline the others still available. Yes, that works, but if the TTL is too short, the node that isn't online often enough will never receive the message, so you have to live with the tradeoff. Peter Surda Bitmessage core developer

[chan] bitmessage
Jan 11 18:22 [raw]

> Also you can run many nodes with same address set. If one node goes offline the others still available. Yeah, I've always wanted to run multiple email servers just to get mail from one fucking account. There is no security in Bitmessage. It's a fucking flood protocol. NSA has all your data. With the current small network size there is no real security against individual pubkey analysis. There are only a few onion nodes that accept incoming connections and I'm betting most of these are run by spooks.

[chan] bitmessage
Jan 12 02:10 [raw]

> There are only a few onion nodes that accept incoming connections and I'm betting most of these are run by spooks. Maybe true, but don't forget at least three of them are not and will never be: - Peter's node (quzwelsuzy) - that crazy Tor guy - yours So, as long as we keep on keeping on, we'll be able to route around any misbehaviour in the network without ever touching the clearnet. All those spook nodes won't be able to say "no no no, that inventory object that you just received DOES NOT EXIST".

[chan] bitmessage
Jan 12 04:01 [raw]

That sounds all warm and fuzzy, and true, a few of us are on the same page, but, I still would not trust my life to such a small network. It needs more routing nodes, as in most or all of them. I'm not trying to discourage use of bitmessage, rather what I'm saying is we need 10 thousand more users and hidden services by default. Until a certain level of saturation and routing dispersion it is not a good idea to use it for any highly sensitive communication. If every node connected via Tor hidden services, I would change my opinion on the issue, but for now that's the way I view it. I really think the default bitmessage install should use the python stem library to automatically require and configure a tor hidden service connection (stem is awesome), and delete the hidden service address and key and replace with a fresh one at least every 3 days. I also believe PGP should be integrated to operate without user interaction, just as with the bitmessage keys. Of course if you're running a bootstrap node you would want to disable automatic key replacement, but that's a one percent case. I do not believe you can be exacting enough, nor employ enough overkill, when it comes to communication security. In it's current incarnation I just don't think it has enough armor to use for anything dangerous, such as whistleblowing. The interface is nice, the API is awesome, but the armor is much less than it could be.

BM-2cXdecLTPcGsRi81UkiN9jgzwpDmp4ZeZG
Jan 12 11:11 [raw]

Peter Surda, thank you for the various clarifications!

[chan] bitmessage
Jan 12 11:15 [raw]

Don't forget fucktrumpbkmcts7! 24/7 BM onion node accepting incoming!

BM-2cW1eU78LAgod3nLsjZ2TP7oDrzk7ndXEy
Jan 16 16:47 [raw]

> Again, it's possible with the same constraints as listed above. But both extremes are probably difficult to check. If you're connected 24/7, they mix with the others that are also > online 24/7, and if you're only connected very shortly, your address may not even propagate, or you may not even connect directly to the attacker at all. Dandelion++ should > make a statistical analysis of propagation much more difficult, so then the attacker is stuck with measuring when is which node online, and I don't think that it has a high degree > of accuracy. I can probably fiddle around with this to make it more fuzzy. Hello Peter, When running a node, would it be useful to use a cron task to have bitmessage randomly on (and off) only some hours a day ? Just enough to catch the messages, redispatch them, and return in hibernation ? Submarine mode :-) Also, what is the clean way to stop a bitmessage instance running remotely ? I think using kill process, but is there a nicest way ? Thanks Harry

[chan] bitmessage
BM-2cWy7cvHoq3f1rYMerRJp8PT653jjSuEdY

Subject Last Count
Chris' new address Apr 21 22:55 3
OTR on Bitmessage Apr 21 15:53 4
Free XMPP Server Apr 20 03:36 1
bitmessage via bluetooth Apr 19 23:15 3
beamstat.com is broken Apr 19 13:39 7
[chan] 411: DARKNET DIRECTORY ASSISTANCE Apr 19 03:38 1
Error 503: Beamstat website is broken Apr 17 21:16 1
Calculation of common stream numbers Apr 17 20:57 8
Get bitcoin while browsing web. Apr 17 09:48 1
1$ XMPP Apr 16 03:36 1
Use a fucking address Peter Apr 15 10:01 20
incoming connections Apr 14 17:12 2
local peer discovery Apr 14 16:38 14
Peter Todd Apr 14 15:36 4
bootstrap nodes Apr 13 11:55 2
a comment on issue 1215 Apr 13 07:59 4
Something broke in today's commit 4/11 Apr 12 01:50 5
feature request Apr 11 23:06 2
Whonix Question Apr 10 12:00 6
done Apr 9 18:30 1
Number of CPU cores in PoW nonce Apr 8 13:32 5
Qs. Apr 8 06:57 4
How to make bitmessage secure Apr 7 23:01 2
BMinstallMenu - easy download + run Bitmessage from py source in one single menu Apr 7 14:52 1
RE: PyBitmessage Daemon on Android Apr 6 19:02 1
PyBitmessage Daemon on Android Apr 6 12:34 15
[WWS11Dev] BMr5 8 day sync stats 180405 Apr 5 23:05 4
Longer time-to-live? Apr 4 08:53 2
The Swiss Khazars rule the world. The Swiss Guard controls the Pope. Apr 3 17:31 1
Any way to use IMAP/POP + SMTP with Bitmessage? Apr 3 17:06 10
Cheating spouse Apr 3 01:07 4
lavabit Apr 2 11:11 3
bitmessage feature proposal Apr 1 12:20 1
more for feature bucket list Mar 31 17:18 7
bug report Mar 31 10:15 10
Adress alias not working Mar 30 18:16 4
bm hidden service settings Mar 30 17:48 2
Any privacy benefits to changing maximum outbound connections? Mar 29 09:50 10
Question about messaging subscribers Mar 29 06:52 3
Request for clarification Mar 28 19:32 2
Unknown encoding type. Mar 28 08:07 9
Harden Bitmessage config for tor use? Mar 28 07:07 2
Whats this bitboard thing about? Mar 27 23:46 2
new bm broadcast address? Mar 27 13:51 2
streams in bm protocol Mar 27 06:35 1
Message to Peter Surda Mar 26 21:26 3
qt theme Mar 26 21:25 5
wiki lock down Mar 26 19:33 2
GPG - Mar 26 19:31 1
How the Hell do you CREATE a Broadcast Address??? Mar 26 19:17 4
Instructions: Create a Broadcast Address Mar 26 17:50 1
not collaborative? Mar 26 17:31 11
BEWARE OF SCAMMERS, THIEVES POSING AS HACKERS! Mar 26 14:57 1
faster hacker is here Mar 26 14:54 5
Bitcoin double Mar 26 07:05 3