End-to-End Encryption for Tor Hidden Services

True end-to-end encryption requires that encryption and decryption happen on the client side - the server never has access to decryption keys. For web applications on .onion services, JavaScript running in the browser handles encryption. The Web Cryptography API (available in Tor Browser) provides AES-GCM and RSA-OAEP encryption primitives. Keys are generated and stored in the browser (IndexedDB or memory) and never transmitted to the server. Encrypted ciphertext is transmitted and stored on the server. Decryption happens in the browser when the user accesses their data. This zero-knowledge design means server compromise does not expose user data.

Managing cryptographic keys in browser-based web applications presents the fundamental challenge: where to store keys. Options in order of security: in-memory only (keys lost on page close, requiring password-derived re-derivation on each session), stored in IndexedDB (persists across sessions, accessible by JavaScript but not transmitted to server), exported and stored by user (user pastes key material on each session, most secure but lowest usability). For practical applications, derive encryption keys from a user password using PBKDF2 or Argon2 in the browser, with the derived key used for symmetric encryption. The user's password is never sent to the server - only encrypted data is stored server-side.

The Signal Protocol provides industry-standard end-to-end encryption for messaging with forward secrecy (new keys for each message) and deniability. The libsignal-client library (available for JavaScript) implements the protocol for browser-based applications. Implementing Signal Protocol in a .onion service messaging application: users register X3DH key bundles (public keys for the initial key exchange), the server stores encrypted key bundles and ciphertext messages but never private keys or plaintext. The Double Ratchet algorithm provides per-message key derivation that limits exposure if any key is compromised. This is the same cryptographic foundation used by Signal, WhatsApp, and Facebook Messenger.

Zero-knowledge applications allow users to search and query their encrypted data without the server learning the search terms or results. Searchable Symmetric Encryption (SSE) allows building encrypted search indices where the server performs search operations on ciphertext without learning the query or the data. Simpler approaches: client-side decryption followed by client-side search (all data decrypted in browser, search performed locally - practical for small datasets up to a few thousand documents). For larger datasets, consider Bloom filter-based keyword indexes that allow approximate membership testing on encrypted data. These techniques involve significant cryptographic complexity - evaluate whether your specific application's privacy requirements justify the implementation effort.

End-to-end encryption in browser-based applications has practical limitations. Large files encrypted in the browser require significant client CPU for AES operations. Key backup is challenging - if a user loses their password or clears browser storage, their data may be permanently inaccessible. Key verification between users (verifying you have the correct public key for who you think you are communicating with) requires out-of-band verification channels or key transparency mechanisms. Design UX to guide users through key generation, backup, and verification rather than hiding these steps. Include clear explanation that the server cannot recover lost data (no recovery path if keys are lost) and that regular encrypted backups of key material are essential.