Sending ACKs from hidden messages

[chan] bitmessage
Oct 12 16:27

Hi Peter, all, I'd like to start a discussion around PR1067 https://github.com/Bitmessage/PyBitmessage/pull/1067, as I'm not 100% convinced by the arguments that have been put forward. Currently, PyBitmessage ignores the ACK objects enclosed in type zero messages, breaking the standard protocol behaviour. Specifically, even if the destination address advertises that will send ACKs in its pubkey bitfield, and the message contains an ACK, if the message encoding is set to zero ("invisible") the ACK will not be sent, which is contrary to the protocol definition and the senders' expectation. It results in rebroadcasts and resource usage on sender side (because each rebroadcast requires new POW). PR1067 enables standard ACK processing for hidden messages. The reason for rejection was that it can be abused as an attack vector for deanonymisation, which is true. I would like to discuss and understand the risks and benefits a little more: 1) At a network-wide level, the ability to send ACKs from invisible messages has documented privacy benefits. For example, a use case from the original whitepaper (chapter 7 "passive operating mode") is increasing ACK anonymity by wrapping the original ACK in a message to another network user. In that case, the privacy is improved if the wrapper message is hidden, as Charlie is (legally) unaware that he is being used by Bradley as a reflector for Alice's ACK. And there are more interesting uses of the ACK mechanism for privacy enhancement purposes (remailers etc) that would benefit from network-wide protocol consistency. 2) At an individual level, honoring ACKs in hidden messages does not create a new attack vector. What it does is change a well-known, overt attack vector into a covert one. What could be achieved with hidden message ACKs can already be achieved today with visible messages “testing bitmessage, please ignore” or “unknown encoding” or “hack your spouse” and the only difference is that right now the attack could be noticed, but still not BLOCKED (other than by going fully offline). At the end of the day, the “dontsendack” flag is, and will remain the main control switch for any user concerned about ACK privacy. What I want to understand is: is the small privacy loss from point 2 more important than the small privacy gain from point 1? And is all this significant enough to justify a protocol inconsistency in pyBitmessage? And if yes, perhaps making this behaviour optional (via a “don't ack hidden messages” boolean) would be a better solution to address the different needs of different users? Ultimately, I respect the experience of the senior developers and will defer to their decision. I just want to make sure we're not missing out on a potential privacy-enhancing feature. Let's discuss.

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Oct 12 17:53

Hi, thank you for the feedback. > 1) At a network-wide level, the ability to send ACKs from invisible > messages has documented privacy benefits. For example, a use case > from the original whitepaper (chapter 7 "passive operating mode") is > increasing ACK anonymity by wrapping the original ACK in a message > to another network user. Yes, onion routing (although the whitepaper doesn't use that name). I want to move onion routing into a separate "thing". I'll probably just repurpose encoding 0. However, this will be opt-in, indicated by a bitfield. If you look at the protocol specification page in the wiki, it says bit 27 = onion_router (proposal). BTW, when I present about bitmessage, I do mention onion routing capability, and also that it's currently disabled for security reasons. Onion routing can benefit from some further tweaks, like TTL optimisation, online signaling and so on, and they should also have a separate interface (e.g. ordering in the "Messages" tab, or putting them into a separate tab). The pubkey objects for onion routers could be unencrypted so that anyone can use them, and have a shorter TTL to indicate when the router is online. There could also be further anonymisation increase by fragmentation and/or padding capabilities but I haven't thought about the design yet. They also could have the "normal" functionality disabled so that they only act as onion routers but not as normal senders/recipients. Onion routing will have further benefits when streams are implemented. > 2) At an individual level, honoring ACKs in hidden messages does not > create a new attack vector. What it does is change a well-known, > overt attack vector into a covert one. Correct. This would allow things like sending short-TTL-ed messages 24/7, and result in a fine-grained detection of when the target is online. Or if two addresses are hosted by the same node. If it's stealthy, you can do it over days/weeks without the target being aware of anything. This data can be used as additional input together with other deanonymisation techniques. > What I want to understand is: is the small privacy loss from point 2 > more important than the small privacy gain from point 1? There are other alternatives, like the one I described above. If you want, you can submit a pull requests that implements bitfield 27 and nothing else. The optimisation can be done incrementally. > And if yes, perhaps making this behaviour optional > (via a “don't ack hidden messages” boolean) would be a better > solution to address the different needs of different users? Or the converse, "do ack hidden messages" boolean, which is what my proposal is. > Ultimately, I respect the experience of the senior developers and > will defer to their decision. I just want to make sure we're not > missing out on a potential privacy-enhancing feature. I don't think I have some uber security experience (although I've been programming for 30 years and did work for a credit card payments company among other things). I prefer heuristics and other experts giving me feedback. One thing that I do is "default to more anonymity for myself" (i.e. the person running the software), which is why UPnP is disabled by default, and if you're on tor, by default you aren't accepting incoming connections and local peer discovery is disabled. It's also why I requested public feedback on peer discovery before implementing it. > Let's discuss. Ok. Let's make it opt-in, and incrementally optimise. Later, there could also be some wizard which will ask if you want to add an onion router address on first launch, or there could be heuristics which when detect you're online all the time, would recommend activating it. Peter Surda Bitmessage core developer

[chan] bitmessage
Oct 12 22:57

Peter, thanks for the clarifications. I should have asked the question before going ahead and submitting the PR. :) >> increasing ACK anonymity by wrapping the original ACK in a message to another network user. > Yes, onion routing (although the whitepaper doesn't use that name). I want to move onion routing into a separate "thing". I'll probably just repurpose encoding 0. However, this will be opt-in, indicated by a bitfield. If you look at the protocol specification page in the wiki, it says bit 27 = onion_router (proposal). > Onion routing can benefit from some further tweaks In brief, you are considering conflating hidden messages under onion routing, using bit 27 and encoding type zero. This makes sense from a certain perspective (there are significant overlaps between the two), but there is also potential to cause confusion and possibly break some existing edge cases: 1) I think, and will detail later, that there are use cases for type zero hidden messages outside of onion routing, and possibly even onion routing methods that don't use hidden messages; also, as you said, onion routing has a different set of optimizations and warnings. 2) I think we should not conflate technical capability (sending ACKs) with advertised intention (acting as onion router). Even if technically they're mostly the same under the hood, in the non-technical world they can have different connotations, perhaps even opposite: to some people, standards compliance is commendable, onion routing is subversive. >Correct. This would allow things like sending short-TTL-ed messages 24/7, and result in a fine-grained detection of when the target is online. Or if two addresses are hosted by the same node. If it's stealthy, you can do it over days/weeks without the target being aware of anything. Yes, the covert factor is indeed a significant issue, however note that there's nothing (except going whitelist-only) to stop a would-be attacker from doing the above OVERTLY right now. That it doesn't happen tells me that, from an attacker's perspective, the outcome is probably not worth the effort compared to other methods currently in use. > If you want, you can submit a pull requests that implements bitfield 27 and nothing else... > ... "do ack hidden messages" boolean, which is what my proposal is. This makes a lot of sense. I have an idea that may cover the onion routing feature, the edge cases and everything in between, but uses two bits from the bitfield. I'll send as a separate message and would like to know your thoughts.

