Pgp-database ziet grote toename aantal keys sinds NSA-onthullingen

Het aantal geüploade pgp-sleutels naar een van de grootste keyservers op het internet, is sinds de onthullingen van NSA-klokkenluider Edward Snowden flink toegenomen. Het is niet duidelijk of er een oorzakelijk verband is.

Het aantal geüploade public pgp-keys bij de SKS-keyserverpool lag voor de onthullingen van Snowden op een normale dag tussen de 500 en 750, maar na die onthullingen werden er op veel dagen tussen de 1000 en 1500 sleutels geüpload, zo blijkt uit de statistieken van de keyserver. Inmiddels lijkt het aantal nieuw toegevoegde sleutels weer wat af te nemen. In totaal zijn er nu 3,4 miljoen publieke sleutels geüpload naar de database; een jaar geleden waren dat er circa 3,2 miljoen.

Internetgebruikers die hun mail versleutelen via pgp kunnen hun publieke sleutel uploaden naar een keyserver, waar andere gebruikers deze kunnen downloaden. Pgp werkt met een combinatie van publieke sleutels en privésleutels. De publieke sleutel kan met iedereen worden gedeeld, en kan enkel worden gebruikt om mails naar die gebruiker te versleutelen. Voor het ontcijferen van die sleutel moet de privésleutel worden gebruikt; daarom moet die goed worden beschermd.

Reacties (60)

[geez]

Ik heb altijd mijn bedenkingen bij het gebruik van publieke servers voor het uitwisselen van public keys. Er is geen enkele manier om te verifieren dat de public key die je download, ook daadwerkelijk van de persoon is van wie je denkt dat hij is.

Er is niemand die bv. de NSA ervan weerhoudt om de public key te onderscheppen en te wisselen voor hun eigen; waarna alle mail die jij denkt te versleutelen voor jouw contact eigenlijk voor de NSA versleuteld wordt, welke op hun beurt de mail opnieuw kunnen versleutelen en door kunnen sturen naar de bedoelde ontvanger. Soortgelijk aan een man-in-the-middle attack op HTTPS door tussencertificaten te gebruiken (ik denk niet dat de NSA moeite heeft hun certificaten ondertekend te krijgen door bv. Verisign).

Bij elkaar creeert dat een vals gevoel van veiligheid, wat misschien nog wel gevaarlijker is. Daarom wissel ik public keys eigenlijk uitsluitend face-to-face uit (4096bit RSA). Een eventueel alternatief zou kunnen zijn het verifieren van de key via een skype conversatie met webcam en een paar slimme vragen ofzo. Overigens gebruik ik zelf Thunderbird + Enigmail voor mail.

Zie ook: http://arstechnica.com/se...ate-to-keep-the-nsa-away/

@defixje: Je hebt het principe van een man-in-the-middle attack niet helemaal begrepen denk ik. Hoe moet ik als ontvanger van een public key weten dat deze onderweg niet veranderd is zonder het origineel in bezit te hebben? Die probeerden we juist te ontvangen! Als jij een NSA-gegenereerde (of van andere hackers) public key ontvangt, zul jij het verschil niet zien. Je zult de mail encrypten met de NSA key, zij zullen de mail ontsleutelen, lezen, en weer versleutelen met de echte public key van je contactpersoon. Jullie zullen beiden niet weten dat de mail onderweg gelezen is.

@elpino.rv: Je hebt het verkeerd om. De public key wordt gebruikt voor encryptie (dus een mail aan mij versleutel je met mijn public key). De public key dankt zijn naam dan ook aan het feit dat je die vrij kunt verspreiden. Mijn private key, die ik dus niet verspreid, gebruik ik om versleutelde mail aan mij te ontsleutelen.

@HMS: Je hebt in principe gelijk, maar dan ga je er wel vanuit dat jullie beiden een derde key in bezit hebben die identiek is. Zeker geen verkeerde aanname, maar niet foolproof (al moet je ergens een grens leggen, wie zegt dat de Ubuntu image die ik heb gebruikt om mijn systeem te installeren niet gemodificeerd is onderweg).

The usual way this is handled is to get your intended recipient to first send you a mail that's signed but not encrypted. Your mail client will notice the certificate on that mail and plumb it in appropriately so that you can subsequently send encrypted mail to that person.

This introduces some level of risk: is the signed mail you've received really from the person it purports to be from? Certificate authorities are supposed to provide the level of trustworthiness here. For the free certificates, which only include e-mail addresses rather than full identities, this isn't really much to go on. For paid certificates, which are in principle verified by the certificate authority, it is a slightly stronger guarantee. In either case, to be sure of the authenticity of a certificate, it's best to confirm it through some alternative channel (ideally in person).

