I have always been interested in P2P Networks and Clients and would like to know what features people of this forum would put in them. Here are my ideas:

Connection:

LAN Peer Discovery (Broadcast?)
Bootstrap Connections : Automatic startup nodes that will send the new node about 10 nodes currently connected to the network
Discovered Peers : Peers discovered while using the program are kept in a file, and are queried once joining the network again (this does not include startup nodes)
Brute Force Peer Discovery : Sending handshakes to each IP address in order (a little archaic imo, but necessary if the rest fail)

Handshake:

Obfuscate data in HTML Packets (looks like a regular HTTP packet)
Diffie Hellman Key Exchange
Transfer the Diffie Hellman elected numbers within HTTP packets (obfuscation)
Connection agreement has been reached once each node sends the other node an Encrypted HELO message (that gets successfully decrypted by the other node)
All Nodes will have this handshake regime

Packets:

Each packet will be encrypted with the key provided by the Diffie Hellman Key Exchange Handshake
Algorithm has yet to be decided, but it has to be powerful enough to prevent decryption by brute force
Each packet will also be compressed with zlib (or any other powerful cross-compatible encryption library)
Will operate on the TCP/IPv6 Protocol
Files will be split into 256kb chunks, with about 20 packets per chunk (feasible?)

Types of Nodes:

