Mehrschichtige E2EE-Architektur
Signal Protocol als Grundlage, erweitert mit Post-Quanten-Kryptografie, AEGIS-Signaturen und clientseitigem Sealed Sender.
Lies es,oder verliere es.
WORLD'S FIRST KEY-DESTRUCTION E2EE
Empfangen
Schlüssel erzeugt · 24h-Timer gestartet
24 Std. vergangen
Noch ungelesen, 23 Stunden 59 Minuten
Schlüssel zerstört
Mathematisch unmöglich zu entschlüsseln
PQXDH-Schlüsselaustausch
Hybrider Post-Quanten-Schlüsselaustausch, der X25519 (Curve25519) und ML-KEM-1024 (NIST FIPS 203) kombiniert. Resistent gegen klassische und Quantenangriffe.
Double Ratchet
Vorwärtsgeheimnis pro Nachricht mittels DH-Ratchet + symmetrischem Ratchet. Die Kompromittierung eines Schlüssels kann weder vergangene noch zukünftige Nachrichten entschlüsseln.
AES-256-GCM-Verschlüsselung
Authentifizierte Verschlüsselung mit 256-Bit-Schlüsseln. Jede Nachricht wird mit einem einzigartigen Schlüssel verschlüsselt, der vom Double Ratchet abgeleitet wird.
AEGIS (Ed25519-Signaturen)
Digitale Signaturen pro Nachricht für Nichtabstreitbarkeit. 90-Tage-Schlüsselrotation mit Übergangszeitraum-Verifizierung. Geräteliste mit Ed25519 signiert.
Clientseitiger Sealed Sender
Ephemerer X25519-Schlüssel pro Nachricht + HKDF-SHA256-abgeleiteter AES-Schlüssel. Selbst der Server kann nicht sehen, wer eine Nachricht gesendet hat.
Read-or-Lose Verschlüsselung
Lies sie, oder verlier sie.
Nachrichten, die 24 Stunden lang ungelesen bleiben, werden mathematisch nicht mehr entschlüsselbar. Nicht gelöscht — der Entschlüsselungsschlüssel selbst wird vernichtet. Kein Gerichtsbeschluss, keine Server-Vorladung und keine Gerätebeschlagnahme kann den Inhalt rekonstruieren.
So funktioniert es
24-Stunden-Schlüssellebensdauer
Jede Nachricht wird mit einem Entschlüsselungsschlüssel verschlüsselt, der exakt 24 Stunden lebt. Danach wird der Schlüssel kryptografisch vernichtet — auf dem Gerät des Absenders, dem Gerät des Empfängers und auf dem Server.
Lesen vor Ablauf der 24 h
Wenn du die Nachricht innerhalb von 24 Stunden liest, wird der Klartext gemäß deinem IGF-Timer sicher auf deinem Gerät gespeichert (bis zu 52 Wochen in kostenpflichtigen Plänen).
Ungelesen nach 24 h
Wenn du nicht rechtzeitig liest, wird die Nachricht dauerhaft unwiederbringlich. Selbst Atlas Associates kann sie nicht zurückholen.
Lese-getriggertes Re-Keying
Sobald dein Posteingang null ungelesene Nachrichten erreicht, rotiert dein Entschlüsselungsschlüssel sofort — für maximale Forward Secrecy.
Mathematische Garantie
Keine Richtlinie, kein Versprechen — die Mathematik selbst verhindert die Wiederherstellung. Kein Gerichtsbeschluss, keine Server-Vorladung und keine Gerätebeschlagnahme kann den Inhalt rekonstruieren.
Transparenter Ungelesen-Status
Sowohl Absender als auch Empfänger sehen, wann eine Nachricht ungelesen abgelaufen ist. Wie ein Anrufprotokoll für verpasste Anrufe — du weißt, dass es passiert ist, aber der Inhalt ist für immer verloren.
Funktioniert mit IGF
Read-or-Lose schützt die 24 Stunden vor dem Lesen. IGF (bis zu 52 Wochen) schützt den Klartext nach dem Lesen. Zwei unabhängige Ebenen der Privatsphäre.
Kostenlos in jedem Plan
Read-or-Lose ist eine Kernfunktion des Arc Protocol — ohne Aufpreis in den Plänen Essential, Premium und Intelligence enthalten.
Die Verpasster-Anruf-Metapher
Stell dir einen Anruf vor, den du nicht angenommen hast. Das Protokoll bleibt — du weißt, dass jemand angerufen hat. Aber die Stimme? Weg. Arcs ungelesene Nachrichten funktionieren genauso: Du siehst, dass eine Nachricht eingetroffen ist, aber ihr Inhalt ist unwiderruflich verloren.
AEGIS — Arc Enhanced Guard & Integrity System
AEGIS (Arc Enhanced Guard & Integrity System) ist Arcs Nachrichtenauthentifizierungsschicht, die auf digitalen XEdDSA-Signaturen über libsignal basiert. Jede einzelne Nachricht, die Sie senden, wird kryptografisch signiert und bietet drei entscheidende Garantien:
Schutz vor Identitätsfälschung
Selbst wenn ein Angreifer den Server kompromittiert, kann er keine Nachrichten in Ihrem Namen fälschen. Ihr Identity Key (X25519) wird für die XEdDSA-Signierung verwendet und verlässt niemals Ihr Gerät.
Manipulationserkennung
Jede Änderung an einer Nachricht — selbst ein einzelnes Zeichen — macht die Signatur sofort ungültig. Empfänger können überprüfen, dass jede Nachricht genau so angekommen ist, wie sie gesendet wurde.
Nichtabstreitbarkeit
Kryptografischer Beweis, dass Sie eine Nachricht verfasst haben. XEdDSA verwendet Ihren X25519 Identity Key für EdDSA-kompatible Signaturen — kein separater Ed25519-Schlüssel erforderlich.
XEdDSA (libsignal) · X25519 Identity Key · 64-Byte-Signaturen · Signierung pro Nachricht
Im Gegensatz zu Standard-Messaging-Apps geht AEGIS über die Verschlüsselung hinaus. Während E2EE den Nachrichteninhalt schützt, schützt AEGIS die Nachrichtenidentität — und stellt sicher, dass jede Nachricht wirklich von dem stammt, der behauptet wird. Angetrieben durch die XEdDSA-Implementierung von libsignal.
Null-Schlüsselkonvertierung
Arc trennt X25519 (Schlüsselaustausch) und Ed25519 (Signaturen) auf Typebene. Anders als bei Signal/WhatsApp gibt es keine Ed25519→X25519-Schlüsselkonvertierung, was die Angriffsfläche minimiert.
Signal/WhatsApp vs Arc V2
| Funktion | Signal | Telegram | Arc V2 | |
|---|---|---|---|---|
| Schlüsseldesign | Ed→X conversion | Ed→X Konvertierung | MTProto 2.0 (proprietär) | Complete separation |
| Nachrichtensignaturen | None (DH only) | Keine (nur DH) | Nur Geheimer Chat | AEGIS XEdDSA |
| Sealed Sender | Server-side | Server-seitig | Nicht verfügbar | Client-side |
| Offline E2EE | Not supported | Nicht unterstützt | Nicht unterstützt | BLE Mesh X3DH+DR |
| Multi-Gerät | Primary/Linked | Primär/Verknüpft | Alle Geräte (Cloud-Sync) | Independent key sets + Key Sync |
| Schlüsselrotation | Fixed interval | Festes Intervall | Manuell (Geheimer Chat) | Multi-stage automatic |
| Geräteliste | No signature | Keine Signatur | Serververwaltet | Ed25519 signed |
| Geräte-Schlüsselübertragung | Via Primary | Über Primärgerät | Server synchronisiert | QR + X25519 ECDH + AES-256-GCM |
| Background E2EE | Foreground only | Nur Vordergrund | Nur Geheimer Chat | ✓ All App States (FG/BG/Terminated) |
| Verlauf auf neuem Gerät | Nur Medien der letzten 45 Tage | Nur Medien der letzten 45 Tage | Vollständiger Verlauf (Cloud) | Alle Nachrichten innerhalb IGF-Ablauf |
| Telefon verloren / Wiederherstellung | Begrenztes Cloud-Backup (PIN erforderlich) | E2EE-Backup (opt-in) + Drive/iCloud | Cloud-Backup (Server) | Wiederherstellung aus verschlüsseltem Backup |
| Server-Zugriff auf Inhalte | Nein | Nein (Metadaten ja) | Ja (nicht Geheimer Chat) | Nein (mit Benutzerschlüssel verschlüsselt) |
| Nachrichtenverlauf-Wachstum | Wächst unbegrenzt | Wächst unbegrenzt | Unbegrenzt (Cloud) | Automatisch begrenzt durch IGF |
| Gerätehierarchie | Telefon ist Master | Multi-Gerät, kein Telefon erforderlich | Keine Hierarchie | Alle Geräte gleichwertig |
ML-KEM-1024-Parameter
NIST FIPS 203 standardisierter Post-Quanten-Schlüsselkapselungsmechanismus.
| Algorithmus | ML-KEM-1024 (via libsignal-client) |
| NIST-Sicherheitsstufe | Level 3 (AES-192 equivalent) |
| Klassische Sicherheit | 2^128 bit (X25519) |
| Quantensicherheit | NIST Level 3 |
| Grundlage | Module Lattice (FIPS 203) |
| Öffentliche Schlüsselgröße | 1,184 bytes |
| Geheime Schlüsselgröße | 2,400 bytes |
| Chiffretext-Größe | 1,088 bytes |
Compliance & Standards
🇺🇸NIST CSF 2.0
NIST-Framework. 6 Funktionen für systematisches Cyber-Risikomanagement.
🇺🇸NIST SP 800-53
Sicherheitskontrollen für Bundesbehörden. FedRAMP-Grundlage.
🇺🇸FIPS 140-3
Bundesvalidierung kryptographischer Module. Umfasst ML-KEM-1024.
🇺🇸NIST SP 800-175B
Leitfaden zur Auswahl kryptographischer Algorithmen. Basiert auf FIPS 203.
🌐ISO/IEC 27001
Internationale ISMS-Zertifizierung. B2B/B2G-Vertrauensgrundlage.
🇪🇺GDPR
EU-Datenschutz-Grundverordnung. Weltweit höchster Schutzstandard.
🇬🇧UK Cyber Essentials+
UK-staatlich zertifizierte Cybersicherheitszertifizierung.
🇬🇧NCSC Cloud Security
UK NCSC 14 Prinzipien. Cloud-Sicherheitsbewertungsstandard.
Entwickelt in Übereinstimmung mit allen Voraussetzungen von US NIST, EU GDPR, UK NCSC und internationaler ISO.
Arc Protocol: Sicherheits-Whitepaper
Ein umfassendes technisches Dokument, das Arcs kryptografische Architektur, Bedrohungsmodell und Sicherheitsgarantien beschreibt. Behandelt PQXDH-Schlüsselaustausch (ML-KEM-1024), Double Ratchet Forward Secrecy, AEGIS-Nachrichtensignaturen, Sealed Sender und BLE Mesh Offline-E2EE.
15 Abschnitte
Vollständige Protokolldokumentation
Signal-Vergleich
Ehrliche Feature-für-Feature-Analyse
Bedrohungsmodell
STRIDE-Analyse mit Restrisiken
Systemarchitektur-Dokumentation
Vollständige technische Spezifikation von Arc V2 — 5-Schicht-Architektur, E2EE-Pipeline, PQXDH-Implementierung, Schlüssellebenszyklus, Gruppenverschlüsselung, Multi-Geräte-Architektur, BLE-Mesh-Netzwerk und On-Device-KI.
15+ Technische Abschnitte
Schichtarchitektur, PQC-Implementierung, Verschlüsselungspipeline, Datenspeicherung und mehr
Zweisprachig (EN/JP)
Vollständige Dokumentation in Englisch und Japanisch mit Ein-Klick-Umschaltung
Version 3.1 — März 2026
Inkl. Elixir PreKey Server, Sealed Sender, Sender Keys und PQXDH ML-KEM-1024
Dieses Dokument ist vertraulich und ausschließlich für NDA-gebundene Partner, Investoren und autorisierte technische Prüfer zugänglich. Der Zugang erfordert eine vorherige Genehmigung durch Atlas Associates.