Encryption at Rest for AI Conversations
The Okara Architecture
Version 1.0 | October 2025
Executive Summary
As AI becomes integral to how we work and think, the privacy of our conversations with AI models has never been more critical. Every query, every draft, every brainstorming session reveals our thought processes, business strategies, and sensitive information.
Today, we're introducing Okara's encryption-at-rest system—designed to protect your conversation history from unauthorized access. Unlike traditional AI interfaces where conversation histories sit in plaintext databases vulnerable to breaches, Okara encrypts all stored conversations. Even if our database is compromised, your conversation history remains cryptographically protected.
This whitepaper details our encryption implementation, threat model, and privacy guarantees, demonstrating how Okara balances AI capabilities with robust protection of stored conversations.
The Privacy Problem in AI Chat
Current State of AI Storage
Most AI chat platforms store conversation histories in plaintext databases:
- Users send messages to the platform
- The platform processes and routes messages to AI models
- Conversations are stored in plaintext in databases
- Platform operators have full access to stored conversation content
- Database backups contain plaintext conversations
This creates several critical vulnerabilities:
- Data Breaches: Plaintext databases are high-value targets; breaches expose complete conversation histories
- Insider Access: Database administrators can read all stored conversations
- Backup Compromises: Stolen or leaked backups expose user data
- Compliance Complexity: Plaintext storage complicates data protection requirements
- Long-term Risk: Conversations stored indefinitely in readable form
For individuals sharing personal information and companies discussing proprietary strategies, plaintext storage of conversation histories represents a significant and permanent risk.
Why Encryption at Rest Matters
Encryption at rest protects stored data through cryptographic guarantees:
- Breach Resilience: Even if databases are compromised, encrypted data cannot be read
- Reduced Insider Risk: Database administrators cannot read encrypted conversation content
- Regulatory Compliance: GDPR, HIPAA, and other frameworks require data protection measures
- Long-term Privacy: Historical conversations remain protected indefinitely
- Defense in Depth: Additional security layer beyond access controls and network security
Okara's Encryption Architecture
What We Protect
Encrypted in Storage:
- All conversation messages (user and AI responses)
- Complete conversation history
- Deleted conversations (until permanently purged)
Not Encrypted (Necessary for Functionality):
- Messages during active processing and routing
- Metadata (timestamps, conversation IDs, model selection)
- Account information (email, subscription status)
Core Principles
Our encryption system is built on three foundational principles:
- Client-Side Key Generation: Encryption keys are generated on your device
- Encrypted Storage: All conversation history is encrypted before database storage
- User-Controlled Decryption: Only you can decrypt your conversation history
Encryption Flow
1. Key Generation and Management
When a user creates an Okara account:
created locally
6-digit passcode
encrypted private key
On Your Device:
- Generate X25519 key pair (256-bit elliptic curve cryptography)
- Private key: Used to decrypt your stored conversations
- Public key: Used by Okara to encrypt messages for storage
- Derive encryption key from your 6-digit passcode using Argon2id
- Encrypt private key with passcode-derived key
- Send encrypted private key to Okara servers
On Okara Servers:
- Store public key (used for encrypting messages)
- Store encrypted private key (cannot decrypt without user's passcode)
- Store passcode hash and salt for authentication
- Never receive or store plaintext private keys
Key Hierarchy:
- Private Key: User-controlled, stored encrypted, decrypts conversations
- Public Key: Stored on server, encrypts messages for storage
- Passcode: 6-digit PIN, never transmitted in plaintext, used to encrypt/decrypt private key locally
2. Message Flow: From Input to Encrypted Storage
When you send a message:
- You type message on device (plaintext)
- Message sent to Okara via HTTPS (TLS encrypted in transit)
- Okara receives and processes message (plaintext in server memory)
- Message routed to selected AI provider (plaintext)
- AI provider returns response (plaintext)
- ENCRYPTION HAPPENS: Before database storage
- Generate ephemeral X25519 key pair
- Perform ECDH with user's public key
- Derive AES-256-GCM encryption key
- Encrypt message and response
- Encrypted data stored in database (ciphertext only)
- Original plaintext cleared from memory
Storage Format:
Database stores:
- Ephemeral public key (32 bytes)
- Initialization vector (16 bytes)
- Authentication tag (16 bytes)
- Encrypted message content (variable length)
Database does NOT store:
- Plaintext message content
- Plaintext AI responses
3. Multi-Model Routing
Okara routes your messages to multiple AI providers (GPT-4, Claude, Gemini, etc.):
Visual Key
Important Clarifications:
- During Processing: Messages exist as plaintext in server memory for routing
- AI Providers: Receive messages in plaintext (required for model processing)
- After Processing: Messages encrypted before database storage
- Contractual Protection: AI providers contractually prohibited from training on your data
What This Means:
- Your stored conversation history is encrypted
- Active message processing requires plaintext handling
- We cannot route to AI models without processing plaintext
- Focus is on protecting long-term storage, not active processing
4. Retrieving Encrypted Conversations
When you access past conversations:
on your device
encrypted messages
on your device
- You authenticate with 6-digit passcode
- Okara retrieves encrypted private key from server
- Client derives decryption key from passcode
- Private key decrypted locally on your device
- Encrypted messages fetched from database
- Messages decrypted locally on your device
- Conversation displayed
Cross-Device Synchronization
How It Works:
- You log in on a new device with your 6-digit passcode
- Encrypted private key downloaded from Okara servers
- Passcode-derived key generated locally on new device
- Private key decrypted locally
- You can now decrypt conversation history on new device
Security Properties:
- Private key travels only in encrypted form
- Passcode never transmitted to server
- Each device decrypts locally
- Passcode compromise = access from any device (see Security Limitations)
Cryptographic Implementation
Algorithms and Standards
- Asymmetric Cryptography: X25519 ECDH (elliptic curve Diffie-Hellman)
- Key Derivation: Argon2id (t=4, m=128MB, p=2) + HKDF-SHA512
- Symmetric Encryption: AES-256-GCM (authenticated encryption)
- Random Number Generation: Cryptographically secure OS-level PRNG
- Transport Security: TLS 1.3 for all network communication
Key Derivation
Passcode to Encryption Key:
Passcode Key = Argon2id(
password = HMAC-SHA256(6_digit_passcode, server_pepper),
salt = unique_user_salt (256-bit),
iterations = 4,
memory = 128MB,
parallelism = 2
)Per-Message Encryption Key:
Shared Secret = X25519_ECDH(
ephemeral_private_key,
user_public_key
)
Message Key = HKDF-SHA512(
shared_secret,
salt = 'okara-encryption-salt',
info = 'okara-message-key',
length = 32_bytes // AES-256 key size
)Storage Format
Database Record:
{
"conversation_id": "uuid",
"message_id": "uuid",
"encrypted_payload": "base64(ephemeral_pubkey + iv + auth_tag + ciphertext)",
"timestamp": "2025-10-22T10:30:00Z",
"metadata": {
"model": "gpt-4",
"role": "user"
}
}Encrypted Payload Structure:
- Bytes 0-31: Ephemeral public key (X25519)
- Bytes 32-47: Initialization vector (AES-GCM)
- Bytes 48-63: Authentication tag (AES-GCM)
- Bytes 64+: Encrypted message content
Threat Model and Security Guarantees
What Okara's Encryption Protects Against
| Threat | Protection | Explanation |
|---|---|---|
| Database Breach | ✓ Strongly Protected | Attackers get encrypted data; cannot read without passcode |
| Stolen Database Backup | ✓ Strongly Protected | Backups contain only ciphertext |
| SQL Injection Attack | ✓ Strongly Protected | Even with full database access, conversations remain encrypted |
| Database Administrator Access | ✓ Protected | DBAs see only encrypted conversations |
| Cloud Provider Breach | ✓ Protected | Cloud providers store encrypted data |
| Long-term Storage Compromise | ✓ Protected | Historical data remains encrypted indefinitely |
| Physical Server Theft | ✓ Protected | Stolen hardware contains encrypted data |
| Network Eavesdropping (Transit) | ✓ Protected | TLS encryption for data in motion |
Trust Boundaries
What You Must Trust:
- Your device security (OS, hardware, malware protection)
- Your 6-digit passcode strength and protection
- Okara's implementation of cryptography
- Okara servers during active message processing
- AI provider security and contractual compliance
- The cryptographic algorithms (X25519, AES-256, Argon2id)
What You Don't Need to Trust (For Stored Data):
- Okara database security (conversations encrypted)
- Database administrators (cannot read encrypted content)
- Cloud storage providers (data encrypted)
- Backup security (backups are encrypted)
- Long-term data retention (remains encrypted)
Comparison with Other AI Platforms
| Feature |  |  ChatGPT |  Claude |  Gemini |
|---|---|---|---|---|
| Encrypted Storage | ✓ Yes | ✗ Unknown | ✗ Unknown | ✗ Unknown |
| Client-Side Key Generation | ✓ Yes | ✗ No | ✗ No | ✗ No |
| Database Breach Protection | ✓ Yes | ✗ Unknown | ✗ Unknown | ✗ Unknown |
| User-Controlled Decryption | ✓ Yes | ✗ No | ✗ No | ✗ No |
| Processing (Active Use) | Plaintext | Plaintext | Plaintext | Plaintext |
| Multi-Model Access | ✓ Yes | ✗ No | ✗ No | ✗ No |
| Plaintext Database Storage | ✗ No | ✓ Likely | ✓ Likely | ✓ Likely |
Key Differentiator: Okara is the only multi-model AI platform with client-side key generation and encrypted storage of conversation history. While messages are processed in plaintext (like all AI platforms), your stored conversation history is cryptographically protected from database breaches.
Use Cases: Where Encrypted Storage Matters
For Individuals
Healthcare Discussions: Your past conversations about symptoms, medications, and health concerns remain encrypted even if our database is breached. Medical history stays private long-term.
Financial Information: Discussions about income, investments, debt, and financial strategies stored encrypted. Protects sensitive financial data from database compromises.
Personal Writing: Journals, therapy reflections, and private thoughts encrypted in storage. Protects intimate content from unauthorized access.
Legal Matters: Past legal questions and sensitive situations remain encrypted. Reduces risk of exposure through data breaches.
For Businesses
Strategic Planning: Historical discussions about business strategy, competitive analysis, and roadmaps encrypted. Protects against intellectual property theft via database breach.
Proprietary Code: Past code review discussions stored encrypted. Protects source code and technical details from competitors who might compromise databases.
Confidential Deals: M&A discussions, partnership negotiations, and business development conversations encrypted long-term.
HR and Personnel: Performance reviews, hiring decisions, and sensitive employee discussions encrypted at rest.
The Core Value Proposition
Problem: Traditional AI platforms store complete conversation histories in plaintext databases.
Risk: Single database breach exposes years of sensitive conversations.
Okara's Solution: Conversations encrypted before database storage. Breach attackers get useless ciphertext.
Trade-off: Active processing still requires plaintext, but historical data remains protected.
Privacy Guarantees and Compliance
GDPR Alignment
Okara's encryption-at-rest architecture supports GDPR requirements:
- Data Minimization (Article 5): Plaintext not stored; only encrypted ciphertext retained
- Storage Limitation (Article 5): Encryption ensures data cannot be "accessed" without user key
- Right to Erasure (Article 17): Deletion removes encrypted data; keys deleted make data unrecoverable
- Data Portability (Article 20): Users can export their encrypted conversation history
- Security of Processing (Article 32): Encryption is "appropriate technical measure"
Data Retention and Deletion
Encrypted Conversations:
- Stored indefinitely until user requests deletion
- Encrypted with user-specific keys
- Inaccessible without user's passcode
Deletion Process:
- User requests conversation deletion
- Encrypted data removed from database
- Backups purged after 14 days
- Data becomes unrecoverable
Metadata Retention:
- Timestamps, conversation IDs stored unencrypted
- Model selection, message count stored for functionality
- Logs retained for 30 days (security monitoring)
- No message content in metadata or logs
Enterprise and Healthcare Readiness
Current Status:
- Encryption at rest for all stored conversations
- Client-side key generation and management
- User-controlled decryption
- Foundation for compliance requirements
Future Development:
- SOC 2 Type II certification (in progress)
- ISO 27001 certification (planned)
- Team workspaces with per-user encryption
- Enterprise audit logs and access controls
- On-premise deployment options
Note: Okara currently serves individual users. Enterprise compliance certifications will be completed as we expand to organizational deployments.
Technical FAQ
Q: Is this end-to-end encryption?
A: No. This is encryption at rest with client-side key generation. Messages are plaintext during active processing (necessary for AI routing) but encrypted in database storage. E2EE would prevent us from routing to AI providers.
Q: Can Okara read my stored conversations?
A: No. Stored conversations are encrypted and we cannot decrypt them without your passcode. However, during active use when you send a message, it exists as plaintext in our servers briefly for routing to AI providers.
Q: What about AI providers like OpenAI and Anthropic?
A: AI providers receive your messages in plaintext (required for model processing). We contractually prohibit them from training on your data. Your conversation history in our database remains encrypted.
Q: What happens if someone gets my 6-digit passcode?
A: They can access your account from any device and decrypt your entire conversation history. Treat your passcode like your bank PIN. We're exploring longer passphrase options for users who want stronger security.
Q: What if Okara's database is hacked?
A: Attackers would get encrypted conversations. Without your passcode, the data is ciphertext. However, 6-digit passcodes are vulnerable to brute-force attacks by sophisticated attackers. Argon2id makes this expensive but not impossible.
Q: Can you recover my conversations if I forget my passcode?
A: Only if you saved your recovery key during signup. Without your passcode or recovery key, encrypted conversations are permanently inaccessible. This is by design—no backdoors means we truly cannot access your data.
Q: Does encryption slow down the chat experience?
A: No. Encryption/decryption happens in the background for storage and retrieval. Active chatting is not affected by encryption overhead.
Q: Why not encrypt during processing too?
A: AI models require plaintext input to generate responses. Fully encrypted processing (homomorphic encryption) is not yet practical for real-time AI interactions. We focus on protecting long-term storage.
Q: Is this security audited?
A: Independent security audit in progress, with publication expected December 2025. Client-side code will be open-sourced for community review.
Q: What metadata do you store?
A: Timestamps, conversation IDs, model selection, and message roles (user vs assistant). Message content is encrypted. We don't analyze or process metadata for profiling.
Conclusion
Most AI chat platforms store conversation histories in plaintext databases. A single breach—increasingly common in our threat landscape—exposes years of sensitive conversations: business strategies, personal health information, financial details, and private thoughts.
Okara takes a different approach. While we process messages in plaintext during active use (necessary for multi-model AI routing), we encrypt conversation history before database storage. Your conversations are protected by client-generated keys that only you control.
We're honest about limitations:
- Messages are plaintext during active processing
- 6-digit passcodes are convenient but not maximum security
- AI providers receive plaintext for model processing
- Sophisticated attackers with database access face reduced but not eliminated barriers
But we're committed to protection where it matters most:
- Your conversation history is encrypted at rest
- Database breaches expose ciphertext, not your thoughts
- Only you can decrypt your conversations
- Long-term privacy through cryptographic guarantees
As AI becomes more integrated into our lives, protecting the privacy of our conversation histories is essential. Okara's encryption-at-rest system represents our commitment to that protection.
Your conversations deserve better than plaintext storage. Okara provides cryptographic protection for your conversation history.
Get Started
Try Okara: okara.ai
Pricing: $15/month, free trial available
Platforms: Web • iOS & Android coming soon
For Enterprise: Contact enterprise@okara.ai
About Okara
Okara is a privacy-focused AI chat platform providing unified access to multiple AI models while protecting conversation history through encryption at rest. Founded in 2025, we're building AI interfaces that respect user privacy through honest security practices.
This whitepaper is version 1.0, published October 22, 2025. For the latest version and technical updates, visit okara.ai/whitepaper.