TrueLock – encrypted capsules with built-in unlock rules(truelock.pro)
truelock.pro
TrueLock – encrypted capsules with built-in unlock rules
https://truelock.pro/
6 comments
Maker here. I’m especially interested in criticism of the threat model.
If you try it, I’d love feedback on:
which rule is actually useful in practice (time/geo/visual key)
what is confusing in setup
what would increase trust fastest (spec, vectors, reproducible builds)
If you try it, I’d love feedback on:
which rule is actually useful in practice (time/geo/visual key)
what is confusing in setup
what would increase trust fastest (spec, vectors, reproducible builds)
If useful, I can post a minimal capsule format sketch (header + policy fields)
and a compact threat-model table (what it protects vs. what it does not).
As promised, here’s a minimal sketch.
*Capsule format (high-level)*
* magic + version * crypto suite id (AEAD) * KDF id + parameters (for password path) * salt / nonces * policy section (time/geo/password/visual, AND/OR AST) * ciphertext (payload blob) * auth tag / integrity
*Threat model (compact)* Protects against:
* someone who only gets the `.cfcaps` file (without required secrets/rules) * accidental/premature access during sharing (time/place/team constraints)
Does not protect against:
* fully compromised endpoint/runtime (bypass checks / exfiltrate plaintext after legitimate open) * malicious recipient taking photos/screenshots once content is opened
If people want, I can write a 1-page spec from this (policy AST fields + encoding).
*Capsule format (high-level)*
* magic + version * crypto suite id (AEAD) * KDF id + parameters (for password path) * salt / nonces * policy section (time/geo/password/visual, AND/OR AST) * ciphertext (payload blob) * auth tag / integrity
*Threat model (compact)* Protects against:
* someone who only gets the `.cfcaps` file (without required secrets/rules) * accidental/premature access during sharing (time/place/team constraints)
Does not protect against:
* fully compromised endpoint/runtime (bypass checks / exfiltrate plaintext after legitimate open) * malicious recipient taking photos/screenshots once content is opened
If people want, I can write a 1-page spec from this (policy AST fields + encoding).
Design question: for Windows geo I chose a phone relay (QR challenge/proof) instead of trusting desktop location APIs. Is that the right tradeoff in your view, or would you prefer a different approach?
[deleted]
A capsule is one .cfcaps file containing encrypted payload + an embedded unlock policy. The recipient gets one file, and the app checks rules locally before open.
Current rules:
time window
geo radius
password
visual key (up to 5 images)
AND/OR logic across rules
Windows geo can be confirmed via a phone relay (QR challenge/proof flow).
Capsules can contain text and attachments (including media). Current clients: Android + Windows.
Crypto in current build: AEAD (AES-GCM / ChaCha20-Poly1305) + Argon2id for passwords. Format: cross-platform capsule container.
Threat-model boundary: This is application-layer enforcement. A fully compromised endpoint/runtime can bypass local checks or exfiltrate plaintext after legitimate open. The goal is programmable disclosure in normal environments (reduce premature/accidental access).
I’d value technical feedback on:
threat-model clarity
most compelling real use case
which trust artifact is most useful next (format spec, vectors, reproducible builds, etc.)
Quick test: set a time window (e.g., unlock in 2 minutes), share the .cfcaps, try open before/after.
https://truelock.pro