Lumo is an AI assistant for people who care about privacy. Whether you’re drafting emails, solving technical problems, or simply looking for answers, Lumo helps you get more done without compromising your data. Powered by open-source language models and built on Proton’s zero-access encryption, Lumo offers a secure alternative to mainstream AI tools.

Let’s explore the architecture behind Lumo’s privacy-first design and the features that make it a trustworthy choice for private, encrypted AI conversations.

Why privacy in AI matters

As data breaches and privacy invasions proliferate, ensuring the confidentiality of large language models becomes not just a technical challenge, but an ethical imperative. People go to AI assistants for help with sensitive issues, from medical conditions to confidential business matters. They should be able to share this kind of information without fearing that their data will train language models, be exploited by Big Tech companies or governments, or leaked in a data breach.

At Proton, we build products with privacy by design, and Lumo is no exception. Individuals and organizations should be able to use AI with confidence, knowing their most sensitive information remains protected.

Challenges of full E2EE for AI systems

Typically, Proton’s data security models involve full end-to-end encryption, as seen in our private email and secure cloud storage products. Why? Because E2EE ensures that the data is never accessible to the platform itself. For example, when you send an email in Proton Mail, your messages are encrypted on your device before being sent to the servers and can only be opened by the intended recipient. Proton can’t see them, and even if our servers were breached, the messages would remain unreadable by anyone else.

Achieving full end-to-end encryption for AI systems presents unique challenges. Ideally, messages should be encrypted in a way that even the LLM cannot read them. The most promising technique for this is homomorphic encryption (HE), also sometimes discussed under the fully Homomorphic Encryption (FHE) variant. However, HE is very, very resource-intensive and extremely slow. While regular AI like ChatGPT responds to queries in a few seconds, experiments with HE have shown responses taking more than a day(new window). While the technical achievement is impressive, waiting so long for a reply is impractical.

Clearly, we can’t sit and wait for HE to be ready. We need to find practical solutions for the AI privacy problem — today.

Thankfully, there are other ways to offer a high level of privacy and a smooth user experience. Security is intrinsically linked to practicality(new window); a system that prioritizes safety at the expense of usability is likely to be underutilized, making it less protective in the end.

With Lumo, we implement several forms of encryption to maximize user privacy. Compared with other LLM apps, Lumo’s implementation is simply much stronger than anything else on the market. To understand why, we must look at two distinct phases in a person’s interactions with AI:

Encryption in transit: How do we ensure that messages between the user and the AI are unreadable by anyone else?

Encryption at rest: How do we ensure private long-term storage?

Each of these two stages requires a distinct solution, which we explore in the following sections.

User-to-Lumo (U2L) encryption: Securing the pathway to the LLM

Our first solution to the problem of securely chatting with an AI is to encrypt all communications between the user’s device and Lumo. Usually with end-to-end encryption, both “ends” are human, but here the other end would be the language model itself. As noted above, true E2EE that bypasses the LLM server would be far too slow using homomorphic encryption or something else. So we need to provide the LLM with cleartext messages.

Short of E2EE, we can still build a tightly secured pathway between the user and Lumo. In one sense, you could define this setup as a form of end-to-end encryption where the user is one “end” and Lumo is the other “end.” That said, we acknowledge this is not the regular definition of end-to-end encryption, which is why we prefer to call it user-to-Lumo (U2L) encryption to avoid any misunderstanding.

A diagram of how Lumo encrypts your queries and responses

To achieve our objective, we use classic, battle-tested, bidirectional asymmetric encryption between the user’s device and the LLM. Here are the main steps:

  • Lumo public key: Ahead of time, the LLM server publishes a public, static PGP key for all clients. This key is fetched by the user’s device and will be used to secure the user-to-Lumo direction of the pipeline.
  • User message encryption: The user’s device generates a symmetric AES(new window) key for the duration of the request. This key is used for encrypting the user’s message and the LLM’s response. With each new message, we must send the full conversation from top to bottom, because the LLM server is memoryless and does not keep any logs of the conversation from a previous session.
  • Encryption of AES key: The AES key is encrypted using the LLM’s public PGP key and included alongside the request. This ensures that only the LLM server, which has the corresponding private PGP key, can decrypt the AES key.
  • Request ID: The Lumo app sends a unique identifier called the Request ID alongside the request using a common encryption scheme known as AEAD. This ID is used for authenticating that the request messages are confidential and are the original message generated by the user. AEAD ensures no attacker has substituted the message or response with a different message.
  • User message encryption: When the user sends a message to Lumo, the message is encrypted using the AES key. This key is also used for encrypting the response from the LLM.
  • TLS encryption: The AES-encrypted user message, the encrypted AES key, and the Request ID are sent to Proton servers through a layer of TLS encryption (HTTPS). TLS encryption is a common, standard practice, and virtually all modern websites implement it as part of their basic setup. It simply hides the content of your communications from third parties on the network, such as your ISP, internet backbone routers, and the ISP connecting to our data center. (TLS encryption happens on every communication from your device to Proton, not just Lumo.)
  • Internal routing: The encrypted message reaches Proton servers at the TLS termination endpoint, at which point it is routed through a series of internal systems — load balancing, Lumo backend application server, message queues, etc. — until it finally reaches the LLM server. At this point, the message is still encrypted, which means that no intermediate system inside Proton can read the message content: They merely forward opaque payloads to the LLM server.
  • Decryption by LLM server: The LLM server possesses the private counterpart of the PGP key the request was encrypted with, and thus can decrypt the AES key. Using this key, the LLM gets to see the decrypted user message and process it directly. The user’s cleartext message never leaves the server, and the request is not logged or retained by the LLM server after completing that request.
  • Response generation: After reading the user request, the LLM starts to generate a response. This is usually done in a streaming fashion, meaning the LLM generates a sequence of sub-words known as tokens, resulting in the word-by-word effect you tend to see in most AI chat apps, including Lumo.
  • Response encryption: To encrypt these tokens on their way back to the user’s Lumo app, we use the same AES key. Each token packet is encrypted with the AES key and authenticated with AEAD based on the Request ID. It crosses the network layer AES-encrypted, is then routed through Proton internal systems as an opaque payload, and then gets further encrypted with the same TLS channel between Proton and the user’s device, where it can be finally decrypted.