edit: Paar mooie toevoegingen onderaan nog, waar ik niet allemaal meer op ga reageren Dank voor de aanvulling. WoT is inderdaad een goed systeem om dit risico te verlagen (al draagt (id)init een wat mij betreft relevant bezwaar aan, waar je overigens ook niet omheen komt zonder WoT, tenzij je eigen mailservers gaat gebruiken). Fingerprints vergelijken is wat gebruiksvriendelijker dan de hele key inderdaad, al zullen we er dan vanuit moeten gaan dat bv. de NSA geen betrouwbare collision-generation methode voor o.a. SHA-1 heeft, dat daar bijna uitsluitend voor gebruikt wordt..

[Reactie gewijzigd door geez op 27 juli 2024 10:26]

[Yggdrasil]

Dat is een bekend probleem in public-key cryptografie waar al lang een oplossing voor is. De keyservers zijn alleen bedoeld om gemakkelijk keys op te kunnen halen. In tegenstelling tot de van SSL bekende gecentraliseerde autoriteit van Certificate Authorities, komt de betrouwbaarheid bij GPG/PGP uit het zgn. Web of Trust. Mensen controleren elkaars identiteit fysiek, ondertekenen dan elkaars key (nadat ze de fingerprint hiervan gecontroleerd hebben) en publiceren deze ondertekening ook naar de keyservers.

Als jij een public key download van een keyserver krijg je alle handtekeningen erbij. Jouw lokale GPG-client berekend dan hoe betrouwbaar de identiteit van de opgehaalde key is, op basis van jouw persoonlijke netwerk. Hoe streng hij daarin is bepaal je zelf. Je geeft je oordeel over de betrouwbaarheid (niet als persoon maar als GPG gebruiker) van de GPG-gebruikers die je zelf al ontmoet en ondertekend hebt.

Bijv: Ik wil communiceren met Bob en ken Bob niet persoonlijk. Zijn public-key blijkt ondertekend door Alice, die ik wel ken én waarvan ik redelijk vertrouw dat ze een correcte identificatie van Bob kan uitvoeren. Omdat ik in mijn GPG-client heb ingesteld dat minimaal twee 'redelijke' ondertekeningen nodig zijn is één ondertekening nog niet voldoende om Bobs key te vertrouwen. Het blijkt echter dat ook Henk een ondertekening heeft toegevoegd aan Bobs key. Henk begrijpt goed hoe GPG werkt, en zijn oordeel vertrouw ik volledig. Mijn GPG-client zal daarom Bobs key vertrouwen op basis van Henks oordeel. "Ik heb Henks key zelf gecontroleerd, en als Henk zegt dat Bobs key echt van Bob is dan geloof ik dat". Als Henks ondetekening er niet geweest was dan had ik misschien een tweede persoon die ik 'redelijk' vertrouw nodig gehad om Bobs key te kunnen vertrouwen.

Het web-of-trust is dus vergelijkbaar met hoe mensen onderling elkaar vertrouwen en werkt vrij intuïtief. De software berekend dit voor je dus hoef je niets te doen, behalve je trust in te stellen op de keys van mensen die je persoonlijk kent. Bij ontvangst van een door Bob ondertekend bericht geeft GPG aan of de ondertekening goed is, én of de key van Bob door mij vertrouwd wordt. Op basis van beide feiten kan ik dan besluiten het bericht te vertrouwen.

Een andere uitleg van hoe dit werkt vind je hier: http://www.rubin.ch/pgp/weboftrust.en.html

[HMS]

Je moet dan ook controleren of de key die je download / ontvangt wel door de juiste public key is getekend (een public key die JIJ vertrouwd). Daar is de hele PGP Web of Trust omheen gebouwd.

reactie op edit:
Je kan natuurlijk ook in persoon de fingerprint van de key gaan controleren, en vervolgens met je eigen key de ander zijn key gaan signen. Dat is de makkelijkste manier.

Maar security is nooit fool proof, dus helaas.

[Reactie gewijzigd door HMS op 27 juli 2024 10:26]

[TheBlackbird]

Een PGP public key moet in principe geverifieerd worden door contact met de uitgever ervan: beide partijen vergelijken de fingerprint van de public key met elkaar, zijn die dezelfde, dan weet je dat je naar de juiste persoon een gecodeerd bericht zult sturen.

Voorbeeld 1: Good boy
Persoon X geeft public key uit -> fingerprint ABCDE
Persoon Y downloadt public key van X -> fingerprint ABCDE

X en Y bellen met elkaar en geven de fingerprints door; ze komen overeen => Y is zeker dat hij een gecodeerde boodschap naar X zal sturen

Voorbeeld 2: Bad boy
Persoon X geeft public key uit -> fingerprint ABCDE
Persoon Z geeft public key uit die zich voor doet als X -> fingerprint FGHIJ
Persoon Y downloadt public key van Z (denkt dat het van X is) -> fingerprint FGHIJ

X en Y bellen met elkaar en geven de fingerprints door; ze komen NIET overeen => Y weet dat hij in de luren gelegd wordt.

[collin.]

Inderdaad, je moet de public key verrifiëren. Maar het kan helpen wanneer je een email moet versturen naar een onbekende. Overigens kun je alsnog de fingerprint even checken, ik vraag meestal om (een deel) van de fingerprint terug te krijgen op whatsapp of zo.

