Page cover
For the complete documentation index, see llms.txt. This page is also available as Markdown.

KeyStore Storage

Why We're Using React Native Keychain for Secure Private Key Storage

The Problem

In any application that handles cryptographic identities, whether for blockchain wallets, end-to-end encrypted messaging, secure authentication, or post-quantum communication, securely storing private keys is a non-negotiable requirement.

Storing a private key insecurely, for example in AsyncStorage, the file system, or an unencrypted database, exposes the user to serious security risks. If someone gains access to that key, they may gain control over the user's identity, messages, or assets.

The question is not whether private keys should be stored, but how they can be stored safely without compromising usability or sovereignty.

Why React Native Keychain

Cryptic uses React Native Keychain in mobile client applications because it provides access to OS-native secure storage mechanisms rather than JavaScript-level storage.

OS-Level, Hardware-Backed Security

Instead of relying on application-level storage, React Native Keychain interfaces directly with platform-native secure storage:

  • iOS: Private keys are stored in the iOS Keychain and may be protected by the Secure Enclave when key-generation policies require hardware-backed isolation.

  • Android: Keys are stored using the Android Keystore and may be backed by a Trusted Execution Environment (TEE) or StrongBox, depending on device capabilities.

This allows cryptographic material to benefit from OS-level isolation, access control, and hardware-assisted protections where available.

Important clarification: Not all Keychain-stored keys are always Secure Enclave–resident. Hardware backing depends on key attributes and device support. Cryptic configures keys to use the strongest available protection where supported.

Fit for Private Keys

Private keys are long-lived, high-value secrets that cannot simply be reset if leaked. React Native Keychain provides important safeguards:

  • Encrypted at rest: The OS encrypts key material before persistence

  • Application-scoped access: Other apps cannot read or extract stored keys

  • Optional biometric enforcement: Access can require Face ID or fingerprint authentication

This allows private key material to remain on-device and non-custodial, without transmission to servers.

What We’re Avoiding

Cryptic avoids storing sensitive key material in:

AsyncStorage

Not suitable for private keys or long-lived secrets

File system / SQLite

Requires careful encryption and secure bootstrapping

Server-side key storage

Introduces custody, privacy, and trust assumptions


Security-Usability Tradeoff

Keeping keys only in volatile memory would maximize security, but it would severely degrade usability. React Native Keychain provides a practical balance:

  • Security: OS-level encryption, access controls, and hardware-backed isolation where available

  • Usability: Keys can be securely persisted and accessed without repeated manual recovery

  • Sovereignty: Users retain control over device-bound keys

Real-World Applications

Cryptic uses secure on-device storage in client applications for:

  • Wallet-based identity: Long-lived identity keys used for signing and authentication

  • Secure communication: Keys used to support secure communication flows

  • Post-quantum workflows: ML-KEM and ML-DSA related key material where applicable

  • Decentralized authentication: Cryptographic signatures that reduce reliance on traditional usernames and passwords

Note: Device-stored keys are used in client-side applications such as Cryptic Mobile. Desktop and SDK-based implementations may use different secure storage methods depending on platform, deployment model, and integration requirements.

Summary: Why We Trust It

React Native Keychain provides a mature, OS-native mechanism for storing sensitive key material in mobile environments. Used correctly, it helps ensure:

  • Private keys remain device-bound

  • Access is enforced by OS security and optional biometrics

  • User experience remains practical without compromising cryptographic hygiene

Last updated