|Page Name:||Algorithm and Implementation|
The main property, where the Silktorrent differs from the other similar projects is that its algorithm is modular. The modularity of its implementation is at least as granular as its algorithm.
Silktorrent packets are tar-files that have a name that contains the size of the file and at least one cryptogaphically secure hash of that tar-file. The reason, why tar is used in stead of tar.gz, zip, xz, etc. is that multi-TiB files that consist of only regular patterns, may be all zeros or all ones, can be compressed to a very small file and that kind of file can be used for DoS-attacking computers that run software that unpacks the compression result. The Silktorret packet contains folders "header" and "payload". The folder "header" contains a file "silktorrent_salt.txt", which is used for giving the cryptographically secure hash of the tar-file a semirandom value and is used as a padding to somewhat hide the minimum size of the payload. This allows a single payload to have multiple Silktorrent packets. The idea is that when one package name is blacklisted by censors, the same payload can be distributed by using a different Silktorrent packet.
Optional Silktorrent Packet Header Fields
All of the files in the "header" folder are part of the tar-file and influence the secure hash of the tar-file. Secure hash algorithms do have collisions, but within the limits of those collisions the headers are inseparable from the Silktorrent packet. Silktorrent packet creation software is allowed to add additional, implementation specific, files to a folder called "custom_headers" and the folder "custom_headers" must be a direct child folder of the "header" folder.
The general idea is that there's a random graph, an addressing scheme for navigating in a huge random graph and the tunnels are the edges of the graph. A tunnel can be an USB-stick that is passed on, literally a mail pigeon with a memory card attached to its leg, a drone with an USB-stick, ordinary HTTP, BitTorrent, Tor network, Freenet, etc. The details are at a separate document.
Messaging Related Aspects
Due to the fact that encryption function is a reverse function of decryption function, deriving the decryption function from a public encryption key and a publicly known encryption algorithm is only a matter of mathematical ingenuity. Only symmetric encryption algorithms can be sufficiently strong. Silktorrent packets that are used for delivering messages/letters, should be kept free of all cleartext metadata. The ID of the encryption/decryption key is part of cleartext metadata. The solution might be to use only one-time keys or a huge set of keys or use an encryption implementation, where a single key has thousands of different ID-s, which are loaded into a relational database to create a 2-column table with the relations: key_ID -> key_file_path. Server storage should be saved by using "suggested_deletion_time" in stead of the "time_to_live", because the suggested_deletion_time can be stored without storing the upload/creation time of the Silktorrent packet. If possible, the metadata of a message/letter, for example, the ID of the recipient, should be stored to a different server than the one, where the message/letter itself is stored.
TODO: figure out some proper time-dependent ID-scheme, where the actual decryption key ID-s are derived by the message recipient by using the message recipient temporary ID. The storage server would get only the suggested_deletion_time, a binary ID-less blob and one ID that goes with the blob. The recipient makes radix-sort style queries to the server, where the query consists of a timeslot_ID_when_the_message_arrived_to_server, something_for_the_query. It is possible to make queries also about time slots that have ended, reside wholly in the past. As of now it still remains to be seen, what the ID-scheme will look like.