Verifiera säkerheten själv!

Så fungerar krypteringen

Delare använder AES-256-GCM via webbläsarens inbyggda Web Crypto API. Det betyder att själva krypteringen inte är en egen kryptografisk implementation i JavaScript, utan utförs av standardiserade kryptografiska funktioner som finns inbyggda i moderna webbläsare.

För varje ny klientkrypterad delning skapas en ny slumpmässig 256-bitars nyckel – 32 byte – direkt i webbläsaren med crypto.getRandomValues(). Nyckeln genereras alltså på användarens enhet och behöver aldrig hämtas från Delare.

AES-256-GCM: kryptering och manipulationsskydd

AES-GCM är en så kallad authenticated encryption-metod. Förutom att göra innehållet oläsbart utan rätt nyckel skapas även en autentiseringstagg som gör att webbläsaren kan upptäcka om den krypterade datan har ändrats.

Delare använder en 96-bitars IV (initialization vector), som genereras på nytt med kryptografiskt säkra slumpvärden vid varje kryptering. 96 bitar är den IV-längd som rekommenderas för AES-GCM. Eftersom Delare inte anger någon egen tagLength använder Web Crypto standardvärdet 128 bitar för autentiseringstaggen.

Resultatet från Web Crypto består därför inte bara av krypterad text. Ciphertexten innehåller även den autentiseringstagg som används vid dekrypteringen för att kontrollera datans integritet. Om nyckeln är fel, IV:n är fel eller ciphertexten har förändrats misslyckas dekrypteringen i stället för att manipulerat innehåll visas.

Vad krypteras?

Vid en privat krypterad textdelning samlar Delare titel, text och eventuell formaterad text i en payload som krypteras i webbläsaren. För privata ritningar krypteras även den sanerade SVG-datan.

Först efter krypteringen skickas formuläret till servern. Klartextfälten töms innan överföringen och servern har dessutom en egen kontroll som avvisar en klientkrypterad delning om titel, text, HTML eller SVG ändå skulle skickas i klartext.

Servern får i stället bland annat:

• Base64URL-kodad AES-GCM-ciphertext
• en Base64URL-kodad 96-bitars IV
• krypteringsversionen
• typen av krypterat innehåll
• vanlig metadata som delningstyp och giltighetstid

Krypteringsnyckeln finns inte med.

Nyckeln färdas i länken – men inte till servern

Den 256-bitars rånyckel som skapas i webbläsaren kodas som Base64URL utan padding. Det ger en 43 tecken lång nyckel som placeras efter # i delningslänken:

https://delare.se/s/exempel#KRYpTERINGSNYCKEL...

Delen efter # kallas URL-fragment. Till skillnad från sökvägen och query-parametrar skickas fragmentet inte till webbservern när webbläsaren hämtar sidan. Det behandlas lokalt av webbläsaren.

Servern kan därför ta emot en begäran om den krypterade delningen och skicka tillbaka ciphertexten utan att få krypteringsnyckeln genom själva HTTP-begäran.

Så dekrypteras innehållet hos mottagaren

När mottagaren öppnar länken hämtar webbläsaren först det krypterade innehållet från Delare. Därefter läser klientkoden nyckeln från window.location.hash.

De 43 Base64URL-tecknen avkodas tillbaka till den ursprungliga 256-bitarsnyckeln och importeras i Web Crypto som en AES-GCM-nyckel. Det importerade CryptoKey-objektet markeras som icke exporterbart.

Webbläsaren använder sedan nyckeln, ciphertexten och IV:n för att dekryptera payloaden lokalt. Först efter en lyckad AES-GCM-kontroll återskapas titel och innehåll och visas på sidan.

Varför är delen efter # inte hela säkerheten?

JavaScript som körs i en webbsida kan läsa URL-fragmentet. En webbapplikation skulle därför tekniskt kunna läsa nyckeln och själv skicka den vidare i ett nytt nätverksanrop.

Därför nöjer vi oss inte med att konstatera att webbläsaren inte skickar fragmentet automatiskt. Delare Crypto Verify observerar den faktiska nätverkstrafiken och kontrollerar att Delare-koden inte skickar krypteringsnyckeln eller testets klartext vidare.

Hur stark är krypteringen?

En slumpmässig AES-256-nyckel har 2²⁵⁶ möjliga värden. Att försöka hitta en korrekt genererad nyckel genom att systematiskt prova alla alternativ är inte en realistisk angreppsväg med dagens teknik.

I praktiken ligger därför de viktigare riskerna runt krypteringen: exempelvis att någon får tillgång till hela delningslänken, att avsändarens eller mottagarens enhet är komprometterad eller att klientkoden förändras. Därför behandlas hela länken till en krypterad delning som en hemlighet, och därför finns vårt separata verifieringsverktyg för den kod som faktiskt körs.

Ingen tredjepart behöver se innehållet

På de granskade sidorna för att skapa och läsa dessa delningar laddas Delare:s egna JavaScript-filer från samma domän. Vi har inte tredjeparts-analytics, externa JavaScript-CDN:er eller klientbaserad felrapportering i detta flöde som skickar titel, klartext, dekrypterat innehåll eller URL-fragment vidare.

Ett utkast kan före en lyckad delning tillfälligt finnas i sessionStorage i den aktuella webbläsarfliken så att texten kan återställas vid exempelvis ett formulärfel. Det är lokal webbläsarlagring och skickas inte till Delare som en del av krypteringsflödet. Utkastet rensas efter en lyckad delning.

Fördjupning: Web Crypto API hos MDN, kryptografiska slumpvärden, URL-fragment, NIST SP 800-38D om AES-GCM och W3C Web Cryptography Level 2.