Skip to main content
TASIOMIND.DEV — OPERATIONAL▸▸▸FULL STACK DEVELOPER @ GWQ SERVICEPLUS AG▸▸▸FOUNDER — K8SGPT.AI▸▸▸OPEN SOURCE: ACTIVE▸▸▸DISTRIBUTED SYSTEMS / KUBERNETES / AI▸▸▸RUST + GO + PYTHON▸▸▸FIELD TESTED / STATUS — NOMINAL▸▸▸LOCATION: EUROPE/BERLIN▸▸▸TASIOMIND.DEV — OPERATIONAL▸▸▸FULL STACK DEVELOPER @ GWQ SERVICEPLUS AG▸▸▸FOUNDER — K8SGPT.AI▸▸▸OPEN SOURCE: ACTIVE▸▸▸DISTRIBUTED SYSTEMS / KUBERNETES / AI▸▸▸RUST + GO + PYTHON▸▸▸FIELD TESTED / STATUS — NOMINAL▸▸▸LOCATION: EUROPE/BERLIN▸▸▸
on the bench

CMD Chat – Ephemerer, verschlüsselter Konsolen-Chat

Eine sichere, ausschließlich im Arbeitsspeicher laufende Konsolen-Chatlösung mit tokenbasierter Authentifizierung, sessionbasierter Verschlüsselung und optionaler TLS-Unterstützung. Ideal für vertrauliche, kurzlebige Kommunikation.

Aland Baban · October 2025 · 5 min read · tier:[flagship]
PythonasyncioRSA-2048AES-GCMDockersystemd
View repo
[ click to zoom ]
01 / 03

CMD Chat ist eine minimalistische und sicherheitsorientierte Chat-Anwendung für die Konsole. Alle Nachrichten existieren ausschließlich im Arbeitsspeicher (RAM) und werden standardmäßig nicht persistent gespeichert. Die Anwendung richtet sich an Nutzer, die eine Lösung für kurzfristige und vertrauliche Kommunikation benötigen, beispielsweise für interne Abstimmungen, Debugging-Sitzungen oder temporäre Dateiübertragungen.


Sicherheitskonzept

Jeder Client erzeugt beim Verbindungsaufbau ein RSA-2048-Schlüsselpaar. Über diesen Handshake wird für jede Sitzung ein symmetrischer AES-GCM-Session-Key ausgehandelt. Nachrichten werden ausschließlich im Arbeitsspeicher des Servers verarbeitet und weder gespeichert noch protokolliert.

Hinweis: Es handelt sich hierbei nicht um eine klassische Peer-to-Peer-Ende-zu-Ende-Verschlüsselung (E2EE), da der Server die Nachrichten im Arbeitsspeicher entschlüsseln kann.


Technologiestack

  • Python: Implementierung von Server und Client.
  • RSA-2048 & AES-GCM: Verfahren für den Schlüsselaustausch und die Nachrichtenverschlüsselung.
  • Docker / docker-compose: Ermöglicht die containerisierte Bereitstellung der Anwendung.
  • systemd: Dient dem optionalen Betrieb als Linux-Dienst.

Features

  • Multi-Room-Funktionalität: Unterstützung mehrerer, isolierter Chat-Räume über den /join-Befehl.
  • Authentifizierung: Token-basierte Zugangskontrolle über die Umgebungsvariable CMDCHAT_TOKENS.
  • Transportverschlüsselung: Optionale Aktivierung von TLS für eine gesicherte Verbindung (WSS/HTTPS).
  • Dateiübertragung: Segmentierte Übertragung von Dateien bis zu einer Größe von 10 MB.
  • Flexible Ausgabe: Verschiedene Renderer für die Darstellung der Nachrichten (rich, minimal, json).
  • Lokale Protokollierung: Optionale, clientseitig verschlüsselte Speicherung der Chat-Historie.
  • Stabilität: Integriertes Rate Limiting, Heartbeats zur Verbindungserhaltung und automatische Wiederverbindungsversuche.

Screenshots und Funktionsweise

Übersicht der verbundenen Clients

Alle Clients

Einzelansicht der Clients

Client "Aland"

Client "Tolas"

Funktionsweise: Alle abgebildeten Clients sind gleichzeitig mit demselben CMD-Chat-Server verbunden. Nach einer erfolgreichen Authentifizierung mittels Token durchläuft jeder Client folgende Schritte:

  1. Der Client tauscht seinen öffentlichen RSA-Schlüssel mit dem Server aus.
  2. Der Server generiert einen individuellen AES-Session-Key und übermittelt ihn verschlüsselt an den Client.
  3. Alle nachfolgenden Nachrichten werden mit diesem Sitzungsschlüssel ver- und entschlüsselt.
  4. Ein Client empfängt nur Nachrichten aus dem Raum, dem er beigetreten ist.

Auf diese Weise wird eine logische Kommunikation zwischen den Konsolen-Instanzen realisiert, obwohl diese in getrennten Prozessen und Terminals ausgeführt werden.


Betrieb der Anwendung

Schnellstart

code
git clone https://github.com/amariwan/cmd-chat.git
cd cmd-chat
python -m venv .venv
source .venv/bin/activate
pip install -e .

# Server starten
cmdchat-server

# Client verbinden
cmdchat-client --name alice

Docker

code
docker build -t cmdchat .
docker run -d \
  --name cmdchat-server \
  -p 5050:5050 \
  -e CMDCHAT_TOKENS="your-secret-token" \
  cmdchat

systemd

Eine vorkonfigurierte systemd-Unit (cmdchat-server.service) ist im Repository enthalten und ermöglicht eine unkomplizierte Installation für den Produktivbetrieb unter Linux.


Sicherheitshinweise

  • Aktivieren Sie TLS in allen Produktionsumgebungen.
  • Verwenden Sie Tokens mit hoher Entropie. Ein sicheres Token kann wie folgt generiert werden:
    code
    openssl rand -hex 32
    
  • Die maximale Dateigröße für Übertragungen ist bewusst auf 10 MB beschränkt, um die Serverlast zu begrenzen.

Projektstruktur

code
cmd-chat/
├── cmdchat/
│   ├── server.py
│   ├── client.py
│   ├── crypto.py
│   └── protocol.py
├── Dockerfile
├── docker-compose.yml
├── SYSTEMD_INSTALL.md
└── README.md

Anwendungsfälle

  • Ephemere Kommunikation in vertrauenswürdigen Netzwerkumgebungen.
  • Schnelle und sichere Abstimmungen ohne persistente Chat-Historie.
  • Temporäres Debugging und Austausch von Konfigurationsdateien oder Log-Ausschnitten.

Repository: https://github.com/amariwan/cmd-chat

01

architecture

Drei-Kern-Schichten: Client (Terminal-UI + asyncio), Server (Verbindungs-Multiplexing, Raum-Isolation, Token-Gating, Rate-Limiting) und eine Krypto-Schicht (RSA-2048-Handshake, AES-GCM-Session-Keys). Ein optionaler TLS-Gateway transportiert WSS. Nachrichten existieren ausschließlich als entschlüsselter Zustand im Prozessspeicher.

[ CMD Chat — session cryptography ]5 nodes · click to inspect

select a node to inspect responsibility, I/O, failure modes & security

02

problem

Verschlüsselte, kurzlebige Team-Kommunikation ohne dauerhafte Speicherung — Chat-Verläufe dürfen nach Sitzungsende nicht rekonstruierbar sein.

03

context

Vertrauliche Abstimmungen und Debugging-Sessions verlangen einen Chat, der keine Beweise hinterlässt. Klassische Messenger persistieren Nachrichten oder sind nicht verschlüsselt. Ziel war eine reine Konsolenlösung, die ausschließlich im RAM lebt.

04

requirements

  • Ende-zu-Ende-verschlüsselte Nachrichten pro Session (kein Klartext am Server)
  • Keine Persistenz von Nachrichten auf der Festplatte
  • Tokenbasierte Authentifizierung für den Zugriff auf Räume
  • Optional TLS-Transport für Produktionsbetrieb
  • Bereitstellung als Container oder Linux-Service
05

constraints

  • Keine externen SaaS-Abhängigkeiten — nur Python-Standardbibliothek + cryptography
  • Bewusst keine Datenbank; Zustand lebt im RAM
  • Single-Server-Modell, keine horizontale Skalierung in v1
07

key decisions

AES-GCM über ChaCha20
Hardware-Beschleunigung (AES-NI) auf Zielservern, kombinierte Authenticity + Confidentiality im selben Pass, Misuse-Resistenz durch zufällige Nonces.
RSA-2048-Handshake für Session-Keys
Etablierter, gut audierter Schlüsselaustausch für kleine Client-Zahlen; erlaubt server-seitige Schlüssel-Derivation ohne PSK-Verteilung.
RAM-only Zustand, kein Datenbank-Layer
Security-Requirement 'keine Spuren' dominiert; Persistenz wäre ein Beweismittel-Risiko.
08

alternatives considered

SQLite-Persistenz mit Verschlüsselung
[ rejected ]
Einfacher, ermöglicht Verlaufswiederherstellung.
why not: Verstößt gegen das Nicht-Persistenz-Prinzip; Angriffsfläche für Beweismittel.
E2EE per Signal-Protokoll
[ rejected ]
Maximale Sicherheit gegen Server-Kompromittierung.
why not: Implementierungsaufwand in Python ohne Solana/Matrix-Stacks zu hoch für den Anwendungsfall; Server-Entschlüsselbarkeit im RAM war akzeptiert.
09

trade-offs

  • Komfort vs. Sicherheit: kein Verlauf nach Neustart (gewollt) — kollidiert mit UX-Erwartung von Chat
  • Single-Server-Architektur vereinfacht Betrieb, begrenzt Skalierung auf einen Knoten
  • RAM-only erhöht Memory-Footprint pro Room, eliminiert aber Persistenz-Risiken
10

security

  • Nachrichten leben nur im RAM und werden nie auf die Festplatte geschrieben
  • Token-Gating über CMDCHAT_TOKENS; Rate-Limiting pro Verbindung gegen Brute-Force
  • Optionale WSS/TLS-Termination für Produktion; Client-seitiges Logging abwählbar
  • Session-Keys pro Sitzung ephemer; kein Schlüsselmaterial in Logs
11

reliability

  • Heartbeat + Reconnect-Logik im Client gegen Server-Neustarts
  • Container-Restart-Policy + systemd-Units sichern Selbstheilung
  • Slow-Loris-Schutz durch begrenzte Reader-Puffer
12

testing

  • Manuelle Round-Trip-Tests: Handshake, Verschlüsselung, Token-Reject, Room-Isolation
  • Fail-Tests: Server-Neustart, Token-Expiry, TLS-Pfad
13

deployment

  • Docker-Image + docker-compose für Container-Betrieb
  • systemd-Unit für Bare-Metal; Ports skaliert auf TLS-Gateway
14

observability

  • Structured Logs für Verbindungsaufbau und Auth-Events (keine Inhalte)
  • Metriken: offene Verbindungen, Rooms, Rate-Limit-Hits
15

results

  • Verschlüsselter Chat mit Null-Persistenz und Token-Auth in unter 5 min deploybar
  • Architektur-Referenz für spätere Security-Projekte (SSH-Hack, Orion)
16

lessons

  • Security-Requirement 'nichts speichern' muss früh die Datenmodell-Entscheidung treiben
  • RAM-only klingt einfach, erfordert aber Disziplin bei Logging und Fehlerpfaden