Show HN: TrueLock – secure messages as encrypted files with unlock rules (truelock.pro)
Instead of sending plaintext in chat, you wrap a message (and attachments) into a single encrypted capsule file (.cfcaps) and share it via any channel (Telegram/email/drive/USB). The recipient opens the file in the app.
What’s different vs “just encrypt a file” is that the unlock policy travels with the ciphertext:
time window
geo radius
password (Argon2id)
visual key (optional)
AND/OR logic across rules
Current clients: Android + Windows. Crypto: AEAD (AES-GCM / ChaCha20-Poly1305).
Threat-model boundary: policy checks are local; a fully compromised endpoint can bypass checks or exfiltrate plaintext after legitimate open.
I’d value technical feedback on:
threat-model clarity
strongest real use case
what trust artifact you’d want next (format spec, test vectors, reproducible builds)
3 comments
[ 3.1 ms ] story [ 16.6 ms ] threadAssume the capsule file leaks (someone forwards/copies it). In your view, does embedding the access policy (time/geo/password/visual key) into the same artifact as the ciphertext add any value, or is it pure security theater?
If you think it’s theater, what’s the smallest, most realistic bypass you’d try first — and what constraint would you add to make this primitive actually useful?
Capsule = one file: header (version, KDF/AEAD ids) + encrypted payload chunks + policy tree (AND/OR over time/geo/password/visual). Password path uses Argon2id; payload encryption is AEAD (AES-GCM or ChaCha20-Poly1305).
If you were reviewing this: what would you want first — (a) public capsule format spec, (b) test vectors for decrypt/verify, or (c) a short threat-model page with explicit non-goals?
1. “policy travels with ciphertext” — why is that a bad idea vs external workflow? 2. geo/time gating — useless gimmick or actually valuable friction? 3. visual key — dumb novelty or practical multi-party secret?
I’m genuinely trying to find the sharpest criticism, not compliments.