Artifact Content
Not logged in

Artifact 57ed71bad0edc0d86335dfe3bcbe671b2016b27f:

Wiki page [Algorithm and Implementation] by martin_vahi on 2017-03-14 06:57:50.
D 2017-03-14T06:57:50.752
L Algorithm\sand\sImplementation
P d84ad10afd51aa0f402e7268159326c3eadc8291
U martin_vahi
W 3331
<p>The main property, where the Silktorrent differs from the other similar
projects is that its <b>algorithm is modular.</b> The modularity of its
implementation is at least as granular as its algorithm.</p>

<p><br>
</p>

<h1>Algorithm</h1>

<div><br>
</div>

<h2>Silktorrent Packets</h2>

<p>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 &nbsp;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.&nbsp;</p>

<p><br>
</p>

<h3>Optional Silktorrent Packet Header Fields</h3>

<p>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. &nbsp;</p>

<p><br>
</p>

<p><br>
</p>

<h2>Silktorrent Tunnels&nbsp;</h2>

<p>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, <a href="https://freenetproject.org/">Freenet</a>,
etc. The details are at a separate document.</p>

<p><a href="http://longterm.softf1.com/specifications/experimental/silktorrent_v_1_0/">Specification_v_1_0</a><br>
</p>

<p><br>
</p>

<p><br>
</p>

<h2>Messaging Related Aspects</h2>

<p>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.
Therefore <b>only symmetric encryption algorithms can be sufficiently strong.</b>
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 a solution, 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 -&gt; key_file_path.&nbsp;</p>

<p>&nbsp;</p>

<p><br>
</p>

<p><br>
</p>

Z 8aace16aba1383a159ee3f0420d22dd3