Het voordeel van de keyserver is dat je een key kunt "revoken". Daarmee geef je dus aan dat een public key niet langer gebruikt dient te worden. Dit is een stuk handiger dan iedereen de opdracht te geven handmatig jouw sleutel te revoken.

Je kunt een key ook uploaden naar meedere servers, en het kan ook gechecked worden op meerdere servers. Man-in-the-middle wordt hiermee iets lastiger, hoewel zeker niet onmogelijk.

Ja, indien mogelijk moet je de fingerprint via een ander kanaal checken.
Ja, public key servers zijn in theorie vatbaar voor man-in-the-middle (hoewel er geen bewijs is dat dit tot op heden gebeurt is in praktijk naar mijn beste weten).
Nee, het is niet per sé veiliger het per email te versturen (man-in-the-middle is hier waarschijnlijker). Vertrouw liever op een fingerprint check.
Ja, key revoking is een belangrijk hulpmiddel om betrouwbaarheid van public keys te waarborgen.

Key revoking: http://pgp.mit.edu/faq.html

[Reactie gewijzigd door collin. op 27 juli 2024 10:26]

[elpino.rv]

Huh? Volgens mij snap je het principe niet 100%.

Je hebt public en private keys. De private keys gebruik je voor het ENCRYPTEN. Deze moet je altijd in jouw bezit houden (lokaal dus). De public keys worden alleen gebruikt voor het DECRYPTEN.

Het zijn dus assymetrische sleutels. Met de public key kun je niet encrypten en andersom.

-edit- klopt, het is precies andersom.. zoals hierboven en onder wordt gezegd, public=encrypt, private=decrypt

[Reactie gewijzigd door elpino.rv op 27 juli 2024 10:26]

[angelina]

Is toch juist andersom? Public key voor encrypten en private voor decrypten? Want anders kan iedereen decypten met de publiek gemaakte PUBLIC key.

[HMS]

Klopt. Signing doe je dan wel weer met je private key.

[Zoidberg_AvG]

Volgens mij werkt het beide kanten op, dus met de private key kan je iets openen wat met de public key versleuteld is en met de public key kan je iets openen wat met de private key versleutelt is.

met public key encrypten. >> iets wegsturen dat alleen door de eigenaar van een private key geopend kan worden .

met private key encrypten. >> ontvanger kan verifieren of het bericht van de eigenaar van de private key komt. als dat niet het geval is kan hij het niet decrypten met de public key.

[roland83]

Dat is niet helemaal waar. Zie Wikipedia voor een lange uitleg.

Korte uitleg:
* Als ik naar jou een mail stuur, en jij gebruikt ook PGP: ik encrypt met jouw public key mijn mail, waarna jij alleen kunt decrypten met jouw private key.
* Als ik naar jou een mail stuur, en jij gebruikt geen PGP, dan onderteken ik de mail. Die ondertekening is een afgeleide van mijn private key, die te controleren is met mijn public key. Van de ondertekening kun je niet de keys terug afleiden.

Iemand die geen kennis heeft van deze keys, kan een encrypted mail niet ontcijferen.
Een ondertekende mail kan door iedereen worden gecontroleerd. Mijn public key staat in de keyserver-pool. Bovenaan de handtekening staat het e-mailadres en de fingerprint van mijn public/private-key paar, dus dat is het herkenningspunt.

[HMS]

Een signature is in principe gewoon een hash van je bericht die versleuteld is met je private key. Omdat de encryptie van de private key omkeerbaar is met behulp van de bijbehorende public key, kan je dus de hash weer terugkrijgen.

Als de hash die jij berekend, en de hash die verstuurd en versleuteld is overeenkomen dan weet je dus dat er niks aan het bericht veranderd is (aangenomen dat de private key ook echt private is).

[donzz]

je kan beide sleutels gebruiken voor encrypten, je hebt altijd de ander nodig voor decrypten.
situatie 1: ik wil jou een mail sturen die alleen jij kan lezen. Ik encrypt hem met jouw public key, want dan ben ik "zeker" dat alleen jij hem kan decrypten.
situatie 2: ik wil jou een mail sturen en jou "garanderen" dat hij van mij afkomstig is. Ik encrypt hem met mijn private key, zodat jij hem met mijn public key kan decrypten.

Combinaties zijn ook mogelijk natuurlijk.

[defixje]

Tuurlijk weet je dat wel, jij maakt die key en stuurt die zelf toch door naar de gene die die key moet gebruiken? Als er iets veranderd dan zie je toch dat je key niet meer klopt?

[borft]

als de PK die je ontvangen hebt niet de goeie is, kan je de mail die je gekregen hebt niet decrypten (of verifieren), dus dan weet je direct dat de key niet klopt!

[serkoon]

Daarom heb je natuurlijk ook de web-of-trust (WoT) voor PGP, zoals je PKI hebt voor SSL-certificaten.

Via het WoT kun je de betrouwbaarheid van de keys bepalen doordat keys ondertekend worden door anderen. Als jij die anderen vertrouwt, kun je er ook op vertrouwen dat de desbetreffende key daadwerkelijk van de persoon is die bij het e-mailadres hoort.

Daarnaast kun je natuurlijk gewoon de fingerprint van de enkele key verifieren. Degene waarmee je e-mail wil uitwisselen zal die fingerprint op een veilige manier, bijvoorbeeld face-to-face, moeten overhandigen. Je kunt zo'n fingerprint ook bijvoorbeeld op je visitekaartje zetten.

[Verwijderd]

Zodra je PGP keys van een ander gaat ondertekenen gooi je je anonimiteit te grabbel. Iedereen kan dan zien wie met wie een connectie heeft.

Een betere oplossing zou zijn dat je bij email servers een PGP of S/MIME key op kunt vragen van de gebruikers uiteraard alleen via een TLS beveiligde verbinding.

[Reactie gewijzigd door Verwijderd op 27 juli 2024 10:26]

[AVee]

Dat is toch niet wezenlijk anders dan ze bij een keyserver via https opvragen?

[Verwijderd]

keyserver laat zien wie de key heeft ondertekent en is een centrale database.

[Bacchus]

Je belt de persoon die je wilt mailen en vraagt hem de fingerprint van zijn key voor te lezen. Als je de persoon die je probeert te mailen niet kent, moet je je sowieso afvragen wat je aan het beveiligen bent en op basis daarvan bedenken hoe nauwkeurig je weten moet wie er aan de andere kant van je lijn zit.

Bijvoorbeeld: Mensen die ik ken, ken ik niet omdat ik een kopie van hun paspoort heb opgeslagen maar omdat ze zich ooit (in persoon, aan de telefoon, in een mail of op een forum/blog) onder die naam hebben voorgesteld en ik bepaalde eigenschappen (uiterlijk, stem, schrijfstijl) van ze herken. Die eigenschappen zijn het enige dat ik redelijkerwijs kan controleren.

[Spekkie88]

En wat als jij dan als verzender de mail encrypt met de public key van de ontvanger en signed met je eigen key? Op die manier kan de ontvanger dan toch nagaan of er is geprutst met de mail? Of zie ik dat verkeerd?

[Ultraman]

Verstandig om niet blind op de keyserver te vertrouwen.
Al kun je keys die er vandaan komen wel controleren door inderdaad contact op te nemen met de eigenaar en bijvoorbeeld de fingerprint er van te verifiëren.

Als de NSA een key zou onderscheppen en zou vervangen door een key van henzelf, dan zou je dat misschien niet direct opvallen, maar als je een testmail stuurt wel. De NSA heeft immers de private delen van de key niet en dan deze ook niet genereren.
Zodra jij een mail versteuteld met die valse public key kan de ontvanger deze niet oncijferen met zijn private key, maar kan enkel de NSA die mail ontcijferen. Voor een signature geldt eigenlijk hetzelfde, maar dan precies de andere kant op.

Als ze echt alle infrastructuur er tussen beheren, mja misschien dat het dan zou lukken. Mits jullie twee niet de fingerprint van elkaars key hebben uitgewisseld en controleren. Zo te zien doe jij dat wel, dus dan lukt dit truukje al niet.

Dit is ook de reden waarom je met het signen van elkaar keys dit face-to-face wilt doen. Waarmee je aangeeft dat je een key van de ander vertrouwd, als in dat je zeker weet dat je juiste persoon er achter zit.

Ooit op een key signing party geweest?
Mag je je ID en fingerprints enzo meenemen.

[Reactie gewijzigd door Ultraman op 27 juli 2024 10:26]

[thunder7]

Dat hangt van je mailprogramma af. Is dat Mutt met een grote hoeveelheid macro's, of Emacs, dan gaat het automatisch. Windows-gebruikers lopen volgens mij wat achter. Lees je eens in, bv. op http://www.gpg4win.org voor een gratis windows-programma

[sfranken]

Mail lezen met emacs? Weet je dat zeker dat dat kan aangezien het een editor is...

[magistus]

Emacs is alles behalve een editor
http://www.emacswiki.org/emacs/CategoryMail

[sfranken]

Emacs is wel degelijk een editor.. met zo'n beetje alles als plugin. Daarom ook vaak het gootsteen icoon..

Dat mail mogelijk was wist ik écht niet.

[Phyxion]

http://www.postbox-inc.com/extensions

Postbox (ook voor Windows) heeft gewoon een plugin beschikbaar voor PGP Lijkt mij ook gewoon voor Thunderbird beschikbaar te zijn aangezien de engine hetzelfde is als Postbox.

Outlook (ook voor Windows ) heeft ook een PGP plugin beschikbaar, o.a.
http://code.google.com/p/outlook-privacy-plugin/

[mbb]

Het probleem is dat het pas voor het grote publiek kan doorbreken als er een outlook(express) extensie voor de zakelijke markt, en een browser-plug-in voor webmail is, tot die tijd moet er of met proxy-mail-servers geklooid worden en
-
net gekeken, er bestaan Firefox-plug-ins, zoals deze
https://addons.mozilla.or...webpg-firefox/?src=search
(maar hoe verifieer je daar nu weer de betrouwbaarheid van? )

