Een veilige berichtenapp kiezen: 12 vragen op basis van bewijs

Een berichtenapp kan een slotje tonen, zichzelf privé noemen en toch belangrijke vragen onbeantwoord laten.

Welke gesprekken zijn versleuteld? Zijn bijlagen beschermd? Waar worden de sleutels opgeslagen? Welke informatie bewaart de server? Wat gebeurt er als je een apparaat verliest? Kunnen versleutelingssleutels zonder waarschuwing veranderen?

Deze details helpen je zowel nuttige bescherming als ontbrekend bewijs te herkennen. Geen enkele checklist certificeert op zichzelf dat een product veilig is.

Deze gids geeft je twaalf praktische vragen om te stellen voordat je een versleutelde berichtenapp vertrouwt met persoonlijke gesprekken, vertrouwelijke bestanden of gevoelig werk.

Wat is een veilige berichtenapp?

Een veilige berichtenapp is een communicatiedienst die is ontworpen om gesprekken te beschermen tegen onbevoegde toegang, onderschepping, accountovername en onbedoelde blootstelling van gegevens.

Een serieuze privéberichtenapp moet op zijn minst veilig netwerktransport, sterke accountauthenticatie, zorgvuldige toegangscontroles en duidelijke procedures voor gegevensverwerking gebruiken.

Voor zeer vertrouwelijke gesprekken moet de app ook end-to-endversleuteling bieden.

End-to-endversleuteling, of E2EE, beschermt ondersteunde inhoud door die op het apparaat van de afzender te versleutelen en op het apparaat van een bevoegde ontvanger te ontsleutelen. De dienst kan de versleutelde gegevens afleveren zonder de leesbare berichttekst nodig te hebben.

Versleuteling is echter maar één onderdeel van veilige berichtenuitwisseling.

Een volledige beoordeling moet ook rekening houden met:

• Welke gesprekken versleuteld zijn
• Of foto's en bestanden dezelfde bescherming krijgen
• Waar privésleutels worden opgeslagen
• Hoe contacten sleutels kunnen verifiëren
• Welke metadata zichtbaar blijven
• Hoe account- en sleutelherstel werken
• Wat er gebeurt als een apparaat wordt gecompromitteerd
• Hoe de dienst zijn beperkingen documenteert

Lees voor een uitgebreidere inleiding het artikel over de werking van end-to-endversleuteling.

Waarom het woord ‘versleuteld’ niet genoeg is

Bijna elke moderne berichtendienst versleutelt netwerkverkeer met HTTPS, TLS of een andere beschermde transportmethode.

Die bescherming is belangrijk, maar betekent niet noodzakelijk dat het gesprek end-to-endversleuteld is.

Bij transportversleuteling zijn gegevens beschermd tijdens het transport tussen je apparaat en de dienst. De dienst kan de leesbare inhoud nog steeds ontvangen voordat die via een andere beschermde verbinding wordt doorgestuurd.

Bij E2EE wordt ondersteunde berichtinhoud voor de deelnemers versleuteld voordat die de berichtendienst bereikt.

Dat onderscheid beïnvloedt wie technisch toegang tot de berichttekst kan hebben.

Daarom moet je precieze vragen stellen in plaats van een algemeen label ‘versleuteld’ te accepteren.

Bewering	De vraag die je moet stellen
‘Je chats zijn versleuteld’	Zijn ze alleen tijdens transport versleuteld of end-to-end?
‘Je gegevens zijn veilig’	Welke gegevens, tegen welke dreigingen en hoelang?
‘Wij kunnen je berichten niet lezen’	Geldt dit voor directe chats, groepen, media, oproepen en back-ups?
‘Privacy ingebouwd in het ontwerp’	Welke metadata en operationele informatie blijven beschikbaar?
‘Veilig herstel’	Wie kan de versleutelingssleutels herstellen en welk geheim is nodig?

1. Welke gesprekken zijn end-to-endversleuteld?

Ga er niet van uit dat één uitspraak over versleuteling voor elk onderdeel van een applicatie geldt.

Een berichtendienst kan verschillende bescherming bieden voor:

• Directe een-op-eengesprekken
• Privégroepen
• Openbare groepen
• Uitzendkanalen
• Spraak- en videogesprekken
• Stories of tijdelijke berichten
• Bots en geautomatiseerde accounts
• Gesynchroniseerde gespreksgeschiedenis

Vraag de aanbieder de precieze grens aan te geven.

Een sterk antwoord klinkt zo:

Tekst en media in directe berichten worden op de apparaten van deelnemers versleuteld. Compatibele privégroepen zijn end-to-endversleuteld met LGS1, met automatische rotatie van afzendersleutels bij wijzigingen in het lidmaatschap. Kanalen gebruiken een aparte, voor de server leesbare architectuur en worden niet als E2EE beschreven.

Een zwak antwoord klinkt zo:

Je communicatie wordt beschermd met versleuteling van militair niveau.

Het eerste antwoord geeft informatie die je kunt beoordelen. Het tweede gebruikt indrukwekkende taal zonder de beschermde inhoud of het dreigingsmodel te definiëren.

2. Zijn foto's, video's en bijlagen ook versleuteld?

Een applicatie kan tekst versleutelen terwijl geüploade media via een ander systeem worden verwerkt.

Dat roept een belangrijke vraag op: wordt een foto vóór het uploaden aan de clientzijde versleuteld, of wordt die alleen beschermd door serverrechten en transportversleuteling?

Vraag naar:

• Foto's en video's
• Documenten
• Spraakberichten
• Linkvoorvertoningen
• Miniaturen
• Tijdelijke uploadbestanden
• Media in de cache
• Autorisatie voor downloads

Mediabescherming moet afzonderlijk worden beschreven en niet worden verstopt in een brede uitspraak over ‘berichten’.

Vraag afzonderlijk naar toegang tot versleutelde bytes en toegang tot de ontsleutelingssleutel. Sommige ontwerpen verspreiden versleutelde bijlagen via minder afgeschermde opslag; dat is niet automatisch blootstelling van leesbare gegevens. De cruciale vraag is of een onbevoegde partij leesbare media of de bijbehorende sleutel kan verkrijgen, en welke metadata het opslagpad onthult.

3. Waar worden versleutelingssleutels gegenereerd en opgeslagen?

Versleuteling is slechts zo betrouwbaar als het sleutelbeheer.

Bij E2EE aan de clientzijde moet privésleutelmateriaal onder controle van de apparaten van deelnemers blijven. Openbare sleutels kunnen worden gedeeld zodat contacten versleutelde communicatie kunnen opzetten, maar privésleutels hebben sterkere bescherming nodig.

Zoek duidelijke antwoorden op deze vragen:

• Wordt de privésleutel op het apparaat gegenereerd?
• Wordt die ooit onversleuteld geüpload?
• Kan de aanbieder de sleutel afleiden of vervangen?
• Kan een ander aangemeld apparaat die automatisch verkrijgen?
• Is de lokale sleutelopslag beschermd?
• Wat gebeurt er na een sleutelreset?
• Maakt herinstallatie van de applicatie een nieuwe identiteitssleutel aan?

De documentatie hoeft niet elk implementatiedetail openbaar te maken. Ze moet wel uitleggen wie de privésleutels beheert en hoe hun levenscyclus verloopt.

4. Kunnen contacten elkaars sleutels verifiëren?

End-to-endversleuteling beschermt een gesprek alleen wanneer de versleutelingssleutels van de bedoelde deelnemers zijn.

Veel veilige berichtensystemen stellen een openbare sleutel voor met een vingerafdruk, veiligheidsnummer, QR-code of andere verificatiewaarde.

Twee contacten kunnen die waarde vergelijken via een vertrouwd kanaal, zoals:

• Een persoonlijke ontmoeting
• Een geverifieerd telefoongesprek
• Een eerder geauthenticeerd account
• Een vertrouwde bedrijfsgids

Sleutelverificatie geeft extra vertrouwen dat de verwachte sleutels worden gebruikt; op zichzelf bewijst ze niet de identiteit van een persoon. Sommige producten bieden ook controles op sleuteltransparantie, zoals Signals automatische verificatie. Controleer de ondersteunde account- en versievoorwaarden in plaats van voor elk product een uitsluitend handmatige werkwijze te eisen.

Vraag ook wat er gebeurt wanneer een vingerafdruk verandert.

Een gewijzigde sleutel kan een onschuldige verklaring hebben, zoals een reset, vervanging van een apparaat of herstel. De wijziging moet wel zichtbaar zijn. Stille vervanging maakt het moeilijker om een onverwachte wijziging van de identiteitssleutel op te merken.

5. Welke metadata bewaart de dienst?

Berichtinhoud en berichtmetadata zijn verschillende categorieën.

Een dienst kan niet in staat zijn de tekst van een E2EE-bericht te lezen en toch informatie verwerken die nodig is om het gesprek te routeren, te synchroniseren en weer te geven.

Afhankelijk van het systeem kan het gaan om:

• Accountidentificatoren van afzender en ontvanger
• Lidmaatschap van gesprekken
• Tijdstempels van berichten
• Aflever- en leesbevestigingen
• Berichtgrootte
• Reacties en bewerkingsgebeurtenissen
• Apparaatsessies
• Synchronisatiecursors
• Openbaar sleutelmateriaal
• Tokens voor pushmeldingen
• Registraties voor misbruikpreventie en beveiliging

Het bestaan van operationele metadata maakt een dienst niet automatisch onveilig.

De belangrijke vragen zijn:

• Wat wordt verzameld?
• Waarom is het nodig?
• Hoelang wordt het bewaard?
• Wie heeft er toegang toe?
• Kan de gebruiker het exporteren of verwijderen?
• Wordt het gebruikt voor advertenties of niet-gerelateerde profilering?

Wees voorzichtig wanneer een aanbieder beweert ‘geen metadata’ op te slaan zonder te definiëren wat die als metadata beschouwt.

6. Hoe wordt je account geauthenticeerd?

Sterke berichtversleuteling compenseert geen zwakke accountbeveiliging.

Een aanvaller die een account overneemt, kan zich mogelijk voordoen als de gebruiker, een nieuwe sleutel registreren, toegang krijgen tot serverleesbare inhoud of herstel verstoren.

Beoordeel of de dienst bescherming biedt zoals:

• Veilige verwerking van wachtwoorden
• Beperking van het aantal verzoeken
• Intrekken van sessies
• Duidelijk apparaat- of sessiebeheer
• Bescherming tegen hergebruik van onderschepte inloggegevens
• Veilige procedures voor wachtwoordreset
• Multifactorauthenticatie waar passend
• Meldingen bij belangrijke accountwijzigingen

Maak ook onderscheid tussen accountauthenticatie en berichtversleuteling.

Aanmelden bewijst dat iemand over het accountinlogmiddel beschikt. Het bewijst niet noodzakelijk dat het apparaat de oorspronkelijke privéversleutelingssleutel bezit.

7. Hoe werkt versleuteld herstel?

Herstel leidt tot een van de moeilijkste afwegingen bij privéberichten.

Gebruikers willen begrijpelijkerwijs toegang tot hun gespreksgeschiedenis na vervanging van een apparaat. Maar als een aanbieder elke privésleutel stilzwijgend kan herstellen, heeft die mogelijk meer ontsleutelingsmogelijkheden dan gebruikers verwachten.

Een beschermd herstelontwerp kan een back-up op de client versleutelen en een herstelgeheim, passkey of goedkeuring van een vertrouwd apparaat vereisen. Bepaal eerst wat de back-up bevat: accountidentiteit, contacten en berichtgeschiedenis zijn verschillende dingen.

Vraag:

• Wordt de back-up vóór het uploaden versleuteld?
• Is het accountwachtwoord genoeg om hem te herstellen?
• Kent de aanbieder het herstelgeheim?
• Kan de klantenservice het geheim resetten?
• Wat gebeurt er als het geheim verloren gaat?
• Behoudt herstel dezelfde vingerafdruk van de openbare sleutel?
• Kan herstel worden uitgeschakeld?

Een betrouwbaar antwoord kan een ongemakkelijke beperking bevatten: als zowel de privésleutel als het herstelgeheim verloren gaan, kan oude versleutelde inhoud onherstelbaar worden.

Dat gevolg kan een aanwijzing zijn voor een echte beveiligingsgrens in plaats van een productfout.

8. Wat gebeurt er wanneer je verbinding wegvalt?

Beveiliging en betrouwbaarheid moeten samenwerken.

Mobiele verbindingen vallen weg. Browsers gaan in slaapstand. Apparaten wisselen van netwerk. Een goed ontworpen messenger moet tijdelijke onderbrekingen kunnen opvangen zonder berichten te dupliceren, de volgorde te verliezen of de versleuteling te verzwakken.

Zoek een offline- en synchronisatiemodel dat het volgende kan:

1. Een uitgaande actie lokaal klaarzetten.
2. Er een stabiele identificator aan toewijzen.
3. Na herstel van de verbinding veilig opnieuw proberen.
4. Dubbel verzenden voorkomen.
5. De bevestiging van de server verwerken en afstemmen.
6. Wijzigingen ophalen die tijdens het offline zijn zijn gemist.

Vraag afzonderlijk hoe de app de netwerkgegevens en de lokale uitgaande wachtrij beschermt terwijl een bericht wacht. E2EE bewijst niet automatisch dat de lokale wachtrij versleuteld is tijdens opslag.

Opnieuw proberen via het netwerk mag niet vereisen dat de bezorgdienst een leesbare kopie krijgt van een bericht dat verder end-to-endversleuteld is.

9. Hoe wordt toegang tot uploads en opgeslagen objecten toegestaan?

Mediabeveiliging omvat meer dan versleuteling.

Een dienst kan avatars, berichtbijlagen, achtergronden, stories, tijdelijke uploads en gegenereerde miniaturen verwerken. Voor elk object is een toegangsbeleid nodig.

Controleer of de applicatie:

• Authenticatie vereist om privémedia op te halen
• Controleert of het aanvragende account bij het betreffende gesprek hoort
• Openbare bestanden scheidt van privéberichtobjecten
• Niet-gekoppelde uploads opruimt
• Verlopen tijdelijke objecten verwijdert
• Caching over accountgrenzen heen voorkomt
• Onvoorspelbare identificatoren gebruikt zonder onvoorspelbaarheid als autorisatie te behandelen

Een privébestand in leesbare vorm mag niet toegankelijk worden alleen doordat iemand de URL raadt. Onderzoek bij versleutelde objecten hoe sleutels en toegangsrechten worden verspreid en ingetrokken. De autorisatierichtlijnen van OWASP adviseren toegangsbeslissingen consequent af te dwingen, ook voor statische bronnen; een onvoorspelbare identificator is op zichzelf geen volledig autorisatiebeleid.

10. Worden groepschats anders beschermd?

Groepsversleuteling en lidmaatschapsbeheer brengen andere vragen mee dan versleuteling van directe chats.

Wijzigingen in lidmaatschap, meerdere apparaten, berichtgeschiedenis, beheerdersrollen, uitnodigingen, verwijderingen en sleutelrotatie stellen allemaal aanvullende ontwerpeisen.

Sommige diensten bieden E2EE voor zowel directe chats als groepen. Andere bieden E2EE alleen voor directe gesprekken en beschermen groepen via TLS, geauthenticeerde opslag en toegangscontroles op de server.

Het tweede model kan nog steeds zinvolle beveiliging bieden, maar heeft een andere vertrouwensgrens.

Vraag of de server groepsinhoud kan verwerken en of de bescherming verandert wanneer:

• Een lid toetreedt
• Een lid vertrekt
• Een beheerder iemand verwijdert
• Een bericht wordt bewerkt
• De geschiedenis naar een nieuw apparaat wordt gesynchroniseerd
• Een bot of integratie de groep binnenkomt

Ga er nooit van uit dat een slotje bij één gesprekstype automatisch voor elk ander type geldt.

11. Welke privacyinstellingen heeft de gebruiker?

Privacy gaat ook over controle nadat informatie de dienst bereikt.

Zoek praktische account- en gespreksfuncties zoals:

• Accountgegevens exporteren
• Een account verwijderen
• Sessies intrekken
• Lokale of gesynchroniseerde geschiedenis wissen
• Verzonden berichten verwijderen waar dat is toegestaan
• Leesbevestigingen beheren
• De zichtbaarheid van het profiel regelen
• Ongewenste contacten blokkeren
• Meldingsvoorvertoningen beheren
• Sleutelback-ups uitschakelen of verwijderen

De aanbieder moet uitleggen of verwijderen alleen jouw kopie, de kopieën van alle deelnemers of de serverregistratie zelf verwijdert.

Een ontvanger kan een bericht al hebben gedownload, gekopieerd, doorgestuurd of gefotografeerd. Geen verwijderfunctie kan garanderen dat het van elk eindapparaat verdwijnt.

12. Zijn beveiligingsclaims specifiek en verifieerbaar?

De sterkste beveiligingsdocumentatie definieert grenzen.

Zoek specifieke uitspraken over:

• Algoritmen en sleutellengtes
• Bewerkingen aan de clientzijde tegenover de serverzijde
• Gesprekstypen die door E2EE worden gedekt
• Mediaversleuteling
• Opgeslagen informatie
• Authenticatie
• Herstel
• Sleutelwijzigingen
• Toegangscontroles
• Bekende beperkingen
• De datum waarop de documentatie voor het laatst is bijgewerkt

Behandel vage formuleringen voorzichtig:

• Onkraakbare versleuteling
• Absolute privacy
• Beveiliging van militair niveau
• Volledig anoniem
• Geen metadata
• Onmogelijk te hacken
• Toekomstbestendige versleuteling

Geen complex communicatiesysteem mag uitsluitend op basis van een slogan worden beoordeeld.

Onafhankelijke audits, openbare technische documentatie, reproduceerbare clients, professionele beoordelingen en duidelijk afgebakende beveiligingsrapporten kunnen extra zekerheid bieden. Ze leveren niet allemaal hetzelfde bewijsniveau, maar zijn nuttiger dan onbewezen superlatieven.

Veilige berichtenuitwisseling: sterke kenmerken en waarschuwingssignalen

Sterk kenmerk	Waarschuwingssignaal
De aanbieder benoemt welke gesprekken E2EE gebruiken	Elke functie wordt simpelweg als ‘versleuteld’ omschreven
Het beheer van privésleutels wordt uitgelegd	Sleutelbeheer wordt nooit besproken
Sleutelwijzigingen zijn zichtbaar	Sleutels kunnen stilzwijgend veranderen
Herstelbeperkingen zijn gedocumenteerd	De klantenservice kan alles herstellen zonder uit te leggen hoe
Metadatacategorieën worden opgesomd	De aanbieder claimt ‘geen metadata’ zonder definities
Mediabescherming wordt apart beschreven	Alleen tekstberichten worden genoemd
Groepen hebben een vastgelegde vertrouwensgrens	Claims over directe chats worden impliciet op groepen toegepast
Beveiligingspagina's bevatten actuele implementatiedetails	Marketingtaal spreekt technische documentatie tegen
Beperkingen worden duidelijk vermeld	De dienst belooft absolute of onkraakbare bescherming

De checklist toepassen op de openbare claims van Livara

De beveiligingspagina van Livara biedt productdocumentatie, geen onafhankelijke certificering. De huidige grenzen maken onderscheid tussen:

• Directe berichten: LVR1 gebruikt hybride sleutelovereenkomst met P-256 en ML-KEM-768 en geauthenticeerde versleuteling voor ondersteunde inhoud.
• Compatibele privégroepen: bescherming met LGS1-afzendersleutels; lidmaatschap en rollen blijven een afzonderlijke grens waarover de server beslist. Oudere, incompatibele groepen mogen niet automatisch een E2EE-label krijgen.
• Openbare kanalen: voor de server leesbare inhoud, geen E2EE.
• Herstel: identiteitsmateriaal wordt vóór het uploaden versleuteld; het herstellen daarvan is niet hetzelfde als het herstellen van chatgeschiedenis.
• Metadata en apparaten: routeringsregistraties en gecompromitteerde eindapparaten vallen buiten de belofte van inhoudsversleuteling.

Gebruik deze uitspraken als claims om te toetsen aan je geïnstalleerde versie en het dreigingsmodel. Een protocolspecificatie, een lokale testvector, een audit van een bepaalde versie en observatie van de actieve dienst zijn verschillende vormen van bewijs. Vervang ontbrekend bewijs niet door de aanname van perfecte beveiliging of een bewezen kwetsbaarheid.

Een checklist voor veilige berichtenuitwisseling in 60 seconden

Controleer voordat je een account maakt of je elke vraag kunt beantwoorden:

• Welke gesprekstypen zijn end-to-endversleuteld?
• Vallen afbeeldingen, video's, documenten en spraakberichten onder de bescherming?
• Worden privésleutels op apparaten van deelnemers gegenereerd en bewaard?
• Kunnen contacten sleutelvingerafdrukken of veiligheidsnummers vergelijken?
• Zijn sleutelwijzigingen zichtbaar?
• Benoemt het privacybeleid welke metadata worden opgeslagen?
• Wordt accountauthenticatie uitgelegd?
• Staat sleutelherstel los van gewoon aanmelden?
• Worden verzoeken om privémedia geauthenticeerd en geautoriseerd?
• Blijft versleuteling actief tijdens offline wachten in de wachtrij?
• Hebben groepen en kanalen een precieze beveiligingsgrens?
• Zijn beperkingen gedocumenteerd zonder overdreven beloften?

Markeer onbeantwoorde punten als ‘onbekend’, niet automatisch als ‘veilig’ of ‘onveilig’. Een aanbieder hoeft niet dezelfde architectuur als elke concurrent te gebruiken.

De aanbieder moet wel antwoorden geven die precies genoeg zijn om gebruikers te laten begrijpen waarop ze vertrouwen.

De veiligste keuze hangt af van je dreigingsmodel

Er is geen universele berichtenapp die automatisch voor iedere persoon en situatie de beste is.

Een familiegroep, een werkplek, een journalist en bron, een zorgteam en een openbare gemeenschap kunnen verschillende combinaties nodig hebben van:

• Vertrouwelijkheid
• Identiteitsverificatie
• Anonimiteit
• Groepsbeheer
• Bewaren van berichten
• Naleving van regelgeving
• Herstel
• Ondersteuning voor meerdere apparaten
• Openbroncode
• Onafhankelijke audits
• Gebruiksgemak

Begin met de vraag wat je beschermt en tegen wie.

Bij gewone persoonlijke communicatie zijn de belangrijkste risico's mogelijk accountdiefstal, een onveilig netwerk, een verloren apparaat of overmatige gegevensverzameling.

Voor communicatie met hogere risico's heb je mogelijk ook geverifieerde identiteiten, beleid voor verdwijnende berichten, extra beveiligde apparaten, strikte operationele procedures en onafhankelijke beveiligingsbeoordeling nodig.

Versleuteling kan een gecompromitteerd eindapparaat niet herstellen en niet voorkomen dat een vertrouwde ontvanger een bericht deelt.

Privacy begint met juiste verwachtingen

Een betrouwbare messenger vraagt gebruikers niet te geloven dat elk risico verdwenen is.

Die legt uit:

• Wat beschermd is
• Welke apparaten de sleutels bezitten
• Wat de server verwerkt
• Welke metadata overblijven
• Hoe herstel werkt
• Waar E2EE begint en eindigt
• Welke beschermingsmaatregelen nog niet zijn geïmplementeerd

Die duidelijkheid stelt gebruikers in staat geïnformeerde beslissingen te nemen.

Duidelijke documentatie is noodzakelijk voor beoordeling, maar niet voldoende om de veiligste app vast te stellen. Implementatiekwaliteit, tijdige updates, onafhankelijke bevindingen en de risico's van je werkelijke gebruik tellen ook mee. De gids van EFF voor het kiezen van hulpmiddelen adviseert eveneens om bij je dreigingen te beginnen en openheid te zien als een mogelijkheid voor beoordeling, niet als garantie.

Doe als volgende stap een onschuldige proef: verifieer één contact, verstuur een voorbeeldbijlage, controleer gekoppelde apparaten, bekijk de reikwijdte van de back-up en bevestig dat beide deelnemers de instellingen betrouwbaar kunnen gebruiken. Test niet met het vertrouwelijke materiaal dat je probeert te beschermen.

Veelgestelde vragen

Wat maakt een berichtenapp veilig?

Een veilige berichtenapp combineert beschermd netwerktransport, sterke authenticatie, zorgvuldige toegangscontroles, veilig sleutelbeheer, verantwoord gegevensbeheer en duidelijk gedocumenteerde privacygrenzen. Voor privéberichtinhoud biedt end-to-endversleuteling een belangrijke extra laag.

Is een versleutelde berichtenapp automatisch privé?

Nee. Een app kan berichtinhoud versleutelen terwijl die nog steeds accountinformatie, tijdstempels, lidmaatschap, bevestigingen, apparaatinformatie of andere metadata verwerkt. Privacy hangt af van zowel versleuteling als het bredere gegevensbeleid van de dienst.

Verbergt end-to-endversleuteling met wie ik berichten uitwissel?

Niet noodzakelijk. E2EE beschermt vooral ondersteunde berichtinhoud. De dienst kan nog steeds gegevens over afzender, ontvanger, lidmaatschap, tijd en routering nodig hebben om gesprekken af te leveren en te synchroniseren.

Kan een berichtenaanbieder E2EE-berichten herstellen?

Dat hangt af van het sleutel- en back-upontwerp. Een aanbieder kan versleutelde berichtgeschiedenis bewaren zonder de privésleutel te bezitten die nodig is om die te openen. Een herstelsysteem kan de sleutel mogelijk alleen herstellen wanneer de gebruiker een apart herstelgeheim verstrekt.

Is beveiligde berichtenuitwisseling via de browser veilig?

Een browser kan sterke cryptografie aan de clientzijde uitvoeren, maar beveiliging blijft afhankelijk van de implementatie van de applicatie, de integriteit van de browser, apparaatbeveiliging, sleutelopslag, het aanleveren van applicatiecode door de server en de extensies en het besturingssysteem van de gebruiker.

Zijn groepschats altijd end-to-endversleuteld?

Nee. Sommige diensten bieden E2EE voor groepen, andere passen het alleen toe op directe gesprekken. Controleer de documentatie van de aanbieder voor de precieze grens.

Wat gebeurt er als mijn versleutelingssleutel verandert?

Een sleutelwijziging kan ontstaan door een nieuw apparaat, herinstallatie, sleutelreset of herstelproces. Een veilige messenger moet de wijziging zichtbaar maken en contacten de nieuwe vingerafdruk laten verifiëren.

Is E2EE genoeg voor zeer gevoelige communicatie?

E2EE beschermt inhoud tussen ondersteunde eindapparaten, maar beschermt geen besmet of ontgrendeld apparaat, garandeert het gedrag van een ontvanger niet en verbergt metadata niet automatisch. Gebruikers met hogere risico's hebben ook sterke apparaatbeveiliging en veilige operationele werkwijzen nodig.