Whitepaper

Security & encryption in KENI

Version 1.2 — 2026-08

This document explains how KENI encrypts your data, where the keys live, what our server can and cannot see, and the deliberate trade-offs we made. We wrote it for people who actually read whitepapers — concise, no marketing.

1. Threat model

We assume the network is hostile and our infrastructure is assumed-breached. The goal is: even an attacker with full read access to our database, plus traffic capture between client and server, cannot read your 1:1 message text. (Group messages and the media you send in 1:1 are server-readable by design — see §5.)

We do not defend against malware on your own device, a compromised peer (your friend's phone), or a lawful subpoena against our compliance archive (see §5). If your threat model requires defending against state-level actors with subpoena power, Signal is the right answer — KENI made a different choice and we'll explain it honestly.

2. Key generation

On first install the client generates two key pairs on-device:

Private keys are never transmitted to our servers. The optional passphrase backup (§4) is the only way private keys leave the device, and that copy is encrypted with a key derived from a passphrase we never see.

3. Per-room session

When two users start a 1-on-1 chat:

  1. Client A fetches B's identity public key from server.
  2. Both clients run X25519 ECDH locally to derive a 32-byte shared secret.
  3. The shared secret seeds the initial ratchet root key. Each message is sealed with AES-256-GCM under a fresh 12-byte nonce; ciphertext, nonce and ratchet header are transmitted.
  4. Group chats default to server-side encryption with a compliance copy (see §5). An end-to-end group mode using the Sender Keys protocol (a rotating per-sender key distributed over each member's pairwise session) is available to every group; a new group starts server-readable and its owner switches the mode on.

1:1 sessions run a simplified Signal Double Ratchet. A fresh ephemeral X25519 key is generated at every DH ratchet step, and each message carries a ratchet header next to its ciphertext. That gives forward secrecy — message keys from before a ratchet step cannot be re-derived — and break-in recovery: once a peer's new ratchet public key arrives, future message keys are independent of any key leaked earlier.

The boundary, stated plainly. This is a simplified ratchet, not a line-for-line Signal implementation. And messages sent before the ratchet shipped carry no ratchet header — they are still decrypted over the original static-X25519-ECDH path, so forward secrecy does not apply retroactively to that history.

Several devices on one account are handled per-device, not per-account. Each device publishes its own key and is delivered its own copy of a message. The distribution query returns approved devices only, so a device that has not been approved is handed nothing it could decrypt — the gate fails closed, not open. Your first device approves itself; every device after it starts pending and must be approved from one you have already approved. The safety number you compare with a contact covers their whole approved device set, so a device appearing on their account shows up as a change in that number rather than as a silent addition.

4. Identity backup (zero knowledge)

Losing your phone shouldn't lose your message history. Users can opt into a passphrase-backed key escrow:

  1. User types a passphrase (≥ 8 chars), entered only on-device.
  2. Client generates a random 16-byte salt.
  3. Client runs PBKDF2-SHA256, 600,000 iterations, salt + passphrase → 256-bit KEK. Backups written before this count was raised record their own iteration value and are read back at it.
  4. Client encrypts { identity_priv, identity_pub, prekey_priv, prekey_pub } as JSON with AES-256-GCM under KEK, fresh nonce.
  5. Client uploads { version, salt, ciphertext } to server.

Server stores opaque ciphertext. Without the passphrase we can't derive the KEK; without the KEK we can't decrypt. Lost passphrase = permanently lost backup. We will not "reset" your identity for you because we can't.

5. Compliance archive (be aware)

1:1 message text is end-to-end encrypted only — no compliance copy, nothing we can decrypt, not even us. Group messages keep a compliance copy encrypted with KENI's platform public key (group chats are server-readable by design; an end-to-end group mode is available and is switched on per group by its owner). The group compliance copy exists for two reasons:

The platform private key is held in HSM-grade storage. Access is gated on multi-party authorization with logged justification. We do not mine the archive for product analytics, advertising, or training data. If this trade-off doesn't fit your threat model, please use Signal — we won't be offended.

6. AI features (what leaves your device)

AI features (the KENI assistant, intent routing, summarization) are not E2EE. The cloud LLM has to read your prompt to answer. What we do:

7. TURN / WebRTC media

Voice/video uses WebRTC. Signaling goes through our WS gateway (the SDPs themselves are not message content). Media flows peer-to-peer when NAT allows; behind symmetric NAT we relay through our own coturn server (turn.hikeni.com). The relay sees encrypted SRTP packets — it cannot decrypt media. Each session uses HMAC-SHA1 short-term TURN credentials (24h TTL) signed by the gateway with a server-only secret; users never see permanent TURN passwords.

8. What we deliberately did NOT do

9. Open issues & roadmap

10. Contact

Found a bug in our crypto? Want to argue with a trade-off above? Email safety@hikeni.com. We read every report and reply within 5 working days.