From cc23fba208c704f2ac4d702d79e2832e4c63d7d2 Mon Sep 17 00:00:00 2001 From: inference Date: Mon, 26 Jun 2023 01:34:52 +0100 Subject: [PATCH] Remove unnecessary HTML line breaks. --- ...usted_the_issue_with_decentralisation.html | 25 ++----------------- 1 file changed, 2 insertions(+), 23 deletions(-) diff --git a/blog/untrusted_the_issue_with_decentralisation.html b/blog/untrusted_the_issue_with_decentralisation.html index 88c7b4c..c8f9a5e 100644 --- a/blog/untrusted_the_issue_with_decentralisation.html +++ b/blog/untrusted_the_issue_with_decentralisation.html @@ -5,7 +5,7 @@ - + @@ -29,15 +29,9 @@

Blog - #2

-
-
-

Untrusted: The Issue with Decentralisation

-

Posted: 2022-06-30 (UTC+00:00)

Updated: 2022-10-29 (UTC+00:00)

-
-

Table of Contents

@@ -55,9 +49,6 @@
  • Conclusion
    • -
    -
    -

    Introduction

    A recent trend is seeing people move towards decentralised services and platforms. While this is @@ -66,8 +57,6 @@ 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.

    -
    -

    Examples

    -

    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, @@ -94,8 +82,6 @@ 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.

    -
    -

    Solution

    I'll cut to the chase; there isn't a definitive solution. The best way to handle this situation @@ -104,7 +90,6 @@ 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.

    -

    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 @@ -112,7 +97,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.

    -

    In order to have a root of trust, I have posted my keys to my website, which is protected by multiple layers of security:

    @@ -128,14 +112,11 @@ it.

  • 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.
    • - -
    +

    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.

    -
    -

    Conclusion

    Do not demand anonymity; demand privacy and control of your own data. Complete anonymity makes it @@ -155,7 +136,5 @@ 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.

    -
    -