> For the complete documentation index, see [llms.txt](https://wiki.gen6.life/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.gen6.life/solutions/gen6-msg.md).

# NCrypt

**NCrypt is Gen6's encryption layer.** It provides the key generation, key distribution, key exchange, and authenticated encryption that the rest of the Gen6 stack relies on whenever data must be readable by some parties and not others.

Encrypted messaging is the most visible application of NCrypt — but it is an application of the layer, not the layer itself. Every Gen6 identity receives NCrypt keys at the moment its wallet is created, which means encryption capability is a property of the identity rather than a feature a user opts into later.

### The Layer

NCrypt handles four things on behalf of the wider stack:

**Key generation.** NCrypt keypairs are generated on the user's device at wallet creation, in seed-words format alongside the wallet keys. Private keys never leave the device and are never escrowed — Gen6 cannot recover a lost key because Gen6 never holds one.

**Key distribution.** The NCrypt public key is published on the Gen6 chain and bound to the identity. This is what allows any party to encrypt data to any Gen6 identity without a prior handshake, an introduction, or a central directory.

**Key exchange.** Establishes a shared secret between parties (currently X25519; migrating to hybrid X25519 + ML-KEM-768 — see below).

**Authenticated encryption.** Encrypts the payload and authenticates its origin, so that content is both unreadable to outsiders and verifiably unmodified for the recipient.

Because these are identity-level rather than app-level capabilities, anything in Gen6 that needs confidentiality or selective disclosure can build on NCrypt instead of implementing its own cryptography — which is the point of having an encryption layer at all.

### Messaging: the primary application

NCrypt messaging is decentralized, end-to-end encrypted communication built directly on the layer above.

**Only the intended recipient can read a message.** No Gen6 server, node operator, or intermediary can decrypt a conversation.

**Messages cannot be altered undetected.** A modified message fails authentication rather than arriving silently changed.

**Send and read events can be made indisputable.** Optionally, proof that a message was sent — and read — is anchored on the Gen6 chain. Neither party can later deny it, and no third party is needed to adjudicate. The *content* stays private while the *fact* of communication becomes provable. This is the property that distinguishes NCrypt from conventional encrypted messengers.

**Notifications preserve privacy.** Message notifications never carry message content.

### What NCrypt Does Not Claim

Stated precisely, because an overstated guarantee is a weaker one:

* **Encrypted traffic can still be captured.** Encryption prevents data from being *read*, not from being *observed or recorded*. This is not academic — it is the entire basis of the "harvest now, decrypt later" threat driving the post-quantum roadmap below. The accurate claim is that captured traffic is unreadable, not that capture is impossible.
* **Encryption does not conceal that communication occurred**, unless send/read anchoring is deliberately left unused. Content confidentiality and metadata minimisation are different properties.
* **Key custody is the user's responsibility.** This is a deliberate design choice, and its cost is that key loss is unrecoverable.

### Technical Data

**Infrastructure**

|         |                |
| ------- | -------------- |
| Pallet  | `postman`      |
| API     | Gen6 MW        |
| Storage | IPFS or custom |

**Cryptography (current)**

| Function           | Primitive                        |
| ------------------ | -------------------------------- |
| Key exchange       | X25519 (Curve25519 ECDH)         |
| Authentication     | Ed25519 (EdDSA)                  |
| Payload encryption | ChaCha20-Poly1305 (256-bit AEAD) |

**Key lifecycle**

* Generated at **wallet creation**, seed-words format, on-device
* Public key **published on the Gen6 chain**, bound to the identity
* Private key never uploaded, escrowed, or recoverable by Gen6

***

### Post-Quantum Roadmap

X25519 and Ed25519 are both broken by a sufficiently capable quantum computer. ChaCha20-Poly1305 is not — at a 256-bit key it remains strong and is retained unchanged.

**Because NCrypt is the encryption layer rather than a single feature, its post-quantum migration is the highest-priority work in the entire Gen6 stack.** Two reasons compound:

1. **Retroactive exposure.** Encrypted data captured today can be decrypted years from now. Signature forgery has no equivalent — a signature forged after the fact is worthless. Confidentiality is the only part of Gen6 where the quantum threat is active today rather than pending.
2. **Blast radius.** Anything in Gen6 that relies on NCrypt for confidentiality inherits its cryptographic posture. Migrating the layer migrates everything built on it; leaving it classical leaves all of it classical.

Target: hybrid key exchange (X25519 + ML-KEM-768) with ML-DSA authentication, ChaCha20-Poly1305 retained. A working prototype of the post-quantum encryption path already runs at [pqc.gen6.life](https://pqc.gen6.life).

### Technical Data

* Pallet used: postman
* API used: Gen6 MW
* Storage used: IPFS or custom