# Encryption Encryption is the main layer that protects the content of messages in Sealed. Its purpose is simple: before a message leaves the sender’s device, it is turned into unreadable data that only the intended recipient can open. Sealed uses encryption not only to hide what a message says, but also to reduce what can be learned around the message. This is why the encryption design combines message encryption, post-quantum protection, separate keys for each conversation, changing hints, Padmé-style padding. ### End-to-end message encryption Sealed uses end-to-end encryption based on **AES-GCM with an HKDF-derived key**. In simple terms, AES-GCM protects the message content, while HKDF helps create the encryption key used for that message from shared cryptographic material. For the user, this happens automatically. They write a message and press send. Before the message leaves the device, Sealed encrypts it locally. The readable version of the message is not sent to the blockchain, RPC infrastructure, notification systems, or any server. It becomes readable again only after the recipient’s device decrypts it locally. ### Post-quantum protection Sealed adds quantum-resistant protection through a hybrid approach: **X25519 + ML-KEM-512**. X25519 is a modern key exchange method widely used in secure communication, while ML-KEM-512 is a NIST-standardized post-quantum mechanism designed to protect against known quantum-computing attacks. The reason for combining both is long-term resilience. X25519 protects communication with a proven modern standard, while ML-KEM-512 adds protection against future risks, including “save now, decrypt later” scenarios where encrypted data is stored today in the hope that it can be decrypted years later. ### Separate keys for each conversation Each Sealed Alias Chat conversation uses its own separate set of keys. This means that one conversation is not protected by the same cryptographic material as every other conversation. This separation is important because it limits how much can be connected or affected at once. If a user has multiple conversations, each one has its own encryption context. A problem in one conversation should not automatically expose the cryptographic material of another conversation. ### Changing hint for every message Sealed uses hints to help the recipient’s app recognize which encrypted messages are intended for it. A hint is not the message content. It is only a detection marker that allows the app to find relevant encrypted messages inside the larger Sealed message flow. To reduce linkability, the hint changes with every message. This means that messages in the same conversation do not expose one permanent marker that can easily be followed over time. The recipient’s app can still recognize the messages, but outside observers have a harder time grouping them into one conversation. ### Padmé-style padding Sealed uses **Padmé-style padding** for every message. Padding changes the visible size of encrypted messages so that the original length of the plaintext is harder to guess. This matters because message size can reveal information even when the content is encrypted. Without padding, an observer may not know what a message says, but they could still notice whether it was very short, unusually long, or part of a recognizable pattern. Padmé-style padding reduces this kind of size-based analysis without forcing every message into one fixed size. ### Encryption summary Sealed protects messages with layered encryption. Message content is encrypted locally with AES-GCM using HKDF-derived keys, while hybrid X25519 + ML-KEM-512 adds post-quantum protection. Each conversation uses a separate key set, every message receives a changing hint, and Padmé-style padding reduces what can be learned from message size. When messages are sent or retrieved through blockchain infrastructure, OHTTP protects the user’s IP address from the RPC layer. Together, these mechanisms are designed to protect not only the message content, but also the surrounding signals that could otherwise make private communication easier to analyze. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.sealed.channel/security-and-privacy/encryption.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.