To summarize, the message is encrypted using a symmetric AES key, which is itself encrypted with the LLM’s public PGP key. The LLM server decrypts the AES key and processes the user message in place. The response is encrypted using the same AES key, ensuring the cleartext message never leaves the server. To protect your privacy, the LLM server forgets the request as soon as the response is generated.

All of this happens automatically in the background, so you can enjoy the benefits of chatting with Lumo without having to think about encryption.

At-rest zero-access encryption for conversational history

Once the LLM has generated a response, we can leverage full zero-access encryption to ensure state-of-the-art security and privacy for the conversational history. The LLM server is not involved in this step; the task at hand is to retain user data for long-term storage in a way that only the user can decrypt. Unlike the User-to-Lumo setup described in the previous section, in which the other “end” was the LLM server, in this case both “ends” are the user, which meets the traditional definition of E2EE. In other words, no system at Proton can ever read a Lumo conversational history.

We employ a robust encryption technique, similar to that used in Proton Mail, Drive, and Calendar, which combines asymmetric and symmetric encryption. This method ensures that only the user’s device can decrypt the stored data.

Each piece of content, including messages, conversation metadata, and attachments, is encrypted using a set of symmetric keys known as Conversation Keys. These Conversation Keys are themselves encrypted using a symmetric Master Key, which is unique to each user. Finally, the Master Key is also encrypted, this time asymmetrically, using the user’s PGP keypair, which requires the user password to be unlocked. This means that the user password is the ultimate layer of security and the cornerstone of this scheme’s soundness. It is essentially the same principle — albeit with a slightly different key hierarchy structure — that secures your data in other Proton apps; in all cases, your account password is always the supreme lock to your data vault.

After a user sends a message to Lumo and receives a response, the client application closes the PGP-secured connection described in the first section, and prepares for long-term conversation storage. It starts by encrypting both messages using the Conversation Key. These encrypted messages are then sent to Proton servers for storage in our data centers. Although the files are stored on our servers, the zero-access encryption prevents us (or anyone else) from opening them. But users can log in to their account and access their conversation history on the left sidebar of the Lumo app.

Additionally, conversation data is cached in the browser’s local storage, following the same encryption scheme. This means that even if someone steals your hard drive, your data remains secure as long as the thief doesn’t know your password.

By implementing this multi-layered encryption approach, we ensure that your conversations with Lumo are not only secure in transit but also protected at rest. This commitment to privacy and security is at the heart of everything we do at Proton, and we are proud to extend these principles to the AI world.

Conclusion

Undoubtedly, LLMs are one of the most groundbreaking inventions of the last decade, yet major platforms today often fall short of providing robust privacy safeguards, leaving user data vulnerable to exploitation. These companies can use your chats with AI to further train their systems, potentially leaking sensitive information you provide. What’s more problematic is that your data may remain available forever in a Big Tech database. They can decide at any point to turn a profit by selling it or to share it with third parties — it wouldn’t be the first time(new window) — or your chats could be exposed in a data breach. The political climate is also uncertain and no one can predict what governments will do if they access your data.

With Lumo, we’re offering a private alternative. First, your messages are encrypted across the entire network, including Proton’s internal pipeline, until they reach the LLM, which keeps no logs of your chats. On the way back, the reply is secured with the same encryption strategy, ensuring your message never crosses any network boundary unencrypted. Second, your conversation history is zero-access encrypted using a second encryption process. We use classic encryption at rest, protected by the account password, which is only known to the user. This uses the same battle-tested principles as the ones behind Proton Mail, Proton Drive, Proton Pass, and our other services that protect the data of over 100 million people.

Ultimately, what matters to us is that these strong guarantees are available to anyone, not just tech-savvy people who already seek out privacy tools. This is why we have designed the experience such that users don’t need to think about the cryptography behind it. This is, in our view, where security becomes truly useful — when it’s practical.

We hope you have smooth, delightful, and — most of all — secure discussions with Lumo.