A Constantly Variable "Entropy Mechanism" for Verifying BitTorrent Clients
(but usable by other "thin" clients)




Abstract

Since the late 2010s (in North America, as well as Europe and Australasia) many private IT companies have set up fake BitTorrent clients for no other purpose but to "legally entrap" people for "copyright" violation reasons. The legal and moral grounds for doing this are often nebulous, and in no way ever take into account how computer networks are actually used [or the meaningful legality of the copyright law in force].

Because of the porous nature of most Internet networks, Internet users that have no idea what BitTorrent is -- can be falsely accused of copyright violation. Once accused the Internet user [in many nations] often has limited or non-existent legal recourse.

Many ISPs don't like being forced to enforce national copyright laws, as drains their limited resources. It is either provide for customer service, or enforce copyright laws. A servant cannot have two masters, so this leads to a much less reliable (and much less stable) Internet. Sadly, those involved with Internet copyright law enforcement don't care if the Internet is working or not. Incomes are only possible from Internet copyright law enforcement due to governmental corruption, as the objects traded over the Internet are not physical objects.

Only by routing out the "untrustworthy" BitTorrent clients (and networks) can nations -- as well as individual internet users -- regain their sovereignty.

Overview

In North America many large ISP networks (like the Microsoft Network, but the Facebook network is no different) are subject to ~99% traffic interception mainly from the ECHELON system.
BitTorrent traffic has no strategic or military value, and probably never will -- because of the bizarre ways BitTorrent technologies work. However, there are issues beyond the copyright and trademark system [in the parts of the world influenced by Europe] that are not helping the Internet.

There are private companies with mini-ECHELON interception systems that do nothing but track BitTorrent traffic. This unwarranted interception leads to many false accusations of copyright violation, via the ISP. This arrangement can only lead to further civil rights abuses in future. Forcing ISPs to be fully knowledgeable about the traffic they carry is a fool's errand, because the Internet has hundreds of secure protocols.

Specifically, in the case of Australia, Canada and New Zealand (and parts of the European Union) the civil society state of the Internet is not healthy for cultural reasons.
BitTorrent describes over 20 computer protocols, and at least one primary and 5 ancillary file formats. BitTorrent (as a technology) is mess that very few BitTorrent clients (and trackers) have managed to tame. Yet, in spite of ongoing technological problems at least 20% of global Internet traffic is BitTorrent -- for the simple reason that no other protocol can allow one to download files reliably over the Internet.

Simply by excluding BitTorrent clients via a verification mechanism (implying that the client is controlled by a real person), normal BitTorrent traffic patterns on the Internet may return hopefully freer from unwarranted interception.



The Constantly Variable Entropy Solution


OVERVIEW

Each BitTorrent client must verify each other BitTorrent client before any "Client to Client" communications can begin. If a client does not verify, it must be treated as untrustworthy. The verification must be done outside any and all BitTorrent related protocols.

Tracker websites must also be able to verify if a BitTorrent client is real or not for security and legal reasons.

No other options are workable.

However, whatever solution that is devised must work equally with "Open Source" and "Closed Source" clients. On top of this the solution must be fully automatable. The clients must be able to come up with their own permutations on bits and bytes that are mutually transmittable to each other over an unreliable channel.

Client to Client Communication Mechanism
Client to Tracker Communications Mechanism

The Entropy Solution (client application)

SSL Certificate Size
Port Knock Entropy
Entropy files
Entropy file size
Entropy file change (daily)
VM Capability
Initial (0.1a - 0.5b) 64 bits
10123 ^ 7
2
32 k
8 k per file
1 KB code, 3 arrays
Intermediate
256 bits
11456 ^ 9
3
48 k
16 k per file
2 KB code, 4 arrays
Final (1.0 - 3.0)
1024 bits
12101 ^ 12
5
64 k
32 k per file
3 KB code, 5 arrays
Future (9.0 - 25.0)
2048 bits
16384 ^ 16
8
64 k + salt
64 k over all files
4 KB code, 8 arrays

Note

State machine (client setup)
Ideally, the Entropy Files should be changed daily -- with total entropy replacement every 10 to 15 days.

The entropy subsystem provided by the BitTorrent (or any other thin client that needs this kind of verification) should be a self contained Java application on the server side (with a user interface).

Failing the use of Java, an ADA 95 or Erlang client could be able to handle all the required server side tasks. In theory, once operational -- the client side of the equation should take up very little CPU time.