[chan] bitmessage
Oct 12 23:14

Hi again, As I said, I think the current roadmap to onion routing and hidden message acknowledgements may cause some confusion and risks breaking some legitimate use cases. I suggest that a healthy balance could be achieved by using two separate bitfield bits (existing onion_router and a new bit send_hidden_ack) to control hidden ACK sending and onion routing independently from each other. To illustrate, I'll use some back-alley pseudocode: 1) Original (pre-mitigations) behaviour: “If message decrypted correctly, then if my address does_ack, then send the ACK” 2) Current behaviour: “If message decrypted correctly, then if my address does_ack, then send the ACK, except if the message is hidden, in which case drop the ACK” 3) Current roadmap behaviour: “If message decrypted correctly, then if my address does_ack, then send the ACK, except if the message is hidden, in which case drop the ACK, except if my address is also onion_router, in which case DO send the ACK, but also route onions, and optimize operation for onion routing etc, as an all-or-nothing bundle” # notice it's a bit hard to follow and what if I just want to send the ACK? 3b) Proposed behaviour using a second bit “does_hidden_ack”, 0 by default: “If message decrypted correctly, then if my address does_ack, then send the ACK, except if the message is hidden, then if my address does_hidden_ack, then send the ACK, in all other cases drop the ACK”, and independently from all of the above: “If my address is onion_router, then optimize for onion routing and do other cool things that onions do but regular addresses don't – promiscuous uptime protocol etc”, and finally: “Warn if onion_router is used without does_ack” Cons: uses two bits from the bitfield, adds complexity. Pros: mainly deriving from having independent controls for hidden acks and the full onion router behaviour: - cleaner and easier to understand - can perform stealth onion routing as a sub-channel of regular text messages, not just type zero (deniability is realized in this case via PR1062 that puts realistic message-like objects in the ack slot of regular non-onion messages, further blurring the distinction between ACKs and text messages) - can enable hidden message ACK functionality without advertising as an onion router, for non-onion use cases such as targeted public key distribution etc. Basically, it puts full control in the hands of the user, without cutting corners or forced bundling, and enables modular development and testing of clip-on solutions based on the ACK mechanism (like onion routing) without requiring changes in the object layer, or breaking compatibility with other clients. What do you think?

[chan] bitmessage
Oct 12 23:49

First, PyBitmessage is not violating the spec by ignoring ACKs in message encoded 0 messages. The spec says "Any data with this number may be ignored" so the pubkey, message, ack, and/or signature can be ignored (although technically it doesn't make sense to verify the signature if the pubkey is ignored). Second, the spec also says that "The sending node might simply be sharing its public key with you" which implies it is acceptable to use message encoding 0 to privately convey a pubkey. This is quite a neat feature allowing users to not publish pubkeys publicly and/or customize pubkeys for individual contacts by specifying different PoW difficulties and behavor bitfields. eg a user could specify that they will send ACKs for, and/or accept multi-part messages from, specific contacts. Implementations could easily generate a template message for message encoding 0 (similar to what PyBitmessage does currently) indicating the senders changed preferences for communicating with them. Message encoding 0 messages are only "hidden" in the sense that the spec only has 2 sentences about them thus implementors don't know what to do with them.

[chan] bitmessage
Oct 13 00:25

"In general engineering design contexts, the principle can be taken to mean that a component of a system should behave in a manner consistent with how users of that component are likely to expect it to behave; that is, users should not be astonished at the way it behaves" https://en.wikipedia.org/wiki/Principle_of_least_astonishment

[chan] bitmessage
Oct 13 01:14

So which is least astonishing, that something that may be ignored: a) is ignored, or b) is not ignored?

[chan] bitmessage
Oct 13 01:56

Tough question. Both answers are equally unastonishing. Perhaps the more relevant "hidden" question is which is least astonishing, that the encoding field effects: a) only how the message field is processed, or b) how any field in the msg object is processed? Since only 1 out of the 4 message encodings effects a field other than the message field then clearly (a) is least astonishing and therefore it is astonishing that ACKs are handled differently depending on the encoding of the message field.

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Oct 13 11:31

Well, since Bitmessage has a special security purpose, perhaps the correct "least astonishing" option should be if none of the adversaries show up at your doorstep because they deanonymised you. https://www.youtube.com/watch?v=_bSEfx6D8mA Peter Surda Bitmessage core developer

[chan] bitmessage
Oct 13 13:59

