LYRD

Security architecture

What we protect, and what we can't.

LYRD uses established primitives from Apple's frameworks and no third-party code. This page summarises the design. It has not yet been independently audited; we will publish the review when it has.

Key hierarchy

PatternOrdered path on a 5 × 5 grid (at least 6 points). Never stored, logged or compared.
StretchingPBKDF2-HMAC-SHA512, calibrated per installation to about half a second.
Device bindingHKDF with a secret from a Secure Enclave key agreement. Without this iPhone, guessing offline is not possible.
Layer Master KeyRandom 256-bit key per Layer, stored only inside an encrypted key slot.
ContentAES-256-GCM, a separate key per object, fresh random nonces, chunked and padded.
RecoveryOptional 12-word phrase (128-bit) that opens a second slot with the same master key.

The Secure Enclave does not run file encryption; it performs one key agreement per unlock to tie keys to the device. Encryption runs in the app with CryptoKit.

Plausible deniability

The interface never shows how many Layers exist and never says a pattern is wrong: an unknown pattern opens an empty Layer. All 64 key slots look like random data, and a random number of decoy slots is marked as used, so the number of used slots never equals the number of Layers.

With forensic access to the device, someone can see that LYRD holds encrypted data, roughly how much, when it changed, and an upper bound on the number of Layers. They cannot see what the data is, what it is called, or how it is divided.

On the device

Not protected

Report a vulnerability

Email security@lyrd.app. Please don't open public issues for vulnerabilities.