[TheNephilim]

Heb me vaker afgevraagd wat OpenPGP nu inhield, maar ik snap het nu eindelijk. Dank voor de uitleg!

Het wel of niet samenhangen met de onthullingen vind ik minder interessant. Ik neem aan dat je je mail continue versleuteld en niet alleen als je zoiets dergelijks verstuurd.

[roland83]

Je versleutelt alleen mail naar iemand die ook PGP gebruikt. De sleutel om te versleutelen is (zoals in het artikel al staat) de publieke sleutel van de ontvanger. Dus niet die van jezelf.

Als je mail stuurt naar iemand die geen PGP gebruikt, dan kun je je mail ondertekenen met je eigen private key. De ontvanger kan met jouw publieke sleutel vervolgens controleren of er niets aan de e-mail is veranderd onderweg. Alles is plain-text (de signatures, maar ook de keys).

Ik kan me voorstellen dat er mensen zijn die iets meer bescherming willen. In Nederland hoef je voor zover ik me goed kan herinneren je private key nooit gedwongen prijs te geven, bijvoorbeeld als je ergens van wordt verdacht.

De algoritmes die voor PGP worden gebruikt zijn zodanig sterk, dat het zonder de juiste private keys serieus tijd kost om alle encrypted e-mails te willen ontsleutelen.

[Verwijderd]

Als je mail stuurt naar iemand die geen PGP gebruikt, dan kun je je mail ondertekenen met je eigen private key. De ontvanger kan met jouw publieke sleutel vervolgens controleren of er niets aan de e-mail is veranderd onderweg. Alles is plain-text (de signatures, maar ook de keys).

En voor de goede orde: (uit de tekst begrijp ik dat jij je dat realiseert, maar dat zal wellicht niet voor iedereen duidelijk zijn.)
De verzonden mail kan in dat geval indien onderschept gewoon worden gelezen; de benodigde publieke sleutel is immers gewoon beschikbaar.

[Ultraman]

Die verzonden mail kan zonder sleutel ook prima worden gelezen. Je praat namelijk over een mail die enkel gesigneerd is. Er wordt aan de email dan enkel een soort van checksum toegevoegd, het signatuur, die gecontroleerd kan worden op correctheid met de publieke key van de zender.
Met de inhoud van de mail gebeurt niks op zo'n moment, dat is een doodnormale email, waar een signatuur, vaak als attachment, is toegevoegd.

Wanneer je email ook versleuteld wordt pas de plain text in de email verhaspeld tot onleesbare tekst, die enkel nog te ontcijferen is met de private key van de geaddresseerde.
De mail is dan tijdens verzender versleuteld met de public key van de geaddresseerde, welke enkel "ongedaan" kan worden gemaakt met de private key van die geaddresseerd.

Om de encryptie met public&private keys uit te leggen aan de hand van een voorbeeld:
Jan en Klaas hebben een koffertje waarmee ze spullen tussen elkaar willen uitwisselen door dat koffertje naar elkaar toe te sturen. Maar ze willen dat niemand zomaar in de koffer kan kijken -> er moet dus een slot op dat koffertje.
Dus ze kopen een hangslot, maar dan volgt er een probleem. Hoe voorkomen ze dat ze telkens ergens moeten afspreken om of de koffer, of de sleutel uit te wisselen? Ze willen dat niet, wie weet wonen ze wel tig uur rijden van elkaar vandaan.
Hoe lossen ze dat op?
Ze kopen allebei een hangslot.
Zo'n slot bestaat, wel bekend waarschijnlijk, uit het hangslot en een sleutel.
Ze spreken een keer af en wisselen de hangsloten uit, in open staat, terwijl ze wel zelf hun eigen sleuteltje houden.
Nu wil Jan iets naar Klaas sturen. Jan stopt de geheime inhoud in de koffer en sluit deze. Daarna drukt hij het slot van Klaas er op en stuurt de koffer met de post naar Klaas.
-dag later-
De koffer komt bij Klaas aan. Die kan het slot open maken met zijn sleutel en dan bij de inhoud van de koffer komen.
Voor het terugsturen doet Klaas precies hetzelfde als Jan, maar dan drukt hij het slot van Jan er op. (en hij stopt zijn eigen slot weer geopend er bij in de koffer, zodat Jan die later weer terug kan sturen met de koffer).

In dit verhaal zijn de hangsloten de publieke keys, en de sleuteltjes van de hangsloten de private keys.
Klaas en Jan hebben elkaars publieke key en versleutelen met die publieke key van de ander de "koffer". Die "koffer" kan dan enkel geopend worden met de private key van de ontvangende partij. Een sleutel die niemand anders dus heeft.

Duidelijk?

[Reactie gewijzigd door Ultraman op 27 juli 2024 10:26]

[roland83]

De mail kan inderdaad gewoon worden gelezen als deze wordt onderschept.

