Eind-tot-eindversleuteling met Signal Protocol en overal AES-256
Sanket (Sanket.Chat) van Tosh Defence versleutelt elk bericht, elke reactie en elk versleuteld groepsbericht van afzender tot ontvanger met Signal Protocol, via de officiële, onafhankelijk gecontroleerde libsignal van Signal. Daarbij gebruikt het PQXDH voor sleuteluitwisseling en Double Ratchet met SPQR. Bestanden, gespreksbeelden, de overdracht van gesprekken, lokale opslag en elke TLS-verbinding die door de installatie wordt beëindigd, gebruiken AES-256, zonder terugval op AES-128 en zonder compatibiliteitsmodus.
AES-256 of geen versleuteling is het in de programmacode afgedwongen ontwikkelbeleid van Sanket. Als versleuteling niet precies volgens het ontwerp kan worden uitgevoerd, wordt de bewerking geweigerd in plaats van de beveiliging te verzwakken.
Berichten: het Signal Protocol, ongewijzigd
SANKET gebruikt de officiële libsignal-bibliotheek van Signal voor de versleuteling van alle berichten, in dezelfde versie op iOS, Android, computers en de server. Het bevat geen eigen herimplementatie van Signal Protocol en geen alternatief versleutelingsalgoritme voor berichten.
Sessies worden tot stand gebracht met PQXDH, de postkwantumuitbreiding van X3DH, die X25519-sleuteluitwisselingen combineert met een Kyber-sleutelinkapseling. Berichten worden vervolgens versleuteld met de Double Ratchet: elke berichtsleutel wordt uitgebreid tot een AES-256-sleutel, een HMAC-SHA256-sleutel en een initialisatievector. Het bericht wordt versleuteld met AES-256 en geauthenticeerd met HMAC-SHA256, waarna de sleutel na gebruik wordt verwijderd. De schaarse postkwantumratel van Signal draait daarnaast voor elke sessie.
Bewust geen terugvalmogelijkheid
Een client weigert een bericht te verzenden als versleuteling met libsignal niet mogelijk is. Apparaten die geen libsignal-identiteitssleutel publiceren, worden overgeslagen in plaats van dat het bericht als platte tekst wordt verzonden. Verouderde markeringen voor platte tekst worden geweigerd en de server weigert sleutelbundels die niet voldoen aan het libsignal-formaat. Voor berichtinhoud is er geen route via platte tekst of een alternatief versleutelingsalgoritme.
Groepen zonder gedeelde sleutel
Groepsberichten worden versleuteld via paarsgewijze distributie: het verzendende apparaat versleutelt het bericht afzonderlijk voor elk vertrouwd apparaat van elk groepslid, telkens via een eigen libsignal-sessie. Bij wijzigingen in het groepslidmaatschap hoeven de sleutels niet te worden vernieuwd; een verwijderd lid staat simpelweg niet meer op de distributielijst.
Voordat een afzender versleutelt, controleert deze voor elk ontvangersaccount de apparatenlijst die met de eigen sleutel van dat account is ondertekend, en verzendt niets naar een apparaat dat niet op die lijst staat.
Bestanden en gesprekken
De inhoud, namen en typen van bijlagen worden op het apparaat versleuteld met AES-256-GCM, met voor elk bestand een willekeurig gegenereerde sleutel van 256 bits. Die sleutel wordt in het libsignal-bericht meegestuurd.
Spraak en video zijn dubbel beveiligd. De frames van elke deelnemer worden end-to-end versleuteld met AES-256-GCM, met een sleutel per verzender die elke 200 milliseconden wordt vernieuwd. Dat levert voor elke verzender vijf nieuwe framesleutels per seconde op, met een nieuwe willekeurige sleutel telkens wanneer iemand deelneemt of vertrekt. Tussen elk apparaat en de mediaserver accepteert SRTP uitsluitend AEAD_AES_256_GCM. De mediaserver stuurt versleutelde frames door die hij niet kan ontsleutelen. Het ontwerp sluit opname van gesprekken op de server uit.
- AES-256-GCM per bestand
- Gespreksleutels per afzender, nooit één gedeelde sleutel voor de hele gespreksruimte
- Vijf framesleutels per seconde per afzender
- Alleen SRTP met AES-256-GCM
Transport en opslag
Elke clientverbinding gebruikt TLS 1.3 met TLS_AES_256_GCM_SHA384, of TLS 1.2 met ECDHE en AES-256-GCM voor netwerkstacks van platforms die dit vereisen. AES-128, ChaCha20, versleutelingscombinaties met CBC en statische RSA zijn uitgesloten. De hybride groep X25519MLKEM768, die bescherming biedt tegen aanvallen met kwantumcomputers, wordt als eerste aangeboden. Elk goedgekeurd apparaat kan zich via wederzijdse TLS-authenticatie ook met een eigen clientcertificaat identificeren.
Op apparaten zijn lokale databases versleuteld met AES-256 en geauthenticeerd met HMAC-SHA256. Op telefoons zijn de protocolopslag en apparaatgeheimen versleuteld met een door hardware beveiligde sleutel in de Secure Enclave, StrongBox of de vertrouwde uitvoeringsomgeving.
Technische onderbouwing
Lees de details in de whitepaper van SANKET
Elke bewering op deze pagina wordt volledig uiteengezet in het openbare technische witboek over de beveiliging en architectuur van Sanket, dat zonder registratie gratis te lezen is.
Gebruikt SANKET het Signal Protocol?
Ja. Sanket versleutelt alle berichten op elk platform met de officiële libsignal-bibliotheek van Signal, met PQXDH-sleutelovereenkomst en Double Ratchet met SPQR. Het bevat geen eigen herimplementatie van het protocol.
Gebruikt SANKET AES-256 voor versleutelde berichten?
Ja. Berichten gebruiken AES-256-CBC met HMAC-SHA256 binnen libsignal; bestanden, gespreksframes, gesprekstransport, lokale opslag en TLS gebruiken AES-256-GCM. Er is geen terugval op AES-128.
Zijn spraak- en videogesprekken end-to-end versleuteld?
Ja. Beeld- en geluidsframes van gesprekken worden eind-tot-eind versleuteld met AES-256-GCM, met sleutels per afzender die via libsignal worden verstrekt. Per afzender worden 5 nieuwe framesleutels per seconde gebruikt, binnen SRTP dat uitsluitend AES-256-GCM accepteert.
Zijn reacties en berichten aan meerdere ontvangers versleuteld?
Ja. Reacties en versleutelde berichten aan meerdere ontvangers zijn libsignal-berichten en worden, net als alle andere berichten, van begin tot eind versleuteld. Ook de prioriteit, uiterste reactietijd en vervaltijd van zo'n bericht vallen onder de versleuteling.
Gebruikt SANKET afzendersleutels voor groepen?
Nee. SANKET versleutelt groepsberichten afzonderlijk voor elk vertrouwd apparaat van elk groepslid, telkens via een eigen libsignal-sessie, zodat er geen gedeelde groepssleutel is.
Welke TLS-versies accepteert SANKET?
TLS 1.3 heeft de voorkeur, uitsluitend met TLS_AES_256_GCM_SHA384. TLS 1.2 wordt alleen geaccepteerd met ECDHE en AES-256-GCM. Versies lager dan TLS 1.2 worden niet geaccepteerd en de hybride postkwantum-sleuteluitwisseling X25519MLKEM768 wordt als eerste aangeboden.
Is libsignal gecontroleerd?
Ja. SANKET is gebaseerd op de onafhankelijk beveiligingsgecontroleerde libsignal-bibliotheek van Signal, en het PQXDH-protocol is formeel geanalyseerd.
Bespreek de cryptografie van SANKET met onze ingenieurs
Tosh Defence neemt de beveiligingsarchitecten en evaluatiecommissies laag voor laag mee door het cryptografische ontwerp. De gecontroleerd toegankelijke versie van de whitepaper is beschikbaar onder een geheimhoudingsovereenkomst.