2024-06-26 15:57:15 +00:00
|
|
|
<!DOCTYPE html>
|
|
|
|
|
<html lang="{{ page.lang | default: site.lang | default: en }}">
|
|
|
|
|
{%- include head.html -%}
|
|
|
|
|
|
|
|
|
|
<body>
|
2024-09-05 16:59:32 +00:00
|
|
|
<div class="container">
|
|
|
|
|
|
|
|
|
|
{%- include header.html -%}
|
|
|
|
|
|
|
|
|
|
<main>
|
|
|
|
|
<section class="flex-container">
|
|
|
|
|
<div class="flex-container-inner">
|
|
|
|
|
<h1>Distrust Disaster Recovery</h1>
|
|
|
|
|
<p>
|
|
|
|
|
The only fully open source, technology agnostic disaster
|
|
|
|
|
recovery and key escrow service.
|
|
|
|
|
</p>
|
|
|
|
|
<a href="https://docs.distrust.co/qkm" class="action-button">Documentation</a>
|
|
|
|
|
<a href="/contact.html" class="action-button">Join Waitlist</a>
|
|
|
|
|
<br />
|
|
|
|
|
</div>
|
|
|
|
|
</section>
|
|
|
|
|
|
|
|
|
|
<br />
|
|
|
|
|
|
|
|
|
|
<section class="flex-container">
|
|
|
|
|
<div class="flex-container-inner">
|
|
|
|
|
<h1>Quick Start</h1>
|
|
|
|
|
<div class="cta-well">
|
|
|
|
|
<p>
|
|
|
|
|
If you are ready to protect your data, you can use
|
|
|
|
|
the Wizard which will walk you through the process.
|
|
|
|
|
</p>
|
|
|
|
|
<a href="/contact.html" class="action-button">Quick Start</a>
|
|
|
|
|
</div>
|
|
|
|
|
</div>
|
|
|
|
|
</section>
|
|
|
|
|
|
|
|
|
|
<br />
|
|
|
|
|
|
|
|
|
|
<section class="flex-container">
|
|
|
|
|
<div class="flex-container-inner">
|
|
|
|
|
<h1 style="text-align: center">How it Works</h1>
|
|
|
|
|
<p>
|
|
|
|
|
Distrust used the <a href="https://docs.distrust.co/qkm/">
|
|
|
|
|
Quorum Key Management</a> specification to generate
|
|
|
|
|
entropy offline and used it to derive a
|
|
|
|
|
<a href="/public_key">PGP key</a> which anyone can
|
|
|
|
|
encrypt to.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
The only way to reconstruct the private key which is
|
|
|
|
|
used to decrypt is by bringing together multiple shard
|
|
|
|
|
holders who are in separate geographical locations.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
Distrust Disaster Recovery will always verify the
|
|
|
|
|
<a href="/recovery-rules">recovery rules</a> before
|
|
|
|
|
decrypting any client data.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
Clients may choose to generate their own encryption key,
|
|
|
|
|
encrypt data, then encrypt that key to the
|
|
|
|
|
<a href="/public-key">Distrust Disaster Recovery Public
|
|
|
|
|
Key</a>. In this way the data is never exposed to
|
|
|
|
|
anyone, but can be protected using a form of
|
|
|
|
|
"crypto-shredding".
|
|
|
|
|
</p>
|
|
|
|
|
</div>
|
|
|
|
|
</section>
|
|
|
|
|
|
|
|
|
|
<section class="flex-container">
|
|
|
|
|
<div class="flex-container-inner">
|
|
|
|
|
<h1 style="text-align: center">Security</h1>
|
|
|
|
|
<p>
|
|
|
|
|
Distrust Disaster recovery focuses on removing single points
|
|
|
|
|
of failure on all levels.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h3>Reproducible Builds</h3>
|
|
|
|
|
<p>
|
|
|
|
|
Being able to ensure that all of the software that's
|
|
|
|
|
used is deterministic is essential. Learn more about
|
|
|
|
|
why <a href="https://en.wikipedia.org/wiki/Reproducible_builds">here</a>
|
|
|
|
|
<!-- TODO: write our own doc about this -->
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h3>Full Source Bootstrapped</h3>
|
|
|
|
|
<p>
|
|
|
|
|
Being able to verify the compiler by
|
|
|
|
|
<a href="https://en.wikipedia.org/wiki/Bootstrapping_(compilers)">
|
|
|
|
|
bootstrapping</a> it in order to ensure it is not
|
|
|
|
|
capable of injection malicious code at runtime is an
|
|
|
|
|
essential part of supply chain security - and often
|
|
|
|
|
ignored.
|
|
|
|
|
<!-- TODO: write our own doc about this -->
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h3>Side Channel Attack Resistance</h3>
|
|
|
|
|
<p>
|
|
|
|
|
Attacks that are able to exfiltrate data via
|
|
|
|
|
non-standard channels is an important consideration
|
|
|
|
|
when handling sensitive cryptographic material.
|
|
|
|
|
Because of this, HSMs are leveraged.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h3>Cold Key Management</h3>
|
|
|
|
|
<p>
|
|
|
|
|
Ensuring that the lifecycle of cryptographic material is
|
|
|
|
|
handled in a fully air-gapped environment helps
|
|
|
|
|
drastically reduce surface area for attacks.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h3>Multi Party Access Control</h3>
|
|
|
|
|
<p>
|
|
|
|
|
Because eliminating single points of failure is an
|
|
|
|
|
effective way to reduce the likelihood of compromise
|
|
|
|
|
use of quorums where multiple individuals are required
|
|
|
|
|
to carry out actions is a core control mechanism for
|
|
|
|
|
Distrust Disaster Recovery.
|
|
|
|
|
</p>
|
|
|
|
|
</div>
|
|
|
|
|
</section>
|
|
|
|
|
|
|
|
|
|
<section class="flex-container">
|
|
|
|
|
<div class="flex-container-inner">
|
|
|
|
|
<h1 style="text-align: center">The Approach</h1>
|
|
|
|
|
<p>
|
|
|
|
|
Distrust Key Escrow has been designed with the utmost
|
|
|
|
|
care to eliminate single points of failure to ensure
|
|
|
|
|
that your backups are inaccessible by any single
|
|
|
|
|
individual, under any circumstances.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
This may seem like a big claim, but all our processes
|
|
|
|
|
and software are fully open source - so yo can verify
|
|
|
|
|
for yourself. If you still don't trust us, that's okay,
|
|
|
|
|
you can use our blueprint to set up the system yourself
|
|
|
|
|
- and we invite you to do so. You can find the
|
|
|
|
|
documentation on how QKM works
|
|
|
|
|
<a href="https://docs.distrust.co/qkm">here</a></p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
Most, if not all current commercial backup/disaster
|
|
|
|
|
recovery systems have many single points of failure and
|
|
|
|
|
sell a service which is simply not suited for many
|
|
|
|
|
contexts - especially for backing up digital asset
|
|
|
|
|
wallets. The lack of transparency on how their systems
|
|
|
|
|
work means that the end user can't verify whether their
|
|
|
|
|
approach to security matches your desired threat model,
|
|
|
|
|
and security properties, and what remains is blind trust,
|
|
|
|
|
rather with transparency.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
We invite you to question any part of our system.
|
|
|
|
|
</p>
|
|
|
|
|
</div>
|
|
|
|
|
</section>
|
|
|
|
|
</main>
|
|
|
|
|
{%- include footer.html -%}
|
|
|
|
|
</div>
|
2024-06-26 15:57:15 +00:00
|
|
|
</body>
|
|
|
|
|
|
2024-09-05 16:59:32 +00:00
|
|
|
</html>
|