De beschikbaarheid van de publieke sleutel is hierbij echter niet relevant. De mail is alleen maar ondertekend met de pgp-sleutel. De mail bestaat dan uit het mailbericht, met de ondertekening als attachment (meestal met naam signature.asc).

De ondertekening geeft dus geen uitsluitsel of de mail onderschept is, maar geeft wel zekerheid dat er niet aan geknoeid is onderweg. Als de signature dus niet te verifieren is met met de public key van de verzender, dan moet je als ontvanger achter de oren krabben.

[Reactie gewijzigd door roland83 op 27 juli 2024 10:26]

[Mr_gadget]

Maar de vraag is of hij hiervoor niet een door de NSA met backdoor uitgerust algoritme gebruikt?

Maar stom eigenlijk dat thunderbird oid. hier geen support voor heeft, je kan het makkelijk zo maken dat ie gelijk even checkt op een keyserver of iemand een publieke key heeft.

EDIT: zo te zien kan het wel maar je moet wel zelf de key opzoeken...
https://support.mozillame...g-and-encrypting-messages

[Reactie gewijzigd door Mr_gadget op 27 juli 2024 10:26]

[Fermion]

Dat de algoritmes zo goed zijn, zal wel de reden zijn dat MS ze niet gebruikt? Maar anders, dan had NSA wel weer een oplossing op gevonden.

[kramer65]

Jij weet niet wat PGP is, maar neemt wel aan dat iedereen zijn mail continue versleuteld?

Ik ben er ook wel eens mee bezig geweest, maar mijn ervaringen ermee zijn als "moeizaam" te beschrijven. Wat ik vooral niet begrijp is dat bestaande mail programma's geen optie hebben om bij elke verzonden mail automatisch in de key-DB te kijken en als er een public key voor is, de mail automatisch te versleutelen.

Of bestaat dat inmiddels al wel?

[Ultraman]

Dat kan al tijden , in ieder geval met de software die ik gebruik, en zo uit mijn hoofd gebruik ik die al sinds 2011. En dat is geen bijzonder spul, namelijk: Thunderbird met de Enigmail add-on, welke OpenPGP support naadloos toevoegt.

Ik kan voor een email adres kiezen of mailverkeer met dat adres gesigneerd en/of versleuteld moet worden. Die opties worden dan automatisch voor mij ingeschakeld.

Standaard signeer ik al mijn mail, dus die staat voor alles standaard aan. Dat is zodat de authenticiteit van mijn mail te controleren valt. Iemand die geen PGP/GPG gebruikt merkt daar vrijwel niets van, er hangt enkel een attachment aan de mail genaamd "signature.asc".
Voor de contactpersonen waarvan ik weet dat ze PGP/GPG gebruiken, en ik hun public keys (dus) ook heb, wordt automatisch encryptie ingeschakeld.

PGP/GPG encryptie gaan gebruiken is in den beginne een handmatig iets. Je moet namelijk je keypair aanmaken, dat is gelukkig in een paar minuutjes gepiept. Ook wil je je even inlezen in de best practices rondom PGP/GPG. Eventueel nog een add-on installeren voor je mail client en die inschakelen voor jouw keypair, heeft Enigmail een prima wizard voor, is ook weer minutenwerk.

Als dat eenmaal staat dan kun je gewoon emailen alsof je dat altijd doet, met de extra opties om dus te signeren en/of versleutelen. Gaanderweg kun je mensen die ook PGP/GPG gebruiken toevoegen aan je keyring en voor die mensen de optie om altijd de versleutelen bijvoorbeeld inschakelen.
En waarschijnlijk wil je nog iets van een agent/tooltje configureren dat je niet zo vaak je passphrase in hoeft te vullen, bijvoorbeeld door je keyring aan je sessielogin te koppelen. Daar zijn meerdere manieren voor.

Ik versleutel dus lang niet al mijn mail. Integendeel, ik versleutel vrij weinig mail omdat ik niet veel contactpersonen heb die een PGP/GPG key hebben en gebruiken. Wel zijn het er de afgelopen periode iets meer geworden, en dan met name aan de zakelijke kant.
Denk ook aan logins voor machines e.d., daar wordt door een aantal mensen ook voorzichtiger mee gedaan.

Toevallig ben ik bezig met een blog over het aanmaken van GPG keys, gebruik van subkeys en een voorbeeld van gebruik. Met eventueel als follow-up een stukje over het signen van andersmans keys en je eigen key gesigned krijgen door anderen, zodat je web of trust groter wordt.
Als je dat interessant vind mag je me een DM/email sturen, dan stuur ik wel een berichtje terug zodra ik iets gepubliceerd heb.

[TheNephilim]

Nee, mijn punt was, dat als je toch al gevoelige informatie verzend. Je al je mail versleuteld verzend. Tenminste, anders is er altijd het risico dat je eens iets niet versleuteld.

Als ik jou begrijp, is het allemaal een handmatig gebeuren. Erg onhandig lijkt me inderdaad

[roland83]

