Security Policy

1. Zero-Knowledge Architecture

Cryple is built from the ground up as a zero-knowledge service. Our architecture means that no employee, administrator, or attacker compromising our servers can read your stored items, credentials, notes or documents.

We operate strictly under the following policy:

• Your recovery phrase and your PIN never leave your browser.
• All encryption/decryption happens locally on your device before transmission.
• We only store randomly generated salts, ECDSA public keys, and encrypted payloads.

2. Cryptography Practices

We leverage industry-standard cryptographic tools:

• Authentication: ECDSA P-256 signatures over a client-generated challenge; in Paranoid Mode the PIN is stretched client-side with PBKDF2-SHA256 (600,000 iterations) and stored server-side as an Argon2id hash.
• Signing: Asymmetric public/private key-pairs (ECDSA P-256) are derived client-side from your recovery phrase and sign every challenge and privileged action.
• Data Storage: vault items, notes and documents are encrypted on the client device using AES-256-GCM, each under its own key.
• Post-Quantum: the hybrid PQXDH construction — X25519 combined with ML-KEM-768 — is implemented and specified for encrypting to another person. Private sharing is the feature that will use it; it is not shipped yet.

3. Infrastructure Protection

Our server infrastructure is protected by rigorous engineering limits against attack vectors:

• Single-use nonce locking prevents replay attacks on every authentication and privileged action.
• Database volumes and object storage buckets are encrypted at rest via our cloud providers.
• Rate limiting on authentication endpoints is designed and not yet deployed. Until it is, a 6-digit PIN in Paranoid Mode is defended by server-side cost alone, and we would rather say so than imply a control we do not run.

4. What This Model Does Not Cover

A security policy that lists only strengths is marketing. These are the limits of our architecture, stated plainly, so you can weigh them before you rely on us.

Each of these is a known and accepted limitation of the current design, not an oversight:

• Data availability. Your encrypted data lives in our storage. We cannot read it, but we do hold it: if our storage were lost or withheld, the ciphertext would go with it. Zero-knowledge removes our ability to read your data; it does not remove our custody of the bytes. Keep your own copy of anything you cannot replace.
• Metadata. We cannot see what you store, but we can see that you store: how many items exist, roughly how large they are, and when they changed. Encrypting content is not the same as hiding activity, and we do not claim to hide it.
• Losing your phrase is final. There is no recovery path, so there is nothing for an attacker to subvert and nothing for a court to compel — and equally nothing for us to offer you if the phrase is gone. This is the trade, stated once and honoured in both directions.

5. Auditing & Open Source

We believe security requires transparency. Therefore, our target is an "Open Source Client" philosophy, meaning all client-side decryption logic is inspectable by security researchers before usage.

We are presently undergoing internal security reviews ahead of formal independent third-party penetration testing.

6. Vulnerability Disclosure

If you discover a security issue or vulnerability please report it immediately rather than disclosing it publicly. We are working on a Bug Bounty program, but in the meantime please contact our security team.

7. Contact Information

For urgent security disclosures, or questions regarding this policy, please reach out directly: contact@cryple.io or by mail at Cryple LLC, 30 N Gould St Ste R, Sheridan, WY 82801, USA.