Fysiek afspreken is niet meer nodig: Signal automatiseert vergelijken van keys

Signal gaat cryptografische sleutels voortaan automatisch verifiëren. Het gaat om de functie waarmee gebruikers via een QR-code kunnen controleren of hun gesprekspartner inderdaad de juiste ontvanger van een bericht is. Om dat nu te verifiëren, moeten gebruikers fysiek afspreken, maar dat proces besteedt Signal nu uit aan Cloudflare en een ander beveiligingsbedrijf.

Signal noemt dat proces Automatic Key Verification. De chatapp gaat de verificatie in de toekomst cryptografisch automatiseren door een samenwerking met 'auditors', specifiek Cloudflare en Trail of Bits.

Key verification is een functie in Signal (en WhatsApp heeft het ook) waarmee gebruikers kunnen controleren of een gesprekspartner wel is wie die zegt te zijn. Dat werkt door in de chat naar 'Verify safety number' te gaan. Daar staat een cryptografische code van 60 cijfers. Zowel de verzender als de ontvanger zien in hun chats met elkaar dezelfde cijfers. Die cijfers worden cryptografisch gegenereerd op het moment dat de twee gebruikers een chat met elkaar beginnen. Voor het gebruikersgemak worden die cijfers ook omgezet in een QR-code.

Om sleutels met elkaar te vergelijken was het altijd nodig deze code fysiek te vergelijken.

Hacker in het midden

De veiligheidscheck is bedoeld voor het geval dat Signal wordt gehackt of een aanvaller via een adversary-in-the-middleaanval berichten probeert te onderscheppen. Daardoor kan die bijvoorbeeld berichten meelezen. Op dat moment verandert ook de cryptografische sleutel tussen verzender en ontvanger. Om zeker te weten of je als verzender wel een bericht stuurt aan de juiste ontvanger en niet aan een hacker-in-het-midden, bestaat de functie om cryptografische sleutels met elkaar te vergelijken.

Het grote probleem daarbij is alleen dat verzender en ontvanger daarvoor fysiek bij elkaar moeten komen en hun telefoons langs elkaar moeten houden. Dat doet niemand. En precies dat proces neemt Signal nu uit handen.

Auditors controleren logs

Signal verzamelt daarvoor alle wijzigingen in de cryptografische sleutels op een centrale plek, een 'ledger'. Daarin staat of de koppeling tussen een Signal-telefoonnummer en een public key nog klopt – ook dat gaat overigens grotendeels cryptografisch. Maar omdat de functie bedoeld is om juist aanvallen op Signal zelf te spotten, kan Signal niet de enige partij zijn die die ledger controleert.

Daarom werkt Signal samen met twee partijen die als auditor gelden. Dat zijn Cloudflare en securitybedrijf Trail of Bits. Die controleren onafhankelijk van elkaar de ledger. Cloudflare schrijft daar zelf over: "Cloudflare haalt periodiek batches met updates uit Signals Key Transparency-log en verifieert cryptografisch dat iedere update consistent is met alles dat eerder is opgenomen. Zodra die check slaagt, ondertekent Cloudflare de update en Signal stuurt de ondertekende update naar zijn gebruikers. Die kunnen dat verifiëren en zeker weten dat Signal hen een globaal consistent inzicht in het log toont." Ook Trail of Bits heeft een blogpost geschreven.

Twee = een en een = geen

Voor de veiligheid zijn er twee partijen die dat naast Signal doen. Cloudflare en Trail of Bits verifiëren de systemen onafhankelijk van elkaar, zodat er geen nieuwe single point of failure ontstaat dat kan worden aangevallen. De auditors werken alleen met cryptografische verificatie en kunnen dus geen gebruikersnamen of telefoonnummers zien, of zelfs de public keys zelf.

In de praktijk betekent dat dus dat gebruikers ervan uit kunnen gaan dat de cryptografische verificatie tussen verzender en ontvanger niet is onderschept, zonder dat ze elkaar fysiek hoeven te ontmoeten. Dat moet het verificatieproces veel laagdrempeliger maken, al moeten gebruikers nog steeds zelf de functie opzoeken in een chat als ze die willen gebruiken.

Alleen telefoonnummers

De functie van key transparency werkt zowel handmatig als automatisch alleen met telefoonnummers. Gebruikers die elkaar alleen kennen op basis van hun gebruikersnamen kunnen elkaar niet verifiëren.

Daarnaast werkt de functie niet meer als een van de gebruikers zijn of haar telefoonnummer of gebruikersnaam verandert. Dan geldt weer hetzelfde. De gebruikers moeten elkaar dan opnieuw fysiek ontmoeten om de keys te controleren.

Reacties (62)

[striper]

Toevallig kwam ik gisteren deze optie tegen onder Settings->Advanced: Automatic Key Verification. Zou dit de feature uit het artikel zijn? Ik heb v8.23 op iOS. Het klinkt overigens alsof de verificatie volledig automatisch is, dus dat er geen handmatige actie voor nodig is.

edit:
Je moet dus nog steeds handmatig via User info -> View Safety Number -> Automatic verification de verificatie uitvoeren. Het voelt tegenstrijdig om handmatig iets "automatisch" te moeten starten. OK, de verificatie is automatisch, maar dit moet toch volledig automatisch kunnen gebeuren? Zoals bij WA, zodra je een nieuwe chat start met iemand.

[Reactie gewijzigd door striper op 14 augustus 2026 12:00]

[baseoa]

Het kan niet automatisch zonder quantumverstrengeling. Key distribution is een fundamenteel probleem bij klassieke cryptografie: hoe weet je wiens sleutel je ontvangen hebt wanneer het medium authenticiteit niet garandeert? Als WhatsApp je wijsmaakt dat het automatisch gaat, vertellen ze niet het hele verhaal. (Ik heb WhatsApp niet geïnstalleerd dus kan niet zien wat ze in de app precies claimen.)

Er wordt op verschillende manieren omheen gewerkt, maar je moet altijd ergens iets of iemand verifiëren en vertrouwen:

HTTPS vertrouwt een lijst van enkele honderden certificeringsautoriteiten (CA's) waarvan de public keys op jouw systeem voorgeïnstalleerd staan. Als een van hen het certificaat ondertekent waarvoor de server de bijbehorende private key heeft, krijg jij een groen slotje in de browser te zien. Een tweede afhankelijkheid hier is dat je die lijst ergens gedownload hebt toen je de browser installeerde en dat die regelmatig updates krijgt. Dit overlapt dan met "is mijn OS wel veilig?" maar omdat het om sleutels uitwisselen gaat, schaar ik het er in dit geval ook onder.

Chat-app Keybase probeerde Blockchain te gebruiken (ik meen specifiek Bitcoin) een aantal jaar geleden. Dat was een leuk idee, maar je wilt geen terabytes aan data op een telefoon hoeven opslaan om waarden in de blockchain te kunnen checken. Daar kun je met light clients best een leuk ontwerp omheen maken, maar zover ik weet staat dat ontwerpticket nog open, terwijl ze wel adverteerden (banner bij het openen van een nieuwe chat) met end-to-end-versleuteling. Die 'ends' waren dus helemaal niet geverifieerd en je vertrouwt erop dat de server de goede sleutel opstuurt. Je kon het ook niet zelf handmatig checken. NCC Group had dit ge-audit en over het hoofd gezien. Daarop heb ik het gerapporteerd en ze snapten het probleem niet en vroegen om een proof-of-concept (hun server is closed source: ik zou dan het hele protocol moeten reverse engineeren en een kwaadaardige server in elkaar knutselen... voor wat, omdat zij niet willen toegeven dat ze nooit e2ee waren? Pre-LLM een week aan werk wat vervolgens in de prullenbak kan omdat je het natuurlijk niet gaat gebruiken... dus dat hebben ze nooit opgelost of erkend). Anyway, zelfs als je dit zou doen moet je aannemen dat Bitcoin betrouwbaar blijft (dat geen mining pool >50% in handen krijgt of er meerdere samenzweren), wat ik niet onredelijk vind maar het onderliggende principe van derden moeten vertrouwen blijft hetzelfde.

Threema toont verschillende verificatieniveau's, maar dat is eigenlijk vooral anti-phishing: je krijgt een gele in plaats van een rode indicator bij contacten die in je adresboek staan, groen wordt het dan wanneer je hun sleutel zelf verifiëert.

PGP werkt met een web of trust: als jouw vriend Pietje (die je geverifieerd hebt) de sleutel van Jantje al gecontroleerd heeft, en jij instelt dat je Pietje vertrouwt om dit fatsoenlijk na te kijken (niet zoals Cueball in XKCD), dan hoef jij dit niet nogmaals te doen. Je hebt dan al een chain of trust (jij vertrouwt A, A vertrouwt . Een verzameling van zulke relaties wordt web of trust genoemd. Ook hier vertrouw je dan dus de tussenpartijen; het gaat niet automagisch. In ons bedrijf maakt dat e-mailen heel makkelijk: ik sign iedereens sleutel en iedereen hoeft alleen mijn sleutel handmatig te checken.

Signal werkt al jaren met Intel-CPU's voor private contact discovery, wat niet echt een key distribution problem is maar het vertrouwen van de sleutel van een derde werkt op een vergelijkbare manier: hun CPU's hebben een private key ingebakken die de maker, Intel, ondertekend heeft bij productie. De CPU certificeert welk programma het uitvoert (remote attestation), in dit geval het programma dat zoekt naar overeenkomstige contacten zonder daarbij jouw contactenlijst voor de amerikaanse Signal Foundation inzichtelijk te maken. Als jij Intel vertrouwt, weet je dus zeker dat de server het juiste programma draait. Nu is het, net als bij dit nieuws, jammer dat het allemaal onder de zeggenschap valt van de amerikaanse overheid, en dat Intel SGX (zoals de functie heet) talloze lekken kent en algemeen als onveilig beschouwd wordt, maar het is wel een vernieuwende oplossing die nog niet elders wordt toegepast zover ik weet.

De meest decentrale oplossing (geen één partij die alles moet bijhouden, tracken, of offline kan gaan) blijft nog altijd PGP. Deze ledger van Signal zouden derden als ik ook kunnen verifiëren, maar ik heb die sleutels niet gecontroleerd: beide chatpartijen moeten dan aan mij doorgeven of hun sleutel in de ledger zit, anders kan het ook Signal of de AIVD zijn die doorgeven "hoi ik ben [phone] en mijn sleutel is inderdaad 0x5up3rev1l".

Maargoed, Signal laat het toch niet toe om zomaar een controlerende partij te worden. Het blijft dus vertrouwen dat Trail of Bits, Cloudflare, en Signal niet samenwerken, dan wel dezelfde brief gekregen hebben van de overheid.

[Reactie gewijzigd door baseoa op 14 augustus 2026 18:33]

[david-v]

Zoals bij WA, zodra je een nieuwe chat start met iemand.

Doet WA deze sleutel verificatie bij elke chat? Voor zover ik weet heeft WA hetzelfde als Signal. Verificatie fysiek maar niet remote. Ik weet het niet omdat ik al jaren geen WA met gebruik.

[ccnl]

Dus je moet 2 US organisaties vertrouwen?

Trail of Bits: 228 Park Ave S #80688, New York, NY 10003

Cloudflare: 101 Townsend St. San Francisco, CA 94107

[astro_volt]

Het idee is als je snel een simpele manier wil hebben om op afstand automatisch cryptografische sleutels te verifieren, kan je dat dus via 2 independent organizaties dat doen zonder dat je persoonlijke informatie met hun deelt.

Als je threat level hoog genoeg is dat de VS Cloudflare en Trail of Bits zou forceren om, bijvoorbeeld alle sleutel verificatie te ondermijnen voor een bepaalde tijd die overeenkomt met de tijd dat jij de verificatie zou doen, en daar bovenop nog eens een 'man in the middle' attack op je uitvoert zonder dat Signal hier van weet, dan kan je altijd nog gewoon fysiek met je contact je sleutels verifieren.

[ccnl]

zonder dat Signal hier van weet

Hoezo zonder Signal het weet? Signal kan gedwongen worden te zwijgen

Signal Technology Foundation: 650 Castro Street, Suite 120-223, Mountain View, CA 94041


Als iemand 'man in the middle' attack op mijn thuisinternet kan uitvoeren, moet van de kaliber CIA of NSA zijn, dus alle 3 Signal, Cloudflare en Trail of Bits zijn niet te vertrouwen.

[astro_volt]

Inderdaad Signal kan dan ook worden geforceerd om te zwijgen.

Maarja dan nog, dan moeten ze eerst een patch uitbrengen die jij dan moet downloaden om de verificatie van cryptografische sleutels te bypassen. En dat terwijl al hun software open source is en constant gaudit word door derden.

[GameNympho]

En jij denkt dat ze dit niet wisten en misschien wel specifiek zo gedaan hebben?

Zolang men meer wil weten dan nodig is en alles door brieft, is het een no-go voor mij.

[astro_volt]

Als jij nu Signal, of wat voor andere E2E-encrypted messaging app zou gebruiken en je word getroffen door een man-in-the-middle attack dan zien ze toch al je berichtjes die je vanaf dat moment stuurt. Dat is, zolang jij geen sleutel verificatie hebt gedaan.

Dit systeem bestaat alleen maar om sleutelverificatie makkelijker te maken voor de meeste mensen. Als jij verwacht dat je door de CIA/NSA gaat worden onderzocht dan ga je toch niet dit systeem gebruiken, maar wel de in-person sleutelverificatie.

Om te denken dat deze hele constructie een opzet is door Signal zodat ze in de toekomst heel stiekem een patch kunnen uitbrengen voor een handjevol gebruikers om de hele encryptie te slopen is echt gewoon een dikke conspiracy-theory.

[Reactie gewijzigd door astro_volt op 14 augustus 2026 14:45]

[GameNympho]

I like conspiracy theorie`s, there is always a truth that comes up

[astro_volt]

Tja als je elk jaar 10,000 keer wat roept misschien dat je een keertje in je leven wel gelijk krijgt

[Guru Evi]

Niemand wordt gedwongen te zwijgen en/of te liegen, hier is het principe: een mens kan een geheim houden, twee mensen kunnen dit niet.

Dus als je denkt dat Signal gecompromitteerd is, vraag je het aan 2 of 3 andere onafhankelijke mensen of de nummers overeenkomen. Je bent ook niet verplicht die twee mensen te gebruiken, in principe kan gelijk welke derde partij gevraagd worden.

[ccnl]

Niemand wordt gedwongen te zwijgen en/of te liegen

Behalve degene, de een National Security Letter kreeg. Schending van geheimhoudingsplicht of verraad van staatsgeheim kunnen tot hoge gevangnisstrafen leiden.

een mens kan een geheim houden, twee mensen kunnen dit niet.

Vervang je mensen door landen, dan komt je beetje dichter bij de waarheid.

[Guru Evi]

Ik denk dat je niet begrijpt wat een NSL mag en niet mag doen.

Het mag vragen voor informatie over bepaalde mensen, het is mogelijk dat een bedrijf de informatie van de aanvraag niet mag verspreiden (binnen bepaalde perken), het kan echter niet opleggen dat een betrokken partij moet liegen, systemen aanpassen of een niet betrokken partij moet zwijgen. Een kanarie is door het hooggerechtshof in de VS toegelaten als vrijheid van meningsuiting.

[Reactie gewijzigd door Guru Evi op 15 augustus 2026 19:20]

[Nark0tiX]

Maar dit doe je toch 1 malig? Je spreekt af hey ik ben Piet dit is mijn public key, hey ik ben jan dit is mijn public key.

Daarna hoef je toch niks meer te checken, je encrypt je berichten met die public key. Als persoon ineens wijzigt van public key jammer voor hem. Kan hij ook geen berichten meer ontsleutelen.

Snap dit probleem niet zo. Met pgp gaat het ook zo. Public key uitwisselen via veilig kanaal. En vanaf dat moment kan je altijd verifiëren of bericht gesigned is door persoon x. Of bericht persoon x ontsleutelen. Niks en niemand voor nodig.

[xxs]

Ik denk wel meer, om te beginnen de maker van je OS.

[ccnl]

Astra Linux van Rusland en Harmony OS van China werken prima met Signal van US maker.

[xxs]

Vast wel, en waarschijnlijk niemand hier die het echt gebruikt.

[Blizz]

2 maar? Toch zeker minimaal de volgende partijen voor de dienst:

• Trail of Bits: 228 Park Ave S #80688, New York, NY 10003, USA
• Cloudflare: 101 Townsend St. San Francisco, CA 94107, USA
• Signal Messenger LLC: 650 Castro Street, Suite 120-223 Mountain View, CA 94041, USA

Voor je apparaat en het OS meestal 1 of 2 van de volgende partijen:

• Apple Inc.: One Apple Park Way, Cupertino, CA 95014, USA
• Google LLC: 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA
• Samsung Electronics Co., Ltd.: 129 Samsung-ro, Yeongtong-gu, Suwon-si, Gyeonggi-do, South Korea

[Reactie gewijzigd door Blizz op 15 augustus 2026 01:53]

[Maurits van Baerle]

Ha, gaan ze in zee met Cloudflare, de grootste Man-in-the-Middle partij ter wereld.

Ik vraag me af of ze geen betere clubs hadden kunnen vinden om dit te doen om reputatieschade te voorkomen.

[astro_volt]

Heb je het artikel niet gelezen? Ze hebben met opzet een 2e onafhankelijke partij ingeschakelt, namelijk Trail of Bits.

En dit is optionele verificatie. Je kan nog steeds gewoon fysiek de QR code scannen of de code invoeren en manueel verifieren als je Cloudflare en Trail of Bits niet vertrouwd.

[Overheid]

Je kunt best vraagtekens zetten bij hoe "onafhankelijk" deze partijen zijn, gezien ze beiden in de VS zitten. Ze hadden beter een partij A in de VS kunnen doen en een partij B in bijvoorbeeld Zwitserland zodat het er op z'n minst op papier beter uit ziet.

[astro_volt]

De Signal foundation is ook gewoon een non-profit gebaseerd in de VS.

Bovendien halen ze de in-person sleutelverificatie niet er uit. Dit is gewoon een additionele optie die wat makkelijker is te gebruiken en heel moeilijk kan worden misbruikt.

Als ze een partij in Zwitserland hadden ingeschakelt dan kan de VS ook invloed uitoefenen, kijk maar naar hoeveel dataverzoeken bijvoorbeeld Proton moet delen via de Zwitserse authoriteiten met hun buitenlandse partners tegen 'potentiele criminele activiteiten'. Dat is hier eigenlijk niet anders.

[baseoa]

De Signal foundation is ook gewoon een non-profit gebaseerd in de VS.

Daarom toch juist? Als zij in Nederland zaten zou je een verificatie in Rusland willen hebben zitten en omgekeerd. Nu dat zowel de controlerende instantie als de gecontroleerde in de VS zitten, weet je niet of ze niet beide dezelfde brief hebben gekregen met een tapbevel

Natuurlijk voor nagenoeg niemand relevant en je kan ook gewoon de volledige verificatie zelf doen, maar als je toch bezig bent, waarom dan niet ook gelijk een partij elders op de wereld nemen

[R_Zwart]

Heb je suggesties wie dit beter kan doen? (En hebben die ook de benodigde schaalgrootte?)

[baseoa]

Dit soort verificatiesystemen kun je bijna op een raspberry pi draaien. Hoe vaak voeg je een nieuw contact toe? Stel dat dat gemiddeld tien keer per jaar is, plus zeg dat 25% van de mensen jaarlijks nieuw bij Signal komen die dan gemiddeld 50 contacten toevoegen in een jaar, dan zit je bij een miljard gebruikers aan gemiddeld 634 requests per seconde. Mensen zijn tegelijkertijd wakker dus op piekmomenten is het misschien 6340 r/s. Dat haalt mijn oude laptop, die ik als server inzet, waarschijnlijk net niet in z'n eentje. Nu heeft Signal nog geen tiende van die hoeveelheid gebruikers maar dat is het type infra waar je aan moet denken (plus natuurlijk redundantie). Je hoeft geen Cloudflare te heten om een paar database lookups te doen, zeker niet wanneer alle actieve gebruikers in RAM passen (telefoonnummer is zo'n 33 bits, een hashwaarde bijvoorbeeld 256 bits, maal een miljard = 36GB voor de complete database)

[DigitalExorcist]

Naja je kán het overslaan (lijkt me??) en het nog steeds 'fysiek' doen. Neem ik aan.

[ocf81]

Precies dit. De overheid gaat dan de keten af om te zien wie ze onder druk kunnen zetten om hier tussen te komen.

[david-v]

Dan heb je als gebruiker nog steeds de optie om fysiek de verificatie te doen. Zelfs via een ander medium zou je de verificatie kunnen doen, elkaar opbellen en de cijferreeksen noemen en controleren. Er zijn veel makkelijkere manieren voor een overheid om mee te kijken met berichten op je telefoon.

[PeterDeTweaker]

Ok, zojuist gedaan bij een contact, maar ik kan het daarna meteen weer doen.

Moet je het bij elk bericht weer opnieuw doen?

[DigitalExorcist]

Nee in principe doe je dit eenmalig per contact. Misschien moet je 't opnieuw doen als je een nieuwe foon in gebruik neemt, dat zou op zich logisch zijn.

iMessage heeft deze functie ook al een tijdje maar hoeft niet perse fysiek bij elkaar te zijn, daar kun je je contactpersoon vragen om het Verificatie-code menuutje op zijn (m/v) telefoon te openen en als je dat zelf op hetzelfde moment doet kun je ook verifiëren.

Ik heb een nieuwe iPhone in gebruik genomen een week of wat geleden en m'n publieke key bleef hetzelfde, waarschijnlijk omdat ik m'n iCloud backup 1-op-1 teruggezet heb.

Die publieke key kan je ook gewoon online delen trouwens. Is ook handig.

[ECM-Droid]

Mooi dat Signal, (maar ook andere privacy gerichte chat apps zoals Threema) blijven innoveren op dit gebied. Je zou denken dat het ondertussen niet veiliger kan, maar jawel hoor, weer een nieuwe functie die het nog weer veiliger maakt.

Dat zegt tegelijkertijd ook wel veel over chat apps als Whatsapp en Telegram die dat niet doen. Het eigenlijk gewoon houden op "simpele" e2e.

edit:
I now, dit is wat kort door de bocht, maar je snapt m'n punt wel denk ik🙃

[Reactie gewijzigd door ECM-Droid op 14 augustus 2026 11:53]

[Mirved]

maar Whatsapp is toch helemaal niet gericht op privacy of veiligheid. Denk dat de gemiddelde gebruiker daar ook totaal geen behoefte toe heeft bij deze app. Snap zelf nauwelijks waarom ik als regulier persoon gebruik zou willen maken van genoemde functie.

[DigitalExorcist]

Ik weet niet of het default uit- of aan staat, maar ik krijg telkens als iemand een nieuwe foon heeft een melding in Whatsapp dat de veiligheidscode veranderd is. Kan me niet herinneren dat ik dat áángezet heb, maar misschien ooit wel gedaan.

Een 'gewone' gebruiker hoeft daar niet zoveel mee. Maar dat de optie er is is op zich mooi. Ik vermijd sowieso mensen die Whatsapp gebruiken trouwens maar goed, dát het kan is leuk.

[DigitalExorcist]

Mja Whatsapp zegt me al járen dat 'de veiligheidscode voor persoon <x> is gewijzigd' als die persoon een nieuwe foon heeft. Dat suggereert toch ongeveer hetzelfde?

iMessage kan dat ook al een tijdje, en ook semi-op-afstand.

[Reactie gewijzigd door DigitalExorcist op 14 augustus 2026 11:58]

[david-v]

WhatsApp gebruikt dezelfde methode als Signal. Als de code veranderd dan weet je dat er iets gaande is. Je zou dan fysiek moeten afspreken om die code te verifiëren. Maar elkaar bellen en de codes opnoemen kan ook. Wat er nu bijkomt is dat het ook via deze partijen geautomatiseerd kan.

[baseoa]

WhatsApp gebruikt dezelfde methode als Signal.

Daar komt dat niet door; een nieuwe sleutel niet zomaar vertrouwen is geen unieke feature van het Signal Protocol. Dat gebeurt al sinds asymmetrische versleuteling gemeengoed werd met PGP

[Reactie gewijzigd door baseoa op 14 augustus 2026 18:57]

[hanskroll]

Dit wordt dus een functie die de gebruiker zelf nog altijd aan en uit kan zetten

[DigitalExorcist]

Vet handig wel. Hoewel ik dit fysiek met de personen met wie ik het meeste communiceer al gedaan heb.

iMessage heeft dat trouwens ook al een tijdje.. zowel automagisch als fysiek...

[Recursio]

"hacker-in-het-midden" als vertaling van "Man-in-the-Middle" of "adversary-in-the-middle" ziet er wel een beetje krampachtig uit. Hoewel het lijkt alsof lezers geholpen worden door de term niet in het Engels maar in het Nederlands aan te bieden maak je het de lezers die daar verder in willen duiken juist moeilijker, want waar op de zoeken? Als het onderwerp belangrijk en/of interessant voor de lezer is, kan deze best een nieuwe term leren lijkt me, daar is hij/zij het meest bij geholpen.

[Reactie gewijzigd door Recursio op 14 augustus 2026 12:33]

[baseoa]

In de industrie gebruik je sowieso alleen de term MITM of MitM. In onze rapporten hebben we dan een termenoverzicht waar dit soort afkortingen worden uitgelegd. Daar is het Machine-in-the-Middle, waar je prima resources op kan vinden (Wikipedia heeft er bijv. een redirect voor en benoemt het in het artikel) en toch niet meer alleen over mannen hoeft te gaan. De woorden zijn ook goed bekend in het Nederlands: "machine in" bestaan letterlijk, "the" is het eerst wat je leert na yes/no dus dat snapt ook iedereen, en dat middle midden moet zijn haal je desnoods uit de context van het artikel. Ik zou Tweakers dus vooral dat aanraden in plaats van een 15e standaard te gaan bedenken voor het Nederlandse publiek

[Memori]

en toch niet meer alleen over mannen hoeft te gaan

Ik neem aan dat je "mensen" bedoelde? Want het zelfstandig naamwoord "man" refereert in deze context niet naar mannen, maar naar mensen.

man noun (PEOPLE)
- the human race
- a person

Woorden hebben vaak meer dan één betekenis en uit context zijn deze zeer makkelijk te begrijpen, alleen struikelen sommige mensen hier tegenwoordig over door tunnelvisie van hun ideologieën, als een stier op een rood doek.

In het Nederlands is dit ook zo:

3) persoon, mens
op de man af iets vragen
als één man achter iemand staan

[baseoa]

Dat hangt van de context af. Als je zegt "the man over there" dan betekent dat toch echt niet "mens" en zou je niet een madame verwachten daar te zien

Zie daarnaast de verschuiving van betekenissen en connotaties. Vroeger berekende gay heel wat anders in het Engels en nog niet zo lang geleden was neger een geaccepteerd woord in het Nederlands. Vroeger moest je inderdaad maar genoegen nemen met dat je er half bij hangt wanneer men over "man" spreekt, alsof zo iedereen genoemd is die ertoe doet. Hoe anno 2026 de zin "a man intercepts your connection" verstaan wordt, kan ieder voor zich invullen. Ik zie iig geen nadeel in het gebruik van de term "machine". Uiteindelijk is dat toch wat het is – voor niet-cyborgmensen die geen ethernet kunnen voelen xD

[Reactie gewijzigd door baseoa op 14 augustus 2026 19:18]

[fuzzyIon]

Leuk maar je moet nog de auditors (grote bedrijven) maar vertrouwen al zijn alle drie nodig voor een key acceptstie. Veel liever zou ik de mogelijkheid voor absolute zero trust willen zien. Maw elke gebruiker de mogelijkheid van een mandatory yubikey. Dus al zouden alle drie de auditors stuk gaan dan nog is goedkeuring van de gebruiker nodig voor key verandering.

[Miglow]

Ik denk dat met een verplichte autorisatie via yubikey de app zo op zijn gat ligt. Ik ken slechts een persoon met een yubikey en dat is omdat ze haar eigen bedrijf heeft en met gevoelige bedrijfsgegevens werkt. Als dat verplicht wordt omdat iemand anders dat vinkje aan heeft gezet aan hun kant: Toedeledoki.

[ultimahuman]

Ik ken best veel mensen die een yubi key hebben voor werk en twee mensen die er voor hebben gekozen voor prive gemak.


Dus ligt beetje aan de risico nivo en hoe je er over denkt zeg maar.

[Llopigat]

Ik gebruik ze ook voor mijn wachtwoord manager en SSH logins ja, handiger dan een wachtwoord en veel veiliger.

[Miglow]

Of wat voor werk je doet. Maar ik zou direct afhaken als ik een yubikey moet kopen om een messaging app te gebruiken. Mijn computer gebruik is namelijk 99% hobby en 1% een overheids taakje oid te doen.

[SourceUnknown]

Het is altijd fijn om te lezen wanneer partijen pogingen doen om hun veiligheid en de privacy van hun diensten te verhogen. Helaas is dit in de huidige staat absoluut niet intuïtief en ik vraag me sterk af welk nut het daadwerkelijk dient als de verificatie alsnog een grotendeels handmatig proces is.

Niet alleen moet je het op dit moment zelf bij elk contact uitvoeren, nadat je het groene vinkje krijgt bij de automatische check wordt het safety nummer niet eens automatisch gemarkeerd als "vertrouwd". Dat moet je kennelijk ook nog zelf doen zonder dat dit duidelijk gemaakt wordt. Als je dit niet doet en later hetzelfde contact opnieuw bekijkt zie je nergens of/hoe/wanneer er een eerdere (automatische) verificatie poging is gedaan.

Er is ook nergens beschreven wat er gebeurt wanneer er wel een aanval door het systeem wordt ontdekt van het type waartegen zij zeggen dat dit bescherming biedt. Krijg je dan automatisch een melding? Moet je voor elk verstuurd bericht zelf een nieuwe verificatie doen? Binnen chats of het contact overzicht is in ieder geval nergens een UI-element dat de status van de verificatie in één oogopslag toont.

Ook over de verificatie van je eigen keys is het niet erg duidelijk. Dat zou wel automatisch gebeuren op de achtergrond, maar volgens de documentatie krijg je de volgende melding als er onregelmatigheden worden gedetecteerd:

If the app is unable to verify the log, or finds that not all keys are expected, the user is presented with a warning that “Automatic Key Verification is currently unavailable for your device.”

In welke wereld is dat de tekst die duidelijk zou moeten maken dat je keys gemanipuleerd kunnen zijn. "Currently unavailable" klinkt als een tijdelijke storing, totaal geen indicatie van urgentie.

Al met al voelt dit, in de huidige staat, als een heleboel extra werk voor minimaal praktisch nut voor de eindgebruiker.

[Madelijn]

Daar is Matrix beter in. Daar staat bij twijfelachtige (d.w.z. ongeverifieerde) berichten een schildje. Je kunt ook kiezen geen ontcijferingssleutels te sturen naar ongeverifieerde groepsleden.