Het is inderdaad een redelijk handmatig gebeuren, maar er zijn genoeg plugins voor browsers en mailprogramma's die PGP-handelingen automatisch voor je doen.

[Verwijderd]

Het blijft een geklungel om het allemaal te configureren.

[janrotterdam]

@ twop
Om over het aantal oogbewegingen nog maar te zwijgen inderdaad.

[Reactie gewijzigd door janrotterdam op 27 juli 2024 10:26]

[Dorank]

Wat ik vooral niet begrijp is dat bestaande mail programma's geen optie hebben om bij elke verzonden mail automatisch in de key-DB te kijken en als er een public key voor is, de mail automatisch te versleutelen.

Automatisch versleutelen met keys gevonden in een directory heeft geen toegevoegde waarde, je weet immers niet of dat wel de echte publieke sleutel is. Je weet ten eerste al niet of je met een legitieme keyserver praat, dat kan je wellicht ondervangen door met verschillende servers te verbinden.

Maar iedereen kan een sleutel aanmaken met een willekeurig emailadres en die publiceren. Dat is weer ondervangen door (wederzijds) signing van publieke sleutels, maar dat kan je alleen doen indien je daadwerkelijk weet dat een sleutel bij een persoon/emailadres hoort (zie key siging partys).Een onbekende sleutel is alleen zinnig in er een web of trust is met een direct pad (immers als je al bezig bent met keys faken, dan zet je ook een WoT op).

[woutersamaey]

Moeten ontvangers van je e-mail iets bijzonder doen om je mail te kunnen lezen, of doet het mailprogramma alles automatisch?

[i7x]

Ja, ontvangers moeten het bericht ontsleutelen. Alleen zij kunnen dat en dat is ook de hele kracht er achter. Er zijn wel programma's/plug-ins die dit vereenvoudigen maar lukraak PGP emails gaan versturen gaat niet werken. Je zult de public keys van de ontvangers nodig hebben en ook zij hebben een programma nodig om vervolgens de binnenkomende mail te ontsleutelen.

Wellicht veel te veel werk voor een hoop mensen, maar als het om privé mailen gaat is PGP-versleuteling echt een uitkomst. De ervaring heeft ons mogen leren dat anonieme email providers eigenlijk niet bestaan of anders op zijn minst erg onstabiel zijn (bijv. sluiting door nieuwe regelgeving of simpelweg sites die worden neergehaald door overheden).

Zorg er alleen wel voor dat je geen gebruik maakt van mailsites waarbij je je private key (dus niet de key waarover het in dit artikel gaat) kunt uploaden om het gebruik "gemakkelijker te maken". Je private key is het belangrijkste onderdeel van de veiligheid van PGP en dien je nooit uit handen te geven.

Als je echt paranoide bent en bonuspunten wilt verdienen prop je vervolgens ook nog eens de hele handel in een TrueCrypt container of draai je het binnen een virtuele machine.

[Reactie gewijzigd door i7x op 27 juli 2024 10:26]

[martijnvanegdom]

Op de Mac met Mail kun je gpgtools gebruiken (https://gpgtools.org) daar gaat vrijwel alles automatisch. Je kunt gewoon je mail lezen en gebruiken. Als je naar e-mail mailt zonder key in de database word de e-mail gesigneerd anders automatisch versleuteld.

Enige nadeel is dat er vrijwel geen webmail client is die het ondersteunt.

[wootah]

Met een chrome plugin gaat dat prima met gmail:
https://chrome.google.com...dnlpmopmjhijplpjhlplfkhba
Werkt vrij eenvoudig

[Verwijderd]

Ehm. En dan versleutel je je email om het vervolgens bij Google op de server te zetten? Dat lijkt me toch een duidelijk gevalletje van het privacybeleid van Google écht niet begrepen hebben...

[wootah]

Volgens mij is dit een duidelijk gevalletje van te snel conclusies trekken.

Alle encryptie decryptie loopt via de browser: "The project is powered by OpenPGP.js", javascript dus.
Keys worden alleen lokaal op je pc opgeslagen, Google heeft dus helemaal niks met je encryptie te maken.

Als OpenPGP zijn werk dus goed doet kan niemand en lezen behalve de persoon waarvoor het bedoeld is.

[cyberstalker]

Waarmee natuurlijk wel één van de voordelen van webmail wegvalt: overal even snel je mail kunnen checken.

Je kunt dan je mail niet lezen op een computer waar niet:
- de plugin is geïnstalleerd
- jouw key niet bekend is.

Je zult die key dus overal moeten gaan importeren waar jij je mail wilt lezen. Op die manier is je privacy ook al redelijk weg. Hoe ga je die key overal naartoe meenemen? Op een usb-stick? Schrijf je die uit op papier om die steeds met de hand uit te typen? Heeft de computer waarop je typt niet stieken een keylogger?

[wootah]

Waarmee natuurlijk wel één van de voordelen van webmail wegvalt: overal even snel je mail kunnen checken.

Een van de voordelen is dat je niet allerlei mail-clients hoeft te installeren met vervelende eigenschappen. Ook hoef je niet al je contacten te synchroniseren, enz. enz.

Dat ik niet overal kan PGP-en is helemaal niet erg, dat kan anders namelijk ook niet zo eenvoudig.

[Barryke]

Als Google, een MITM (man in the middle) of iemand met toegang tot je PC dat wil, kan die vast een extra stukkje JS injecteren in die browser pagina/sessie wat jouw sleutel kan ophoesten.. niets is veilig.

Simpeler is beter, als het zo belangrijk is, gewoon niet emailen.

[Reactie gewijzigd door Barryke op 27 juli 2024 10:26]

[markusclaas]

Google wel, maar niet een MITM. De verbinding naar Google is namelijk over https. Daar kan niet zo maar iemand tussenin wat javascript doorheen mengen.

[batjes]

Google is de mitm in dit geval.

[Barryke]

Dat kan wel, zeker als ze ertussenin zitten.
Een MITM omzeilt liever het hele kraken van https meteen:

1) Het stukje dat ze invoegen kan prima zonder https in je pagina belanden, browsers (of gebruikers die de popup wegklikken) slikken dit.
2) Het stuk dat ze invoegen kan via https worden ingevoegt door gebruik te maken van een slecht ontworpen/beveiligde pagina op de host, die hun stuk ophoest tussen wat AJAX tbv het weerbericht bijvoorbeeld.
3) Een vals certificaat doorgeven richting gebruiker is prima mogelijk. Dit is waarom diginotar gehackt was. Misschien wel door de NSA, zoals al gezegd wordt..
4) Https handshake afvangen en toch kraken, het algoritme komt immers van de NSA en die zullen wel een betere kansberekening kunnen doen dan een rainbowtable, ik zal je de details besparen.
5) Data invoegen door voor of achter de https verbinding te gaan zitten aan de kant van Google of je Browser, ipv ertussen. (al valt dat misschien onder iemand met toegang tot je PC, dat is betwistbaar)

