Krypteringsnycklar
Var finns dekrypteringsnyckeln?
Varför Collogue använder ett separat angivet lösenord i stället för att lägga nyckeln i URL:en.
Publicerad: 28 februari 2026
Gränser för den aktuella implementationen
Den aktuella klienten krypterar texten i webbläsaren och bär det krypterade innehållet i URL:en. Webbläsaren använder Web Crypto API: PBKDF2-SHA-256 med 310 000 iterationer härleder en 256-bitars AES-GCM-nyckel från det separat angivna lösenordet, med ett slumpmässigt salt på 16 byte och ett IV på 12 byte. Den aktuella klienten skickar ingen API-begäran till applikationen för att skapa, hämta eller lagra meddelanden.
Lösenordet är inte kodat i länken. Implementation ger inte engångsvisning, radering på serversidan eller någon utgångstimer. Behandla hela länken som känslig och skicka lösenordet genom en separat kanal.
Mer sammanhang
Kryptering ersätter ett svårt problem med ett annat.
Nycklar är små. Konsekvenserna är det inte.
En symmetrisk krypteringsnyckel låter mottagarens webbläsare omvandla autentiserad chiffertext tillbaka till klartext.
``text https://collogue.net/m/example-message#example-key-material ``
Använd bara exemplet om det stämmer med den faktiska arkitekturen.
Fragmentet är delen av en URL efter #.
``text https://example.test/message/123#key-material ``
``text /message/123 ``
Webbläsaren behåller #key-material lokalt och gör det tillgängligt för den laddade sidan.
Men tre varningar är viktiga.
För det första kan JavaScript som laddas av sidan läsa fragmentet. Dekryptering i webbläsaren kräver detta eller en motsvarande mekanism.
För det andra är hela länken nu en åtkomstbefogenhet. Den som får tag på den kan få både chiffertextreferensen och nyckeln.
För det tredje kan fragment fortfarande läcka genom mänskligt beteende, skärmbilder, kopierad text, webbläsartillägg, urklippshistorik, synkroniseringsverktyg eller ändrad klientkod.
Ett fragment är en användbar protokollgräns. Det är inget kraftfält.
- åtkomstloggar;
- loggar från omvänd proxy;
- webbläsarhistorik;
- kopierad diagnostik;
- hänvisningsdata, beroende på policy och navigering;
- övervakningssystem.
I så fall måste den publika artikeln förklara den verkliga exponeringen i stället för att beskriva fragmentets beteende.
En minnesvärd lösenfras och en likformigt slumpmässig nyckel är inte utbytbara. Härledningsparametrar spelar roll.
Användare antar ibland att en krypterad länk är säker att publicera eftersom den ”bara innehåller krypterad data”.
Den slutsatsen är fel när länken också ger möjlighet att dekryptera.
- offentliga ärendehanterare;
- delade kanaler med onödiga medlemmar;
- URL-analystjänster;
- offentliga länksförkortare;
- dokument med bred åtkomst.
Innehav av länken kan visa att någon har länken. Det fastställer inte nödvändigtvis identiteten.
Om en angripare får URL:en före den avsedda mottagaren kan kryptografin fungera perfekt för angriparen.
Detta är den återkommande lärdomen med bärar-befogenheter: auktorisering representeras av innehav.
För hemligheter med högre risk ska du verifiera mottagaren och överväga en separat kanal för sammanhang eller ytterligare autentisering. Beskriv inte separata kanaler som automatiskt säkra; de ändrar bara angriparens krav.
- att avsändaren delar fel länk;
- att mottagaren vidarebefordrar den;
- att skadlig kod i webbläsaren läser fragmentet;
- att ett skadligt skript på sidan fångar klartext;
- att urklippshistoriken behåller URL:en;
- att en länkskanner begär sidan;
- att mottagaren sparar det dekrypterade meddelandet.
Det kan vara en användbar design eftersom fragmentet normalt inte skickas i HTTP-begäranden. Säkerheten beror fortfarande på den levererade sidan, webbläsarmiljön, länkhanteringen och mottagarens beteende.
Ja. JavaScript som körs på sidan kan komma åt fragmentet. Det är vanligtvis så som klientbaserad dekryptering får sitt nyckelmaterial.
Om Collogue inte behåller eller härleder nyckeln kan meddelandet bli omöjligt att återställa om nödvändigt länkmaterial går förlorat. Bekräfta implementationen innan du publicerar det påståendet.
Skapa en privat Collogue-länk när du behöver skicka ett lösenord, en token, en återställningskod eller en annan kort känslig text.