ADC, not NMDC, can support multiple share profiles

NMDC cannot support multiple shares within a single client for the same reasons that it’s vulnerable to nick-faking; client-client connections cannot be unambiguously correlated. Identifying arbitrary client-client connections with the hubs from which they emanate is actually simpler than precluding nick-faking; any protocol which can prevent such an exploit, which requires characterizing not only the hub but the specific user, has the required machinery to allow unambiguous multiple share support. Because ADC can prevent nick-faking, it can also provide multiple share support in a manner unavailable to NMDC.

Whilst a protocol capable of identifying both user and hub can trivially identify a subset of that information and therefore the hub, which is sufficient for multiple share support, that doesn’t imply the converse of a protocol not identifying both the user and the hub being unable to identify just the hub, alternatively sufficient. However, when applied to NMDC and ADC the converse holds true. A gap between this claim and its converse would appear in NMDC having some mechanism capable of identifying hub, but not user. However, because in C-C connections, the sole identification of a nick is not hub-centric, but rather user-centric, such a gap mechanism does not occur. Therefore, one can reasonably conclude that no additional method beyond those previously discussed and dismissed exists within NMDC that would otherwise, after all, allow it potential ADC-level multiple share functionality.

Finally, though the CTM token of ADC has weaknesses, these are, both by contrast with NMDC’s client-client user identification weaknesses and in absolute terms, negligible. In particular, multiple users can collude across hubs to produce identical CTM tokens, and even sans such active malice, such a situation can by chance occur. However, multiple remote clients capable of cooperating to that degree might as well be treated as one client; indeed, a single remote client can behave arbitrarily whilst claiming a constant CTM token as well, so such collusion doesn’t actually increase vulnerability. The situation occurring by chance also fails to warrant substantial concern, provided a high-quality randomness source. This is an example of a birthday attack; the chances of such a collision remain negligibly small with at least 128 bits of randomness even with a large number of CTM tokens drawn.

As none of these weaknesses poses as substantial a threat to reliable identification of a C-C user with an identity derived from an existing hub as exists in NMDC, and indeed a negligible threat at all, ADC-based systems can well function to provide functionality that NMDC-based systems not only historically have not but theoretically cannot robustly and reliably provide, including multiple share support, resistance to nick-faking, and any other feature dependent on associating client-client connections with hub users.

Don’t forget that you can make topic suggestions for blog posts in our “Blog Topic Suggestion Box!”

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: