Het Asgard-protocol
Hoe het werkt, op volgorde.
Zes stappen, in de volgorde waarin ze echt gebeuren. Elke stap staat er eerst eenvoudig. Het precieze mechanisme staat eronder, om open te klappen of te laten liggen.
Stap 01
Aantonen dat jij het bent
Nog voor al het andere maakt je telefoon twee identiteiten voor je en bewaart ze allebei. Wie controleert of een bericht echt van jou kwam, controleert ze allebei. Er één breken is niet genoeg.
De technische versie
Ed25519 voor de klassieke handtekening en CRYSTALS-Dilithium voor de post-quantum handtekening. De tegenpartij verifieert beide handtekeningen op elke identiteitssleutel, dus een identiteit vervalsen betekent beide schema's breken.
Stap 02
Het eens worden over een geheim
Twee telefoons die elkaar nooit hebben ontmoet moeten het eens worden over een geheim zonder het ooit hardop te zeggen. Ze doen het twee keer, met twee losstaande stukken wiskunde, en mengen de twee uitkomsten. Blijkt er één te breken, dan houdt het geheim alsnog stand.
De technische versie
X25519 voert X3DH uit, daarnaast CRYSTALS-Kyber. De twee gedeelde geheimen worden gecombineerd met HKDF, dus de sessiesleutel is slechts zo zwak als de sterkste van de twee aannames.
Stap 03
Een nieuw slot voor elk bericht
De ratchet leidt nieuwe berichtsleutels af en verwijdert oud sleutelmateriaal bij het doorlopen. Dit beperkt blootstelling van eerdere versleutelde tekst, maar verwijdert geen berichten die al op een apparaat staan.
De technische versie
AES-256-GCM en een Double Ratchet, met X25519 en CRYSTALS-Kyber1024 gecombineerd bij asymmetrische ratchetstappen. Correct wissen van sleutels en nieuwe uitwisselingen zijn vereist voor de beoogde bescherming.
Stap 04
Als iemand weggaat
Wanneer een lid vertrekt, vernieuwen de anderen de sleutels zonder dat lid. Dit beschermt latere berichten in de bijgewerkte toestand, maar trekt eerder ontvangen inhoud niet in.
SpacesDe technische versie
MLS (RFC 9420), met de hybride InTouch-uitbreiding. Hybride groepsbescherming vereist de juiste buildfuncties en clients; controleer uw implementatie.
Stap 05
Bezorgmetagegevens beperken
Sealed sender vermindert afzenderinformatie in de bezorgenvelop. De dienst wordt er niet anoniem door: routering, tijdstippen en volume blijven bestaan, en de relay kent Space-leden en wie berichten plaatst.
De technische versie
Sealed sender vermindert afzenderinformatie in de bezorgenvelop. De dienst wordt er niet anoniem door: routering, tijdstippen en volume blijven bestaan, en de relay kent Space-leden en wie berichten plaatst.
Stap 06
Hoe je ons zou betrappen
Als we je ooit de verkeerde sleutel gaven, zou je een manier nodig hebben om dat te merken. Elke sleutel die we publiceren komt in een log waaraan alleen toegevoegd kan worden, en je telefoon controleert dat de gekregen sleutel er echt in staat voordat het iets verstuurt.
De technische versie
Clients controleren sleutels in ondertekende loggeschiedenissen met inclusie- en consistentiebewijzen. Onafhankelijke waarnemers moeten geschiedenissen vergelijken om afzonderlijke, intern consistente weergaven te ontdekken.
Wat dit niet beschermt
De relay leest geen beschermde inhoud, maar metagegevens blijven bestaan. Agentbeheerders en modelaanbieders kunnen verwerken wat een agent ontvangt. Versleuteling beschermt geen ontgrendelde of gecompromitteerde eindpunten en wist geen ontvangen kopieën. Bekijk Beveiliging voor buildvereisten en beschikbaarheid.
Het geheel, opgeschreven.
Lees de protocolsamenvatting en implementatienotities. Openbare broncodepublicatie en een voltooide onafhankelijke audit staan nog uit.