You make some very good points. The more I think about the attack that Peter described, I realize that the one-line patch from PR1067 was not the right way to do it. So thanks Peter for rejecting it. :) To summarise my previous stream-of-consciousness message, I think there should be several different levels on the privacy / functionality scale of an address object: - 0: send no ACKs - the equivalent of "dontsendack=True" in the current version, or setting the send_ack - 1: send ACKs from visible messages only - this is the default setting in the current version - 2: send ACKs from all message objects, visible and invisible - there is no such option currently; I suggested using a separate bit "send_hidden_acks" or similar - 3: act as an onion router, advertise this publicly and enable optimizations - the planned "onion_router" bit 27. Retaining option 1 as default seems like the safest option going forward. Really interesting discussion about the POLA, however in this case the proverbial balance between security and convenience appears pretty compelling to me. The ensuing astonishment can be smoothed a bit by documenting the hows and whys, and by providing an option to enable (at own risk) the "expected" behaviour. I also strongly believe that there is a technical need for the option 2 between 1 and 3. As long as this defaults to disabled and requires manually activation as an "advanced setting", it shouldn't introduce an extra risk to the average user. My only concern is at a protocol design level, about the sub-optimal use of the bitfield space. Long-term, the ability that you mentioned below, to customize and push these settings individually for each addressbook entry shows serious promise from a "choose what to share and with whom" angle, considering that currently users only have an all-or-nothing choice. Separate topic for some other time. Any thoughts or suggestions?

[chan] bitmessage
Oct 13 14:02

You make some very good points. The proverbial balance between and messages only concern is the POLA, however in message encoded messages only concern is a bit send no Acks in the right way to do it. To summarise my previous stream of the POLA, however in the more I realize that you mentioned below, to disabled and As this case the ensuing astonishment can be several different levels on the send no acks in the more I suggested using a separate bit send no Acks from all message, objects, visible messages only have an advanced setting the bitfield space. Any thoughts or similar act as this is a technical need for the spec only have an all message I think about the enable optimizations the one line patch from all message objects, visible messages only have an all message encoding to me; in the expected behaviour. My previous stream of the average user; choose what to enable optimizations the average user. Any thoughts or suggestions?

[chan] bitmessage
Oct 13 16:25

Thought: this Markov messages are gettin better, AI behind them? Suggestion: Never mind, motherfucka, just fuck ya brain off!

[chan] bitmessage
BM-2cWy7cvHoq3f1rYMerRJp8PT653jjSuEdY

