Re: Essay on PGP as it is used today
Stefan Claas via Gnupg-users wrote: > raf via Gnupg-users wrote: > > > Stefan Claas via Gnupg-users wrote: > > > > > Andrew Gallagher wrote: > > > > > > > * And finally: “don’t encrypt email”? Yes, well. Email is not going > > > > away. Just like passwords, its death has been long anticipated, yet > > > > never arrives. So what do we do in the meantime? > > > > > > I think the biggest problems is how can PGP or GnuPG users tell other > > > users, not familar with email encyrption yet, what else to use ... > > > > At work, when a client insists on email, and I (or the law) > > insist on encryption, I provide them with instructions for > > installing 7-zip and send them an AES-256 encrypted zip or 7z > > file as an attachment. It's the simplest thing I could think > > of that I thought most people could cope with. > > That is simple, indeed. But how do you exchange passphrases for > the encrypted files in advance and do you switch them regularly > or leave them the same when dealing with many clients? > > I solved this with using NaCl public keys, bearing no infos of > the key owners and having a little key ring, where I only assign > nicknames to the pub keys. The software I use is box > > https://github.com/rovaughn/box Windows users who are interested to try out box can find a GUI based solution, from inwtx, at github. https://github.com/inwtx/NaClBoxEncryption https://github.com/inwtx/NaClBoxEncryption/releases It uses base64 as armor and the armor headers can be set to 'off'. Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Fresh certificate marked as expired / messed-up certificate chain pulling expired root cert in gpgsm
Hi, thanks for looking at this … am Sat, 20 Jul 2019 11:01:49 +0200 schrieb Dirk Gottschalk : > This is the issue here. These two certs of DTAG (Telekom) are exired > and that's the reason why gpgsm is complaining correctly. Please check again my original post, though. The issue I see is that these certs are not even supposed to be in the chain! To repeat the summary, which may be lost in the noise before it: The chain in the imported new key & cert file how it should be: 4. Thomas Orgis (me) signed by DFN-Verein Global Issuing CA 3. DFN-Verein Global Issuing CA signed by DFN-Verein Certification Authority 2 2. DFN-Verein Certification Authority 2 signed by T-TeleSec GlobalRoot Class 2 1. T-TeleSec GlobalRoot Class 2 signed by T-TeleSec GlobalRoot Class 2 (root) Compared to what gpgsm sees/shows: 4. Thomas Orgis (me) signed by DFN-Verein Global Issuing CA 3. DFN-Verein Global Issuing CA signed by DFN-Verein Certification Authority 2 2. DFN-Verein Certification Authority 2 signed by T-TeleSec GlobalRoot Class 2 1. T-TeleSec GlobalRoot Class 2 signed by Deutsche Telekom Root CA 2 0. Deutsche Telekom Root CA 2 signed by Deutsche Telekom Root CA 2 (expired root) The bogus signatures by the old Telekom certificates appear only after importing in gpgsm, and colleagues using the same kind of certificates use them without problem in software not relying on gpgsm. So I assume the presence of the old certificates stirs things up. When I create a fresh user and import the new key with its certs into gpgsm, the chain looks like it should. /home/tester/.gnupg/pubring.kbx --- ID: 0x310C60AF Issuer: /CN=DFN-Verein Global Issuing CA/OU=DFN-PKI/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./C=DE Subject: /CN=Thomas Orgis/OU=HPC/OU=Basis-Infrastruktur/OU=RRZ/O=Universitaet Hamburg/L=Hamburg/ST=Hamburg/C=DE validity: 2019-07-05 08:22:41 through 2022-07-04 08:22:41 Certified by ID: 0xD9463C45 Issuer: /CN=DFN-Verein Certification Authority 2/OU=DFN-PKI/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./C=DE Subject: /CN=DFN-Verein Global Issuing CA/OU=DFN-PKI/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./C=DE validity: 2016-05-24 11:38:40 through 2031-02-22 23:59:59 chain length: 1 Certified by ID: 0xD3A89A93 Issuer: /CN=T-TeleSec GlobalRoot Class 2/OU=T-Systems Trust Center/O=T-Systems Enterprise Services GmbH/C=DE Subject: /CN=DFN-Verein Certification Authority 2/OU=DFN-PKI/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./C=DE validity: 2016-02-22 13:38:22 through 2031-02-22 23:59:59 chain length: 2 Certified by ID: 0x17D894E9 Issuer: /CN=T-TeleSec GlobalRoot Class 2/OU=T-Systems Trust Center/O=T-Systems Enterprise Services GmbH/C=DE Subject: /CN=T-TeleSec GlobalRoot Class 2/OU=T-Systems Trust Center/O=T-Systems Enterprise Services GmbH/C=DE validity: 2008-10-01 10:40:14 through 2033-10-01 23:59:59 chain length: unlimited So this looks like a corruption in my keyring that includes the history of using gpgsm for about 5 years:-/ I now could play games with exporting keys and starting with a fresh database … but I'd like to have understood first what happened here. Regards, Thomas -- Dr. Thomas Orgis HPC @ Universität Hamburg ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Upgrading to GnuPG 2.2.17
Dear Developers, My OS is Linux Mint 19.1 Cinnamon. The automated software manager says that its GNUPG version is "2.2.4-1ubuntu1.2". For a transfer to GnuPG 2.2.17, what do you recommend?: - To wait for the Mint managers to update their repository - To uninstall GNUPG 2.2.4-1ubuntu1.2, and install v. 2.2.17 (However: for v. 2.2.4, software manager says: "cannot remove" !!! How then?) - Something else Please advise. Roland ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
About support of RFC 2437, 4056 and 6979
Hi all. Does GnuPG support OAEP for RSA (PKCS#1 v2 and RFC 2437), RSA-PSS (RFC 4056?), or deterministic usage of (EC)DSA (RFC 6979)? And if GnuPG does support RFC 6979, would it also work with (EC)DSA private keys stored on OpenPGP cards which support (EC)DSA algorithms? Best Regards, Persmule ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Secure algorithm extension of RSA and DSA
Hi all. Does GnuPG support OAEP for RSA (PKCS#1 v2 and RFC 2437), RSA-PSS (RFC 4056?), or deterministic usage of (EC)DSA (RFC 6979)? And if GnuPG does support RFC 6979, would it also work with (EC)DSA private keys stored on OpenPGP cards which support (EC)DSA algorithms? Best Regards, Persmule___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: --lsign --add-me or the invisible WoT
Stefan Claas via Gnupg-users wrote: > Hi all, > > now since we have Hagrid and WKD I was wondering if in the future an > additional paramemter like --add-me for --lsign would make sense, for > people still in need of a WoT? > > The idea would be that people --lsign each others keys and GnuPG, > or other public key crypto software, would then save an additional > file in the key ring, allowing users to exchange that blob so that > only they can see that other people, which belong to their WoT, have > lsigend their pub key. > > Well, just a thought ... To be more precise, when exporting a blob it should be something like --export-blob Alice, so that users can individually choose what parts of the blob will be exchanged, so that they do not have to reveal the whole blob, containing all lsigned users. Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
--lsign --add-me or the invisible WoT
Hi all, now since we have Hagrid and WKD I was wondering if in the future an additional paramemter like --add-me for --lsign would make sense, for people still in need of a WoT? The idea would be that people --lsign each others keys and GnuPG, or other public key crypto software, would then save an additional file in the key ring, allowing users to exchange that blob so that only they can see that other people, which belong to their WoT, have lsigend their pub key. Well, just a thought ... Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Fresh certificate marked as expired / messed-up certificate chain pulling expired root cert in gpgsm
Hello. Am Donnerstag, den 18.07.2019, 18:33 +0200 schrieb Dr. Thomas Orgis: > Certified by >ID: 0x61A8CF44 >Issuer: /CN=Deutsche Telekom Root CA 2/OU=T-TeleSec Trust > Center/O=Deutsche Telekom AG/C=DE > Subject: /CN=T-TeleSec GlobalRoot Class 2/OU=T-Systems Trust > Center/O=T-Systems Enterprise Services GmbH/C=DE > validity: 2016-04-25 09:01:39 through 2019-07-09 23:59:59 > chain length: unlimited > Certified by >ID: 0x8CDE37BF >Issuer: /CN=Deutsche Telekom Root CA 2/OU=T-TeleSec Trust > Center/O=Deutsche Telekom AG/C=DE > Subject: /CN=Deutsche Telekom Root CA 2/OU=T-TeleSec Trust > Center/O=Deutsche Telekom AG/C=DE > validity: 1999-07-09 12:11:00 through 2019-07-09 23:59:00 > chain length: 5 This is the issue here. These two certs of DTAG (Telekom) are exired and that's the reason why gpgsm is complaining correctly. Regards, Dirk -- Dirk Gottschalk GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380 Keybase: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac signature.asc Description: This is a digitally signed message part ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