All nodes pass queries through them to other nodes
Client Node - These nodes can upload and download and query
Seeding Node - Nodes that exist solely to upload a file
Reflection Node - Nodes that exist to reflect data chunks other nodes contain (decided based upon rariety or demand)
Proxy Node - Nodes that exist solely to act as proxies for other nodes
Tracker Node - These nodes track a certain hash of data (or merkle hash tree's) and keep a list of nodes that contain that data, then pass this list off to any nodes wanting that hash of data
Farm Node - Nodes that keep lists of Filenames and Hash's of other nodes data and act as data farms
HUB Node - Nodes that keep a list of other nodes within its private HUB (passworded)

Demand/Rareity Handling

Rare files will be determined by a node performing its own network search for the hash of another nodes data (when requested for reflection), no reflector node can hold more than 1 chunk of another nodes data
Demand will be determined by how many searches have been performed from that data, once the data has been reflected demand will be determined by the amount of demand for the chunk the reflector node is holding

Download/Upload Efficiency

Download/Uploads will firstly be favoured by nodes within the same LAN as the requesting node
Download/Uploads will secondly be favoured by nodes within the same ISP (WHOIS) as the requesting node
Download/Uploads will thirdly be favoured by nodes who are closer geographically to the requesting node
Uploads will be favoured on the node depending on rare/demanding the data is

Anonymity

The Encryption provided by the Diffie Hellman Key Exchange should be enough to prevent any ISP shaping and sniffing
Clients should have the option to route through TOR/I2P/A third party proxy
Uploaders should have the option of distributing there files through reflector nodes
Clients should have the option to use proxy nodes within the network
All queries should be passed from the node that did the query until TTL is reached (Time to Live), and passed back through the respective nodes to anonymise queries

Hashing

Merkle hashing tree's should be used to split hash's into chunks, so someone can search for a merkle hash tree and provided a node has at least on of those chunks it can be used in uploading, this allows coincidental data sharing
Hash searches should be valid

File Availability

Searches can be performed, by filename or hash, these searches are passed down through each node to all the nodes there connected to until TTL is reached (standard is 10).
Links (such as ED2K links) will be available, just using theprotocol://<hash> (client will search for the hash)
Files (such as .torrent) will be available, will be pointers towards trackers within the network (as well as hash's etc.), in typical XML format

Ports

Communication done passively over port 80 (no mucking about with port forwarding)

Dirty Nodes

Spamming, DOSing and Advertising Nodes will be known as 'Dirty' Nodes
Common String Checks (including variables), hash checks and filesize checks will be excluded from a clients search if to common
Flood Checks, if more than 15 queries come from the same user in under 5 seconds disconnect from that node, or 6 single same queries from the same node

Theres my ideas, let me know if you like them, or hate them

I think it would be great to have ratings / reviews according to the file you are about to download. It is annoying when you are looking for something and end up with a corrupted file, a file encoded in another format and you need to download a magical cracker which contains all sorts of malware, etc.

It would need to show IP range as well as some malicious person could just keep rating his/her own file with, this was excellent, blah blah blah.

Other than that, I like your ideas.

I believe those ideas are good but from a development and deployment standpoint are not realistic. Mainly what you are focusing on is more security of information being shared between two parties. Yes this would be a great feature to have but a complicated one when you introduce more then two people into the scheme. Encryption being a part of that. With the method you described Diffie Hellman Key Exchange would be a good solution since it dose not require any user to have previsios contact. The problem with that encryption method is it has not protection from middle man attacks. Even with the packet compress encryption any user that connects once you the enviorment would technically be able to become a middle man with not a lot of problems. Another issue with Diffie Hellman Key Exchang is it was really only developed for two parties that create a connection at the same time. With P2P network most of the time users dont all join at once so a shared key would not be avaibile to users once that first connection between parties have been made. So if 3 people connect at once and determine a shared key a 4th person that comes in 4 min later would not be able to be part of that connection.

Also to prevent the man in the middle attack stated above you would need to create some secure connection between the two such as VPN using IPSec but that would have problems in itself. Since a secure connection would be as it says a secure connection all information being sent out would be secure and would only being going to the destination the connection was established with. So if the user decided to surf the web and share at the same time their would have to be a filter on a secondary system to route the traffic that is P2P and what is not. The P2P traffic would be sent back on the secure connection but all other traffic would be filter out at a central point to the insecure internet. That in itself would cause problems.

Another issue would be using IPv6. Due to IPv6 still not consider a standard yet(Manufacturers and developers are not required to support it yet) some users would not be able to connect unless they had IPv6 compatible networks/ IP address's (Class D). Now if you wanted to release a program like this 2-3 years down the road when IPv6 is slated to be implemented industry wide it would be very possible to go that route.

Another big issue with all of this would also be how much extra work is being done. When a user sends a piece of data they will have to encrypt that information have a secure connection made, compress the packet, send it, and then when it receives it decrypt, uncompress, and then work with the data. Their is not that large prentage of systems able to do this at a quick enough pace to be efficient.

With the development of a application such as this it would definitely not be free due to how much it would cost to develop and support. Also the application alone would need to be extremely well built and supported.

I am not putting down your ideas but I agree with you it would be nice to have them but currently they would not be practical to develop and implement in a P2P application.

This post has been edited by lockdown: 29 Dec, 2007 - 06:51 PM

This P2P Network would not be a server-client relationship, so every node would potentially have at least 10 connections with other nodes open, each node would negotiate its key with the other node so every node->node connection would be different (2 parties talking, which is all you would really need for file sharing). Also it seems to me that to instigate a successful man in the middle attack an ISP would have to modify the Handshake packets to insert there own generated numbers, then act as a proxy decrypting and re-encrypting between the two nodes. However this is where obfuscation comes in, if we transfer the numbers in HTTP HTML Packets there will be a lot of reluctance from ISP's to modify them, especially since they don't know that those packets may/may not contain the numbers from this encryption scheme or just numbers from some other program.



I was under the impression that if something didn't support IPv6 that it would just wrap that packet into an IPv4 packet, creating more overhead but it would be good for future. Although IPv6 isn't really a core issue to a P2P network, so it can swing either way.

Thanks for your thoughts, keep em coming

Either way you have some great ideas. If u ever wanted to look into more about developing it I would be happy to give a hand.

MITM attacks are increasingly difficult with some sort of strong mutual authentication. Wouldn't SSL be sufficient for this?

Doesn't SSL rely on certificates? Not exactly a field I know much about, and I'm positive the Diffie-Hellman key exchange with obfuscation will work well enough to keep ISP's out of the loop.

Yes SSL dose rely on signed certificates. Just had to learn all about that from my Comptai Security+ course which was a pain.

OK I'm currently developing a small program that should emulate the way I want these nodes to handshake, however I have run into a small block, firstly I have to generate a prime and a generator. To generate a prime number I would use the Sieve of Atkin however I do not understand that pseudocode (specifically the [] used).

Also I do not know what a 'Primitive Root' is, in this visual explanation, they explain that they can start with a Prime of 11 and a Generator of 7, meaning that 7 must be the primitive root of 11, however i personally do not see any correlation that and this primitive root system I looked up.

Can someone who has a handle on this kind of maths lend a hand?

I was not great with understanding complex algorithms (I just did not like learning all of them mostly) but I will take a look at it.