znce2e implements the AndroidIRCX/mIRC-compatible IRC E2E message format for use inside ZNC. It improves confidentiality on the IRC network side, but it is not a Signal/Matrix-style modern secure messenger.

ZNC is inside the trust boundary.

When you use this module, plaintext exists inside the ZNC process after decrypting incoming messages and before encrypting outgoing messages. A ZNC administrator, shell administrator, debugger, process dump, malicious module, or compromised host can potentially access plaintext and keys.

Use TLS between your IRC client and ZNC. If the client-to-ZNC connection is not encrypted, plaintext can travel over that link even though the server-side IRC message is encrypted.

Current ZNC implementation stores identity keys, DM keys, channel keys, and auto-encrypt flags in ZNC module NV state. Treat that storage as sensitive.

Do not share the ZNC datadir. Backups of the datadir contain the module's long-term keys unless you add external encryption.

Encrypted-at-rest storage is not implemented yet.

Known limitations inherited from the current project scope:

• No perfect forward secrecy for stored long-term DM/channel keys.
• No Double Ratchet or MLS-style group ratchet.
• No replay protection yet; old valid encrypted payloads may be replayed by an attacker.
• Channel keys are shared symmetric keys. Anyone who receives a channel key can read and write messages for that channel key epoch.
• Key verification UX is minimal. Use out-of-band verification for public key fingerprints when high assurance is needed.
• Message length is limited by IRC line limits after JSON/base64 expansion.
• The module hides raw protocol messages from attached clients only when showraw off; raw encrypted lines may still exist in server logs or IRC logs.

The module must not silently fall back to plaintext when encryption was explicitly requested.

Expected behavior:

• encmsg and chan send refuse to send if a required key is missing.
• auto dm and auto chan halt outgoing plaintext if the required key is missing or encryption fails.
• Incoming encrypted messages are rejected if parsing, sender-key validation, or AEAD authentication fails.

Never overwrite a loaded ZNC module binary. Unload first:

/msg *status unloadmod znce2e

Then copy the rebuilt .so/.dll, and load it again:

/msg *status loadmod znce2e
/msg *znce2e selftest

Windows ZNC modules are C++ ABI-sensitive. Build with the same compiler/runtime/toolchain as the target ZNC process. Prefer the target installation's own znc-buildmod or the same MSYS2/MinGW environment used for ZNC.

For security issues, avoid posting secrets, private keys, plaintext messages, ZNC datadirs, or raw logs containing keys. Provide reproduction steps with synthetic keys/messages whenever possible.