From me at halfdog.net Mon Jun 1 14:34:00 2020 From: me at halfdog.net (halfdog) Date: Mon, 01 Jun 2020 12:34:00 +0000 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: <6b33aedb-65f8-723e-bb37-0a7b97917de1@enigmail.net> References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> <20200529215736.00007768.sac@300baud.de> <20200529231224.0000775a.sac@300baud.de> <9b6f5702-dd29-8cd7-cea2-0e32f8e34d55@sixdemonbag.org> <5862fc6c-33bc-8f6b-b588-f736f1c94371@gmx.com> <1f3a71ee-c6bb-c358-4b73-21adbfa380cd@enigmail.net> <4c2c08eb-14f4-9cda-6228-534ca28ba883@enigmail.net> <6b33aedb-65f8-723e-bb37-0a7b97917de1@enigmail.net> Message-ID: <4365-1591014840.646077@G648.CdAo.H2SZ> Patrick Brunschwig writes: > Andreas Boehlk Computer-Service wrote on 31.05.2020 11:09: > ... >>>> Also what if you need your public keys outside of TB such >>>> as encrypting a file? >>> >>> That's not supported by Thunderbird. The idea of OpenPGP >>> in Thunderbird is that you use it for email. >>> >> That is correct, but nevertheless it is mandatory to have >> and use a single key-store. > > For which use-case precisely? If you only use OpenPGP for emails > (and given the users I know who had support cases in the past, > this is true for the majority of the Enigmail users), then > this is irrelevant. > > To be quite clear: Thunderbird will not support GnuPG for scenarios > other than handling secret keys. And that's only because the > OpenPGP library they use can't handle smartcards yet. Once > the library will support smartcards, I expect that GnuPG support > will be removed entirely. Just out of curiosity, but knowing that this is not relevant to standard users. As encrypted mails cannot easily be malware scanned and even if they were might contain really hard-to-detect social engineering attacks, therefore systems running mail software are at a higher. Hence to avoid full system compromise, running mail software in virtual machines. With Enigmail I used some simple tool [0] to act instead of gnupg, intercept all calls to forward them over network and then filter all requests via whitelists before passing the real requests to gnupg. Thus no private keys were available on the risky desktop system (same as with smartcards), the desktop system had never full access to the private key (each whitelisted sign/encrypt operation had also to be reviewed and confirmed outside the virtual machine) and thus even full system compromise on root level would not compromise the keys the same way as a directly attached smart-card could be (pin stolen on desktop system or card used by Mallory while being unlocked). With smartcard support fully built into TB, which method for external filtering would you deem most appropriate? Have a custom virtual-smartcard library, that forwards the requests over network? Have a virtual-smartcard reader device attached to the virtual machine, that intercepts requests and forwards them to a real smartcard reader? hd [0] https://www.halfdog.net/Projects/CryptoTools/RemoteGnupg/ (outdated!) From steffen at sdaoden.eu Mon Jun 1 16:57:17 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 01 Jun 2020 16:57:17 +0200 Subject: libgcrypt: random source via library on Linux? In-Reply-To: <20200530145210.EwnnE%steffen@sdaoden.eu> References: <20200526133548.V9X00%steffen@sdaoden.eu> <875zcgtizp.fsf@wheatstone.g10code.de> <20200528124301.mbcVa%steffen@sdaoden.eu> <87sgfjrqf1.fsf@wheatstone.g10code.de> <20200529155411.TgyU1%steffen@sdaoden.eu> <20200529202134.6LZBJ%steffen@sdaoden.eu> <20200530145210.EwnnE%steffen@sdaoden.eu> Message-ID: <20200601145717.q2cXI%steffen@sdaoden.eu> Steffen Nurpmeso wrote in <20200530145210.EwnnE%steffen at sdaoden.eu>: |Steffen Nurpmeso wrote in |<20200529202134.6LZBJ%steffen at sdaoden.eu>: ||Steffen Nurpmeso wrote in ||<20200529155411.TgyU1%steffen at sdaoden.eu>: |||Werner Koch wrote in |||<87sgfjrqf1.fsf at wheatstone.g10code.de>: ||||On Thu, 28 May 2020 14:43, Steffen Nurpmeso said: | ... ||So with the attached patch libgcrypt solely relies upon getentropy I realized i am in fact subscribed to -devel and moved this over. Thank you, and Ciao! --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From wk at gnupg.org Tue Jun 2 11:49:30 2020 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Jun 2020 11:49:30 +0200 Subject: libgcrypt: random source via library on Linux? In-Reply-To: <20200529155411.TgyU1%steffen@sdaoden.eu> (Steffen Nurpmeso's message of "Fri, 29 May 2020 17:54:11 +0200") References: <20200526133548.V9X00%steffen@sdaoden.eu> <875zcgtizp.fsf@wheatstone.g10code.de> <20200528124301.mbcVa%steffen@sdaoden.eu> <87sgfjrqf1.fsf@wheatstone.g10code.de> <20200529155411.TgyU1%steffen@sdaoden.eu> Message-ID: <87y2p5pzkl.fsf@wheatstone.g10code.de> On Fri, 29 May 2020 17:54, Steffen Nurpmeso said: > Looking at the source it seems libgcrypt knows about the Linux > getrandom systemcall. Yet it does not seem to know about glibc's > getrandom library function. Which was not available back then when I implemented support for getrandom. Further; there is no guarantee that getrandom(2) is supported on all machines. We care a lot about backward compatibility and can't simply demand a certain Linux kernel or glibc version. > i would change, maybe with a new call-in to rndlinux.c which > should be made responsible for Linux-only environmental detections You don't change audited RNG code if there is not a very good reason for that. 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 wk at gnupg.org Tue Jun 2 12:01:05 2020 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Jun 2020 12:01:05 +0200 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: (karel-v's message of "Fri, 29 May 2020 14:43:28 +0200 (CEST)") References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> Message-ID: <87tuztpz1a.fsf@wheatstone.g10code.de> On Fri, 29 May 2020 14:43, karel-v_g--- said: > But it's a pity that Thunderbird developed its own solution because of > licensing issues while we have a proven working solution with GnuPG... For the records: There is no licensing issue; it is just a Mozilla policy issue not to use or depend on software which is not fully under their policy control. We have had long discussions with them more than 15 years ago with the result: no OpenPGP support and no improvements to their (back then) not very well working S/MIME code. This decision forced us to implement S/MIME in GnuPG and is also one of the reasons why Patrick does not use GPGME has interface to GnuPG, despite that it is a well tested, maintained, and widely used (think Windows) interface to GnuPG. 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 Tue Jun 2 12:19:46 2020 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Jun 2020 12:19:46 +0200 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: <7c37900f-89ad-e163-62de-cc5086e51f58@theflorys.org> (David Flory's message of "Sun, 31 May 2020 11:10:43 -0600") References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> <20200529215736.00007768.sac@300baud.de> <20200529231224.0000775a.sac@300baud.de> <9b6f5702-dd29-8cd7-cea2-0e32f8e34d55@sixdemonbag.org> <7c37900f-89ad-e163-62de-cc5086e51f58@theflorys.org> Message-ID: <87lfl5py65.fsf@wheatstone.g10code.de> On Sun, 31 May 2020 11:10, David Flory said: > How does one identify a v3 key? By trying to import it with gpg; you should get a hint that v3 keys are not anymore supported. 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 wk at gnupg.org Tue Jun 2 12:17:35 2020 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Jun 2020 12:17:35 +0200 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: <6b33aedb-65f8-723e-bb37-0a7b97917de1@enigmail.net> (Patrick Brunschwig's message of "Sun, 31 May 2020 12:35:00 +0200") References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> <20200529215736.00007768.sac@300baud.de> <20200529231224.0000775a.sac@300baud.de> <9b6f5702-dd29-8cd7-cea2-0e32f8e34d55@sixdemonbag.org> <5862fc6c-33bc-8f6b-b588-f736f1c94371@gmx.com> <1f3a71ee-c6bb-c358-4b73-21adbfa380cd@enigmail.net> <4c2c08eb-14f4-9cda-6228-534ca28ba883@enigmail.net> <6b33aedb-65f8-723e-bb37-0a7b97917de1@enigmail.net> Message-ID: <87pnahpy9s.fsf@wheatstone.g10code.de> On Sun, 31 May 2020 12:35, Patrick Brunschwig said: > Let's first define Standard users. The majority of users who use > smartcards that *I* know are expert or power users. They can handle this. I have a different experience here and we are actually promoting the use of smartcards because they better protect your private key and it is easy to explain why users need to take care of their card than of a bunch of files in the GnuPG home directory. > The "Standard users" I have in mind don't use GnuPG for anything else > than encrypting mails, and they don't use smartcards either. They won't > have this issue in any way. The standard user clicks right on a file icon, encrypts the file, and sends it as attachment using his MUA. That is an easy to teach and understand workflow and does not require any special MUA. Well, Outlook users are more and more using the well integrated support we provide in Gpg4win. 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 wk at gnupg.org Tue Jun 2 12:25:18 2020 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Jun 2020 12:25:18 +0200 Subject: gpgAnon, draft 20150 In-Reply-To: <081d4993-3e43-251a-494b-e840919ce909@mail.ru> (LisToFacTor via Gnupg-users's message of "Fri, 29 May 2020 15:39:50 +0000") References: <081d4993-3e43-251a-494b-e840919ce909@mail.ru> Message-ID: <87h7vtpxwx.fsf@wheatstone.g10code.de> On Fri, 29 May 2020 15:39, LisToFacTor said: > vaguely as "group policies". Other than that, the only substantial > change is the replacement of pgp 2.6.3ia-multi06 with gpg 1.4.10 You should not propose the use of 1.4 for any other use than decrypting old data. In particular not in a guide which is being read by people who risk high personal trouble and worse. Friends don't tell friends to use 1.4. 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 Tue Jun 2 12:32:45 2020 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Jun 2020 12:32:45 +0200 Subject: gpg generate key is not finishing In-Reply-To: (Chad L. via Gnupg-users Williams's message of "Sat, 30 May 2020 14:51:49 +0000") References: Message-ID: <87d06hpxki.fsf@wheatstone.g10code.de> On Sat, 30 May 2020 14:51, Williams, Chad L said: > Attempting to generate a key on Solaris 10 server using the below command > > gpg --full-generate-key --pinentry-mode=loopback Do not use loopback unless you know what you are doing. Adding --verbose should give you some insight what goes wrong. On an old Solaris box you may want to run something like find /usr -type f | xargs cat >/dev/null which is more effective than typing on the keyboard. 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 juergen at bruckner.tk Tue Jun 2 13:16:38 2020 From: juergen at bruckner.tk (Juergen Bruckner) Date: Tue, 2 Jun 2020 13:16:38 +0200 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: <6b33aedb-65f8-723e-bb37-0a7b97917de1@enigmail.net> References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> <20200529215736.00007768.sac@300baud.de> <20200529231224.0000775a.sac@300baud.de> <9b6f5702-dd29-8cd7-cea2-0e32f8e34d55@sixdemonbag.org> <5862fc6c-33bc-8f6b-b588-f736f1c94371@gmx.com> <1f3a71ee-c6bb-c358-4b73-21adbfa380cd@enigmail.net> <4c2c08eb-14f4-9cda-6228-534ca28ba883@enigmail.net> <6b33aedb-65f8-723e-bb37-0a7b97917de1@enigmail.net> Message-ID: <129eb5d7-6425-0366-2dda-031ac18ec9c4@bruckner.tk> Hello Patrick, > Let's first define Standard users. The majority of users who use > smartcards that *I* know are expert or power users. They can handle this. > > The "Standard users" I have in mind don't use GnuPG for anything else > than encrypting mails, and they don't use smartcards either. They won't > have this issue in any way. I'm sorry but I have to contradict you in that topic. I found out that more 'standard users' than I thought are using Smartcards or Tokens like Nitrokey or Yubikey (or anything similiar). It is requested in security/gpg workshops more and more, and in the last 3 or 4 workshops I've held, each of the 15 participiants already had a Smartcard or Token and wanted to know how to use them. So I think this is not just a topic for 'professional or power users' but also for so called standard users. best regards from Austria Juergen -- Juergen M. Bruckner -------------- 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 chad.williams at dxc.com Tue Jun 2 15:59:17 2020 From: chad.williams at dxc.com (Williams, Chad L) Date: Tue, 2 Jun 2020 13:59:17 +0000 Subject: gpg generate key is not finishing In-Reply-To: <87d06hpxki.fsf@wheatstone.g10code.de> References: <87d06hpxki.fsf@wheatstone.g10code.de> Message-ID: I tried the suggested commands below and had the same results. The key generations never finishes [cid:image002.jpg at 01D638BC.16B954A0] -----Original Message----- From: Werner Koch Sent: Tuesday, June 2, 2020 5:33 AM To: Williams, Chad L via Gnupg-users Cc: Williams, Chad L Subject: Re: gpg generate key is not finishing On Sat, 30 May 2020 14:51, Williams, Chad L said: > Attempting to generate a key on Solaris 10 server using the below > command > > gpg --full-generate-key --pinentry-mode=loopback Do not use loopback unless you know what you are doing. Adding --verbose should give you some insight what goes wrong. On an old Solaris box you may want to run something like find /usr -type f | xargs cat >/dev/null which is more effective than typing on the keyboard. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. DXC Technology Company - Headquarters: 1775 Tysons Boulevard, Tysons, Virginia 22102, USA. DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. --. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 26616 bytes Desc: image002.jpg URL: From wk at gnupg.org Wed Jun 3 11:08:58 2020 From: wk at gnupg.org (Werner Koch) Date: Wed, 03 Jun 2020 11:08:58 +0200 Subject: gpg generate key is not finishing In-Reply-To: (Chad L. via Gnupg-users Williams's message of "Tue, 2 Jun 2020 13:59:17 +0000") References: <87d06hpxki.fsf@wheatstone.g10code.de> Message-ID: <877dwoo6s5.fsf@wheatstone.g10code.de> On Tue, 2 Jun 2020 13:59, Williams, Chad L said: > [cid:image002.jpg at 01D638BC.16B954A0] [Which is a screenshot of the curses pinentry waiting for input.] If you want the volunteers here to help you, it is important that you write a proper bug report. This includes telling us the version of GnuPG and of the OS, describing _exactly_ what you did, and providing logs. You should be aware thata curses based panel disturbs the stderr diagnostics printed to the tty; thus you should redirect it to a log file. BTW, there are commercial support service providers available [1] who will be able to talk you to a solution. Shalom-Salam, Werner [1] https://gnupg.org/service.html for a list. gnupg.com is my own service which also develops and maintains GnuPG and friends. -- 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 ludwig.reiter at intevation.de Wed Jun 3 11:36:31 2020 From: ludwig.reiter at intevation.de (Ludwig Reiter) Date: Wed, 3 Jun 2020 11:36:31 +0200 Subject: Examples of use python3-gpg and emails Message-ID: <202006031136.31448.ludwig.reiter@intevation.de> Hi folks, I am working on examples for encrypting and signing mails. It uses python3-gpg (gpgme) and the python3 email lib and is in draft. The git repo is at gitlab. See: https://gitlab.com/reiterl/python3-gpg-examples.git If you are interested in learning to use python3-gpg with email context, it should be useful for you. Please write me a mail with comments, if you look at it. Also feedback would be nice. Kind Regards, Ludwig -- Intevation GmbH, Osnabr?ck Firmensitz: Neuer Graben 17, 49074 Osnabr?ck Registereintrag: Amtsgericht Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From ludwig.reiter at intevation.de Wed Jun 3 12:52:46 2020 From: ludwig.reiter at intevation.de (Ludwig Reiter) Date: Wed, 3 Jun 2020 12:52:46 +0200 Subject: how to use WKD with python3? Message-ID: <202006031252.46292.ludwig.reiter@intevation.de> Hi folks, how do I get public keys over WKD with python3/gpgme? I didn't find anything about this in the web. It seems like python3-gpg doesn't support to use WKD. Can someone point me to a good start point? Kind Regards, Ludwig -- Intevation GmbH, Osnabr?ck Firmensitz: Neuer Graben 17, 49074 Osnabr?ck Registereintrag: Amtsgericht Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From aheinecke at gnupg.org Wed Jun 3 17:16:52 2020 From: aheinecke at gnupg.org (Andre Heinecke) Date: Wed, 03 Jun 2020 17:16:52 +0200 Subject: how to use WKD with python3? In-Reply-To: <202006031252.46292.ludwig.reiter@intevation.de> References: <202006031252.46292.ludwig.reiter@intevation.de> Message-ID: <3581025.7UyGShJzBo@esus> Hi, I'll try to answer this even though I don't completely know how to do it in python, but I know how it's done in C / C++. On Wednesday 3 June 2020 12:52:46 CEST Ludwig Reiter wrote: > how do I get public keys over WKD with python3/gpgme? you can do a keylist with KEYLIST_MODE_LOCATE for a single mbox. If python does not have that (it was added later this mode is KEYLIST_MODE_EXTERNAL | KEYLIST_MODE_LOCAL) So I think it would be: ctx.keylist(some_uid, mode=(gpg.constants.keylist.mode.LOCAL | gpg.constants.keylist.mode.EXTERNAL)) or: ctx.keylist(some_uid, mode=gpg.constants.keylist.mode.LOCATE) > I didn't find anything about this in the web. It seems like python3-gpg > doesn't support to use WKD. You can force that only WKD is used in the keylist if you set the auto-key- locate context flag (gpgme_set_ctx_flag) to "clear,nodefault,wkd". > Can someone point me to a good start point? Good starting points are usually our "run-foo" test tools under gpgme/tests. I usually use them as a starting point and example. We maintain these tools because we usually use them when developing new features. ;-) Best regards, Andre -- GnuPG.com - a brand of g10 Code, the GnuPG experts. g10 Code GmbH, Erkrath/Germany, AG Wuppertal HRB14459 GF Werner Koch, USt-Id DE215605608, www.g10code.com. GnuPG e.V., Rochusstr. 44, D-40479 D?sseldorf. VR 11482 D?sseldorf Vorstand: W.Koch, B.Reiter, A.Heinecke Mail: board at gnupg.org Finanzamt D-Altstadt, St-Nr: 103/5923/1779. Tel: +49-211-28010702 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From denis.beurive at gmail.com Fri Jun 5 14:14:53 2020 From: denis.beurive at gmail.com (Denis BEURIVE) Date: Fri, 5 Jun 2020 14:14:53 +0200 Subject: Standalone signature (0x02) ? Message-ID: Hello, I am studying the RFC 4880 and I am using GPG as a tool to experiment. I explored PGP signatures. You can find notes here : https://github.com/denis-beurive/bouncy-castle-examples/blob/master/doc/pgp-sig.md I pretty much explore all types of signatures, except one : *Standalone signature (sigclass = 0x02*). In the RFC, you can read : This signature is a signature of only its own subpacket contents. It is calculated identically to a signature over a zero-length binary document. Note that it doesn't make sense to have a V3 standalone signature. This description remains mysterious. I looked for this signature in various PGP documents but could not spot one. *Is it possible to generate this kind of signature with GPG ?* *What is this signature used for ?* My intuition tells me that it may be used in association with hashed subpackets. However, I cannot find any document to confirm this intuition. Thanks for your help, Denis -------------- next part -------------- An HTML attachment was scrubbed... URL: From chad.williams at dxc.com Fri Jun 5 15:16:13 2020 From: chad.williams at dxc.com (Williams, Chad L) Date: Fri, 5 Jun 2020 13:16:13 +0000 Subject: gpg generate key is not finishing In-Reply-To: <877dwoo6s5.fsf@wheatstone.g10code.de> References: <87d06hpxki.fsf@wheatstone.g10code.de> <877dwoo6s5.fsf@wheatstone.g10code.de> Message-ID: Is there a site to write the bug report or response to this email? This is on Solaris UNIX 10 Sparc based system using below version of gnugp 133 PROD/ah57sdcux01013 /export/home/dca1367$ gpg --version gpg (GnuPG) 2.2.20 libgcrypt 1.8.5 Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: /export/home/dca1367/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 -----Original Message----- From: Werner Koch Sent: Wednesday, June 3, 2020 4:09 AM To: Williams, Chad L via Gnupg-users Cc: Williams, Chad L Subject: Re: gpg generate key is not finishing On Tue, 2 Jun 2020 13:59, Williams, Chad L said: > [cid:image002.jpg at 01D638BC.16B954A0] [Which is a screenshot of the curses pinentry waiting for input.] If you want the volunteers here to help you, it is important that you write a proper bug report. This includes telling us the version of GnuPG and of the OS, describing _exactly_ what you did, and providing logs. You should be aware thata curses based panel disturbs the stderr diagnostics printed to the tty; thus you should redirect it to a log file. BTW, there are commercial support service providers available [1] who will be able to talk you to a solution. Shalom-Salam, Werner [1] https://gnupg.org/service.html for a list. gnupg.com is my own service which also develops and maintains GnuPG and friends. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. DXC Technology Company - Headquarters: 1775 Tysons Boulevard, Tysons, Virginia 22102, USA. DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. --. From 2017-r3sgs86x8e-lists-groups at riseup.net Sat Jun 6 19:19:09 2020 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Sat, 6 Jun 2020 18:19:09 +0100 Subject: Comparison of RSA vs elliptical keys In-Reply-To: <87imgi1mrw.fsf@wheatstone.g10code.de> References: <5ff821cc-b71d-04c9-0640-00e914b2e9b8@gmx.com> <4794bb75-fbd7-45dd-b368-f6fcfd9051db@www.fastmail.com> <4c3f44ad-2e49-30a3-c3ac-dc18e99e81ea@vulcan.xs4all.nl> <059039b4-52f4-f63d-637b-c4e23f30c23d@unifr.ch> <5975a18f-d676-1c0f-7cfb-d3a5d2ae1939@sixdemonbag.org> <20200513150943.00001d15.sac@300baud.de> <87sgg29u1w.fsf@wheatstone.g10code.de> <20200514230126.00001289.sac@300baud.de> <20200515004100.00005d5c.sac@300baud.de> <665264269.20200515005157@mail.riseup.net> <20200516224955.00005826.sac@300baud.de> <1589682794.1744.76.camel@16bits.net> <875zct92gk.fsf@wheatstone.g10code.de> <1337448496.20200520180632@mail.riseup.net> <875zco4ai4.fsf@wheatstone.g10code.de> <1888339675.20200522150827@mail.riseup.net> <87imgi1mrw.fsf@wheatstone.g10code.de> Message-ID: <446468133.20200606181909@mail.riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi > For sure the MUA knows your own key. No. The MUA just passes the email address to GnuPG and GnuPG selects the key. - -- Best regards MFPA Eat well, stay fit - Die anyway -----BEGIN PGP SIGNATURE----- iQQLBAEWCgOzFiEE1ZATtM6MlUs0sIeidL1wjXEhZekFAl7b0BpfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQ1 OTAxM0I0Q0U4Qzk1NEIzNEIwODdBMjc0QkQ3MDhENzEyMTY1RTnCdCYAmDMEXgvh ABYJKwYBBAHaRw8BAQdArI4Hnf6FTTsybpJYDIMD0+xTrXnsPfC/3Uu2cxa4teW0 EjB4QjkzQjIwRjNDNjUwREFCQ4ifBBMWCgBHAhsBDAsNCQwICwcKAwQBAgcVCgkI CwMCBRYDAgEAAh4BAheAFiEEqezluzzMIo36IIunuTsg88ZQ2rwFAl4L4QIFCQLP 0wIACgkQuTsg88ZQ2rwoOgEAiWZc9DebbXONXemf/QkWTxhV7OBcg983xmEhV9l1 LwYA/AzZAko/rn0Erv1M4ZjAtsDqeAFt0PNNeUmi4eGUwyIOuDMEXgvhARYJKwYB BAHaRw8BAQdAi9UIpY+60yljsQPtgMvyp6/22AJvlFJc+TOKsklaMNmJAVYEGBYK ACYCGwIWIQSp7OW7PMwijfogi6e5OyDzxlDavAUCXgvhAgUJAs/TAQDiwBYgBBkW CgB9FiEE1ZATtM6MlUs0sIeidL1wjXEhZekFAl4L4QFfFIAAAAAALgAoaXNzdWVy LWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQ1OTAxM0I0 Q0U4Qzk1NEIzNEIwODdBMjc0QkQ3MDhENzEyMTY1RTkACgkQdL1wjXEhZem5+AD9 FKjnQrwvWofniFDjLQgiAcTmZWJaLE4AhWBDS5lc6rMBAIst24nbfvXzFmjwtowD q4GzfSi67WeVp7XFtdF0OAsDCRC5OyDzxlDavEvRAP4vRocpa0PyNtwNKhNPSHIO 9hVI1r9FomgHqZOyo2YFcwD/cMdoU7nLsARyoihiD01sdZ4nNpiPzD/mZBwLwY0K 0wa4OAReC+ECEgorBgEEAZdVAQUBAQdAgkTQ4VKOfMY0P81tSnm3W/Hr6z+kFNu8 bjH6Y9FkUX8DAQgHiH4EGBYKACYCGwwWIQSp7OW7PMwijfogi6e5OyDzxlDavAUC XgvhAwUJAs/TAQAKCRC5OyDzxlDavJ4WAQCRf2LVenMTVSM7k2BlDJV+Y410xT14 R3eKvpIPDO9iagD+NrZruWKSTD93k6V38dewDa5Tn0LSbHcGidiazqREogMACgkQ dL1wjXEhZengGgEAtkVJtrhO63gg+8W/vEOtPmlhyicLneItm195ikeQs6YBAK/K Of9LOL3CXEQzyoLaM1GtWqyjQ+A9d94rXjyZHD8IiQ8RBAEWCg65FiEElgyGKNWS /4zei7C/4OLe4dbI7voFAl7b0BtfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlv bnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk2MEM4NjI4RDU5MkZGOENERThC QjBCRkUwRTJERUUxRDZDOEVFRkHNeiYAmQINBFmF3poBEACjmnBUOd79vOc6sywd w7d85ItYQDeSh5WhTguXkt84+8C+oLXYbWelVmyjtZ+vOsZSXb44tE2zNCWouNK/ wcE16JmmIV3VVn9I/EpMTK/iFx3e/SGk6C56uopgsQFlDjbYRZ6bPc+ImsEdfaj3 DyYrWJO3dCEBEEOv4/u7UZ/ulBJOEW4pCJjgk7esmT9LmG0AvSSUZhZQqqMo5wvr fz07uDbJ6MFjPXgBIThtJPjKSpTXCaaCs2GJZVkKagR1rexytIgsEU3OYHAl+qYf HqcFqa1xbrdEjC8RDFIU0vJc3aGpRufGEVlnDw/LfWN6qX4NE9IC/QyKFXEQOybP 9UEl9ti/dE6FUSHT+g/M4zCdSL1RFMkz91/UnjgrZAboMoKgBZqYLpawjYIyVMYT dIerDQYiymCdD+Ifkgc3FwgTsfSFnFJXwLL2hqJGoZSz6jHKKiDDKathLQqWEvAb Co6FP5VsqILi2Tu+6IWOeLp07YXzDiDNR7/yqDGOCavYmwN3mt5TwdNeOd22LFWH LBcsDc5gIB2EkJoMpemG1TJi60FX9P2WI8K7ICBmFzwnvH9i2xBln+4+YDHyod7c lC1I0wE2BbO6ttNaUR/6Xczm8gjx0zzKsvOZZDTXjXtO8ss41j7Rg0TS3C4+QWMc mHCJCiu8tD4GS5du/V5xw8TJ8QARAQABtBIweEFDRTU2OTcxRDU1NURBQTWJAl4E EwEKAEgCGwECHgECF4ACGQELCw0JCAwHAwsKBAIGFQoJCAsDBRYDAgEAFiEEeRDE X4n8jMLL0kqwrOVpcdVV2qUFAl7VLfsFCQWgFTsACgkQrOVpcdVV2qVD5hAAjbEz bwbyBdscKbawdz3H6rWoeuoMJ1IInK3u5qrFAQwTrlsNmNFj8mDqsZGcgOiTKVlb Kr+zokLIazna7poly/fMOKFB0ryGO/nJaHdq6z7x359wL77avx0oK+LFZvgAyQHF kmSKxL1t3yQ2JtjaXzJ30dYuEK9W9CD7XBvKbDUk1AxGYfh1zO7c1jbjstgyXq2e J+mAJaJYqPzVN7+GGPPb4rV6/hZLsbyp3lrnzSZmB9fVzUQsRcPgBxKlP3zEytRu fmdmXYShml4PQIuyB4xOuqlhTZZ7//4C9AUMz+cYhrBY0RSNHrjUdbMZLwWukMCk zc5LeDn73Y3uaRTCwVqxIZt9IPq03sj6tU8ytTqX/ToK4bfyWhPVENwHE3WQq8m+ hXtLiHAD4stFVXby6vBDpyKYgegiiYM5qubrot7smXY5GDCIjwZ7dsORDPry21t2 fh9fkNTXPYklaQXFklCaI9RMskkbooQZWrE68lhUhOd0423J4WE3XlVRbCpj+U9i tq4iF8ueSCw5KtTs8prkNva/MW+PzbZ/FpHOenAiD6NgXB2Zr3OS5AH+cajsQHrx Ns4f8KZEB34ZHhYI/yFuczsFRq0/BNQPsdvnnM7Y9Oa39iSwdTSv8Z/Z6I1NjJAy tm/K1f3qSFzE5WRgXrUEjXIc1A9y082u3QYskvK5Ag0EWYXwgAEQAO+wh3g3SgeB WkzLaIHo3p7Z92CyEnssgvZnfaWNBowuv1INtprqa15yRpaIr8eFlchlVqCiQ2FN 54tWkND5qlallwi2YSUW+nkEXCvyUR1S///MmwI5qos0A+Sil3uPsuBQtRezCaNE ghM5a83Lfvv9kYqzfa9D6gCYUCv6NtbH/yeshOuRhT2P3jFK0+kIObyPO26Xsbfd bocutYA3c/27TAsE8VJvu4yqL5CUvz5H+EzGAdmrXVYD/VFxMrbIkKjmb7I0Tnl8 RF3IUsL3SK/AKWYPOI4mMp5dv4yO/gYVoWX5Fd4dv6EQmvHMfiIvsxP8EBOTNVEt j/rac4P7Trdsc7CWsL5zzpofxIFQibo3JVNTRs/PPIlVmPROYLbXaolufgAmi+E8 BCer780yc4nkmWOEcepuk3cQCM3l6OrgI8aWQyrcf4uW4Jtn98AldJ21PhtN4A0d 5PF0YvX/OrXoi3XBROUVLY6IF5QbkSMeOvqJWzgktxvULI53Q3jtZvgtmF2dZ5rF gJCy3PjuXRBi2ZTz47eW94E7xDr04euhFnyMaiDMKS0XAj978kyCUrtDsssWp83j 1IZt5Bd7JmtohThlEZCQ3Y0u3Gjmj9Nkv18qmF8O21Qe0LzG8Ad9HPTbQd9Rk+GQ z57WxlcsjK2bC0WG7f6R5BHq1YmuoD8nABEBAAGJAjwEGAEKACYCGwwWIQR5EMRf ifyMwsvSSrCs5Wlx1VXapQUCXtUuawUJBaADdQAKCRCs5Wlx1VXapW7JD/0fKfbj JLJIKIF5AemDcDN60FMvkM/6K14ScQsdO9z/RnCO2C4riGz3Otw8ZHQGVS1E353l fGKlyDtv7yJtzLb/6FA+I/2u+sSoK8WYpfShl2m+C0gYPqC9/4Qc5fVvpvw0lMWg dbGIHIcXx7fOmEl58VMlWWVIkZWPTfyJXDQu+55ZG+sK4CqLL6ffXFqP33pyMg0E uy6vzH664tbyceiuhF9ga8WQ1vg4ByANBzBkMcZurdMC0BLlSEVIZrRsARUul7gZ rpDGz0BgOnI0ztOgFrdU/hcnV5pQasF083u5rgZbIKHLosPtFA5T8cQ8XoHqI6jI UnC8E6Fe12wL0XE/2FDUgUHriXK3acU4MKyW30RzO1l4c7h18zrTfVRLN5JY+KLN jv3ptD8nT7JqGgNqSWA5qqfP6IpVCsCGQvN7uNm1ywmpQJxiONUiXkJEPtDgW/t9 p7jMoo7cfIPtVdrILB4nxHKTQSU9to39wOeUUHk2qXntT9dqSGYqHooezfktsFtx yQ+7d9xAi9VRQukMLk5rog/GGH8+67vFxzZJhYTDmKfzBuHTnm2HjcV9k7gqrTiG 5ZuXKavtnxhjnns9Bfuuj6YZkD2eGwpazirWzi8udrsQ+/WvmHUI4XMVjTNwSNtj PmrHVung/urdu/l+jhw4441y0Pbc5l3Off5/xbgzBFmF9HQWCSsGAQQB2kcPAQEH QIvVCKWPutMpY7ED7YDL8qev9tgCb5RSXPkzirJJWjDZiQKzBBgBCgAmAhsCFiEE eRDEX4n8jMLL0kqwrOVpcdVV2qUFAl7VLmwFCQWf/4EAgXYgBBkWCAAdFiEElgyG KNWS/4zei7C/4OLe4dbI7voFAlmF9HQACgkQ4OLe4dbI7vpdcAEA2GBaDiUbWapu jHFGfh/a3MH1mXU/7Vrf+6aCBSoqwlABAOlljw5f6gCnD6b8LjBIsS2W/U5jTtAt 1aouzFDvhioICRCs5Wlx1VXapd0JEACQSkLwLegfS19aQ+7lqxMLOI8wLkmes+ov PILuBfPmL+OhQQfQsWQ8bPfT/YZVWcyUDgDEBzGgSiunlKkbUq98oEUHxas8N2vZ aOXfX0jXAHPUkTXjNXWE/eKtiT9SCpKHBgaEngisGGtMymxm/WKnNnftRu7VtM5d 8ctL7RZnl8fpHYivbWKoMdBsrSUsLLhkp1yuUVE4yTlU3kR5Xnc92ek2s8drJ3qF aSEyJQUWXsVyS1pvtu4rtc/eQkvTmbYjZ7opCE+5PbtMbD/F8KJyHBO1WP0JrbQC NPZsb48t8+Hm3XAChkvKze/5v+O5lG1iAF3Ci3CbhGl47G1dhFL3mRj5F4wFRdP7 1xFC3oSqXwbuXd99wyrDSScQFjhXbxSLYEwwz3t/CW4urjOfk5BIOwEz0+jgosSv CCWYJJXAm6nK5k1lpDAnjYYxVLCWdeC+gRkzVPSVBCmL1QYsoQayxcW9KLp3XD9l MjedAq+zhYHoL6bS/rj7sTuAVG128tGIKKEkNAzqwYYj7ySY4WJiUJYeUr8Iv+nJ l8alY0KjNewcq6FEpSmrZyqjE+zjbpPEIg6fNiziKiTRdmb5zxru2PlurPKb+2hi ZbUmIyInjP76/UlpNNhwVJrTObUFyuLjyiXUxiQBr7+CFUfADaocf7OieZniE74N VKfYgyI9H7g4BFmF99oSCisGAQQBl1UBBQEBB0CCRNDhUo58xjQ/zW1Kebdb8evr P6QU27xuMfpj0WRRfwMBCAeJAjwEGAEKACYCGwwWIQR5EMRfifyMwsvSSrCs5Wlx 1VXapQUCXtUubAUJBZ/8GwAKCRCs5Wlx1VXapZz5D/91MYwguJMhWnzi33OnBEuQ 92UA7DUKsuzAVD5wYKJvX98AOdnNpKKMmQk+bYkUreL+U66EPXG6cR7i/jb5L+U6 2NKy1TXSTZ05Z+FkwcPXvzeFL6d22pan+EATdYmLgFirn5/nlXJewcKAKX24Zi2i oKqwpBIEo59IFlIvEpPtAwXRZD33UeJYg6r6zA8hNnZ6OwxsZAiaBNRKuLMu7M9V uhSZ9SjVZyWVXNG0ycbtDWBqbe6eqppHP1/xknFtFrDzMSPrmPwXt047ubkIo85U Ds2+Ue+TkHRnTkSFQR5dESshdnGtlqU1V6s9M9MmE1hsYBQIPHEPJKLEAthMPcEJ Y2CoX9ha+KeMYiHeoPfn2h7WB8svUzi/+Udwnc1RgRFYmJAK9Em7jqr+hJ8u+XCN m8vYvyNo0gttuMEvlqgZWMvN6u3J2m+Innq+/1XrCL8WBUGOGPwg5OpIvWOhhU6B 98VvkNV3M3Kft6cZ7tj47c6MeeIp8WgwtzTZjURf+iELwsqgWUV4ov86lqcAcgJL td29xHZCo9fhA0byXELkI9x0qqZYTUHSHn52uwd60PuCNPFZlzhgptNi1XZp1FBO hp54i+EWrrCW6ujLFqFhu/OTBTkAyo/NR0Wz/C4r4+4Y4RywMK+PvbN0aTFZRl2Y 0rhJcRZ/qNN1RCP5pAQMzgAKCRDg4t7h1sju+lMLAP0WC6v9TunqrtKo7goZUEI7 XapkTwLP7fcPZaOooJSskgEA4RIPCaO1r1Q1RaoIKjo6Tke7uZKImVnpck09i0J3 yAc= =cex0 -----END PGP SIGNATURE----- From oub at mat.ucm.es Sun Jun 7 16:50:31 2020 From: oub at mat.ucm.es (Uwe Brauer) Date: Sun, 07 Jun 2020 16:50:31 +0200 Subject: root certificate for smime missing gpgconf --launch dirmngr Message-ID: <87sgf7lyko.fsf@mat.ucm.es> Hi I received a smime signed message, however it turns out that I cannot use it for encrypting my responsce Since > gpgsm: issuer certificate: #/CN=T-TeleSec GlobalRoot Class 2,OU=T-Systems Trust Center,O=T-Systems Enterprise Services GmbH,C=DE Is not found I have drmngr installed (Ubuntu 16.06) and run gpgconf --launch dirmngr However the root certificate is still not found. Thunderbird provides this certificate so I could install it manually. However I would prefer an automated solution. Any hints? Thanks and regards Uwe Brauer From oub at mat.ucm.es Sun Jun 7 17:14:10 2020 From: oub at mat.ucm.es (Uwe Brauer) Date: Sun, 07 Jun 2020 17:14:10 +0200 Subject: root certificate for smime missing gpgconf --launch dirmngr Message-ID: <87eeqqnc1p.fsf@mat.ucm.es> Hi I received a smime signed message, however it turns out that I cannot use it for encrypting my responsce Since > gpgsm: issuer certificate: #/CN=T-TeleSec GlobalRoot Class 2,OU=T-Systems Trust Center,O=T-Systems Enterprise Services GmbH,C=DE Is not found I have drmngr installed (Ubuntu 16.06) and run gpgconf --launch dirmngr However the root certificate is still not found. Thunderbird provides this certificate so I could install it manually. However I would prefer an automated solution. Any hints? Thanks and regards Uwe Brauer -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5673 bytes Desc: not available URL: From wk at gnupg.org Mon Jun 8 11:20:48 2020 From: wk at gnupg.org (Werner Koch) Date: Mon, 08 Jun 2020 11:20:48 +0200 Subject: Standalone signature (0x02) ? In-Reply-To: (Denis BEURIVE via Gnupg-users's message of "Fri, 5 Jun 2020 14:14:53 +0200") References: Message-ID: <87d06952xb.fsf@wheatstone.g10code.de> On Fri, 5 Jun 2020 14:14, Denis BEURIVE said: > *Is it possible to generate this kind of signature with GPG ?* No. > *What is this signature used for ?* I can't remember. I am pretty sure this has been discussed in the WG back in 1998 or so. If you are really interested you could dive into the archives or ask on the WG ML; maybe Jon Callas remembers for what it was intended. 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 denis.beurive at gmail.com Mon Jun 8 12:24:15 2020 From: denis.beurive at gmail.com (Denis BEURIVE) Date: Mon, 8 Jun 2020 12:24:15 +0200 Subject: Standalone signature (0x02) ? In-Reply-To: <87d06952xb.fsf@wheatstone.g10code.de> References: <87d06952xb.fsf@wheatstone.g10code.de> Message-ID: Thank you Werner, I'll look in the WG back in 1998 (for the "sake of completeness"). Regards, Denis Le lun. 8 juin 2020 ? 11:25, Werner Koch a ?crit : > On Fri, 5 Jun 2020 14:14, Denis BEURIVE said: > > > *Is it possible to generate this kind of signature with GPG ?* > > No. > > > *What is this signature used for ?* > > I can't remember. I am pretty sure this has been discussed in the WG > back in 1998 or so. If you are really interested you could dive into > the archives or ask on the WG ML; maybe Jon Callas remembers for what it > was intended. > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernhard at intevation.de Tue Jun 9 09:47:49 2020 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 9 Jun 2020 09:47:49 +0200 Subject: gpg generate key is not finishing In-Reply-To: References: <877dwoo6s5.fsf@wheatstone.g10code.de> Message-ID: <202006090947.54845.bernhard@intevation.de> Am Freitag 05 Juni 2020 15:16:13 schrieb Williams, Chad L via Gnupg-users: > Is there a site to write the bug report or response to this email? If the report is complete enough https://dev.gnupg.org/ may take it, but often this ml or the devel ml is better. The important part is the diagnosis logs, you enable them with the -v and --debug command line flags. And you may need shell redirection to see it. E.g. GNUPGHOME=~/dot-gnupg-test2/ gpg -vvv --debug-all --quick-generate-key test at example.com 2>debug-log.txt Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Tue Jun 9 09:40:25 2020 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 9 Jun 2020 09:40:25 +0200 Subject: root certificate for smime missing gpgconf --launch dirmngr In-Reply-To: <87eeqqnc1p.fsf@mat.ucm.es> References: <87eeqqnc1p.fsf@mat.ucm.es> Message-ID: <202006090940.29384.bernhard@intevation.de> Hi Uwe, Am Sonntag 07 Juni 2020 17:14:10 schrieb Uwe Brauer via Gnupg-users: > However the root certificate is still not found. Thunderbird provides > this certificate so I could install it manually. > However I would prefer an automated solution. from my point of view, installing a root CA in the hiearchical trust model means that you fully trust it, thus it cannot be done automatically, unless you have a trusted sources of root certificates. If you trust a set of root certificates, like the ones shipped with your operating system or a different application, you could just import them all and mark them trusted. Of course you would need to sync this, if the set changes on updates. Some hints about using CMS and S/MIME are here https://wiki.gnupg.org/X.509 but this misses instructions how to deal with root certificates in modern GnuPG versions currently. Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3855 bytes Desc: not available URL: From computer at boehlk.com Tue Jun 9 17:25:11 2020 From: computer at boehlk.com (Andreas Boehlk Computer-Service) Date: Tue, 9 Jun 2020 17:25:11 +0200 Subject: Certified OpenPGP-encryption after release of Thunderbird 78 In-Reply-To: <6b33aedb-65f8-723e-bb37-0a7b97917de1@enigmail.net> References: <20200527234129.00006492.sac@300baud.de> <20200528232112.00007649.sac@300baud.de> <20200529215736.00007768.sac@300baud.de> <20200529231224.0000775a.sac@300baud.de> <9b6f5702-dd29-8cd7-cea2-0e32f8e34d55@sixdemonbag.org> <5862fc6c-33bc-8f6b-b588-f736f1c94371@gmx.com> <1f3a71ee-c6bb-c358-4b73-21adbfa380cd@enigmail.net> <4c2c08eb-14f4-9cda-6228-534ca28ba883@enigmail.net> <6b33aedb-65f8-723e-bb37-0a7b97917de1@enigmail.net> Message-ID: Am 31.05.2020 um 12:35 schrieb Patrick Brunschwig: > Andreas Boehlk Computer-Service wrote on 31.05.2020 11:09: >> Hello Patrick, >> >> >> Am 31.05.2020 um 10:01 schrieb Patrick Brunschwig: >>> Mark wrote on 31.05.2020 01:28: >>>> Doesn't TB also need your secret keys to decrypt messages?? >>> >>> With smartcard support via GnuPG, all secret key operations are handled >>> by GnuPG, and all public key operations are handled by TB (Note: the >>> standard case, without smartcard support, will be that all keys are in >>> Thunderbird). >>> >>> The use-cases are clearly distinct: >>> - encryption: you only need public keys >>> - decryption: you only need secret keys >>> - signing: you only need secret keys >>> - verification: you only need public keys >>> >> The standard user will not be able to work with that "solution". >> Compared to the "enigmail-solution" this is the hell and bound to fail. > > Let's first define Standard users. The majority of users who use > smartcards that *I* know are expert or power users. They can handle this. > > The "Standard users" I have in mind don't use GnuPG for anything else > than encrypting mails, and they don't use smartcards either. They won't > have this issue in any way. > >>>> Also what if you need your public keys outside of TB such as encrypting >>>> a file? >>> >>> That's not supported by Thunderbird. The idea of OpenPGP in Thunderbird >>> is that you use it for email. >>> >> That is correct, but nevertheless it is mandatory to have and use a >> single key-store. > > For which use-case precisely? If you only use OpenPGP for emails (and > given the users I know who had support cases in the past, this is true > for the majority of the Enigmail users), then this is irrelevant. > The use cases are clear and I myself and some of my clients use them. And when I speak from my point of view it is enough work to take care of one key store and I personally do not want to have a second one; and this second one has to be synchronized on every single endpoint as well. That is twice the work. > To be quite clear: Thunderbird will not support GnuPG for scenarios > other than handling secret keys. And that's only because the OpenPGP > library they use can't handle smartcards yet. Once the library will > support smartcards, I expect that GnuPG support will be removed entirely. > From then on PGP and the second key store will be mandatory for the purpose of signing and decrypting. > Note: I'm not a Thunderbird developer and I don't drive Thunderbird > decisions -- this is simply my expectation of what will happen. > Yes, I got that of course. It is just my lack of understanding TB's decision to not trying to adapt a running system in a proper way. > -Patrick > Andreas -------------- 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 Tue Jun 9 18:26:12 2020 From: wk at gnupg.org (Werner Koch) Date: Tue, 09 Jun 2020 18:26:12 +0200 Subject: On using --debug flags (was: gpg generate key is not finishing) In-Reply-To: <202006090947.54845.bernhard@intevation.de> (Bernhard Reiter's message of "Tue, 9 Jun 2020 09:47:49 +0200") References: <877dwoo6s5.fsf@wheatstone.g10code.de> <202006090947.54845.bernhard@intevation.de> Message-ID: <87ftb49pej.fsf_-_@wheatstone.g10code.de> On Tue, 9 Jun 2020 09:47, Bernhard Reiter said: > GNUPGHOME=~/dot-gnupg-test2/ gpg -vvv --debug-all --quick-generate-key Pretty please do not use --debug-all. It is better to use dedicated debug flags to get useful logs and avoid leaking secrets. All GnuPG components support symbolic debug constants; use for example gpg --debug help to view them. In many cases --debug ipc is helpful and won't reveal any long term secrets. The very first thing after a problem is to use --verbose which often is enough to see what's wrong. Only then try the debug constants. 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 patrick at enigmail.net Fri Jun 12 07:45:14 2020 From: patrick at enigmail.net (Patrick Brunschwig) Date: Fri, 12 Jun 2020 07:45:14 +0200 Subject: agent_genkey failed: Invalid flag Message-ID: A user of Enigmail tried to create a key using the following command: /usr/bin/gpg2 --charset utf-8 --display-charset utf-8 \ --no-auto-check-trustdb --batch --no-tty --no-verbose --status-fd 2 \ --gen-key %echo Generating key Key-Type: EDDSA Key-Curve: Ed25519 Key-Usage: sign Subkey-Type: ECDH Subkey-Curve: Curve25519 Subkey-Usage: encrypt Name-Real: [name] Name-Email: [email] Expire-Date: 1825 gpg reports the following error: gpg: agent_genkey failed: Invalid flag gpg: key generation failed: Invalid flag [GNUPG:] ERROR key_generate 16777288 [GNUPG:] KEY_NOT_CREATED Any idea what could be wrong here? -Patrick From gniibe at fsij.org Fri Jun 12 10:49:28 2020 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 12 Jun 2020 17:49:28 +0900 Subject: agent_genkey failed: Invalid flag In-Reply-To: References: Message-ID: <87o8poy8h3.fsf@jumper.gniibe.org> Hello, Patrick Brunschwig wrote: > gpg reports the following error: > > gpg: agent_genkey failed: Invalid flag > gpg: key generation failed: Invalid flag > [GNUPG:] ERROR key_generate 16777288 > [GNUPG:] KEY_NOT_CREATED > > Any idea what could be wrong here? The error is from libgcrypt. I think that libgcrypt is too old to use Ed25519/Curve25519. When generating Ed25519/Curve25519 key/subkey, gpg uses three flags: comp eddsa djb-tweak It seems that some flag(s) is not supported by libgcrypt in the user's system. Meaning: comp: compact format (only use x or y-coordinate to represent an EC point) eddsa: use for EdDSA djb-tweak: specify bits of secret is tweaked DJB's method; MSB is set, LSBs are cleared. -- From justin at justinsteven.com Mon Jun 15 04:36:07 2020 From: justin at justinsteven.com (Justin Steven) Date: Mon, 15 Jun 2020 12:36:07 +1000 Subject: Bug? Vulnerability? gpgme_op_verify_result() can be made to return a list of zero signatures Message-ID: Hi all, On 9 June 2020 I disclosed a vulnerability in fwupd. There was a problem with the way that it used libgpgme to verify the PGP signature of its update metadata. I would like to put it forward for wider discussion: is libgpgme is working as intended, or should this particular behaviour be considered a bug or a vulnerability in libgpgme? # How fwupd uses libgpgme fwupd used gpgme_op_verify() and gpgme_op_verify_result() with a GPG homedir containing only trusted keys. If gpgme_op_verify() returned GPG_ERR_NO_ERROR then it looped over the signatures returned by gpgme_op_verify_result(). If any of those signatures were "bad" (According to logic implemented by fwupd) then the metadata signature was deemed "bad". Otherwise, the signature was deemed "good". This logic is fragile, if not outright incorrect. fwupd is assuming that if it gets GPG_ERR_NO_ERROR from gpgme_op_verify() then it will get at least one signature back from gpgme_op_verify_result() In short, by giving gpgme_op_verify() the following arguments: * A normal (i.e. NON-DETACHED) signature as 'sig' * Any data as 'signed_text' (which is a hint to gpgme that 'sig' should be detached) * Anything as 'plain' Then gpgme will attempt to verify the non-detached signature as if it were a detached signature. I found that this triggers interesting behaviour in libgpgme, where gpggme_op_verify() will return GPG_ERR_NO_ERROR but gpgme_op_verify_result() will return a list of zero signatures. This violates the assumption made by fwupd, which allowed me to bypass its signature validation. fwupd fixed this vulnerability on their end by ensuring that libgpgme returned a non-zero number of signatures. However, I wouldn't be surprised if there were other software projects making the same assumption, and I think libgpgme could act more predictably (or indeed "correctly") considering such inputs. More details on the fwupd vulnerability are available at https://github.com/justinsteven/advisories/blob/master/2020_fwupd_dangling_s3_bucket_and_CVE-2020-10759_signature_verification_bypass.md (In particular the section titled "So whose fault was this anyway?") # Could this be a bug in libgpgme? During the disclosure process with fwupd I reached out to . In short, the developers on duty said that this is expected behaviour from libgpgme and that fwupd is solely to blame for its insecure use of libgpgme. The developers on duty made a documentation change cautioning developers of this behaviour at I do agree that fwupd was using libgpgme in an unorthodox and very dangerous way. However, I feel that it is very surprising for gpgme_op_verify() to return GPG_ERR_NO_ERROR but for gpgme_op_verify_result() to return a list of zero signatures. This feels like an erroneous condition to me, and with libgpgme working the way it is, there is the risk of surprising developers and for there to be verification bypasses in their code. # Caveat It is possible that there are many sets of input to gpgme_op_verify() that will cause it to return zero signatures. I stopped looking for such edge-cases after I found the one I did. Justin From wk at gnupg.org Mon Jun 15 12:24:15 2020 From: wk at gnupg.org (Werner Koch) Date: Mon, 15 Jun 2020 12:24:15 +0200 Subject: Bug? Vulnerability? gpgme_op_verify_result() can be made to return a list of zero signatures In-Reply-To: (Justin Steven's message of "Mon, 15 Jun 2020 12:36:07 +1000") References: Message-ID: <87h7vc7hkg.fsf@wheatstone.g10code.de> Hi! On Mon, 15 Jun 2020 12:36, Justin Steven said: > GPG_ERR_NO_ERROR but for gpgme_op_verify_result() to return a list of zero > signatures. This feels like an erroneous condition to me, and with libgpgme We already explained that this is a requirement for OpenPGP because OpenPGP allows to embed a signature in encrypted data (combined method in contrast to the rarely used MIME containers). Thus when calling the decrypt function you can't know in advance whether there will be a signature - not returning an error if there is no signature is proper behaviour. More important: Checking the signature is one thing; its result is basically whether the data is corrupted. The more important step is to check whether you can trust the key used to generate a signature; this is basic crypto knowledge which can't be ignored even if you use "GnuPG Made Easy". GPGME has mechanisms to do this in a not too complicated way and of course it requires to loop over all signatures. 20 years ago when Debian started to sign packages it was figured that this is not a trivial task and together we developed gpgv which is a simple command line tool dedicated to check signatures against a fixed set of keys. There is no gpgme support for gpgv because calling gpgv is pretty straightforward. 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 justin at justinsteven.com Mon Jun 15 14:15:56 2020 From: justin at justinsteven.com (Justin Steven) Date: Mon, 15 Jun 2020 22:15:56 +1000 Subject: Bug? Vulnerability? gpgme_op_verify_result() can be made to return a list of zero signatures In-Reply-To: <87h7vc7hkg.fsf@wheatstone.g10code.de> References: <87h7vc7hkg.fsf@wheatstone.g10code.de> Message-ID: Hi Werner, Thanks for responding > this is a requirement for OpenPGP because OpenPGP allows to embed a signature > in encrypted data (combined method in contrast to the rarely used MIME > containers). Thus when calling the decrypt function you can't know in > advance whether there will be a signature - not returning an error if there > is no signature is proper behaviour. I'm not referring to any decrypt function. I'm only referring to: * gpgme_op_verify() * gpgme_op_verify_result() I do understand that a PGP message can be both encrypted and signed. Taking tests/run-verify.c as an example (I only just found it) it seems as though gpgme_op_verify() doesn't handle encrypted data at all, and the behaviour I identified is somewhat novel. ``` % ./run-verify <(echo hello | gpg --detach-sign) <(echo hello) Original file name .: [none] MIME flag ..........: no Signature ...: 0 status ....: Success summary ...: valid green fingerprint: F7DFBCA15A8D731FB0E7323A8719360278F979DD created ...: 1592217969 expires ...: 0 validity ..: full val.reason : Success pubkey algo: 1 (RSA) digest algo: 10 (SHA512) pka address: [none] pka trust .: n/a other flags: de-vs ``` Above is expected behaviour ``` % ./run-verify <(echo hello | gpg --sign) Original file name .: [none] MIME flag ..........: no Signature ...: 0 status ....: Success summary ...: valid green fingerprint: F7DFBCA15A8D731FB0E7323A8719360278F979DD created ...: 1592218246 expires ...: 0 validity ..: full val.reason : Success pubkey algo: 1 (RSA) digest algo: 10 (SHA512) pka address: [none] pka trust .: n/a other flags: de-vs ``` Also expected behaviour ``` % ./run-verify <(echo hello | gpg --sign) <(echo hello) Original file name .: [none] MIME flag ..........: no ``` Above is the surprising behaviour I'm writing about (No error; no signatures) ``` % ./run-verify <(echo hello | gpg --encrypt -r 'Test Key') <(echo hello) Original file name .: [none] MIME flag ..........: no run-verify: verify failed: General error ``` Above is trying to verify an encrypted message as though it's a detached signature. General error is expected (There's no signature to verify) ``` % ./run-verify <(echo hello | gpg --encrypt -r 'Test Key') Original file name .: [none] MIME flag ..........: no run-verify: verify failed: General error ``` Above is trying to verify an encrypted message as though it's a regular signature. General error is expected (There's no signature to verify) ``` % ./run-verify <(echo hello | gpg --sign --encrypt -r 'Test Key') <(echo hello) Original file name .: [none] MIME flag ..........: no run-verify: verify failed: General error ``` Above is trying to verify an encrypted signed message as though it's a detached signature. General error is probably expected behaviour (I don't know if it could possibly make sense to ever verify an encrypted message with a detached signature) ``` % ./run-verify <(echo hello | gpg --sign --encrypt -r 'Test Key') Original file name .: [none] MIME flag ..........: no run-verify: verify failed: General error ``` Above is trying to verify an encrypted signed message as though it's a regular signature. General error might be unexpected - if gpgme_op_verify() can be used to check signatures on an encrypted message, is this a functional bug? (Please do forgive my unfamiliarity with libgpgme. If gpgme_op_verify() can be used to verify signatures on encrypted messages, do you know where I could find an example?) > More important: Checking the signature is one thing; its result is basically > whether the data is corrupted. The more important step is to check whether > you can trust the key used to generate a signature; this is basic crypto > knowledge which can't be ignored even if you use "GnuPG Made Easy". GPGME > has mechanisms to do this in a not too complicated way and of course it > requires to loop over all signatures. I don't disagree at all. For what it's worth, I'm not trying to shift blame from fwupd to libgpgme. I believe that fwupd can be (and indeed was) vulnerable; and at the same time, libgpgme is exhibiting surprising behaviour. In my mind, if libgpgme can be made to behave more predictably, it's not necessarily taking responsibility for fwupd's bug. It's an outcome that would serve the greater good. That is, unless there's a reason why libgpgme's behaviour is actually functionally required - which I know you're trying to explain, I just can't think of a concrete example as it relates to gpgme_op_verify(). If you have one I'd greatly appreciate it. One last thing, https://www.gnupg.org/documentation/manuals/gpgme/Verify.html says: > The function gpgme_op_verify verifies that the signature in the data object > sig is a valid signature [...] The function returns the error code > GPG_ERR_NO_ERROR if the operation could be completed successfully, [...] > GPG_ERR_NO_DATA if sig does not contain any data to verify, and passes > through any errors that are reported by the crypto engine support routines. Based on this description, I can't understand how it makes sense for gpgme_op_verify() to return GPG_ERR_NO_ERROR ("the operation could be completed successfully") if: * gpgme_op_verify_result() is going to return zero signatures; and * gpg would print an error and exit with a non-zero status in a similar case There is even a GPG_ERR_NO_DATA result that could be returned instead. Justin From sac at 300baud.de Thu Jun 18 15:33:38 2020 From: sac at 300baud.de (Stefan Claas) Date: Thu, 18 Jun 2020 15:33:38 +0200 Subject: As a fan of GnuPG ... Message-ID: <20200618153338.00002a53.sac@300baud.de> ... you should try this out in your terminal and look at the beginning of the output: $ echo 1fccaf3d | xxd -r -p | openssl dgst -sha256 -binary | openssl enc -base64 :-) P.S. A friend of mine came up with a shell script to do this. Regards Stefan -- my 'hidden' service gopherhole: gopher://iria2xobffovwr6h.onion From cderr at simons-rock.edu Thu Jun 18 16:31:47 2020 From: cderr at simons-rock.edu (charlie derr) Date: Thu, 18 Jun 2020 10:31:47 -0400 Subject: As a fan of GnuPG ... In-Reply-To: <20200618153338.00002a53.sac@300baud.de> References: <20200618153338.00002a53.sac@300baud.de> Message-ID: <63d016e4-34c3-d39b-fe24-6e566c58333e@simons-rock.edu> On 6/18/20 9:33 AM, Stefan Claas wrote: > ... you should try this out in your terminal and look at the beginning > of the output: > > $ echo 1fccaf3d | xxd -r -p | openssl dgst -sha256 -binary | openssl enc > -base64 > > :-) > > P.S. A friend of mine came up with a shell script to do this. > > Regards > Stefan > Is getting those first 5 characters into the output of this string really that amazing? Or am i missing something significant about what the rest of the seemingly random characters represent? spoiler, my output was: GnuPGCfA8srqYMiMWAFrWTvP0n0pbfSGRdUIA7kv/1U= somewhat confused, ~c -- Charlie Derr Director, Instructional Technology 413-528-7344 https://www.simons-rock.edu Bard College at Simon's Rock Encryption key: http://hope.simons-rock.edu/~cderr/ Personal writing: https://medium.com/@cderr pronouns: either he/him or they/them is acceptable Home landline: 860-435-1427 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Thu Jun 18 16:54:09 2020 From: sac at 300baud.de (Stefan Claas) Date: Thu, 18 Jun 2020 16:54:09 +0200 Subject: As a fan of GnuPG ... In-Reply-To: <63d016e4-34c3-d39b-fe24-6e566c58333e@simons-rock.edu> References: <20200618153338.00002a53.sac@300baud.de> <63d016e4-34c3-d39b-fe24-6e566c58333e@simons-rock.edu> Message-ID: <20200618165409.00000468.sac@300baud.de> charlie derr wrote: > Is getting those first 5 characters into the output of this string > really that amazing? Or am i missing something significant about what > the rest of the seemingly random characters represent? Well, it is just for fun and maybe people find it cool. At least it is a brute-force method to find words in such hashed and base64 encoded strings. I have a Golang version of the program and can let it run for a while and with 'grep' I can look for words and save the strings in a file. Not so fast as those GPU BTC-vanity generators, but fun and interesting IMHO. Regards Stefan -- my 'hidden' service gopherhole: gopher://iria2xobffovwr6h.onion From Ilya.Pirogov at setitagila.ru Fri Jun 19 10:43:32 2020 From: Ilya.Pirogov at setitagila.ru (=?windows-1251?B?yOv8/yDP6PDu4+7i?=) Date: Fri, 19 Jun 2020 13:43:32 +0500 Subject: GnuPG for WIndows and key management files. Message-ID: <202006191343316548677@setitagila.ru> I am interested in the question of where to find the files pubring.gpg, secring.gpg and randseed.bin in GnuPG for WIndows. ???? ??????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From angel at pgp.16bits.net Sun Jun 21 04:02:14 2020 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Sun, 21 Jun 2020 04:02:14 +0200 Subject: As a fan of GnuPG ... In-Reply-To: <20200618165409.00000468.sac@300baud.de> References: <20200618153338.00002a53.sac@300baud.de> <63d016e4-34c3-d39b-fe24-6e566c58333e@simons-rock.edu> <20200618165409.00000468.sac@300baud.de> Message-ID: <1592704934.4387.58.camel@16bits.net> On 2020-06-18 at 16:54 +0200, Stefan Claas wrote: > charlie derr wrote: > > > Is getting those first 5 characters into the output of this string > > really that amazing? Or am i missing something significant about what > > the rest of the seemingly random characters represent? > > Well, it is just for fun and maybe people find it cool. At least it is > a brute-force method to find words in such hashed and base64 encoded > strings. Each base64 character encodes 6 bits. So on average you can expect to get those 5 characters there once in 2^(5*6) inputs, thus requiring about 2?? operations. Note you can do the same with gpg keys, getting such vanity keyids. Best regards From 2017-r3sgs86x8e-lists-groups at riseup.net Sat Jun 20 23:53:50 2020 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Sat, 20 Jun 2020 22:53:50 +0100 Subject: GnuPG for WIndows and key management files. In-Reply-To: <202006191343316548677@setitagila.ru> References: <202006191343316548677@setitagila.ru> Message-ID: <753937102.20200620225350@mail.riseup.net> An HTML attachment was scrubbed... URL: From sac at 300baud.de Sun Jun 21 10:57:09 2020 From: sac at 300baud.de (Stefan Claas) Date: Sun, 21 Jun 2020 10:57:09 +0200 Subject: As a fan of GnuPG ... In-Reply-To: <1592704934.4387.58.camel@16bits.net> References: <20200618153338.00002a53.sac@300baud.de> <63d016e4-34c3-d39b-fe24-6e566c58333e@simons-rock.edu> <20200618165409.00000468.sac@300baud.de> <1592704934.4387.58.camel@16bits.net> Message-ID: <20200621105709.00000d63.sac@300baud.de> ?ngel wrote: > On 2020-06-18 at 16:54 +0200, Stefan Claas wrote: > > charlie derr wrote: > > > > > Is getting those first 5 characters into the output of this string > > > really that amazing? Or am i missing something significant about what > > > the rest of the seemingly random characters represent? > > > > Well, it is just for fun and maybe people find it cool. At least it is > > a brute-force method to find words in such hashed and base64 encoded > > strings. > > > Each base64 character encodes 6 bits. So on average you can expect to > get those 5 characters there once in 2^(5*6) inputs, thus requiring > about 2?? operations. > > Note you can do the same with gpg keys, getting such vanity keyids. I used a Vanity Generator this year, on Palindrome Day, and my fingerprint for my current key is: 02022020D638E78F4DFE737C419F025C897DB2E6 :-) ^^^^^^^^ Certified by Governikus at the *same* day. :-) Regards Stefan -- my 'hidden' service gopherhole: gopher://iria2xobffovwr6h.onion From kloecker at kde.org Sun Jun 21 17:36:34 2020 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sun, 21 Jun 2020 17:36:34 +0200 Subject: GnuPG for WIndows and key management files. In-Reply-To: <753937102.20200620225350@mail.riseup.net> References: <202006191343316548677@setitagila.ru> <753937102.20200620225350@mail.riseup.net> Message-ID: <30058097.XR7lqj05fd@breq> On Samstag, 20. Juni 2020 23:53:50 CEST MFPA via Gnupg-users wrote: > On Friday 19 June 2020 at 9:43:32 AM, in > , ???? ??????? wrote:- > > I am interested in the question of where to find the files > > pubring.gpg, secring.gpg and randseed.bin in GnuPG > > for WIndows. > > My pubring.gpg and random_seed files are at %AppData%\gnupg. In the > old days secring.gpg was there too, but that file is not used anymore. pubring.gpg is also gone. It has been replaced with pubring.kbx in modern GnuPG. And what used to be stored in secring.gpg (i.e. you secret keys) can now be found in the folder private-keys-v1.d. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From 2017-r3sgs86x8e-lists-groups at riseup.net Mon Jun 22 03:22:43 2020 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Mon, 22 Jun 2020 02:22:43 +0100 Subject: GnuPG for WIndows and key management files. In-Reply-To: <30058097.XR7lqj05fd@breq> References: <202006191343316548677@setitagila.ru> <753937102.20200620225350@mail.riseup.net> <30058097.XR7lqj05fd@breq> Message-ID: <824873401.20200622022158@mail.riseup.net> Hi On Sunday 21 June 2020 at 4:36:34 PM, in , Ingo Kl?cker wrote:- > pubring.gpg is also gone. It has been replaced with > pubring.kbx in modern > GnuPG. Oops. I forgot about that. -- Best regards MFPA There is no snooze button for a cat that wants breakfast -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 6436 bytes Desc: not available URL: From ama6701559a1 at icloud.com Sun Jun 21 22:27:50 2020 From: ama6701559a1 at icloud.com (Andrew Mallin) Date: Sun, 21 Jun 2020 16:27:50 -0400 Subject: Upgrading from gpg1 to gpg2: lots of trouble, need help Message-ID: <93E73614-F84D-460B-9AAA-75DFC2BC52C4@icloud.com> Sent from my iPhone From wk at gnupg.org Mon Jun 22 15:08:08 2020 From: wk at gnupg.org (Werner Koch) Date: Mon, 22 Jun 2020 15:08:08 +0200 Subject: GnuPG for WIndows and key management files. In-Reply-To: <202006191343316548677@setitagila.ru> (=?utf-8?B?ItCY0LvRjNGP?= =?utf-8?B?INCf0LjRgNC+0LPQvtCyIidz?= message of "Fri, 19 Jun 2020 13:43:32 +0500") References: <202006191343316548677@setitagila.ru> Message-ID: <87zh8v1c5j.fsf@wheatstone.g10code.de> On Fri, 19 Jun 2020 13:43, ???? ??????? said: > I am interested in the question of where to find the files > pubring.gpg, secring.gpg and randseed.bin in GnuPG for WIndows. Those files are not anymore used (see the otehr replies). However to figure out GnuPG's home directory you use the command gpgconf --list-dirs homedir or leave out "homedir" and it lists all important file system locations. This command works on all platforms. "gpg --version" also prints the home directory right before the list of supported algorithms. 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 blmatthews at gmail.com Tue Jun 23 23:21:32 2020 From: blmatthews at gmail.com (Brian L. Matthews) Date: Tue, 23 Jun 2020 14:21:32 -0700 Subject: gpg bug Message-ID: I'm installing gpg from source and ran into a problem. I'm making gnupg-2.2.20 on an iMac running macos 10.14.6. I've done $ ./configure --prefix=$HOME/gnu $ make successfully. However, on make check I found that it doesn't work if I have a space in PATH. I do because VMWare Fusion adds "/Applications/VMware Fusion.app/Contents/Public" to PATH, but VMWare Fusion isn't required to reproduce the problem, if I just do: $ PATH="$PATH:a b" make check I get (after the tests in common, kbx, sm, scd, and tools pass): Making check in openpgp LC_ALL=C EXEEXT= PATH=../gpgscm:/Library/Frameworks/Python.framework/Versions/3.8/bin:/Users/blm/perl5/bin:/Users/blm/bin:/Users/blm/gnu/bin:/usr/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:a b abs_top_srcdir=/Users/blm/src/3rdparty/gpg/gnupg-2.2.20 objdir=/Users/blm/src/3rdparty/gpg/gnupg-2.2.20 GPGSCM_PATH=/Users/blm/src/3rdparty/gpg/gnupg-2.2.20/tests/gpgscm /Users/blm/src/3rdparty/gpg/gnupg-2.2.20/tests/gpgscm/gpgscm \ /Users/blm/src/3rdparty/gpg/gnupg-2.2.20/tests/openpgp/run-tests.scm /bin/sh: b: command not found make[2]: *** [xcheck] Error 127 make[1]: *** [check-recursive] Error 1 make: *** [check-recursive] Error 1 If I don't add "a b" to PATH, make check completes successfully. The workaround is obvious so I have everything installed and running, but thought you might want to know. I'm not on the mailing list and didn't want to create an account on the bug tracking site just for this. Thanks, Brian From sac at 300baud.de Wed Jun 24 17:16:30 2020 From: sac at 300baud.de (Stefan Claas) Date: Wed, 24 Jun 2020 17:16:30 +0200 Subject: OpenPGP messages to .png images Message-ID: <20200624171630.00004f0d.sac@300baud.de> Hi all, a little test. Please download the tiny image https://ibb.co/S3CsHb0 and convert it to a signed message, with file2png.py (Python2) https://github.com/hasherezade/crypto_utils Should be IMHO come in handy to bypass mail filters, like procmail etc. or maybe useful to send as MMS with a smartphone, which I haven't tried out yet. Regards Stefan -- my 'hidden' service gopherhole: gopher://iria2xobffovwr6h.onion From d.haid at gogi.tv Thu Jun 25 11:24:36 2020 From: d.haid at gogi.tv (Daniel Haid) Date: Thu, 25 Jun 2020 11:24:36 +0200 Subject: Use the same passphrase for PGP and SSH keys and get prompted only once by gpg-agent Message-ID: <311a700a-1cda-6c2f-36fe-b6478ca888ac@gogi.tv> > I've successfully set it up, now whenever I restart gpg-agent (e.g. on > reboot), it will ask for the passphrase twice, once for the GPG keys, > once for the SSH keys, even though they are the same passphrases. I need a solution for this same problem. > You may now wonder why this does not happen when you decrypt a mail, > reply to it and sign the reply. [...] gpg-agent knows about it and > tries the last passphrase used for any of the the subkeys of a key. However, even if the primary key has capabilities [SCA] and one subkey has capability [E], if I use the subkey for encryption first and then try to use the primary key for SSH I am asked for the passphrase again. Is this expected? > No, there is no way to configure an extra hack to also test a > passphrase for an ssh key. Do you not think this could be useful? Gnupg uses the same passphrase for the primary key and all subkeys by default, so this should be a common setup? > I thought of one way, but really is a hack and it's predicated on the > standard key access being invoked first. If SSH always comes first > then it won't work. Could you tell me what your hack is? My current solution is use one primary key with [SCA] capabilities and one [E] subkey. In my scripts, instead of gpg --decrypt [...] && ssh [...] I now use gpg -s /dev/null && gpg --decrypt [...] && ssh [...] which asks for my passphrase once for signing and then uses it for decrypting and for ssh. Do you know any clean way to do this? Note that I only need this for scripts that do multiple things simultaneously, so I *can* run arbitrary commands first. It would be perfectly fine for me to send something like "ask for only one passphrase and try to unlock KEYGRIP1 and KEYGRIP2 with it" to the agent. (Or, even better "if the passphrase for KEYGRIP1 or KEYGRIP2 is cached, try to unlock the other one with that. Otherwise ask for one passphrase and unlock both".) Is such a thing possible? Regards, DH From 400thecat at gmx.ch Fri Jun 26 09:33:15 2020 From: 400thecat at gmx.ch (Fourhundred Thecat) Date: Fri, 26 Jun 2020 09:33:15 +0200 Subject: decrypt aes256 encrypted file without gpg-agent Message-ID: <1206f0a3-dea3-4e7c-6ac7-8837e0d2e565@gmx.ch> Hello, I have file encrypted with symmetric cipher (aes256) and not signed. How can I decrypt it without using gpg agent ? I get these errors: $ gpg -d file.gpg gpg: failed to start gpg agent ... gpg: decryption failed: no secret key as I said above, there is no secret key involved here. It is symmetric and not signed. From jaredvacanti at gmail.com Fri Jun 26 17:32:05 2020 From: jaredvacanti at gmail.com (Jared Vacanti) Date: Fri, 26 Jun 2020 10:32:05 -0500 Subject: Specifying smartcard reader when multiple readers attached Message-ID: Using gpg (GnuPG) 2.2.19, is there a way to specify a reader when multiple readers are available? For example: $ gpg --card-status --reader FEITIAN gpg: WARNING: "--reader-port" is an obsolete option - it has no effect except on scdaemon I seem to only be able to interact with smartcards or the Yubikey 5 NFC OpenPGP applet when the device is the only one available. Any feedback would be really appreciated. Jared -------------- next part -------------- An HTML attachment was scrubbed... URL: From vedaal at nym.hush.com Fri Jun 26 20:15:52 2020 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Fri, 26 Jun 2020 14:15:52 -0400 Subject: decrypt aes256 encrypted file without gpg-agent In-Reply-To: <1206f0a3-dea3-4e7c-6ac7-8837e0d2e565@gmx.ch> Message-ID: <20200626181552.D221D80081A@smtp.hushmail.com> On 6/26/2020 at 4:54 AM, "Fourhundred Thecat" <400thecat at gmx.ch> wrote: > >Hello, > >I have file encrypted with symmetric cipher (aes256) and not >signed. > >How can I decrypt it without using gpg agent ? > >I get these errors: > >$ gpg -d file.gpg >gpg: failed to start gpg agent >... >gpg: decryption failed: no secret key ===== Also can't get it without using agent. Tried using option of --no-use-agent and gpg2 says 'obsolete option, has no effect'. The option of --no-default-keyring doesn't help if the home directory is not open. Agent will not start unless home directory is open ( my home directory is in an encrypted container) Once the home directory is there (when I unencrypted mine), agent starts, and a pinentry window opens asking for the symmetric passphrase, When I unencrypt the home directory, but not the keyring, gpg will still decrypt when using the option of --no-default-keyring (feature request: can GPG2 be made to work from only the command-line without a pine entry window, and without gpg-agent?) TIA vedaal From dag at gnui.org Sat Jun 27 18:52:42 2020 From: dag at gnui.org (Dmitry Alexandrov) Date: Sat, 27 Jun 2020 19:52:42 +0300 Subject: decrypt aes256 encrypted file without gpg-agent In-Reply-To: <20200626181552.D221D80081A@smtp.hushmail.com> (vedaal via Gnupg-users's message of "Fri, 26 Jun 2020 14:15:52 -0400") References: <1206f0a3-dea3-4e7c-6ac7-8837e0d2e565@gmx.ch> <20200626181552.D221D80081A@smtp.hushmail.com> Message-ID: vedaal at nym.hush.com wrote: > can GPG2 be made to work from only the command-line without a pine entry window | '--pinentry-mode MODE' | Set the pinentry mode to MODE. Allowed values for MODE are: | ??? | loopback | Redirect Pinentry queries to the caller. Note that in | contrast to Pinentry the user is not prompted again if he | enters a bad password. ? (info "(gnupg) GPG Esoteric Options") -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From wk at gnupg.org Sun Jun 28 16:07:40 2020 From: wk at gnupg.org (Werner Koch) Date: Sun, 28 Jun 2020 16:07:40 +0200 Subject: decrypt aes256 encrypted file without gpg-agent In-Reply-To: <1206f0a3-dea3-4e7c-6ac7-8837e0d2e565@gmx.ch> (Fourhundred Thecat's message of "Fri, 26 Jun 2020 09:33:15 +0200") References: <1206f0a3-dea3-4e7c-6ac7-8837e0d2e565@gmx.ch> Message-ID: <87tuyvxp03.fsf@wheatstone.g10code.de> On Fri, 26 Jun 2020 09:33, Fourhundred Thecat said: > How can I decrypt it without using gpg agent ? You can't the agent is a cornerstone of gpg and is thus required. 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 400thecat at gmx.ch Sun Jun 28 21:23:56 2020 From: 400thecat at gmx.ch (Fourhundred Thecat) Date: Sun, 28 Jun 2020 21:23:56 +0200 Subject: decrypt aes256 encrypted file without gpg-agent In-Reply-To: <87tuyvxp03.fsf@wheatstone.g10code.de> References: <1206f0a3-dea3-4e7c-6ac7-8837e0d2e565@gmx.ch> <87tuyvxp03.fsf@wheatstone.g10code.de> Message-ID: > On 2020-06-28 16:07, Werner Koch wrote: > On Fri, 26 Jun 2020 09:33, Fourhundred Thecat said: > >> How can I decrypt it without using gpg agent ? > > You can't the agent is a cornerstone of gpg and is thus required. I thought the agent is for manipulating the private key. But why do I need the agent, when no secret key is involved? I simply want to decrypt a password-encrypted file. What possible useful role would agent play? Seems to me that this is a terrible design, that gpg is basically unusable without agent. Why should I need some monstrosity running as daemon, when I just want to decrypt file? I remember a time, when gpg was a simple, cleanly design utility that worked. Imagine the maintainers of ls decided, that ls will no longer work, unless ls-daemon is running. What happened to this project? From kloecker at kde.org Sun Jun 28 21:47:34 2020 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sun, 28 Jun 2020 21:47:34 +0200 Subject: decrypt aes256 encrypted file without gpg-agent In-Reply-To: <1206f0a3-dea3-4e7c-6ac7-8837e0d2e565@gmx.ch> References: <1206f0a3-dea3-4e7c-6ac7-8837e0d2e565@gmx.ch> Message-ID: <6181584.YkJhdY0nTz@breq> On Freitag, 26. Juni 2020 09:33:15 CEST Fourhundred Thecat wrote: > I have file encrypted with symmetric cipher (aes256) and not signed. > > How can I decrypt it without using gpg agent ? Use openssl. Or another simple program offering symmetric encryption/ decryption with AES. GnuPG is a tool for public key encryption. The fact that it can also be used for symmetric encryption doesn't mean that it's the best tool for symmetric encryption. You want to decrypt files without using gpg-agent? Then don't use gpg. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From sac at 300baud.de Sun Jun 28 22:24:54 2020 From: sac at 300baud.de (Stefan Claas) Date: Sun, 28 Jun 2020 22:24:54 +0200 Subject: decrypt aes256 encrypted file without gpg-agent In-Reply-To: <6181584.YkJhdY0nTz@breq> References: <1206f0a3-dea3-4e7c-6ac7-8837e0d2e565@gmx.ch> <6181584.YkJhdY0nTz@breq> Message-ID: <20200628222454.00001d84.sac@300baud.de> Ingo Kl?cker wrote: > On Freitag, 26. Juni 2020 09:33:15 CEST Fourhundred Thecat wrote: > > I have file encrypted with symmetric cipher (aes256) and not signed. > > > > How can I decrypt it without using gpg agent ? > > Use openssl. Or another simple program offering symmetric encryption/ > decryption with AES. Well, the OP could use sequoia pgp, to decrypt his file(s) ... Regards Stefan -- my 'hidden' service gopherhole: gopher://iria2xobffovwr6h.onion From rjh at sixdemonbag.org Sun Jun 28 22:24:43 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 28 Jun 2020 16:24:43 -0400 Subject: decrypt aes256 encrypted file without gpg-agent In-Reply-To: References: <1206f0a3-dea3-4e7c-6ac7-8837e0d2e565@gmx.ch> <87tuyvxp03.fsf@wheatstone.g10code.de> Message-ID: <96b95437-f8d5-9126-f28d-0e4c35d72bcb@sixdemonbag.org> > I thought the agent is for manipulating the private key. It's also responsible for calling pinentry, which is how GnuPG receives passphrases. It's a pluggable component: on Windows you get a Windows pinentry that uses a Windows look and feel, on KDE you get a Qt one that looks like a KDE app, on GNOME you get a GTK one that looks like a GNOME app, and so on. GnuPG sees the symmetrically encrypted message and knows it needs to recover/derive a key. It calls gpg-agent, which in turn calls pinentry. > But why do I need the agent, when no secret key is involved? I simply > want to decrypt a password-encrypted file. What possible useful role > would agent play? > > Seems to me that this is a terrible design... Let's be clear: you're passing judgment on a design without first learning what the design is. > I remember a time, when gpg was a simple, cleanly design utility that > worked. GnuPG adopted gpg-agent in large part to clean up GnuPG's design. GnuPG was introduced in GnuPG 1.9.0, released in August *2003*. You've ignored GnuPG development for so long you're surprised by a change introduced seventeen years ago. That's on you. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 821 bytes Desc: OpenPGP digital signature URL: From 400thecat at gmx.ch Mon Jun 29 07:56:46 2020 From: 400thecat at gmx.ch (Fourhundred Thecat) Date: Mon, 29 Jun 2020 07:56:46 +0200 Subject: decrypt aes256 encrypted file without gpg-agent In-Reply-To: <96b95437-f8d5-9126-f28d-0e4c35d72bcb@sixdemonbag.org> References: <1206f0a3-dea3-4e7c-6ac7-8837e0d2e565@gmx.ch> <87tuyvxp03.fsf@wheatstone.g10code.de> <96b95437-f8d5-9126-f28d-0e4c35d72bcb@sixdemonbag.org> Message-ID: <3c720787-703d-811b-a9bf-7ac4bb6342cc@gmx.ch> > On 2020-06-28 22:24, Robert J. Hansen wrote: >> I remember a time, when gpg was a simple, cleanly design utility that >> worked. > > GnuPG adopted gpg-agent in large part to clean up GnuPG's design. GnuPG > was introduced in GnuPG 1.9.0, released in August *2003*. > > You've ignored GnuPG development for so long you're surprised by a > change introduced seventeen years ago. That's on you. excuse me, gpg-agent might have been introduced in 2003, but it was optional. Until not long ago, it was still possible to decrypt file with password, without having the agent. Also, I would like to add, I am not protesting the existence of the agent. I actually use it on my desktop/gui. I am protesting the fact, that gpg can no longer be used without the agent. From rjh at sixdemonbag.org Mon Jun 29 08:31:24 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 29 Jun 2020 02:31:24 -0400 Subject: decrypt aes256 encrypted file without gpg-agent In-Reply-To: <3c720787-703d-811b-a9bf-7ac4bb6342cc@gmx.ch> References: <1206f0a3-dea3-4e7c-6ac7-8837e0d2e565@gmx.ch> <87tuyvxp03.fsf@wheatstone.g10code.de> <96b95437-f8d5-9126-f28d-0e4c35d72bcb@sixdemonbag.org> <3c720787-703d-811b-a9bf-7ac4bb6342cc@gmx.ch> Message-ID: <2d3d6a64-3593-5b34-31f0-271b5d33e105@sixdemonbag.org> > excuse me, gpg-agent might have been introduced in 2003, but it was > optional. Until not long ago, it was still possible to decrypt file with > password, without having the agent. If you were using GnuPG 1.4, yes. GnuPG 2.0 and later have always used gpg-agent. If you want a gpg-agent free version of GnuPG, use version 1.4. From 400thecat at gmx.ch Mon Jun 29 08:11:40 2020 From: 400thecat at gmx.ch (Fourhundred Thecat) Date: Mon, 29 Jun 2020 08:11:40 +0200 Subject: decrypt aes256 encrypted file without gpg-agent In-Reply-To: <6181584.YkJhdY0nTz@breq> References: <1206f0a3-dea3-4e7c-6ac7-8837e0d2e565@gmx.ch> <6181584.YkJhdY0nTz@breq> Message-ID: <387321e0-73c4-eeb6-731a-df613a521d5e@gmx.ch> > On 2020-06-28 21:47, Ingo Kl?cker wrote: > On Freitag, 26. Juni 2020 09:33:15 CEST Fourhundred Thecat wrote: >> I have file encrypted with symmetric cipher (aes256) and not signed. >> >> How can I decrypt it without using gpg agent ? > > Use openssl. Or another simple program offering symmetric encryption/ > decryption with AES. how can I use openssl, to decrypt a file that has been encrypted with gpg (symmetrically, aes256). Can openssl read the gpg format/header ? Can openssl decrypt gpg file ? thanks, From wk at gnupg.org Mon Jun 29 11:49:13 2020 From: wk at gnupg.org (Werner Koch) Date: Mon, 29 Jun 2020 11:49:13 +0200 Subject: decrypt aes256 encrypted file without gpg-agent In-Reply-To: <96b95437-f8d5-9126-f28d-0e4c35d72bcb@sixdemonbag.org> (Robert J. Hansen's message of "Sun, 28 Jun 2020 16:24:43 -0400") References: <1206f0a3-dea3-4e7c-6ac7-8837e0d2e565@gmx.ch> <87tuyvxp03.fsf@wheatstone.g10code.de> <96b95437-f8d5-9126-f28d-0e4c35d72bcb@sixdemonbag.org> Message-ID: <87ftaexkva.fsf@wheatstone.g10code.de> On Sun, 28 Jun 2020 16:24, Robert J. Hansen said: > GnuPG sees the symmetrically encrypted message and knows it needs to > recover/derive a key. It calls gpg-agent, which in turn calls pinentry. In addition gpg-agent also takes care of caching passphrases which makes even symmetrically encryption more convenient. It is also used to figure out a suitable number of hash iteration to make new symmetric passphrase encryption stronger - this can't be done by a plain command line tool. In theory it is possible to pass a set of option to avoid the use of gpg-agent for plain symmetric encryption but as soon as any pubkey key is used as an alternative to the symmetric encryption the agent is required to check whether a private key exists. From engineering and security POVs it does not make sense to special case very rare use cases. 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 400thecat at gmx.ch Mon Jun 29 18:38:03 2020 From: 400thecat at gmx.ch (Fourhundred Thecat) Date: Mon, 29 Jun 2020 18:38:03 +0200 Subject: decrypt aes256 encrypted file without gpg-agent In-Reply-To: References: <1206f0a3-dea3-4e7c-6ac7-8837e0d2e565@gmx.ch> <87tuyvxp03.fsf@wheatstone.g10code.de> <96b95437-f8d5-9126-f28d-0e4c35d72bcb@sixdemonbag.org> <3c720787-703d-811b-a9bf-7ac4bb6342cc@gmx.ch> Message-ID: <8c3a3d2e-ba19-3ecf-10cd-52b0fdafc346@gmx.ch> > On 2020-06-29 14:42, Dmitry Alexandrov wrote: > Fourhundred Thecat <400thecat at gmx.ch> wrote: >> I am protesting the fact, that gpg can no longer be used without the agent. > > Yet you have not described the reason behind it so far, have you? Why are you sure, that the issue, that make gpg-agent fail to start in your case, is hard to resolve? I don't have gpg-agent installed, on this particular server, where I need to decrypt one file. From vedaal at nym.hush.com Mon Jun 29 19:07:51 2020 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Mon, 29 Jun 2020 13:07:51 -0400 Subject: decrypt aes256 encrypted file without gpg-agent In-Reply-To: <8c3a3d2e-ba19-3ecf-10cd-52b0fdafc346@gmx.ch> References: <1206f0a3-dea3-4e7c-6ac7-8837e0d2e565@gmx.ch> <87tuyvxp03.fsf@wheatstone.g10code.de> <96b95437-f8d5-9126-f28d-0e4c35d72bcb@sixdemonbag.org> <3c720787-703d-811b-a9bf-7ac4bb6342cc@gmx.ch> <8c3a3d2e-ba19-3ecf-10cd-52b0fdafc346@gmx.ch> Message-ID: <20200629170751.E8FD180113F@smtp.hushmail.com> On 6/29/2020 at 12:40 PM, "Fourhundred Thecat" <400thecat at gmx.ch> wrote: >I don't have gpg-agent installed, on this particular server, where >I >need to decrypt one file. ===== Try this very long workaround : [1] Install a fake homedirectory [2] Install a fake keyring (1 public and secret key that you never use) Then try this command: gpg --agent-program --no-use-agent --passphrase yourpassphrasestring --decrypt filename This is a way of making the --no-use-agent option active. GnuPG still needs a homedirectory and a keyring before trying to use the passphrase to decrypt (n.b. I have not actually tried the above, so am unsure if it is effective) otherwise , just use GnuPG 1.4.x , and unless you ever need an elliptic key, it should do everything you want. vedaal From wk at gnupg.org Mon Jun 29 19:40:59 2020 From: wk at gnupg.org (Werner Koch) Date: Mon, 29 Jun 2020 19:40:59 +0200 Subject: decrypt aes256 encrypted file without gpg-agent In-Reply-To: <20200629170751.E8FD180113F@smtp.hushmail.com> (vedaal via Gnupg-users's message of "Mon, 29 Jun 2020 13:07:51 -0400") References: <1206f0a3-dea3-4e7c-6ac7-8837e0d2e565@gmx.ch> <87tuyvxp03.fsf@wheatstone.g10code.de> <96b95437-f8d5-9126-f28d-0e4c35d72bcb@sixdemonbag.org> <3c720787-703d-811b-a9bf-7ac4bb6342cc@gmx.ch> <8c3a3d2e-ba19-3ecf-10cd-52b0fdafc346@gmx.ch> <20200629170751.E8FD180113F@smtp.hushmail.com> Message-ID: <87tuytwz10.fsf@wheatstone.g10code.de> On Mon, 29 Jun 2020 13:07, vedaal said: > otherwise , just use GnuPG 1.4.x , and unless you ever need an Do not use 1.4 unless you have to decrypt old non-MDC protected data or data encrypted to a legacy v3 key. 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 peter at digitalbrains.com Mon Jun 29 20:03:54 2020 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 29 Jun 2020 20:03:54 +0200 Subject: decrypt aes256 encrypted file without gpg-agent In-Reply-To: <8c3a3d2e-ba19-3ecf-10cd-52b0fdafc346@gmx.ch> References: <1206f0a3-dea3-4e7c-6ac7-8837e0d2e565@gmx.ch> <87tuyvxp03.fsf@wheatstone.g10code.de> <96b95437-f8d5-9126-f28d-0e4c35d72bcb@sixdemonbag.org> <3c720787-703d-811b-a9bf-7ac4bb6342cc@gmx.ch> <8c3a3d2e-ba19-3ecf-10cd-52b0fdafc346@gmx.ch> Message-ID: <3ec1022c-fdbb-dbde-52fb-fa2fb443fee8@digitalbrains.com> On 29/06/2020 18:38, Fourhundred Thecat wrote: > I don't have gpg-agent installed, on this particular server, where I > need to decrypt one file. You could try installing sequioa-pgp[1], an alternative but also libre OpenPGP implementation (still in its infancy). It requires a Rust build environment to compile. Or just bite the bullet and install gpg-agent. If you also need unattended decryption, there are ways to programmatically pass the passphrase to it. Although many people make security theater of their unattended decryption methods, it requires thought to design unattended decryption that isn't trivial to bypass once the attacker has read access to storage, or perhaps some other form of access that is definitely within scope of your threat model. HTH, Peter. [1] https://gitlab.com/sequoia-pgp/sequoia -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From ralph at ml.seichter.de Mon Jun 29 19:16:00 2020 From: ralph at ml.seichter.de (Ralph Seichter) Date: Mon, 29 Jun 2020 19:16:00 +0200 Subject: decrypt aes256 encrypted file without gpg-agent In-Reply-To: <3c720787-703d-811b-a9bf-7ac4bb6342cc@gmx.ch> References: <1206f0a3-dea3-4e7c-6ac7-8837e0d2e565@gmx.ch> <87tuyvxp03.fsf@wheatstone.g10code.de> <96b95437-f8d5-9126-f28d-0e4c35d72bcb@sixdemonbag.org> <3c720787-703d-811b-a9bf-7ac4bb6342cc@gmx.ch> Message-ID: <87k0zpvlm7.fsf@wedjat.horus-it.com> * Fourhundred Thecat: > I am protesting the fact, that gpg can no longer be used without the > agent. Whining about a design detail of free software? Get a grip. -Ralph From dag at gnui.org Mon Jun 29 21:32:35 2020 From: dag at gnui.org (Dmitry Alexandrov) Date: Mon, 29 Jun 2020 22:32:35 +0300 Subject: decrypt aes256 encrypted file without gpg-agent In-Reply-To: <8c3a3d2e-ba19-3ecf-10cd-52b0fdafc346@gmx.ch> (Fourhundred Thecat's message of "Mon, 29 Jun 2020 18:38:03 +0200") References: <1206f0a3-dea3-4e7c-6ac7-8837e0d2e565@gmx.ch> <87tuyvxp03.fsf@wheatstone.g10code.de> <96b95437-f8d5-9126-f28d-0e4c35d72bcb@sixdemonbag.org> <3c720787-703d-811b-a9bf-7ac4bb6342cc@gmx.ch> <8c3a3d2e-ba19-3ecf-10cd-52b0fdafc346@gmx.ch> Message-ID: <8sg5k6r0.dag@gnui.org> Fourhundred Thecat <400thecat at gmx.ch> wrote: >> On 2020-06-29 14:42, Dmitry Alexandrov wrote: >> Fourhundred Thecat <400thecat at gmx.ch> wrote: >>> I am protesting the fact, that gpg can no longer be used without the agent. >> >> Yet you have not described the reason behind it so far, have you? Why are you sure, that the issue, that make gpg-agent fail to start in your case, is hard to resolve? > > I don't have gpg-agent installed, on this particular server, where I need to decrypt one file. Ah, so it?s in fact very easy to resolve ? just install gpg-agent. :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From dag at gnui.org Mon Jun 29 14:42:58 2020 From: dag at gnui.org (Dmitry Alexandrov) Date: Mon, 29 Jun 2020 15:42:58 +0300 Subject: decrypt aes256 encrypted file without gpg-agent In-Reply-To: <3c720787-703d-811b-a9bf-7ac4bb6342cc@gmx.ch> (Fourhundred Thecat's message of "Mon, 29 Jun 2020 07:56:46 +0200") References: <1206f0a3-dea3-4e7c-6ac7-8837e0d2e565@gmx.ch> <87tuyvxp03.fsf@wheatstone.g10code.de> <96b95437-f8d5-9126-f28d-0e4c35d72bcb@sixdemonbag.org> <3c720787-703d-811b-a9bf-7ac4bb6342cc@gmx.ch> Message-ID: Fourhundred Thecat <400thecat at gmx.ch> wrote: > I am protesting the fact, that gpg can no longer be used without the agent. Yet you have not described the reason behind it so far, have you? Why are you sure, that the issue, that make gpg-agent fail to start in your case, is hard to resolve? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From johanw at vulcan.xs4all.nl Tue Jun 30 00:55:08 2020 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Tue, 30 Jun 2020 00:55:08 +0200 Subject: decrypt aes256 encrypted file without gpg-agent In-Reply-To: <87tuytwz10.fsf@wheatstone.g10code.de> References: <1206f0a3-dea3-4e7c-6ac7-8837e0d2e565@gmx.ch> <87tuyvxp03.fsf@wheatstone.g10code.de> <96b95437-f8d5-9126-f28d-0e4c35d72bcb@sixdemonbag.org> <3c720787-703d-811b-a9bf-7ac4bb6342cc@gmx.ch> <8c3a3d2e-ba19-3ecf-10cd-52b0fdafc346@gmx.ch> <20200629170751.E8FD180113F@smtp.hushmail.com> <87tuytwz10.fsf@wheatstone.g10code.de> Message-ID: On 29-06-2020 19:40, Werner Koch via Gnupg-users wrote: > Do not use 1.4 unless you have to decrypt old non-MDC protected data or > data encrypted to a legacy v3 key. Do not break backwards compatibility if you want all people to upgrade. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From gnupg at raf.org Tue Jun 30 03:17:01 2020 From: gnupg at raf.org (raf) Date: Tue, 30 Jun 2020 11:17:01 +1000 Subject: decrypt aes256 encrypted file without gpg-agent In-Reply-To: <87tuytwz10.fsf@wheatstone.g10code.de> References: <1206f0a3-dea3-4e7c-6ac7-8837e0d2e565@gmx.ch> <87tuyvxp03.fsf@wheatstone.g10code.de> <96b95437-f8d5-9126-f28d-0e4c35d72bcb@sixdemonbag.org> <3c720787-703d-811b-a9bf-7ac4bb6342cc@gmx.ch> <8c3a3d2e-ba19-3ecf-10cd-52b0fdafc346@gmx.ch> <20200629170751.E8FD180113F@smtp.hushmail.com> <87tuytwz10.fsf@wheatstone.g10code.de> Message-ID: <20200630011701.puuouhqocpcc5q5c@raf.org> Werner Koch via Gnupg-users wrote: > On Mon, 29 Jun 2020 13:07, vedaal said: > > > otherwise , just use GnuPG 1.4.x , and unless you ever need an > > Do not use 1.4 unless you have to decrypt old non-MDC protected data or > data encrypted to a legacy v3 key. > > Shalom-Salam, > > Werner Sadly, there are other reasons that make it seem (to me) as though I still need 1.4. :-( I assume the answer must be no, but is there any chance that --pinentry-mode loopback could be made to prompt again when the wrong passphrase is entered? If it did that, I'd be happy to stop using 1.4 on my mac laptop. Alternatively, is there a pinentry program that works inside vim and all/most variants of gvim (at least X11/motif and MacVim)? Preferably available via macports, but not necessarily. I can't seem to find one. I've tried pinentry-curses and pinentry-tty on debian-10 with gpg-2.2.12 but neither prompt for the passphrase when invoked inside vim or gvim, and the file is not decrypted. Hopefully, I'm just ignorant and there is a solution to my ergonomic issues (other than using loopback and typing long passphrases very slowly and carefully). cheers, raf From 400thecat at gmx.ch Tue Jun 30 06:58:14 2020 From: 400thecat at gmx.ch (Fourhundred Thecat) Date: Tue, 30 Jun 2020 06:58:14 +0200 Subject: decrypt aes256 encrypted file without gpg-agent In-Reply-To: <87k0zpvlm7.fsf@wedjat.horus-it.com> References: <1206f0a3-dea3-4e7c-6ac7-8837e0d2e565@gmx.ch> <87tuyvxp03.fsf@wheatstone.g10code.de> <96b95437-f8d5-9126-f28d-0e4c35d72bcb@sixdemonbag.org> <3c720787-703d-811b-a9bf-7ac4bb6342cc@gmx.ch> <87k0zpvlm7.fsf@wedjat.horus-it.com> Message-ID: <7eb9d4b0-0069-24b5-004c-813f334ecd2d@gmx.ch> > On 2020-06-29 19:16, Ralph Seichter via Gnupg-users wrote: > >> I am protesting the fact, that gpg can no longer be used without the >> agent. > > Whining about a design detail of free software? Get a grip. There are more examples of bad design. In fact, gpg epitomizes a perfect anti-UNIX design. (See Eric S. Raymond for details, what UNIX philosophy means) For instance, even for basic operations (encrypt, decrypt), where no modifications to my key pair are necessary, gpg still requires my ~/.gnupg/ to be writable (cannot me on read-only filesystem) That is another example of hard-requiring something, that it does not need (same as agent for symmetric decryption) gpg is considered a core component of linux and other systems. This is not some solitaire gui app, that I can choose to ignore. That is why I a m giving here my honest feedback. I believe this project is going in the wrong direction, and bad design decisions are being made. From rjh at sixdemonbag.org Tue Jun 30 08:37:22 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 30 Jun 2020 02:37:22 -0400 Subject: decrypt aes256 encrypted file without gpg-agent In-Reply-To: <7eb9d4b0-0069-24b5-004c-813f334ecd2d@gmx.ch> References: <1206f0a3-dea3-4e7c-6ac7-8837e0d2e565@gmx.ch> <87tuyvxp03.fsf@wheatstone.g10code.de> <96b95437-f8d5-9126-f28d-0e4c35d72bcb@sixdemonbag.org> <3c720787-703d-811b-a9bf-7ac4bb6342cc@gmx.ch> <87k0zpvlm7.fsf@wedjat.horus-it.com> <7eb9d4b0-0069-24b5-004c-813f334ecd2d@gmx.ch> Message-ID: <2e4f6e17-cb5f-6200-d47b-ac197ed547e0@sixdemonbag.org> > In fact, gpg epitomizes a perfect anti-UNIX design. (See Eric S. Raymond > for details, what UNIX philosophy means) Mmmhmm. > For instance, even for basic operations (encrypt, decrypt), where no > modifications to my key pair are necessary, gpg still requires my > ~/.gnupg/ to be writable (cannot me on read-only filesystem) Again, you're criticizing a design before learning why that design is the way it is. > That is another example of hard-requiring something, that it does not > need (same as agent for symmetric decryption) You don't understand the design, which means you don't know what the system needs and/or doesn't need. You're not displaying judgment here, you're displaying prejudice. > That is why I a m giving here my honest feedback. You are of course welcome to give what feedback you like. I respectfully suggest that if you start by learning why these various tradeoffs were made, it will allow you to make better criticisms that will be taken more seriously by the development team. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 821 bytes Desc: OpenPGP digital signature URL: From ralph at ml.seichter.de Tue Jun 30 08:55:34 2020 From: ralph at ml.seichter.de (Ralph Seichter) Date: Tue, 30 Jun 2020 08:55:34 +0200 Subject: decrypt aes256 encrypted file without gpg-agent In-Reply-To: <7eb9d4b0-0069-24b5-004c-813f334ecd2d@gmx.ch> References: <1206f0a3-dea3-4e7c-6ac7-8837e0d2e565@gmx.ch> <87tuyvxp03.fsf@wheatstone.g10code.de> <96b95437-f8d5-9126-f28d-0e4c35d72bcb@sixdemonbag.org> <3c720787-703d-811b-a9bf-7ac4bb6342cc@gmx.ch> <87k0zpvlm7.fsf@wedjat.horus-it.com> <7eb9d4b0-0069-24b5-004c-813f334ecd2d@gmx.ch> Message-ID: <87lfk5m49l.fsf@wedjat.horus-it.com> * Fourhundred Thecat: >> Whining about a design detail of free software? Get a grip. > > There are more examples of bad design. Are there now? GnuPG is software that has evolved since its introduction in 1997. Can you show me any meaningful software of yours that has been evolving over 23 years and has what you consider "good design"? It should be interesting. > In fact, gpg epitomizes a perfect anti-UNIX design. (See Eric > S. Raymond for details, what UNIX philosophy means) Ha, now you're trying to teach your grandma to suck eggs. ;-) Besides, quoting ESR is a somewhat risky business. He said and wrote a lot over the decades, much of which I consider nonsense. > I believe this project is going in the wrong direction, and bad design > decisions are being made. What insight do you have in the design and development of GnuPG; in its goals and restrictions? There is a difference between you not liking something for a personal reason, and objectively "bad design". You are entitled to your opinion of course, but unless you can demonstrate the skills to come up with a better design for free software that offers the same functionality as GnuPG, that opinion does not mean so much. -Ralph From 400thecat at gmx.ch Tue Jun 30 11:56:15 2020 From: 400thecat at gmx.ch (Fourhundred Thecat) Date: Tue, 30 Jun 2020 11:56:15 +0200 Subject: decrypt aes256 encrypted file without gpg-agent In-Reply-To: <87lfk5m49l.fsf@wedjat.horus-it.com> References: <1206f0a3-dea3-4e7c-6ac7-8837e0d2e565@gmx.ch> <87tuyvxp03.fsf@wheatstone.g10code.de> <96b95437-f8d5-9126-f28d-0e4c35d72bcb@sixdemonbag.org> <3c720787-703d-811b-a9bf-7ac4bb6342cc@gmx.ch> <87k0zpvlm7.fsf@wedjat.horus-it.com> <7eb9d4b0-0069-24b5-004c-813f334ecd2d@gmx.ch> <87lfk5m49l.fsf@wedjat.horus-it.com> Message-ID: > On 2020-06-30 08:55, Ralph Seichter via Gnupg-users wrote: > * Fourhundred Thecat: >> > What insight do you have in the design and development of GnuPG; in its > goals and restrictions? There is a difference between you not liking > something for a personal reason, and objectively "bad design". You are > entitled to your opinion of course, but unless you can demonstrate the > skills to come up with a better design for free software that offers the > same functionality as GnuPG, that opinion does not mean so much. I am basing my judgment on universal principles, that apply not only to gpg or other software, but design of any systems in general. One such principle is a having distinct modes of operation for: 1) maintenance (read/write operations) 2) general use (read-only operations) In case of gpg, there is one mode where you generate your key pair, change configuration files, or any other read-write operation. But for general usage, there is no reason for the key pair to need to be writable. Take a car, as an analogy: Imagine what a mess it would be, if you tried to design a car where the engine can be replaced while you are driving. I have no experience designing cars, but that does not prevent me from seeing this would be bad design specification. Maintenance and usage are two different modes, and should not be mixed. From wk at gnupg.org Tue Jun 30 12:10:40 2020 From: wk at gnupg.org (Werner Koch) Date: Tue, 30 Jun 2020 12:10:40 +0200 Subject: decrypt aes256 encrypted file without gpg-agent In-Reply-To: (Johan Wevers's message of "Tue, 30 Jun 2020 00:55:08 +0200") References: <1206f0a3-dea3-4e7c-6ac7-8837e0d2e565@gmx.ch> <87tuyvxp03.fsf@wheatstone.g10code.de> <96b95437-f8d5-9126-f28d-0e4c35d72bcb@sixdemonbag.org> <3c720787-703d-811b-a9bf-7ac4bb6342cc@gmx.ch> <8c3a3d2e-ba19-3ecf-10cd-52b0fdafc346@gmx.ch> <20200629170751.E8FD180113F@smtp.hushmail.com> <87tuytwz10.fsf@wheatstone.g10code.de> Message-ID: <878sg4x3rz.fsf@wheatstone.g10code.de> On Tue, 30 Jun 2020 00:55, Johan Wevers said: >> Do not use 1.4 unless you have to decrypt old non-MDC protected data or >> data encrypted to a legacy v3 key. > > Do not break backwards compatibility if you want all people to upgrade. Do not update so that the bad guys can exploit your legacy software ;-) There are well documented reasons what we don't support MDC and PGP3 keys anymore - it was complex to support and virtually impossible to make sure that the message has not been tampered with. See the discussion around EFFail of MUAs using gpg in a brittle and insecure way. 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 ralph at ml.seichter.de Tue Jun 30 12:26:04 2020 From: ralph at ml.seichter.de (Ralph Seichter) Date: Tue, 30 Jun 2020 12:26:04 +0200 Subject: decrypt aes256 encrypted file without gpg-agent In-Reply-To: References: <1206f0a3-dea3-4e7c-6ac7-8837e0d2e565@gmx.ch> <87tuyvxp03.fsf@wheatstone.g10code.de> <96b95437-f8d5-9126-f28d-0e4c35d72bcb@sixdemonbag.org> <3c720787-703d-811b-a9bf-7ac4bb6342cc@gmx.ch> <87k0zpvlm7.fsf@wedjat.horus-it.com> <7eb9d4b0-0069-24b5-004c-813f334ecd2d@gmx.ch> <87lfk5m49l.fsf@wedjat.horus-it.com> Message-ID: <87v9j87sub.fsf@wedjat.horus-it.com> * Fourhundred Thecat: > I am basing my judgment on universal principles, that apply not only > to gpg or other software, but design of any systems in general. Universal principles, oh my. In other words, you don't know nearly enough about the finer points of GnuPG design goals, don't know much about the challenges of evolutionary software design, and thus don't know too well what you are talking about, universally speaking. Show us a body of your work which proves you have the necessary skills to critique the GnuPG authors' work. Until you do, your "judgment" is moot. > Take a car, as an analogy: [...] Unrelated nonsense. Was that really the best you could come up with? -Ralph From 400thecat at gmx.ch Tue Jun 30 12:47:46 2020 From: 400thecat at gmx.ch (Fourhundred Thecat) Date: Tue, 30 Jun 2020 12:47:46 +0200 Subject: decrypt aes256 encrypted file without gpg-agent In-Reply-To: <87v9j87sub.fsf@wedjat.horus-it.com> References: <1206f0a3-dea3-4e7c-6ac7-8837e0d2e565@gmx.ch> <87tuyvxp03.fsf@wheatstone.g10code.de> <96b95437-f8d5-9126-f28d-0e4c35d72bcb@sixdemonbag.org> <3c720787-703d-811b-a9bf-7ac4bb6342cc@gmx.ch> <87k0zpvlm7.fsf@wedjat.horus-it.com> <7eb9d4b0-0069-24b5-004c-813f334ecd2d@gmx.ch> <87lfk5m49l.fsf@wedjat.horus-it.com> <87v9j87sub.fsf@wedjat.horus-it.com> Message-ID: <1979c721-cafd-78ae-6e6e-4dc7d6bb9b11@gmx.ch> > On 2020-06-30 12:26, Ralph Seichter via Gnupg-users wrote: > * Fourhundred Thecat: > >> I am basing my judgment on universal principles, that apply not only >> to gpg or other software, but design of any systems in general. > > Universal principles, oh my. In other words, you don't know nearly > enough about the finer points of GnuPG design goals, don't know much > about the challenges of evolutionary software design, and thus don't > know too well what you are talking about, universally speaking. > > Show us a body of your work which proves you have the necessary skills > to critique the GnuPG authors' work. Until you do, your "judgment" is > moot. An idea should be considered on its own merit. You should counter my criticism with facts, instead of attacking me personally. I stand behind my statement, that it is a sign of bad design, when gpg does not work on a read-only filesystem. You can either reply with counterargument, or ignore my messages in this thread. Cheers, From ralph at ml.seichter.de Tue Jun 30 13:27:34 2020 From: ralph at ml.seichter.de (Ralph Seichter) Date: Tue, 30 Jun 2020 13:27:34 +0200 Subject: decrypt aes256 encrypted file without gpg-agent In-Reply-To: <1979c721-cafd-78ae-6e6e-4dc7d6bb9b11@gmx.ch> References: <1206f0a3-dea3-4e7c-6ac7-8837e0d2e565@gmx.ch> <87tuyvxp03.fsf@wheatstone.g10code.de> <96b95437-f8d5-9126-f28d-0e4c35d72bcb@sixdemonbag.org> <3c720787-703d-811b-a9bf-7ac4bb6342cc@gmx.ch> <87k0zpvlm7.fsf@wedjat.horus-it.com> <7eb9d4b0-0069-24b5-004c-813f334ecd2d@gmx.ch> <87lfk5m49l.fsf@wedjat.horus-it.com> <87v9j87sub.fsf@wedjat.horus-it.com> <1979c721-cafd-78ae-6e6e-4dc7d6bb9b11@gmx.ch> Message-ID: <87y2o44wux.fsf@wedjat.horus-it.com> * Fourhundred Thecat: >> Show us a body of your work which proves you have the necessary >> skills to critique the GnuPG authors' work. Until you do, your >> "judgment" is moot. > > An idea should be considered on its own merit. What "idea" would that be, exactly? > You should counter my criticism with facts, instead of attacking me > personally. I am not attacking you. Read what I wrote in this thread. I just doubt that you have enough knowledge about the motivation behind and the inner workings of GnuPG to offer your "critique" (which I consider personal dislike for certain behaviour) until you convince me otherwise. Based on what you wrote so far, you are just some random person behind a pseudonym. What are your credentials in this field? What qualification do you have that would enable you to call the work of other people "bad design" with actual justification? Have you designed and maintained software on the scale of GnuPG, for decades, with a worldwide user base, dealing with security, usability and compatibility issues, having to find some compromise between the various aspects? > You can either reply with counterargument, or ignore my messages in > this thread. You can either tell people why your opinion should matter, or live with being called out for not doing so. -Ralph From johanw at vulcan.xs4all.nl Tue Jun 30 14:43:28 2020 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Tue, 30 Jun 2020 14:43:28 +0200 Subject: decrypt aes256 encrypted file without gpg-agent In-Reply-To: <878sg4x3rz.fsf@wheatstone.g10code.de> References: <1206f0a3-dea3-4e7c-6ac7-8837e0d2e565@gmx.ch> <87tuyvxp03.fsf@wheatstone.g10code.de> <96b95437-f8d5-9126-f28d-0e4c35d72bcb@sixdemonbag.org> <3c720787-703d-811b-a9bf-7ac4bb6342cc@gmx.ch> <8c3a3d2e-ba19-3ecf-10cd-52b0fdafc346@gmx.ch> <20200629170751.E8FD180113F@smtp.hushmail.com> <87tuytwz10.fsf@wheatstone.g10code.de> <878sg4x3rz.fsf@wheatstone.g10code.de> Message-ID: On 30-06-2020 12:10, Werner Koch via Gnupg-users wrote: >> Do not break backwards compatibility if you want all people to upgrade. > > Do not update so that the bad guys can exploit your legacy software ;-) > > There are well documented reasons what we don't support MDC and PGP3 > keys anymore - it was complex to support and virtually impossible to > make sure that the message has not been tampered with. Not supporting encryption anymore I can understand, but by removing decryption ability which makes old mail archives unusable you can't realistically expect people to abandon 1.4 completely. Complex, nah, you can always put the v3 key code in a separate set of functions that are called when a v3 header is detected. Maybe not the cleanest design but for code that is probably not going to see any changes it would work. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From dag at gnui.org Tue Jun 30 15:41:36 2020 From: dag at gnui.org (Dmitry Alexandrov) Date: Tue, 30 Jun 2020 16:41:36 +0300 Subject: decrypt aes256 encrypted file without gpg-agent In-Reply-To: (Fourhundred Thecat's message of "Tue, 30 Jun 2020 11:56:15 +0200") References: <1206f0a3-dea3-4e7c-6ac7-8837e0d2e565@gmx.ch> <87tuyvxp03.fsf@wheatstone.g10code.de> <96b95437-f8d5-9126-f28d-0e4c35d72bcb@sixdemonbag.org> <3c720787-703d-811b-a9bf-7ac4bb6342cc@gmx.ch> <87k0zpvlm7.fsf@wedjat.horus-it.com> <7eb9d4b0-0069-24b5-004c-813f334ecd2d@gmx.ch> <87lfk5m49l.fsf@wedjat.horus-it.com> Message-ID: Fourhundred Thecat <400thecat at gmx.ch> wrote: > In case of gpg, there is one mode where you generate your key pair, change configuration files, or any other read-write operation. > > But for general usage, there is no reason for the key pair to need to be writable. Sure. So there is none: $ chmod a-w $GNUPGHOME/pubring.kbx $GNUPGHOME/private-keys-v1.d/* $ echo foo | gpg -qe --default-recipient-self | gpg -qd foo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From dag at gnui.org Tue Jun 30 16:22:48 2020 From: dag at gnui.org (Dmitry Alexandrov) Date: Tue, 30 Jun 2020 17:22:48 +0300 Subject: decrypt aes256 encrypted file without gpg-agent In-Reply-To: <7eb9d4b0-0069-24b5-004c-813f334ecd2d@gmx.ch> (Fourhundred Thecat's message of "Tue, 30 Jun 2020 06:58:14 +0200") References: <1206f0a3-dea3-4e7c-6ac7-8837e0d2e565@gmx.ch> <87tuyvxp03.fsf@wheatstone.g10code.de> <96b95437-f8d5-9126-f28d-0e4c35d72bcb@sixdemonbag.org> <3c720787-703d-811b-a9bf-7ac4bb6342cc@gmx.ch> <87k0zpvlm7.fsf@wedjat.horus-it.com> <7eb9d4b0-0069-24b5-004c-813f334ecd2d@gmx.ch> Message-ID: Fourhundred Thecat <400thecat at gmx.ch> wrote: > In fact, gpg epitomizes a perfect anti-UNIX design. (See Eric S. Raymond for details, what UNIX philosophy means) > I believe this project is going in the wrong direction, and bad design decisions are being made. Was not it you who have just complained about introduction of gpg-agent, that is about switching from a solid rock tool to a set of independent programs that are communicating via textual streams ? in other words, about GPGv2 be much more UNIX-wayish that GPGv1? > There are more examples of bad design. > For instance, even for basic operations (encrypt, decrypt) ??? gpg still requires my ~/.gnupg/ to be writable (cannot me on read-only filesystem) Heh. Use of files as a temporal storage medium or just unique entities for anything from sockets to boolean flags, and therefore a need for writable FS to store them, is a hallmark of UNIX-way design. You might believe that UNIX-way design is a bad design, of course, and that GPG should have joined the trend of moving _away_ from it before it had became a mainstream (cf. systemd, Wayland, etc); but saying ?UNIX? to mean ?cool? looks funny as hell. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From rjh at sixdemonbag.org Tue Jun 30 16:50:59 2020 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 30 Jun 2020 10:50:59 -0400 Subject: decrypt aes256 encrypted file without gpg-agent In-Reply-To: References: <1206f0a3-dea3-4e7c-6ac7-8837e0d2e565@gmx.ch> <87tuyvxp03.fsf@wheatstone.g10code.de> <96b95437-f8d5-9126-f28d-0e4c35d72bcb@sixdemonbag.org> <3c720787-703d-811b-a9bf-7ac4bb6342cc@gmx.ch> <87k0zpvlm7.fsf@wedjat.horus-it.com> <7eb9d4b0-0069-24b5-004c-813f334ecd2d@gmx.ch> <87lfk5m49l.fsf@wedjat.horus-it.com> Message-ID: <1dd393f0-c83b-fcef-de16-068e153cea3b@sixdemonbag.org> > I am basing my judgment on universal principles, that apply not only to > gpg or other software, but design of any systems in general. There is no such universal playbook. It simply does not exist. In his book _Lila_ the philosopher Robert M. Pirsig wrote that morality is not a set of universal principles, so much as it is what emerges from the interplay of conflicting principles that are at odds with each other. You can say the same about software engineering. There are no universal principles, only rules of thumb that are often at odds with each other. Learn about GnuPG's design and why it is the way it is, _then_ judge it. To loftily decree there exist universal principles and thus you don't need to learn the specifics before judging is little different from the judge who decrees that murder is illegal and so doesn't need to learn whether the accused was acting in self-defense. > Imagine what a mess it would be, if you tried to design a car where the > engine can be replaced while you are driving. I have no experience > designing cars, but that does not prevent me from seeing this would be > bad design specification. I'm an amateur auto racer, and this sounds like an *awesome* idea. In virtually all races pit crews are required to not touch the car until it's stopped moving, entirely for safety reasons: when there's a thousand-kilo piece of metal in motion, it's wise to require people to stay clear of it. If you could figure out a way to make it safe to make changes to a car in motion, you'd have every NASCAR and SCCA team beating a path to your door. Your "universal principles", well -- aren't. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 821 bytes Desc: OpenPGP digital signature URL: