Security Architecture

How TextSafe protects your data, and the limits of that protection.

The Core Principle

TextSafe operates on a zero-knowledge model. The server stores data it cannot read. Your text is encrypted in your browser before transmission, using keys derived from credentials that never leave your device.

If an attacker gained complete access to the database, they would find only encrypted blobs. Without the original passcode and color for each entry, the plaintext cannot be recovered.

Cryptographic Implementation

AES-256-GCM

Symmetric encryption with 256-bit keys. GCM mode provides both confidentiality and authenticity. Tampering with ciphertext is detectable.

PBKDF2-SHA256

Key derivation with 100,000 iterations. Converts your passcode and color into a cryptographic key. The iteration count makes brute-force attacks computationally expensive.

Random Initialization Vectors

Each encryption operation generates a fresh 12-byte IV using crypto.getRandomValues(). The IV is prepended to the ciphertext.

SHA-256 Storage IDs

The encryption key is hashed to create a 64-character hex storage identifier. This hash is one-way. The server cannot derive the key from it.

Data Handling

What the server stores

Encrypted content (IV + ciphertext, base64 encoded)
Storage ID (SHA-256 hash of the encryption key)
Expiration timestamp (expires_at column)
Last update timestamp (updated_at column)

What the server never receives

Your passcode
Your color selection
The encryption key
Plaintext content

Data Deletion

A background process runs every hour and executes DELETE FROM secure_storage WHERE expires_at < NOW(). Expired rows are permanently removed from the database. Rate limiting data (IP addresses) is purged after 24 hours via a similar mechanism.

Threat Model

TextSafe provides protection against:

Database breach: Leaked data contains only encrypted blobs. Without individual passcodes, content remains unreadable.
Network interception: HTTPS encrypts data in transit. The payload itself is already encrypted with your personal key.
Server operator access: We have no mechanism to decrypt stored content. This is architectural, not policy-based.
Credential guessing: Rate limiting blocks requests after 10 failed attempts per IP. The 32-color requirement adds 5 bits of entropy.

Known Limitations

TextSafe does not protect against:

Compromised endpoints: Malware on your device can capture keystrokes or screen content before encryption occurs.
Physical observation: Someone watching you enter credentials can learn them.
Weak passcodes: If you replace the generated passcode with something predictable, security decreases accordingly.
Credential loss: There is no recovery mechanism. Lost credentials mean the data remains encrypted until automatic deletion.
Browser vulnerabilities: The Web Crypto API is well-tested, but browser bugs could theoretically affect cryptographic operations.

TextSafe is designed for temporary, private storage. For long-term secrets or high-value data, use dedicated tools like PGP, hardware security keys, or encrypted local storage.

Questions?

The implementation uses standard Web Crypto APIs with well-documented behavior.

Back to TextSafe