Software-update: Gpg4win 4.2.0

Versie 4.2.0 van Gpg4win is uitgekomen. Met dit programma kan een stukje zekerheid aan het versturen van e-mails en bestanden worden toegevoegd. Zo kunnen deze worden versleuteld met OpenPGP of S/MIME. Daarnaast kan aan de hand van een digitale handtekening zowel de integriteit van de bestanden of e-mails, als de afzender worden geverifieerd. Om dit alles te bewerkstelligen maakt Gpg4win gebruik van een aantal externe programma's zoals GnuPG, Kleopatra, GpgOL en GpgEX. De changelog voor deze uitgave kan hieronder worden gevonden.

Changes in version 4.2.0:

• Okular (GnuPG Edition): Gpg4win has been extended with the popular Okular PDF Viewer. Although our Okular version is currently considered experimental and therefore not installed by default, this provides the ability to legally sign and verify documents with the S/MIME certificates and smart cards GnuPG supports. The GnuPG Edition of Okular is optimized to be lightweight and to provide as little attack surface as possible. It does not support any active content like JavaScript or media files in PDF documents. It should therefore be more suitable in high security environments than other PDF readers. See here.
• GnuPG: The new component "keyboxd" is now enabled by default for new users of Gpg4win. keyboxd stores certificates (public keys) in an sqlite database and keeps it in memory. The resulting performance improvement can be quite large especially for users with large keyrings. Adventuresome users can enable it manually: Select all certificates in Kleopatra and export them with a right click. Add a file %APPDATA%\gnupg\common.conf with the contents "use-keyboxd" (without the quote marks), then restart Kleopatra and import your certificates again. As usual we caution to make a backup of the %APPDATA%\gnupg directory before modifying files in there. To switch back to the old behavior, add a "#" character in front of the "use-keyboxd" and restart Kleopatra. Where applicable you have to export the certificate before and import them again after the restart.
• mkportable has been removed. Please see here on how to create a portable version of Gpg4win.
• Kleopatra: Folder encryption and decryption (gpgtar) has been completely reworked so that it now has roughly the same performance as on the command line. The new architecture also allows for further performance improvements in the future and is much more robust. And solves several issues. [T5478 T6488 T6499 et.al.]
• Kleopatra: The progress indicator now also works for very large data files. [T6534]
• Kleopatra: It is now possible to rename the output file, if a file with the same name already exists, instead of just overwriting or canceling. [T6372]
• Kleopatra: It is now offered to delete the secret key on the computer after it was successfully transferred to a smart card. [T5836]
• Kleopatra: Added warnings when your certificate or other certificates in your keyring are about to expire. The warnings are configurable and should allow a smoother switch to a new or extended certificate. [T6452]
• Kleopatra: The Notepad now also uses the last chosen certificates for signing and self-encryption as default. The values are shared with file encryption.[T6415]
• Kleopatra: The startup time of Kleopatra has been slightly improved. [T6259]
• Kleopatra: The certificate selection input and dropdown fields are now alphabetically sorted. [T6492, T6514]
• Kleopatra: Backed up subkeys can now be restored through the UI even when they were used from a smart card in between. [T3456, T3391]
• Kleopatra: For certifications of public keys it is now possible to configure a default validity period. [T6452]
• Kleopatra: When extending the validity period of a certificate, the default for new ones is now preset. [T6479]
• Kleopatra: The default validity of new certificates is now three years instead of two. This can be changed through configuration. [T2701]
• GpgOL: Now offers to create a OpenPGP certificate, if none with signing capability exists and only signing is requested. [T5869]
• GnuPG: The PKCS#12 (.p12 files) parser has been rewritten to increase compatibility with other PKCS#12 implementations. [T6536]
• GnuPG: S/MIME certificate listings have been sped up on Windows. [rG08ff55bd44]
• GnuPG: A new option "ADSK" has been added to signal the intention that messages should be encrypted to multiple subkeys. [T6395, more info]
• GnuPG: There are now more compressed formats detected for which GnuPG then automatically disables its builtin compression. This can result in significant speed ups. [T6332]
• Kleopatra: An accidental timeout when creating checksum files has been removed. This could result in empty or incomplete checksum files. [T6573]
• Kleopatra: The validity period of all subkeys is now extended even if the primary key was already expired. This fixes the case where seemingly extended keys were no longer usable for encryption. [T6473]
• Kleopatra: A rare occurrence, where encryption only keys would be offered as signing keys, has been fixed. [T6456]
• Kleopatra: Some obsolete configuration options have been removed. [T6326 T6327]
• Kleopatra: The button "What's this" in the right upper corner has been removed, since it was only used in very few places. [T6318]
• Kleopatra: Canceling file operations now reliably cancels the underlying backend operations, too. [T6524]
• Kleopatra: A number of encoding problems when displaying output from the backend have been solved. [T5960]
• Kleopatra: A cause for longer loading time of the certificate list at startup was fixed. [T6261]
• Kleopatra: Selecting cancel when exporting a secret subkey now properly cancels instead of creating a file without the secret part. [T5755]
• Kleopatra: When importing secret keys you do not want to mark as your own, it is no longer asked multiple times if it is your own key. [T6474]
• GnuPG/Kleopatra: Error handling for permission and write errors has been improved across the board. [T6528]
• GpgOL: An issue has been fixed where crypto mails would show up empty if text/plain display was preferred. [T6357]
• GpgOL: Fixed a crash that occurred when encrypting a mail with an attachment without a file name. [T6546]
• GpgOL: Category and flag changes now work again if the mail is not displayed in a decrypted state when they are made. [T4127]
• GpgOL: Added safeguards against a plain text leak back to the server in a specific unusual configuration. (dd3ff839)
• GnuPG: For a full list of the backend changes between GnuPG 2.4.0 in Gpg4win-4.1.0 and GnuPG 2.4.3 in Gpg4win-4.2.0 please see: 2.4.1, 2.4.2 and 2.4.3.
• GnuPG: 2.4.3
• Kleopatra: 3.1.28
• Okular: 23.07.70-patched
• GpgOL: 2.5.8
• GpgEX: 1.0.9
• Kompendium DE: 4.0.1
• Compendium EN: 3.0.0