State machine (client to client verification)

Note
A low complexity (and low bandwidth) "Virtual Machine" (VM) is needed for this to work. ALL VM TRANSACTIONS MUST TAKE PLACE IN A SECURE TUNNEL.
Each VM communication must provide a Version Number and an "out of band" set of hashsums to verify the VM state machine has been transmitted properly. The VM code itself must contain internal checksums and hashsums for integrity verification. The VM instructions should contain their own parity bits.


The VM specification

Instruction coding format (binary)
Instructions should at most have 3 parameters of 3 bits per parameter.
Use "Signed Ints" (16 bits).
The "Signed Bit" is the Instruction Parity Bit.
The Instruction Parity Bit should be Odd Parity.

Instructions will have to have all parameters not contained in the instruction directly following the instruction. This varies on an instruction by instruction basis.

This instruction parameter handling practice is logically reasonable. Almost all 8 bit and 16 bit computers have used this same exact practice. The x86 line of CPUs have used this practice since the beginning. Java VMs (a classical 8 bit VM) to this day use this practice without any problems whatsoever.

Instruction coding format, binary field
The overall instruction syntax should be
 Other VM issues


State machine (client to client; code generation for verification)

In a way this is the most important and most difficult part of the VM idea. Clearly, the Header and Footer of the generated code for verification process are only going to change slightly over time and can be ignored as part of the code generation process.

Clearly the computational parts can be sectored off like this

By designating in some kind of 'meta-code'

A lot of the design elements of the code are really up to the entity or open source group that produces the Torrent Client in the 1st place. All of the coding should be open source so as to ferret out security problems, and to provide something for the programmer user base of the Torrent Client something to do.

About 128 completely interchangeable code fragments (of various functions) will be needed for each client, but with file compression there should only be about a 100k penalty for disk space. 

In general, using these code segments would involve this kind of state machine behaviour 

  1. Once running, update : VM, Entropy Files, Code Segments. [Save state at each update stage...]
  2. If already hosting files, begin Seeding. Put VM in temporary rest state, or generate verification code.
  3. In the DHT or Tracker provided lists of other clients -- find other like clients for verification before transferring any data.
  4. Do these clients support verification? Maybe filter out those that don't.
  5. Generate verification VM code. 
  6. Determine the outcome of the VM code. Store outcome and code. 
  7. Send code via secure [vendor or program specific] channel to unverified client. 
  8. Wait client results.
  9. Receive client results.
  10. Verify client results. 
  11. If Client verifies OK, proceed with normal communications ...
  12. If Client does not verify, peruse multiple evasive tactics ... based on policy. 

A lot of state machine and code debugging aspects have not been covered here. There is a lot of possible complexity here, but the key is simplicity. Reduction of complexity here can keep the VM lean and efficient.

State machine (client to tracker website, bad client notification)

Inevitably, the bad clients and bad networks (or at least bad IP addresses) will be sorted out by this kind of approach by about 3 to 4 months after this verification method is mandatory.

However, ongoing verification to the tracker websites will be needed indefinitely. This is assisted by the fact that clients do communicate with private trackers on an ongoing basis -- to indicate how much has been transferred per file over time or recently. Currently BitTorrent has no formally standardised state machine for Tracker-Client communications. The BitTorrent Tracker-Client protocols are not many, but with a small amount of reuse and re-configuration of the existing protocols there is room.

What the Client must tell the Private Tracker
  1. This reverse verification mechanism applies to Private Trackers only.
  2. Some way must be found to inform the Client that the Tracker is of the Private type, unless there are ways of doing this that are already clear.
  3. If there is no way to avoid contacting Public trackers, this will end up with Public trackers being swamped with requests to send a type of information that does not apply to them. 
  4. A policy set must be in place [by Clients and Trackers] to deal with older Clients that don't have this verification mechanism.

Protocol information


Alternate ideas worth considering

You don't need a full blown VM state machine with a variable entropy store to verify thing clients. Entropy stores are a solid idea, but even thinner methods should be tried and considered.

Port Knocking

Port Knocking Math



References

Random number generation
Languages suitable for VM development

Virtual Machines

Secure Tunnel Protocols

Port Knocking




Created by
Max Power

Initial idea
05 March 2013

Created
07 March 2013

Last Updated
24 March 2013
added references