Subject Last Count
Bitmessage security suggestion Feb 21 04:26 3
Bitmessage feature request for API commands Feb 20 23:00 1
bitmessage launches cmd and then powershell Feb 20 19:23 43
I want the FEDS on this chan to know I identified one of their new tactics. Feb 20 12:03 2
Mitigating exploited software with firejail Feb 19 22:42 8
Critical vulnerability in v0.6.2 Feb 19 16:51 50
message database seems to be corrupted after all that upgraes and attacks Feb 19 14:55 7
Since upgrading yesterday to 6.3.2, Bitmessage is not connecting Feb 19 11:12 7
Inflood of old messages Feb 18 19:16 23
It is slow making connection. Feb 18 18:04 1
Globewashing Feb 18 17:44 1
how to make bitmessage secure Feb 18 05:02 1
Are you blacklisted/whitelisted? Feb 18 04:19 2
Are Linux systems vulnerable to recent attack? Feb 18 02:19 12
Are you blacklisted? Feb 18 02:09 1
address on Peter's reddit account Feb 17 23:51 3
Can't add entries to black list using Add Entry button Feb 17 15:20 4
Errors while trying to run 0.6.2 or 0.6.1 Feb 17 15:20 4
Bitmessage project looking for auditors and/or security specialists (reddit crosspost) Feb 17 13:21 6
HIRE A HACKER/CHANGE GRADES Feb 17 08:59 2
Download it. Feb 17 07:59 2
passphrase strength ? Feb 16 20:34 8
$ cd PyBitmessage ; git log | grep Author | sort -u | blacklist Feb 16 15:54 18
diagram Feb 16 01:46 1
Bitmessage components security seclusion example Feb 16 01:24 1
⩩ 𐄉 ㎮ ䷦ 🞳 🆁 ㍝  f 𝙲 🄦 ➇ ⨘ ㊳ 𝐗 ⦱ 󿿻  🄹 𝟒  ䷄  K  🆙  ䷤ 𝐙  ⒄ ₹ ꠲  Feb 16 00:04 1
NOTICE: Address Revocation Feb 15 18:28 12
Cannot connect since yesterday Feb 15 17:59 2
Questions regarding recent bitmessage data exploit Feb 15 03:46 2
Latest commit borked Feb 14 05:26 5
BM-onion Feb 14 05:22 5
That's my new address Feb 14 03:40 1
BM massacre! Feb 13 21:23 2
Namecoin integration Feb 13 20:18 11
Hashwalling Functions for Security Feb 13 17:58 2
Same old problem connecting to network Feb 13 17:12 4
Injection attack mitigation Feb 13 16:52 7
This denial of service shit needs to be patched Feb 13 12:00 7
Test Feb 13 11:37 1
Proving that BM was sent? Feb 13 11:07 10
bitmessage ... Feb 13 08:13 1
Improve icon for chan + messages: important or not Feb 13 05:25 2
pickle puzzle Feb 13 01:03 20
so happy Feb 12 16:32 2
Fwd: Re: Did everyone else's BM starting freezing up Feb 11 03:54 10
hacker service Feb 10 03:48 2
another feature request Feb 10 01:12 1
bitmessage feature request Feb 10 01:10 1
feature request Feb 10 01:04 1
Questions for the Bitmessage Community Feb 9 21:30 7
Did everyone else's BM starting freezing up Feb 9 03:21 4
A light weight version of the denial of service message Feb 8 13:22 3
RE: Hello. Feb 8 11:48 1
WWtest Feb 8 10:44 1
test1 Feb 8 10:37 1
WARNING! denial of service message Feb 8 10:19 3
extended encoding Feb 8 01:24 7
bountyfy -- 7 € payout Feb 5 20:59 2
clean up pyBM github landing page, please Feb 4 23:00 2
Running BM daemon as a service Feb 4 13:47 6
hidden service - long names Feb 4 12:37 7
RAM consumption - RAM not released Feb 3 21:05 4
Bug? First connection quickly breaks Feb 3 11:41 6
Request: debug.log initialization / termination Feb 2 18:30 2
kqueue poller in asyncore bounty -- no payout Feb 2 14:23 5
Bitmessage bug in Help > About Feb 2 13:59 7
Message size is metadata Feb 2 13:25 6
New warning "sni-qt/5864" WARN Feb 2 12:12 2
ordering Feb 1 10:38 12
RAM consumption Feb 1 10:14 5
discrepancy in transmit/receive byte counts Feb 1 07:53 6
BM CPU time Feb 1 02:39 5
kqueue poller in asyncore bounty Feb 1 00:13 15
new theme for beamstat Jan 31 11:35 2
Support request -- dontconnect in pyBM 062 not being honoured Jan 31 10:16 1
python IDE Jan 31 10:15 2
My BM is connected to one peer twice Jan 30 06:36 7
Support request/Bug report: keys.dat gets corrupted when running out of disk space Jan 29 15:44 2
Feature request/idea/suggestion: user-defined data directory (command-line argument) Jan 29 15:16 2
GUI dontsendack Jan 29 05:15 1
Another message problem Jan 29 03:49 3
Message deletion broken Jan 29 00:28 3
bitmessage on android device Jan 29 00:03 1
#1 Jan 27 10:12 1
/src/helper_* python files ? Jan 27 04:53 3
Dandelion + supervising BM ? Jan 26 18:41 2
CPU time : connection frequency - patch Jan 24 22:40 4
huge spike Jan 24 12:31 1