From 9624592e96b12e789cd0a0a03871ce0f82437fc4 Mon Sep 17 00:00:00 2001 From: Anton Livaja Date: Mon, 30 Sep 2024 17:39:00 -0400 Subject: [PATCH] more content updates --- _layouts/about.html | 8 ++++---- _layouts/landing.html | 7 +++++++ recovery_policy.md | 30 ++++++++++++++++++++++++++---- 3 files changed, 37 insertions(+), 8 deletions(-) diff --git a/_layouts/about.html b/_layouts/about.html index d332721..270a953 100644 --- a/_layouts/about.html +++ b/_layouts/about.html @@ -17,12 +17,12 @@ to problems of managing systems in a way where no single individual can compromise them.

This methodical approach to building systems which are resilient to single points of failure was appealing to - blockchain companies, so they started to work closely with companies which managed large sums of digital + fintech companies, so they started to work closely with companies which managed large amounts of assets and wanted to be sure that they are taking a first principles approach to building their security - posture.

+ systems.

-

From these interactions with many large protocols, blockchain labs, funds and other clients managing large - amounts of funds - they learned how to build systems which are resilient to the most adversarial threat +

From these interactions with many financial institutions, and other clients managing highly sensitive data or + large amounts of funds - they learned how to build systems which are resilient to the most adversarial threat landscapes.

Distrust Disaster Recovery is the result of years of collaboration and implementing real world systems diff --git a/_layouts/landing.html b/_layouts/landing.html index 2a0f983..e2b2068 100644 --- a/_layouts/landing.html +++ b/_layouts/landing.html @@ -80,6 +80,12 @@ of failure on all levels.

+

Transparency

+

Every part of the Distrust Disaster Recovery system is + fully open source and has been audited by leading security + firms. We encourage you to review our technology for yourself. +

+

Reproducible Builds

Being able to ensure that all of the software that's @@ -122,6 +128,7 @@ to carry out actions is a core control mechanism for Distrust Disaster Recovery.

+ diff --git a/recovery_policy.md b/recovery_policy.md index 0b1b22e..9456c04 100644 --- a/recovery_policy.md +++ b/recovery_policy.md @@ -24,7 +24,7 @@ valid recovery request. The main conditions of a Recovery Policy are: * Time lock until year/month/day -* n of m cryptographic signatures (PGP) +* n of m cryptographic signatures (FIDO2, PGP) * n of m KYC verifications At least one of cryptographic signature or kyc verification is always required. @@ -40,9 +40,9 @@ possible. The data will not be recoverable until the day after the lock date. ## Cryptographic Signature Verification -This method supports PGP cryptographic signatures. One may register as many as -32 public keys, and set how many of those keys are required for a valid recovery -request, for example, 3 of 7. +This method supports several cryptographic signature schemes including PGP and +FIDO2. One may register as many as 32 public keys, and set how many of those +keys are required for a valid recovery request, for example, 3 of 7. ## KYC Verification @@ -61,3 +61,25 @@ signed by Distrust. individuals, and require any number of individuals to express intent to recover. For example, the total number of individuals may be 7, and 3 of them are required to initialize the recovery process. + +## When and How The Policy Can Be Changed + +A policy can only be updated by providing the authentication required to recover +the data. + +A policy can be defined to be valid: + +* After a specific date +* Between specific dates +* Before a specific date + +Additionally, the policy can be made updateable, or non-updateable. + +There is also a cooldown period, which requires a specific amount of time to +elapse before the policy is updated upon request. + +For example, one may choose to create a policy that's only in effect after a +specific date, and can be updated, creating a lock on the data and the ability +to update until after that date. Conversely, a policy can be created which is +only valid up to a specific date and can not be updated, effectively expiring +after that date, making the data non-recoverable.