Das Dokument
Das Protokoll, aufgeschrieben.
Eine Zusammenfassung des Asgard-Protokolls: die vier Schichten, die Primitiven, die jede davon nutzt, und die Standards, aus denen sie stammen. Geschrieben, um geprüft zu werden. Wo etwas spezifiziert und noch nicht gebaut ist, sagt die Seite es.
- Protokoll
- Asgard
- Gruppenerweiterungen
- intouch_hybrid_v1
- Normgrundlage
- CRYSTALS Runde 3 · RFC 9420
- Protokollkomposition
- Hybrides Asgard-Profil
Vier Schichten, und jede davon hybrid
Asgard kombiniert klassische und Post-Quanten-Primitive für Identitäten, Sitzungen, Ratchets und Gruppen. Die Gruppenerweiterung benötigt passende Build-Funktionen. Veröffentlichte Primitive ersetzen keine unabhängige Prüfung ihrer Kombination.
- 01
Identität
Ed25519 + CRYSTALS-Dilithium
Identitätsmaterial kombiniert Ed25519 und CRYSTALS-Dilithium5. Private Signaturschlüssel gehören den Endpunkten der Teilnehmer. Prüfen Sie, welche Signaturkontrollen veröffentlichter Client und Bereitstellung durchsetzen.
- 02
Sitzung
Hybrid X3DH · X25519 + CRYSTALS-Kyber1024 · HKDF
Eine hybride Sitzung kombiniert X25519-Schlüsselaustausche und CRYSTALS-Kyber1024-Kapselung über HKDF. Öffentliche Vorschlüssel ermöglichen den Sitzungsbeginn, während der Empfänger offline ist.
- 03
Nachricht
Double Ratchet · new root = HKDF(DH_ratchet ‖ KEM_ratchet)
AES-256-GCM und ein Double Ratchet, mit X25519 und CRYSTALS-Kyber1024 an asymmetrischen Ratchet-Schritten. Korrekte Schlüssellöschung und neue Austausche sind für den vorgesehenen Schutz erforderlich.
- 04
Gruppen
MLS (RFC 9420) + intouch_hybrid_v1
MLS (RFC 9420) mit der hybriden InTouch-Erweiterung. Hybrider Gruppenschutz benötigt die passenden Build-Funktionen und Clients; prüfen Sie die Konfiguration Ihrer Bereitstellung.
Veröffentlichte Primitive, InTouch-Komposition
Asgard nutzt die unten genannten veröffentlichten Primitive in einer hybriden InTouch-Komposition. Die CRYSTALS-Kodierungen aus Runde 3 unterscheiden sich von den endgültigen ML-KEM- und ML-DSA-Standards. Dies ist keine FIPS-Validierung oder unabhängige Prüfung.
- Symmetrische Verschlüsselung
- AlgorithmusAES-256-GCM
- StandardNIST
- Stärke256 Bit
- Schlüsselaustausch
- AlgorithmusX25519
- StandardRFC 7748
- Stärke~128 Bit klassisch
- Signaturen
- AlgorithmusEd25519
- StandardRFC 8032
- Stärke~128 Bit klassisch
- Post-Quanten-KEM
- AlgorithmusCRYSTALS-Kyber1024
- StandardCRYSTALS Runde 3
- StärkeNIST-Stufe 5
- Post-Quanten-Signaturen
- AlgorithmusCRYSTALS-Dilithium5
- StandardCRYSTALS Runde 3
- StärkeNIST-Stufe 5
- Schlüsselableitung
- AlgorithmusHKDF-SHA-512
- StandardRFC 5869
- Stärke256 Bit
- Gruppenprotokoll
- AlgorithmusMLS
- StandardRFC 9420
- Stärke—
Was der Server hält
Der Relay verarbeitet verschlüsselte Inhalte, öffentliches Prüfmaterial und Betriebsmetadaten, einschließlich Space-Mitgliedern und Absendern. Die Listen unterscheiden diese Daten von geschützten Inhalten und privaten Schlüsseln.
Gehalten
- Kontokennungen und öffentliche Prüfschlüssel
- Verschlüsselte Nachrichten bis zur Zustellung
- Space-Mitglieder und Absender
- Empfängerrouting, Zeitpunkte und Datenvolumen
- Verschlüsselte Schlüsselsicherungen, sofern aktiviert
Außer Reichweite
- Geschützte Nachrichteninhalte
- Verschlüsselte Nachrichtenfelder und Werte
- Private Entschlüsselungsschlüssel der Teilnehmer
Wogegen das nicht schützt
Der Schutz hängt von sicheren Endpunkten, Build-Funktionen und Betriebseinstellungen ab. Befugte Empfänger und Agenten können Inhalte behalten. Metadaten bleiben sichtbar. CRYSTALS-Algorithmen aus Runde 3 verwenden nicht die endgültigen FIPS-Kodierungen von ML-KEM und ML-DSA; keine Zertifizierung oder abgeschlossene unabhängige Prüfung wird behauptet.
Verfügbarkeit der Kontaktsuche
Eine serverseitige Implementierung für verblindete Kontaktsuche wurde im Quellcode bestätigt. Client-Integration und Verfügbarkeit im Betrieb sind nicht verifiziert. Prüfen Sie App-Version und Sicherheitsseite, bevor Sie sich darauf verlassen.
Was Sie heute prüfen können
Lesen Sie die Protokollübersicht, prüfen Sie den Sicherheitsstatus und vergleichen Sie wichtige Identitäten über einen vertrauenswürdigen Kanal.
- 01
Sicherheitsstatus lesen
Implementierungsnachweise, Anforderungen an Bereitstellungen und Schutzmechanismen, deren unabhängige Prüfung noch aussteht.
- 02
Beobachten Sie das Transparenzprotokoll
Clients prüfen Schlüssel anhand signierter Protokollverläufe mit Inklusions- und Konsistenznachweisen. Unabhängige Beobachter müssen Verläufe vergleichen, um getrennte, jeweils intern konsistente Ansichten zu erkennen.
- 03
Vergleichen Sie eine Sicherheitsnummer
Vergleichen Sie Sicherheitsnummern über einen unabhängigen Kanal mit einer Person, deren Identität Sie bereits kennen.
Das ist die Form davon, nicht das Ganze.
Lesen Sie Protokollübersicht und Implementierungshinweise. Die öffentliche Quellcodeveröffentlichung und eine abgeschlossene unabhängige Prüfung stehen noch aus.