top | item 47204396

Ask HN: Long-term recoverable digital vault without a master key?

1 points| YuriiDev | 1 day ago

I’m exploring a long-term encryption design where a master key is never stored — only reconstructed.

The goal is a vault that can be recovered 10+ years later without writing down or backing up any master password. The only dependency should be stable long-term human memory.

The approach:

Instead of storing a password, the final encryption key is derived from multiple personal answers in sequence using Argon2.

k0 = seed

k1 = Argon2(answer1, salt = k0)

k2 = Argon2(answer2, salt = k1)

...

kn = Argon2(answern, salt = kn-1)

Final key = kn.

Properties:

No concatenation of answers

No static master password

Each step depends strictly on the previous

Memory-hard derivation (Argon2 at every step)

Brute forcing cannot be parallelized across answers

The vault is structured as nested encrypted layers. Each layer contains the next question and the next encrypted payload. You must answer each question correctly to decrypt the next layer. The file never stores the master key — only encrypted guidance for reconstructing it.

There’s a working prototype. Deterministic reconstruction works as long as the answers and seed remain unchanged.

My open architectural question is about the root seed (k0).

Right now k0 is derived from the container hash. But it could be any deterministic reproducible value.

What would be a robust long-term root of trust for a system that must remain recoverable after 10+ years without storing secrets?

Constraints:

Must be reproducible

Must not depend on external services

Must not introduce a new single point of failure

Must remain stable over a decade

Is using a file hash reasonable? Should k0 be user-derived? Should it be fixed and public?

More fundamentally: is relying on long-term human memory as a cryptographic reconstruction mechanism inherently flawed?

I’d especially appreciate critique around entropy assumptions, threat models, and long-term survivability risks.

3 comments

order

pestatije|1 day ago

it does not pass the wrench test

YuriiDev|1 day ago

You’re right — under direct physical coercion this design does not provide strong resistance. My current threat model is focused more on long-term survivability and secret non-storage rather than state-level coercion resistance. I’m experimenting with limited deniability extensions (e.g. decoy derivation paths), but I’m aware that application-layer branching is not equivalent to formally secure deniable encryption. So I wouldn’t claim this passes a true “wrench test.” At best it may reduce risk in casual coercion scenarios. If the goal were coercion resistance specifically, the architecture would likely need to move toward threshold schemes or multi-party secret sharing instead.

I appreciate the pushback.