Artifact Content
Not logged in

Artifact de90e8a947545385b4ccf0babc82219ed5d6a26b:

Wiki page [Algorithm and Implementation] by martin_vahi on 2018-12-29 21:12:58.
D 2018-12-29T21:12:58.506
L Algorithm\sand\sImplementation
P c5b49e0495ea0a6ba875c10d803d9540c2dcc361
U martin_vahi
W 4612
<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.
<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. <b>The ID of the encryption/decryption key
is part of cleartext metadata.</b> 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 -&gt;
key_file_path. &nbsp;Server storage should be saved by using &nbsp;<b>"suggested_deletion_time"
in stead of the "time_to_live"</b>, 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.&nbsp;</p>

<p>&nbsp;</p>

<p><font color="#ff0000">TODO: figure out some proper time-dependent ID-scheme</font>,
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 &nbsp;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.<font color="#ff0000">&nbsp;As of
now it still remains to be seen, what the ID-scheme will look like.</font></p>

<p><br>
</p>

<h1>Some References</h1>

<p>
<ul>
<li><a href="http://magnet-uri.sourceforge.net/">http://magnet-uri.sourceforge.net/</a><br>
</li>
</ul></p>

<p><br>
</p>

Z ede903a88c737afa004c08091277344a