Protocol

This P2P protocol was proposed by a bunch of current and graduated university students who wanted to explore the concept of a secure, reliable, truly peer-to-peer network. (And also to make it to be harder to get in trouble sharing files on the university network.)

The goals are to:

Note: this protocol will be slow (even slower than DC/ADC) for a few reasons:

  1. it uses encryption — making it secure, but more CPU-intensive
  2. it is hubless — making the network more robust (and making blame more transient), but requiring overhead in establishing and maintaining a mesh
  3. it uses TCP for everything — making it more reliable, but slower

Messages

4CC Message Payload† Action
BCHA broadcast chat TTL, oIP, nick, message display as chat; forward to all peers (except sender)
BFND broadcast: find file hash TTL, oIP, hash* if a matching file is found, send RFND
BFNN broadcast: find file name TTL, oIP, name** if a matching file is found, send RFNN
BFNI broadcast: find file info min.size, max.size, name** if a matching file is found, send RFNI
PCHA private chat nick, message display as private chat
PFNF File not found hash (*)
PGFI GET file hash, start, end, chunksize if a matching file is found, send PSFI; else send PFNF
PHFI HEAD file hash if a matching file is found, send PIFI; else send PFNF
PIFI Info file hash, file modified time, file size (*)
PING ping message send PONG(message) back to sender
PONG ping response message (*)
PPRT open ports comma-delimited list of ports, in Base32-encoding (*)
PSFI send file chunk hash, start, size, chunk (*)
QPRT query open ports   send PPRT
RFND response: found file hash hash (*)
RFNN response: found file name hash, name (*)
RFNI response: found file info min.size, max.size, hash, name (*)
WQRY web-of-trust query uID if the client knows about the user, send WVER
WVER web-of-trust verify uID, level of belief, level of trust (*)
† all message payloads include Origin-ID
* file hash value -1 means 'file list,' and may be ignored when appropriate
** file name may contain wildcards [*?]
(*) message is in response to a request; handle it appropriately

Client

At first I'm going to write the client in Java, because it's got a good API.

The client will support establishing secure connections (including public-key cryptography with sessions), building webs of trust, and discovering a mesh network of peers. Oh, and of course the whole file-transfer thing.

Web of Trust

Client have a level of belief and a level of trust in peers. Belief is confidence that the peer is who it purports to be. Trust is confidence that someone introduced by that peer is who they say they are. (Trust ≤ Belief)

Levels of belief and trust take integer values from {0, 1, 2}, where 0 means little or no belief/trust, 1 means partial, and 2 means total.

A peer (B) may introduce another peer (C) to the client (A), in which case A's level of belief in C may be established by the following forumla:

AbC ⇐ MAX( BbC + AtB - 2, 0 )

(where AbC is A's belief in C, BbC is B's belief in C, and AtB is A's trust in B.)

The finite state table of the formula is:

AtB BbC AbC
0 0 0
0 1 0
0 2 0
1 0 0
1 1 0
1 2 1
2 0 0
2 1 1
2 2 2

Port Jiggery-Pokery

In the interest of being interesting, the client could introduce a bit of message spoofing, making the interception of data (and discovery of existence of the network) even less trivial.

An example might be having clients open ports 80, 8080, and 8000 and using a very cut-down version of the HTTP protocol to send and recieve embedded messages on those ports.

This could be a query/response sent over pseudo-HTTP:

POST /random/crap.html HTTP/1.1
Host: ip.ip.ip.ip
Accept: text/plain, text/html, image/gif, image/jpeg
User-Agent: SimpleHttpClient/0.8
Content-Length: ##
Content-Type: application/x-www-form-urlencoded

{P2P-QUERY-MESSAGE-IN-URLENCODED-FORMAT}
200: Ok
Content-Type: application/octet-stream
Content-Length: ##

{P2P-RESPONSE-MESSAGE-IN-RAW-CYPHERTEXT}

Any genuine HTTP request (one that isn't a POST, with a valid message in the query) would receive a valid HTTP 4xx or 5xx response.

Things to note:

Things to Consider

From Bronson: