Hokono startet — was es schützt, was nicht, und warum wir das offen sagen

Ein ehrlicher Start. Kein Marketing-Text.

Wir starten Hokono: verschlüsselte Sprachanrufe und flüchtige Nachrichten, die auch künftige Quantencomputer nicht rückwirkend knacken sollen — und deren Gesprächswege durch ein mehrstufiges Mixnet geschützt werden. Ohne Telefonnummer, ohne Konto, ohne Server-Logs.

Wir wissen, wie dieser Satz klingt: wie hundert andere „sichere Messenger", die es nicht gehalten haben. Deshalb fangen wir nicht mit dem an, was Hokono kann, sondern mit dem, was es nicht kann — und mit der Bitte, uns die Löcher zu zeigen, die wir übersehen haben.

Wogegen Hokono gedacht ist

Zwei konkrete Bedrohungen:

„Jetzt abgreifen, später entschlüsseln." Verschlüsselter Verkehr wird heute massenhaft gespeichert, um ihn zu knacken, sobald Quantencomputer es können. Klassische Verfahren (RSA, elliptische Kurven) sind dagegen langfristig nicht sicher.
Metadaten. Wer mit wem, wann, wie oft — das verrät oft mehr als der Inhalt. Ende-zu-Ende-Verschlüsselung allein schützt das nicht.

Hokono adressiert beides: Post-Quanten-Kryptografie für den Inhalt, ein Mixnet gegen die Verkehrsanalyse.

Wie es funktioniert — und warum wir keine eigene Kryptografie erfunden haben

Der berechtigte Reflex bei jedem neuen Krypto-Produkt lautet „don't roll your own crypto". Wir haben es nicht getan. Hokono setzt ausschließlich auf etablierte, peer-reviewte Bausteine:

Schlüsselaustausch (PQXDH, hybrid): X25519 + ML-KEM-768 (NIST FIPS 203). Hybrid heißt: selbst wenn eines der beiden Verfahren fällt, hält das andere.
Signaturen: Ed25519 + ML-DSA-65 (NIST FIPS 204).
Sitzungsschlüssel: der Double Ratchet (das Verfahren aus dem Signal-Protokoll).
Verkehrsschutz: Sphinx-Onion-Routing (konstante 4096-Byte-Pakete) mit Loopix-Cover-Traffic — beides aus der akademischen Literatur, nicht selbst ausgedacht.
Die Post-Quanten-Primitive kommen aus OpenSSL (≥ 3.5), nicht aus eigenem Krypto-Code.

Neu ist nicht die Kryptografie, sondern die Komposition: PQ-Ende-zu-Ende + Mixnet + push-basiertes Wecken ohne Telefonnummer. Genau diese Komposition gehört geprüft — dazu unten mehr.

Was Hokono heute nicht kann

Der wichtigste Abschnitt. Wer diese Punkte gegen uns verwendet, sagt nur, was hier schon steht.

Ein Betreiber, kein verteiltes Vertrauen (noch). Die Eintritts-Relays, das Gateway und der Push-Dienst laufen derzeit im selben Konto von uns. Das heißt: Der reale Anonymitäts-Gewinn gegenüber diesem Betreiber ist begrenzt — technisch könnte, wer alle Knoten kontrolliert, mehr korrelieren, als das Mixnet-Modell verspricht. Der volle Nutzen entsteht erst, wenn unabhängige Dritte in getrennten Jurisdiktionen Knoten betreiben. Das ist Roadmap, nicht Ist-Zustand. Wir vermarkten es nicht als „schon anonym".
Der Weck-Anruf ist auf iOS sichtbar. Damit dein iPhone zuverlässig klingelt, geht ein Apple-Push (APNs) an das Gerät. Apple und unser Push-Dienst sehen dabei: dass dein Gerät zu einem Zeitpunkt gerufen wird — nicht von wem (der Auslöser läuft anonym durchs Mixnet) und nie den Inhalt. Wer auch das vermeiden will, nutzt den Hochsicherheitsmodus (kein APNs — dafür muss die App laufen). Vollständige Metadaten-Anonymität beim Wecken kommt erst mit Android/GrapheneOS.
Noch kein externes Audit. Der Code ist quelloffen und intern reviewt, aber noch nicht unabhängig auditiert. Ein externes Krypto-/Infrastruktur-Audit ist geplant — bis dahin: nicht für lebenskritische Bedrohungsmodelle verlassen.
Beta, kleines Team. Hokono ist jung. Es wird Fehler geben. Die Frage ist nicht ob, sondern wie schnell und offen wir sie beheben.
Anonymitäts-Set = klein. Solange wir die Knoten selbst betreiben, ist die Menge derer, in der man „untertaucht", klein. Anonymität ist eine Eigenschaft der Menge, nicht nur des Codes.

Offen und prüfbar

Quelloffen (Server AGPL-3.0, App GPL-3.0) — nichts musst du uns glauben, du kannst es lesen.
Ziel: reproduzierbare Builds, damit das ausgelieferte Binary nachweisbar dem Quellcode entspricht.
Keine Logs in der Produktion (nachweisbar leere Journale) — kein Inhalt, keine IPs, keine Verbindungsdaten auf unseren Servern.
Sicherheitslücken bitte an uns, bevor an die Öffentlichkeit: Meldeweg unter /security. Responsible Disclosure wird belohnt mit schneller, sichtbarer Behebung und Nennung (auf Wunsch).

Ausdrückliche Einladung: Zerlegt Hokono. Lest das Bedrohungsmodell, prüft die Primitive, sucht die Metadaten-Lecks. Sagt uns, wo wir uns irren — wir räumen berechtigte Punkte öffentlich ein und beheben sie sichtbar. Konstruktive Kritik ist kein Angriff, sondern genau das, was ein Sicherheits-Tool vor dem Vertrauen verdient.

Was als Nächstes kommt

Unabhängige Betreiber für Eintritts-Relays und Directory (getrennte Jurisdiktionen) — der eigentliche Metadaten-Schutz.
Externes Audit (Krypto-Kern zuerst, dann Infrastruktur).
Android/GrapheneOS — für Weck-Anonymität ohne Apple im Weg.

Erwartung

Hokono ist kein fertiges Versprechen von Unangreifbarkeit. Es ist ein ehrlicher, quelloffener Versuch, post-quanten-sichere und metadaten-arme Kommunikation zu bauen — mit klar benannten Grenzen und dem Willen, sie öffentlich abzubauen. Wenn du auf Basis deines Bedrohungsmodells entscheidest, es zu nutzen oder zu prüfen: willkommen. Wenn du erst zerlegen willst: erst recht.

— Das Hokono-Team