Multiple addresses and anonymity

BM-2cXdecLTPcGsRi81UkiN9jgzwpDmp4ZeZG
Jan 11 14:16

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

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

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

> 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

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

> 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

> 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

> 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

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

Peter Surda, thank you for the various clarifications!

[chan] bitmessage
Jan 12 11:15

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

BM-2cW1eU78LAgod3nLsjZ2TP7oDrzk7ndXEy
Jan 16 16:47

> 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
Protonmail integration with Bitmessage Jan 19 01:48 6
bitmessage debian install script Jan 18 23:56 2
BM CPU time Jan 18 20:47 11
Layout and Formatting Feature Requests Jan 18 02:19 1
Feature Request Jan 18 01:12 1
chan Procedure Nazi Dumb Blonde SuperDick Jan 18 00:38 2
RFC: lighting payments on mailchuck email gateway Jan 18 00:08 5
help me modify my bitmessage Jan 18 00:08 4
Public announcement Jan 17 05:19 7
[chan] 411 BM-2cW53MzWqtod8TA6vybdUeqd2LhTuXCX3L Jan 17 01:02 1
Multiple addresses and anonymity Jan 16 16:47 12
need help broke af Jan 15 18:56 8
randomize exchange of bitmessage objects Jan 14 13:32 3
python IDE Jan 13 12:42 2
suggestion : "private DML" Jan 13 12:39 1
mailchuck spamfilter Jan 12 18:56 2
tor-0.3.2.9 message log warnings Jan 11 13:46 8
Which python IDE are BM devs using ? Jan 11 07:03 10
New functionality request for BitMessage after the trolling of nazi feds of yesterday. Jan 10 15:47 2
New functionality request for BitMessage after the trolling of nazi feds of yesterday on the Crypto-Anarchist chan. Jan 10 08:03 6
emoji only partially supported 🏴‍☠️🏴‍☠️ Jan 10 00:51 10
New Functionality request [..] Jan 10 00:33 1
how do bitmessage peers find each other on a local network? Jan 9 08:57 5
mailchuck Jan 7 21:23 11
hashionados Jan 7 01:27 14
bitmessage history Jan 6 08:24 2
colored emoji font Jan 6 07:37 1
noncetrialsperbyte Jan 6 00:38 4
STATBOT v0.0 : pings other STATBOTS to measure bitmessage transit times Jan 6 00:32 6
Bitseal Jan 4 10:37 2
Updated: STATBOT v0.0 : pings other STATBOTS to measure bitmessage transit times Jan 4 09:22 4
bitmessage plugin testing Jan 3 06:57 2
BM API - how to check if chan exists in keys.dat Jan 1 15:23 9
Forwarding port 8444, must the IP address be static ? Jan 1 12:22 10
[chan] statbot_pool <BM-2cXrouuaAyw8rzvfc2d4RgoFMn7SjnJBsQ> Jan 1 08:17 1
BONK 31337313373133731337 Jan 1 06:56 1
running the 1500 chan mammoth Dec 31 10:26 3
massive BM spike due to Russians Dec 30 20:41 2
The BM network seems to be acting funny Dec 30 17:12 4
fuck me ! The Russians posted 8000 BMs. they OWN bm. Dec 30 10:35 2
ERROR - Unknown state connection_fully_established Dec 30 09:34 7
the glider life can be simulated in your computer ! Dec 30 02:36 3
latest commit Dec 29 19:02 3
did you always want to edit a file ? 100 lines release ! Dec 29 17:07 2
did you always want to edit a file ? Dec 29 17:07 3
pyBM 0.6.2 new feature kinda pointless Dec 29 15:26 12
py2 py3 problems Dec 28 18:50 1
api / bmconfigparser / keys.dat Dec 28 12:56 6
dontconnect in pyBM 062 not being honoured Dec 27 22:11 2
mammoth Dec 27 18:40 1
want to goof around with data base ? Dec 27 14:04 1
sqlite has betrayed me Dec 27 06:46 5
200 watch, 2000 stars and 500 forks - sow where are the USERS ? Dec 27 04:22 19
DevTalk: pyBM code audit Dec 27 00:04 1
nice BM proggy Dec 26 19:20 1
stay dark on github Dec 26 16:17 4
Bitmessage to Shell Dec 26 16:07 1
CLI Dec 26 13:54 1
so I signed my pull request Dec 26 13:37 1
pygubu tkinter GUI builder Dec 26 11:34 3
clean up pyBM github landing page, please Dec 26 11:05 40
New bitmessage readme Dec 26 02:22 6
new BM GUI to be released Dec 26 01:59 8
DEMONSAW The Future is Clear PROMETHER The End of Surveillance Dec 25 21:56 1
Merry christmas everyone! Dec 25 13:40 6
collectd boot strap nodes Dec 24 15:26 5
which GUI widgets for BM ? Dec 24 15:25 4
Frohe Weihnachten! Dec 24 15:19 2
question Dec 24 13:42 8
BM Corporation Dec 24 10:46 3
tips for mammoth users Dec 24 05:04 3
BM collect daemon monitor over boot strap nodes Dec 23 21:24 16
BM collect daemon monitor over boot strap nodes - DEL known nodes to see it in netwk TAB Dec 23 14:37 1
dictionary attack Dec 23 10:38 1
DO NOT need spellchecker Dec 22 15:41 1
KDE dolphin "pyloader" launcher - how the fuck it works ? Dec 22 15:35 3
need spellchecker Dec 22 12:19 4