YuriiDev

Thanks for sharing this! POTSHARDS is a fascinating approach to long-term survivability through secret sharing and distribution. While they focus on avoiding encryption keys via data sharding across multiple archives, I’m trying to tackle the problem from the human side — using a memory-derived recursive cascade as the key. It's interesting to see how different architectures address the 'forgotten master key' dilemma.

  That is a very valid concern and the main reason why "Cognitive Entropy" is tricky. To mitigate this, I’ve focused on three layers of defense:

Static Facts vs. Subjective Tastes: I advise users to avoid "dynamic" memories (like favorite flavors) in favor of "static" facts that are etched into long-term memory but aren't easily searchable (e.g., specific digits from an old, expired ID, or the exact layout of a childhood home). LLM-Assisted Question Grading: The app includes a prototype tool (integrated with an LLM) that helps users evaluate their questions. It "grades" them based on two factors: Memorability (will you remember this in 10 years?) and Guessability (can this be found on Facebook/OSINT?). If a user picks "Mother's maiden name," the system flags it as high-risk.

  The "Physical Anchor" Defense: This is crucial. Even if an attacker knows your mother's name, they cannot even see the question or attempt the Argon2 cascade without the initial seed (k_0) derived from your "Physical Anchor" (the file hash). The answers are useless without the specific photo or document you chose as a seed.

  Encrypted Hints: The system allows embedding hints directly into the questions. Since the questions themselves are encrypted, these hints are only revealed step-by-step to the person who already unlocked the previous layer.

I’ve detailed the philosophy behind this "Cognitive Security" in my White Paper Vol. 1 — Vision & Concept:

https://secretmemorylocker.com/white-paper/en/vision-and-con...

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.

Thank you for the feedback — I fully agree with the "Zero Trust" principle. Users should never run executables without verification.

This is an early-stage MVP prototype, built in Python and packaged with PyInstaller, which often triggers false positives on VirusTotal because of how standalone binaries are analyzed. For those familiar with Python apps, 4/72 detections is typical for PyInstaller builds, not an indication of malware.

The project is currently in concept validation stage, and the encryption logic requires balancing transparency with the need to keep certain modules private to prevent misuse during early testing.

Source code: I plan to publish it (with a clean structure and documentation) in the next iteration, once the core approach is stable.

In the meantime:

If you’re not comfortable running the EXE — please wait for the open version (coming soon).

Or run it in a sandbox/VM if you want to explore the concept now.

I’ll also add a clear note on the website about this being a closed-source prototype. Thanks for raising these important points — transparency and security are top priorities for me.