Inferencium/website
1
0
Fork 0
Code Issues Activity

Update Blog #2 webpage from version 4.0.0.16 to 4.1.1.24.

Browse Source
This commit is contained in:
inference 2023-06-26 03:03:37 +01:00
parent bfffed3a18
commit a2b279778d
Signed by: inference
SSH Key Fingerprint: SHA256:9Pl0nZ2UJacgm+IeEtLSZ4FOESgP1eKCtRflfPfdX9M
1 changed files with 129 additions and 159 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

102
blog/untrusted_the_issue_with_decentralisation.html
View File

@ -5,22 +5,19 @@
<!-- Copyright 2022 Jake Winters -->
<!-- SPDX-License-Identifier: BSD-3-Clause -->
<!-- Version: 4.0.0.16 -->
<!-- Version: 4.1.1.24 -->
<html>
<head>
<head>
<title>Inferencium - Blog - Untrusted: The Issue with Decentralisation</title>
<link rel="stylesheet" href="../inf.css">
<meta name="viewport" content="width=device-width, initial-scale=1">
</head>
<!-- Navigation bar. -->
<div class="sidebar">
<img src="../asset/img/logo-inferencium-no_text.png"
width="110px" height="110px">
<a class="title">Inferencium</a><br>
</head>
<!-- Navigation bar -->
<div class="sidebar">
<a href="../index.html"><img src="../asset/img/logo-inferencium-no_text.png" width="110px" height="110px"></a>
<a href="../index.html" class="title">Inferencium</a><br>
<br>
<br>
<div><a href="../about.html">About</a></div>
@ -28,57 +25,39 @@
<div><a href="../blog.html">Blog</a></div>
<div><a href="../source.html">Source</a></div>
<div><a href="../key.html">Key</a></div>
</div>
<body>
<div><a href="../changelog.html">Changelog</a></div>
</div>
<body>
<h1>Blog - #2</h1>
<br>
<br>
<br>
<h2>Untrusted: The Issue with Decentralisation</h2>
<br>
<p class="update_date">Posted: 2022-06-30 (UTC+00:00)</p>
<p class="update_date">Updated: 2022-10-29 (UTC+00:00)</p>
<br>
<br>
<!-- Table of contents. -->
<h2 id="toc"><a href="#toc" class="h2"
>Table of Contents<a/></h2>
<!-- Table of contents -->
<section id="toc">
<h2 id="toc"><a href="#toc" class="h2">Table of Contents<a/></h2>
<ul>
<li><a href="#introduction" class="body-link"
>Introduction</a></li>
<li><a href="#examples" class="body-link"
>Examples</a></li>
<li><a href="#introduction" class="body-link">Introduction</a></li>
<li><a href="#examples" class="body-link">Examples</a></li>
<ul>
<li><a href="#examples-messaging" class="body-link"
>Messaging</a></li>
<li><a href="#examples-messaging" class="body-link">Messaging</a></li>
</ul>
<li><a href="#solution" class="body-link"
>Solution</a></li>
<li><a href="#conclusion" class="body-link"
>Conclusion</a></li>
<li><a href="#solution" class="body-link">Solution</a></li>
<li><a href="#conclusion" class="body-link">Conclusion</a></li>
</ul>
<br>
<br>
<br>
<h2 id="introduction"><a href="#introduction" class="h2"
>Introduction</a></h2>
</section>
<section id="introduction">
<h2 id="introduction"><a href="#introduction" class="h2">Introduction</a></h2>
<p>A recent trend is seeing people move towards decentralised services and platforms. While this is
reasonable and I can understand why they are doing such a thing, they are seemingly doing it without
thinking about the possible consequences of doing so. The issue with decentralisation is trust;
there is no way to pin a key to a specific person, to ensure that you are communicating with the
same person you are supposed to be communicating with. In this article, I will discuss some of the
security issues with the decentralised model.</p>
<br>
<br>
<h2 id="examples"><a href="#examples" class="h2"
>Examples</a></h2>
<h3 id="examples-messaging"><a href="#examples-messaging" class="h3"
>Messaging</a></h3>
</section>
<section id="examples">
<h2 id="examples"><a href="#examples" class="h2">Examples</a></h2>
<section id="examples-messaging">
<h3 id="examples-messaging"><a href="#examples-messaging" class="h3">Messaging</a></h3>
<p>When it comes to messaging your contacts on a centralised platform, such as Twitter or Facebook,
the keys are pinned to that user account, using the user's password as the method of identification.
This approach makes it impossible to log in as a specific user without their password, should it be
@ -88,7 +67,6 @@
servers, which makes the physical security trusted. As for remote security, should a user's password
be compromised, it can typically be reset if the user can prove they are the owner of the account
via some form of identification; this is where the trust issue of decentralisation occurs.</p>
<br>
<p>In the decentralised model, keys are kept on the users' devices, in their possession. While this
soveriegnty is welcomed, it introduces a critical flaw in the security of communicating with anyone
via a decentralised platform; should a user's device be lost, stolen, or otherwise compromised,
@ -101,18 +79,16 @@
literally no way to know if the person you are communicating with is the real person or an imposter;
there is no root of trust. This point is fatal; game over. The only way to establish trust again
would be to physically meet and exchange keys.</p>
<br>
<br>
<h2 id="solution"><a href="#solution" class="h2"
>Solution</a></h2>
</section>
</section>
<section id="solution">
<h2 id="solution"><a href="#solution" class="h2">Solution</a></h2>
<p>I'll cut to the chase; there isn't a definitive solution. The best way to handle this situation
is to design your threat model and think about your reasoning for avoiding centralised platforms. Is
it lack of trust of a specific company? Is it the possibility of centralised platforms going
offline? Only by thinking logically and tactically can you solve both the issue of centralisation
and decentralisation. Often, one size fits all is never the correct approach, nor does it typically
work.</p>
<br>
<p>In order to avoid the issue of loss of trust due to lack of root of trust, all users' keys must
be stored in a centralised location where all contacts are able to go to in case of compromise or to
periodically check the state of keys and to see if they have changed. This centralised location
@ -120,7 +96,6 @@
person who initially signed up for the platform, using a trust-on-first-use (TOFU) model, which
isn't much different than what today's centralised platforms are already doing; the only difference
is who is controlling the location; trust is still present and required.</p>
<br>
<p>In order to have a root of trust, I have posted my keys to my website, which is protected by
multiple layers of security:<br>
<br>
@ -136,17 +111,14 @@
it.</li>
<li>I have enabled DNSSEC on my domain, so it is extremely difficult to spoof my domain to make you
believe you're connecting to it when you're actually connecting to someone else's.</li>
</ol>
<br>
</ol></p>
<p>While not the most secure implementation of a root of trust, it is the most secure implementation
currently available to me. While the domain name registrar or virtual private server host could
tamper with my domain and data, they are the most trustworthy parties available. In its current
form, decentralisation would make this impossible to implement in any form.</p>
<br>
<br>
<h2 id="conclusion"><a href="#conclusion" class="h2"
>Conclusion</a></h2>
</section>
<section id="conclusion">
<h2 id="conclusion"><a href="#conclusion" class="h2">Conclusion</a></h2>
<p>Do not demand anonymity; demand privacy and control of your own data. Complete anonymity makes it
impossible to have a root of trust, and is typically never necessary. It is possible for someone
else to hold your keys, without them taking control of them and dictating what you can and cannot do
@ -164,8 +136,6 @@
Decentralisation does not solve the government issue. In order to live a happy, fun, and fulfilled
life, while protecting yourself against logical threats, there are only two words you must live by:
Threat model.</p>
<br>
<br>
</body>
</section>
</body>
</html>