Security Design

Classification: Technical · Crypto Stack · Threat Model

SecureChat's security is built on one principle: we cannot read your messages, even if compelled by a court order. The architecture makes this technically impossible, not just a policy promise.

Three Rules — Never Broken

🔒 No internet permission by default. SecureChat never makes network calls without explicit user action. Kaspa identity anchoring requires one-time opt-in.
🔒 Private keys never leave hardware. All key generation and crypto operations happen inside Android Keystore (StrongBox or TEE). Keys are not exportable.
🔒 Fail Secure. On any error, the app encrypts — never decrypts. No plaintext fallback. No silent degradation.

Cryptographic Algorithms

AlgorithmUse CaseParametersLibrary
XChaCha20-Poly1305Message encryption256-bit key, 192-bit nonce, AEADlazysodium-android
X25519 ECDHKey exchangeCurve25519, ephemeral per-sessionlazysodium-android
Double RatchetForward secrecyHKDF-SHA256, RFC 5869lazysodium-android
Ed25519Identity signing64-byte signatureslazysodium-android
Argon2idKey derivation64MB memory, 3 iterations, 4 threadslazysodium-android
Android KeystoreKey storageStrongBox/TEE, per-use authAndroid API 26+
HMAC-SHA256IFR cache integrity256-bit key from KeystoreAndroid Keystore

Threat Model

Protected against: Network eavesdropping, relay server compromise, metadata analysis (with message padding), key theft (hardware-backed), screenshot/recording (FLAG_SECURE).

Out of scope (by design): Compromised OS (rooted device with malware), physical observation side-channels, attacker who already has the key, Kaspa chain-level metadata (who communicates with whom — only content is protected).

External audit: Trail of Bits recommended before public release. Audit report will be published publicly.