Exploits as defenses

Technical discussion about the NMDC and <a href="http://dcpp.net/ADC.html">ADC</A> protocol. The NMDC protocol is documented in the <a href="http://dcpp.net/wiki/">Wiki</a>, so feel free to refer to it.

Moderator: Moderators

Locked
Todi
Forum Moderator
Posts: 699
Joined: 2003-03-04 12:16
Contact:

Exploits as defenses

Post by Todi » 2004-03-19 07:30

I just read this article, and it made me curious as to how many defenses it would be possible to come up with if this kind of situation would come up for a user on direct connect (if it hasn't already).

The protocol is obviously not the best, we already know that due to various exploits and limitations. But which ones could be used as a defense in a court of law?

Media Sentry is most likely already on DC, i know i've seen bots connecting from their ip-range plenty of times myself. But what kind of evidence are they collecting? As far as i know, right now they are only doing active searches (i havn't seen any passive ones, which of course doesn't mean it's not possible), and are not actually downloading anything. So the question is, exactly how reliable is the information retrieved from active searches? The answer i suppose is, not at all.

As certain people are fond of saying, you can't trust anything you've recieved from another client, and you should usually not trust anything you've gotten from a hub either. So a searchresult can contain pretty much exactly what the user sending it wants it to contain, and i suppose since you don't expect a reply back it would even be possible to spoof the ip-adress somehow (i'll leave that to more knowledgeable people than myself).

Essentially, a searchresult is in no way any kind of proof that the ip-adress sending it was actually sharing the file in question, there is no real way to prove the user with the ip actually had the file (he could have spoofed the result, or had faked files), or that indeed the ip actually belonged to a user at all. Of course you'd have to convince a court of this..

The logical step after this would be for Media Sentry to start actually downloading files from users to have some kind of evidence. What kind of defences could be put forward in that case?

xhost+
Posts: 19
Joined: 2004-01-22 18:01
Location: in.the.middle.of.nowhere

Post by xhost+ » 2004-04-10 10:46

The only way to avoid trouble from intellectual rights protection organisms is by achieving total anonymity on the hub.
One way to do that would be by both encryption and man-in-the-middle transfer.
People have already discussed about ecryption, so I'll focus on indirect transfers:
For that a modification of the protocol must be undertaken.
I think that the DC protocol would not need a major upgrade to be able to guarantee anonymous transfers.
Here's how I see it : instead of a direct connection, we'll have to insert an anonymizer between A (the sink) and B (the source). A wants to download a file from B. A knows B via the hub as a nickname only, its IP is not available.
A's client selects a third user C (which can be the hub, but also another user although the hub would be better as it will be seen in what follows) and sends a request to C whose content will be "I want to know B's public key". C forwards this message to B (so C knows both A and B IP, and that A and B will initiate a transfer but has no idea of the content).
B sends its public key to C which forward it to A. A does not know the IP of B, only those of C. A will then select another user D and all transfers between A and B will go through D (the bridge) but all will be encrypted using B's public key. D does not know B's public key that is why it is better not to use another user as C but the hub instead because C will be forbidden to download from B since it would be able to fake a transfer having B think it is a bridge. B will answer using its private key to encrypt messages which it sends to A via D. A will use B's public key to decrypt them.
For me the only major modifications of the protocol would be :
- each client must have 2 types of slots : slots for uploading (be a source) and slot for forwarding (be a bridge)
- symetric encryption must be implemented in the protocol
All the rest is already available in the DC protocol (which will have to be renamed to something like iDC, for it becomes indirect...).

The major drawback is of course increased bandwidth usage, since all transfers will be doubled. But we can bypass its negative effect by cleverly selecting the Ds : either randomly shuffles all hub users for a bridge slot or monitor bridge bandwidth to drop a bridge if its speed goes below a defined limit.
This is my "high level" vision. Does anybody here has any idea of the amount of workload it would take to implement such a protocol? Do you see any flaws in it? Is this the way that freenet stuff works?

xhost+

Pofis
Posts: 14
Joined: 2003-11-25 14:06
Location: Portugal
Contact:

Post by Pofis » 2004-04-11 05:41

Seems a good ideia to me :D
Offcourse, for it to work well all the clients need to agree with this new changes in the protocol. let's see what arne thinks of this.
anyway, if this ideia move ahead i would like to help you guys.

Btw, The fact of needing a public key can move away the newbys, which can be seen as a good thing :p

Pofis

HaArD
Posts: 147
Joined: 2003-01-04 02:20
Location: Canada http://hub-link.sf.net
Contact:

Post by HaArD » 2004-04-11 06:26

FYI: The courts ruled against the CRIA in that case....

So, for now anyway, sharing music files is totally legal in Canada.

Fixed the link /Todi

HaArD
Posts: 147
Joined: 2003-01-04 02:20
Location: Canada http://hub-link.sf.net
Contact:

Post by HaArD » 2004-04-11 06:28

stupidfreakingforumsettingscan'teditmyowndamnpostsdamntyposgrumblemumblemumble

Alexei Kubarev
Posts: 18
Joined: 2004-04-08 15:46
Location: Sweden
Contact:

Post by Alexei Kubarev » 2004-04-11 08:06

Nice post ;) The last one ofcource ;)

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2004-04-11 15:36

