TrueLock – encrypted capsules with built-in unlock rules
1–7 of 7 posts
Re: TrueLock – encrypted capsules with built-in unlock rules
#2I built TrueLock to share content that opens only under rules, without cloud dependency or a central service.
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.
Re: TrueLock – encrypted capsules with built-in unlock rules
#3I built TrueLock to share content that opens only under rules, without cloud dependency or a central service. 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…
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)
Re: TrueLock – encrypted capsules with built-in unlock rules
#4I built TrueLock to share content that opens only under rules, without cloud dependency or a central service. 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…
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 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).
Re: TrueLock – encrypted capsules with built-in unlock rules
#5Earlier quoted context omitted.
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 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).
Re: TrueLock – encrypted capsules with built-in unlock rules
#6[deleted]
Re: TrueLock – encrypted capsules with built-in unlock rules
#7Earlier quoted context omitted.
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 ac…
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?