Versleuteling
Hoe Collogue een privébericht versleutelt
Een beknopte uitleg van de geverifieerde versleutelingsstroom in de browser die Collogue gebruikt.
Gepubliceerd: 17 februari 2026
Grenzen van de huidige implementatie
Huidige Collogue-links bevatten de versleutelde inhoud in de URL. De browser gebruikt de Web Crypto API: PBKDF2-SHA-256 met 310.000 iteraties leidt uit het afzonderlijk ingevoerde wachtwoord een 256-bits AES-GCM-sleutel af, met een willekeurige salt van 16 bytes en een IV van 12 bytes. De huidige client doet geen verzoek naar een applicatie-API om berichten te maken, op te halen of op te slaan.
Het wachtwoord is niet in de link opgenomen. De implementatie biedt geen eenmalige weergave, verwijdering aan de serverkant of vervaltimer. Behandel de volledige link als gevoelig en deel het wachtwoord via een apart kanaal.
Verdere context
Het idee is eenvoudig. De correcte uitvoering is waar de interessante problemen beginnen.
Een bericht begint als leesbare tekst in de browser van de afzender.
- de gebruiker;
- de browser;
- scripts van de pagina;
- browserextensies met voldoende toegang;
- malware op het apparaat;
- systemen voor toegankelijkheid en invoer.
Dit is geen probleem dat uniek is voor Collogue. Een geheim moet ergens in leesbare vorm bestaan voordat het kan worden versleuteld.
Een cryptografische sleutel moet uit een cryptografisch veilige bron of een gedocumenteerd afleidingsproces komen. Menselijk ogende willekeur is niet genoeg. Een tijdstempel met decoratieve leestekens blijft een tijdstempel.
Als er een wachtwoordzin wordt gebruikt, moet de implementatie een geschikte sleutelafleidingsfunctie en parameters gebruiken. Als er een willekeurige sleutel wordt gemaakt, moeten de lengte en de bron van de generatie worden gedocumenteerd.
- Vertrouwelijkheid — de cijfertekst onthult zonder de sleutel niets over de platte tekst.
- Integriteit — ongeoorloofde wijzigingen worden tijdens het ontsleutelen gedetecteerd.
De publieke pagina moet de exacte constructie pas noemen nadat de code is gecontroleerd. “AES” alleen is geen volledige beschrijving. Modi, nonces, authenticatietags, sleutellengtes, codering en foutafhandeling zijn belangrijk.
Cryptografische API’s leveren berucht genoeg scherpe gereedschappen met professioneel gemaakte handvatten. Correct gebruik hoort bij het ontwerp.
De verwachte veilige vorm is, als de echte code dit ondersteunt, een verzoek met cijfertekst en operationele instellingen in plaats van leesbare berichttekst.
Controleer het netwerkpaneel van de browser. Leid deze eigenschap niet af uit tekst in de interface.
Deze waarden zijn niet automatisch geheim. Sommige zijn nodig voor ontsleuteling en kunnen veilig met de cijfertekst meegaan. De sleutel is het belangrijke onderscheid.
Een veilige link is niet automatisch onschuldige metadata. Als iemand met de volledige link kan ontsleutelen, is de link een bearer-capability: wie hem bezit kan het bericht mogelijk openen.
Behandel de link daarom gedurende zijn korte levensduur ongeveer even zorgvuldig als het geheim.
Dit detail is belangrijk omdat geautomatiseerde systemen links kunnen opvragen. Een gewone GET-aanvraag kan gemakkelijker door een voorbeeldbot worden geactiveerd dan een expliciete menselijke handeling, hoewel geen enkel mechanisme perfect bewijst dat er een mens achter zit.
De browser van de ontvanger ontvangt de cijfertekst en het benodigde sleutelmateriaal en voert vervolgens geauthenticeerde ontsleuteling uit.
Als de authenticatie mislukt, moet de toepassing melden dat het bericht niet kon worden geverifieerd of ontsleuteld. Ze mag beschadigde tekst niet tonen alsof er niets is gebeurd.
Geslaagde ontsleuteling maakt platte tekst aan in de browser van de ontvanger. Vanaf dat moment kan cryptografie niet voorkomen dat kopiëren, schermafbeeldingen, foto’s of een geïnfecteerd apparaat het bericht vastleggen.
De versleuteling beschermt een traject. Ze kan het toekomstige gedrag van de ontvanger niet bepalen.
Een goede privacy-pagina benoemt die grens in plaats van haar te vervangen door “voor altijd verdwenen”.
De juiste conclusie is geen pessimisme maar specificiteit.
Collogue moet een beperkte belofte doen, die met waarneembaar gedrag ondersteunen en de aannames uitleggen. Dat is nuttiger dan een groot slotpictogram naast een korte alinea zetten.
Nee. Veilige sleutelgeneratie, geauthenticeerde versleuteling, unieke nonces waar nodig, correcte codering, integriteitscontroles en veilige foutafhandeling maken allemaal deel uit van het protocol.
Omdat ontsleuteling leesbare tekst op het apparaat van de ontvanger moet maken. Cryptografie kan de toegang daarvoor controleren, niet het gedrag van de ontvanger daarna.
Maak een privélink van Collogue wanneer u een wachtwoord, token, herstelcode of andere korte gevoelige waarde moet versturen.