Om maar wat te noemen.

[HMS]

Jammer dat er alleen betaalde PGP support voor Outlook is, een gratis open source oplossing zou het een stuk makkelijker maken om het te gaan gebruiken.

Natuurlijk kan je met Outlook wel S/MIME gebruiken, maar PGP heeft mijn voorkeur.

Daarnaast gebruikt werkelijk niemand e-mail encryptie, helaas. Ik zeg het vaak genoeg, zet geen dingen in je e-mail die je ook niet op de achterkant van een ansichtkaart zou sturen.

[Bacchus]

Eigenlijk vind ik het ontbreken van encryptie (het onleesbaar maken) niet zo'n probleem, ik mis de ondertekening (authenticatie en onweerlegbaarheid) in de praktijk veel meer. Niemand schijnt door te hebben hoe kinderlijk eenvoudig het is om een mail onderweg aan te passen of er een uit iemand anders zijn naam te sturen.

[regmaster]

Al die mensen die nu ineens PGP gaan gebruiken trekken juist de aandacht omdat hun gedrag afwijkt van hetgeen 'normaal' is. Beter is het om in de grote massa te blijven opgaan, dan val je minder op.

Zelf gebruik ik alleen 7-Zip om vertrouwelijke informatie uit te wisselen. Ik comprimeer en versleutel een tekstbestand, inclusief eventuele andere bestanden off-line met een sterk wachtwoord, Dat wachtwoord sms of bel door naar de ontvanger. Met een aantal ontvangers heb ik vaste wachtwoorden afgesproken die in onze KeepassX database staan opgeslagen dus daarmee hoef ik niet meer mee te communiceren. Daarna mail ik het versleutelde zip naar de ontvanger als een willekeurig genoemd attachment, bijvoorbeeld recept.docx o.i.d.. Zo lijkt het een reguliere mail die dus verder niet opvalt bij allerlei 'luister- of mee lees vinkjes.

[gekkie]

Behalve dan dat als ik door heb wat je doet .. ik jouw methode verdachter vind .. omdat je het niet alleen probeert te versleutelen maar ook nog probeert te verbergen :-)

[jGS]

Gebruiken ze dan nu een ander type/grootte key of niet? Dat is de vraag natuurlijk!

[Ultraman]

Aan PGP/GPG zelf als standaard is bij mijn weten niks veranderd die maand.

Maar het zou kunnen zijn dan mensen die hiervan al gebruik maakten hun sleutels versterkt hebben. Bijvoorbeeld een nieuwe key gemaakt van 4096 bits ipv 1024 of 2048 (<- huidig aanbevolen minimum). Zo heeft bekende cryptografiedeskundige Bruce Scheier recent zijn oude keys vervangen voor nieuwe van 4096 bits sterk.

Mogelijk heeft dat ook invloed gehad op de statistieken.

[sumac]

Wat ik uit deze discussie lees is vooral: héééééél veel verwarring over wat encryptie nu is.

Persoon A zegt dit, persoon B zegt dat A het verkeerd begrepen heeft, en vervolgens is het aan de lezer om uit te maken wie gelijk heeft.