Versienummer	4.2.0
Releasestatus	Final
Besturingssystemen	Windows 7, Windows 8, Windows 10, Windows 11
Website	Gpg4win
Download	https://www.gpg4win.org/get-gpg4win.html
Bestandsgrootte	33,28MB
Licentietype	GPL

Reacties (12)

[Ozymandias]

Het is nog altijd lastig in het dagelijkse gebruik, daarom worden de meeste mails nog steeds in plaintext verstuurd. Maar of dit een probleem is?

[novice.tweaker]

Het is nog altijd lastig in het dagelijkse gebruik, daarom worden de meeste mails nog steeds in plaintext verstuurd. Maar of dit een probleem is?

Het probleem zit denk ik meer in hoeverre men ervan bewust is en wat dat in de praktijk betekent.
Overigens wordt het wel steeds makkelijker. In protonmail bijvoorbeeld wordt het standaard gebruikt in e-mailverkeer tussen protonmail-gebruikers onderling. In Thunderbird is de mogelijkheid inmiddels geïntegreerd en in veel webmails, zo niet de meeste, is ondersteuning ervoor ook aanwezig. Het zal eens tijd worden ook, de technologie is al eeuwen oud in IT-begrippen.

[FrostyPeet]

GPG/PGP is een oud systeem wat "vroeger" door de "nerds" werd gebruikt. De mensen die nog met een command prompt konden omgaan. De tijd van de cyberknight versie van PGP die belachelijke sleutels aan kon (8K lang, terwijl 2048 bits al als "zeer veilig" werd beschouwd).

Het heeft altijd twee problemen gehad.
1) Het uitwisselen/vinden van de juiste publieke sleutel. Gingen trollen een sleutel kamen van het white house etc. De publieke sleutelservers, b.v. die van MIT die plat lag of missende sleutels.
2) Het is een lastig te gebruiken systeem tenzij je precies weet wat je doet. Dat mensen hun private key stuurden, want ik wil iets privé naar je sturen. De uitleg van Edward Snowden naar die journalist met al die plaatjes en lappen tekst is legendarisch. Die journalist had zoiets van "daar begin ik niet aan". De rest is geschiedenis.

GPG/PGP is altijd wel in de "nerd" hoek blijven hangen, van systeembeheerders en mensen die het wel "moesten" gebruiken (mensenrechten clubs).

Ik heb het idee dat de meesten wel zijn overgestapt op een E2EE chat systeem (zeg maar de Signals), wat gewoon "simpel" werkt voor een leek.

[Verwijderd]

Ozymandias schreef:

Het is nog altijd lastig in het dagelijkse gebruik, daarom worden de meeste mails nog steeds in plaintext verstuurd. Maar of dit een probleem is?

Soms - alhoewel.

Omdat er mails met vervalste afzender worden verzonden, is het van belang dat je redelijk zeker weet dat de afzenders, van mails die jij ontvangt, niet vervalst zijn.

Dat kan met een digitale handtekening. Een essentiële voorwaarde daarvoor, die bijna niemand goed begrijpt, is dat je zeker weet dat de public key, waarmee je een digitale handtekening verifieert (om de authenticiteit en integriteit van het bericht vast te stellen), daadwerkelijk van de betrokkene is - en dat die betrokkene diens private key strikt geheim houdt.