If you want anonymous filesharing, Direct Connect is not for you. ADC (one next-gen DC protocol) is not moving in this direction either.

cyberal
Posts: 360
Joined: 2003-05-16 05:42

Re: Exploits as defenses

Post by cyberal » 2004-04-11 16:16

Todi wrote:Essentially, a searchresult is in no way any kind of proof that the ip-adress sending it was actually sharing the file in question, there is no real way to prove the user with the ip actually had the file (he could have spoofed the result, or had faked files), or that indeed the ip actually belonged to a user at all. Of course you'd have to convince a court of this..
sure, a UDP search result alone is not proof.. but one connection attempt is enough to verify the users IP.
http://whyrar.omfg.se - Guide to RAR and DC behaviour!
http://bodstrom.omfg.se - Bodströmsamhället, Länksamling om hoten mot vår personliga integritet

Qbert
Posts: 73
Joined: 2003-06-07 03:12

Post by Qbert » 2004-04-11 17:27

cyberal wrote:but one connection attempt is enough to verify the users IP.
With that knowledge they can then only warn the person, hoping that they don't know better. A copyrighted piece of work must still be obtained for the actual proof that they are normally alleging. (There are other things they could allege that the user is breaking the law, but that probably wouldn't be their place.) The piece of work is still illegal if it's only a partial copyrighted work, (how large of it I don't know but am interested in finding out.)

More discussion of this exactly was at
http://dcplusplus.sourceforge.net/forum ... 6424#46116
Todi wrote:But which ones could be used as a defense in a court of law?
I’m very much interested in studying how mathematically sound the following link is in not being able to readily detect more data.
http://lcamtuf.coredump.cx/ wrote:A tool for the ultra-paranoid, 2c2 implements sort of a deniable (and thus subpoena-proof) encryption by creating a file that can be decrypted into several variants, depending on the key, and for which the presence of any of the variants cannot be detected without knowing the key.
Twocrypt v2 Readme wrote:2c2 is a simple symmetric file encryption utility. It comes with an
interesting optional feature - it is capable to embed an additional file
within an encrypted data. This is done in a way that cannot be detected
without knowing the passphrase protecting the "hidden" file, even if the
password for the primary file is disclosed. The design is such that the
fact of using this method alone does not constitute a credible evidence of
data hiding (IANALBMSUTDO). This kind of encryption is also called
"subpoena-proof" or "deniable".
My Visual Studio .NET 2003 is licensed under my name, and the same for my operating system... What about you?
I surf on an OC3 without limitations, two to be exact, and I'm not joking.

Locked