From oub at mat.ucm.es Thu Dec 5 11:59:34 2019 From: oub at mat.ucm.es (Uwe Brauer) Date: Thu, 05 Dec 2019 11:59:34 +0100 Subject: gmail smime, sends two messages one is not encrypted. Experience? Message-ID: <87k17bqbqh.fsf@mat.ucm.es> Hi This might be slightly off topic, but I would really appreciate some feedback. My university uses a special gmail service for academic institutions. Recently gmail provides smime support itself and this has been enabled by my university. Now comes the strange thing: I use smime mostly with emacs+gnus, sometimes with thunderbird. When I sent (with emacs or thunderbird) an encrypted+signed message [1], to a person in my university which whom I have interchanged the public key, since some time, *two* messages are sent, one 1. Is encrypted and signed 2. The other is only signed. Can somebody please confirm this strange behavior? Is this connected to the fact that my university enabled smime support? It seems to me a complete security breach. Regards Uwe Brauer Footnotes: [1] purely encrypted messages are rejected by the server From jerry at seibercom.net Thu Dec 5 20:10:27 2019 From: jerry at seibercom.net (Jerry) Date: Thu, 5 Dec 2019 14:10:27 -0500 Subject: Moving sigs from Wins machine to FreeBSD Message-ID: <20191205141027.000037e2@seibercom.net> I have gpg4win installed on a Win 10 machine. I just installed FreeBSD onto a new PC. I installed GNUPG 2.2.18 and would like to move all of the signatures over to it from the Windows machine. Is that possible and how would be the best way to go about it? Thanks! -- Jerry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Dec 5 20:48:01 2019 From: wk at gnupg.org (Werner Koch) Date: Thu, 05 Dec 2019 20:48:01 +0100 Subject: Moving sigs from Wins machine to FreeBSD In-Reply-To: <20191205141027.000037e2@seibercom.net> (Jerry's message of "Thu, 5 Dec 2019 14:10:27 -0500") References: <20191205141027.000037e2@seibercom.net> Message-ID: <87r21iblla.fsf@wheatstone.g10code.de> On Thu, 5 Dec 2019 14:10, Jerry said: > I have gpg4win installed on a Win 10 machine. I just installed > FreeBSD onto a new PC. I installed GNUPG 2.2.18 and would like to move > all of the signatures over to it from the Windows machine. Is that > possible and how would be the best way to go about it? All data used by gpg and gpgsm is stored in a platform independent format. For example, moving your GnuPG home directory from a 64bit big endian Unix to a 32 bit Windows box will not lead to any problems. Data (signed or encrypted files) as created by gpg is per OpenPGP specs also platform neutral. When using the armored format the line endings are created as required by the platform; however all kind of line endings are accepted by gpg. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jerry at seibercom.net Thu Dec 5 22:02:46 2019 From: jerry at seibercom.net (Jerry) Date: Thu, 5 Dec 2019 16:02:46 -0500 Subject: Moving sigs from Wins machine to FreeBSD In-Reply-To: <87r21iblla.fsf@wheatstone.g10code.de> References: <20191205141027.000037e2@seibercom.net> <87r21iblla.fsf@wheatstone.g10code.de> Message-ID: <20191205160246.0000360e@seibercom.net> On Thu, 05 Dec 2019 20:48:01 +0100, Werner Koch stated: >On Thu, 5 Dec 2019 14:10, Jerry said: >> I have gpg4win installed on a Win 10 machine. I just installed >> FreeBSD onto a new PC. I installed GNUPG 2.2.18 and would like to >> move all of the signatures over to it from the Windows machine. Is >> that possible and how would be the best way to go about it? > >All data used by gpg and gpgsm is stored in a platform independent >format. For example, moving your GnuPG home directory from a 64bit big >endian Unix to a 32 bit Windows box will not lead to any problems. > >Data (signed or encrypted files) as created by gpg is per OpenPGP specs >also platform neutral. When using the armored format the line endings >are created as required by the platform; however all kind of line >endings are accepted by gpg. > > >Shalom-Salam, > > Werner So Werner, if I am understanding you correctly, I can just copy the C:\Users\gerar\AppData\Roaming\gnupg files over to the ~/.gnupg directory and it will work. Sounds good. Thanks! -- Jerry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From oub at mat.ucm.es Thu Dec 5 23:05:45 2019 From: oub at mat.ucm.es (Uwe Brauer) Date: Thu, 05 Dec 2019 23:05:45 +0100 Subject: gmail smime, sends two messages one is not encrypted. Experience? References: <87k17bqbqh.fsf__14890.3057490074$1575543713$gmane$org@mat.ucm.es> Message-ID: <87zhg6sa12.fsf@mat.ucm.es> >>> "UBvG" == Uwe Brauer via Gnupg-users writes: > Hi > It seems to me a complete security breach. I repeated the test with other gmail accounts, with emacs or thunderbird, always I receive messages which are on signed but not encrypted although I did enable both options. I am deeply worried. Anybody with the same experience, or somebody who wants to run an experiment with me. Uwe Brauer -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5025 bytes Desc: not available URL: From sac at 300baud.de Thu Dec 5 23:39:49 2019 From: sac at 300baud.de (Stefan Claas) Date: Thu, 5 Dec 2019 23:39:49 +0100 Subject: gmail smime, sends two messages one is not encrypted. Experience? In-Reply-To: <87k17bqbqh.fsf@mat.ucm.es> References: <87k17bqbqh.fsf@mat.ucm.es> Message-ID: <20191205233949.00004662.sac@300baud.de> Uwe Brauer via Gnupg-users wrote: > Hi > > This might be slightly off topic, but I would really appreciate some > feedback. > > My university uses a special gmail service for academic institutions. > Recently gmail provides smime support itself and this has been enabled > by my university. > > Now comes the strange thing: > I use smime mostly with emacs+gnus, sometimes with thunderbird. > > When I sent (with emacs or thunderbird) an encrypted+signed message [1], to a > person in my university which whom I have interchanged the public key, since > some time, *two* messages are sent, one > > 1. Is encrypted and signed > > 2. The other is only signed. > > Can somebody please confirm this strange behavior? > > Is this connected to the fact that my university enabled smime support? > > > It seems to me a complete security breach. Sorry, I can't help you but I do have a question, if you don't mind ... Why are the Students at the University don't use OpenPGP with Gmail via the free Mailvelope add-on for Firefox, Chrome? Wouldn't that be not cheaper instead of purchasing a whole lot of S/MIME certificates? And Mailvelope is also super easy to use and no GnuPG installation is required. Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From oub at mat.ucm.es Thu Dec 5 23:43:01 2019 From: oub at mat.ucm.es (Uwe Brauer) Date: Thu, 05 Dec 2019 23:43:01 +0100 Subject: [gmx+gmail] (was: gmail smime, sends two messages one is not encrypted. Experience?) References: <87k17bqbqh.fsf__14890.3057490074$1575543713$gmane$org@mat.ucm.es> <87zhg6sa12.fsf__8737.69340557686$1575583645$gmane$org@mat.ucm.es> Message-ID: <87o8wms8ay.fsf_-_@mat.ucm.es> >>> "UBvG" == Uwe Brauer via Gnupg-users writes: >>> "UBvG" == Uwe Brauer via Gnupg-users writes: >> Hi >> It seems to me a complete security breach. > I repeated the test with other gmail accounts, with emacs or > thunderbird, always I receive messages which are on signed but not > encrypted although I did enable both options. I am deeply worried. > Anybody with the same experience, or somebody who wants to run an > experiment with me. I extended my experiment: I sent message between a gmx and a gmail account, then everything was ok, encrypted was encrypted. Signed was signed, even for seamonkey/thunderbird, so the culprit are not the MTA, but it seems that gmail does something strange. I'd love to get some confirmation about this from somebody else. Uwe Brauer -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5025 bytes Desc: not available URL: From wk at gnupg.org Fri Dec 6 08:07:31 2019 From: wk at gnupg.org (Werner Koch) Date: Fri, 06 Dec 2019 08:07:31 +0100 Subject: Moving sigs from Wins machine to FreeBSD In-Reply-To: <20191205160246.0000360e@seibercom.net> (Jerry's message of "Thu, 5 Dec 2019 16:02:46 -0500") References: <20191205141027.000037e2@seibercom.net> <87r21iblla.fsf@wheatstone.g10code.de> <20191205160246.0000360e@seibercom.net> Message-ID: <87immuaq4s.fsf@wheatstone.g10code.de> On Thu, 5 Dec 2019 16:02, Jerry said: > So Werner, if I am understanding you correctly, I can just copy the > C:\Users\gerar\AppData\Roaming\gnupg files over to the ~/.gnupg > directory and it will work. Sounds good. Thanks! Right. If you are deeply worried about security you may want to delete the random_seed file; it is a cache to speed up entropy collection. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Sat Dec 7 13:06:34 2019 From: wk at gnupg.org (Werner Koch) Date: Sat, 07 Dec 2019 13:06:34 +0100 Subject: [Announce] GnuPG 2.2.19 released Message-ID: <87imms9w6t.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: version 2.2.19. This version fixes a bug introduced with the last release. See below for details. About GnuPG =========== The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation of the OpenPGP and S/MIME standards. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. The separate library GPGME provides a uniform API to use the GnuPG engine by software written in common programming languages. A wealth of frontend applications and libraries making use of GnuPG are available. As an universal crypto engine GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Noteworthy changes in version 2.2.19 ==================================== * gpg: Fix double free when decrypting for hidden recipients. Regression in 2.2.18. [#4762]. * gpg: Use auto-key-locate for encryption even for mail addressed given with angle brackets. [#4726] * gpgsm: Add special case for certain expired intermediate certificates. [#4696] Release-info: https://dev.gnupg.org/T4768 Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.2.19 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.19.tar.bz2 (6597k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.19.tar.bz2.sig An installer for Windows without any graphical frontend except for a very minimal Pinentry tool is available here: https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.19_20191207.exe (4140k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.19_20191207.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. A new version of GnuPG's full installer for Windows (aka Gpg4win) featuring several frontends and plugins will be released shortly. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.2.19.tar.bz2 you would use this command: gpg --verify gnupg-2.2.19.tar.bz2.sig gnupg-2.2.19.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See the end of this mail for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.2.19.tar.bz2, you run the command like this: sha1sum gnupg-2.2.19.tar.bz2 and check that the output matches the next line: e24a1208ffe69d7436b2f27e99542a85f34d0ac0 gnupg-2.2.19.tar.bz2 fb0eebb29c73c72d0045e3100963dd9a62a188bb gnupg-w32-2.2.19_20191207.tar.xz a2e95e66918ed8e228c75d59feeee3bf6bc42d1d gnupg-w32-2.2.19_20191207.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese (traditional and simplified), Czech, French, German, Japanese, Norwegian, Polish, Russian, and Ukrainian being almost completely translated. Documentation and Support ========================= If you used GnuPG in the past you should read the description of changes and new features at doc/whats-new-in-2.1.txt or online at https://gnupg.org/faq/whats-new-in-2.1.html The file gnupg.info has the complete reference manual of the system. Separate man pages are included as well but they miss some of the details available only in thee manual. The manual is also available online at https://gnupg.org/documentation/manuals/gnupg/ or can be downloaded as PDF at https://gnupg.org/documentation/manuals/gnupg.pdf . You may also want to search the GnuPG mailing list archives or ask on the gnupg-users mailing list for advise on how to solve problems. Most of the new features are around for several years and thus enough public experience is available. https://wiki.gnupg.org has user contributed information around GnuPG and relate software. In case of build problems specific to this release please first check https://dev.gnupg.org/T4768 for updated information. Please consult the archive of the gnupg-users mailing list before reporting a bug: . We suggest to send bug reports for a new release to this list in favor of filing a bug at . If you need commercial support go to or . If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== Maintenance and development of GnuPG is mostly financed by donations. The GnuPG project currently employs two full-time developers and one contractor. They all work exclusively on GnuPG and closely related software like Libgcrypt, GPGME and Gpg4win. We have to thank all the people who helped the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Many thanks to our numerous financial supporters, both corporate and individuals. Without you it would not be possible to keep GnuPG in a good shape and to address all the small and larger requests made by our users. Thanks. Happy hacking, Your GnuPG hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users'at'gnupg.org mailing list. p.p.s List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: rsa2048 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048 2014-10-29 [expires: 2020-10-30] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa3072 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) The keys are available at and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From juergen at bruckner.tk Sat Dec 7 20:35:14 2019 From: juergen at bruckner.tk (Juergen Bruckner) Date: Sat, 7 Dec 2019 20:35:14 +0100 Subject: [gmx+gmail] (was: gmail smime, sends two messages one is not encrypted. Experience?) In-Reply-To: <87o8wms8ay.fsf_-_@mat.ucm.es> References: <87k17bqbqh.fsf__14890.3057490074$1575543713$gmane$org@mat.ucm.es> <87zhg6sa12.fsf__8737.69340557686$1575583645$gmane$org@mat.ucm.es> <87o8wms8ay.fsf_-_@mat.ucm.es> Message-ID: <56fc7b56-0756-748f-12bc-cedc93e15e50@bruckner.tk> Hello Uwe, i use Gmail for business for a very long time and never had any issue like that. This message here should reach you as S/MIME signed message. best regards Juergen Am 05.12.19 um 23:43 schrieb Uwe Brauer via Gnupg-users: >>>> "UBvG" == Uwe Brauer via Gnupg-users writes: > >>>> "UBvG" == Uwe Brauer via Gnupg-users writes: > >> Hi > > >> It seems to me a complete security breach. > > > I repeated the test with other gmail accounts, with emacs or > > thunderbird, always I receive messages which are on signed but not > > encrypted although I did enable both options. I am deeply worried. > > > Anybody with the same experience, or somebody who wants to run an > > experiment with me. > > I extended my experiment: I sent message between a gmx and a gmail > account, then everything was ok, encrypted was encrypted. Signed was > signed, even for seamonkey/thunderbird, so the culprit are not the MTA, > but it seems that gmail does something strange. > > I'd love to get some confirmation about this from somebody else. > > Uwe Brauer > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- Juergen M. Bruckner juergen at bruckner.tk -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3894 bytes Desc: S/MIME Cryptographic Signature URL: From juergen at bruckner.tk Sat Dec 7 20:43:37 2019 From: juergen at bruckner.tk (Juergen Bruckner) Date: Sat, 7 Dec 2019 20:43:37 +0100 Subject: gmail smime, sends two messages one is not encrypted. Experience? In-Reply-To: <20191205233949.00004662.sac@300baud.de> References: <87k17bqbqh.fsf@mat.ucm.es> <20191205233949.00004662.sac@300baud.de> Message-ID: <18098912-1343-f450-5c06-3c9fe49c7c7c@bruckner.tk> This question is very easy to answer. S/MIME has some advantages over (Open)PGP. One of them - the most important for the usual S/MIME users - is, that S/MIME allows the uniquely identification of a communication partner, which is only limitedly possible with PGP. In addition, educational institutions, such as universities, schools, research networks etc., have their own internal CA, which keeps the costs very manageable. Am 05.12.19 um 23:39 schrieb Stefan Claas via Gnupg-users: > Sorry, I can't help you but I do have a question, if you don't mind ... > > Why are the Students at the University don't use OpenPGP with Gmail > via the free Mailvelope add-on for Firefox, Chrome? Wouldn't that be > not cheaper instead of purchasing a whole lot of S/MIME certificates? best regards Juergen -- Juergen M. Bruckner juergen at bruckner.tk -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3894 bytes Desc: S/MIME Cryptographic Signature URL: From sac at 300baud.de Sat Dec 7 20:59:16 2019 From: sac at 300baud.de (Stefan Claas) Date: Sat, 7 Dec 2019 20:59:16 +0100 Subject: gmail smime, sends two messages one is not encrypted. Experience? In-Reply-To: <18098912-1343-f450-5c06-3c9fe49c7c7c@bruckner.tk> References: <87k17bqbqh.fsf@mat.ucm.es> <20191205233949.00004662.sac@300baud.de> <18098912-1343-f450-5c06-3c9fe49c7c7c@bruckner.tk> Message-ID: <20191207205916.00004d2b.sac@300baud.de> Juergen Bruckner via Gnupg-users wrote: Hi Juergen, > This question is very easy to answer. > > S/MIME has some advantages over (Open)PGP. > One of them - the most important for the usual S/MIME users - is, that > S/MIME allows the uniquely identification of a communication partner, > which is only limitedly possible with PGP. > > In addition, educational institutions, such as universities, schools, > research networks etc., have their own internal CA, which keeps the > costs very manageable. Ah, o.k. with an own CA that make sense. However, I was also assuming that students may use their certs also for 'outside' comms, which then would require then that the other parties have always to import non- trusted root certs, which is not the case with commercial ones, obtained from globally trusted CAs. > Am 05.12.19 um 23:39 schrieb Stefan Claas via Gnupg-users: > > Sorry, I can't help you but I do have a question, if you don't mind ... > > > > Why are the Students at the University don't use OpenPGP with Gmail > > via the free Mailvelope add-on for Firefox, Chrome? Wouldn't that be > > not cheaper instead of purchasing a whole lot of S/MIME certificates? Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From sac at 300baud.de Sat Dec 7 21:11:27 2019 From: sac at 300baud.de (Stefan Claas) Date: Sat, 7 Dec 2019 21:11:27 +0100 Subject: gmail smime, sends two messages one is not encrypted. Experience? In-Reply-To: <18098912-1343-f450-5c06-3c9fe49c7c7c@bruckner.tk> References: <87k17bqbqh.fsf@mat.ucm.es> <20191205233949.00004662.sac@300baud.de> <18098912-1343-f450-5c06-3c9fe49c7c7c@bruckner.tk> Message-ID: <20191207211127.000048d8.sac@300baud.de> Juergen Bruckner via Gnupg-users wrote: > This question is very easy to answer. > > S/MIME has some advantages over (Open)PGP. > One of them - the most important for the usual S/MIME users - is, that > S/MIME allows the uniquely identification of a communication partner, > which is only limitedly possible with PGP. Yes, but the is not an OpenPGP 'fault' IHMO, it is caused by users and the OpenPGP community in general, not accepting CAs and still relying on the classical WoT. Maybe we should ask ourselves why we not have more (free) CAs for the OpenPGP ecosystem (wish we had more like Governikus ...) Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From juergen at bruckner.tk Sat Dec 7 21:19:02 2019 From: juergen at bruckner.tk (Juergen BRUCKNER) Date: Sat, 7 Dec 2019 21:19:02 +0100 Subject: gmail smime, sends two messages one is not encrypted. Experience? In-Reply-To: <20191207205916.00004d2b.sac@300baud.de> References: <87k17bqbqh.fsf@mat.ucm.es> <20191205233949.00004662.sac@300baud.de> <18098912-1343-f450-5c06-3c9fe49c7c7c@bruckner.tk> <20191207205916.00004d2b.sac@300baud.de> Message-ID: <9f06a365-89bf-144b-6385-9e1530828879@bruckner.tk> Hi Stefan, well... what is a trusted and a untrusted CA? Is a CA really trusted just about the fact it is "build in" in a browser or mail client? Is a not included CA really untrusted? I think it is more a personal decision than anything else. The past few years showed us very good examples why "trusted" CA are not much better that so called untrusted ones. And for personally .. i think i can for example trust the CA CAcert much more than a CA which is located in China or Turkey. So isf someone is iporting a root certificate of any CA he shows that he is trusting this CA - not more not less Am 07.12.19 um 20:59 schrieb Stefan Claas: > Ah, o.k. with an own CA that make sense. However, I was also assuming > that students may use their certs also for 'outside' comms, which then > would require then that the other parties have always to import non- > trusted root certs, which is not the case with commercial ones, obtained > from globally trusted CAs. regards Juergen From juergen at bruckner.tk Sat Dec 7 21:28:27 2019 From: juergen at bruckner.tk (Juergen BRUCKNER) Date: Sat, 7 Dec 2019 21:28:27 +0100 Subject: gmail smime, sends two messages one is not encrypted. Experience? In-Reply-To: <20191207211127.000048d8.sac@300baud.de> References: <87k17bqbqh.fsf@mat.ucm.es> <20191205233949.00004662.sac@300baud.de> <18098912-1343-f450-5c06-3c9fe49c7c7c@bruckner.tk> <20191207211127.000048d8.sac@300baud.de> Message-ID: <62bf59b7-1a9a-7577-ebaa-e9cc07e43d8d@bruckner.tk> Hi Stefan Thats not the approach PGP pursues. PGP was, is and should continue to be decentralized in the future. It was never really intended to validate identities in a wide circle, but to secure communication, and - im parts - to ensure the integrity of software. The so-called WOT has proven to me in the field of PGP and does not really need central instances Am 07.12.19 um 21:11 schrieb Stefan Claas: > Yes, but the is not an OpenPGP 'fault' IHMO, it is caused by users and > the OpenPGP community in general, not accepting CAs and still relying > on the classical WoT. > > Maybe we should ask ourselves why we not have more (free) CAs for > the OpenPGP ecosystem (wish we had more like Governikus ...) regards Juergen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3894 bytes Desc: S/MIME Cryptographic Signature URL: From sac at 300baud.de Sat Dec 7 21:29:03 2019 From: sac at 300baud.de (Stefan Claas) Date: Sat, 7 Dec 2019 21:29:03 +0100 Subject: gmail smime, sends two messages one is not encrypted. Experience? In-Reply-To: <9f06a365-89bf-144b-6385-9e1530828879@bruckner.tk> References: <87k17bqbqh.fsf@mat.ucm.es> <20191205233949.00004662.sac@300baud.de> <18098912-1343-f450-5c06-3c9fe49c7c7c@bruckner.tk> <20191207205916.00004d2b.sac@300baud.de> <9f06a365-89bf-144b-6385-9e1530828879@bruckner.tk> Message-ID: <20191207212903.00002507.sac@300baud.de> Juergen BRUCKNER wrote: Hi Juergen, > well... what is a trusted and a untrusted CA? With that I meaned those already found in the Certificate Store of a MUA/NUA or OS, so that Joe User does not have to care much. Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From sac at 300baud.de Sat Dec 7 21:51:34 2019 From: sac at 300baud.de (Stefan Claas) Date: Sat, 7 Dec 2019 21:51:34 +0100 Subject: gmail smime, sends two messages one is not encrypted. Experience? In-Reply-To: <62bf59b7-1a9a-7577-ebaa-e9cc07e43d8d@bruckner.tk> References: <87k17bqbqh.fsf@mat.ucm.es> <20191205233949.00004662.sac@300baud.de> <18098912-1343-f450-5c06-3c9fe49c7c7c@bruckner.tk> <20191207211127.000048d8.sac@300baud.de> <62bf59b7-1a9a-7577-ebaa-e9cc07e43d8d@bruckner.tk> Message-ID: <20191207215134.00000301.sac@300baud.de> Juergen BRUCKNER wrote: > Hi Stefan > > Thats not the approach PGP pursues. > PGP was, is and should continue to be decentralized in the future. It > was never really intended to validate identities in a wide circle, but > to secure communication, and - im parts - to ensure the integrity of > software. Well, the integrity of software can also be shown with a simple hash value posted, because I can not verify if the sig belongs to person xyz, even when he / she has a lot of fan sigs from people unknown to me. So, why then all this sigs stuff, Mr Zimmermann invented, while no other public key crypto software has such functionallity? > The so-called WOT has proven to me in the field of PGP and does not > really need central instances Why do you or other people think it is central, when we would have many CAs in place, each one not connected to the other one? And even if it would be run by one CA people don't trust, they could trust the CA sig, if the signing procedure would be correct. I for example do not trust third party sigs from regular users, because I have withnessed that also people sign other peoples keys out of the blue, while never ever contacting the person who owns the key ... > > Am 07.12.19 um 21:11 schrieb Stefan Claas: > > Yes, but the is not an OpenPGP 'fault' IHMO, it is caused by users and > > the OpenPGP community in general, not accepting CAs and still relying > > on the classical WoT. > > > > Maybe we should ask ourselves why we not have more (free) CAs for > > the OpenPGP ecosystem (wish we had more like Governikus ...) Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From oub at mat.ucm.es Sun Dec 8 10:38:43 2019 From: oub at mat.ucm.es (Uwe Brauer) Date: Sun, 08 Dec 2019 10:38:43 +0100 Subject: gmail smime, sends two messages one is not encrypted. Experience? References: <87k17bqbqh.fsf@mat.ucm.es> <20191205233949.00004662.sac__47704.6530855418$1575585672$gmane$org@300baud.de> Message-ID: <87h82bf97g.fsf@mat.ucm.es> > Uwe Brauer via Gnupg-users wrote: > Sorry, I can't help you but I do have a question, if you don't mind ... > Why are the Students at the University don't use OpenPGP with Gmail > via the free Mailvelope add-on for Firefox, Chrome? Wouldn't that be > not cheaper instead of purchasing a whole lot of S/MIME certificates? Well, first of all the university decided to use (as a understand, without charge) gmail services, since they could not effort to run their own server. Now to the question s/mime versus gnupg. There are the following points which make s/mime easier. 1. Key generation. In s/mime you apply for a certificate and don't have to generate the key by yourself. 2. Key interchange. This is in my experience the biggest problem for most users. In s/mime it is sufficient to send a sign message, it contains the public key of the sender (I don't want now to enter the technical details) 3. Software: if you use a proper MTA s/mime is usually included, while pgp is not, but a plugin has to be installed. If the user is using gmail's webinterface, which, unfortunately more and more users are doing, things get more complicated. You mentioned mailvelop, but again this is a plugin to be installed, while now gmail (at least for its business/academic suite) offers s/mime support natively. Last but not least, a lot of people in my university now posses a first class certificate anyhow, provided by the Spanish administration, which can be used for all sort of things, one of them to use it for encrypted emails. I hope that makes it clear why s/mime is preferred of pgp. Uwe Brauer -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5025 bytes Desc: not available URL: From sac at 300baud.de Sun Dec 8 20:08:24 2019 From: sac at 300baud.de (Stefan Claas) Date: Sun, 8 Dec 2019 20:08:24 +0100 Subject: gmail smime, sends two messages one is not encrypted. Experience? In-Reply-To: <87h82bf97g.fsf@mat.ucm.es> References: <87k17bqbqh.fsf@mat.ucm.es> <20191205233949.00004662.sac__47704.6530855418$1575585672$gmane$org@300baud.de> <87h82bf97g.fsf@mat.ucm.es> Message-ID: <20191208200824.00005f4e.sac@300baud.de> Uwe Brauer via Gnupg-users wrote: > > > Uwe Brauer via Gnupg-users wrote: > > > Sorry, I can't help you but I do have a question, if you don't mind ... > > > Why are the Students at the University don't use OpenPGP with Gmail > > via the free Mailvelope add-on for Firefox, Chrome? Wouldn't that be > > not cheaper instead of purchasing a whole lot of S/MIME certificates? > > Well, first of all the university decided to use (as a understand, > without charge) gmail services, since they could not effort to run their > own server. > > Now to the question s/mime versus gnupg. > > There are the following points which make s/mime easier. [snip] > I hope that makes it clear why s/mime is preferred of pgp. Yes, it is clear now and makes sense. Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From jblist at icloud.com Sun Dec 8 18:48:47 2019 From: jblist at icloud.com (jblist at icloud.com) Date: Sun, 8 Dec 2019 10:48:47 -0700 Subject: Partial/fragmented decryption keys Message-ID: <3EC97DD9-43E3-47F8-8E11-02177C33E54A@icloud.com> I recall from the early days of PGP that there was a way to create a corporate key, fragmented into a certain number of potions, which would require some quorum to be able to perform decryption. I pored over the GnuPG documentation but could not find an equivalent. Perhaps I?m just getting the terminology wrong. Is this still possible in OpenPGP and therefore in GnuPG? From sac at 300baud.de Sun Dec 8 21:43:23 2019 From: sac at 300baud.de (Stefan Claas) Date: Sun, 8 Dec 2019 21:43:23 +0100 Subject: Partial/fragmented decryption keys In-Reply-To: <3EC97DD9-43E3-47F8-8E11-02177C33E54A@icloud.com> References: <3EC97DD9-43E3-47F8-8E11-02177C33E54A@icloud.com> Message-ID: <20191208214323.000064e0.sac@300baud.de> Joseph Bruni via Gnupg-users wrote: > I recall from the early days of PGP that there was a way to create a > corporate key, fragmented into a certain number of potions, which would > require some quorum to be able to perform decryption. I pored over the GnuPG > documentation but could not find an equivalent. Perhaps I?m just getting the > terminology wrong. Is this still possible in OpenPGP and therefore in GnuPG? I don't remember that, but you may search (on GitHub) for 'Shamir's Secret Sharing', which allows you to share a secret with multiple parties and only if the parties come together they can decrypt the secret. Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From dgouttegattat at incenp.org Sun Dec 8 21:54:53 2019 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sun, 8 Dec 2019 20:54:53 +0000 Subject: Partial/fragmented decryption keys In-Reply-To: <3EC97DD9-43E3-47F8-8E11-02177C33E54A@icloud.com> References: <3EC97DD9-43E3-47F8-8E11-02177C33E54A@icloud.com> Message-ID: <20191208205453.aydo7awdzd2ai7pl@dynein.local.incenp.org> On Sun, Dec 08, 2019 at 10:48:47AM -0700, Joseph Bruni via Gnupg-users wrote: >I recall from the early days of PGP that there was a way to create a >corporate key, fragmented into a certain number of potions, which would >require some quorum to be able to perform decryption. [...] Is this >still possible in OpenPGP and therefore in GnuPG? The OpenPGP RFC [1] seems to acknowledge this possibility by defining a flag that can be set on a public key to indicate that the corresponding private key ?may have been split by a secret-sharing mechanism? (? 5.2.3.1). But it does not provide any details about how that feature should be implemented, leaving that entirely to the implementations (which makes sense, I guess, since what an implementation does with a private key is not supposed to have an impact on interoperability, and so does not need to be specified). I don?t know about early (or even more recent) PGP versions, but GnuPG does not have such a feature. If you are interested the topic has been discussed a few years ago on the -devel mailing list [2]. Cheers, - Damien [1] https://tools.ietf.org/html/rfc4880#section-5.2.3.21 [2] https://lists.gnupg.org/pipermail/gnupg-devel/2016-January/030681.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From philip-jackson at gmx.com Sun Dec 8 20:41:05 2019 From: philip-jackson at gmx.com (Philip Jackson) Date: Sun, 8 Dec 2019 20:41:05 +0100 Subject: Partial/fragmented decryption keys In-Reply-To: <3EC97DD9-43E3-47F8-8E11-02177C33E54A@icloud.com> References: <3EC97DD9-43E3-47F8-8E11-02177C33E54A@icloud.com> Message-ID: On 08/12/2019 18:48, Joseph Bruni via Gnupg-users wrote: > I recall from the early days of PGP that there was a way to create a corporate key, fragmented into a certain number of potions, which would require some quorum to be able to perform decryption. I pored over the GnuPG documentation but could not find an equivalent. Perhaps I?m just getting the terminology wrong. Is this still possible in OpenPGP and therefore in GnuPG? I don't know about a solution within PGP but it sounds a bit like? 'ssss' -? Shamir's Secret Sharing Scheme. I quote the description within Ubuntu linux distribution of the ssss package : "allows a secret to be split in to shares. These shares can then be distributed to different people. When the time comes to retrieve the secret then a preset number of the shares need to be combined. The number of shares created, and the number needed to retrieve the secret are set at splitting time. The number of shares required to re-create the secret can be chosen to be less that the number of shares created, so any large enough subset of the shares can retrieve the secret. This scheme allows a secret to be shared, either to reduce the chances that the secret is lost, or to increase the number of parties that must cooperate to reveal the secret." hhh Philip -------------- next part -------------- An HTML attachment was scrubbed... URL: From dirkx at webweaving.org Mon Dec 9 18:21:20 2019 From: dirkx at webweaving.org (Dirk-Willem van Gulik) Date: Mon, 9 Dec 2019 18:21:20 +0100 Subject: v2.1 openpgp smartcard -- packing in after a `key to card' Message-ID: During a pretty standard create key; key to card cycle (scripted) - I got an error gpg: OpenPGP card not available: Card removed just after the ?save? in the ?edit-key. A subsequent status check gives me: gpg2 --card-status gpg: OpenPGP card not available: Card removed with below scdaemon log information. The key moved onto it was a rsa1024 key: gpg2 --homedir . --batch --passphrase ?$TEMP_PASSWD" --quick-add-key $FPR2 rsa1024 i.e the second of (key 1): sec ed25519/F93BF2C7E09FEDC0 created: 2019-12-09 expires: 2021-12-08 usage: SC trust: ultimate validity: ultimate ssb rsa1024/3341725A21249687 created: 2019-12-09 expires: never usage: E Does this ring a bell with anyone ? With kind regards, Dw. 2019-12-09 18:15:06 scdaemon[47159] DBG: chan_7 <- GETINFO version 2019-12-09 18:15:06 scdaemon[47159] DBG: chan_7 -> D 2.2.17 2019-12-09 18:15:06 scdaemon[47159] DBG: chan_7 -> OK 2019-12-09 18:15:06 scdaemon[47159] DBG: chan_7 <- SERIALNO openpgp 2019-12-09 18:15:06 scdaemon[47159] ccid open error: skip 2019-12-09 18:15:06 scdaemon[47159] ccid open error: skip 2019-12-09 18:15:06 scdaemon[47159] ccid open error: skip 2019-12-09 18:15:06 scdaemon[47159] detected reader 'SCM Microsystems Inc. SPR 532' 2019-12-09 18:15:06 scdaemon[47159] detected reader 'ACS ACR122U PICC Interface' 2019-12-09 18:15:06 scdaemon[47159] detected reader 'OMNIKEY AG CardMan 3121' 2019-12-09 18:15:06 scdaemon[47159] reader slot 0: not connected 2019-12-09 18:15:07 scdaemon[47159] pcsc_control failed: not transacted (0x80100016) 2019-12-09 18:15:07 scdaemon[47159] pcsc_vendor_specific_init: GET_FEATURE_REQUEST failed: 65547 2019-12-09 18:15:07 scdaemon[47159] reader slot 0: active protocol: T1 2019-12-09 18:15:07 scdaemon[47159] slot 0: ATR=3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C 2019-12-09 18:15:07 scdaemon[47159] AID: D2 76 00 01 24 01 02 01 00 05 00 00 57 2D 00 00 2019-12-09 18:15:07 scdaemon[47159] Historical Bytes: 00 31 C5 73 C0 01 40 05 90 00 2019-12-09 18:15:07 scdaemon[47159] Version-2+ .....: yes 2019-12-09 18:15:07 scdaemon[47159] Extcap-v3 ......: no 2019-12-09 18:15:07 scdaemon[47159] Button .........: no 2019-12-09 18:15:07 scdaemon[47159] SM-Support .....: no 2019-12-09 18:15:07 scdaemon[47159] Get-Challenge ..: yes (2048 bytes max) 2019-12-09 18:15:07 scdaemon[47159] Key-Import .....: yes 2019-12-09 18:15:07 scdaemon[47159] Change-Force-PW1: yes 2019-12-09 18:15:07 scdaemon[47159] Private-DOs ....: yes 2019-12-09 18:15:07 scdaemon[47159] Algo-Attr-Change: yes 2019-12-09 18:15:07 scdaemon[47159] Symmetric Crypto: no 2019-12-09 18:15:07 scdaemon[47159] KDF-Support ....: no 2019-12-09 18:15:07 scdaemon[47159] Max-Cert3-Len ..: 2048 2019-12-09 18:15:07 scdaemon[47159] Cmd-Chaining ...: no 2019-12-09 18:15:07 scdaemon[47159] Ext-Lc-Le ......: yes 2019-12-09 18:15:07 scdaemon[47159] Status-Indicator: 05 2019-12-09 18:15:07 scdaemon[47159] GnuPG-No-Sync ..: no 2019-12-09 18:15:07 scdaemon[47159] GnuPG-Def-PW2 ..: no 2019-12-09 18:15:07 scdaemon[47159] Key-Attr-sign ..: RSA, n=2048, e=32, fmt=std 2019-12-09 18:15:07 scdaemon[47159] Key-Attr-encr ..: RSA, n=1024, e=32, fmt=std 2019-12-09 18:15:07 scdaemon[47159] Key-Attr-auth ..: RSA, n=2048, e=32, fmt=std 2019-12-09 18:15:07 scdaemon[47159] DBG: chan_7 -> S SERIALNO D27600012401020100050000572D0000 2019-12-09 18:15:07 scdaemon[47159] DBG: chan_7 -> OK 2019-12-09 18:15:07 scdaemon[47159] sending signal 31 to client 47158 2019-12-09 18:15:07 scdaemon[47159] DBG: chan_7 <- LEARN --force 2019-12-09 18:15:07 scdaemon[47159] DBG: chan_7 -> S READER OMNIKEY AG CardMan 3121 2019-12-09 18:15:07 scdaemon[47159] DBG: chan_7 -> S SERIALNO D27600012401020100050000572D0000 2019-12-09 18:15:07 scdaemon[47159] DBG: chan_7 -> S APPTYPE OPENPGP 2019-12-09 18:15:07 scdaemon[47159] DBG: chan_7 -> S EXTCAP gc=1+ki=1+fc=1+pd=1+mcl3=2048+aac=1+sm=0+si=5+dec=0+bt=0+kdf=0 2019-12-09 18:15:07 scdaemon[47159] DBG: chan_7 -> S DISP-NAME 2019-12-09 18:15:07 scdaemon[47159] DBG: chan_7 -> S DISP-LANG de 2019-12-09 18:15:07 scdaemon[47159] DBG: chan_7 -> S DISP-SEX 9 2019-12-09 18:15:07 scdaemon[47159] DBG: chan_7 -> S KEY-FPR 2 26CFCE98D4681687B9665A273341725A21249687 2019-12-09 18:15:07 scdaemon[47159] DBG: chan_7 -> S KEY-TIME 2 1575909434 2019-12-09 18:15:07 scdaemon[47159] DBG: chan_7 -> S CHV-STATUS +0+32+32+32+3+0+3 2019-12-09 18:15:07 scdaemon[47159] DBG: chan_7 -> S SIG-COUNTER 0 2019-12-09 18:15:07 scdaemon[47159] pcsc_transmit failed: not transacted (0x80100016) 2019-12-09 18:15:07 scdaemon[47159] apdu_send_simple(0) failed: general error 2019-12-09 18:15:07 scdaemon[47159] reading public key failed: General error 2019-12-09 18:15:07 scdaemon[47159] DBG: chan_7 -> S KEYPAIRINFO 2AF8CE28A1F0B6E3194C2505C682357407ACC3B3 OPENPGP.2 2019-12-09 18:15:07 scdaemon[47159] pcsc_transmit failed: not transacted (0x80100016) 2019-12-09 18:15:07 scdaemon[47159] apdu_send_simple(0) failed: general error 2019-12-09 18:15:07 scdaemon[47159] reading public key failed: General error 2019-12-09 18:15:07 scdaemon[47159] DBG: chan_7 -> OK 2019-12-09 18:15:07 scdaemon[47159] sending signal 31 to client 47158 2019-12-09 18:15:07 scdaemon[47159] DBG: Removal of a card: 0 2019-12-09 18:15:07 scdaemon[47159] DBG: chan_7 <- READKEY OPENPGP.2 2019-12-09 18:15:07 scdaemon[47159] DBG: chan_7 -> ERR 100663406 Card removed 2019-12-09 18:15:07 scdaemon[47159] DBG: chan_7 <- RESTART 2019-12-09 18:15:07 scdaemon[47159] DBG: chan_7 -> OK From wiktor at metacode.biz Mon Dec 9 21:40:27 2019 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Mon, 9 Dec 2019 21:40:27 +0100 Subject: Partial/fragmented decryption keys In-Reply-To: <3EC97DD9-43E3-47F8-8E11-02177C33E54A@icloud.com> Message-ID: <889dd8fb-bb74-d3d0-71d3-ab3745860a8a@metacode.biz> Hi, > I recall from the early days of PGP that there was a way to create a corporate key, fragmented into a certain number of potions, which would require some quorum to be able to perform decryption. I pored over the GnuPG documentation but could not find an equivalent. Perhaps I?m just getting the terminology wrong. Is this still possible in OpenPGP and therefore in GnuPG? It is indeed not implemented in GnuPG. In case you're curious on how does it work in Symantec PGP here's the description: https://support.symantec.com/us/en/article.HOWTO42097.html and a video tutorial: https://www.youtube.com/watch?v=Q_Mpa8TOhU0 Symantec recommends this feature for "extremely high security keys" by which I guess they mean designated revoker key or additional decryption key. Their implementation seems to bring all private keys to one trusted computer to reconstruct the combined key. As others mentioned there is a flag for marking an OpenPGP key as "split" in the spec so theoretically it could implemented in free software. One project that's close is DKGPG but mind that it "should NOT be used in production environments". Check out the following links: http://nongnu.org/dkgpg/ http://www.nongnu.org/libtmcg/kryptotag26_stamer_slides.pdf Hope this helps! Kind regards, Wiktor -- https://metacode.biz/@wiktor From oub at mat.ucm.es Tue Dec 10 12:46:14 2019 From: oub at mat.ucm.es (Uwe Brauer) Date: Tue, 10 Dec 2019 12:46:14 +0100 Subject: [RESOLVED?] (was: [gmx+gmail]) References: <87k17bqbqh.fsf__14890.3057490074$1575543713$gmane$org@mat.ucm.es> <87zhg6sa12.fsf__8737.69340557686$1575583645$gmane$org@mat.ucm.es> <87o8wms8ay.fsf_-_@mat.ucm.es> <56fc7b56-0756-748f-12bc-cedc93e15e50__37633.8987772883$1575747422$gmane$org@bruckner.tk> Message-ID: <87h828flo9.fsf_-_@mat.ucm.es> >>> "JBvG" == Juergen Bruckner via Gnupg-users writes: Hell Juergen > Hello Uwe, > i use Gmail for business for a very long time and never had any issue > like that. You are not going to belive that. I deactivated the s/mime support of gmail's webinterface and even deleted the certificate. Then everything worked as expected. I suspect that this internal s/mime support decrypts the message and copies it in my folder, which is really bad. Unfortunately I cannot investigate this issue, since my university lacks experts in that matter. Regards Uwe -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5025 bytes Desc: not available URL: From mwood at iupui.edu Tue Dec 10 16:09:39 2019 From: mwood at iupui.edu (Mark H. Wood) Date: Tue, 10 Dec 2019 10:09:39 -0500 Subject: gmail smime, sends two messages one is not encrypted. Experience? In-Reply-To: <20191207205916.00004d2b.sac@300baud.de> References: <87k17bqbqh.fsf@mat.ucm.es> <20191205233949.00004662.sac@300baud.de> <18098912-1343-f450-5c06-3c9fe49c7c7c@bruckner.tk> <20191207205916.00004d2b.sac@300baud.de> Message-ID: <20191210150939.GB7834@IUPUI.Edu> On Sat, Dec 07, 2019 at 08:59:16PM +0100, Stefan Claas via Gnupg-users wrote: > Juergen Bruckner via Gnupg-users wrote: > > Hi Juergen, > > > This question is very easy to answer. > > > > S/MIME has some advantages over (Open)PGP. > > One of them - the most important for the usual S/MIME users - is, that > > S/MIME allows the uniquely identification of a communication partner, > > which is only limitedly possible with PGP. > > > > In addition, educational institutions, such as universities, schools, > > research networks etc., have their own internal CA, which keeps the > > costs very manageable. > > Ah, o.k. with an own CA that make sense. However, I was also assuming > that students may use their certs also for 'outside' comms, which then > would require then that the other parties have always to import non- > trusted root certs, which is not the case with commercial ones, obtained > from globally trusted CAs. Here, the University has a deal with an academic consortium to provide cert.s chained back, ultimately, to a well-known commercial provider. I just submit a CSR to a website, a globally-valid cert. is issued to me in a few hours, and my department is not billed for anything. It's probably cheaper than all the paperwork required to process a requisition and chargeback. We use this, not only for email, but for websites and other network services, where there is no viable OpenPGP-based alternative. The ability to issue email certificates was actually added later, when the Powers That Be became increasingly concerned about phishing. > > Am 05.12.19 um 23:39 schrieb Stefan Claas via Gnupg-users: > > > Sorry, I can't help you but I do have a question, if you don't mind ... > > > > > > Why are the Students at the University don't use OpenPGP with Gmail > > > via the free Mailvelope add-on for Firefox, Chrome? Wouldn't that be > > > not cheaper instead of purchasing a whole lot of S/MIME certificates? -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From mwood at iupui.edu Tue Dec 10 16:50:08 2019 From: mwood at iupui.edu (Mark H. Wood) Date: Tue, 10 Dec 2019 10:50:08 -0500 Subject: gmail smime, sends two messages one is not encrypted. Experience? In-Reply-To: <20191207215134.00000301.sac@300baud.de> References: <87k17bqbqh.fsf@mat.ucm.es> <20191205233949.00004662.sac@300baud.de> <18098912-1343-f450-5c06-3c9fe49c7c7c@bruckner.tk> <20191207211127.000048d8.sac@300baud.de> <62bf59b7-1a9a-7577-ebaa-e9cc07e43d8d@bruckner.tk> <20191207215134.00000301.sac@300baud.de> Message-ID: <20191210155008.GC7834@IUPUI.Edu> On Sat, Dec 07, 2019 at 09:51:34PM +0100, Stefan Claas via Gnupg-users wrote: > Juergen BRUCKNER wrote: > > > Hi Stefan > > > > Thats not the approach PGP pursues. > > PGP was, is and should continue to be decentralized in the future. It > > was never really intended to validate identities in a wide circle, but > > to secure communication, and - im parts - to ensure the integrity of > > software. > > Well, the integrity of software can also be shown with a simple hash > value posted, because I can not verify if the sig belongs to person > xyz, even when he / she has a lot of fan sigs from people unknown to > me. Yes, if you trust that the page with the hash on it has not been compromised. Once the bad guy is inside the site, changing the hash is just as easy as replacing the software. Signatures depend on material that is *not* in the same place with the signed object (if we're doing it right) and thus can be verified from independent sources. Simple hashes can only detect simple failures. They have no value against a careful adversary. PKC, used properly, can raise the cost of compromise, by increasing the number of places that the bad guy must break into and get out of undetected. This is the electronic analog of a principle in physical security: require the bad guy to spend time, make noise, and create a visible mess, to increase his fear of being discovered to the point that the expectation of winning is not worth the expectation of losing. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From mwood at iupui.edu Tue Dec 10 17:01:19 2019 From: mwood at iupui.edu (Mark H. Wood) Date: Tue, 10 Dec 2019 11:01:19 -0500 Subject: gmail smime, sends two messages one is not encrypted. Experience? In-Reply-To: <87h82bf97g.fsf@mat.ucm.es> References: <87k17bqbqh.fsf@mat.ucm.es> <20191205233949.00004662.sac__47704.6530855418$1575585672$gmane$org@300baud.de> <87h82bf97g.fsf@mat.ucm.es> Message-ID: <20191210160119.GD7834@IUPUI.Edu> On Sun, Dec 08, 2019 at 10:38:43AM +0100, Uwe Brauer via Gnupg-users wrote: > Now to the question s/mime versus gnupg. > > There are the following points which make s/mime easier. > > 1. Key generation. In s/mime you apply for a certificate and don't > have to generate the key by yourself. Oh, I hope not. The point of asymmetric crypto is that you never, ever, give your private key to anyone, even, *especially*, the CA. The proper way to get an X.509 certificate is to generate a keypair, keep the private key private, and send a CSR containing the public key to the entity which will issue the certificate. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From oub at mat.ucm.es Tue Dec 10 18:20:55 2019 From: oub at mat.ucm.es (Uwe Brauer) Date: Tue, 10 Dec 2019 18:20:55 +0100 Subject: gmail smime, sends two messages one is not encrypted. Experience? References: <87k17bqbqh.fsf@mat.ucm.es> <20191205233949.00004662.sac__47704.6530855418$1575585672$gmane$org@300baud.de> <87h82bf97g.fsf@mat.ucm.es> <20191210160119.GD7834__3637.17157613195$1575995772$gmane$org@IUPUI.Edu> Message-ID: <87blsgf66g.fsf@mat.ucm.es> >>> "MHWvG" == Mark H Wood via Gnupg-users writes: > On Sun, Dec 08, 2019 at 10:38:43AM +0100, Uwe Brauer via Gnupg-users wrote: >> Now to the question s/mime versus gnupg. >> >> There are the following points which make s/mime easier. >> >> 1. Key generation. In s/mime you apply for a certificate and don't >> have to generate the key by yourself. > Oh, I hope not. The point of asymmetric crypto is that you never, > ever, give your private key to anyone, even, *especially*, the CA. > The proper way to get an X.509 certificate is to generate a keypair, > keep the private key private, and send a CSR containing the public key > to the entity which will issue the certificate. Ah, sorry for the sloppy formulation. You are completely right. The process is, usually[1], as follows 1. For example using Comodo, you apply for a certificate. 2. Your keypair is generated by your own crypt module of the browser (quite some time ago I had a look at the corresponding javascript and it did not look suspicious). 3. You receive a link via email, which you have to open with the same browser and the same computer and your keys get signed. However the user usually does not notice all these steps, and this is what I meant. In the case for pgp the user has to generate a keypair him/herself and believe me, for most users this is much more complicated than 'applying for a certicate in comodo'. Footnotes: [1] there is one exception https://www.actalis.it/products/certificates-for-secure-electronic-mail.aspx they really generate a keypair and send it to you, no kidding. That seems to me a mayor security breach, to say the least -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5025 bytes Desc: not available URL: From juergen at bruckner.tk Tue Dec 10 18:20:57 2019 From: juergen at bruckner.tk (Juergen Bruckner) Date: Tue, 10 Dec 2019 18:20:57 +0100 Subject: gmail smime, sends two messages one is not encrypted. Experience? In-Reply-To: <20191210160119.GD7834@IUPUI.Edu> References: <87k17bqbqh.fsf@mat.ucm.es> <20191205233949.00004662.sac__47704.6530855418$1575585672$gmane$org@300baud.de> <87h82bf97g.fsf@mat.ucm.es> <20191210160119.GD7834@IUPUI.Edu> Message-ID: <9a788b7a-b37b-839c-d64f-a26025fe5b42@bruckner.tk> Sadly i know many CA's who don't give the user any choice about this. They say as a 'user friendly service' they generate also the key for the user and send him a .p12-file. Am 10.12.19 um 17:01 schrieb Mark H. Wood via Gnupg-users: > > Oh, I hope not. The point of asymmetric crypto is that you never, > ever, give your private key to anyone, even, *especially*, the CA. > The proper way to get an X.509 certificate is to generate a keypair, > keep the private key private, and send a CSR containing the public key > to the entity which will issue the certificate. > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- Juergen M. Bruckner juergen at bruckner.tk -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3894 bytes Desc: S/MIME Cryptographic Signature URL: From sac at 300baud.de Tue Dec 10 18:31:26 2019 From: sac at 300baud.de (Stefan Claas) Date: Tue, 10 Dec 2019 18:31:26 +0100 Subject: gmail smime, sends two messages one is not encrypted. Experience? In-Reply-To: <20191210155008.GC7834@IUPUI.Edu> References: <87k17bqbqh.fsf@mat.ucm.es> <20191205233949.00004662.sac@300baud.de> <18098912-1343-f450-5c06-3c9fe49c7c7c@bruckner.tk> <20191207211127.000048d8.sac@300baud.de> <62bf59b7-1a9a-7577-ebaa-e9cc07e43d8d@bruckner.tk> <20191207215134.00000301.sac@300baud.de> <20191210155008.GC7834@IUPUI.Edu> Message-ID: <20191210183126.00002056.sac@300baud.de> Mark H. Wood via Gnupg-users wrote: > On Sat, Dec 07, 2019 at 09:51:34PM +0100, Stefan Claas via Gnupg-users wrote: > > Juergen BRUCKNER wrote: > > > > > Hi Stefan > > > > > > Thats not the approach PGP pursues. > > > PGP was, is and should continue to be decentralized in the future. It > > > was never really intended to validate identities in a wide circle, but > > > to secure communication, and - im parts - to ensure the integrity of > > > software. > > > > Well, the integrity of software can also be shown with a simple hash > > value posted, because I can not verify if the sig belongs to person > > xyz, even when he / she has a lot of fan sigs from people unknown to > > me. > > Yes, if you trust that the page with the hash on it has not been > compromised. Once the bad guy is inside the site, changing the hash > is just as easy as replacing the software. Signatures depend on > material that is *not* in the same place with the signed object (if > we're doing it right) and thus can be verified from independent > sources. > > Simple hashes can only detect simple failures. They have no value > against a careful adversary. The software author(s) can simply provide a, via blockchain, timestamped record[1] of the original hash value. Additionally, from time to time, a timestamped warrant canary would be welcome addition too. P.S. I have read recently that one can only trust software he / she has written themselves ... ;-D [1] https://opentimestamps.org/ Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From sac at 300baud.de Tue Dec 10 18:53:32 2019 From: sac at 300baud.de (Stefan Claas) Date: Tue, 10 Dec 2019 18:53:32 +0100 Subject: gmail smime, sends two messages one is not encrypted. Experience? In-Reply-To: <20191210183126.00002056.sac@300baud.de> References: <87k17bqbqh.fsf@mat.ucm.es> <20191205233949.00004662.sac@300baud.de> <18098912-1343-f450-5c06-3c9fe49c7c7c@bruckner.tk> <20191207211127.000048d8.sac@300baud.de> <62bf59b7-1a9a-7577-ebaa-e9cc07e43d8d@bruckner.tk> <20191207215134.00000301.sac@300baud.de> <20191210155008.GC7834@IUPUI.Edu> <20191210183126.00002056.sac@300baud.de> Message-ID: <20191210185332.000011eb.sac@300baud.de> Stefan Claas via Gnupg-users wrote: > Mark H. Wood via Gnupg-users wrote: > > > On Sat, Dec 07, 2019 at 09:51:34PM +0100, Stefan Claas via Gnupg-users > > wrote: > > > Juergen BRUCKNER wrote: > > > > > > > Hi Stefan > > > > > > > > Thats not the approach PGP pursues. > > > > PGP was, is and should continue to be decentralized in the future. It > > > > was never really intended to validate identities in a wide circle, but > > > > to secure communication, and - im parts - to ensure the integrity of > > > > software. > > > > > > Well, the integrity of software can also be shown with a simple hash > > > value posted, because I can not verify if the sig belongs to person > > > xyz, even when he / she has a lot of fan sigs from people unknown to > > > me. > > > > Yes, if you trust that the page with the hash on it has not been > > compromised. Once the bad guy is inside the site, changing the hash > > is just as easy as replacing the software. Signatures depend on > > material that is *not* in the same place with the signed object (if > > we're doing it right) and thus can be verified from independent > > sources. > > > > Simple hashes can only detect simple failures. They have no value > > against a careful adversary. > > The software author(s) can simply provide a, via blockchain, timestamped > record[1] of the original hash value. Additionally, from time to time, a > timestamped warrant canary would be welcome addition too. P.S. And regarding PGP signatures, for security software releases; a *super nice* gesture, which would IMHO have a major impact in the OpenPGP ecosystem, would be if authors of security software which are German nationals would have *certified* their software signing keys by the German CA Governikus[2]. [2] https://pgp.governikus.de/pgp/ Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas From gniibe at fsij.org Wed Dec 11 08:44:06 2019 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 11 Dec 2019 16:44:06 +0900 Subject: v2.1 openpgp smartcard -- packing in after a `key to card' In-Reply-To: References: Message-ID: <87tv6771dl.fsf@jumper.gniibe.org> Dirk-Willem van Gulik wrote: > During a pretty standard create key; key to card cycle (scripted) - I got an error > > gpg: OpenPGP card not available: Card removed > > just after the ?save? in the ?edit-key. A subsequent status check gives me: > > gpg2 --card-status > gpg: OpenPGP card not available: Card removed > > with below scdaemon log information. Unfortunately, your log only includes information _after_ the failure. So, I could only guess about failure. I guess that "key to card" was failed for some reason. > 2019-12-09 18:15:06 scdaemon[47159] detected reader 'SCM Microsystems Inc. SPR 532' > 2019-12-09 18:15:06 scdaemon[47159] detected reader 'ACS ACR122U PICC Interface' > 2019-12-09 18:15:06 scdaemon[47159] detected reader 'OMNIKEY AG CardMan 3121' While you have three card readers... > 2019-12-09 18:15:07 scdaemon[47159] DBG: chan_7 -> S READER OMNIKEY AG CardMan 3121 What you were using was "OMNIKEY AG CardMan 3121", which only supports short APDU level exchange. It is listed in this list: https://ccid.apdu.fr/ccid/supported.html It should work for 1024-bit key. However, I'm afraid that probably, it doesn't work well with recent PC/SC lite, because readers with short APDU level exchange only are getting uncommon. SCM SPR 532 works better, because it supports TPDU level exchance (lower level). -- From aajaxx at gmail.com Wed Dec 11 22:12:01 2019 From: aajaxx at gmail.com (Ajax) Date: Wed, 11 Dec 2019 21:12:01 +0000 Subject: gpg-agent relocation error Message-ID: The command: gpg-agent --version gives me the following output: /------- gpg-agent: relocation error: gpg-agent: symbol assuan_sock_set_system_hooks, version LIBASSUAN_1.0 not defined in file libassuan.so.0 with link time referencel \------- libassuan.so.0 is linked to libassuan.so.0.8.3. I have a compressed 163K copy which is too large to attach heree on thei list but which can mail directly if someone can use it to help me. This version of gpg-agent was built with the following commands: /------- cd gnupg-2.2.19 LD_LIBRARY_PATH=$(pwd)/PLAY/inst/lib export PATH LD_LIBRARY_PATH make -f build-aux/speedo.mk native \ INSTALL_PREFIX="$HOME" \ > ../gnupg-2.2.19.speedo-output \ 2>../gnupg-2.219.speedo-errorout \------- This is on a Debian 9.11 (stretch) box with a Linux 4.9.0-11 amd64 kernel. I have seen this problem for a long time but I remain stumped on it. What should I be looking for? Why did not testing the binaries using LD_LIBRARY_PATH show a problem? What in the speedo outputs indicates that the binaries were tested? Thank you. --ajax -- From johanw at vulcan.xs4all.nl Wed Dec 11 23:24:38 2019 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Wed, 11 Dec 2019 23:24:38 +0100 Subject: gpg-agent relocation error In-Reply-To: References: Message-ID: <70f6fc15-ca83-5c8f-eb76-5fb068b5c850@vulcan.xs4all.nl> On 11-12-2019 22:12, Ajax via Gnupg-users wrote: > The command: gpg-agent --version gives me the following output: > > /------- > gpg-agent: relocation error: gpg-agent: symbol > assuan_sock_set_system_hooks, version LIBASSUAN_1.0 not defined in > file libassuan.so.0 with link time referencel > \------- > > libassuan.so.0 is linked to libassuan.so.0.8.3. That's quite an ancient version, current version is 2.5.3. My first guess is to upgrade libassuan. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From wk at gnupg.org Thu Dec 12 10:45:13 2019 From: wk at gnupg.org (Werner Koch) Date: Thu, 12 Dec 2019 10:45:13 +0100 Subject: gpg-agent relocation error In-Reply-To: <70f6fc15-ca83-5c8f-eb76-5fb068b5c850@vulcan.xs4all.nl> (Johan Wevers's message of "Wed, 11 Dec 2019 23:24:38 +0100") References: <70f6fc15-ca83-5c8f-eb76-5fb068b5c850@vulcan.xs4all.nl> Message-ID: <87eex9lvx2.fsf@wheatstone.g10code.de> On Wed, 11 Dec 2019 23:24, Johan Wevers said: >> libassuan.so.0 is linked to libassuan.so.0.8.3. > > That's quite an ancient version, current version is 2.5.3. My first Nope. Assuming this is a standard Linux distor, this is the lates versions. The name of the libary includes the *SO version* which is another name for the ABI. The 2.5.3 is the software version - software verion and SO version are different. The problem here is that GnuPg was build using a newer Libassuan version but the runtime linker picks up an older version. Set LD_LIBARY_PATH and things will be good. Or put /usr/local/lib into your ld.so.conf so that they are picked up. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From aajaxx at gmail.com Thu Dec 12 20:51:04 2019 From: aajaxx at gmail.com (Ajax) Date: Thu, 12 Dec 2019 19:51:04 +0000 Subject: gpg-agent relocation error In-Reply-To: <87eex9lvx2.fsf@wheatstone.g10code.de> References: <70f6fc15-ca83-5c8f-eb76-5fb068b5c850@vulcan.xs4all.nl> <87eex9lvx2.fsf@wheatstone.g10code.de> Message-ID: On Thu, Dec 12, 2019 at 10:33 AM Werner Koch via Gnupg-users wrote: > > On Wed, 11 Dec 2019 23:24, Johan Wevers said: > > >> libassuan.so.0 is linked to libassuan.so.0.8.3. > > > > That's quite an ancient version, current version is 2.5.3. My first > > Nope. Assuming this is a standard Linux distor, this is the lates > versions. The name of the libary includes the *SO version* which is > another name for the ABI. The 2.5.3 is the software version - software > verion and SO version are different. > > The problem here is that GnuPg was build using a newer Libassuan version > but the runtime linker picks up an older version. Set LD_LIBARY_PATH > and things will be good. Or put /usr/local/lib into your ld.so.conf so > that they are picked up. > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > Thank you for your quick and clear response; however I must still be missing something. With $ printenv LD_LIBRARY_PATH giving /..../src/gnupg/gnupg-2.2.19/PLAY/inst/lib $ gpg-agent --version gives the same relocation error as before. What should I try now? --ajax -- _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From npy at gmx.com Fri Dec 13 07:14:23 2019 From: npy at gmx.com (npy at gmx.com) Date: Fri, 13 Dec 2019 07:14:23 +0100 Subject: gnupg private-keys encryption Message-ID: Hi, Gnupg (installed from debian repositories) seems to ignore cipher/digest preferences while encrypting the key. Below are the options I've in my gpg.conf. personal-digest-preferences SHA512 personal-cipher-preferences AES256 personal-compress-preferences Uncompressed digest-algo SHA512 cipher-algo AES256 s2k-mode 3 s2k-count 65011712 s2k-digest-algo SHA512 s2k-cipher-algo AES256 However, --export-secret-keys followed by --list-packets shows, "iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: ", and in the binary *.key file from the private-keys dir, ".. protected25:openpgp-s2k3-sha1-aes-cbc .." leads me to believe that the key is encrypted with SHA1/AES. How can I control the encryption on the private-key? Thanks From gusnan at librem.one Fri Dec 13 13:53:30 2019 From: gusnan at librem.one (Andreas Ronnquist) Date: Fri, 13 Dec 2019 13:53:30 +0100 Subject: pinentry-gtk-2 dialog doesn't appear before getting input Message-ID: <20191213135330.063c70f8@debian-i7> Hi! I have a problem on Debian unstable (running in Virtualbox), running the Xfce desktop - I have my gpg key on a card (a Librem key, which basically is a Nitrokey) when using pinentry to enter the card password, I first have to press my mouse on the screen (or a key on my keyboard) to make the password dialog appear. For example: Doing gpg --clearsign [somefile] prints gpg: using [long key fingerprint] as default secret key for signing and the librem key light starts flashing. After a short time it stops flashing, and does nothing. What it actually does is waiting for me to start typing, or pressing the mouse button - as soon as I do this the dialog appears. Before this I can only guess if it is ready for my to enter the passphrase, or still doing something non-visible. And if I do nothing, it of course times out after a while. This is when using pinentry-gtk-2. Is there any way to make the dialog appear at once, when it is ready to take my passphrase entry, or some workaround of any kind? Is this a known bug? I have found https://dev.gnupg.org/T2434 , but that seems to be a bit different. -- Andreas R?nnquist mailinglists at gusnan.se andreas at ronnquist.net [Please don't CC me, if I mail to a mailinglist, I am subscribed to it.] From rjh at sixdemonbag.org Sat Dec 14 17:51:02 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 14 Dec 2019 11:51:02 -0500 Subject: gnupg private-keys encryption In-Reply-To: References: Message-ID: > How can I control the encryption on the private-key? Change the passphrase. Just changing configuration file preferences doesn't change the way the key is stored on disk. It only says "the next time you have to alter the way the key is stored on disk, use these new parameters". Changing the passphrase on the key will force GnuPG to write it out to disk again, at which point your new preferences will take effect. Warning: this information was correct for GnuPG 1.4 and 2.0. I'm not sure about 2.2, as I've never needed to do it on 2.2. From mistave at countermail.com Sat Dec 14 23:18:32 2019 From: mistave at countermail.com (Defiant) Date: Sat, 14 Dec 2019 23:18:32 +0100 Subject: Modern gnupg.conf setup Message-ID: Hey, I recall back in the days there were lots of online tutorials about how to strengthen your GnuPG configuration. I'm setting up my gnupg.conf environment and I was wondering which of these options still apply for todays standards (GnuPG v2.2). Thanks. no-emit-version no-comments export-options export-minimal keyid-format 0xlong with-fingerprint list-options show-uid-validity verify-options show-uid-validity personal-cipher-preferences AES256 personal-digest-preferences SHA512 default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES TWOFISH ZLIB BZIP2 ZIP Uncompressed cipher-algo AES256 digest-algo SHA512 cert-digest-algo SHA512 compress-algo ZLIB disable-cipher-algo 3DES IDEA CAST5 Blowfish weak-digest SHA1 s2k-cipher-algo AES256 s2k-digest-algo SHA512 s2k-mode 3 s2k-count 65011712 From rjh at sixdemonbag.org Sun Dec 15 01:31:55 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 14 Dec 2019 19:31:55 -0500 Subject: Modern gnupg.conf setup In-Reply-To: References: Message-ID: > Hey, I recall back in the days there were lots of online tutorials about > how to strengthen your GnuPG configuration. I'm setting up my gnupg.conf > environment and I was wondering which of these options still apply for > todays standards (GnuPG v2.2). The standard advice still applies: unless you know what you're doing and why it's necessary, just stick with the defaults. :) GnuPG 2.2 runs quite well with a minimal config. That said, I'll try to answer your question! > no-emit-version > no-comments > export-options export-minimal > keyid-format 0xlong > with-fingerprint All still valid, all still useful. > list-options show-uid-validity > verify-options show-uid-validity Valid. Whether they're useful depends a lot on your personal needs. I don't have much use for them, but your needs might be different from mine. > personal-cipher-preferences AES256 > personal-digest-preferences SHA512 Please don't: you're possibly harming interoperability. Although AES256 is a strong and well-supported cipher, you'll find other people who don't have it listed on their key preferences. In that case, you will silently degrade to 3DES, which is widely considered the worst cipher in OpenPGP. It's slow, it's inefficient, and it has inherent risks when encrypting large files due to its 64-bit block size. (It is also overengineered like a Soviet workers' housing bloc. No one is aware of any cryptographic attacks on it, other than when used with very large files. Still: slow and inefficient.) Likewise, if you encounter someone who for whatever reason can't use SHA512 (like if they're using the old, but still encountered, PGP 8.1), you will silently degrade to using SHA-1, which I don't think you want to do. Instead, try this: personal-cipher-preferences AES256 CAMELLIA256 TWOFISH AES192 CAMELLIA192 AES CAMELLIA128 personal-digest-preferences SHA512 SHA384 SHA256 SHA224 RIPEMD160 This way, if your correspondent can't use AES256 GnuPG will degrade to the (strong, modern, fast) CAMELLIA algorithm. If that's a no-go, degrade to the (strong, modern, fast) 256-bit TWOFISH algorithm. If the 256-bit ciphers are all a no-go, it degrades to 192-bit AES and CAMELLIA, then the 128-bit variants. Only if *no* modern cipher is available will it then degrade to 3DES. The same logic applies to SHA512. It will exhaust all the modern hashes before degrading to the (old, probably not very reliable any more, but still better than SHA-1) RIPEMD160 algorithm, and only if all of them are a no-go will it fall to SHA-1. > default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES > TWOFISH ZLIB BZIP2 ZIP Uncompressed Why do you prefer 128-bit AES over 256-bit TWOFISH? > cipher-algo AES256 > digest-algo SHA512 *These are probably bad ideas.* These say "screw what I just said about my preference lists, ONLY use AES256 and SHA512" -- which can make your message traffic non-interoperable with people who, for whatever reason, cannot use AES256 or SHA512. > cert-digest-algo SHA512 Still valid, still useful. > compress-algo ZLIB Scratch this for the same reasons as scratching "cipher-algo" and "digest-algo". Let GnuPG use a compression algorithm your correspondent can actually use: don't force GnuPG to use one your correspondent can't use. 20 years ago it was widely believed compression before encryption was a good idea. Today that belief is pretty much shot, given how most file formats already incorporate compression. You can remove this line entirely. > disable-cipher-algo 3DES IDEA CAST5 Blowfish 3DES is a MUST algorithm, according to the spec. If you want to disable the others that's your business -- but it's already implicit by not including them in your personal-cipher-preferences. This line can be removed entirely. > weak-digest SHA1 Again, SHA-1 is a MUST. > s2k-cipher-algo AES256 > s2k-digest-algo SHA512 These are implicit given your personal-cipher-preferences and personal-digest-preferences, and can be removed. > s2k-mode 3 This is the default, and as such it can be removed. > s2k-count 65011712 I have never found any use for cranking s2k-count this high. I'd suggest removing this line and using the defaults unless you have a specific need for such a high count. From dgouttegattat at incenp.org Sun Dec 15 03:07:57 2019 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sun, 15 Dec 2019 02:07:57 +0000 Subject: Modern gnupg.conf setup In-Reply-To: References: Message-ID: <20191215020757.4bvzje3jvlglsieb@dynein.local.incenp.org> On Sat, Dec 14, 2019 at 11:18:32PM +0100, Defiant wrote: >Hey, I recall back in the days there were lots of online tutorials about >how to strengthen your GnuPG configuration. I don?t know which tutorials exactly you?re referring to, but I have seen several of them myself, and I have always had the feeling that they were written by people who couldn?t be bothered to check what GnuPG?s default configuration actually is before deciding it needed to be ?strengthened?? >no-emit-version >no-comments Not needed, those are the defaults. >export-options export-minimal That?s up to you. Note, this does not actually ?strengthen? anything. >keyid-format 0xlong >with-fingerprint For information, the default is not to display any key ID (either short or long) but to display the full fingerprint instead (which makes displaying the key ID quite irrelevant). Setting keyid-format to either ?short? or ?long? however has the effect of forcing GnuPG to display the key ID of *subkeys*, so if that?s something you need, you may keep that line. >list-options show-uid-validity >verify-options show-uid-validity Already enabled by default. >personal-cipher-preferences AES256 The default is AES256, AES192, AES128, 3DES. Note that you cannot remove 3DES which is mandatory as per the RFC 4880 (that?s the only algorithm which is guaranteed to be supported by any compliant OpenPGP implementation): even if you do not include it, GnuPG will silently add it back. By removing AES192 and AES128, you?re actually increasing the risk that GnuPG will have to fallback to 3DES if AES256 is not supported by the other party. I don?t think this is what you want. >personal-digest-preferences SHA512 The default is SHA256, SHA384, SHA512, SHA-224, SHA1, with SHA1 being mandatory. Same problem as above: by limiting GnuPG?s options, you are increasing the risk of having to fallback to SHA1. >default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES >TWOFISH ZLIB BZIP2 ZIP Uncompressed This is almost exactly the default list, except that the default list does not include TWOFISH. >cipher-algo AES256 >digest-algo SHA512 >cert-digest-algo SHA512 >compress-algo ZLIB You are basically bypassing the whole preference-based mechanism used to select algorithms compatible with your recipients? implementation. Almost certainly a bad idea unless you are operating in a context where you know you don?t need to care about interoperability (e.g. if you are only encrypting files for yourself). >disable-cipher-algo 3DES IDEA CAST5 Blowfish >weak-digest SHA1 3DES and SHA1 are mandatory as said above. The other algorithms are already not used by default. >s2k-cipher-algo AES256 >s2k-digest-algo SHA512 >s2k-mode 3 >s2k-count 65011712 The default S2K mode is already 3 (iter+salt). As for the S2K count, for information the default is a value automatically determined by GPG Agent so that, on your computer, running the S2K algorithm will take ~100ms. Overall I?d say most of your configuration is either uneeded or even counterproductive. I?ll quote GnuPG?s FAQ [1]: > Does GnuPG need to be ?tuned? before use? > No. GnuPG has sensible defaults right out of the box. Cheers, - Damien [1] https://gnupg.org/faq/gnupg-faq.html#tuning -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From dgray4656 at yahoo.com Sun Dec 15 02:05:04 2019 From: dgray4656 at yahoo.com (dgray4656 at yahoo.com) Date: Sat, 14 Dec 2019 20:05:04 -0500 Subject: Usability of OpenSSL vs GNUPG References: <000f01d5b2e3$afdcef70$0f96ce50$.ref@yahoo.com> Message-ID: <000f01d5b2e3$afdcef70$0f96ce50$@yahoo.com> I've been playing around some with OpenSSL recently, and it seems to me that the OpenSSL command structure is rather convoluted. I've read a number of articles, blog posts, etc. that criticize GNUPG and even make the case that people should stop using it, in large part because of concerns around the GNUPG command structure and general usability. Yet I can't recall encountering any similar complaints about OpenSSL. I find this somewhat curious, and am wondering if there are OpenSSL detractors out there that I simply haven't come across or if the OpenSSL command structure isn't as complicated as it seems to me. Or if it seems to others that OpenSSL doesn't get the same level of criticism as GNUPG does for usability, although the tools seem to offer a generally similar user experience. I suppose that OpenSSL is geared toward a very technical and security-aware user base, who aren't likely to complain about usability issues - while GNUPG is a tool that could be used by all sorts of users, some of whom are definitely not technically inclined or interested in details of information security. That alone could explain the difference, I suppose. But I'm wondering if anyone has any other thoughts around this topic. Thanks, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From mistave at countermail.com Sun Dec 15 13:33:14 2019 From: mistave at countermail.com (Defiant) Date: Sun, 15 Dec 2019 13:33:14 +0100 Subject: Modern gnupg.conf setup In-Reply-To: References: Message-ID: <0bf51e63-ae66-7c71-f577-79959bb9b16a@countermail.com> Thank you kindly for your very informative answers. It seems I was right to have asked here after all. It's amazing how many outdated tutorials exist i.e. googling for "perfect pgp keypair" gives at least three "wrong" articles among the top few results. Having read the GnuPG docs a bit it appears a lot of options I listed are already enabled by default by a recent gpg, so I removed them. On 15. 12. 19 01:31, Robert J. Hansen wrote:> > Instead, try this: > > personal-cipher-preferences AES256 CAMELLIA256 TWOFISH AES192 > CAMELLIA192 AES CAMELLIA128 > personal-digest-preferences SHA512 SHA384 SHA256 SHA224 RIPEMD160 > Should these also be included in the default-preference-list? I think the latter is only used when generating new keys (setpref), yes? Alas: personal-cipher-preferences AES256 CAMELLIA256 TWOFISH AES192 CAMELLIA192 AES CAMELLIA128 personal-digest-preferences SHA512 SHA384 SHA256 SHA224 RIPEMD160 default-preference-list SHA512 SHA384 SHA256 SHA224 RIPEMD160 AES256 CAMELLIA256 TWOFISH AES192 CAMELLIA192 AES CAMELLIA128 ZLIB BZIP2 ZIP Uncompressed >> cert-digest-algo SHA512 > > Still valid, still useful. > This I'm uncertain about. Should probably be removed too? The documentation says: --cert-digest-algo name Use name as the message digest algorithm used when signing a key. Running the program with the command --version yields a list of supported algorithms. *Be aware that if you choose an algorithm that GnuPG supports but other OpenPGP implementations do not, then some users will not be able to use the key signatures you make, or quite possibly your entire key.* Source: https://www.gnupg.org/documentation/manuals/gnupg/GPG-Esoteric-Options.html#GPG-Esoteric-Options >> disable-cipher-algo 3DES IDEA CAST5 Blowfish > > 3DES is a MUST algorithm, according to the spec. If you want to disable > the others that's your business -- but it's already implicit by not > including them in your personal-cipher-preferences. This line can be > removed entirely. > >> weak-digest SHA1 > > Again, SHA-1 is a MUST. > The RFC 4880 standard (section 9) does say that 3DES and SHA-1 must be implemented, but the reason I included these is because I read on some websites that you do NOT want to use these at all due to their weaknesses and there should be some way of warning the user that weak algorithms are being used. disable-cipher-algo 3DES weak-digest SHA1 If some client can't support newer algorithms like SHA-2 and AES then it's better if that person upgraded their software rather than continue to use SHA-1 and 3DES. Best regards, Mistave. From bex at pobox.com Sun Dec 15 17:41:30 2019 From: bex at pobox.com (Brian Exelbierd) Date: Sun, 15 Dec 2019 17:41:30 +0100 Subject: Usability of OpenSSL vs GNUPG In-Reply-To: <000f01d5b2e3$afdcef70$0f96ce50$@yahoo.com> References: <000f01d5b2e3$afdcef70$0f96ce50$.ref@yahoo.com> <000f01d5b2e3$afdcef70$0f96ce50$@yahoo.com> Message-ID: <9c3980b5-5e35-405f-b80e-6def6f9c864b@www.fastmail.com> Hi, On Sun, Dec 15, 2019, at 2:05 AM, Dave via Gnupg-users wrote: > I?ve been playing around some with OpenSSL recently, and it seems to me > that the OpenSSL command structure is rather convoluted. I?ve read a > number of articles, blog posts, etc. that criticize GNUPG and even make > the case that people should stop using it, in large part because of > concerns around the GNUPG command structure and general usability. Most of the criticism I have seen is that it is difficult for the target users of a specific use case to use gpg effectively to protect themselves. This is things like message/email encryption/verification. > Yet > I can?t recall encountering any similar complaints about OpenSSL. I > find this somewhat curious, and am wondering if there are OpenSSL > detractors out there that I simply haven?t come across or if the > OpenSSL command structure isn?t as complicated as it seems to me. Or if > it seems to others that OpenSSL doesn?t get the same level of criticism > as GNUPG does for usability, although the tools seem to offer a > generally similar user experience. I haven't seen OpenSSL pitched as the GPG replacement here, possibly for the reasons you cite. Mostly I see, use application X (Signal, etc.) and don't believe email can reasonably be secured without ALL parties being "experts" at GPG. The one use case no one seems to have a replacement for is "encrypt this file on disk for me to use later." > I suppose that OpenSSL is geared toward a very technical and > security-aware user base, who aren?t likely to complain about usability > issues ? while GNUPG is a tool that could be used by all sorts of > users, some of whom are definitely not technically inclined or > interested in details of information security. That alone could explain > the difference, I suppose. But I?m wondering if anyone has any other > thoughts around this topic. My understanding is that most people encounter OpenSSL configured by someone else who is presumably a technical expert. What usecases do you have in mind? regards, bex > > > Thanks, > > > Dave > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From rjh at sixdemonbag.org Sun Dec 15 19:32:39 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 15 Dec 2019 13:32:39 -0500 Subject: Modern gnupg.conf setup In-Reply-To: <0bf51e63-ae66-7c71-f577-79959bb9b16a@countermail.com> References: <0bf51e63-ae66-7c71-f577-79959bb9b16a@countermail.com> Message-ID: <025efc75-9204-d983-2bf1-fe4345049031@sixdemonbag.org> > It seems I was right to have asked here after all. It's amazing how many > outdated tutorials exist... That presumes they were ever accurate in the first place. Many of them were not. >> personal-cipher-preferences AES256 CAMELLIA256 TWOFISH AES192 >> CAMELLIA192 AES CAMELLIA128 >> personal-digest-preferences SHA512 SHA384 SHA256 SHA224 RIPEMD160 > > Should these also be included in the default-preference-list? I think > the latter is only used when generating new keys (setpref), yes? Not necessarily. Personal-cipher-preferences is the list of ciphers you're willing to use, but the list of ciphers on your key (what's put there via setpref) is the list of ciphers you ask *other people* to use. Will they often be the same? Yes. But not always, and there's a subtlety there that's often overlooked. You might be willing to generate traffic using ciphers you're not willing to accept. >>> cert-digest-algo SHA512 >> >> Still valid, still useful. > > This I'm uncertain about. Should probably be removed too? Probably not. The reason why cipher-algo and digest-algo are recommended against is because GnuPG already has a robust mechanism for choosing a strong cipher that you're willing to generate (via personal-cipher-preferences) and the recipient is willing to receive (via prefs on the key). There is no such mechanism for certificate signatures. That's entirely generated by you. You have zero knowledge of what algorithm other people will use. If you want maximum interoperability, you have to use SHA-1; everyone can read SHA-1 signatures. But that's SHA-1, and SHA-1 isn't exactly a highly recommended digest any more. Use something better and stronger. SHA512 is probably the best option right now. If someone can't read your certificate signatures, well -- that's on them: they should be moving away from SHA-1. > The RFC 4880 standard (section 9) does say that 3DES and SHA-1 must be > implemented, but the reason I included these is because I read on some > websites that you do NOT want to use these at all due to their > weaknesses and there should be some way of warning the user that weak > algorithms are being used. I question the credentials of anyone calling 3DES "weak". It has one and only one serious cryptographic weakness: due to its 64-bit block size, it should not be used to encrypt more than about 4Gb of data with the same session key. 40 years after it was first released, the best attack on it is a meet-in-the-middle that requires -- hand to God, I am not making this up -- 64 pebibytes of RAM, 2**112 operations, and several strategic nuclear weapons to generate enough energy to run the computer. Let me repeat: I am not making that up. So, yeah, if your attacker has technology straight out of _Star Trek_ and is willing to cause untold ecological catastrophe, you're hosed. Otherwise, 3DES is still solid. That's not to mean it's perfect. It's not. It's slow, it shouldn't be used to encrypt bulk data due to its 64-bit blocksize, and more. There are lots of reasons to prefer other, better ciphers than 3DES. And maybe I can understand people calling it "weak" because really, that's a lot easier for people to understand than talking about block sizes and clock-cycles-per-block and everything else. But it's *not weak*. And any website that tells you to avoid 3DES because it's weak is, to be honest, either too ignorant to be taken seriously, so patronizing they'll handwave away complex issues behind the comforting veneer of "it's weak", or is outright lying to you. SHA-1, on the other hand... *At the present moment* SHA-1 is still trustworthy in the places where it's baked into the RFC4880 spec. The attacks against it don't affect the (few) places where it's baked into OpenPGP. But attacks can get better quite suddenly, and it's a good idea to avoid SHA-1 whenever possible. But please don't use weak-digest on SHA-1. The only thing it'll do is drown you in false positives. 99.999% of the time when you get a warning of "SHA-1 is being used!!!! You asked me to warn you about it!!!!!", in fact nothing is amiss at all. A 'warning' that's wrong 99.999% of the time is worse than receiving no warning at all. From dgouttegattat at incenp.org Sun Dec 15 19:49:17 2019 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sun, 15 Dec 2019 18:49:17 +0000 Subject: Usability of OpenSSL vs GNUPG In-Reply-To: <000f01d5b2e3$afdcef70$0f96ce50$@yahoo.com> References: <000f01d5b2e3$afdcef70$0f96ce50$.ref@yahoo.com> <000f01d5b2e3$afdcef70$0f96ce50$@yahoo.com> Message-ID: <20191215184917.6hkyd5ghnf3qpxcb@dynein.local.incenp.org> On Sat, Dec 14, 2019 at 08:05:04PM -0500, Dave via Gnupg-users wrote: >I can?t recall encountering any similar complaints about OpenSSL. I >find this somewhat curious, and am wondering if there are OpenSSL >detractors out there that I simply haven?t come across OpenSSL definitely has its detractors. They were for example very vocal back in 2014 in the aftermath of the Heartbleed bug. >OpenSSL command structure isn?t as complicated as it seems to me. For what I have seen, most of the criticisms against OpenSSL are directed at the code and/or the API rather than at the command line tools. This may reflect the fact that OpenSSL is probably more often used as a programming library than as a set of command line tools. That being said I have seen complaints about the command line OpenSSL tools as well. (I?ve heard a crypto-nerd once telling me that the only way to correctly generate a certificate signing request using OpenSSL?s req command was to type the command while sitting in a demonic circle after having sacrificed at least a dozen of chickens?or two dozens if the CSR is for a ECC certificate.) >I suppose that OpenSSL is geared toward a very technical and >security-aware user base, who aren?t likely to complain about usability >issues I am not sure I?d buy that. All the criticisms I have seen against either GnuPG or OpenSSL came from very technical-minded people. By contrast, in my experience non-technical people showing up at cryptoparties are very much willing to use the software as it is, learning what they need to learn instead of complaining that the software should be simple enough that they shouldn?t have to learn anything. (Of course those are the people motivated enough to attend a cryptoparty. They may not reflect the larger group of users.) Cheers, - Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From mistave at countermail.com Sun Dec 15 21:42:09 2019 From: mistave at countermail.com (Defiant) Date: Sun, 15 Dec 2019 21:42:09 +0100 Subject: Modern gnupg.conf setup In-Reply-To: <025efc75-9204-d983-2bf1-fe4345049031@sixdemonbag.org> References: <0bf51e63-ae66-7c71-f577-79959bb9b16a@countermail.com> <025efc75-9204-d983-2bf1-fe4345049031@sixdemonbag.org> Message-ID: <26c6dfee-1572-b393-67a5-05e9b1ac700a@countermail.com> On 15. 12. 19 19:32, Robert J. Hansen wrote: > >> It seems I was right to have asked here after all. It's amazing how many >> outdated tutorials exist... > > That presumes they were ever accurate in the first place. Many of them > were not. > >>> personal-cipher-preferences AES256 CAMELLIA256 TWOFISH AES192 >>> CAMELLIA192 AES CAMELLIA128 >>> personal-digest-preferences SHA512 SHA384 SHA256 SHA224 RIPEMD160 >> >> Should these also be included in the default-preference-list? I think >> the latter is only used when generating new keys (setpref), yes? > > Not necessarily. Personal-cipher-preferences is the list of ciphers > you're willing to use, but the list of ciphers on your key (what's put > there via setpref) is the list of ciphers you ask *other people* to use. > > Will they often be the same? Yes. But not always, and there's a > subtlety there that's often overlooked. You might be willing to > generate traffic using ciphers you're not willing to accept. > >>>> cert-digest-algo SHA512 >>> >>> Still valid, still useful. >> >> This I'm uncertain about. Should probably be removed too? > > Probably not. > > The reason why cipher-algo and digest-algo are recommended against is > because GnuPG already has a robust mechanism for choosing a strong > cipher that you're willing to generate (via personal-cipher-preferences) > and the recipient is willing to receive (via prefs on the key). > > There is no such mechanism for certificate signatures. That's entirely > generated by you. You have zero knowledge of what algorithm other > people will use. If you want maximum interoperability, you have to use > SHA-1; everyone can read SHA-1 signatures. > > But that's SHA-1, and SHA-1 isn't exactly a highly recommended digest > any more. > > Use something better and stronger. SHA512 is probably the best option > right now. If someone can't read your certificate signatures, well -- > that's on them: they should be moving away from SHA-1. > >> The RFC 4880 standard (section 9) does say that 3DES and SHA-1 must be >> implemented, but the reason I included these is because I read on some >> websites that you do NOT want to use these at all due to their >> weaknesses and there should be some way of warning the user that weak >> algorithms are being used. > > I question the credentials of anyone calling 3DES "weak". It has one > and only one serious cryptographic weakness: due to its 64-bit block > size, it should not be used to encrypt more than about 4Gb of data with > the same session key. > > 40 years after it was first released, the best attack on it is a > meet-in-the-middle that requires -- hand to God, I am not making this up > -- 64 pebibytes of RAM, 2**112 operations, and several strategic nuclear > weapons to generate enough energy to run the computer. > > Let me repeat: I am not making that up. > > So, yeah, if your attacker has technology straight out of _Star Trek_ > and is willing to cause untold ecological catastrophe, you're hosed. > Otherwise, 3DES is still solid. > > That's not to mean it's perfect. It's not. It's slow, it shouldn't be > used to encrypt bulk data due to its 64-bit blocksize, and more. There > are lots of reasons to prefer other, better ciphers than 3DES. And > maybe I can understand people calling it "weak" because really, that's a > lot easier for people to understand than talking about block sizes and > clock-cycles-per-block and everything else. > > But it's *not weak*. And any website that tells you to avoid 3DES > because it's weak is, to be honest, either too ignorant to be taken > seriously, so patronizing they'll handwave away complex issues behind > the comforting veneer of "it's weak", or is outright lying to you. > > SHA-1, on the other hand... > > *At the present moment* SHA-1 is still trustworthy in the places where > it's baked into the RFC4880 spec. The attacks against it don't affect > the (few) places where it's baked into OpenPGP. But attacks can get > better quite suddenly, and it's a good idea to avoid SHA-1 whenever > possible. > > But please don't use weak-digest on SHA-1. The only thing it'll do is > drown you in false positives. 99.999% of the time when you get a > warning of "SHA-1 is being used!!!! You asked me to warn you about > it!!!!!", in fact nothing is amiss at all. > > A 'warning' that's wrong 99.999% of the time is worse than receiving no > warning at all. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > Hey, thanks for all the help. That was really an educational read. I ended up with this config file contents: keyid-format 0xlong with-fingerprint personal-cipher-preferences AES256 CAMELLIA256 TWOFISH AES192 CAMELLIA192 AES CAMELLIA128 personal-digest-preferences SHA512 SHA384 SHA256 SHA224 RIPEMD160 default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES ZLIB BZIP2 ZIP Uncompressed cert-digest-algo SHA512 Do you also have any suggestions for generating new keypairs with GnuPG v2.2? I'm planning to use a Raspberry Pi (Raspbian) to create a RSA-4096 master key with CS capabilities (the UID comment should obviously be left empty) and three RSA-4096 subkeys for E, S and A. The subkeys will be put on a smartcard (Nitrokey Pro) while the master key will remain on the raspi, airgapped. main: RSA-4096 SC, 5y sub: RSA-4096 E, 2y sub: RSA-4096 S, 2y sub: RSA-4096 A, 2y Also I was told to armor export the secret keys to a file and then print that file as a last resort paper backup. Best regards! From nkr at gmx.com Sun Dec 15 21:08:19 2019 From: nkr at gmx.com (nkr at gmx.com) Date: Sun, 15 Dec 2019 21:08:19 +0100 Subject: gnupg private-keys encryption In-Reply-To: References: Message-ID: > Change the passphrase. Tried this now. No change in the encryption scheme in 2.2.17. From gniibe at fsij.org Mon Dec 16 02:47:32 2019 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 16 Dec 2019 10:47:32 +0900 Subject: pinentry-gtk-2 dialog doesn't appear before getting input In-Reply-To: <20191213135330.063c70f8@debian-i7> References: <20191213135330.063c70f8@debian-i7> Message-ID: <87d0cpvy6j.fsf@iwagami.gniibe.org> Andreas Ronnquist wrote: > I have a problem on Debian unstable (running in Virtualbox), running the > Xfce desktop - > > I have my gpg key on a card (a Librem key, which basically is a > Nitrokey) when using pinentry to enter the card password, I first have > to press my mouse on the screen (or a key on my keyboard) to make the > password dialog appear. I think that it's related to window manager. For testing, you can manually invoke pinentry like: $ pinentry # run pinentry by command line (-gtk2 or any) confirm # shows a dialog box bye # finish the session $ Doing this makes it easy to identify a problem (from complicated interaction of gpg <-> gpg-agent <-> pinentry). > Is there any way to make the dialog appear at once, when it is ready to > take my passphrase entry, or some workaround of any kind? It seems for me that: You can somehow control the behavior of the window manager. In its configuration by "Focus" tab in "Window Manager Tweaks": https://docs.xfce.org/xfce/xfwm4/wmtweaks And/or the first entry of "Accessibility" tab which says "Raise windows when any mous button is pressed". Or "Focus" tab in "Preferences": https://docs.xfce.org/xfce/xfwm4/preferences Looking the commit log of xfwm4 (about "stacking"), it appears something has been changed. -- From gusnan at librem.one Mon Dec 16 12:10:04 2019 From: gusnan at librem.one (Andreas Ronnquist) Date: Mon, 16 Dec 2019 12:10:04 +0100 Subject: pinentry-gtk-2 dialog doesn't appear before getting input In-Reply-To: <87d0cpvy6j.fsf@iwagami.gniibe.org> References: <20191213135330.063c70f8@debian-i7> <87d0cpvy6j.fsf@iwagami.gniibe.org> Message-ID: <20191216121004.7340f3af@debian-i7> On Mon, 16 Dec 2019 10:47:32 +0900 NIIBE Yutaka wrote: >Andreas Ronnquist wrote: >> I have a problem on Debian unstable (running in Virtualbox), running >> the Xfce desktop - >> >> I have my gpg key on a card (a Librem key, which basically is a >> Nitrokey) when using pinentry to enter the card password, I first >> have to press my mouse on the screen (or a key on my keyboard) to >> make the password dialog appear. > >I think that it's related to window manager. For testing, you can >manually invoke pinentry like: > > $ pinentry # run pinentry by command line (-gtk2 or > any) confirm # shows a dialog box > bye # finish the session > $ > Thanks - that indeed runs just fine, and without the problems I described. >Doing this makes it easy to identify a problem (from complicated >interaction of gpg <-> gpg-agent <-> pinentry). > >> Is there any way to make the dialog appear at once, when it is ready >> to take my passphrase entry, or some workaround of any kind? > >It seems for me that: > >You can somehow control the behavior of the window manager. > >In its configuration by "Focus" tab in "Window Manager Tweaks": > > https://docs.xfce.org/xfce/xfwm4/wmtweaks > >And/or the first entry of "Accessibility" tab which says "Raise windows >when any mous button is pressed". > >Or "Focus" tab in "Preferences": > > https://docs.xfce.org/xfce/xfwm4/preferences > >Looking the commit log of xfwm4 (about "stacking"), it appears >something has been changed. You are right - I have the settings xfwm4/raise_with_any_button (disabled) xfwm4/raise_on_focus (disabled) but xfwm4/raise_on_click enabled in xfce4-settings-editor - this to be able to scroll windows without focusing them. It would be very nice if pinentry could ignore these settings and always focus the entry window to avoid the problem I have. -- Andreas From gusnan at librem.one Mon Dec 16 13:39:10 2019 From: gusnan at librem.one (Andreas Ronnquist) Date: Mon, 16 Dec 2019 13:39:10 +0100 Subject: pinentry-gtk-2 dialog doesn't appear before getting input In-Reply-To: <20191216121004.7340f3af@debian-i7> References: <20191213135330.063c70f8@debian-i7> <87d0cpvy6j.fsf@iwagami.gniibe.org> <20191216121004.7340f3af@debian-i7> Message-ID: <20191216133910.4de7770c@debian-i7> On Mon, 16 Dec 2019 12:10:04 +0100 Andreas Ronnquist wrote: >On Mon, 16 Dec 2019 10:47:32 +0900 >NIIBE Yutaka wrote: > >>Andreas Ronnquist wrote: >>> I have a problem on Debian unstable (running in Virtualbox), running >>> the Xfce desktop - >>> >>> I have my gpg key on a card (a Librem key, which basically is a >>> Nitrokey) when using pinentry to enter the card password, I first >>> have to press my mouse on the screen (or a key on my keyboard) to >>> make the password dialog appear. >> >>I think that it's related to window manager. For testing, you can >>manually invoke pinentry like: >> >> $ pinentry # run pinentry by command line (-gtk2 or >> any) confirm # shows a dialog box >> bye # finish the session >> $ >> > >Thanks - that indeed runs just fine, and without the problems I >described. > >>Doing this makes it easy to identify a problem (from complicated >>interaction of gpg <-> gpg-agent <-> pinentry). >> >>> Is there any way to make the dialog appear at once, when it is ready >>> to take my passphrase entry, or some workaround of any kind? >> >>It seems for me that: >> >>You can somehow control the behavior of the window manager. >> >>In its configuration by "Focus" tab in "Window Manager Tweaks": >> >> https://docs.xfce.org/xfce/xfwm4/wmtweaks >> >>And/or the first entry of "Accessibility" tab which says "Raise >>windows when any mous button is pressed". >> >>Or "Focus" tab in "Preferences": >> >> https://docs.xfce.org/xfce/xfwm4/preferences >> >>Looking the commit log of xfwm4 (about "stacking"), it appears >>something has been changed. > >You are right - I have the settings > >xfwm4/raise_with_any_button (disabled) >xfwm4/raise_on_focus (disabled) > >but xfwm4/raise_on_click enabled in xfce4-settings-editor - this to be >able to scroll windows without focusing them. > >It would be very nice if pinentry could ignore these settings and >always focus the entry window to avoid the problem I have. > Changing to pinentry-gtk3 also removes the problem, and that is an acceptable solution for me, so I have no hurry in getting fixes to the gtk-2 version. -- Andreas From me at halfdog.net Mon Dec 16 16:14:36 2019 From: me at halfdog.net (halfdog) Date: Mon, 16 Dec 2019 15:14:36 +0000 Subject: Usability of OpenSSL vs GNUPG In-Reply-To: <20191215184917.6hkyd5ghnf3qpxcb@dynein.local.incenp.org> References: <000f01d5b2e3$afdcef70$0f96ce50$.ref@yahoo.com> <000f01d5b2e3$afdcef70$0f96ce50$@yahoo.com> <20191215184917.6hkyd5ghnf3qpxcb@dynein.local.incenp.org> Message-ID: <7113-1576509276.918788@Mx2e.JO6K.vE8I> Damien Goutte-Gattat via Gnupg-users writes: > On Sat, Dec 14, 2019 at 08:05:04PM -0500, Dave via Gnupg-users > wrote: >> I can?t recall encountering any similar complaints about >> OpenSSL. I find this somewhat curious, and am wondering if >> there are OpenSSL detractors out there that I simply haven?t >> come across > > OpenSSL definitely has its detractors. They were for example > very vocal back in 2014 in the aftermath of the Heartbleed > bug. I cannot speak for anyone else but from my experience the GnuPG community ecosystem's way of dealing with issues is way more conflict prone than how OpenSSL handles this. One side of that conflict is how GnuPG treats the command line "API". While my written OpenSSL instructions, automation scripts around key generation, signing, de/encryption required (minor) modification due to OpenSSL software changes in the last years, GnuPG updates from Debian quite often require quite intruding changes to written manual instructions or automated scripts. To nail it down, here is the list of changes as an example and the time to fix (estimate from memory): OpenSSL: * Generate dh-params during deployment and always use them on connection (15 minutes) * Force SSL to drop older TLS versions on internal connections (5 minutes) GnuPG: * Initrd restructuring due to gnupg-agent use (4h) * Secure forced termination of gnupg-agent for single-use private key decryption (4h) * Update, testing of numerous procedures after introduction of "pin-entry-mode" (4h) * Decoding of PGP private key format using RFC to resurrect old private keys after suddenly not being useable any more after a minor update (1 day) * Workaround for secure GnuPG passphrase handling after gnupg started silently ignoring the command line parameters to have a stronger passphrase bruteforce security by integrating GnuPG with argon2. (4h) As I have the feeling I use OpenSSL and GnuPG in a similar number of procedures, the much huger amount of time required to keep GnuPG operational and secure does not make me cheerful about command line/operating system API stability. As mentioned above, this is only one side of that conflict. The other one is, that when such problems occur, which cannot be avoided even with best software, then documentation or online resources are usually not very helpful. Thus the community contact is sought, but to my opinion replies are often not acknowledging the problem (not accepting that someone might have used GnuPG for such procedures before the change and requires to find a working solution to keep production running), empathic (a reply like: "sorry, we understand this is annoying for you, but this change was technically required ...), not increasing community knowlege to build a better GnuPG community (the change was needed for use-case [reference], thus requirements [reference] contratict your use case. See [doc-url] for considerations, workarounds ..."). So for example following following sequence or events represents quite well the usual experience I perceive dealing with GnuPG software issues: * Discovering accidentially that GnuPG private key passphrase bruteforce somehow was reduced to 1/100 strength with new keys. * Searching the documentation, internet, not finding anything of relevance to this issue. * Asking the GnuPG security contact finding out a) the parameter for better bruteforce protection is silently ignored in GnuPG2 passphrase symmetric key generation b) there is no problem GnuPG downgrading security on its own without any warning by ignoring the parameter, c) the documention is outdated/ambiguous and does not mention the change, c) why do you want to have a strong bruteforce protection, the reduced value is way better for good user experience with gnupg-agent? and d) gnupg-agent will manage (calibrate) that parameter for optimized user experience automatically to 1/100, no need to mingle with that. * Me not being happy to reduce bruteforce protection to something used 10 years ago, thus integrating GnuPG with argon2 to have appropriate protection again. Having such experiences more than once reduced trust and sympathy for GnuPG, thus also willingness to contribute to testing or development. But maybe just my expectations of GnuPG as open source software are wrong and my limited communication skills do not allow me to sort it out in a more positive manner. hd From dkg at fifthhorseman.net Mon Dec 16 20:01:22 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 16 Dec 2019 14:01:22 -0500 Subject: pinentry-gtk-2 dialog doesn't appear before getting input In-Reply-To: <20191216133910.4de7770c@debian-i7> References: <20191213135330.063c70f8@debian-i7> <87d0cpvy6j.fsf@iwagami.gniibe.org> <20191216121004.7340f3af@debian-i7> <20191216133910.4de7770c@debian-i7> Message-ID: <87v9qg5c3h.fsf@fifthhorseman.net> On Mon 2019-12-16 13:39:10 +0100, Andreas Ronnquist wrote: > Changing to pinentry-gtk3 also removes the problem, and that is an > acceptable solution for me, so I have no hurry in getting fixes to the > gtk-2 version. just to clarify, i think you're talking about pinentry-gnome3, not gtk3. Right? My experience is that pinentry-gnome3 is much better-integrated with any modern desktop installation than pinentry-gtk2 is, so this outcome is not surprising to me. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From gusnan at librem.one Mon Dec 16 20:49:12 2019 From: gusnan at librem.one (Andreas Ronnquist) Date: Mon, 16 Dec 2019 20:49:12 +0100 Subject: pinentry-gtk-2 dialog doesn't appear before getting input In-Reply-To: <87v9qg5c3h.fsf@fifthhorseman.net> References: <20191213135330.063c70f8@debian-i7> <87d0cpvy6j.fsf@iwagami.gniibe.org> <20191216121004.7340f3af@debian-i7> <20191216133910.4de7770c@debian-i7> <87v9qg5c3h.fsf@fifthhorseman.net> Message-ID: <20191216204912.5a5625d0@debian-i7> On Mon, 16 Dec 2019 14:01:22 -0500 Daniel Kahn Gillmor wrote: >On Mon 2019-12-16 13:39:10 +0100, Andreas Ronnquist wrote: >> Changing to pinentry-gtk3 also removes the problem, and that is an >> acceptable solution for me, so I have no hurry in getting fixes to >> the gtk-2 version. > >just to clarify, i think you're talking about pinentry-gnome3, not >gtk3. Right? > >My experience is that pinentry-gnome3 is much better-integrated with >any modern desktop installation than pinentry-gtk2 is, so this outcome >is not surprising to me. > You are right of course, I mean gnome3 and not gtk3. Best /Andreas From rick.rustad at enavate.com Tue Dec 17 03:00:52 2019 From: rick.rustad at enavate.com (Rick Rustad) Date: Tue, 17 Dec 2019 02:00:52 +0000 Subject: GnuPG v2.2.17.22805 with StarksoftCryptographyOpenPGP Message-ID: Hi. I'm running into some difficulties trying to encrypt and sign a file using gpg and Starksoft through a .Net C# API. I generated my own public/private keys and received the recipient's public key which I imported into Kleopatra v 3.1.8. On my VM, where I'm developing the program, the Starksoft code receives an error message, 2, from gpg.exe. I've tried changing and removing options and I continue to get the same error message. Might you have some suggestions? Error Msg1 with command line: C:\Program Files\GnuPG\bin\gpg.exe--passphrase-fd 0 --verbose --batch --trust-model always --pinentry-mode loopback --armor --recipient "XXXXXXXXX" --encrypt MESSAGE: gpg: XXXXXXXXX: skipped: No public key gpg: [stdin]: encryption failed: No public key Error Msg2 with command line: C:\Program Files\GnuPG\bin\gpg.exe--verbose --batch --trust-model always --pinentry-mode loopback --default-recipient " XXXXXXXXX " --encrypt MESSAGE: gpg: enabled debug flags: memstat trust extprog gpg: unknown default recipient " XXXXXXXXX " gpg: [stdin]: encryption failed: No public key gpg: keydb: handles=1 locks=0 parse=0 get=0 gpg: build=0 update=0 insert=0 delete=0 gpg: reset=0 found=0 not=1 cache=0 not=0 gpg: kid_not_found_cache: count=0 peak=0 flushes=0 gpg: sig_cache: total=0 cached=0 good=0 bad=0 gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 gpg: rndjent stat: collector=0x00000000 calls=0 bytes=0 gpg: secmem usage: 0/32768 bytes in 0 blocks Thank you. Rick Rustad | Senior Dynamics GP Developer at Enavate Managed Services, a DXC Services Partner Mobile +1 701 428 9900| Office +1 720 577 5027 | E-mail rick.rustad at enavate.com ENAVATE, Inc. | 7887 E. Belleview Ave., Suite 600 | Englewood, CO 80111 | USA This email message and any attachments are intended only for the use of the addressee named above and may contain information that is confidential. If you are not the intended recipient, any dissemination, distribution, or copying is strictly prohibited. If you received this email message in error, please immediately notify the sender by replying to this email message or by telephone. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture (Device Independent Bitmap) 1.jpg Type: image/jpeg Size: 3455 bytes Desc: Picture (Device Independent Bitmap) 1.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture (Device Independent Bitmap) 2.jpg Type: image/jpeg Size: 2134 bytes Desc: Picture (Device Independent Bitmap) 2.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture (Device Independent Bitmap) 3.jpg Type: image/jpeg Size: 832 bytes Desc: Picture (Device Independent Bitmap) 3.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture (Device Independent Bitmap) 4.jpg Type: image/jpeg Size: 814 bytes Desc: Picture (Device Independent Bitmap) 4.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture (Device Independent Bitmap) 5.jpg Type: image/jpeg Size: 830 bytes Desc: Picture (Device Independent Bitmap) 5.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture (Device Independent Bitmap) 6.jpg Type: image/jpeg Size: 814 bytes Desc: Picture (Device Independent Bitmap) 6.jpg URL: From rjh at sixdemonbag.org Tue Dec 17 15:43:55 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 17 Dec 2019 09:43:55 -0500 Subject: GnuPG v2.2.17.22805 with StarksoftCryptographyOpenPGP In-Reply-To: References: Message-ID: <3531c63061b28bdedbb96f19ec497b3d@mail.monkeyblade.net> On 2019-12-16 21:00, Rick Rustad wrote: > I'm running into some difficulties trying to encrypt and sign a file > using gpg and Starksoft through a .Net C# API. The good news is there's a good chance this is an easy fix. > Might you have some suggestions? Sure do. > Error Msg1 with command line: C:Program > FilesGnuPGbingpg.exe--passphrase-fd 0 --verbose --batch --trust-model > always --pinentry-mode loopback --armor --recipient "XXXXXXXXX" > --encrypt > MESSAGE: > gpg: XXXXXXXXX: skipped: No public key > gpg: [stdin]: encryption failed: No public key What this means is really simple: GnuPG can't find the recipient's public key. GnuPG stores keys on a per-user basis, not systemwide. So if you imported the recipient's public key to your local keyring, but this code is running as a different user, GnuPG will look in that different user's keyring for the public key -- not yours. You can test this out by switching over to whatever user account this is running as and running "gpg --list-key XXXXXXXX". I strongly suspect you'll get no output, thus showing that when running as this user GnuPG has no access to the public key that's on your own user keyring. While still logged into the different user account this is running as, import the public key into GnuPG. Your problems should vanish. If this still doesn't work you'll need to dive into Starksoft, as it's possible they're switching users and not telling you. From rjh at sixdemonbag.org Tue Dec 17 15:55:21 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 17 Dec 2019 09:55:21 -0500 Subject: Usability of OpenSSL vs GNUPG In-Reply-To: <7113-1576509276.918788@Mx2e.JO6K.vE8I> References: <000f01d5b2e3$afdcef70$0f96ce50$.ref@yahoo.com> <000f01d5b2e3$afdcef70$0f96ce50$@yahoo.com> <20191215184917.6hkyd5ghnf3qpxcb@dynein.local.incenp.org> <7113-1576509276.918788@Mx2e.JO6K.vE8I> Message-ID: <63e48065b4384227d2115489f5683ac0@mail.monkeyblade.net> > Having such experiences more than once reduced trust and sympathy > for GnuPG, thus also willingness to contribute to testing or > development. But maybe just my expectations of GnuPG as open > source software are wrong and my limited communication skills > do not allow me to sort it out in a more positive manner. One of my repeated complaints about GnuPG is that nobody can agree on what it is. Is it a toolkit for building bespoke cryptographic solutions? Is it an RFC4880 implementation meant for end-users? Is it an RFC4880 implementation meant for MUAs? Is it... A lot of the things you're (rightly, I think) criticizing are the result of this clouded vision of what GnuPG is meant to do. In the course of trying to be all things to all people it's occasionally being very annoying. You're using it as a toolkit for bespoke solutions. You want your tools to work consistently across versions. Other people are using it as an end-user tool. They want the end-user experience to be continuously refined. This leads to things like gpg-agent ignoring s2k iteration counts in order to give a positive end-user experience, at the risk of frustrating people who are wondering why their bespoke solutions with custom s2k iteration counts no longer work. From andrewg at andrewg.com Tue Dec 17 16:09:40 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 17 Dec 2019 15:09:40 +0000 Subject: Usability of OpenSSL vs GNUPG In-Reply-To: <63e48065b4384227d2115489f5683ac0@mail.monkeyblade.net> References: <000f01d5b2e3$afdcef70$0f96ce50$.ref@yahoo.com> <000f01d5b2e3$afdcef70$0f96ce50$@yahoo.com> <20191215184917.6hkyd5ghnf3qpxcb@dynein.local.incenp.org> <7113-1576509276.918788@Mx2e.JO6K.vE8I> <63e48065b4384227d2115489f5683ac0@mail.monkeyblade.net> Message-ID: <44c58fb1-ca53-f088-9dd1-1d2b39e47b1c@andrewg.com> On 17/12/2019 14:55, Robert J. Hansen wrote: > One of my repeated complaints about GnuPG is that nobody can agree on > what it is.? Is it a toolkit for building bespoke cryptographic > solutions?? Is it an RFC4880 implementation meant for end-users?? Is it > an RFC4880 implementation meant for MUAs?? Is it... > > A lot of the things you're (rightly, I think) criticizing are the result > of this clouded vision of what GnuPG is meant to do.? In the course of > trying to be all things to all people it's occasionally being very > annoying. One of my frustrations has long been that the design is inverted - the core utility is the fully-featured CLI (gpg), and the wrapper interface is the reduced-featureset API (gpgme). This is a reflection of its history, especially PGP backwards-compatibility, but causes problems when trying to use it as a component in a larger system. Unfortunately, refactoring it to be a fully-featured API with a reduced-featureset and/or backwards-compatible CLI is a project so overwhelming that I'm sure nobody wants to take it on... -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Tue Dec 17 16:31:16 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 17 Dec 2019 10:31:16 -0500 Subject: GnuPG v2.2.17.22805 with StarksoftCryptographyOpenPGP In-Reply-To: References: <3531c63061b28bdedbb96f19ec497b3d@mail.monkeyblade.net> Message-ID: <50a1ad370e0e4180a6631cffabdd9961@mail.monkeyblade.net> On 2019-12-17 10:10, Rick Rustad wrote: > So very glad you responded. We try to be helpful. We sometimes fail, but we try. :) > I see a bigger issue looming. If this customization I'm working on > will be used by many people and thus the encryption and signature > processing will be utilized by the same many people, is there a way to > override or tell the command line argument to GnuPG to not be user > specific? Yep. Use both "--no-default-keyring" and "--keyring". For instance: $ gpg --no-default-keyring --keyring \path\to\pubring.kbx --list-keys However, as of GnuPG 2.2 you can no longer specify private keys this way. There used to be an option, "--secret-keyring", which was used just like "--keyring", but it's obsolete and now does nothing. > In one of my tests I replaced "--recipient" with "--default-recipient" > but it had no affect, same error message. Yeah, that's expected and doesn't shed much light on the matter. From rjh at sixdemonbag.org Tue Dec 17 17:41:14 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 17 Dec 2019 11:41:14 -0500 Subject: GPGME frustrations (was OpenSSL/GnuPG usability) In-Reply-To: <44c58fb1-ca53-f088-9dd1-1d2b39e47b1c@andrewg.com> References: <000f01d5b2e3$afdcef70$0f96ce50$.ref@yahoo.com> <000f01d5b2e3$afdcef70$0f96ce50$@yahoo.com> <20191215184917.6hkyd5ghnf3qpxcb@dynein.local.incenp.org> <7113-1576509276.918788@Mx2e.JO6K.vE8I> <63e48065b4384227d2115489f5683ac0@mail.monkeyblade.net> <44c58fb1-ca53-f088-9dd1-1d2b39e47b1c@andrewg.com> Message-ID: <353ca5ef75e4159c9cb060d4cc9416a5@mail.monkeyblade.net> On 2019-12-17 10:09, Andrew Gallagher wrote: > One of my frustrations has long been that the design is inverted - the > core utility is the fully-featured CLI (gpg), and the wrapper interface > is the reduced-featureset API (gpgme). It's reduced *twice*. Once by GPGME directly, and then once by whatever language binding to GPGME you're using. Not all language bindings are made equal. The C++ one is reasonably good; the Python one, likewise. But the C# one is alpha-quality only, the Java ones don't even compile any more, and so on. From rjh at sixdemonbag.org Tue Dec 17 17:53:20 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 17 Dec 2019 11:53:20 -0500 Subject: GnuPG v2.2.17.22805 with StarksoftCryptographyOpenPGP In-Reply-To: References: <3531c63061b28bdedbb96f19ec497b3d@mail.monkeyblade.net> <50a1ad370e0e4180a6631cffabdd9961@mail.monkeyblade.net> Message-ID: > I'm not sure if we're closer or not. I plugged in the > -no-default-keyring and -keyring "name" We're definitely closer. Remember what Thomas Edison said when someone accused him of having failed 10,000 times in his pursuit of the light bulb. "I have not failed, I have only found 10,000 ways that don't work!" Churning through failures quickly is an essential part of success. A frustrating part, to be sure -- but essential. So, next up. > Command line I'm pushing to GnuPG: C:Program FilesGnuPGbingpg.exe > --verbose --batch --trust-model always --pinentry-mode loopback > --no-default-keyring --keyring > "C:UsersRickRustadAppDataRoaminggnupgpubring.kbx" --recipient " > XXXXXXX " --encrypt Open a command window and use that exact same command line. Does it work correctly? From oxyopes at googlemail.com Tue Dec 17 16:58:37 2019 From: oxyopes at googlemail.com (oxy) Date: Tue, 17 Dec 2019 16:58:37 +0100 Subject: inline gpg password-prompt ?? Message-ID: Hi, when i try to use my gnupg keys over ssh the password prompt does not tunnel through. (I do have a properly tunneled $DISPLAY) Can i force gpg to prompt for passwd inline? (i mean, inside the terminal) Thx in advance... From abbot at monksofcool.net Tue Dec 17 19:17:35 2019 From: abbot at monksofcool.net (Ralph Seichter) Date: Tue, 17 Dec 2019 19:17:35 +0100 Subject: inline gpg password-prompt ?? In-Reply-To: References: Message-ID: <87d0cm3jgg.fsf@wedjat.horus-it.com> * oxy via Gnupg-users: > Can i force gpg to prompt for passwd inline? > (i mean, inside the terminal) The following might help: export GPG_TTY="$(tty)" If you are not using BASH, change this to your shell's required syntax. -Ralph From jestedfa at microsoft.com Tue Dec 17 16:18:21 2019 From: jestedfa at microsoft.com (Jeffrey Stedfast) Date: Tue, 17 Dec 2019 15:18:21 +0000 Subject: Usability of OpenSSL vs GNUPG Message-ID: <85394334-F431-4B38-B1F8-3DC6DA9F126F@microsoft.com> ?On 12/17/19, 9:55 AM, Robert J. Hansen wrote: > One of my repeated complaints about GnuPG is that nobody can agree on > what it is. Is it a toolkit for building bespoke cryptographic > solutions? Is it an RFC4880 implementation meant for end-users? Is it > an RFC4880 implementation meant for MUAs? Is it... I would just like to say that GnuPG is meant to be an RFC4880 implementation for MUA's. Anyone who says otherwise is just WRONG ;-) -- Says the guy who has written countless mail clients and libraries over the years... Jeff From rick.rustad at enavate.com Tue Dec 17 16:10:33 2019 From: rick.rustad at enavate.com (Rick Rustad) Date: Tue, 17 Dec 2019 15:10:33 +0000 Subject: GnuPG v2.2.17.22805 with StarksoftCryptographyOpenPGP In-Reply-To: <3531c63061b28bdedbb96f19ec497b3d@mail.monkeyblade.net> References: <3531c63061b28bdedbb96f19ec497b3d@mail.monkeyblade.net> Message-ID: HI Robert. So very glad you responded. I understand what you're saying about logins and such. I'm on a local virtual machine that only I log into so I can't log in as anyone else. We've customized an accounting program, business financial, to create a flat file during one of the processing events. This flat file is what my code is trying to encrypt and sign. It may be possible that the accounting program is using a system account when running my custom code and thus trying to access Kleopatra as a system account. My experience with this accounting program is that it should pick up my OS login credentials and use them, however, I'll make that an assumption. When I created and uploaded the keys I did check off for everyone, shouldn't the program see the keys if they are flagged as for everyone? At least for the imported public key. I see a bigger issue looming. If this customization I'm working on will be used by many people and thus the encryption and signature processing will be utilized by the same many people, is there a way to override or tell the command line argument to GnuPG to not be user specific? In one of my tests I replaced "--recipient" with "--default-recipient" but it had no affect, same error message. Thank you. Rick Rustad -----Original Message----- From: Robert J. Hansen Sent: Tuesday, December 17, 2019 8:44 AM To: Rick Rustad Cc: gnupg-users at gnupg.org Subject: Re: GnuPG v2.2.17.22805 with StarksoftCryptographyOpenPGP On 2019-12-16 21:00, Rick Rustad wrote: > I'm running into some difficulties trying to encrypt and sign a file > using gpg and Starksoft through a .Net C# API. The good news is there's a good chance this is an easy fix. > Might you have some suggestions? Sure do. > Error Msg1 with command line: C:Program > FilesGnuPGbingpg.exe--passphrase-fd 0 --verbose --batch --trust-model > always --pinentry-mode loopback --armor --recipient "XXXXXXXXX" > --encrypt > MESSAGE: > gpg: XXXXXXXXX: skipped: No public key > gpg: [stdin]: encryption failed: No public key What this means is really simple: GnuPG can't find the recipient's public key. GnuPG stores keys on a per-user basis, not systemwide. So if you imported the recipient's public key to your local keyring, but this code is running as a different user, GnuPG will look in that different user's keyring for the public key -- not yours. You can test this out by switching over to whatever user account this is running as and running "gpg --list-key XXXXXXXX". I strongly suspect you'll get no output, thus showing that when running as this user GnuPG has no access to the public key that's on your own user keyring. While still logged into the different user account this is running as, import the public key into GnuPG. Your problems should vanish. If this still doesn't work you'll need to dive into Starksoft, as it's possible they're switching users and not telling you. ATTENTION: This email was sent to Enavate from an external source. Please be extra vigilant when replying, opening attachments or clicking links. From rick.rustad at enavate.com Tue Dec 17 16:54:09 2019 From: rick.rustad at enavate.com (Rick Rustad) Date: Tue, 17 Dec 2019 15:54:09 +0000 Subject: GnuPG v2.2.17.22805 with StarksoftCryptographyOpenPGP In-Reply-To: <50a1ad370e0e4180a6631cffabdd9961@mail.monkeyblade.net> References: <3531c63061b28bdedbb96f19ec497b3d@mail.monkeyblade.net> <50a1ad370e0e4180a6631cffabdd9961@mail.monkeyblade.net> Message-ID: Hi Robert. Found the file and I'll plug in your suggestion and run a test. Can I move that KBX file to the C:\Program Files\GnuPG folder for a more central location? Rick -----Original Message----- From: Robert J. Hansen Sent: Tuesday, December 17, 2019 9:31 AM To: Rick Rustad Cc: gnupg-users at gnupg.org Subject: RE: GnuPG v2.2.17.22805 with StarksoftCryptographyOpenPGP On 2019-12-17 10:10, Rick Rustad wrote: > So very glad you responded. We try to be helpful. We sometimes fail, but we try. :) > I see a bigger issue looming. If this customization I'm working on > will be used by many people and thus the encryption and signature > processing will be utilized by the same many people, is there a way to > override or tell the command line argument to GnuPG to not be user > specific? Yep. Use both "--no-default-keyring" and "--keyring". For instance: $ gpg --no-default-keyring --keyring \path\to\pubring.kbx --list-keys However, as of GnuPG 2.2 you can no longer specify private keys this way. There used to be an option, "--secret-keyring", which was used just like "--keyring", but it's obsolete and now does nothing. > In one of my tests I replaced "--recipient" with "--default-recipient" > but it had no affect, same error message. Yeah, that's expected and doesn't shed much light on the matter. ATTENTION: This email was sent to Enavate from an external source. Please be extra vigilant when replying, opening attachments or clicking links. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture (Device Independent Bitmap) 1.jpg Type: image/jpeg Size: 65694 bytes Desc: Picture (Device Independent Bitmap) 1.jpg URL: From rick.rustad at enavate.com Tue Dec 17 17:37:13 2019 From: rick.rustad at enavate.com (Rick Rustad) Date: Tue, 17 Dec 2019 16:37:13 +0000 Subject: GnuPG v2.2.17.22805 with StarksoftCryptographyOpenPGP In-Reply-To: References: <3531c63061b28bdedbb96f19ec497b3d@mail.monkeyblade.net> <50a1ad370e0e4180a6631cffabdd9961@mail.monkeyblade.net> Message-ID: Hi Robert. I'm not sure if we're closer or not. I plugged in the -no-default-keyring and -keyring "name" Command line I'm pushing to GnuPG: C:\Program Files\GnuPG\bin\gpg.exe --verbose --batch --trust-model always --pinentry-mode loopback --no-default-keyring --keyring "C:\Users\RickRustad\AppData\Roaming\gnupg\pubring.kbx" --recipient " XXXXXXX " --encrypt Error message echo'd back to my trace log: gpg: enabled debug flags: memstat trust extprog gpg: XXXXXXX: skipped: No public key gpg: [stdin]: encryption failed: No public key gpg: keydb: handles=1 locks=0 parse=0 get=0 gpg: build=0 update=0 insert=0 delete=0 gpg: reset=0 found=0 not=1 cache=0 not=0 gpg: kid_not_found_cache: count=0 peak=0 flushes=0 gpg: sig_cache: total=0 cached=0 good=0 bad=0 gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 gpg: rndjent stat: collector=0x00000000 calls=0 bytes=0 gpg: secmem usage: 0/32768 bytes in 0 blocks Any other suggestions? Rick Rustad | Senior Dynamics GP Developer at Enavate Managed Services, a DXC Services Partner Mobile +1 701 428 9900| Office +1 720 577 5027 | E-mail rick.rustad at enavate.com ENAVATE, Inc. | 7887 E. Belleview Ave., Suite 600 | Englewood, CO 80111 | USA ____________________________________________ From: Rick Rustad Sent: Tuesday, December 17, 2019 9:54 AM To: Robert J. Hansen Cc: gnupg-users at gnupg.org Subject: RE: GnuPG v2.2.17.22805 with StarksoftCryptographyOpenPGP Hi Robert. Found the file and I'll plug in your suggestion and run a test. Can I move that KBX file to the C:\Program Files\GnuPG folder for a more central location? << OLE Object: Picture (Device Independent Bitmap) >> Rick -----Original Message----- From: Robert J. Hansen Sent: Tuesday, December 17, 2019 9:31 AM To: Rick Rustad Cc: gnupg-users at gnupg.org Subject: RE: GnuPG v2.2.17.22805 with StarksoftCryptographyOpenPGP On 2019-12-17 10:10, Rick Rustad wrote: > So very glad you responded. We try to be helpful. We sometimes fail, but we try. :) > I see a bigger issue looming. If this customization I'm working on > will be used by many people and thus the encryption and signature > processing will be utilized by the same many people, is there a way to > override or tell the command line argument to GnuPG to not be user > specific? Yep. Use both "--no-default-keyring" and "--keyring". For instance: $ gpg --no-default-keyring --keyring \path\to\pubring.kbx --list-keys However, as of GnuPG 2.2 you can no longer specify private keys this way. There used to be an option, "--secret-keyring", which was used just like "--keyring", but it's obsolete and now does nothing. > In one of my tests I replaced "--recipient" with "--default-recipient" > but it had no affect, same error message. Yeah, that's expected and doesn't shed much light on the matter. ATTENTION: This email was sent to Enavate from an external source. Please be extra vigilant when replying, opening attachments or clicking links. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cjac at colliertech.org Tue Dec 17 20:57:42 2019 From: cjac at colliertech.org (C.J. Collier) Date: Tue, 17 Dec 2019 11:57:42 -0800 Subject: Usability of OpenSSL vs GNUPG In-Reply-To: <85394334-F431-4B38-B1F8-3DC6DA9F126F@microsoft.com> References: <85394334-F431-4B38-B1F8-3DC6DA9F126F@microsoft.com> Message-ID: And thank you for doing so, fejj. I'm a big fan of your work, even if we don't agree on everything. On Tue, Dec 17, 2019, 11:36 Jeffrey Stedfast via Gnupg-users < gnupg-users at gnupg.org> wrote: > > ?On 12/17/19, 9:55 AM, Robert J. Hansen wrote: > > One of my repeated complaints about GnuPG is that nobody can agree on > > what it is. Is it a toolkit for building bespoke cryptographic > > solutions? Is it an RFC4880 implementation meant for end-users? Is it > > an RFC4880 implementation meant for MUAs? Is it... > > I would just like to say that GnuPG is meant to be an RFC4880 > implementation for MUA's. Anyone who says otherwise is just WRONG ;-) > > -- Says the guy who has written countless mail clients and libraries over > the years... > > Jeff > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From johndoe65534 at mail.com Wed Dec 18 08:19:59 2019 From: johndoe65534 at mail.com (john doe) Date: Wed, 18 Dec 2019 08:19:59 +0100 Subject: Best way to get fingerprint programatically Message-ID: <8246305a-1064-6e62-74da-d92c532383aa@mail.com> Hi, I'm using the following command to get the fingerprint to quickly change the expiration date on a key. $ gpg --quick-set-expire $(gpg --with-colons -k test | awk -F::::::::: 'NR==3{print substr($2,1,length($2)-1)}') 1d I'm just wondering if there isn't a better, programatically, way to go about it? In other words, why '--quick-set-expire' requires a fingerprint and does not accept a . Any input is welcome. -- John Doe From andrewg at andrewg.com Wed Dec 18 10:20:48 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 18 Dec 2019 09:20:48 +0000 Subject: Best way to get fingerprint programatically In-Reply-To: <8246305a-1064-6e62-74da-d92c532383aa@mail.com> References: <8246305a-1064-6e62-74da-d92c532383aa@mail.com> Message-ID: <50c333f5-3317-7f4f-c4bd-a1c1df6def7a@andrewg.com> On 18/12/2019 07:19, john doe wrote: > $ gpg --quick-set-expire $(gpg --with-colons -k test | awk -F::::::::: > 'NR==3{print substr($2,1,length($2)-1)}') 1d > > I'm just wondering if there isn't a better, programatically, way to go > about it? Your awk looks awkward to me. What about this instead? awk -F: '/^fpr/ {print $10}' -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed Dec 18 10:32:43 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Dec 2019 10:32:43 +0100 Subject: Best way to get fingerprint programatically In-Reply-To: <8246305a-1064-6e62-74da-d92c532383aa@mail.com> (john doe's message of "Wed, 18 Dec 2019 08:19:59 +0100") References: <8246305a-1064-6e62-74da-d92c532383aa@mail.com> Message-ID: <87y2vahtc4.fsf@wheatstone.g10code.de> On Wed, 18 Dec 2019 08:19, john doe said: > In other words, why '--quick-set-expire' requires a fingerprint and does > not accept a . Only the fingerprint is a unique identifier for the keyblock (aka certificate, public key). Allowing a User-id would require extra code in gpg and by the caller to either ask back or to fail if there is an ambiguity. The -F:::::: is an interesting hack but Andrew's or my variant works with all AWK implementations: awk -F: '$1=="fpr" {print $10}' | head -1 Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From oxyopes at googlemail.com Wed Dec 18 10:53:21 2019 From: oxyopes at googlemail.com (oxy) Date: Wed, 18 Dec 2019 10:53:21 +0100 Subject: inline gpg password-prompt ?? In-Reply-To: <87d0cm3jgg.fsf@wedjat.horus-it.com> References: <87d0cm3jgg.fsf@wedjat.horus-it.com> Message-ID: > export GPG_TTY="$(tty)" great! Thx.. From andrewg at andrewg.com Wed Dec 18 10:56:31 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 18 Dec 2019 09:56:31 +0000 Subject: Best way to get fingerprint programatically In-Reply-To: <87y2vahtc4.fsf@wheatstone.g10code.de> References: <8246305a-1064-6e62-74da-d92c532383aa@mail.com> <87y2vahtc4.fsf@wheatstone.g10code.de> Message-ID: On 18/12/2019 09:32, Werner Koch via Gnupg-users wrote: > The -F:::::: is an interesting hack but Andrew's or my variant works > with all AWK implementations: > > awk -F: '$1=="fpr" {print $10}' | head -1 Aha, I forgot about handling multiple results. Note that you don't need head if you're already using awk: awk -F: '$1=="fpr" {print $10; exit}' :-D -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From johndoe65534 at mail.com Wed Dec 18 11:51:07 2019 From: johndoe65534 at mail.com (john doe) Date: Wed, 18 Dec 2019 11:51:07 +0100 Subject: Best way to get fingerprint programatically In-Reply-To: References: <8246305a-1064-6e62-74da-d92c532383aa@mail.com> <87y2vahtc4.fsf@wheatstone.g10code.de> Message-ID: On 12/18/2019 10:56 AM, Andrew Gallagher wrote: > On 18/12/2019 09:32, Werner Koch via Gnupg-users wrote: >> The -F:::::: is an interesting hack but Andrew's or my variant works >> with all AWK implementations: >> >> awk -F: '$1=="fpr" {print $10}' | head -1 > > Aha, I forgot about handling multiple results. Note that you don't need > head if you're already using awk: > > awk -F: '$1=="fpr" {print $10; exit}' > Thanks to both of you, I'll go with the awk version, that way, I can avoid unneeded pipe redirection! :) By any chance, could something like the following be implemented?: $ gpg -K --print-fingerprint-only test Which would only print the fingerprint to avoid the awk redirection altogether. -- John Doe From me at halfdog.net Wed Dec 18 13:12:15 2019 From: me at halfdog.net (halfdog) Date: Wed, 18 Dec 2019 12:12:15 +0000 Subject: Usability of OpenSSL vs GNUPG In-Reply-To: <63e48065b4384227d2115489f5683ac0@mail.monkeyblade.net> References: <000f01d5b2e3$afdcef70$0f96ce50$.ref@yahoo.com> <000f01d5b2e3$afdcef70$0f96ce50$@yahoo.com> <20191215184917.6hkyd5ghnf3qpxcb@dynein.local.incenp.org> <7113-1576509276.918788@Mx2e.JO6K.vE8I> <63e48065b4384227d2115489f5683ac0@mail.monkeyblade.net> Message-ID: <515-1576671135.736422@M74F.DR86.p2d4> Robert J. Hansen writes: > > Having such experiences more than once reduced trust and sympathy > > for GnuPG, thus also willingness to contribute to testing or > > development. But maybe just my expectations of GnuPG as open > > source software are wrong and my limited communication skills > > do not allow me to sort it out in a more positive manner. > > One of my repeated complaints about GnuPG is that nobody can agree on > what it is. Is it a toolkit for building bespoke cryptographic > solutions? Is it an RFC4880 implementation meant for end-users? Is it > an RFC4880 implementation meant for MUAs? Is it... Yes, I fell this is exactly the cause. But what adds to that frustration is, that e.g. offering to participate in defining use cases, requirements, scope of various components seemed not the way the project would like to go forward, maybe as this would surface the conflicts in a short run (while avoiding them in long run). > A lot of the things you're (rightly, I think) criticizing are the result > of this clouded vision of what GnuPG is meant to do. In the course of > trying to be all things to all people it's occasionally being very > annoying. > > You're using it as a toolkit for bespoke solutions. You want your tools > to work consistently across versions. > > Other people are using it as an end-user tool. They want the end-user > experience to be continuously refined. > > This leads to things like gpg-agent ignoring s2k iteration counts in > order to give a positive end-user experience, at the risk of frustrating > people who are wondering why their bespoke solutions with custom s2k > iteration counts no longer work. I can second nearly everything you wrote, but here I have a different opinion: Changing the value might be good for gnupg as end-user tool and therefore I completely understand, that a change in the default is positive to most users and hence the project itself. It also increases the security of the average user I guess, as most likely they did not configure stronger KDF settings on their own. I also understand, that such changes being fruitful for many users (the main use cases) might require others with different usecases to adopt to the new standard. What I do not get is, why such design changes are applied in a non-defensive manner, thus making the end users search for the changes instead of clearly defining the new API, e.g. by failing with exit(1). I would hope for that to be a standard in security-aware software instead silently ignoring a parameter that once before contributed major boost in protection. By saying that, I hope I could make clear, that I am not against having an agile approach to moving open source software forward, when it is also causing some breakage sometimes. At least gnupg should not be come the new MS with eternal backward compatibility in some domains :-) What I would wish for (and would offer to participate in creating it) is some formalized, written down quality optimizing procedures to drive development with such a life-cycle-model in mind for API, features and deprecation. Maybe some of these already exists, otherwise it might make sense to define it? * Write down current usecases, requirements we are aiming to fulfill at the moment. This makes it more transparent what gnupg is at the moment and was it wants to be in the future. By formalizing this process, different opinions are easier to integreate at design phase thus avoiding troubles after implementtion. I believe this could also reduce frustration for gnupg-devs as changes are less disputed (usually only those opposing are the ones being loud, thus reducing the feel-good-factor of their great work). * Rules for deprecation of features settings some rules for backward compatibility but also removal of features. One thing I could envision is something like a "--quality" mode switch with GnuPG. Using this, the software will hard-fail if any function marked for deprecation (--s2k-count, weak ciphers, storage formats, ...) is used. While this would still allow great flexibility for the average user (not depending on special API or cryptographic properties) while the others may also run with "--quality" in their continuous integration environment, thus catching update frictions before those reach production. * Define a user feedback process to get a better insight and real numbers on their usecases (could be as something like having a lime survey open plus a defined feature request/ positive criticism process) to have real numbers, hard evidence where end users are moving to. This can then be combined with the strategy, where we want to move them to, e.g. to get mail-encryption more common. hd From jerry at seibercom.net Wed Dec 18 15:51:17 2019 From: jerry at seibercom.net (Gerard E. Seibert) Date: Wed, 18 Dec 2019 09:51:17 -0500 Subject: "--refresh-keys" not working. Message-ID: <20191218095117.7d776744@scorpio> Operating System: FreeBSD 11.3 KDE Plasma Version: 5.17.4 KDE Frameworks Version: 5.64.0 Qt Version: 5.13.2 Kernel Version: 11.3-RELEASE-p5 OS Type: 64-bit Processors: 4 ? ACPI CPU Memory: 31.7 GiB of RAM gpg2 --version gpg (GnuPG) 2.2.19 libgcrypt 1.8.5 I have just done a fresh installation. When I run the following command, it is apparent that something is not copacetic. gpg2 --refresh-keys gpg: enabled debug flags: memstat trust extprog gpg: mpi too large (28876 bits) gpg: read_block: read error: Invalid packet gpg: keydb: handles=108 locks=107 parse=224 get=224 gpg: build=0 update=0 insert=0 delete=0 gpg: reset=0 found=224 not=1 cache=0 not=0 gpg: kid_not_found_cache: count=0 peak=0 flushes=0 gpg: sig_cache: total=4438 cached=3013 good=2965 bad=48 gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 gpg: rndjent stat: collector=0x0000000000000000 calls=0 bytes=0 gpg: secmem usage: 0/32768 bytes in 0 blocks I have no idea what is wrong or how to fix it. I do know that this is not the way it ran on my old, and now gone, PC. -- Jerry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From ericf at disroot.org Wed Dec 18 13:02:56 2019 From: ericf at disroot.org (Eric F) Date: Wed, 18 Dec 2019 13:02:56 +0100 Subject: Best way to get fingerprint programatically In-Reply-To: References: <8246305a-1064-6e62-74da-d92c532383aa@mail.com> <87y2vahtc4.fsf@wheatstone.g10code.de> Message-ID: On 12/18/19 10:56 , Andrew Gallagher wrote: > On 18/12/2019 09:32, Werner Koch via Gnupg-users wrote: >> The -F:::::: is an interesting hack but Andrew's or my variant works >> with all AWK implementations: >> >> awk -F: '$1=="fpr" {print $10}' | head -1 > Aha, I forgot about handling multiple results. Note that you don't need > head if you're already using awk: > > awk -F: '$1=="fpr" {print $10; exit}' > > :-D This was really interesting. Thanks for that tip (all of you). :) Updated a key the other day, in a more manual way. What about updating sub-keys? $ gpg --with-colons -k 0xlongid | awk -F: '$1=="fpr" {print $10}' 0123? 4567? 8901? 2345? Any convenient way to automate that, or can I just loop it? ?something like: $ for k in $(gpg --with-colons -k 0xlongid | awk -F: '$1=="fpr" {print $10}'); do \ > gpg --quick-set-expire ${k}