Archived

This project has been archived and is no longer under active development. The source code and documentation are provided as-is for reference and educational purposes.

Open Source · Privacy-First Messaging · v3.0

KaleidoTalk End-to-end encrypted chat that protects content — and the metadata everyone else leaks.

Ed25519 identity X25519 ECDH AES-256-GCM encryption HKDF-SHA256 derivation 2048 B cover packets 24 h key rotation TOFU trust GPL-3.0
2048 B
Fixed packet size — no size leaks
24 h
Automatic X25519 rotation cycle
600k
PBKDF2-SHA256 iterations
6
BIP39 words per fingerprint
99.66%
Payload efficiency, large messages
≤620 B/s
Idle cover-traffic bandwidth
01 · Overview

Privacy is engineered, not assumed.

KaleidoTalk is an open-source, end-to-end encrypted instant messaging system built from scratch with privacy as its foundational principle. It combines Ed25519 identity keys, X25519 key exchange, AES-256-GCM symmetric encryption and HKDF-SHA256 key derivation so that only the participants of a conversation can read its content.

But encryption alone is not enough. Even when ciphertext cannot be read, packet sizes and timing still leak behaviour. KaleidoTalk therefore ships a cover traffic layer — a fixed-length packet protocol with random padding and randomised heartbeat intervals — that resists traffic analysis based on observable packet characteristics.

Version 3.0 adds automatic 24-hour key rotation for bounded forward secrecy, an irreversible account freeze backed by Ed25519 recovery certificates, and a modern bubble-chat interface — all under a trust-on-first-use model that removes reliance on centralised certificate authorities.

The Manifesto

  • End-to-end encryption is non-negotiable.
  • Code must be open source for public audit.
  • Users — not certificate authorities — control trust.
  • Metadata (packet sizes & timing) must also be protected.
  • No ads, no trackers, no data mining.
“Privacy is a human right. We write code to protect it.” — Bangze Han, author of KaleidoTalk
02 · Capabilities

A defence-in-depth architecture

Every layer of the stack — identity, key exchange, transport, session, and network behaviour — is hardened independently, so a failure at any single layer does not expose your conversations.

Confidentiality

End-to-end encryption

Messages are sealed with AES-256-GCM before they leave the device. The server relays only ciphertext and never possesses a decryption key.

Eph. X25519 → ECDH → HKDF → AES-256-GCM
Forward secrecy

Fresh key per message

Each message uses a one-time ephemeral X25519 key pair that is discarded immediately after encryption — past messages stay sealed even if long-term keys are later compromised.

PFS via per-message ephemeral keys
Bounded exposure

Automatic key rotation

X25519 keys rotate every 24 hours; the server retains multiple key versions so delivery continues during the transition. A leaked key exposes at most a 24-hour window.

Rotation cycle 24 h · key_id in every message
Account safety

Irreversible account freeze

An Ed25519 recovery certificate is generated at registration. If credentials are stolen, the account can be permanently frozen — no server command or admin can unfreeze it.

Ed25519 recovery cert · no unfreeze path
Metadata protection

Cover traffic

All traffic is wrapped in fixed 2048-byte packets with random padding; randomised heartbeats mask idle periods. Packet size and timing reveal nothing about the conversation.

2048 B packets · heartbeat 3.3–6.7 s
Self-sovereign trust

TOFU + BIP39 fingerprints

No certificate authorities. Server and contact identities are verified out-of-band via six human-readable BIP39 words — trust is your choice, not a corporation's.

SHA-256 → 6-word BIP39 fingerprint
Reliability

Offline message queue

Messages to offline contacts are queued on the server and delivered automatically on next login — before any other communication.

Queued ≤ 10 MiB per message
Operations

Hardened session & DoS layer

HMAC-authenticated requests with per-session sequence numbers and timestamp caching block replay; per-IP rate limiting with automatic banning mitigates flooding.

HMAC-SHA256 · anti-replay · IP bans
03 · Cryptography

Standard primitives, assembled with care

KaleidoTalk uses well-audited, industry-standard algorithms — never homebrew crypto — composed into a single coherent protocol.

ComponentAlgorithmPurpose
Identity keyEd25519Signs sender identity; sender authentication & non-repudiation
Key-exchange keyX25519 (ECDH)Shared-secret agreement, rotated every 24 h
Symmetric cipherAES-256-GCMMessage encryption with built-in authentication
Key derivationHKDF-SHA256Derives AES key & nonce from the ECDH secret
Password storagePBKDF2-SHA256 · 600kServer-side hash; brute-force resistant
TransportTLS 1.2+ · RSA 2048Client–server channel; self-signed + TOFU trust
FingerprintsBIP39 · 6 wordsHuman-verifiable identity comparison (66 bits)
Message pipeline
STEP 01
Ephemeral X25519
fresh key per message
STEP 02
ECDH
recipient's public key
STEP 03
HKDF-SHA256
salt → key + nonce
STEP 04
AES-256-GCM
seal plaintext
STEP 05
Ed25519 sign
authenticate sender
STEP 06
2048 B packet
+ random padding

Defence in depth: passwords are additionally sealed with the server's X25519 public key before they ever reach the wire — so credentials stay confidential even if the TLS tunnel were terminated. The ephemeral key guarantees perfect forward secrecy: the private key is discarded the moment encryption completes.

04 · Cover Traffic

What your traffic looks like to an observer

Encrypting content hides what you say. Cover traffic hides whether you are saying anything at all — and how much.

Fixed-length packet — 2048 bytes
TYPE1 B
LEN2 B
SEQ2 B
TOTAL2 B
PAYLOAD ≤ 2041 Breal data
RANDOM PADDINGos.urandom
7-byte header + payload + random padding = exactly 2048 bytes, always.

Size indistinguishability

Every packet is byte-for-byte the same length — a one-line message and a long attachment produce identical packets on the wire. Padding is drawn from a cryptographically secure RNG, so an entropy analysis cannot tell padding from data.

wire:

Real messages are fragmented and reassembled transparently; large payloads achieve 99.66% efficiency.

Timing indistinguishability

Both client and server emit padding-only packets at randomised intervals — a technique called traffic morphing. Idle standby looks identical to active conversation.

interval = 5.0 + U(−1.67, +1.67) s  →  3.3 – 6.7 s
idle:

Pure padding packets carry no data — but on the wire, nobody can tell them apart from the real thing.

05 · Whitepaper

Specified, analysed, and documented

KaleidoTalk is accompanied by a technical whitepaper covering the architecture, protocol, threat model, security properties, and performance characteristics.

Technical Whitepaper

KaleidoTalk 3.0 — Secure End-to-End Encrypted Chat with Cover Traffic

Complete protocol specification: key hierarchy, message encryption, session & HMAC authentication, replay and DoS protection, the irreversible freeze protocol, network command set, and security analysis.

PDF · English · v3.0
FeatureSignalToxMatrixKaleidoTalk
End-to-end encryptionOptional
Forward secrecy✓ ratchet✓ ratchetPartial✓ bounded (24 h)
Automatic key rotation✓ 24 h cycle
Cover traffic
Open source✓ GPL-3.0
No CA dependency✓ TOFU
Irreversible account freeze
Offline messages
BIP39 fingerprintsPartialPartial✓ 6 words

KaleidoTalk's distinguishing contributions — cover traffic for metadata protection and an irreversible account freeze — are absent from mainstream alternatives.

06 · Security Posture

What we claim — and what we do not

An honest threat model matters as much as a strong one. KaleidoTalk is designed against a network-level adversary and a semi-honest (honest-but-curious) server.

Security properties

  • End-to-end confidentiality — the server never holds decryption keys
  • Bounded forward secrecy — per-message ephemeral keys + 24 h rotation
  • Sender authentication — every message signed with Ed25519
  • Message integrity — authenticated encryption detects tampering
  • Replay protection — sequence numbers + timestamp caching
  • DoS resilience — per-IP rate limiting with automatic bans
  • Metadata protection — fixed packets + randomised heartbeats
  • Trust agility — TOFU eliminates centralised CAs

Explicitly out of scope

  • IP-level traffic correlation between two endpoints
  • Compromise of both communicating devices at once
  • Physical coercion / rubber-hose cryptanalysis
  • Deniability — signatures intentionally provide non-repudiation
  • TOFU first-connection weakness — mitigated by human verification of BIP39 words
  • Large-scale deployment — JSON persistence is sized for small private servers
07 · Getting Started

Run your own server in minutes

KaleidoTalk is a self-hosted system: you control the infrastructure, your friends control their keys. Python 3.8+ is all you need.

Install
# optional: use a virtual environment
pip install -r requirements.txt
Start the server
python run_server.py
# first run: set an admin password · TLS certs generated in server_keys/
# configuration: edit config.json (host, port, rate limits, …)
Start the client
python run_client.py
# verify the server's 6 BIP39 words on first connection
# register, keep your recovery key safe, and start chatting
STEP 01

Verify trust

On first connection, confirm the server fingerprint — 6 BIP39 words — through an independent channel. Compare contact fingerprints the same way.

STEP 02

Choose key storage

Server-hosted (encrypted, cross-device login) or local-only keys — and generate your recovery certificate for the freeze mechanism.

STEP 03

Freeze in emergencies

Lost credentials? Permanently lock the account with the standalone tool — freeze_account.py — no server admin can reverse it.