-
Notifications
You must be signed in to change notification settings - Fork 2
Security and Trust Model
Alex Stoyanov edited this page Mar 2, 2026
·
6 revisions
This page is the operator-facing guide to what Ethernity verification means in practice.
When you recover data, treat these as distinct:
- Integrity: was data changed or corrupted?
- Consistency: do all artifacts belong to the same backup set?
- Identity: is this from the signer/source you expected?
Ethernity is strong on integrity and consistency. Identity assurance depends on your trust and custody controls.
"Verified" means cryptographic and structural checks passed for the input set you provided.
It does not automatically mean your external trust policy is satisfied.
- Verification is rooted in the artifact set itself.
- Strong against corruption and mixed-set errors.
- Suitable for many operator environments with controlled custody.
- Verification is paired with an out-of-band trust anchor.
- Stronger against full artifact-set substitution.
- Requires stricter policy and operational discipline.
- Run periodic recovery drills.
- Keep independent backup paths.
- Keep artifact classes in separate custody paths.
- Treat rescue/bypass paths as incident-only controls.
If you are unsure where to start, use self-contained trust with disciplined custody and drills, then add external trust anchors when policy requires stronger identity guarantees.