RFC, open for review until Dec 11: a cloud mirror that AI assistants can search, where the server never stores the key

Author here. I’m posting this to get the design broken. Is it even possible to have an E2EE system with AI in the loop? AI assistants increasingly answer from a user’s mail, chat and calendar through tool calls, and the backend behind those calls is usually a database the provider can read. We want one where a stolen database, backup or bucket is useless, and each reader (an AI assistant, the web app, a script) has its own revocable access. The design, briefly: – The account key is made on the user’s desktop. The desktop encrypts each message (AES-256-GCM, content key derived with HKDF) and computes keyed search tags (HMAC-SHA256 over trigrams) before upload. – Each reader holds its own token. The server stores only the token’s hash and a copy of the account key locked to that token. – Per request, the server derives the unwrapping key from the token, opens the account key in memory, searches the tags, decrypts only the candidates, returns results and drops the key. – Attachments are encrypted by the storage service under a key derived per request and never kept. What it does NOT protect against, which is the part I most want checked: – A compromised running server captures the account key from any approved request, and that key opens the whole mirror until it’s rotated. Attestation would close this; it isn’t in v0.1. – The tags are deterministic trigrams, so whoever steals the database learns which messages share fragments and may recover text from frequencies. Sizes and timing are visible too. – The storage service sees each attachment in the clear while handling it. – Whatever an AI provider retrieves is outside the design. So this is not end-to-end encryption. It aims to make the at-rest and access story strong, and to state exactly what remains. Where review is most wanted: Is a keyed trigram index acceptable for this threat model, or should tag sets be padded? Is attestation (proving which code the server runs, in the style of Apple’s Private Cloud Compute) the right way to close the first limit? One content key per account with random 96-bit nonces; we propose a new content key each year via HKDF. Enough, or move to AES-GCM-SIV or XAES-256-GCM? Key rotation as a full re-upload from the desktop, or data keys wrapped by the account key? All seven questions: https://ajs-consult-llc.github.io/mirror-encryption-rfc/chapters/12-questions-for-reviewers.html What it doesn’t protect: https://ajs-consult-llc.github.io/mirror-encryption-rfc/chapters/10-what-it-does-not-protect.html Requirements: https://ajs-consult-llc.github.io/mirror-encryption-rfc/chapters/06-system-requirements.html How to comment: https://github.com/ajs-consult-llc/mirror-encryption-rfc/blob/main/CONTRIBUTING.md (the first round closes Dec 11, 2026) Prior art I drew on: searchable encryption (Song, Wagner and Perrig 2000; the leakage attacks in Cash et al. 2015) and Private Cloud Compute for the attestation question. If an open reference design for this already exists, point me to it. I’d rather adopt one than write one. submitted by /u/aaron-riffy [link] [comments]Technical Information Security Content & DiscussionRead More