Een kwaadwillende kan echter "onderweg" zo'n bericht wijzigen en de digitale handtekening verwijderen. Als het jou niet opvalt dat een ontvangen e-mail niet digitaal is ondertekend (terwijl dat wel gebruikelijk is), heeft zo'n systeem geen zin.

Om deze reden (de "alhoewel" waar ik mee begon) kan het verstandig zijn om e-mails, naast ze digitaal te ondertekenen, tevens te versleutelen - ook als de inhoud niet vertrouwelijk is.

Een nadeel van versleutelde mails is dat mailservers er geen spam en malware in kunnen detecteren. Daar komt bij dat de meeste mensen niet snappen dat je een public key niet gewoon kunt mailen en zonder checks gebruiken.

In theorie is het een mooi systeem, in de praktijk nauwelijks bruikbaar; het is te vaak schijnveiligheid.

[novice.tweaker]

Dat kan met een digitale handtekening. Een essentiële voorwaarde daarvoor, die bijna niemand goed begrijpt, is dat je zeker weet dat de public key, waarmee je een digitale handtekening verifieert (om de authenticiteit en integriteit van het bericht vast te stellen), daadwerkelijk van de betrokkene is -

Hoezo? De verificatie zal falen als de public key niet de juiste is.

- en dat die betrokkene diens private key strikt geheim houdt.

En een nieuwe maakt indien de private key is uitgelekt, of gewoon na verloop van tijd.

Een kwaadwillende kan echter "onderweg" zo'n bericht wijzigen en de digitale handtekening verwijderen. Als het jou niet opvalt dat een ontvangen e-mail niet digitaal is ondertekend (terwijl dat wel gebruikelijk is), heeft zo'n systeem geen zin.

Dat is een waarheid als een koe. Als je het niet opmerkt, heeft het inderdaad geen zin gehad in dat geval. Heb je het wel opgemerkt, dan heeft het wel zin gehad. En je hebt in elk geval de mogelijkheid het te controleren, in die zin heeft het altijd zin.

Daar komt bij dat de meeste mensen niet snappen dat je een public key niet gewoon kunt mailen en zonder checks gebruiken.

In principe kan je een public key gewoon mailen. De ontvanger zal zelf moeten aangeven hoe betrouwbaar die sleutel is en eventueel de sleutel controleren. Doet de ontvanger die controle niet, dan is er alleen een probleem als de communicatie al gecompromitteerd was en een andere key was ontvangen en alle communicatie erna ook onderschept en aangepast wordt om de illusie te scheppen dat er niks mis is met de communicatiestroom.

In theorie is het een mooi systeem, in de praktijk nauwelijks bruikbaar; het is te vaak schijnveiligheid.

Heeft https in plaats van http ook geen zin? En heeft een fietsslot ook geen zin omdat je fiets toch gestolen kan worden? Of een slot op de deur van je woning?

[Verwijderd]

Ik schreef:

Omdat er mails met vervalste afzender worden verzonden, is het van belang dat je redelijk zeker weet dat de afzenders, van mails die jij ontvangt, niet vervalst zijn.

Dat kan met een digitale handtekening. Een essentiële voorwaarde daarvoor, die bijna niemand goed begrijpt, is dat je zeker weet dat de public key, waarmee je een digitale handtekening verifieert (om de authenticiteit en integriteit van het bericht vast te stellen), daadwerkelijk van de betrokkene is - en dat die betrokkene diens private key strikt geheim houdt.

Dat novice.tweaker beantwoordde met::

Hoezo? De verificatie zal falen als de public key niet de juiste is.

Dat blinde vertrouwen is precies het probleem.

Bijvoorbeeld op keyservers kun je public keys vinden die niet van de geclaimde eigenaar zijn. Die geclaimde eigenaar kan ze niet eens verwijderen.

Als een scammer jou een gesigneerde mail stuurt met een verwijzing naar zo'n fake key, of jou een "nieuwe" public key mailt omdat er iets met de oude zou zijn, heb je niks anders dan schijnveiligheid.

Voorwaarde van de betrouwbaarheid van public keys is dat je, via een ander, voldoende betrouwbaar kanaal, verifieert dat een public key van de geclaimde eigenaar is. Probleem: bijna niemand doet dat.

Ik ging verder met:

- en dat die betrokkene diens private key strikt geheim houdt.

Waarop novice.tweaker schreef:

En een nieuwe maakt indien de private key is uitgelekt, of gewoon na verloop van tijd.

Waarop gebruikers van de nieuwe public key opnieuw zullen moeten checken dat die nieuwe public key niet van een bedrieger is.

Ik schreef:

Een kwaadwillende kan echter "onderweg" zo'n bericht wijzigen en de digitale handtekening verwijderen. Als het jou niet opvalt dat een ontvangen e-mail niet digitaal is ondertekend (terwijl dat wel gebruikelijk is), heeft zo'n systeem geen zin.

novice.tweaker schreef:

Dat is een waarheid als een koe. Als je het niet opmerkt, heeft het inderdaad geen zin gehad in dat geval.

Niet "geen zin gehad', maar je bent om de tuin geleid. Meestal bewust. Mogelijk met een malware-bijlage of een link naar een phishing site.

Ik schreef:

Daar komt bij dat de meeste mensen niet snappen dat je een public key niet gewoon kunt mailen en zonder checks gebruiken.

novice.tweaker schreef:

In principe kan je een public key gewoon mailen. De ontvanger zal zelf moeten aangeven hoe betrouwbaar die sleutel is en eventueel de sleutel controleren.

Niet "eventueel". Als je van een gemailde public key niet op betrouwbare wijze (via een veilig "kanaal" of, bij voorkeur, "in person") vaststelt dat deze van de geclaimde eigenaar is, maak je e-mail niet betrouwbaarder, maar onbetrouwbaarder.

novice.tweaker schreef:

Doet de ontvanger die controle niet, dan is er alleen een probleem als de communicatie al gecompromitteerd was en een andere key was ontvangen en alle communicatie erna ook onderschept en aangepast wordt om de illusie te scheppen dat er niks mis is met de communicatiestroom.

Mensen gebruiken PGP/GPG/GnuPG omdat ze ervan uitgaan dat elke mail vals kan zijn. Je speelt Russisch roulette als je erop gokt dat de mail met de bijgesloten public key niet gespoofed of gewijzigd is.

novice.tweaker schreef:

IHeeft https in plaats van http ook geen zin?

Je lijkt te suggereren dat ik stel dat PGP e.d. geen zin hebben.

Dat stel ik echter helemaal niet. Ik stel dat velen denken te weten hoe je het veilig inzet.

Het verschil tussen enerzijds PGP e.d. en anderzijds de gebruikelijke X.509 certificaten is, dat niet jijzelf, maar een (hopelijk trustworthy) TTP (Trusted Third Party), vaststelt dat een public key en een uniek beschreven unieke identiteit, beide samen opgenomen in een certificaat-aanvraag, daadwerkelijk bij elkaar horen (waarna de TTP er een geldig certificaat van maakt door er een digitale handtekening onder te zetten).

Mocht het je interesseren, meer leesvoer (door mij geschreven):
• Authenticatie en impersonatie

• Steekproef: overheid + HSTS

Specifiek over Gpg4Win, maar uit 2013:
• Veiliger downloaden onder Windows: GnuPG/PGP handtekeningen

en (ook uit 2013)
• Veiliger downloaden onder Windows deel 2: Windows GUI's voor GnuPG/PGP

[Reactie gewijzigd door Verwijderd op 23 juli 2024 07:17]

[novice.tweaker]

Je lijkt te suggereren dat ik stel dat PGP e.d. geen zin hebben.

Dat stel ik echter helemaal niet.

Oh pardon, ik dacht dat je schreef:

In theorie is het een mooi systeem, in de praktijk nauwelijks bruikbaar; het is te vaak schijnveiligheid.

Maar ik begrijp nu dat een kwaadwillende dat geschreven heeft. Mijn excuses voor de verkeerde aanname

[Verwijderd]

novice.tweaker schreef:

Maar ik begrijp nu dat een kwaadwillende dat geschreven heeft.

Kinderachtig zeg, je doet je pseudoniem eer aan

[novice.tweaker]

[FrostyPeet]

Lees dat stuk over Okular gpg edition, dat het ook in "high security" gebieden bruikbaar is. PDF ondertekenen met de GPG keystore en smime.

Waar ik niet uitkom, is Okular ook geschikt om met GPG sleutelparen te ondertekenen/verifiëren? Naast de (commerciele) smime certificaten?

Staan ook wat tutorials om self signed smime certificaten te maken met de windows opdracht certutil, maar dat schijnt toch ook wel een vage bedoeling te zijn dat wel/niet werkt met Okular.

[vgroenewold]

Ik gebruik het voor de Gitlab instance waar ik in werk (commit signing), het systeem van sleutels is nog steeds een uitstekend iets om te hebben.

[Monzo]

Het feit dat mailprogrammas tegenwoordig geen afzender-mailadressen laten zien en daarmee inherent onveiliger geworden zijn, vind ik een veel groter probleem wat veel hierboven genoemde zaken op zou lossen…

Mailadres tonen is stap 1 van veiligheid, alle andere controles ter aanvulling vullen dit dan aan.