From kloecker at kde.org Fri Mar 1 11:23:06 2019 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Fri, 01 Mar 2019 11:23:06 +0100 Subject: Howto override "encrypt-to KEYHERE" in gpg.conf? In-Reply-To: <201902281340.x1SDeuFR024834@epjdn.zq3q.org> References: <201902281340.x1SDeuFR024834@epjdn.zq3q.org> Message-ID: <2765212.1syOWuWozZ@collossus.ingo-kloecker.de> On Donnerstag, 28. Februar 2019 14:40:56 CET gpg at trodman.com wrote: > I have imported a new / additional primary key (0x2A5D250B1C9BE7D1) to my > keyring. > > But my default-key in gpg.conf is not changed: > $ egrep '^(default-key|encrypt-to) ' ~/.gnupg/gpg.conf > default-key 040B8410C3F36C1E > encrypt-to 040B8410C3F36C1E > > My goal is to run gpg commands that entirely ignore my default-key and > encrypt-to key in ~/.gnupg/gpg.conf. $ man gpg [...] --default-key name Use name as the default key to sign with. If this option is not used, the default key is the first key found in the secret keyring. Note that -u or --local-user overrides this option. [...] $ man gpg [...] --no-encrypt-to Disable the use of all --encrypt-to and --hidden-encrypt-to keys. Regards, Ingo -------------- 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 dkg at fifthhorseman.net Fri Mar 1 07:45:33 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 01 Mar 2019 01:45:33 -0500 Subject: gpg vs gpgv and trustedkeys In-Reply-To: References: <1a28ff3c-5934-106b-31ad-8aeb9c57a725@schinagl.nl> <87ftsbnj34.fsf@fifthhorseman.net> Message-ID: <87lg1zum7m.fsf@fifthhorseman.net> On Wed 2019-02-27 21:10:36 +0100, Olliver Schinagl wrote: > During development, engineers also login to the system and may > need to use the gpgv tool to check things. Having to point to the exact > file is just common cause of imstakes 'where was that file again' or 'oh > forgot'. But sure it is manageable, but. You could write a small script or binary for your system that knows about the specific location for the curated keyring and wraps the invocation of gpgv. Then encourage those engineers to use your wrapper rather than gpgv directly. This has the added advantage that you can enforce additional policy (e.g. "--weak-digest sha1", or timestamp-specific enforcement based on --status-fd, etc) in the wrapper itself, and roll out that policy without retraining people. > Sure, but sometimes you don't care about the precise control; just that > it works as expected, which was my question was about. fwiw, if you're checking cryptographic signatures, i *strongly* recommend caring about precise control. "works as expected" is a pretty sloppy test -- often people will think it just means "approves legitimately-signed files". But for strong cryptographic verification, you really also need to know that it "disapproves all else", right? > Simple example; I have my keys in my keychain generated/created via gpg. > Now I want to use gpgv to validate something, with my key, but now i > explicitly have to point it to the pubkey, because the default of gpgv > is trustedkey. So why the differences? Why are these not in sync, what > is the purpose? If the reason is to force the user to use the parameter, > why set a default, why set a default that does not match the generator. The "trust" that gpg knows about in its keyring is "willingness to rely on OpenPGP certifications made by the keyholder". This is entirely orthogonal to "willingness to accept a data signature in some specific context". frankly, i agree with you that the existence of gpgv's default "acceptable certificates for making data signatures" -- ~/.gnupg/trustedkeys.{kbx,gpg} is a dubious feature. If i'm checking a signature on software package X, i care *very much* that it's not just signed by any key i know about, but by (one of) the key(s) that is associated with the authors of software package X. Likewise, i'm also checking on a new upstream release of software package Y, i *don't* want the authors of X to have any say in the matter. --dkg From dkg at fifthhorseman.net Fri Mar 1 23:01:46 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 01 Mar 2019 17:01:46 -0500 Subject: Using gpg in an automated environememt In-Reply-To: <143801d4ceb8$2b0c2eb0$81248c10$@manymore.fr> References: <143801d4ceb8$2b0c2eb0$81248c10$@manymore.fr> Message-ID: <87o96utfsl.fsf@fifthhorseman.net> Hi Geoffrey-- On Wed 2019-02-27 17:19:08 +0100, gpirlot at manymore.fr wrote: > I've been unsuccessfully trying for a while now to have gpg working in an > automated environment. I've been following the point 8.20 int the gnupg faq > and I get an error at the gpg -homedir command (see screenshot below) In the future, if it's possible, please send the text of such a screenshot as text. it makes it easier to index, to search, and to reply to. I think you're talking about this part of the FAQ: https://www.gnupg.org/faq/gnupg-faq.html#automated_use It looks to me like you might not have followed step 4: Copy secring.auto and the public keyring to a test directory. but i confess i also don't really understand this entry in the FAQ. it looks overly complicated to me, and seems to expect there to be a "secret keyring", which is decidedly not the case for any modern version of GnuPG. (modern GnuPG stores its long-term secrets in ~/.gnupg/private-keys-v1.d/ ) Perhaps if you could explain more about what you're trying to do, someone here could point you to documentation that suits your goals better? all the best, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From oliver at schinagl.nl Sat Mar 2 11:31:44 2019 From: oliver at schinagl.nl (Olliver Schinagl) Date: Sat, 2 Mar 2019 11:31:44 +0100 Subject: gpg vs gpgv and trustedkeys In-Reply-To: <87lg1zum7m.fsf@fifthhorseman.net> References: <1a28ff3c-5934-106b-31ad-8aeb9c57a725@schinagl.nl> <87ftsbnj34.fsf@fifthhorseman.net> <87lg1zum7m.fsf@fifthhorseman.net> Message-ID: <28dee1bf-20bc-b845-0845-c0e1ee629d2a@schinagl.nl> On 01-03-2019 07:45, Daniel Kahn Gillmor wrote: > On Wed 2019-02-27 21:10:36 +0100, Olliver Schinagl wrote: >> During development, engineers also login to the system and may >> need to use the gpgv tool to check things. Having to point to the exact >> file is just common cause of imstakes 'where was that file again' or 'oh >> forgot'. But sure it is manageable, but. > You could write a small script or binary for your system that knows > about the specific location for the curated keyring and wraps the > invocation of gpgv. Then encourage those engineers to use your wrapper > rather than gpgv directly. This has the added advantage that you can > enforce additional policy (e.g. "--weak-digest sha1", or > timestamp-specific enforcement based on --status-fd, etc) in the wrapper > itself, and roll out that policy without retraining people. Well the actualy firmware image validation will be done via a script there, so no worries on that regard. But if an engineer is tasked with modifying any of these scripts, they may struggle to know what's going on when invoking the tools themselves. > >> Sure, but sometimes you don't care about the precise control; just that >> it works as expected, which was my question was about. > fwiw, if you're checking cryptographic signatures, i *strongly* > recommend caring about precise control. "works as expected" is a pretty > sloppy test -- often people will think it just means "approves > legitimately-signed files". But for strong cryptographic verification, > you really also need to know that it "disapproves all else", right? Oh I do agree here :) > >> Simple example; I have my keys in my keychain generated/created via gpg. >> Now I want to use gpgv to validate something, with my key, but now i >> explicitly have to point it to the pubkey, because the default of gpgv >> is trustedkey. So why the differences? Why are these not in sync, what >> is the purpose? If the reason is to force the user to use the parameter, >> why set a default, why set a default that does not match the generator. > The "trust" that gpg knows about in its keyring is "willingness to rely > on OpenPGP certifications made by the keyholder". > > This is entirely orthogonal to "willingness to accept a data signature > in some specific context". > > frankly, i agree with you that the existence of gpgv's default > "acceptable certificates for making data signatures" -- > ~/.gnupg/trustedkeys.{kbx,gpg} is a dubious feature. If i'm checking a > signature on software package X, i care *very much* that it's not just > signed by any key i know about, but by (one of) the key(s) that is > associated with the authors of software package X. Likewise, i'm also > checking on a new upstream release of software package Y, i *don't* want > the authors of X to have any say in the matter. I whole-heartedly agree now that I understand this more. As such however, gpgv should really remove this feature all together. E.g. always point to a keyring. The trustedkeys file is just confusing (and the internet is only filled with confusion surounding this filename). Many suggest to even just symlink the trustedkeys file to the pubkey files. As there is no 'natural' way (or a suggestion in the documenation) to create the trustedkeys file; It really probably is best to just remove it al together. Having said that, I'll didn't check/try; but what IS the best way to get a key into a system. I can do gpg --import and move + package the file of course; but is there a cleaner solution to get the file, into say /etc/keys for example? (Without using the --keyring paramater of gpg, as that paramater has come and gone in certain versions, so not sure how reliable that one is). Or is it really the only and recommended way. > > --dkg From tlikonen at iki.fi Sun Mar 3 09:46:33 2019 From: tlikonen at iki.fi (Teemu Likonen) Date: Sun, 03 Mar 2019 10:46:33 +0200 Subject: Two utilities: gpg-tofu and gpg-graph In-Reply-To: <87ftsnorv9.fsf@iki.fi> (Teemu Likonen's message of "Sun, 17 Feb 2019 08:23:38 +0200") References: <87ftsnorv9.fsf@iki.fi> Message-ID: <87fts49wgm.fsf@iki.fi> Teemu Likonen [2019-02-17 08:23:38+02] wrote: > I have made two utilities to help my usage of gpg. [...] > gpg-tofu > gpg-graph I moved these utilities to a new combined repository: https://github.com/tlikonen/gpg-utilities There is also a new tool gpg-cert-path which find the shortest certification distance between two keys. -- /// Teemu Likonen - .-.. // // PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 /// -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From dkg at fifthhorseman.net Sun Mar 3 17:53:49 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 03 Mar 2019 11:53:49 -0500 Subject: gpg vs gpgv and trustedkeys In-Reply-To: <28dee1bf-20bc-b845-0845-c0e1ee629d2a@schinagl.nl> References: <1a28ff3c-5934-106b-31ad-8aeb9c57a725@schinagl.nl> <87ftsbnj34.fsf@fifthhorseman.net> <87lg1zum7m.fsf@fifthhorseman.net> <28dee1bf-20bc-b845-0845-c0e1ee629d2a@schinagl.nl> Message-ID: <875zszucf6.fsf@fifthhorseman.net> On Sat 2019-03-02 11:31:44 +0100, Olliver Schinagl wrote: > Well the actualy firmware image validation will be done via a script > there, so no worries on that regard. But if an engineer is tasked with > modifying any of these scripts, they may struggle to know what's going > on when invoking the tools themselves. right. If you have the capacity to make a thoughtful design of the internal image validation script (both its API and its internal codebase), then the validation script itself can serve as useful tooling and explanatory guideposts for your engineers. > gpgv should really remove this feature all together. E.g. always > point to a keyring. This is an interesting suggestion, and i wonder whether GnuPG upstream would be willing to consider it for some API-breaking new revision of gpgv (or some alternate signature-verifying tool). I've proposed a new process-level OpenPGP signature-verifying API over here: https://bugs.debian.org/872271 and you're right, it doesn't assume a default keyring, but rather requires an explicit designation of which keys are acceptable. I agree with you that the documentation should be improved, and i think that upstream would welcome patches to that effect. I've just submitted one improvement (to documentation about gpgv's keyring selection) here: https://dev.gnupg.org/T4386 One path toward actually deprecating the default keyring would be to warn if the default keyring is used, probably in main() in g10/gpgv.c. > The trustedkeys file is just confusing (and the internet is only > filled with confusion surounding this filename). Many suggest to even > just symlink the trustedkeys file to the pubkey files. yikes. I can imagine some unusual circumstances where that would be reasonable, but it sounds particularly dangerous in contexts where you care about who the signature comes from. > Having said that, I'll didn't check/try; but what IS the best way to get > a key into a system. I can do gpg --import and move + package the file > of course; but is there a cleaner solution to get the file, into say > /etc/keys for example? (Without using the --keyring paramater of gpg, as > that paramater has come and gone in certain versions, so not sure how > reliable that one is). Or is it really the only and recommended way. The best way to create a set of keys that can validate is to explictly and deliberately *export* (not import!) the keys that you know you care about into a file. so, verify that you get *only* the keys you want: gpg --list-keys $FINGERPRINT and then if it looks good: gpg --output curated.pgp --export $FINGERPRINT then you can pass curated.pgp to gpgv's --keyring argument. Note that gpgv has weird non-standard semantics for its --keyring argument, though -- if the filename has no "/" in it, it's assumed to be found in the homedir (typically, ~/.gnupg/), rather than in the current working directory, so i always specify keyrings with an absolute path. in the shell, you can often launder it through realpath(1), so this should be safe, regardless of how $KEYRING gets set: KEYRING=curated.pgp [?] gpgv --keyring "$(realpath "$KEYRING")" "$signature" "$object" Note also that the semantics of gpgv's return value may not match what you want. In particular, they make it difficult to ship additional signatures during a time of key transition, because gpgv will return non-zero if *any* discovered signatures are "bad" [0]. Additionally, gpgv has some odd semantics around key creation time, expiry, revocation, etc: https://dev.gnupg.org/T1537 So you really do want to use --status-fd and parse its output to determine what happened, and not just rely on its return code. --dkg [0] explanation of the lifecycle of a signed series of updates: * at time T, clients fetch update U_T with signature bundle S_T. the clients all verify that S_T is signed by one of the keys they know about. * initially, all clients know only about signing key K_0. * So, at early time A, a client fetches update U_A and signature S_A and verifies that S_A is made by K_0. * at some future time B, the authors introduce a new signing key K_1, but not all clients know about it yet. S_B contains signatures from both K_0 and K_1. Unupdated clients verify S_B over U_B based on K_0, while updated clients verify S_B over U_B based on K_1. * later, at time C, once all clients are known to be updated (or are explictly unsupported), the authors drop or revoke or destroy K_0, and sign new updates only with K_1. between times B and C, any verification mechanism that depends on gpgv's return code will break for clients that don't know about *both* K_0 and K_1. This requires software vendors to ship their preferred signing keys well before they start actually distributing signatures with them, which is a surprising workflow. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From 2017-r3sgs86x8e-lists-groups at riseup.net Mon Mar 4 02:51:47 2019 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Mon, 4 Mar 2019 01:51:47 +0000 Subject: Howto override "encrypt-to KEYHERE" in gpg.conf? In-Reply-To: <201902281340.x1SDeuFR024834@epjdn.zq3q.org> References: <201902281340.x1SDeuFR024834@epjdn.zq3q.org> Message-ID: <709406441.20190304015147@my_localhost_LG> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Thursday 28 February 2019 at 1:40:56 PM, in , gpg at trodman.com wrote:- > My goal is to run gpg commands that entirely ignore > my default-key and encrypt-to key > in ~/.gnupg/gpg.conf. - --no-options - -- Best regards MFPA Everyone makes mistakes. It is what you do afterwards that counts. -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCXHyEu18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju +hqSAQDoHYdmxfXXS/iL59lKi7iEQSeKqsViNXNa98raL2W3ugEAmkQ3/2n4vmQv EtuFZZFM+cRPe0MXBdwkwtgY8nFN9w+JApMEAQEKAH0WIQRSX6konxd5jbM7JygT DfUWES/A/wUCXHyEu18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/2uzD/9X4iaG7qzIGXwbHIrK46YR+iMM uYVW957P3FtNqOIhf7asAXB5wTpKhB7ZnaHIXbmfi9uVCveu8yT4J/DXSrAeyraN w3cc1DWBcYOcizT0pCo1fH/HWiO59NNcudKirJMZLkNn1p0M+FQuDVzFtMUAgqsg VJCQV1xsEBPC4jBs9s54QswW0I9iFKMVi3erpSJ00vcIIyVANu0POvLfjh9m6Ixp E+RoyLP44klw5JjSEF5pdkkDtmBOg1Igza9baLzZjUxXHzWCw27CIysD084jjUqN tZ+bFOavquKLjjulQvTDHify5USUhRDG2qrDZ8rLpxNckvrd9VkQ3umPEY7J+2Jn rqgD39oahxtxlwqLgm8/EHoATIGJvzOtx5JS4i5o3cZXWXHI5olxsXCRVrgMpTZv Iq1TxB9lljY/FaIfR9X2ebM5BBg7I3VXg3uD0m2sTbt/RxOkRoitWG/YaGjW8si3 bvzsZp10HrLHawPzG3kH0/PCxQF74KYTOdfzEaFxcIeiQaRe6VSxyUFe9Fy934E6 zzuXAf4Esvm7p4XVhJUY+SzPtMBVQjKfSVIn5xEU0wLLgDjd1feDXKFomxNvx1SO DgQ2wkdxgKHl2q6x3EjOWF5Q+jmyPY1uyTBWV3eeJql4aOYd5hwj6WxBGZtvHrEu IYktMs3vyNfoUg1cxA== =BWOr -----END PGP SIGNATURE----- From farhan at farhan.codes Mon Mar 4 03:51:51 2019 From: farhan at farhan.codes (Farhan Khan) Date: Sun, 3 Mar 2019 21:51:51 -0500 Subject: Invalid IPC Response requiring gpg-agent restart Message-ID: <20190304025121.GA7327@pc.farhan.codes> Hi all, I am ssh'ing into a FreeBSD box with my PGP key. I noticed that when I try to decrypt or sign something, I get this error: --- $ echo test | gpg -a --sign gpg: signing failed: Invalid IPC response -----BEGIN PGP MESSAGE----- gpg: signing failed: Invalid IPC response --- When I check the running processes, I see this: gpg-agent --homedir /usr/home/user/.gnupg --use-standard-socket --daemon My ~/.gpg-agent.conf is: enable-ssh-support default-cache-ttl 300 max-cache-ttl 1200 If I kill this process and restart using "gpg-agent --daemon', everything works fine. Is there a long-term solution to fix whatever settings is broken? Thanks! --- Farhan Khan PGP Fingerprint: 1312 89CE 663E 1EB2 179C 1C83 C41D 2281 F8DA C0DE -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: From ralf at rfechner.de Mon Mar 4 13:41:51 2019 From: ralf at rfechner.de (Ralf Fechner) Date: Mon, 4 Mar 2019 13:41:51 +0100 Subject: OPENPGPKEY on DANE Message-ID: <91bdf6a5-dab2-45dc-4ab1-83eae6189665@rfechner.de> Hi, How can I search and load an OPENPGPKEY on DANE in Ubuntu in the terminal? --auto-key-loacate clear, dane, local --locate-key -v email at adress.com This works on Mac OSX, but not on Ubuntu. From gpirlot at manymore.fr Tue Mar 5 10:05:33 2019 From: gpirlot at manymore.fr (gpirlot at manymore.fr) Date: Tue, 5 Mar 2019 10:05:33 +0100 Subject: setting up decryption in an automated environment Message-ID: <013401d4d332$974b7f80$c5e27e80$@manymore.fr> Hi all I'm rather new with gpg, and would like to setup and automated decryption of incoming files into a specific directory. In the previous version the parameter -passphrase did the trick (although not the most secured) but it isn't working anymore. I've ha a try with the 8.20 in the tuto with no more success. Please help .. regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Tue Mar 5 18:05:33 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 05 Mar 2019 18:05:33 +0100 Subject: Invalid IPC Response requiring gpg-agent restart In-Reply-To: <20190304025121.GA7327@pc.farhan.codes> (Farhan Khan via Gnupg-users's message of "Sun, 3 Mar 2019 21:51:51 -0500") References: <20190304025121.GA7327@pc.farhan.codes> Message-ID: <871s3lb6aq.fsf@wheatstone.g10code.de> On Sun, 3 Mar 2019 21:51, gnupg-users at gnupg.org said: > $ echo test | gpg -a --sign > gpg: signing failed: Invalid IPC response Please run $ echo test | gpg -a --sign --verbose --debug ipc to see the communication with the gpg-agent. The rrror message reminds me of the time when gnome-keyring hijacked the gpg-agent connection. What version of gpg are you running - do you have an ancient gpg-agent running? 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 Mar 5 18:08:22 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 05 Mar 2019 18:08:22 +0100 Subject: OPENPGPKEY on DANE In-Reply-To: <91bdf6a5-dab2-45dc-4ab1-83eae6189665@rfechner.de> (Ralf Fechner via Gnupg-users's message of "Mon, 4 Mar 2019 13:41:51 +0100") References: <91bdf6a5-dab2-45dc-4ab1-83eae6189665@rfechner.de> Message-ID: <87wold9rll.fsf@wheatstone.g10code.de> On Mon, 4 Mar 2019 13:41, gnupg-users at gnupg.org said: > --auto-key-loacate clear, dane, local --locate-key -v email at adress.com Do not put spaces between the a-k-l parameters. "dane' would be considered as first argeument and gpg tries to do something with that. There should be a warning. gpg --version shows what (only the first few lines)? 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 Mar 5 18:13:14 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 05 Mar 2019 18:13:14 +0100 Subject: setting up decryption in an automated environment In-Reply-To: <013401d4d332$974b7f80$c5e27e80$@manymore.fr> (gpirlot's message of "Tue, 5 Mar 2019 10:05:33 +0100") References: <013401d4d332$974b7f80$c5e27e80$@manymore.fr> Message-ID: <87sgw19rdh.fsf@wheatstone.g10code.de> On Tue, 5 Mar 2019 10:05, gpirlot at manymore.fr said: > In the previous version the parameter -passphrase did the trick (although > not the most secured) but it isn't working anymore. Given that it is an unattended environment, a passphrase to protect the private key does not make any sense (in most cases). Thus remove the passphrase and you are fine: gpg --passwd KEYID and then enter an empty string and confirm. Also make sure that --batch is passed to gpg. To avoid DoS (think uncompression) it is also often useful to add --max-output=REASONABLE_LARGE_BYTE_COUNT 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 farhan at farhan.codes Tue Mar 5 20:39:37 2019 From: farhan at farhan.codes (Farhan Khan) Date: Tue, 5 Mar 2019 14:39:37 -0500 Subject: PGP Anonymous Board Idea Message-ID: <20190305193937.GA17996@pc.farhan.codes> Hi all, I had an idea for an anonymous PGP messaging board system and wanted to get feedback on it or know if this idea has already been done. In short, this would be an anonymous messaging system where you can post encrypted messages. Anyone can access the encrypted message but obviously only the one with the private key can decrypt it. Receiving users can filter for messages by their key ID to see if they have received anything. The system also replicates data across multiple servers so you can post a message on server A and a user can view the message on server B. Problems this solves: * Increase anonyminity of the *sender*. No attributable data is stored for the sender, such as email headers or IP addresses. The receiver can take steps to be anonymous, such as using a different key than a primary, but ultimately the receiver will require some form of a unique identifier. * While you can already do this on a message board or Usenet, those systems are not designed for this. They are not easily searchable or centralized. For example, I cannot filter for all messages sent to 0x0123456789ABCDEF on an online forum without a manual effort. The general process of the server would be to receive a message via HTTPS, determine its key ID, store it in a binary format to reduce the size and make it searchable by the limited metadata in all encrypted messages. Finally, two or more servers can replicate data on a periodic or in-real-time basis. And there are obviously standard problems, such as spam, the size of the database or a rogue server storing sender IP address data. But these are standard problems in all such systems. Obviously this would not be the next big method of communication, but an interesting niche idea and it seems easy to produce a proof-of-concept. Thoughts? I full anticipate being torn down :) --- Farhan Khan PGP Fingerprint: 1312 89CE 663E 1EB2 179C 1C83 C41D 2281 F8DA C0DE -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: From sac at 300baud.de Tue Mar 5 21:01:57 2019 From: sac at 300baud.de (Stefan Claas) Date: Tue, 5 Mar 2019 21:01:57 +0100 Subject: PGP Anonymous Board Idea In-Reply-To: <20190305193937.GA17996@pc.farhan.codes> References: <20190305193937.GA17996@pc.farhan.codes> Message-ID: <20190305210157.5b0e240a@iria.my-fqdn.de> Am Tue, 5 Mar 2019 14:39:37 -0500 schrieb Farhan Khan via Gnupg-users : Hi, > Hi all, > > I had an idea for an anonymous PGP messaging board system and wanted > to get feedback on it or know if this idea has already been done. > > In short, this would be an anonymous messaging system where you can > post encrypted messages. Anyone can access the encrypted message but > obviously only the one with the private key can decrypt it. Receiving > users can filter for messages by their key ID to see if they have > received anything. The system also replicates data across multiple > servers so you can post a message on server A and a user can view the > message on server B. This already exists for decades ... Simply use free Usenet Servers via Tor and post your anonymous* PGP messages to the Usenet group alt.anonymous.messages. *You send PGP encrypted messages via Mixmaster Remailers (via Tor) and preferably use a hashed subject (hsub) so that the intended receiver(s) can filter out their messages. That is the most reliable old school method. Solution 2 is use Bitmessage, where you can create yourself a chan which everybody can subscribe to. Beware, once a chan is publicty known it can be spammed easily. Bitmessage is so cool an easy to use, via Tor, that it probably became on of the most hated Networks in some peoples eyes. For Bitmessage there is no need to use old stuff like PGP. Hope this helps a bit or two. Regards Stefan From sac at 300baud.de Tue Mar 5 21:23:10 2019 From: sac at 300baud.de (Stefan Claas) Date: Tue, 5 Mar 2019 21:23:10 +0100 Subject: PGP Anonymous Board Idea In-Reply-To: <20190305210157.5b0e240a@iria.my-fqdn.de> References: <20190305193937.GA17996@pc.farhan.codes> <20190305210157.5b0e240a@iria.my-fqdn.de> Message-ID: <20190305212310.51b70873@iria.my-fqdn.de> Am Tue, 5 Mar 2019 21:01:57 +0100 schrieb Stefan Claas : > Solution 2 is use Bitmessage ... Solution 3 is to check out ZeroNet (via Tor), where people can also host their own message boards etc. Regards Stefan From fa-ml at ariis.it Tue Mar 5 21:08:17 2019 From: fa-ml at ariis.it (Francesco Ariis) Date: Tue, 5 Mar 2019 21:08:17 +0100 Subject: PGP Anonymous Board Idea In-Reply-To: <20190305193937.GA17996@pc.farhan.codes> References: <20190305193937.GA17996@pc.farhan.codes> Message-ID: <20190305200817.mucig4secu4nw2te@x60s.casa> Hello Farhan, On Tue, Mar 05, 2019 at 02:39:37PM -0500, Farhan Khan via Gnupg-users wrote: > I had an idea for an anonymous PGP messaging board system and wanted to get > feedback on it or know if this idea has already been done. > > In short, this would be an anonymous messaging system where you can post > encrypted messages. Anyone can access the encrypted message but obviously only > the one with the private key can decrypt it. Receiving users can filter for > messages by their key ID to see if they have received anything. The system also > replicates data across multiple servers so you can post a message on server A > and a user can view the message on server B. Your idea sounds similar (but not exactly the same) to alt.anonymous.messages [1]. [1] https://groups.google.com/forum/#!forum/alt.anonymous.messages From info at rfechner.de Tue Mar 5 22:41:05 2019 From: info at rfechner.de (Ralf Fechner) Date: Tue, 5 Mar 2019 22:41:05 +0100 Subject: OPENPGPKEY on DANE In-Reply-To: <87wold9rll.fsf@wheatstone.g10code.de> References: <91bdf6a5-dab2-45dc-4ab1-83eae6189665@rfechner.de> <87wold9rll.fsf@wheatstone.g10code.de> Message-ID: Hi Werner, gpg --version shows gpg (GnuPG) 2.2.4 libgcrypt 1.8.1 Is the current Ubuntu version 18.04.1 LTS Am Di., 5. M?rz 2019 um 18:10 Uhr schrieb Werner Koch : > On Mon, 4 Mar 2019 13:41, gnupg-users at gnupg.org said: > > > --auto-key-loacate clear, dane, local --locate-key -v email at adress.com > > Do not put spaces between the a-k-l parameters. "dane' would be > considered as first argeument and gpg tries to do something with that. > There should be a warning. > > gpg --version > > shows what (only the first few lines)? > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at rfechner.de Tue Mar 5 23:43:07 2019 From: info at rfechner.de (Ralf Fechner) Date: Tue, 5 Mar 2019 23:43:07 +0100 Subject: OPENPGPKEY on DANE In-Reply-To: <87wold9rll.fsf@wheatstone.g10code.de> References: <91bdf6a5-dab2-45dc-4ab1-83eae6189665@rfechner.de> <87wold9rll.fsf@wheatstone.g10code.de> Message-ID: Here is the comparison between Ubuntu and MacOS X Is the current Ubuntu version 18.04.1 LTS gpg --version shows gpg (GnuPG) 2.2.4 libgcrypt 1.8.1 gpg ?auto-key- locate clear, dane, local ?locate-key -v info at rfechner.de gpg: using pgp trust model gpg: error retrieving 'info at rfechner.de' via DANE: Not found gpg: error retrieving 'info at rfechner.de' via Local: No public key gpg: key "info at rfechner.de" not found: No public key Is the current MacOS X version 10.14.3 gpg --version gpg (GnuPG/MacGPG2) 2.2.10 libgcrypt 1.8.3 gpg --auto-key-locate clear,dane,local --locate-key -v info at rfechner.de gpg: using pgp trust model gpg: pub rsa4096/3483D5010AB99E0E 2018-02-11 Ralf Fechner < ralf at rfechner.de> gpg: key 3483D5010AB99E0E: public key "Ralf Fechner " imported gpg: no running gpg-agent - starting '/usr/local/MacGPG2/bin/gpg-agent' gpg: waiting for the agent to come up ... (5s) gpg: connection to agent established gpg: Total number processed: 1 gpg: imported: 1 gpg: auto-key-locate found fingerprint 48E923AEE27ABAB7A68D76F93483D5010AB99E0E gpg: automatically retrieved 'info at rfechner.de' via DANE pub rsa4096 2018-02-11 [C] [expires: 2024-01-19] 48E923AEE27ABAB7A68D76F93483D5010AB99E0E uid [ unknown] Ralf Fechner sub rsa4096 2018-02-11 [S] [expires: 2020-01-20] sub rsa4096 2018-02-11 [E] [expires: 2020-01-20] sub rsa4096 2018-02-11 [A] [expires: 2020-01-20] Am Di., 5. M?rz 2019 um 18:10 Uhr schrieb Werner Koch : > On Mon, 4 Mar 2019 13:41, gnupg-users at gnupg.org said: > > > --auto-key-loacate clear, dane, local --locate-key -v email at adress.com > > Do not put spaces between the a-k-l parameters. "dane' would be > considered as first argeument and gpg tries to do something with that. > There should be a warning. > > gpg --version > > shows what (only the first few lines)? > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sac at 300baud.de Wed Mar 6 00:00:31 2019 From: sac at 300baud.de (Stefan Claas) Date: Wed, 6 Mar 2019 00:00:31 +0100 Subject: PGP Anonymous Board Idea In-Reply-To: <20190305215330.GA19982@pc.farhan.codes> References: <20190305193937.GA17996@pc.farhan.codes> <20190305210157.5b0e240a@iria.my-fqdn.de> <20190305215330.GA19982@pc.farhan.codes> Message-ID: <20190306000031.089e5f48@iria.my-fqdn.de> Am Tue, 5 Mar 2019 16:53:30 -0500 schrieb Farhan Khan : > My issue with Usenet is two fold: > A. The post metadata of the sender is preserved in Usenet. > B. It is not easily searchable or filterable. However, the subject > hash idea is pretty interesting. Well, about the metadata, there is no metadata from users, when using Mixmaster! You would install a Mixmaster client and then use a chain of remailers, which gives you then latency, and your posting is submitted via a mail2news gatway. The only thing what third parties see is an encrypted PGP message (gpg hidden recipient), posted via an exit remailer, from that chain. Additionally people use nowadays Mixmaster in combination with Tor. You can read more about hsubs here: http://mixnym.net/hsub.html Regards Stefan From sac at 300baud.de Wed Mar 6 00:18:28 2019 From: sac at 300baud.de (Stefan Claas) Date: Wed, 6 Mar 2019 00:18:28 +0100 Subject: PGP Anonymous Board Idea In-Reply-To: <20190306000031.089e5f48@iria.my-fqdn.de> References: <20190305193937.GA17996@pc.farhan.codes> <20190305210157.5b0e240a@iria.my-fqdn.de> <20190305215330.GA19982@pc.farhan.codes> <20190306000031.089e5f48@iria.my-fqdn.de> Message-ID: <20190306001828.6feff690@iria.my-fqdn.de> Am Wed, 6 Mar 2019 00:00:31 +0100 schrieb Stefan Claas : > You can read more about hsubs here: > > http://mixnym.net/hsub.html And to fetch hsub messages from alt.anonymous.messages: https://github.com/crooks/aam2mail Regards Stefan From info at rfechner.de Wed Mar 6 00:27:06 2019 From: info at rfechner.de (Ralf Fechner) Date: Wed, 6 Mar 2019 00:27:06 +0100 Subject: OPENPGPKEY on DANE In-Reply-To: <87wold9rll.fsf@wheatstone.g10code.de> References: <91bdf6a5-dab2-45dc-4ab1-83eae6189665@rfechner.de> <87wold9rll.fsf@wheatstone.g10code.de> Message-ID: Sorry there were again the spaces in it. Of course I use the same command under Ubuntu and MacOS X. gpg ?auto-key-locate clear,dane,local ?locate-key -v info at rfechner.de Am Di., 5. M?rz 2019 um 18:10 Uhr schrieb Werner Koch : > On Mon, 4 Mar 2019 13:41, gnupg-users at gnupg.org said: > > > --auto-key-loacate clear, dane, local --locate-key -v email at adress.com > > Do not put spaces between the a-k-l parameters. "dane' would be > considered as first argeument and gpg tries to do something with that. > There should be a warning. > > gpg --version > > shows what (only the first few lines)? > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Wed Mar 6 08:26:11 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 06 Mar 2019 08:26:11 +0100 Subject: OPENPGPKEY on DANE In-Reply-To: (Ralf Fechner via Gnupg-users's message of "Tue, 5 Mar 2019 23:43:07 +0100") References: <91bdf6a5-dab2-45dc-4ab1-83eae6189665@rfechner.de> <87wold9rll.fsf@wheatstone.g10code.de> Message-ID: <875zswa2gc.fsf@wheatstone.g10code.de> On Tue, 5 Mar 2019 23:43, gnupg-users at gnupg.org said: > gpg: error retrieving 'info at rfechner.de' via DANE: Not found > gpg: error retrieving 'info at rfechner.de' via Local: No public key Okay, you need to look into the actual DNS requests. Please add --8<---------------cut here---------------start------------->8--- log-file /tmp/foo/bar/dirmngr.log verbose debug ipc,dns --8<---------------cut here---------------end--------------->8--- into ~/.gnupg/dirmngr.conf and restart dirmngr (gpgconf --kill dirmngr). Then run the gpg command again and you will find debug messages pertaining to the DNS request in the log. 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 abbot at monksofcool.net Wed Mar 6 17:57:01 2019 From: abbot at monksofcool.net (Ralph Seichter) Date: Wed, 06 Mar 2019 17:57:01 +0100 Subject: PGP Anonymous Board Idea In-Reply-To: <20190305193937.GA17996@pc.farhan.codes> References: <20190305193937.GA17996@pc.farhan.codes> Message-ID: <87y35sc55u.fsf@ra.horus-it.com> * Farhan Khan via Gnupg-users: > Obviously this would not be the next big method of communication, but > an interesting niche idea and it seems easy to produce a proof-of-concept. Not meaning to rain on your parade, but after mulling over your idea, I don't see benefits over what can already be done using the Tor Network as a foundation. -Ralph From ralf at rfechner.de Wed Mar 6 21:58:28 2019 From: ralf at rfechner.de (Ralf Fechner) Date: Wed, 6 Mar 2019 21:58:28 +0100 Subject: OPENPGPKEY on DANE In-Reply-To: <875zswa2gc.fsf@wheatstone.g10code.de> References: <91bdf6a5-dab2-45dc-4ab1-83eae6189665@rfechner.de> <87wold9rll.fsf@wheatstone.g10code.de> <875zswa2gc.fsf@wheatstone.g10code.de> Message-ID: <8c7b8521-bd0f-e8e5-0180-57f0770451c0@rfechner.de> Ubuntu: 2019-03-06 21:25:50 dirmngr[2855.0] permanently loaded certificates: 134 2019-03-06 21:25:50 dirmngr[2855.0]???? runtime cached certificates: 0 2019-03-06 21:25:50 dirmngr[2855.0]??????????? trusted certificates: 134 (133,0,0,1) 2019-03-06 21:25:50 dirmngr[2855.6] handler for fd 6 started 2019-03-06 21:25:50 dirmngr[2855.6] DBG: chan_6 -> # Home: /home/ralf/.gnupg 2019-03-06 21:25:50 dirmngr[2855.6] DBG: chan_6 -> # Config: /home/ralf/.gnupg/dirmngr. conf 2019-03-06 21:25:50 dirmngr[2855.6] DBG: chan_6 -> OK Dirmngr 2.2.4 at your service 2019-03-06 21:25:50 dirmngr[2855.6] connection from process 2854 (1000:1000) 2019-03-06 21:25:50 dirmngr[2855.6] DBG: chan_6 <- GETINFO version 2019-03-06 21:25:50 dirmngr[2855.6] DBG: chan_6 -> D 2.2.4 2019-03-06 21:25:50 dirmngr[2855.6] DBG: chan_6 -> OK 2019-03-06 21:25:50 dirmngr[2855.6] DBG: chan_6 <- KEYSERVER --clear hkp://keys.gnupg.net 2019-03-06 21:25:50 dirmngr[2855.6] DBG: chan_6 -> OK 2019-03-06 21:25:50 dirmngr[2855.6] DBG: chan_6 <- DNS_CERT --dane info at rfechner.de mailto:info at rfechner.de 2019-03-06 21:25:50 dirmngr[2855.6] DBG: dns: libdns initialized 2019-03-06 21:26:00 dirmngr[2855.6] DBG: dns: get_dns_cert(06271baf49532c879aa3c58b48671884bcc858f09197412d68275049._openpgpkey.rfechner.de):Not found 2019-03-06 21:26:00 dirmngr[2855.6] command 'DNS_CERT' failed: Not found 2019-03-06 21:26:00 dirmngr[2855.6] DBG: chan_6 -> ERR 167772187 Not found 2019-03-06 21:26:00 dirmngr[2855.6] DBG: chan_6 <- BYE 2019-03-06 21:26:00 dirmngr[2855.6] DBG: chan_6 -> OK closing connection 2019-03-06 21:26:00 dirmngr[2855.6] handler for fd 6 terminated From ralf at rfechner.de Wed Mar 6 21:59:42 2019 From: ralf at rfechner.de (Ralf Fechner) Date: Wed, 6 Mar 2019 21:59:42 +0100 Subject: OPENPGPKEY on DANE In-Reply-To: <875zswa2gc.fsf@wheatstone.g10code.de> References: <91bdf6a5-dab2-45dc-4ab1-83eae6189665@rfechner.de> <87wold9rll.fsf@wheatstone.g10code.de> <875zswa2gc.fsf@wheatstone.g10code.de> Message-ID: MacOS X 2019-03-06 19:44:46 dirmngr[1934] listening on socket '/Users/ralfi/.gnupg/S.dirmngr' 2019-03-06 19:44:46 dirmngr[1935.0] permanently loaded certificates: 49 2019-03-06 19:44:46 dirmngr[1935.0]???? runtime cached certificates: 0 2019-03-06 19:44:46 dirmngr[1935.0]??????????? trusted certificates: 49 (48,0,0,1) 2019-03-06 19:44:46 dirmngr[1935.6] handler for fd 6 started 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> # Home: /Users/ralfi/.gnupg 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> # Config: /Users/ralfi/.gnupg/dirmngr.conf 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> OK Dirmngr 2.2.10 at your service 2019-03-06 19:44:46 dirmngr[1935.6] connection from process -1 (501:20) 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 <- GETINFO version 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> D 2.2.10 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> OK 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 <- DNS_CERT --dane info at rfechner.de 2019-03-06 19:44:46 dirmngr[1935.6] DBG: dns: fallback resolution order, files then DNS 2019-03-06 19:44:46 dirmngr[1935.6] DBG: dns: libdns initialized 2019-03-06 19:44:46 dirmngr[1935.6] DBG: dns: get_dns_cert(06271baf49532c879aa3c58b48671884bcc858f09197412d68275049._openpgpkey.rfechner.de): Success 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> [ 44 20 99 02 25 30 44 04 5a 80 8f f1 01 10 00 c1 ...(149 byte(s) skipped) ] 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> [ 44 20 83 a9 03 8c f1 68 63 48 4a aa 33 cd 39 61 ...(56 byte(s) skipped) ] 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> [ 44 20 73 c4 8f de 34 eb 4d 5c 07 0f 9a f8 d7 e7 ...(349 byte(s) skipped) ] 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> [ 44 20 0b 04 16 02 03 01 02 1e 01 02 17 80 16 21 ...(20 byte(s) skipped) ] 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> [ 44 20 b9 9e 0e 05 02 5c 44 6e 59 05 09 0b 29 df ...(5 byte(s) skipped) ] 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> [ 44 20 09 10 34 83 d5 01 25 30 41 ] 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> [ 44 20 b9 9e 0e 9a 12 10 00 c1 04 e3 df 72 16 81 ...(577 byte(s) skipped) ] 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> [ 44 20 0b 04 16 02 03 01 02 1e 01 02 17 80 16 21 ...(20 byte(s) skipped) ] 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> [ 44 20 b9 9e 0e 05 02 5c 44 6e 51 05 09 0b 29 df ...(5 byte(s) skipped) ] 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> [ 44 20 09 10 34 83 d5 01 25 30 41 ] 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> [ 44 20 b9 9e 0e 83 e3 10 00 93 ab b7 13 2f 81 b5 ...(471 byte(s) skipped) ] 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> [ 44 20 1b 2e c2 75 6e f2 4b e6 5e e3 79 f5 bb 8d ...(197 byte(s) skipped) ] 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> [ 44 20 23 72 79 b8 da e5 0c 59 4f 7e f3 c3 59 9e ...(12 byte(s) skipped) ] 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> [ 44 20 f0 bd 33 f7 7d de 37 7e c6 0f 8f 3a bb 33 ...(363 byte(s) skipped) ] 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> [ 44 20 b9 9e 0e 05 02 5c 44 6e 9c 05 09 03 a5 11 ...(22 byte(s) skipped) ] 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> [ 44 20 09 10 53 1a 6b b3 75 12 d4 70 ee 27 0f fd ...(4 byte(s) skipped) ] 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> [ 44 20 7d 21 f8 23 55 50 8e d2 99 41 c3 64 7e 22 ...(511 byte(s) skipped) ] 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> [ 44 20 b9 9e 0e 59 be 0f fe 24 6b a7 34 d6 55 f4 ...(346 byte(s) skipped) ] 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> [ 44 20 03 a9 9b c1 bc b6 c5 e3 24 3f 9c 7b fd ad ...(106 byte(s) skipped) ] 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> [ 44 20 d6 50 25 30 44 9d 69 f3 9a 60 bc d7 a9 09 ...(615 byte(s) skipped) ] 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> [ 44 20 b9 9e 0e 05 02 5c 44 6e b8 05 09 03 a5 10 ...(5 byte(s) skipped) ] 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> [ 44 20 09 10 34 83 d5 01 25 30 41 ] 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> [ 44 20 b9 9e 0e a9 82 0f ff 46 43 1f 1e 21 e7 a2 ...(5 byte(s) skipped) ] 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> [ 44 20 c8 70 8d 92 7b 54 19 49 04 7e c3 f4 ab 61 ...(69 byte(s) skipped) ] 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> [ 44 20 9e 65 68 2e 54 db fd 92 14 04 59 e8 35 be ...(981 byte(s) skipped) ] 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> [ 44 20 b9 9e 0e 05 02 5c 44 6e d2 05 09 03 a5 0f ...(5 byte(s) skipped) ] 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> [ 44 20 09 10 34 83 d5 01 25 30 41 ] 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> [ 44 20 b9 9e 0e ae f3 0f ff 4b 0b 9d 2c ff 2b 99 ...(7 byte(s) skipped) ] 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> [ 44 20 82 0f bf 27 a5 f0 91 cc a2 56 e3 48 b0 8a ...(136 byte(s) skipped) ] 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> [ 44 20 f3 c8 6c 6a 92 ac 6b ab 04 5e 98 b8 9a dd ...(12 byte(s) skipped) ] 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> [ 44 20 c3 6a 43 5e eb 11 02 e9 84 74 f7 5a c7 5a ...(44 byte(s) skipped) ] 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> [ 44 20 d5 12 54 f6 63 16 e5 8c ba 15 53 73 b4 4d ...(62 byte(s) skipped) ] 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> [ 44 20 c0 c7 49 b3 04 b7 f3 f9 b0 39 82 99 75 24 ...(99 byte(s) skipped) ] 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> [ 44 20 bd 64 b2 24 6a 01 3e 41 3e b1 ac 70 e3 ff ...(79 byte(s) skipped) ] 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> OK 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 <- BYE 2019-03-06 19:44:46 dirmngr[1935.6] DBG: chan_6 -> OK closing connection 2019-03-06 19:44:46 dirmngr[1935.6] handler for fd 6 terminated 2019-03-06 19:55:46 dirmngr[1935.0] running scheduled tasks 2019-03-06 21:07:51 dirmngr[1935.0] running scheduled tasks 2019-03-06 21:17:51 dirmngr[1935.0] running scheduled tasks 2019-03-06 21:28:02 dirmngr[1935.0] running scheduled tasks 2019-03-06 21:38:02 dirmngr[1935.0] running scheduled tasks 2019-03-06 21:48:02 dirmngr[1935.0] running scheduled tasks 2019-03-06 21:58:02 dirmngr[1935.0] running scheduled tasks From al-gnupg_users at none.at Thu Mar 7 11:09:47 2019 From: al-gnupg_users at none.at (Aleksandar Lazic) Date: Thu, 07 Mar 2019 11:09:47 +0100 Subject: PGP Anonymous Board Idea In-Reply-To: <87y35sc55u.fsf@ra.horus-it.com> References: <20190305193937.GA17996@pc.farhan.codes> <87y35sc55u.fsf@ra.horus-it.com> Message-ID: <5f593c91ed8747e7e1749f52870c41c7@none.at> Hi. Am 06-03-2019 17:57, schrieb Ralph Seichter: > * Farhan Khan via Gnupg-users: > >> Obviously this would not be the next big method of communication, but >> an interesting niche idea and it seems easy to produce a >> proof-of-concept. > > Not meaning to rain on your parade, but after mulling over your idea, I > don't see benefits over what can already be done using the Tor Network > as a foundation. Is Tor really as anonymous as is was in the past? I think the mixmaster approach should be still in place also when you use Tor, IMHO. > -Ralph Aleks > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From abbot at monksofcool.net Thu Mar 7 16:01:05 2019 From: abbot at monksofcool.net (Ralph Seichter) Date: Thu, 07 Mar 2019 16:01:05 +0100 Subject: PGP Anonymous Board Idea In-Reply-To: <5f593c91ed8747e7e1749f52870c41c7@none.at> References: <20190305193937.GA17996@pc.farhan.codes> <87y35sc55u.fsf@ra.horus-it.com> <5f593c91ed8747e7e1749f52870c41c7@none.at> Message-ID: <87zhq6wwy6.fsf@ra.horus-it.com> * Aleksandar Lazic: > Am 06-03-2019 17:57, schrieb Ralph Seichter: > >> I don't see benefits over what can already be done using the >> Tor Network as a foundation. > > Is Tor really as anonymous as is was in the past? I don't know what you mean by that question. > I think the mixmaster approach should be still in place also when you > use Tor, IMHO. I wrote "using the Tor Network as a foundation", but in this case it might actually be enough. The OP presented his idea for "an anonymous PGP messaging board", and such a messaging board could in all likelihood be accessed using only the Tor Browser (I don't see a reason for mail in a forum application). Providing this as an onion service would of course also be an option. -Ralph From wk at gnupg.org Fri Mar 8 09:04:30 2019 From: wk at gnupg.org (Werner Koch) Date: Fri, 08 Mar 2019 09:04:30 +0100 Subject: OPENPGPKEY on DANE In-Reply-To: <8c7b8521-bd0f-e8e5-0180-57f0770451c0@rfechner.de> (Ralf Fechner via Gnupg-users's message of "Wed, 6 Mar 2019 21:58:28 +0100") References: <91bdf6a5-dab2-45dc-4ab1-83eae6189665@rfechner.de> <87wold9rll.fsf@wheatstone.g10code.de> <875zswa2gc.fsf@wheatstone.g10code.de> <8c7b8521-bd0f-e8e5-0180-57f0770451c0@rfechner.de> Message-ID: <87pnr194hd.fsf@wheatstone.g10code.de> On Wed, 6 Mar 2019 21:58, gnupg-users at gnupg.org said: > 2019-03-06 21:25:50 dirmngr[2855.6] DBG: chan_6 -> OK Dirmngr 2.2.4 at > your service Between 2.2.4 and 2.2.10 we fixed a couple of bugs in the DNS resolver. This should explain why it works on macOS, where you use 2.2.10. 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 Fri Mar 8 09:15:43 2019 From: wk at gnupg.org (Werner Koch) Date: Fri, 08 Mar 2019 09:15:43 +0100 Subject: user id question In-Reply-To: <1b3e599f-22f1-dd18-3349-949c2afb5ff0@mail.com> (john doe's message of "Sun, 24 Feb 2019 10:09:52 +0100") References: <997697746.20190223153457@my_localhost_LG> <1b3e599f-22f1-dd18-3349-949c2afb5ff0@mail.com> Message-ID: <87imwt93yo.fsf@wheatstone.g10code.de> On Sun, 24 Feb 2019 10:09, johndoe65534 at mail.com said: > What I understand is that there is no clear convention. Meanwhile I would suggest to only use the mail address, that is john at example.org and leave out all other parts. There are even mail providers which demand this for data privacy reasons. However if you prefer to have your mail in it, do it in the same was as it is common in your country/culture like John Doe If you plan to take part in that nerdy key signing game, some participants have the policy to check the real name agains a passport; obviously you would need the latter form then. I used to include my real name in my keys but for my new ed25519 key I use only the mail addresses (I use 3 different mail addresses in my keys). 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 tlikonen at iki.fi Fri Mar 8 19:21:29 2019 From: tlikonen at iki.fi (Teemu Likonen) Date: Fri, 08 Mar 2019 20:21:29 +0200 Subject: Default trust-model TOFU In-Reply-To: <87imwt93yo.fsf@wheatstone.g10code.de> (Werner Koch's message of "Fri, 08 Mar 2019 09:15:43 +0100") References: <997697746.20190223153457@my_localhost_LG> <1b3e599f-22f1-dd18-3349-949c2afb5ff0@mail.com> <87imwt93yo.fsf@wheatstone.g10code.de> Message-ID: <8736nxut06.fsf_-_@iki.fi> Werner Koch [2019-03-08 09:15:43+01] wrote: > If you plan to take part in that nerdy key signing game, [...] Maybe you refer only to key signing parties as nerdy things but I think the whole social web of trust concept is very nerdy. It's useless for most people and I'd say that TOFU model would be better default. Do you have plans for that, to set the default trust model to "tofu" or "tofu+pgp"? -- /// Teemu Likonen - .-.. // // PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 /// -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From sac at 300baud.de Fri Mar 8 19:24:32 2019 From: sac at 300baud.de (Stefan Claas) Date: Fri, 8 Mar 2019 19:24:32 +0100 Subject: PGP Anonymous Board Idea In-Reply-To: <87zhq6wwy6.fsf@ra.horus-it.com> References: <20190305193937.GA17996@pc.farhan.codes> <87y35sc55u.fsf@ra.horus-it.com> <5f593c91ed8747e7e1749f52870c41c7@none.at> <87zhq6wwy6.fsf@ra.horus-it.com> Message-ID: <20190308192432.5159228b@iria.my-fqdn.de> Am Thu, 07 Mar 2019 16:01:05 +0100 schrieb Ralph Seichter : > * Aleksandar Lazic: > > I think the mixmaster approach should be still in place also when > > you use Tor, IMHO. > > I wrote "using the Tor Network as a foundation", but in this case it > might actually be enough. The OP presented his idea for "an anonymous > PGP messaging board", and such a messaging board could in all > likelihood be accessed using only the Tor Browser (I don't see a > reason for mail in a forum application). Providing this as an onion > service would of course also be an option. Well, mail in a "forum" like a Usenet group is there a prefered delivery method, thanks to mail2news gateways. Also if you host a centralized message board on a web server it can be easily taken down, regardless if .onion site or not. In the past many .onion sites have been shut down. With decentralised Usenet groups or Bitmessage chans you don't have these problems. Regards Stefan From johndoe65534 at mail.com Fri Mar 8 20:05:53 2019 From: johndoe65534 at mail.com (john doe) Date: Fri, 8 Mar 2019 20:05:53 +0100 Subject: Multiple dev one signing key Message-ID: <1d5eea4b-d96f-af4f-6055-aa73c43a13d1@mail.com> Hi, I'm considering working on a project that has only for now a couple of developers. As part of that project everything that will be released will need to be gpg signed. What is the best way forward? - One signing key accessible on the release system - Eatch dev having a copy of the key to be able to sign a release - Other suggestions In other words: What is, if any, the best way to sign a file, when the same key is to be used by multiple persons. Any help is appriciated. -- John Doe From johndoe65534 at mail.com Fri Mar 8 20:24:10 2019 From: johndoe65534 at mail.com (john doe) Date: Fri, 8 Mar 2019 20:24:10 +0100 Subject: user id question In-Reply-To: <87imwt93yo.fsf@wheatstone.g10code.de> References: <997697746.20190223153457@my_localhost_LG> <1b3e599f-22f1-dd18-3349-949c2afb5ff0@mail.com> <87imwt93yo.fsf@wheatstone.g10code.de> Message-ID: On 3/8/2019 9:15 AM, Werner Koch wrote: > On Sun, 24 Feb 2019 10:09, johndoe65534 at mail.com said: > >> What I understand is that there is no clear convention. > 'Consensus' and not 'convention'! :) > Meanwhile I would suggest to only use the mail address, that is > > john at example.org > > and leave out all other parts. There are even mail providers which > demand this for data privacy reasons. However if you prefer to have > your mail in it, do it in the same was as it is common in your > country/culture like > > John Doe > > If you plan to take part in that nerdy key signing game, some > participants have the policy to check the real name agains a passport; > obviously you would need the latter form then. > > I used to include my real name in my keys but for my new ed25519 key I > use only the mail addresses (I use 3 different mail addresses in my > keys). > Thank you Werner for your answer. If the former is acceptable to you, I might as well do that. Looks like your are not keen on key signing party, may I ask why? -- John Doe From konstantin at linuxfoundation.org Fri Mar 8 20:38:16 2019 From: konstantin at linuxfoundation.org (Konstantin Ryabitsev) Date: Fri, 8 Mar 2019 14:38:16 -0500 Subject: Multiple dev one signing key In-Reply-To: <1d5eea4b-d96f-af4f-6055-aa73c43a13d1@mail.com> References: <1d5eea4b-d96f-af4f-6055-aa73c43a13d1@mail.com> Message-ID: <20190308193816.GA12060@chatter.qube.local> On Fri, Mar 08, 2019 at 08:05:53PM +0100, john doe wrote: >Hi, > >I'm considering working on a project that has only for now a couple of >developers. >As part of that project everything that will be released will need to be >gpg signed. > >What is the best way forward? >- One signing key accessible on the release system >- Each dev having a copy of the key to be able to sign a release >- Other suggestions From the perspective of kernel.org, we've tried very hard not to have signing keys residing on any kind of centrally managed infrastructure. The general rule is that we place trust into developers, not into infrastructure or systems admins. Therefore, all tags and tarball releases are signed by developers themselves, using their own PGP keys, and those keys are signed by the lead developer (i.e. everyone signing tags on kernel.org can trace their key via the web of trust to Linus Torvalds). So, if anyone wants to verify a tag or a tarball sig, they can trace that developer's key to Linus. I'm willing to bet that this happens extremely rarely, if ever -- most people just use "Trust On First Use." If, for some reason, you can't use this approach and all your releases must be signed by the same key, a solution I can suggest is having a single Certify ("master") key with multiple Signing subkeys. Each developer is given their own Signing subkey, but not the master key. The master private key is kept offline with the passphrase split between multiple members of the project using something like Shamir's Secret Sharing. When someone new joins the team, a new Signing subkey is created and given to them, and if someone leaves, then their subkey is revoked. There are downsides to this approach -- for example, everyone would need to remember to refresh the pubkey regularly in order to get information about new and revoked signing subkeys. If they don't do that, the signatures would fail to verify due to "unknown key" error -- so if your intended target for these signatures if the public at large, then you are likely to have a lot of confusion about what is going on. Anyway, I don't recommend having central infrastructure storing private keys -- unless you invest a lot of effort into setting that up properly, that's going to be a very interesting target for attackers to get into. Best, -K -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From abbot at monksofcool.net Fri Mar 8 22:00:20 2019 From: abbot at monksofcool.net (Ralph Seichter) Date: Fri, 08 Mar 2019 22:00:20 +0100 Subject: PGP Anonymous Board Idea In-Reply-To: <20190308192432.5159228b@iria.my-fqdn.de> References: <20190305193937.GA17996@pc.farhan.codes> <87y35sc55u.fsf@ra.horus-it.com> <5f593c91ed8747e7e1749f52870c41c7@none.at> <87zhq6wwy6.fsf@ra.horus-it.com> <20190308192432.5159228b@iria.my-fqdn.de> Message-ID: <87d0n1rsij.fsf@ra.horus-it.com> * Stefan Claas: > Well, mail in a "forum" like a Usenet group is there a prefered delivery > method, thanks to mail2news gateways. [...] a) We're moving ever further off topic in terms of GnuPG. b) Once again, the OP wrote about "an anonymous PGP messaging board". I happen to have created and run messaging board software, also known as bulletin board software, since the 1980s (e.g. FidoNet, Z-Netz), and I don't see the necessity for using mail in a MBS/BBS at all. c) the OP proposed a centralized approach and stated "The general process of the server would be to receive a message via HTTPS". Seriously, it strains my patience if participants in a discussion fail to pay attention. -Ralph From phill at thesusis.net Fri Mar 8 20:23:58 2019 From: phill at thesusis.net (Phillip Susi) Date: Fri, 8 Mar 2019 14:23:58 -0500 Subject: Multiple dev one signing key In-Reply-To: <1d5eea4b-d96f-af4f-6055-aa73c43a13d1@mail.com> References: <1d5eea4b-d96f-af4f-6055-aa73c43a13d1@mail.com> Message-ID: <0b9b429d-5abe-d347-39f5-fe63c0e81984@thesusis.net> On 3/8/2019 2:05 PM, john doe wrote: > Hi, > > I'm considering working on a project that has only for now a couple of > developers. > As part of that project everything that will be released will need to be > gpg signed. > > What is the best way forward? > - One signing key accessible on the release system > - Eatch dev having a copy of the key to be able to sign a release > - Other suggestions Each dev just uses their own key to sign a release? From sac at 300baud.de Fri Mar 8 22:34:00 2019 From: sac at 300baud.de (Stefan Claas) Date: Fri, 8 Mar 2019 22:34:00 +0100 Subject: PGP Anonymous Board Idea In-Reply-To: <87d0n1rsij.fsf@ra.horus-it.com> References: <20190305193937.GA17996@pc.farhan.codes> <87y35sc55u.fsf@ra.horus-it.com> <5f593c91ed8747e7e1749f52870c41c7@none.at> <87zhq6wwy6.fsf@ra.horus-it.com> <20190308192432.5159228b@iria.my-fqdn.de> <87d0n1rsij.fsf@ra.horus-it.com> Message-ID: <20190308223400.43f1f3b1@iria.my-fqdn.de> Am Fri, 08 Mar 2019 22:00:20 +0100 schrieb Ralph Seichter : > Seriously, it strains my patience if participants in a discussion fail > to pay attention. O.k. understood and sorry for that i only wanted to point out the disadvantages of centralization etc. while there are are proper and proven methods available. Maybe someone can tell then the OP to use Google and search for the string "anonymous message board" and help him then with the required anonymous PGP posting workflow. eod Regards Stefan From dkg at fifthhorseman.net Sun Mar 10 00:05:35 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 09 Mar 2019 18:05:35 -0500 Subject: Multiple dev one signing key In-Reply-To: <1d5eea4b-d96f-af4f-6055-aa73c43a13d1@mail.com> References: <1d5eea4b-d96f-af4f-6055-aa73c43a13d1@mail.com> Message-ID: <874l8bwsw0.fsf@fifthhorseman.net> On Fri 2019-03-08 20:05:53 +0100, john doe wrote: > I'm considering working on a project that has only for now a couple of > developers. > As part of that project everything that will be released will need to be > gpg signed. > > What is the best way forward? > - One signing key accessible on the release system > - Eatch dev having a copy of the key to be able to sign a release > - Other suggestions > > In other words: What is, if any, the best way to sign a file, when the > same key is to be used by multiple persons. This really depends on the development workflow and practices of your team, and the security requirements of your users. So there's no one clear answer. * Does your team have a single release manager, who is responsible for deciding when a release is fully-baked? If so, let the release manager hold the signing key, and no one else. * Do many different people cut releases in your team? If so, you could: a) share a secret signing-capable subkey among all the people who make releases b) if the primary key is signing-capable, share the associated secret key among all the people who make releases. c) make an OpenPGP certificate with multiple signing-capable subkeys, one per release operator * Do you you need *multiple* people to sign off on a release? In that case, you might need some fancier approach (or you might need to modify how your users or downstreams are expected to verify the releases). Does this make sense? Sorry to not have One True Answer? for you! --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From lists at boyandin.info Sun Mar 10 07:25:41 2019 From: lists at boyandin.info (Konstantin Boyandin) Date: 10 Mar 2019 01:25:41 -0500 Subject: Several GnuPG instances, with their corresponding agents Message-ID: <355d4b5a-6620-4b1a-90af-498d7b2e788f@mtasv.net> Hello, I am currently using Ubuntu 18.04; the "built-in", provided from standard repository, GnuPG version is 2.2.4 (it can't be simply removed/replaced by manually built version). I would like to use, whenever I like, manually builds (such as current 2.2.13). Question: how do I keep several GnuPG versions installed, every version with its own gpg-agent? Thanks. Sincerely, Konstantin From mattia.codato at poste.it Sat Mar 9 18:52:46 2019 From: mattia.codato at poste.it (mattia.codato) Date: Sat, 9 Mar 2019 17:52:46 +0000 Subject: Questions about finding keys used to encrypt files with gpg Message-ID: Hi, i've encrypted some files from my hd using the gpg -c [filename] command. As usual gpg prompted me for a passhprase and then created the encrypted files, so far it worked out perfectly. I noticed that the gpg -d [filename] command works out without asking me for the passphrase, so after a brief search i became aware of the fact that gpg uses public/private keys encrypting, combined with a passphrase. Having i used the gpg -c command straight out of the box (so no explicit key setup was made before running the command), i suppose the gpg command used some kind of default keys or something like that. Unfortunately running the gpg --list-keys or gpg --list-secret-keys command gives nothing in output, so i guess no keys is really installed. As far as i know, in order to succesfully export and decrypt the files in other computers, one must export and restore the original key pairs used to encrypt the original files. So what should i do to figure it out what kind of keys were used ? Regards Mattia From dgouttegattat at incenp.org Sun Mar 10 15:50:28 2019 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sun, 10 Mar 2019 14:50:28 +0000 Subject: Several GnuPG instances, with their corresponding agents In-Reply-To: <355d4b5a-6620-4b1a-90af-498d7b2e788f@mtasv.net> References: <355d4b5a-6620-4b1a-90af-498d7b2e788f@mtasv.net> Message-ID: <20190310145028.esqym2frovohhyvx@aurora.local.incenp.org> Hi, On Sun, Mar 10, 2019 at 01:25:41AM -0500, Konstantin Boyandin wrote: > Question: how do I keep several GnuPG versions installed, every > version with its own gpg-agent? A Gpg-agent is tied to a specific home directory (as specified in the GNUPGHOME environment variable or through the --homedir option of gpg), so all you have to is to make sure you use a separate home directory for each version you want to use. For example, assuming you have installed version X of GnuPG under $HOME/myprogs/gnupg-X, create a directory to use as the home directory for that version (say, $HOME/gnupg-homes/X), then you can start using that version by running the following: PATH=$HOME/myprogs/gnupg-X/bin:$PATH export GNUPGHOME=$HOME/gnupg-homes/X $SHELL -i You'll start a new shell in which all GnuPG invocations will use the binaries from the X version and the keyrings and other associated files from the indicated home directory. Simply exit that shell to use again your system-provided GnuPG in the normal home directory. Hope that helps, - Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From 2017-r3sgs86x8e-lists-groups at riseup.net Sun Mar 10 15:51:12 2019 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Sun, 10 Mar 2019 14:51:12 +0000 Subject: user id question In-Reply-To: <87imwt93yo.fsf@wheatstone.g10code.de> References: <997697746.20190223153457@my_localhost_LG> <1b3e599f-22f1-dd18-3349-949c2afb5ff0@mail.com> <87imwt93yo.fsf@wheatstone.g10code.de> Message-ID: <36208424.20190310145112@my_localhost_LG> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Friday 8 March 2019 at 8:15:43 AM, in , Werner Koch wrote:- > If you plan to take part in that nerdy key signing > game Is "nerdy" good or bad in this context? - -- Best regards MFPA The truth is rarely pure and never simple -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCXIUkZV8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju +u9oAQCQMlSlN7PlFjdh4i67SlS3OgcHaMrz19meN9kt37T6GQD/Xvx8AegXZ7fM 9QnMMnEtAEIAlBvfyxDiXuo+tZn/kAqJApMEAQEKAH0WIQRSX6konxd5jbM7JygT DfUWES/A/wUCXIUkZl8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/8PUD/0YHATTgmY4RbZiKz4HbNDn82S6 X9pvPPDoOf0cO0IVCQuVxj9zF4PCI8vVJs4DJDW1x578ThQ3wbLMNXVNTYpwfmVX G6tIV1PaVLlERH4hHtALhL0y6cxD6Z3OfzsMEalAWusIYZbs48kJQS0hntqgDpOr 21uWZG/sDJ9DcI3TkIywYSI21Z3zAjGNhU9WZbg85cH51d6AUPWTTRSzh25JAad6 RTsT/GMcuuCDiPjHWPHQ1Z2tf1TwQI5chJf8gbRn+9opGhs9ziLlzEQywWMs2NAO Z9+getLMutkQBPDWpkRjox5hYwVV2/fZo1sw+bNDdS2kqdAfJg3kyAcMJQEqZAB4 WPVRTGLXzw7wj+TaXBvyY1Wrejzzgv3b8VEgI+Vn5sVVbCFz6AQNydV9Acf2syR9 SrDhOnCEPMG+jHuMjF/M3ZlchUX1CHrPMd7oQtBaor9kWyGyBshVszvH0s8qpz8v fVHMUjlCgUsEuun1ugIM1HUhDCDLh/FoTgGEOukrTHB+qva/jIZc3T6Z1VArvNOO gRZmrRmrodlOjdy849ylXXr9ymU+4ATaz4vSs9+/0qte7CvVVkgkgNSH76hxdkda 7e48bZgv0AZOma1PRyBL4Ch4HAz4PKSzWWSe3GkvsGWUOTME9CKW15qmwSYVaYQN QDbaywtn8GnaxpFx3g== =UKqC -----END PGP SIGNATURE----- From claudio.floreani at gmail.com Sun Mar 10 15:54:45 2019 From: claudio.floreani at gmail.com (Claudio Floreani) Date: Sun, 10 Mar 2019 15:54:45 +0100 Subject: Keys in the keystore dir (private-keys-v1.d/) are being modified Message-ID: I recently updated to GnuPG 2.2 and migrated my secret keyring file (secring.gpg) to the new keystore dir (private-keys-v1.d). I use a VCS to track what is being modified inside my $GNUPGHOME. After signing a file with my sign subkey I noticed that the private key file of the sign subkey was modified. Why? What happens? I expected that my private key and subkeys were immutable files in the keystore. * C laudio F loreani_ * -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Sun Mar 10 20:04:50 2019 From: wk at gnupg.org (Werner Koch) Date: Sun, 10 Mar 2019 20:04:50 +0100 Subject: Questions about finding keys used to encrypt files with gpg In-Reply-To: (mattia codato's message of "Sat, 9 Mar 2019 17:52:46 +0000") References: Message-ID: <878sxm5z59.fsf@wheatstone.g10code.de> On Sat, 9 Mar 2019 17:52, mattia.codato at poste.it said: > I noticed that the gpg -d [filename] command works out without asking > me for the passphrase, so after a brief search i became aware of the > fact that gpg uses public/private keys encrypting, combined with a Right public key cryptography is the main use case of gpg. However you used plain symmetric encryption (-c) which requires that sender and recipient share one key. The behavior you noticed when decrypting your own symmetric encrypted message is that gpg remembers the passphrase used for symmetric encryption as long as the cache does not expire or you restart gpg-agent. If you would have sent the message to someone else that other party would be asked for the passphrase. To disable this, sometimes surprising, caching of passphrases for symmetric encryption, you can use the option --no-symkey-cache with gpg. > As far as i know, in order to succesfully export and decrypt the files > in other computers, one must export and restore the original key pairs > used to encrypt the original files. So what should i do to figure it > out what kind of keys were used ? Please read a one of the howtos or the README of gpg to learn about the basic use. In short: 1. Create a key pair: gpg --gen-key Which creates the keyblock (certificate) including a user id. You will be asked to protect the private part of the key with a passphrase, so that a stolen computer will not immediately lead to a compromise of your private key. You are not required to use a passphrase, though - the message will be strongly encrypted without a passphrase, the passphrase is pure local thing. 2. Export the public part of the key par gpg -a --export YOUR_USERID >pubkey.asc 3. Send the public key to the recipient by plain mail, courier etc. 4. Ask your peer to encrypt a message to you with gpg -ear YOURUSERID OUTFILE 5. After receiving that message you can use gpg -d PLAINTEXT You may always add -v to get some more info from gpg. There are may GUI frontends and mailers which don't require you to remember the above command. You may also want to look into distribution mechanisms for public keys (which are used to encrypt) like keyservers or the Web Key Directory. 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 Sun Mar 10 20:08:48 2019 From: wk at gnupg.org (Werner Koch) Date: Sun, 10 Mar 2019 20:08:48 +0100 Subject: Keys in the keystore dir (private-keys-v1.d/) are being modified In-Reply-To: (Claudio Floreani's message of "Sun, 10 Mar 2019 15:54:45 +0100") References: Message-ID: <874l8a5yyn.fsf@wheatstone.g10code.de> On Sun, 10 Mar 2019 15:54, claudio.floreani at gmail.com said: > After signing a file with my sign subkey I noticed that the private key > file of the sign subkey was modified. Why? What happens? To speed up the migration and to not annoy you by asking for your passphrase for each private key, GnuPG defers a part of the migration to the time when you have to enter the passphrase anyway. This is what happened here. Please be aware that future versions of GnuPG _may_ update the file with the private key to record certain meta data. 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 Sun Mar 10 20:18:21 2019 From: wk at gnupg.org (Werner Koch) Date: Sun, 10 Mar 2019 20:18:21 +0100 Subject: user id question In-Reply-To: <36208424.20190310145112@my_localhost_LG> (MFPA's message of "Sun, 10 Mar 2019 14:51:12 +0000") References: <997697746.20190223153457@my_localhost_LG> <1b3e599f-22f1-dd18-3349-949c2afb5ff0@mail.com> <87imwt93yo.fsf@wheatstone.g10code.de> <36208424.20190310145112@my_localhost_LG> Message-ID: <87zhq24jya.fsf@wheatstone.g10code.de> On Sun, 10 Mar 2019 14:51, 2017-r3sgs86x8e-lists-groups at riseup.net said: > Is "nerdy" good or bad in this context? That is really up to you. Often it is fun to be a nerd. To the OP: I have done keysigning for about 25 years but meanwhile I don't think that the Web of Trust is a good idea to make encryption for the masses really easy. Also it is often more a game than serious operational security. In particular if it comes to the pretty German of scheme of it which sometimes demands two government issued identity documents and so on. That is in stark contrast to the grassroots origin of PGP and its tendency not to trust the government. For a small closed group the Web of Trust used to work well, though. 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 Sun Mar 10 20:29:14 2019 From: wk at gnupg.org (Werner Koch) Date: Sun, 10 Mar 2019 20:29:14 +0100 Subject: Multiple dev one signing key In-Reply-To: <1d5eea4b-d96f-af4f-6055-aa73c43a13d1@mail.com> (john doe's message of "Fri, 8 Mar 2019 20:05:53 +0100") References: <1d5eea4b-d96f-af4f-6055-aa73c43a13d1@mail.com> Message-ID: <87va0q4jg5.fsf@wheatstone.g10code.de> On Fri, 8 Mar 2019 20:05, johndoe65534 at mail.com said: > What is the best way forward? > - One signing key accessible on the release system I'd say depends on the release system. In most cases this is a networked box and I would hesitate to do this. Using gpg --with a remote gpg-agent would be an option, though. > - Eatch dev having a copy of the key to be able to sign a release That is what we do in GnuPG. We have a few core developers which carry a key and that set of key is distributed with each gpg release and also via other channels. We also demand that the keys are all smartcard based and thus a remote key compromise would need physical access. Well, a developer could be tricked into sign a bad release bu tat leas this would not compromise the widely distributed key. We often add a second signature to a release. For example, I sign many of the releases and when Niibe-san then sends me his signature for the same tarball I then append that signature to mine [1]. This is also the reasons why you often notice changed signature file (you can simply concatenate detached signatures). For a small group this works really well, but for a larger group the system Konstantin describes in his mail is better up to the task. Shalom-Salam, Werner [1] Using gnupg/build-aux/append-signature.sh -- 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 Sun Mar 10 20:31:34 2019 From: wk at gnupg.org (Werner Koch) Date: Sun, 10 Mar 2019 20:31:34 +0100 Subject: PGP Anonymous Board Idea In-Reply-To: <87d0n1rsij.fsf@ra.horus-it.com> (Ralph Seichter's message of "Fri, 08 Mar 2019 22:00:20 +0100") References: <20190305193937.GA17996@pc.farhan.codes> <87y35sc55u.fsf@ra.horus-it.com> <5f593c91ed8747e7e1749f52870c41c7@none.at> <87zhq6wwy6.fsf@ra.horus-it.com> <20190308192432.5159228b@iria.my-fqdn.de> <87d0n1rsij.fsf@ra.horus-it.com> Message-ID: <87r2be4jc9.fsf@wheatstone.g10code.de> On Fri, 8 Mar 2019 22:00, abbot at monksofcool.net said: > a) We're moving ever further off topic in terms of GnuPG. FWIW, given the low traffic on gnupg-users, I would consider this still to on topic. 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 Sun Mar 10 20:39:16 2019 From: wk at gnupg.org (Werner Koch) Date: Sun, 10 Mar 2019 20:39:16 +0100 Subject: Default trust-model TOFU In-Reply-To: <8736nxut06.fsf_-_@iki.fi> (Teemu Likonen's message of "Fri, 08 Mar 2019 20:21:29 +0200") References: <997697746.20190223153457@my_localhost_LG> <1b3e599f-22f1-dd18-3349-949c2afb5ff0@mail.com> <87imwt93yo.fsf@wheatstone.g10code.de> <8736nxut06.fsf_-_@iki.fi> Message-ID: <87mum24izf.fsf@wheatstone.g10code.de> On Fri, 8 Mar 2019 20:21, tlikonen at iki.fi said: > have plans for that, to set the default trust model to "tofu" or > "tofu+pgp"? I am still not convinced that the UI as implemented on the command line is better that what we have now. It looks more complicated than what one would expect under TOFU. The tracking of all signature verification and thus decryption operations in a local database does not feel right. It has been implemented to avoid counting signature several times which would give a wrong picture of the key usage patterns over time. I would like to address these two problems first. 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 johndoe65534 at mail.com Mon Mar 11 12:43:27 2019 From: johndoe65534 at mail.com (john doe) Date: Mon, 11 Mar 2019 12:43:27 +0100 Subject: Multiple dev one signing key In-Reply-To: <87va0q4jg5.fsf@wheatstone.g10code.de> References: <1d5eea4b-d96f-af4f-6055-aa73c43a13d1@mail.com> <87va0q4jg5.fsf@wheatstone.g10code.de> Message-ID: <99904263-adc8-4732-63a1-294966e9e660@mail.com> On 3/10/2019 8:29 PM, Werner Koch wrote: > On Fri, 8 Mar 2019 20:05, johndoe65534 at mail.com said: > >> What is the best way forward? >> - One signing key accessible on the release system > > I'd say depends on the release system. In most cases this is a > networked box and I would hesitate to do this. Using gpg --with a > remote gpg-agent would be an option, though. > Looks like this approach is out of the question, we are scattered around the world without knowing eatch other in real life! :) >> - Eatch dev having a copy of the key to be able to sign a release > > That is what we do in GnuPG. We have a few core developers which carry > a key and that set of key is distributed with each gpg release and also > via other channels. We also demand that the keys are all smartcard based > and thus a remote key compromise would need physical access. Well, a > developer could be tricked into sign a bad release bu tat leas this > would not compromise the widely distributed key. > > We often add a second signature to a release. For example, I sign many > of the releases and when Niibe-san then sends me his signature for the > same tarball I then append that signature to mine [1]. This is also the > reasons why you often notice changed signature file (you can simply > concatenate detached signatures). For a small group this works really > well, but for a larger group the system Konstantin describes in his mail > is better up to the task. > Just to be clear, you Werner will sign everything that needs to be signed for a release with your personal key. As an extra layer of security Niibe will also sign the release and send you the detacht signature. Is that correct or what am I missing? Thank you Werner for your input, along with Werner's input I'd also like to thank the below two for their input: Daniel Kahn Gillmor Konstantin Ryabitsev -- John Doe From wk at gnupg.org Mon Mar 11 15:21:49 2019 From: wk at gnupg.org (Werner Koch) Date: Mon, 11 Mar 2019 15:21:49 +0100 Subject: Multiple dev one signing key In-Reply-To: <99904263-adc8-4732-63a1-294966e9e660@mail.com> (john doe's message of "Mon, 11 Mar 2019 12:43:27 +0100") References: <1d5eea4b-d96f-af4f-6055-aa73c43a13d1@mail.com> <87va0q4jg5.fsf@wheatstone.g10code.de> <99904263-adc8-4732-63a1-294966e9e660@mail.com> Message-ID: <87y35l1og2.fsf@wheatstone.g10code.de> On Mon, 11 Mar 2019 12:43, johndoe65534 at mail.com said: > Just to be clear, you Werner will sign everything that needs to be > signed for a release with your personal key. In practise that is the case. However, anyone of our small group can sign releases and also update the online list of current version numbers. > As an extra layer of security Niibe will also sign the release and send > you the detacht signature. One signature is actually sufficient but for users of the Web of Trust a second signature might a difference to some. 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 lists at boyandin.info Mon Mar 11 16:55:12 2019 From: lists at boyandin.info (Konstantin Boyandin) Date: 11 Mar 2019 11:55:12 -0400 Subject: Several GnuPG instances, with their corresponding agents In-Reply-To: <20190310145028.esqym2frovohhyvx@aurora.local.incenp.org> References: <355d4b5a-6620-4b1a-90af-498d7b2e788f@mtasv.net> <20190310145028.esqym2frovohhyvx@aurora.local.incenp.org> Message-ID: <7dc64ce4-2365-484f-a843-6613ae6395f5@mtasv.net> Hi Damien, On 10.03.2019 21:50, Damien Goutte-Gattat writes: > On Sun, Mar 10, 2019 at 01:25:41AM -0500, Konstantin Boyandin wrote: >> Question: how do I keep several GnuPG versions installed, every >> version with its own gpg-agent? > > A Gpg-agent is tied to a specific home directory (as specified in the > GNUPGHOME environment variable or through the --homedir option of gpg), > so all you have to is to make sure you use a separate home directory for > each version you want to use. > > For example, assuming you have installed version X of GnuPG under > $HOME/myprogs/gnupg-X, create a directory to use as the home directory > for that version (say, $HOME/gnupg-homes/X), then you can start using > that version by running the following: > > PATH=$HOME/myprogs/gnupg-X/bin:$PATH > export GNUPGHOME=$HOME/gnupg-homes/X > $SHELL -i > > You'll start a new shell in which all GnuPG invocations will use the > binaries from the X version and the keyrings and other associated files > from the indicated home directory. Simply exit that shell to use again > your system-provided GnuPG in the normal home directory. Thanks for the pieces of advice, I'll try that shortly. I'd also like to share the same keys among all 2.2.* versions - I'll check how to do that with as little ado as possible. Sincerely, Konstantin From seshadrigupta.sreeram at external.fcagroup.com Mon Mar 11 18:54:27 2019 From: seshadrigupta.sreeram at external.fcagroup.com (Seshadrigupta Sreeram) Date: Mon, 11 Mar 2019 13:54:27 -0400 Subject: Issue with install version (gpg (GnuPG) 2.0.30) Message-ID: Dear Community, We recently installed gpg (GnuPG) 2.0.30 on AIX 7.1 and we are having issues with decryption with the below error message. *Error*: cli007payd04:/global/site/vendor/psoft/payqa/user/inbound/DASHBOARDANYWHERE/ARCHIVING $ gpg2 --decrypt DCXSUBKIOSIUHRY.2018-11-09-16.15.05.000000 Warning: using insecure memory! You need a passphrase to unlock the secret key for user: "PeopleSoft Payroll (File Validation) " 2048-bit ELG key, ID ECC0069D, created 2004-06-25 (main key ID 0CD363B0) exec(): 0509-036 Cannot load program gpg-agent_64 because of the following errors: 0509-130 Symbol resolution failed for gpg-agent_64 because: 0509-136 Symbol _GLOBAL__AIXI_libpth_so (number 188) is not exported from dependent module /usr/lib/libpth.a[libpth.so.20]. 0509-136 Symbol _GLOBAL__AIXD_libpth_so (number 189) is not exported from dependent module /usr/lib/libpth.a[libpth.so.20]. 0509-192 Examine .loader section symbols with the 'dump -Tv' command. gpg: can't connect to the agent: End of file gpg: problem with the agent: No agent running *GPG Version:* cli007payd04:/global/site/vendor/psoft/payqa/user/scripts/validation $ gpg2 --version gpg (GnuPG) 2.0.30 libgcrypt 1.5.4 Copyright (C) 2015 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: ~/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 Encryption works fine and we have the issue only while decryption. Thanks in advance!! *Regards,SreeramPeopleSoft Platform TeamITM ? 3rd Floor, 3S2 E2(O) 248-838-6328 , (M) 248-909-6138, T-line 821-6328Email:- ss2621 at chrysler.com * -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnupg-users at spodhuis.org Mon Mar 11 20:56:37 2019 From: gnupg-users at spodhuis.org (Phil Pennock) Date: Mon, 11 Mar 2019 15:56:37 -0400 Subject: Several GnuPG instances, with their corresponding agents In-Reply-To: <355d4b5a-6620-4b1a-90af-498d7b2e788f@mtasv.net> References: <355d4b5a-6620-4b1a-90af-498d7b2e788f@mtasv.net> Message-ID: <20190311195636.GA30544@osmium.pennocktech.home.arpa> On 2019-03-10 at 01:25 -0500, Konstantin Boyandin via Gnupg-users wrote: > I would like to use, whenever I like, manually builds (such as current > 2.2.13). > > Question: how do I keep several GnuPG versions installed, every version > with its own gpg-agent? After running ./configure [--args], take a look at the generated `config.h` file. Some of these can't be easily overridden at configure time, but you can patch between configure and build. As to whether you break at the "directory" or "socket location" level ... remember that GnuPG regards the contents of the directory as its fiefdom and is free to move things around, often with auto-upgrade logic which might get in the way if you want to try to downgrade. Specifically, the defines which matter here are: GNUPG_DEFAULT_HOMEDIR anything ending _SOCK_NAME I recommend, if doing this, that you just change GNUPG_DEFAULT_HOMEDIR and do not try to share one config directory between multiple concurrently-installed versions of GnuPG. Myself, I install to /opt/gnupg/ and leave the homedir to the default. If a user account needs to use the newer GnuPG instead of the system one, it's the responsibility of that account to manage the directory. If one account is trying to use both system and current GnuPG, that's a logic error elsewhere which should be cleaned up. -Phil From lists at boyandin.info Tue Mar 12 05:57:36 2019 From: lists at boyandin.info (Konstantin Boyandin (lists)) Date: Tue, 12 Mar 2019 04:57:36 +0000 Subject: Several GnuPG instances, with their corresponding agents In-Reply-To: <20190311195636.GA30544@osmium.pennocktech.home.arpa> References: <355d4b5a-6620-4b1a-90af-498d7b2e788f@mtasv.net> <20190311195636.GA30544@osmium.pennocktech.home.arpa> Message-ID: <0fe4b5c996b22f0f95d031c785c808e4@boyandin.info> On 2019-03-11 19:56, Phil Pennock wrote: > On 2019-03-10 at 01:25 -0500, Konstantin Boyandin via Gnupg-users > wrote: >> I would like to use, whenever I like, manually builds (such as current >> 2.2.13). >> >> Question: how do I keep several GnuPG versions installed, every >> version >> with its own gpg-agent? > > After running ./configure [--args], take a look at the generated > `config.h` file. Some of these can't be easily overridden at configure > time, but you can patch between configure and build. > > As to whether you break at the "directory" or "socket location" level > ... remember that GnuPG regards the contents of the directory as its > fiefdom and is free to move things around, often with auto-upgrade > logic > which might get in the way if you want to try to downgrade. > > Specifically, the defines which matter here are: > GNUPG_DEFAULT_HOMEDIR > anything ending _SOCK_NAME > > I recommend, if doing this, that you just change GNUPG_DEFAULT_HOMEDIR > and do not try to share one config directory between multiple > concurrently-installed versions of GnuPG. > > Myself, I install to /opt/gnupg/ and leave the homedir to the default. > If a user account needs to use the newer GnuPG instead of the system > one, it's the responsibility of that account to manage the directory. > If one account is trying to use both system and current GnuPG, that's a > logic error elsewhere which should be cleaned up. Thanks for the pieces of advice. I conclude that the only safe way to share same keys is to re-import all the keys manually into every corresponding GnuPG version's key ring. To me, there's nothing wrong in using different versions of GnuPG under the same account: system-wide applications using the OS-provided version, and in separated environment I can run newer version, if I need its specific features. As soon as they have everything separated, agents sockets included, I see no possible problems. Sincerely, Konstantin From claudio.floreani at gmail.com Tue Mar 12 15:33:11 2019 From: claudio.floreani at gmail.com (Claudio Floreani) Date: Tue, 12 Mar 2019 15:33:11 +0100 Subject: Keys in the keystore dir (private-keys-v1.d/) are being modified In-Reply-To: <874l8a5yyn.fsf@wheatstone.g10code.de> References: <874l8a5yyn.fsf@wheatstone.g10code.de> Message-ID: Il giorno dom 10 mar 2019 alle ore 20:10 Werner Koch ha scritto: > On Sun, 10 Mar 2019 15:54, claudio.floreani at gmail.com said: > > > After signing a file with my sign subkey I noticed that the private key > > file of the sign subkey was modified. Why? What happens? > > To speed up the migration and to not annoy you by asking for your > passphrase for each private key, GnuPG defers a part of the migration to > the time when you have to enter the passphrase anyway. This is what > happened here. > Thank you Werner. So, if I understood it correctly, this should happen only once for each key, the first time it is being used. Am I correct? Are there any discussion or extended comments about what is deferred during the migration, without having to scrabble around the source code? In particular, I am interested in knowing 1) whether the "partially migrated" keys have the same level of security of the "fully migrated" keys or not 2) if also the private master key have to be used before being fully migrated. Please be aware that future versions of GnuPG _may_ update the file with > the private key to record certain meta data. > If I may ask, do you think it will be a good idea to update metadata inside the private keys? I feel much more comfortable if my private keys do never change, so that I can just compare their checksum or ask the VCS in order to know that they have not been tampered. Sacrificing this assurance to have some less or more useful metadata stored inside them, just doesn't seem worth the benefits. What I expected was that the agent could decrypt the keys in volatile memory and then just discard them after they have been used, instead of full rewrite the keys in the persistent memory (a mobile storage, in my case), which in turn adds a (tiny) security risk factor. This arguments seems even more convincing considering that the metadata associated with the keys could as well be written (encrypted or not it depends on the kind of metadata) in a separate file. Ciao, Claudio -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkbryant at gmail.com Wed Mar 13 09:03:31 2019 From: dkbryant at gmail.com (Dan Bryant) Date: Wed, 13 Mar 2019 03:03:31 -0500 Subject: Can I use my Microsoft Outlook S/MIME certificate with gpgsm.exe ? Message-ID: So I work for a large company that has their own internal CA and maintains their own set of S/MIME certificates. We periodically have to re-enroll in S/MIME and import the certificate into Microsoft Outlook to have encrypt / sign functionality. This time when I enrolled for my recent certificate, I went ahead and added my S/MIME to gpgsm. Import looked good (I guess), but I'm unable to sign. I've looked at the public and private keys and it looks like the whole chain is imported. Kleopatra also has them showing up in the right hierarchical order. I apologize for clipping some of my command output but our company is rather paranoid about publicly publishing internal key data, even public key data. $ gpgsm --version --verbose gpgsm (GnuPG) 2.2.11 libgcrypt 1.8.4 libksba 1.3.5 $ gpgsm --import sMIME.pfx gpgsm: total number processed: 4 gpgsm: unchanged: 3 gpgsm: secret keys read: 1 gpgsm: secret keys unchanged: 1 $ echo hi | gpgsm --sign --armor --default-key 0x64208E9A --disable-crl-checks --disable-policy-checks gpgsm: error creating signature: No value From bouncingcats at gmail.com Wed Mar 13 14:21:58 2019 From: bouncingcats at gmail.com (David) Date: Thu, 14 Mar 2019 00:21:58 +1100 Subject: Newbie: Installing Build Dependencies to gnupg-2.2.13 update from gnupg 2.0.22 on Ubuntu 14.04 LTS failed In-Reply-To: <7b714f10ef400a5959c47d2dcb760372@spindel.tax> References: <1141de1a-14fd-4f6b-3786-a531908cc762@xiala.net> <7b714f10ef400a5959c47d2dcb760372@spindel.tax> Message-ID: On Wed, 27 Feb 2019 at 23:16, Oscar Carlsson via Gnupg-users wrote: > > And in future emails, try to [...] use pastebin like > services and/or attach logs instead of adding them inline like this. Why is that suggested? If someone posts hundreds of kilobytes or more, I agree, but in this case I argue the opposite, for these reasons. Providing the information inline has several advantages: 1) all information is available in one place. 2) it's easy to quote/reference in email replies. 3) it's less work for the responders who don't have to cut and paste from other places. 4) it avoids running pastebin javascript. 5) it preserves the integrity of the email archive, so that the conversation can help future readers, particularly when pastebin sites are ephemeral and/or provide only temporary storage. 6) some mailing lists strip attachments. From peter at digitalbrains.com Wed Mar 13 18:24:41 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 13 Mar 2019 18:24:41 +0100 Subject: Newbie: Installing Build Dependencies to gnupg-2.2.13 update from gnupg 2.0.22 on Ubuntu 14.04 LTS failed In-Reply-To: References: <1141de1a-14fd-4f6b-3786-a531908cc762@xiala.net> <7b714f10ef400a5959c47d2dcb760372@spindel.tax> Message-ID: <2628cacf-1cfc-7b59-8f89-62ff18329386@digitalbrains.com> On 13/03/2019 14:21, David wrote: > If someone posts hundreds of kilobytes or more, I agree, > but in this case I argue the opposite, for these reasons. I fully agree. In fact, I much prefer someone include a lot of information and maybe include too much than that the person trying to help has to ask for more information. The one thing that would have made the mail even better was if shell output was put between markers like this: --8<---------------cut here---------------start------------->8--- Terminal contents --8<---------------cut here---------------end--------------->8--- Some mail clients auto-format this, which makes the e-mail more readable, but even without special formatting it helps a /lot/ with the flow. > 4) it avoids running pastebin javascript. In fact, Werner refuses to look at pastes on sites that require JavaScript. That means you lose out on the expertise of the person who knows the most about GnuPG! :-) 7) This is an FSF mailing list. Solely relying on libre services is much preferred in any case. Suggesting people use non-free software quickly ends up in the "not allowed here" territory! Back on topic, I /do/ completely agree with Oscar Carlsson that it is rather futile to compile stuff for an OS that will be unsupported in a few weeks. Running an unsupported OS should not be done in almost every instance. Running security software like GnuPG on an unsupported OS is an enormous red flag and defeats the purpose of GnuPG IMNSHO. My 2 cents, Peter. PS: I found it ironic that the person admonishing someone to be concise was the one who forgot to trim the quotes per list rules :-P. This is tongue in cheek and should not be taken seriously. -- 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 wk at gnupg.org Thu Mar 14 14:17:30 2019 From: wk at gnupg.org (Werner Koch) Date: Thu, 14 Mar 2019 14:17:30 +0100 Subject: Can I use my Microsoft Outlook S/MIME certificate with gpgsm.exe ? In-Reply-To: (Dan Bryant's message of "Wed, 13 Mar 2019 03:03:31 -0500") References: Message-ID: <875zslzjbp.fsf@wheatstone.g10code.de> On Wed, 13 Mar 2019 03:03, dkbryant at gmail.com said: > $ echo hi | gpgsm --sign --armor --default-key 0x64208E9A > --disable-crl-checks --disable-policy-checks > gpgsm: error creating signature: No value Please always add -v or --verbose to the invocation if you run into problems. This gives more diagnostics. For gpgsm I would also suggest to add --audit-log alog.txt which prints some infos about the certificate etc. to the given file. Are you sure that the root certificate of your organization as been imported? Use gpgsm --list-chain 0x64208E9A to check this. You can add --with-validation in which case gpgsm does all checks it would do before signing or encrypting. Note that ECC certificates are not yet supported. 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 dkbryant at gmail.com Thu Mar 14 23:20:03 2019 From: dkbryant at gmail.com (Dan Bryant) Date: Thu, 14 Mar 2019 17:20:03 -0500 Subject: Can I use my Microsoft Outlook S/MIME certificate with gpgsm.exe ? In-Reply-To: <875zslzjbp.fsf@wheatstone.g10code.de> References: <875zslzjbp.fsf@wheatstone.g10code.de> Message-ID: Thanks, I checked the following per your advice 1. Are any of the certs ECC? No, they all appear to be RSA keys. 2. Has the org root cert been imported? I believe so, yes. There are three certs in the chain. My s/MIME cert, it's parent, and its "grandparent". Both gpgsm and the Windows Cert Manager show only three certs in the chain. The same three certs that show up in Windows Cert Manager show up in gpgsm. When I listed the cert chain with validation I got a lot of CRL errors. I tried to import the CRLs listed in the certs, but it appeared to fail. I will also not that I have not added any LDAP servers. I would prefer to be able to do the signing "offline" when I'm not on my corporate network. I also don't think my company will allow me to store password data in cleartext in the dirmngr_ldapservers.conf file. If there is anyway to encrypt this data with a master password, that would be prefered. Here's a list of commands I tried to hopefully shed some light on my config $ gpgsm --verbose --with-validation --list-chain 0x64208E9A [REDACTED]\AppData\Roaming\gnupg\pubring.kbx --------------------------------------------------- ID: 0x64208E9A Certified by ID: 0x2731A14E Certified by ID: 0x0B9BC7C1 wc -l "[REDACTED]\AppData\Roaming\gnupg\dirmngr_ldapservers.conf" 0 [REDACTED]\AppData\Roaming\gnupg\dirmngr_ldapservers.conf $ gpgsm -a --export 0x64208E9A | openssl x509 -text | grep -i http URI:[REDACTED-0x64208E9A-CRL] OCSP - URI:[REDACTED-0x64208E9A-OCSP] CPS: [REDACTED-0x64208E9A-CPS] $ gpgsm -a --export 0x2731A14E | openssl x509 -text | grep -i http $ gpgsm -a --export 0x0B9BC7C1 | openssl x509 -text | grep -i http OCSP - URI:[REDACTED-0x0B9BC7C1-OCSP] CPS: [REDACTED-0x0B9BC7C1-CSP] Explicit Text: [REDACTED-0x0B9BC7C1-ETXT] URI:[REDACTED-0x0B9BC7C1-CRL] $ dirmgr --verbose --fetch-crl [REDACTED-0x0B9BC7C1-CRL] dirmngr[76084]: permanently loaded certificates: 253 dirmngr[76084]: runtime cached certificates: 0 dirmngr[76084]: trusted certificates: 253 (252,0,0,1) dirmngr[76084]: update times of this CRL: this=20190226T000000 next=20190324T235959 dirmngr[76084]: locating CRL issuer certificate by authorityKeyIdentifier dirmngr[76084]: error checking validity of CRL issuer certificate: No value dirmngr[76084]: crl_parse_insert failed: No value dirmngr[76084]: processing CRL from '[REDACTED-0x0B9BC7C1-CRL]' failed: No value $ dirmgr --verbose --fetch-crl [REDACTED-0x64208E9A-CRL] dirmngr[75900]: permanently loaded certificates: 253 dirmngr[75900]: runtime cached certificates: 0 dirmngr[75900]: trusted certificates: 253 (252,0,0,1) dirmngr[75900]: update times of this CRL: this=20190314T170848 next=20190317T170848 dirmngr[75900]: locating CRL issuer certificate by authorityKeyIdentifier dirmngr[75900]: Note: non-critical certificate policy not allowed dirmngr[75900]: error checking validity of CRL issuer certificate: No value dirmngr[75900]: crl_parse_insert failed: No value dirmngr[75900]: processing CRL from '[REDACTED-0x64208E9A-CRL]' failed: No value $ gpgsm --verbose --with-validation --list-chain 0x64208E9A [REDACTED]\AppData\Roaming\gnupg\pubring.kbx --------------------------------------------------- ID: 0x64208E9A S/N: [REDACTED] Issuer: [REDACTED] Subject: [REDACTED] aka: [REDACTED] validity: [REDACTED] key type: 2048 bit RSA key usage: digitalSignature keyEncipherment ext key usage: emailProtection policies: 2.16.840.1.113733.1.7.23.2:N: fingerprint: [REDACTED] [Note: non-critical certificate policy not allowed] [checking the CRL failed: No value] [certificate is bad: No value] Certified by ID: 0x2731A14E S/N: [REDACTED] Issuer: [REDACTED] Subject: [REDACTED] validity: [REDACTED] key type: 2048 bit RSA key usage: certSign crlSign policies: 2.16.840.1.113733.1.7.23.2:N: chain length: 0 fingerprint: [REDACTED] [Note: non-critical certificate policy not allowed] [certificate is bad: No value] Certified by ID: 0x0B9BC7C1 S/N: [REDACTED] Issuer: [REDACTED] Subject: [REDACTED] validity: [REDACTED] key type: 2048 bit RSA chain length: none fingerprint: [REDACTED] [certificate is bad: No value] $ echo hi | gpgsm --sign --armor --default-key 0x64208E9A \ > --disable-crl-checks --disable-policy-checks --verbose \ > --audit-log alog.txt gpgsm: certificate is good gpgsm: validation model used: shell gpgsm: error creating signature: No value $ cat alog.txt * Data signing succeeded: No * Data available: No * Gpg-Agent usable: Yes On Thu, Mar 14, 2019 at 8:20 AM Werner Koch wrote: > > On Wed, 13 Mar 2019 03:03, dkbryant at gmail.com said: > > > $ echo hi | gpgsm --sign --armor --default-key 0x64208E9A > > --disable-crl-checks --disable-policy-checks > > gpgsm: error creating signature: No value > > Please always add -v or --verbose to the invocation if you run into > problems. This gives more diagnostics. For gpgsm I would also suggest > to add > > --audit-log alog.txt > > which prints some infos about the certificate etc. to the given file. > > Are you sure that the root certificate of your organization as been > imported? Use > > gpgsm --list-chain 0x64208E9A > > to check this. You can add --with-validation in which case gpgsm does > all checks it would do before signing or encrypting. > > Note that ECC certificates are not yet supported. > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > -----BEGIN PGP SIGNATURE----- > > iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCXIpUagAKCRD/gK6dHew1 > jcfbAQDejK+gexZxO/4IZNBO7LvvUo5c1m7W89QHEubOCiK6pAD+O9gWjkejwM/r > 3EkthGX3+yoet57UBe6BpCAOz0unWwc= > =R8FP > -----END PGP SIGNATURE----- From kara_da at xiala.net Fri Mar 15 20:26:59 2019 From: kara_da at xiala.net (Daniel) Date: Fri, 15 Mar 2019 20:26:59 +0100 Subject: Newbie: Installing Build Dependencies to gnupg-2.2.13 update from gnupg 2.0.22 on Ubuntu 14.04 LTS failed In-Reply-To: <2628cacf-1cfc-7b59-8f89-62ff18329386@digitalbrains.com> References: <1141de1a-14fd-4f6b-3786-a531908cc762@xiala.net> <7b714f10ef400a5959c47d2dcb760372@spindel.tax> <2628cacf-1cfc-7b59-8f89-62ff18329386@digitalbrains.com> Message-ID: <81ebc5cf-7b65-1cc1-9fff-faa4d5de7605@xiala.net> On 13.03.19 18:24, Peter Lebbing wrote: > On 13/03/2019 14:21, David wrote: >> If someone posts hundreds of kilobytes or more, I agree, >> but in this case I argue the opposite, for these reasons. > I fully agree. In fact, I much prefer someone include a lot of > information and maybe include too much than that the person trying to > help has to ask for more information. The one thing that would have made > the mail even better was if shell output was put between markers like > this: > > --8<---------------cut here---------------start------------->8--- > Terminal contents > --8<---------------cut here---------------end--------------->8--- > > Some mail clients auto-format this, which makes the e-mail more > readable, but even without special formatting it helps a /lot/ with the > flow. > >> 4) it avoids running pastebin javascript. > In fact, Werner refuses to look at pastes on sites that require > JavaScript. That means you lose out on the expertise of the person who > knows the most about GnuPG! :-) > > 7) This is an FSF mailing list. Solely relying on libre services is much > preferred in any case. Suggesting people use non-free software quickly > ends up in the "not allowed here" territory! > > Back on topic, I /do/ completely agree with Oscar Carlsson that it is > rather futile to compile stuff for an OS that will be unsupported in a > few weeks. Running an unsupported OS should not be done in almost every > instance. Running security software like GnuPG on an unsupported OS is > an enormous red flag and defeats the purpose of GnuPG IMNSHO. > > My 2 cents, > > Peter. > > PS: I found it ironic that the person admonishing someone to be concise > was the one who forgot to trim the quotes per list rules :-P. This is > tongue in cheek and should not be taken seriously. > > ----------------------------------- Dear Peter, dear Dave Much thanks for your advice regarding my post, as well as your insight on the breached security issues using an unsupported OS. If I may ask you again how your input was meant dear Peter, I should add code inline in the future like so(?): --8<---------------cut here---------------start------------->8--- dm at dm-ThinkPad-X240:/boot$ sudo apt-get autoremove linux-image-3.13.0-96-generic Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: linux-image-3.13.0-96-generic linux-image-extra-3.13.0-96-generic linux-signed-image-3.13.0-96-generic 0 upgraded, 0 newly installed, 3 to remove and 4 not upgraded. After this operation, 195 MB disk space will be freed. Do you want to continue? [Y/n] --8<---------------cut here---------------end--------------->8--- Again thank you for your reply, you've all been very helpful and I appreciate it greatly. Sincerely, daniel > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -- pgp fingerprint: 02EF 1CA4 A4FB 0F12 76CA BC08 B678 C658 9B03 AB5E -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at digitalbrains.com Fri Mar 15 20:35:02 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 15 Mar 2019 20:35:02 +0100 Subject: (OT) Formatting mails to this list In-Reply-To: <81ebc5cf-7b65-1cc1-9fff-faa4d5de7605@xiala.net> References: <1141de1a-14fd-4f6b-3786-a531908cc762@xiala.net> <7b714f10ef400a5959c47d2dcb760372@spindel.tax> <2628cacf-1cfc-7b59-8f89-62ff18329386@digitalbrains.com> <81ebc5cf-7b65-1cc1-9fff-faa4d5de7605@xiala.net> Message-ID: <42a5bc47-3899-18f1-b77f-2c5d8e791004@digitalbrains.com> On 15/03/2019 20:26, Daniel wrote: > If I may ask you again how your input was meant dear Peter, I should > add code inline in the future like so(?): > > --8<---------------cut here---------------start------------->8--- > dm at dm-ThinkPad-X240:/boot$ sudo apt-get autoremove linux-image-3.13.0-96-generic > Reading package lists... Done > Building dependency tree > Reading state information... Done > The following packages will be REMOVED: > linux-image-3.13.0-96-generic linux-image-extra-3.13.0-96-generic > linux-signed-image-3.13.0-96-generic > 0 upgraded, 0 newly installed, 3 to remove and 4 not upgraded. > After this operation, 195 MB disk space will be freed. > Do you want to continue? [Y/n] > --8<---------------cut here---------------end--------------->8--- Yes, that's exactly what I meant :-). That makes it easier on the eyes to distinguish where prose is and where shell output is. And when you reply to e-mails, please strip qoutes to the minimum necessary to provide context. It's a mailing list, so anyone wanting to read what the previous e-mail said can simply do so in the original mail. Quoting is only to provide context what you are replying to. Thanks! Peter. -- 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 bex at pobox.com Fri Mar 15 23:28:55 2019 From: bex at pobox.com (Brian Exelbierd) Date: Fri, 15 Mar 2019 18:28:55 -0400 Subject: Identifying one of multiple authentication subkeys Message-ID: Hi, I would like to eliminate my SSH keys and consolidate my existing keys into my gpg key. I can do this by either importing my existing keys (easier) or creating new authentication subkeys. Either way, I am unsure how to identify which subkey is which SSH key. I created a test key, below, with two authentication subkeys. I can't tell which subkey matches each key. How do you know? Without this knowledge it is hard to know which key goes with which server and which key is safe to delete later. Any advice? Thank you. regards, bex --- # gpg2 -K --with-keygrip /root/.gnupg/pubring.kbx ------------------------ sec rsa2048 2019-03-15 [SC] [expires: 2021-03-14] 84B9177ECD98386DACDA102DF80B5DDF8D55076A Keygrip = 13C8D80A6B3A5A7CC4095A254A07AFC9F287CF16 uid [ultimate] keyname ssb rsa2048 2019-03-15 [E] [expires: 2021-03-14] Keygrip = 26FD3D7D54BEE12111354B9E968C23EEDC445A4E ssb rsa2048 2019-03-15 [A] Keygrip = A04EA628443B5C1C60411C15E1EC35C21186D405 ssb rsa2048 2019-03-15 [A] Keygrip = 45F02D545B6B6ADC32FCB7BC64B943F23B35D3FF # ssh-add -l 2048 SHA256:T/SZUtqVEzoo4c4rmh5e4jrnCd5ewGNj1Nrsg3VYbCE (none) (RSA) 2048 SHA256:+Qbn7T5rQms4+bBfzc7D68H2TynS/8gyT0pjrMOaiQA (none) (RSA) # ssh-add -L ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC8vnk7hPdP9tWdw8DUV8rOYDTAlhbvSWPuEUwr0FdaveJoJtgYhceKVoyFnOYZnZ8QP0nAytHGeSAHkL/9Vw0Whyouu94awwoEERdkIzvl/KVRU3n0dBabbjbqlY6Dz+4zjIUo/KbyZ9PZHohCVQs/DzFUqnLsPoHzVVDBPvMHFkf0t2qSe0Pv2I7vLmI1UVBFMspjy80kmoijheFAmXebCGC3uzr23BKqzqfj2/HYv/DJAQufGiHsH+/I855U8Dckd4TQmHS4aRsIY0px1HA4of9nIiWWifvqxwshax2VSdJucJi1RB6YbSxbTIbjnl0YJbbIajV8xJjyloaOofph (none) ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCnrIe/fe6i6AMA+evGzz3Gc56rSH5D3cJ9R/cMta2jHjtNlZZD/uJNdbuALsI4elB5m0Yxsbiz0j3UG2L/2nHfjD73oPQkwFIacvtkZT/hpp/BWPFDWQnGaWeWdFfsxlzu6gOMsfYJQDxNIPRjLbYkcIOL3Xw5EIFlS2xEr+/ZGsD2uNnReXj5XZnXh6FrxcX7vhnKpHHsVzDZG+xRs+xhErhiini8J1REZaQzZnVftD/WZGbAU8f3LSDfSCFQVxRTibXW5JMd6JfFe1zZXST+JfAEqg5LhucpzsQAbYWtNiqZ5McerI1HYPjYNUqoYhGzXsWvEuvPp3qugVjH3ZI5 (none) From johndoe65534 at mail.com Sat Mar 16 09:22:52 2019 From: johndoe65534 at mail.com (john doe) Date: Sat, 16 Mar 2019 09:22:52 +0100 Subject: Identifying one of multiple authentication subkeys In-Reply-To: References: Message-ID: <4c3f50fe-1125-e9e7-6d11-b4916132ca77@mail.com> On 3/15/2019 11:28 PM, Brian Exelbierd wrote: > Hi, > > I would like to eliminate my SSH keys and consolidate my existing keys into my gpg key. I can do this by either importing my existing keys (easier) or creating new authentication subkeys. > > Either way, I am unsure how to identify which subkey is which SSH key. I created a test key, below, with two authentication subkeys. I can't tell which subkey matches each key. How do you know? Without this knowledge it is hard to know which key goes with which server and which key is safe to delete later. > > Any advice? Thank you. > > regards, > > bex > > --- > > # gpg2 -K --with-keygrip > /root/.gnupg/pubring.kbx > ------------------------ > sec rsa2048 2019-03-15 [SC] [expires: 2021-03-14] > 84B9177ECD98386DACDA102DF80B5DDF8D55076A > Keygrip = 13C8D80A6B3A5A7CC4095A254A07AFC9F287CF16 > uid [ultimate] keyname > ssb rsa2048 2019-03-15 [E] [expires: 2021-03-14] > Keygrip = 26FD3D7D54BEE12111354B9E968C23EEDC445A4E > ssb rsa2048 2019-03-15 [A] > Keygrip = A04EA628443B5C1C60411C15E1EC35C21186D405 > ssb rsa2048 2019-03-15 [A] > Keygrip = 45F02D545B6B6ADC32FCB7BC64B943F23B35D3FF > > # ssh-add -l > 2048 SHA256:T/SZUtqVEzoo4c4rmh5e4jrnCd5ewGNj1Nrsg3VYbCE (none) (RSA) > 2048 SHA256:+Qbn7T5rQms4+bBfzc7D68H2TynS/8gyT0pjrMOaiQA (none) (RSA) > > # ssh-add -L > ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC8vnk7hPdP9tWdw8DUV8rOYDTAlhbvSWPuEUwr0FdaveJoJtgYhceKVoyFnOYZnZ8QP0nAytHGeSAHkL/9Vw0Whyouu94awwoEERdkIzvl/KVRU3n0dBabbjbqlY6Dz+4zjIUo/KbyZ9PZHohCVQs/DzFUqnLsPoHzVVDBPvMHFkf0t2qSe0Pv2I7vLmI1UVBFMspjy80kmoijheFAmXebCGC3uzr23BKqzqfj2/HYv/DJAQufGiHsH+/I855U8Dckd4TQmHS4aRsIY0px1HA4of9nIiWWifvqxwshax2VSdJucJi1RB6YbSxbTIbjnl0YJbbIajV8xJjyloaOofph (none) > ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCnrIe/fe6i6AMA+evGzz3Gc56rSH5D3cJ9R/cMta2jHjtNlZZD/uJNdbuALsI4elB5m0Yxsbiz0j3UG2L/2nHfjD73oPQkwFIacvtkZT/hpp/BWPFDWQnGaWeWdFfsxlzu6gOMsfYJQDxNIPRjLbYkcIOL3Xw5EIFlS2xEr+/ZGsD2uNnReXj5XZnXh6FrxcX7vhnKpHHsVzDZG+xRs+xhErhiini8J1REZaQzZnVftD/WZGbAU8f3LSDfSCFQVxRTibXW5JMd6JfFe1zZXST+JfAEqg5LhucpzsQAbYWtNiqZ5McerI1HYPjYNUqoYhGzXsWvEuvPp3qugVjH3ZI5 (none) > My understanding is that one subkey is to be used for authentication . -- John Doe From wolfgang.traylor at posteo.de Sat Mar 16 11:11:34 2019 From: wolfgang.traylor at posteo.de (Wolfgang Traylor) Date: Sat, 16 Mar 2019 10:11:34 +0000 Subject: Identifying one of multiple authentication subkeys In-Reply-To: References: Message-ID: <20190316101131.5ev5corfvu7h4b2k@gruenfink> > I am unsure how to identify which subkey is which SSH key. You can export your GPG subkey for SSH and compare with the `ssh-add -L` output: $ gpg2 --export-ssh-key This gives you the SSH-formatted subkey which will match one of your lines from `ssh-add -L`. Note that the comments (anything after the first whitespace in each line) might be different. So compare only up to the first whitespace. Best regards, W. Traylor From peter at digitalbrains.com Sat Mar 16 11:11:57 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 16 Mar 2019 11:11:57 +0100 Subject: Identifying one of multiple authentication subkeys In-Reply-To: References: Message-ID: <20d02c69-3c9b-5798-b4ef-67f642b1e523@digitalbrains.com> Hi Brian, On 15/03/2019 23:28, Brian Exelbierd wrote:> Hi, > Either way, I am unsure how to identify which subkey is which SSH key. Provided the auth keys are in your .gnupg/sshcontrol file, the following will help: --8<---------------cut here---------------start------------->8--- $ ssh-add -L | head -1 >firstkey $ ssh-keygen -l -E md5 -f firstkey 2048 MD5:69:22:fd:08:4e:a5:77:c5:2c:1c:c5:e4:e3:e0:96:96 /home/peter/.ssh/id_rsa (RSA) $ gpg-connect-agent > help keyinfo # KEYINFO [--[ssh-]list] [--data] [--ssh-fpr] [--with-ssh] # # Return information about the key specified by the KEYGRIP. If the # key is not available GPG_ERR_NOT_FOUND is returned. If the option # --list is given the keygrip is ignored and information about all # available keys are returned. If --ssh-list is given information # about all keys listed in the sshcontrol are returned. With --with-ssh # information from sshcontrol is always added to the info. Unless --data # is given, the information is returned as a status line using the format: # # KEYINFO # # KEYGRIP is the keygrip. # # TYPE is describes the type of the key: # 'D' - Regular key stored on disk, # 'T' - Key is stored on a smartcard (token), # 'X' - Unknown type, # '-' - Key is missing. # # SERIALNO is an ASCII string with the serial number of the # smartcard. If the serial number is not known a single # dash '-' is used instead. # # IDSTR is the IDSTR used to distinguish keys on a smartcard. If it # is not known a dash is used instead. # # CACHED is 1 if the passphrase for the key was found in the key cache. # If not, a '-' is used instead. # # PROTECTION describes the key protection type: # 'P' - The key is protected with a passphrase, # 'C' - The key is not protected, # '-' - Unknown protection. # # FPR returns the formatted ssh-style fingerprint of the key. It is only # printed if the option --ssh-fpr has been used. It defaults to '-'. # # TTL is the TTL in seconds for that key or '-' if n/a. # # FLAGS is a word consisting of one-letter flags: # 'D' - The key has been disabled, # 'S' - The key is listed in sshcontrol (requires --with-ssh), # 'c' - Use of the key needs to be confirmed, # '-' - No flags given. # # More information may be added in the future. OK > keyinfo --ssh-list --ssh-fpr S KEYINFO ECBEA361DD2230F79F086E3CAE198EB94A0CE6CF D - - - P 69:22:fd:08:4e:a5:77:c5:2c:1c:c5:e4:e3:e0:96:96 - S S KEYINFO 64711FCE432F5387CCDD5E466513387B63096989 D - - - P c1:34:c6:23:f7:d5:64:fb:49:7a:d3:53:db:d1:87:64 - S OK > --8<---------------cut here---------------end--------------->8--- ssh-add was used to export the first key in the agent to a file. ssh-keygen can produce an MD5 fingerprint for that file for you. You can match the MD5 fingerprint to the 7th field of KEYINFO. Then the 1st field will give you the keygrip of that SSH key. If your auth keys are for some reason not in sshcontrol, you could use --8<---------------cut here---------------start------------->8--- $ gpg-connect-agent 'KEYINFO --list --ssh-fpr' /bye | fgrep 69:22:fd:08:4e:a5:77:c5:2c:1c:c5:e4:e3:e0:96:96 S KEYINFO ECBEA361DD2230F79F086E3CAE198EB94A0CE6CF D - - - P 69:22:fd:08:4e:a5:77:c5:2c:1c:c5:e4:e3:e0:96:96 - - --8<---------------cut here---------------end--------------->8--- because it wouldn't be much fun wading through all your keys if you have a lot of key material, and that command without the grep will list it all. (By the way, as you can see in the ssh-keygen output, my key actually has a comment field in the gpg-agent. It was imported from an on-disk OpenSSH file, that's where it came from. I don't know a way to have a comment field for a key generated with gpg, although I could probably hack it in in the private key store. Let's not do that.) HTH, Peter. PS: I see no reason why you shouldn't have multiple auth subkeys, unlike John Doe. -- 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 peter at digitalbrains.com Sat Mar 16 11:39:49 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 16 Mar 2019 11:39:49 +0100 Subject: Identifying one of multiple authentication subkeys In-Reply-To: <20190316101131.5ev5corfvu7h4b2k@gruenfink> References: <20190316101131.5ev5corfvu7h4b2k@gruenfink> Message-ID: On 16/03/2019 11:11, Wolfgang Traylor wrote: > $ gpg2 --export-ssh-key Actually, if you want a specific subkey, you need to append a ! to the key ID (probably need to quote it as well for the shell, \! ). Otherwise, GnuPG will use key selection rules to take the latest authentication subkey from the certificate selected. It's a fine and simple method. The advantage of my method is it will also work with keys that aren't part of an OpenPGP key :-). Plus it's more fun. HTH, Peter. -- 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 dirk.gottschalk1980 at googlemail.com Sat Mar 16 14:22:46 2019 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Sat, 16 Mar 2019 14:22:46 +0100 Subject: Identifying one of multiple authentication subkeys In-Reply-To: <20d02c69-3c9b-5798-b4ef-67f642b1e523@digitalbrains.com> References: <20d02c69-3c9b-5798-b4ef-67f642b1e523@digitalbrains.com> Message-ID: Hi. Am Samstag, den 16.03.2019, 11:11 +0100 schrieb Peter Lebbing: > (By the way, as you can see in the ssh-keygen output, my key actually > has a comment field in the gpg-agent. It was imported from an on-disk > OpenSSH file, that's where it came from. I don't know a way to have a > comment field for a key generated with gpg, although I could probably > hack it in in the private key store. Let's not do that.) In the output from --export-ssh-key is also a comment field. This fieldd, in my case shows: openpgp:0xF852DAEE This should be enough to identify the key. It is the short ID of the referred authentication subkey. Regards, Dirk -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen, Germany GPG: 4AAB BDA8 C34D 3037 DA6B 7DF9 BB6A A254 DF10 8952 Keybase.io: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- 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 peter at digitalbrains.com Sat Mar 16 14:42:49 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 16 Mar 2019 14:42:49 +0100 Subject: Identifying one of multiple authentication subkeys In-Reply-To: References: <20d02c69-3c9b-5798-b4ef-67f642b1e523@digitalbrains.com> Message-ID: <4d254950-b9cb-8b9d-dcc8-326e6ccd092a@digitalbrains.com> Hi, On 16/03/2019 14:22, Dirk Gottschalk wrote: > In the output from --export-ssh-key is also a comment field. This > fieldd, in my case shows: openpgp:0xF852DAEE Yes, but it is only added by the --export-ssh-key command and has a fixed form. Instead, for my keys, which by the way are not part of an OpenPGP certificate and therefore can't be used with --export-ssh-key, they are stored with the private key. The comment got there because they were originally OpenSSH keys with that comment, and the comment got retained on import into the agent. I could have put any comment whatsoever in it and it would have been stored by the agent and shown on any invocation of ssh-add -{l,L}. --8<---------------cut here---------------start------------->8--- $ ssh-add -l [...] 256 SHA256:xb01Ehdlix7o5oLN0YUEkhr70yZDXXCNXcMoNS48PB0 Just a comment (ED25519) --8<---------------cut here---------------end--------------->8--- HTH, Peter. -- 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 bex at pobox.com Sun Mar 17 12:45:13 2019 From: bex at pobox.com (Brian Exelbierd) Date: Sun, 17 Mar 2019 07:45:13 -0400 Subject: Identifying one of multiple authentication subkeys In-Reply-To: <20d02c69-3c9b-5798-b4ef-67f642b1e523@digitalbrains.com> References: <20d02c69-3c9b-5798-b4ef-67f642b1e523@digitalbrains.com> Message-ID: On Sat, Mar 16, 2019, at 11:12 AM, Peter Lebbing wrote: > Hi Brian, > > On 15/03/2019 23:28, Brian Exelbierd wrote:> Hi, > > Either way, I am unsure how to identify which subkey is which SSH key. > > Provided the auth keys are in your .gnupg/sshcontrol file, the following > will help: > > --8<---------------cut here---------------start------------->8--- > $ ssh-add -L | head -1 >firstkey > > $ ssh-keygen -l -E md5 -f firstkey > 2048 MD5:69:22:fd:08:4e:a5:77:c5:2c:1c:c5:e4:e3:e0:96:96 > /home/peter/.ssh/id_rsa (RSA) > > $ gpg-connect-agent > > help keyinfo > # KEYINFO [--[ssh-]list] [--data] [--ssh-fpr] [--with-ssh] > # > # Return information about the key specified by the KEYGRIP. If the > # key is not available GPG_ERR_NOT_FOUND is returned. If the option > # --list is given the keygrip is ignored and information about all > # available keys are returned. If --ssh-list is given information > # about all keys listed in the sshcontrol are returned. With --with-ssh > # information from sshcontrol is always added to the info. Unless --data > # is given, the information is returned as a status line using the format: > # > # KEYINFO > # > # KEYGRIP is the keygrip. > # > # TYPE is describes the type of the key: > # 'D' - Regular key stored on disk, > # 'T' - Key is stored on a smartcard (token), > # 'X' - Unknown type, > # '-' - Key is missing. > # > # SERIALNO is an ASCII string with the serial number of the > # smartcard. If the serial number is not known a single > # dash '-' is used instead. > # > # IDSTR is the IDSTR used to distinguish keys on a smartcard. If it > # is not known a dash is used instead. > # > # CACHED is 1 if the passphrase for the key was found in the key cache. > # If not, a '-' is used instead. > # > # PROTECTION describes the key protection type: > # 'P' - The key is protected with a passphrase, > # 'C' - The key is not protected, > # '-' - Unknown protection. > # > # FPR returns the formatted ssh-style fingerprint of the key. It is only > # printed if the option --ssh-fpr has been used. It defaults to '-'. > # > # TTL is the TTL in seconds for that key or '-' if n/a. > # > # FLAGS is a word consisting of one-letter flags: > # 'D' - The key has been disabled, > # 'S' - The key is listed in sshcontrol (requires --with-ssh), > # 'c' - Use of the key needs to be confirmed, > # '-' - No flags given. > # > # More information may be added in the future. > OK > > keyinfo --ssh-list --ssh-fpr > S KEYINFO ECBEA361DD2230F79F086E3CAE198EB94A0CE6CF D - - - P > 69:22:fd:08:4e:a5:77:c5:2c:1c:c5:e4:e3:e0:96:96 - S > S KEYINFO 64711FCE432F5387CCDD5E466513387B63096989 D - - - P > c1:34:c6:23:f7:d5:64:fb:49:7a:d3:53:db:d1:87:64 - S > OK > > > --8<---------------cut here---------------end--------------->8--- > > ssh-add was used to export the first key in the agent to a file. > ssh-keygen can produce an MD5 fingerprint for that file for you. > > You can match the MD5 fingerprint to the 7th field of KEYINFO. Then the > 1st field will give you the keygrip of that SSH key. > > If your auth keys are for some reason not in sshcontrol, you could use > > --8<---------------cut here---------------start------------->8--- > $ gpg-connect-agent 'KEYINFO --list --ssh-fpr' /bye | fgrep > 69:22:fd:08:4e:a5:77:c5:2c:1c:c5:e4:e3:e0:96:96 > S KEYINFO ECBEA361DD2230F79F086E3CAE198EB94A0CE6CF D - - - P > 69:22:fd:08:4e:a5:77:c5:2c:1c:c5:e4:e3:e0:96:96 - - > --8<---------------cut here---------------end--------------->8--- > > because it wouldn't be much fun wading through all your keys if you have > a lot of key material, and that command without the grep will list it all. This worked and will allow me to associate the keygrips with the old identify file names for my own bookkeeping/sanity. This way as a project terminates, so can its key. > (By the way, as you can see in the ssh-keygen output, my key actually > has a comment field in the gpg-agent. It was imported from an on-disk > OpenSSH file, that's where it came from. I don't know a way to have a > comment field for a key generated with gpg, although I could probably > hack it in in the private key store. Let's not do that.) I think having the ability to name or associate metadata here is a nice-to-have for those of us managing multiple auth subkeys. That said, I have a new problem of course :D There is no longer an identityfile to use in the .ssh/config file which means all auth keys are tried with all hosts. I have multiple auth keys and the hosts give up after 2 or 3 failures. How can I get the right key served to the right host since SSH doesn't know how to ask for it anymore ... regards, bex PS: This should possibly be a new thread, however, there are so few discussions of multiple auth-subkeys I feel like a searcher is likely to wind up here first. > > HTH, > > Peter. > > PS: I see no reason why you shouldn't have multiple auth subkeys, unlike > John Doe. > > -- > 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 > > > Attachments: > * signature.asc From peter at digitalbrains.com Sun Mar 17 13:12:29 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 17 Mar 2019 13:12:29 +0100 Subject: Identifying one of multiple authentication subkeys In-Reply-To: References: <20d02c69-3c9b-5798-b4ef-67f642b1e523@digitalbrains.com> Message-ID: <66f709b2-b59d-9100-bcec-a5202d0d9268@digitalbrains.com> On 17/03/2019 12:45, Brian Exelbierd wrote: > There is no longer an identityfile to use in the .ssh/config file > which means all auth keys are tried with all hosts. I have multiple > auth keys and the hosts give up after 2 or 3 failures. How can I get > the right key served to the right host since SSH doesn't know how to > ask for it anymore ... Ooohhh. I would have hoped the OpenSSH server's MaxAuthTries would only count failed signatures, not failed key matches. But I can reproduce this problem. Picking an auth key is a two-step process. First the client offers different public keys until the server says it accepts one. Only then is authentication tried with the key that was just negotiated. But indeed, MaxAuthTries counts every *offer* as an auth try and cuts out after 6 in the default configuration. --8<---------------cut here---------------start------------->8--- $ ssh -v [...] [...] debug1: Next authentication method: publickey debug1: Offering ED25519 public key: /home/peter/.ssh/id_ed25519 debug1: Authentications that can continue: publickey debug1: Offering RSA public key: /home/peter/.ssh/id_rsa debug1: Authentications that can continue: publickey debug1: Offering ED25519 public key: Just a comment debug1: Authentications that can continue: publickey debug1: Offering ED25519 public key: Testkey 1 debug1: Authentications that can continue: publickey debug1: Offering ED25519 public key: Testkey 2 debug1: Authentications that can continue: publickey debug1: Offering ED25519 public key: Testkey 3 Received disconnect from ::1 port 22:2: Too many authentication failures Authentication failed. --8<---------------cut here---------------end--------------->8--- I don't know a satisfactory solution to this. Peter. PS: Could you please trim your quotes when you reply on the mailing list? -- 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 bex at pobox.com Sun Mar 17 13:17:43 2019 From: bex at pobox.com (Brian Exelbierd) Date: Sun, 17 Mar 2019 08:17:43 -0400 Subject: Identifying one of multiple authentication subkeys In-Reply-To: <66f709b2-b59d-9100-bcec-a5202d0d9268@digitalbrains.com> References: <20d02c69-3c9b-5798-b4ef-67f642b1e523@digitalbrains.com> <66f709b2-b59d-9100-bcec-a5202d0d9268@digitalbrains.com> Message-ID: <5d2bca1a-c7e0-4760-a15b-c88eff1b0fa4@www.fastmail.com> On Sun, Mar 17, 2019, at 1:12 PM, Peter Lebbing wrote: > On 17/03/2019 12:45, Brian Exelbierd wrote: > > There is no longer an identityfile to use in the .ssh/config file > > which means all auth keys are tried with all hosts. I have multiple > > auth keys and the hosts give up after 2 or 3 failures. How can I get > > the right key served to the right host since SSH doesn't know how to > > ask for it anymore ... > > Ooohhh. I would have hoped the OpenSSH server's MaxAuthTries would only > count failed signatures, not failed key matches. But I can reproduce > this problem. > > I don't know a satisfactory solution to this. Having done no code examination, I feel like this is where the identity information for subkeys comes into play. I presume the SSH request would pass the value of the identity file to the gpg-agent. This is probably 100% wrong though/ Also, as an aside. It appears that subkeys do not prompt for the key passphrase. Instead I just get an allow/deny dialog or no dialog at all if I don't force confirm. > PS: Could you please trim your quotes when you reply on the mailing > list? Happily - and I should have last time. Distracting myself with GPG/SSH while doing taxes is a bad idea and leads to bad internet hygiene :D regards, bex From peter at digitalbrains.com Sun Mar 17 13:40:15 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 17 Mar 2019 13:40:15 +0100 Subject: Identifying one of multiple authentication subkeys In-Reply-To: <5d2bca1a-c7e0-4760-a15b-c88eff1b0fa4@www.fastmail.com> References: <20d02c69-3c9b-5798-b4ef-67f642b1e523@digitalbrains.com> <66f709b2-b59d-9100-bcec-a5202d0d9268@digitalbrains.com> <5d2bca1a-c7e0-4760-a15b-c88eff1b0fa4@www.fastmail.com> Message-ID: <846cbf6a-9bea-4ad8-fafa-40963a394624@digitalbrains.com> On 17/03/2019 13:17, Brian Exelbierd wrote: > Having done no code examination, I feel like this is where the > identity information for subkeys comes into play. I presume the SSH > request would pass the value of the identity file to the gpg-agent. > This is probably 100% wrong though/ 30% wrong? It actually is "the wire encoding of the public key", so key material rather than a filename. Your comment made a click in my mind though. I've solved it. Put this in .ssh/config: --8<---------------cut here---------------start------------->8--- Host your-server.com IdentitiesOnly yes IdentityFile ~/.ssh/testkey7.pub --8<---------------cut here---------------end--------------->8--- Where testkey7.pub is a file containing the *public* key. Usually you would use a private key here, but OpenSSH is just as happy with a public key as long as the agent can do the private operation. > Also, as an aside. It appears that subkeys do not prompt for the key > passphrase. Instead I just get an allow/deny dialog or no dialog at > all if I don't force confirm. The passphrase is cached. The duration can be controlled through default-cache-ttl-ssh and max-cache-ttl-ssh in ~/.gnupg/gpg-agent.conf or on a per-key basis in sshcontrol. It is possible to turn off caching for SSH keys completely. See "man gpg-agent". > Distracting myself with GPG/SSH while doing taxes is a bad idea and > leads to bad internet hygiene :D Hehehe :-D HTH, Peter. -- 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 t-rai at umin.ac.jp Mon Mar 18 05:25:06 2019 From: t-rai at umin.ac.jp (Tetsuji Rai) Date: Mon, 18 Mar 2019 13:25:06 +0900 Subject: gpg-agent of gpg 2.2.13 seems to pass wrong passphrase Message-ID: <91b16db1-4349-e01c-dfb2-dc34b93b65f3@umin.ac.jp> Hi, I'm using gnupg 2.2.13 and 1.4.23 on Fedora 29 on gnome desktop on two computers.? Usually, I use 2.2.13. On one desktop, gpg-2.2.13 works perfectly.??? However on the other one, gpg-agent seems to work wrong.?? It doesn't seem to pass the passphrase entered to gpg2 properly.?? So I cannot decode files encrypted with an error "Bad passphrase".?? But on the console, without gpg-agent, gpg2 can receive the passphrase correctly and decode encrypted files. So I want to know how this can be avoided, or how I can see if the passphrase is passed from gpg-agent to gpg2. Best regards, -Tetsuji From t-rai at umin.ac.jp Mon Mar 18 06:13:08 2019 From: t-rai at umin.ac.jp (Tetsuji Rai) Date: Mon, 18 Mar 2019 14:13:08 +0900 Subject: gpg-agent of gpg 2.2.13 seems to pass wrong passphrase In-Reply-To: <91b16db1-4349-e01c-dfb2-dc34b93b65f3@umin.ac.jp> References: <91b16db1-4349-e01c-dfb2-dc34b93b65f3@umin.ac.jp> Message-ID: On 3/18/19 1:25 PM, Tetsuji Rai wrote: > Hi, > > I'm using gnupg 2.2.13 and 1.4.23 on Fedora 29 on gnome desktop on two > computers.? Usually, I use 2.2.13. > > On one desktop, gpg-2.2.13 works perfectly.??? However on the other one, > gpg-agent seems to work wrong.?? It doesn't seem to pass the passphrase > entered to gpg2 properly.?? So I cannot decode files encrypted with an > error "Bad passphrase".?? But on the console, without gpg-agent, gpg2 > can receive the passphrase correctly and decode encrypted files. > > So I want to know how this can be avoided, or how I can see if the > passphrase is passed from gpg-agent to gpg2. > > Best regards, > > -Tetsuji > Hi, Self-reply. I found the solution after launching gpg-agent with --debug-level advance option.?? In a nutshell, gpg-agent doesn't seems to support Xwayland.?? It works with Xorg, but not with Xwayland.?? So I changed /etc/gdm/custom.conf so that gdm always launches Xorg instead of Xwayland and the problem has gone. Thank you!! -Tetsuji From ml-gnupg-xix.iii at linuxwan.net Mon Mar 18 14:09:41 2019 From: ml-gnupg-xix.iii at linuxwan.net (Ted Cooper) Date: Mon, 18 Mar 2019 23:09:41 +1000 Subject: Hostname of key server pool disappeared? hkps.pool.sks-keyservers.net Message-ID: Howdy, If there is a more appropriate place to post this please do let me know. Methods of contact and persons responsible for the sks-keyservers infrastructure is not obvious. Onto the problem; The hostname hkps.pool.sks-keyservers.net appears to have been pulled, and now returns NXDOMAIN. It's even return NSEC records to prove it's NXDOMAIN. keys.gnupg.net is just a CNAME for hkps.pool.sks-keyservers.net. This host appears to be the default for GNUpg configs. Other hostnames (pools) in the pool.sks-keyservers.net domain are still functional. The status page for sks-keyservers.net shows no hosts are currently available via hkps but other ports are available. https://sks-keyservers.net/status/ Is there some kind of maintenance happening, or has something broken? Is there a news post somewhere that the service will be pulled? Ted. From gnupg-users at spodhuis.org Tue Mar 19 04:33:39 2019 From: gnupg-users at spodhuis.org (Phil Pennock) Date: Mon, 18 Mar 2019 23:33:39 -0400 Subject: Hostname of key server pool disappeared? hkps.pool.sks-keyservers.net In-Reply-To: References: Message-ID: <20190319033338.GA66867@osmium.pennocktech.home.arpa> On 2019-03-18 at 23:09 +1000, Ted Cooper wrote: > If there is a more appropriate place to post this please do let me know. > Methods of contact and persons responsible for the sks-keyservers > infrastructure is not obvious. Onto the problem; The SKS Devel mailing-list is also used for Operations issues. > The hostname hkps.pool.sks-keyservers.net appears to have been pulled, > and now returns NXDOMAIN. It's even return NSEC records to prove it's > NXDOMAIN. https://lists.nongnu.org/archive/html/sks-devel/2019-03/msg00060.html It appears that CRL expiration led to all HKPS hosts failing verification so they all dropped out of the pool. -Phil From wk at gnupg.org Tue Mar 19 08:18:43 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 19 Mar 2019 08:18:43 +0100 Subject: Hostname of key server pool disappeared? hkps.pool.sks-keyservers.net In-Reply-To: (Ted Cooper's message of "Mon, 18 Mar 2019 23:09:41 +1000") References: Message-ID: <87va0f49ik.fsf@wheatstone.g10code.de> On Mon, 18 Mar 2019 23:09, ml-gnupg-xix.iii at linuxwan.net said: > keys.gnupg.net is just a CNAME for hkps.pool.sks-keyservers.net. This > host appears to be the default for GNUpg configs. FWIW, keys.gnupg.net is a hardcoded alias in dirmngr since 2.2.7 and thus the CNAME is not used since that version of GnuPG. For details see https://dev.gnupg.org/T3755 or the code snippet below. Shalom-Salam, Werner --8<---------------cut here---------------start------------->8--- /* We used to have DNS CNAME redirection from the URLs below to * sks-keyserver pools. The idea was to allow for a quick way to * switch to a different set of pools. The problem with that * approach is that TLS needs to verify the hostname and - because * DNS is not secured - it can only check the user supplied hostname * and not a hostname from a CNAME RR. Thus the final servers all * need to have certificates with the actual pool name as well as * for keys.gnupg.net - that would render the advantage of * keys.gnupg.net useless and so we better give up on this. Because * the keys.gnupg.net URL are still in widespread use we do a static * mapping here. */ if (!strcmp (uri, "hkps://keys.gnupg.net") || !strcmp (uri, "keys.gnupg.net")) uri = "hkps://hkps.pool.sks-keyservers.net"; else if (!strcmp (uri, "https://keys.gnupg.net")) uri = "https://hkps.pool.sks-keyservers.net"; else if (!strcmp (uri, "hkp://keys.gnupg.net")) uri = "hkp://hkps.pool.sks-keyservers.net"; else if (!strcmp (uri, "http://keys.gnupg.net")) uri = "http://hkps.pool.sks-keyservers.net"; else if (!strcmp (uri, "hkps://http-keys.gnupg.net") || !strcmp (uri, "http-keys.gnupg.net")) uri = "hkps://ha.pool.sks-keyservers.net"; else if (!strcmp (uri, "https://http-keys.gnupg.net")) uri = "https://ha.pool.sks-keyservers.net"; else if (!strcmp (uri, "hkp://http-keys.gnupg.net")) uri = "hkp://ha.pool.sks-keyservers.net"; else if (!strcmp (uri, "http://http-keys.gnupg.net")) uri = "http://ha.pool.sks-keyservers.net"; --8<---------------cut here---------------end--------------->8--- -- 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 Mar 19 12:28:25 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 19 Mar 2019 12:28:25 +0100 Subject: [Announce] GnuPG 2.2.14 released Message-ID: <87bm273xye.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: version 2.2.14. This is a maintenance release; see below for a list of fixed bugs. About GnuPG =========== The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation of the OpenPGP and S/MIME standards. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. The separate library GPGME provides a uniform API to use the GnuPG engine by software written in common programming languages. A wealth of frontend applications and libraries making use of GnuPG are available. As an universal crypto engine GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Noteworthy changes in version 2.2.14 ==================================== * gpg: Allow import of PGP desktop exported secret keys. Also avoid importing secret keys if the secret keyblock is not valid. [#4392] * gpg: Do not error out on version 5 keys in the local keyring. * gpg: Make invalid primary key algo obvious in key listings. * sm: Do not mark a certificate in a key listing as de-vs compliant if its use for a signature will not be possible. * sm: Fix certificate creation with key on card. * sm: Create rsa3072 bit certificates by default. * sm: Print Yubikey attestation extensions with --dump-cert. * agent: Fix cancellation handling for scdaemon. * agent: Support --mode=ssh option for CLEAR_PASSPHRASE. [#4340] * scd: Fix flushing of the CA-FPR DOs in app-openpgp. * scd: Avoid a conflict error with the "undefined" app. * dirmngr: Add CSRF protection exception for protonmail. * dirmngr: Fix build problems with gcc 9 in libdns. * gpgconf: New option --show-socket for use wity --launch. * gpgtar: Make option -C work for archive creation. Release-info: https://dev.gnupg.org/T4412 Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.2.14 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.14.tar.bz2 (6550k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.14.tar.bz2.sig An installer for Windows without any graphical frontend except for a very minimal Pinentry tool is available here: https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.14_20190319.exe (4077k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.14_20190319.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.2.14.tar.bz2 you would use this command: gpg --verify gnupg-2.2.14.tar.bz2.sig gnupg-2.2.14.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See the end of this mail for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.2.14.tar.bz2, you run the command like this: sha1sum gnupg-2.2.14.tar.bz2 and check that the output matches the next line: f349c20e7498af88299b0d42a961e0364e5c37e7 gnupg-2.2.14.tar.bz2 d88b15f7625dcaa5d6991222bcf2c69be2b5a987 gnupg-w32-2.2.14_20190319.tar.xz a8f74358cab09b737b2f69c096072428e5ae2d9d gnupg-w32-2.2.14_20190319.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese (traditional and simplified), Czech, French, German, Japanese, Norwegian, Russian, and Ukrainian being almost completely translated. Documentation and Support ========================= If you used GnuPG in the past you should read the description of changes and new features at doc/whats-new-in-2.1.txt or online at https://gnupg.org/faq/whats-new-in-2.1.html The file gnupg.info has the complete reference manual of the system. Separate man pages are included as well but they miss some of the details available only in thee manual. The manual is also available online at https://gnupg.org/documentation/manuals/gnupg/ or can be downloaded as PDF at https://gnupg.org/documentation/manuals/gnupg.pdf . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. You may also want to search the GnuPG mailing list archives or ask on the gnupg-users mailing list for advise on how to solve problems. Most of the new features are around for several years and thus enough public experience is available. In case of build problems specific to this release please first check https://dev.gnupg.org/T4412 for updated information. Please consult the archive of the gnupg-users mailing list before reporting a bug: . We suggest to send bug reports for a new release to this list in favor of filing a bug at . If you need commercial support check out . If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== Maintenance and development of GnuPG is mostly financed by donations. The GnuPG project currently employs two full-time developers and one contractor. They all work exclusively on GnuPG and closely related software like Libgcrypt, GPGME and Gpg4win. We have to thank all the people who helped the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Many thanks to our numerous financial supporters, both corporate and individuals. Without you it would not be possible to keep GnuPG in a good shape and to address all the small and larger requests made by our users. Thanks. Happy hacking, Your GnuPG hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users'at'gnupg.org mailing list. p.p.s List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: rsa2048 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048 2014-10-29 [expires: 2020-10-30] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa3072 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) The keys are available at and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From jimpop at domainmail.org Tue Mar 19 17:42:10 2019 From: jimpop at domainmail.org (Jim Popovitch) Date: Tue, 19 Mar 2019 12:42:10 -0400 Subject: Hostname of key server pool disappeared? hkps.pool.sks-keyservers.net In-Reply-To: <87va0f49ik.fsf@wheatstone.g10code.de> References: <87va0f49ik.fsf@wheatstone.g10code.de> Message-ID: <1553013730.2409.3.camel@domainmail.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Tue, 2019-03-19 at 08:18 +0100, Werner Koch wrote: > On Mon, 18 Mar 2019 23:09, ml-gnupg-xix.iii at linuxwan.net said: > > > keys.gnupg.net is just a CNAME for hkps.pool.sks-keyservers.net. This > > host appears to be the default for GNUpg configs. > > FWIW, keys.gnupg.net is a hardcoded alias in dirmngr since 2.2.7 and > thus the CNAME is not used since that version of GnuPG. One of the issues with that is not supervising the alias you delegate power to. keys.gnupg.net (aka hkps.pool.sks-keyservers.net) only has servers in Europe. keys.gnupg.net has EDNS0 issues http://dnsviz.net/d/keys.gnupg.net/dnssec/ I do understand why someone decided to delegate keys.gnupg.net to someone else, but is that healthy for GnuPG? - -Jim P. -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEECPbAhaBWEfiXj/kxdRlcPb+1fkUFAlyRG+IACgkQdRlcPb+1 fkWieQ/+Nh849k2I7yLD6atD5TOTTXAzmVdGHYc8hz4Jn6Nrkr+Ppj11HheEg7n/ j1H+Y29yOtZcCrZn+0l475LPf8lzFF0zKyz3Y6kvaL4Z64LblKGewam1qLXBAuIv orxoNNb8Oj+Wu+GapKvCUfPyPav+ZVU2XG36NMTEdnzvxfsJKheMBmtytnQTthLt yOCHV17mV2gYcKCIbEllE7vFXER8tkHDP3uRvkQT+mB9vC/eEKQeOdguC4hCdMrx J2fYfYv8slyF8kVKUt8ot/CeBmiLFkw4Aw5hmxmR1J7VuwIYzLeSeSqLwFihXTkk ri7dYsfz7qcn1q/7mcQJEkiO0jR40iQOfLVJ/bUUD6R5RhqBwNfoXft59gKyHIeO bGA6Gvzky0C7emRTesfIOgBdfD1Q23+3GVnC7scEgQTCyEXVUXidhY8msSyC/eD6 5zuBKKKB7BewVvtgecJw+bu/O3e53gouxvkLeHS6c+Y9jV1l017EsGZHCO6OU4wU LUrdfYG/MOef6uJRk1kxHzDYiPsrH1DNyvKCCS4anoBaezIQfjubSrVPXGaJz+tB e+sXVwc1jI6xYeNFZv5Vb6ZmKQ3rmbbeNkkLXYuiUIwj2pe+V/rhaCFA/FwYZHU/ 1up8i9e2tHc64hjWO7D+hlHvbvOEegARQRno48NGWQXM9uXOppA= =pVXK -----END PGP SIGNATURE----- From wk at gnupg.org Wed Mar 20 11:39:32 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 20 Mar 2019 11:39:32 +0100 Subject: Hostname of key server pool disappeared? hkps.pool.sks-keyservers.net In-Reply-To: <1553013730.2409.3.camel@domainmail.org> (Jim Popovitch via Gnupg-users's message of "Tue, 19 Mar 2019 12:42:10 -0400") References: <87va0f49ik.fsf@wheatstone.g10code.de> <1553013730.2409.3.camel@domainmail.org> Message-ID: <874l7x3k4b.fsf@wheatstone.g10code.de> On Tue, 19 Mar 2019 12:42, gnupg-users at gnupg.org said: > I do understand why someone decided to delegate keys.gnupg.net to someone > else, but is that healthy for GnuPG? gnupg.{net,com,org,de} and gpg4win.{org,de} are all owned by my company g10 Code GmbH. whois unfortunately does not show that anymore (unfortunate fallout from the GDPR). 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 ggroenhoff at ggf-controls.de Fri Mar 22 23:46:22 2019 From: ggroenhoff at ggf-controls.de (Gert Groenhoff) Date: Fri, 22 Mar 2019 23:46:22 +0100 Subject: gpg: packet(3) with unknown version 7 Message-ID: <4a3ed6cf-03ce-5ae2-7878-c1a845f31096@ggf-controls.de> Hi, I changed to Kubuntu 18.04 and now I can't decrypt any longer a formerly with gpg2 symmetric encrypted file. I allways get "gpg: packet(3) with unknown version 7". With Kubuntu 16.04 I never had problems. I assume, they changed the gpg2. Has anyone an idea, how can I decrypt the file? It contains important data. Many Thanks Gert From bex at pobox.com Sat Mar 23 13:39:20 2019 From: bex at pobox.com (Brian Exelbierd) Date: Sat, 23 Mar 2019 08:39:20 -0400 Subject: Identifying one of multiple authentication subkeys In-Reply-To: <20d02c69-3c9b-5798-b4ef-67f642b1e523@digitalbrains.com> References: <20d02c69-3c9b-5798-b4ef-67f642b1e523@digitalbrains.com> Message-ID: <6b96902a-cf19-43ba-a2a6-31697195fc0d@www.fastmail.com> Hi Peter, Your help has been amazing and very useful. I was re-reading this answer and I noticed the comments below: On Sat, Mar 16, 2019, at 11:12 AM, Peter Lebbing wrote: > (By the way, as you can see in the ssh-keygen output, my key actually > has a comment field in the gpg-agent. It was imported from an on-disk > OpenSSH file, that's where it came from. How did you import this key? Monkeysphere's pem2opengpg only reads older formats that don't support comments. I didn't see anything about import from the newer formats in my searches. > I don't know a way to have a > comment field for a key generated with gpg, although I could probably > hack it in in the private key store. Let's not do that.) Should I open a feature request on this, or have you already done so? regards, bex From peter at digitalbrains.com Sat Mar 23 16:19:32 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 23 Mar 2019 16:19:32 +0100 Subject: Identifying one of multiple authentication subkeys In-Reply-To: <6b96902a-cf19-43ba-a2a6-31697195fc0d@www.fastmail.com> References: <20d02c69-3c9b-5798-b4ef-67f642b1e523@digitalbrains.com> <6b96902a-cf19-43ba-a2a6-31697195fc0d@www.fastmail.com> Message-ID: <5bfc24af-8b6e-a2ca-f61d-97c3409cb22b@digitalbrains.com> On 23/03/2019 13:39, Brian Exelbierd wrote: > How did you import this key? If your OpenSSH private key is .ssh/id_ed25519, and you are running gpg-agent as your SSH agent, it's a matter of: $ ssh-add ~/.ssh/id_ed25519 Any comment on the private key that was already there (presumably through ssh-keygen's -C option) will be saved in private-keys-v1.d. I don't use monkeysphere, I just maintain all authorized_keys files by hand. While I do have files with the public keys, often I'll just use ssh-add -L to get the public key I need to put in there. The point where stuff gets interesting is deleting SSH keys. For that I would use the method I outlined in this thread to get at the keygrip, because ssh-add -d doesn't work with gpg-agent. Well, not with the version in Debian stretch anyway, I reserve the right to be ignorant about features added since then. > Should I open a feature request on this, or have you already done so? I don't care enough to open a feature request. The development team's time is limited after all. HTH, Peter. -- 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 emvaldes at hotmail.com Fri Mar 22 19:32:45 2019 From: emvaldes at hotmail.com (eduardo) Date: Fri, 22 Mar 2019 11:32:45 -0700 (MST) Subject: Automated Batch Subkey Creation In-Reply-To: <9165039.3MGhes33ai@inno> References: <87ppf0rhsg.fsf@vigenere.g10code.de> <87wq97olon.fsf@vigenere.g10code.de> <9165039.3MGhes33ai@inno> Message-ID: <1553279565454-0.post@n7.nabble.com> Thanks for this bash-code. It's interesting how people ask if there is a need for automating something. The question should be "what should not be automated/scriptable" other than that, EVERYTHING must be scriptable. for some reason there is a gen-key, right? so, why not having one for gen-subkey? Nevertheless, thanks for the incredible work you guys have done and keep doing. Please, add a gen-subkey at some point. The use-case is to provision systems to end-users where a set of configurations allows the end-user to start working asap. There is not a fully automated setup as the passphrase will be asked to the end-user during the setup. The subkeys portion of this automation will allow the end-user to not having to deal with the "complicated" process (trust when others tell you that is "complicated" to them). Thanks. -- Sent from: http://gnupg.10057.n7.nabble.com/GnuPG-User-f3.html From cao at iimshillong.ac.in Sun Mar 24 08:53:51 2019 From: cao at iimshillong.ac.in (Chief Administrative Officer) Date: Sun, 24 Mar 2019 13:23:51 +0530 Subject: Error while using gpg with evolution on GhostBSD Message-ID: -----BEGIN PGP SIGNED MESSAGE-----Hash: SHA512Sir,I am using GhostBSD. On configuring evolution on GhostBSD and after installing the pgp, I get the following error while trying to sign the message with my keys"You may need to select different mail options.Detailed error: Output from gpg2:gpg: using subkey 61A41CB7B99E1DA1 instead of primary key 2B44A7D03BFC07B1gpg: writing to '-'gpg: pinentry launched (29261 tty 1.1.0 - cons25 unix:0.0)gpg: signing failed: Invalid IPC responsegpg: [stdin]: clear-sign failed: Invalid IPC response"Could you please help.Regards,P. P. KulkarniChief Administrative Office andSecretary to the BoG,IIM, Shillong,Meghalaya.-----BEGIN PGP SIGNATURE-----Version: Mailvelope v3.1.0Comment: https://www.mailvelope.comwsFcBAEBCgAGBQJclzdzAAoJEGGkHLe5nh2hIagQAJewAtT/+QO9MbLu27ZK5M6qtxYCuFFQkMR3B6ajRmXKfNsfvmwd2GCtIENALrAi6p3VyOJJV3Ef6xPaThIFzuh95q75jqlXfxS36uJimKOBby7dyb8pItKoYHroWC19q20TcMuaKmYkd2AKWqUz8okpeIisiV5Fvjjf6+5i7tj55WbTunUyPO+y+Q2ZLIhYSU6ZHN+zBz1AtQc8NRgvM3Fa/STJ61lO9d0QWr4VZ9DC6/fqNh2IcNrpWg5ZIXMSHqLbsLrKzJyWDbRJXGKYEiw8WuQu5+6svtXMcY+K2i0R2LWTt0VEOwTyKmEagWoH1pVOs1P6XoBapXCnjgeaK5lbKbpIVURWlL/4lxZ5kmZB2DULCIKp+JM+kLeMAcCc4fxRYpu8oJ28ioOoY2T9XWj/XCHKv7cXAz0kLTXXXECanlpUgiw8eNVuQ5OpvS0fqqkzrkNBBbxGnJ8AICIL7e07PLFkVOPKnElrrNb+0tyqZ7cyV2fe50lP3+qKL7fs4l7aT7uNNXJ9z762q5lnuF4Sk/PkT6WHXzs1va2dLrTQwyew5GXKO9WpIlGlS590fEqBPJWfDyJSOljFP799qaKaPZ4DLQo92+sNhoX9KRR5V2BuOB8DdX3Es6XWrIj9lxRZ5lFD8pknxITez3L+4+llajilkYzgoRrMzFfsP+MR=g2Q8-----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Mon Mar 25 15:45:21 2019 From: wk at gnupg.org (Werner Koch) Date: Mon, 25 Mar 2019 15:45:21 +0100 Subject: Identifying one of multiple authentication subkeys In-Reply-To: <5bfc24af-8b6e-a2ca-f61d-97c3409cb22b@digitalbrains.com> (Peter Lebbing's message of "Sat, 23 Mar 2019 16:19:32 +0100") References: <20d02c69-3c9b-5798-b4ef-67f642b1e523@digitalbrains.com> <6b96902a-cf19-43ba-a2a6-31697195fc0d@www.fastmail.com> <5bfc24af-8b6e-a2ca-f61d-97c3409cb22b@digitalbrains.com> Message-ID: <87d0mfvwqm.fsf@wheatstone.g10code.de> On Sat, 23 Mar 2019 16:19, peter at digitalbrains.com said: > because ssh-add -d doesn't work with gpg-agent. Well, not with the > version in Debian stretch anyway, I reserve the right to be ignorant That is on purpose: gpg-agent stores the key permanently and thus it makes no sense to add and remove it regularly. Do quickly disable a key, prefix its keygrip in ~/.gnupg/sshcontrol with an exclamation mark. A comment above each automatically added keygrip gives info about the 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 wk at gnupg.org Mon Mar 25 15:56:12 2019 From: wk at gnupg.org (Werner Koch) Date: Mon, 25 Mar 2019 15:56:12 +0100 Subject: gpg: packet(3) with unknown version 7 In-Reply-To: <4a3ed6cf-03ce-5ae2-7878-c1a845f31096@ggf-controls.de> (Gert Groenhoff's message of "Fri, 22 Mar 2019 23:46:22 +0100") References: <4a3ed6cf-03ce-5ae2-7878-c1a845f31096@ggf-controls.de> Message-ID: <878sx3vw8j.fsf@wheatstone.g10code.de> On Fri, 22 Mar 2019 23:46, ggroenhoff at ggf-controls.de said: > with gpg2 symmetric encrypted file. I allways get > "gpg: packet(3) with unknown version 7". That is garbled data because a version 7 of the session key packet (tag 3) is not defined. Please check the error messages again or provide a sample message for us. 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 peter at digitalbrains.com Mon Mar 25 16:02:14 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 25 Mar 2019 16:02:14 +0100 Subject: Identifying one of multiple authentication subkeys In-Reply-To: <87d0mfvwqm.fsf@wheatstone.g10code.de> References: <20d02c69-3c9b-5798-b4ef-67f642b1e523@digitalbrains.com> <6b96902a-cf19-43ba-a2a6-31697195fc0d@www.fastmail.com> <5bfc24af-8b6e-a2ca-f61d-97c3409cb22b@digitalbrains.com> <87d0mfvwqm.fsf@wheatstone.g10code.de> Message-ID: <4b8d7681-861a-6513-37c6-9a66c5696182@digitalbrains.com> On 25/03/2019 15:45, Werner Koch wrote: > That is on purpose: gpg-agent stores the key permanently and thus it > makes no sense to add and remove it regularly. It might also be "slightly annoying" to remove key material which is also in use for other purposes :-). You remove an SSH key, and suddenly an OpenPGP subkey is also missing... But something more user friendly to match SSH fingerprint and keygrip could be beneficial. I'm not sure what that would look like and neither do I think it is high on the priority list. For one thing, OpenSSH seems to prefer SHA256 SSH fingerprints over the old MD5 ones now. Peter. -- 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 wk at gnupg.org Tue Mar 26 09:16:22 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 26 Mar 2019 09:16:22 +0100 Subject: Identifying one of multiple authentication subkeys In-Reply-To: <4b8d7681-861a-6513-37c6-9a66c5696182@digitalbrains.com> (Peter Lebbing's message of "Mon, 25 Mar 2019 16:02:14 +0100") References: <20d02c69-3c9b-5798-b4ef-67f642b1e523@digitalbrains.com> <6b96902a-cf19-43ba-a2a6-31697195fc0d@www.fastmail.com> <5bfc24af-8b6e-a2ca-f61d-97c3409cb22b@digitalbrains.com> <87d0mfvwqm.fsf@wheatstone.g10code.de> <4b8d7681-861a-6513-37c6-9a66c5696182@digitalbrains.com> Message-ID: <87sgvauk2x.fsf@wheatstone.g10code.de> On Mon, 25 Mar 2019 16:02, peter at digitalbrains.com said: > But something more user friendly to match SSH fingerprint and keygrip > could be beneficial. I'm not sure what that would look like and neither You can build a script based on this: $ gpg-connect-agent 'keyinfo --ssh-list --ssh-fpr' /bye S KEYINFO 1234[...] D - - - P SHA256:PtJi[...] - S [...] This lists all keys allowed for ssh with its keygrip (1234. and the corresponding ssh fingerprint (SHA256:PTJI). Details as usual by using 'help keyinfo'. > For one thing, OpenSSH seems to prefer SHA256 SSH fingerprints over the > old MD5 ones now. That is right and you can tell gpg-agent this by using ssh-fingerprint-digest sha256 (I don't like the base64 encoding becuase it is hard to visual compare, but that is how it is). Note that while writing this I noticed that the KEYINFO command always printed MD5 fingerprints. I fixed that for 2.2.15 so that the above option is considered. Further, it is also possible to use keyinfo --ssh-list --ssh-fpr-md5 keyinfo --ssh-list --ssh-fpr=sha1 keyinfo --ssh-list --ssh-fpr=sha256 to select a certain fingerprint format independent of the option. Salam-Shalom, Werner p.s. Eventually someone(tm) should write a GUI tool to list and manage all kind of private keys in GnuPG. For example to list all users of a certain private key. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From peter at digitalbrains.com Tue Mar 26 11:49:33 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 26 Mar 2019 11:49:33 +0100 Subject: Identifying one of multiple authentication subkeys In-Reply-To: <87sgvauk2x.fsf@wheatstone.g10code.de> References: <20d02c69-3c9b-5798-b4ef-67f642b1e523@digitalbrains.com> <6b96902a-cf19-43ba-a2a6-31697195fc0d@www.fastmail.com> <5bfc24af-8b6e-a2ca-f61d-97c3409cb22b@digitalbrains.com> <87d0mfvwqm.fsf@wheatstone.g10code.de> <4b8d7681-861a-6513-37c6-9a66c5696182@digitalbrains.com> <87sgvauk2x.fsf@wheatstone.g10code.de> Message-ID: On 26/03/2019 09:16, Werner Koch wrote: > This lists all keys allowed for ssh with its keygrip (1234. and the > corresponding ssh fingerprint (SHA256:PTJI). Details as usual by using > 'help keyinfo'. Right, yes, the comment lines in sshcontrol are also really helpful for keys in sshcontrol. I should have been more explicit about my weird edge case. I use OpenPGP cards with a key in the authentication slot which is not part of any OpenPGP certificate, and is not in sshcontrol. gpg-agent is fine with this: if I have the card inserted, it will be offered as an authentication key to SSH servers. If I don't have the card inserted, it is not offered. This in contrast to the case where you were to add it to sshcontrol: then it would /ask/ for the card to be inserted if the server accepts the key. If it is not in sshcontrol, it will not be offered for SSH authentication. In this particular case, it is actually very easy to pick the correct SSH public key, because gpg-agent will add the comment "cardno:XXX", where XXX is the serial number of the card, to the public key when you do ssh-add -l or -L. It is more difficult to find the keygrip, though. While participating in this thread, I worked from the assumption that the key, for whatever reason, was not in sshcontrol, to catch edge cases such as this. I don't know whether there are other edge cases than this specific one where SSH keys are not in sshcontrol, though. This might be the only one. The use case I considered is this: I have a card I use on two PC's, but one of the PC's also has an on-disk SSH key. Some SSH accounts will only accept the card for authentication, but there are accounts which accept either key. If I'm on the machine with the on-disk key and my card is not inserted, it will pick the on-disk key. If I'm on the PC without the on-disk key, I cannot log in to that account without inserting the card. If the card were in sshcontrol, and it were offered before the on-disk key, I would be prompted to insert the card. But this would be unnecessary, since I have an on-disk key that will do the job just as well. But I have to say I no longer actually use this scenario :-). I did in the past, though. What would actually help in this use case, might be to have --card-status accept a --with-keygrip option. Then you have the "cardno:XXX" comment in ssh-add to pick the public key or its fingerprint, and --card-status to find the keygrip. > (I don't like the base64 encoding becuase it is hard to visual compare, > but that is how it is) Yes, I totally agree. And when matching stuff together like we do in this thread, we don't actually use any cryptographic properties of the fingerprint, there is no adversary. So MD5 might be easier on the eyes, but it has the disadvantage that the user needs to be /aware/ that they can get the same fingerprint format from ssh-keygen, ssh-add and gpg-agent. If they just see one format here and another there, they might very well not realise they can be made to match. So I'm inclined to think the default should be to output it in the same format in both tools. Plus, when it's purely for identification purposes, you can skip reading more letters of the base64 encoding once you've identified the right key. > I fixed that for 2.2.15 so that the above option is considered. > Further, it is also possible to use Neat! Thanks! > p.s. Eventually someone(tm) should write a GUI tool to list and manage > all kind of private keys in GnuPG. For example to list all users of a > certain private key. :-) Sorry for the long mail. I didn't see a lot of opportunity to shorten it without losing clarity. If I were to introduce a misunderstanding, it will only take even more time to sort out. Cheers, Peter. -- 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 peter at digitalbrains.com Tue Mar 26 12:29:11 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 26 Mar 2019 12:29:11 +0100 Subject: Please start a new thread In-Reply-To: References: <20d02c69-3c9b-5798-b4ef-67f642b1e523@digitalbrains.com> <6b96902a-cf19-43ba-a2a6-31697195fc0d@www.fastmail.com> <5bfc24af-8b6e-a2ca-f61d-97c3409cb22b@digitalbrains.com> <87d0mfvwqm.fsf@wheatstone.g10code.de> <4b8d7681-861a-6513-37c6-9a66c5696182@digitalbrains.com> <87sgvauk2x.fsf@wheatstone.g10code.de> Message-ID: <1cfbf9df-34c8-0c90-ae52-765450d0763f@digitalbrains.com> Hi, On 26/03/2019 12:20, Shweta Tyagi wrote: > gpg --batch --passphrase-fd n and it stops popup which asks for the > passphrase Please start a new thread with your question, it is something completely different than the thread you replied to. Thanks, Peter. -- 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 peter at digitalbrains.com Tue Mar 26 12:51:20 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 26 Mar 2019 12:51:20 +0100 Subject: Please start a new thread In-Reply-To: References: <20d02c69-3c9b-5798-b4ef-67f642b1e523@digitalbrains.com> <6b96902a-cf19-43ba-a2a6-31697195fc0d@www.fastmail.com> <5bfc24af-8b6e-a2ca-f61d-97c3409cb22b@digitalbrains.com> <87d0mfvwqm.fsf@wheatstone.g10code.de> <4b8d7681-861a-6513-37c6-9a66c5696182@digitalbrains.com> <87sgvauk2x.fsf@wheatstone.g10code.de> <1cfbf9df-34c8-0c90-ae52-765450d0763f@digitalbrains.com> Message-ID: <5d082c75-7fcc-c999-479d-6bcfeddebdb0@digitalbrains.com> Hi Shweta, On 26/03/2019 12:30, Shweta Tyagi wrote: > How can start a new thread? Please advise. Start a new e-mail (rather than replying to one), and address it to . That will start a new thread. Oh, I forgot this the previous time, but some mailing list members might appreciate it if you send a plain-text e-mail rather than one that has plain text as well as HTML content. If you don't know how to, I think it is acceptable to send them as you do now (not entirely sure about how strict that policy is). HTH, Peter. -- 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 shweta at upayasolution.com Tue Mar 26 12:20:13 2019 From: shweta at upayasolution.com (Shweta Tyagi) Date: Tue, 26 Mar 2019 16:50:13 +0530 Subject: Identifying one of multiple authentication subkeys In-Reply-To: References: <20d02c69-3c9b-5798-b4ef-67f642b1e523@digitalbrains.com> <6b96902a-cf19-43ba-a2a6-31697195fc0d@www.fastmail.com> <5bfc24af-8b6e-a2ca-f61d-97c3409cb22b@digitalbrains.com> <87d0mfvwqm.fsf@wheatstone.g10code.de> <4b8d7681-861a-6513-37c6-9a66c5696182@digitalbrains.com> <87sgvauk2x.fsf@wheatstone.g10code.de> Message-ID: Hi All, I am using the following command gpg --batch --passphrase-fd n and it stops popup which asks for the passphrase. but when I run this command on window server 12 it's not working its always show popup for the passphrase. can someone please help me how can I stop popup on window server 12. Shweta Tyagi Netsuite Technical Consultant Upaya - The Solution Inc p: 408-868-4477 w: www.upayasolution.com e: shweta at upayasolution.com s: shweta.tyagi97 a: 4320 Stevens Creek Blvd Suite # 124, San Jose, CA 95129 On Tue, Mar 26, 2019 at 4:22 PM Peter Lebbing wrote: > On 26/03/2019 09:16, Werner Koch wrote: > > This lists all keys allowed for ssh with its keygrip (1234. and the > > corresponding ssh fingerprint (SHA256:PTJI). Details as usual by using > > 'help keyinfo'. > > Right, yes, the comment lines in sshcontrol are also really helpful for > keys in sshcontrol. > > I should have been more explicit about my weird edge case. > > I use OpenPGP cards with a key in the authentication slot which is not > part of any OpenPGP certificate, and is not in sshcontrol. gpg-agent is > fine with this: if I have the card inserted, it will be offered as an > authentication key to SSH servers. If I don't have the card inserted, it > is not offered. This in contrast to the case where you were to add it to > sshcontrol: then it would /ask/ for the card to be inserted if the > server accepts the key. If it is not in sshcontrol, it will not be > offered for SSH authentication. > > In this particular case, it is actually very easy to pick the correct > SSH public key, because gpg-agent will add the comment "cardno:XXX", > where XXX is the serial number of the card, to the public key when you > do ssh-add -l or -L. > > It is more difficult to find the keygrip, though. While participating in > this thread, I worked from the assumption that the key, for whatever > reason, was not in sshcontrol, to catch edge cases such as this. I don't > know whether there are other edge cases than this specific one where SSH > keys are not in sshcontrol, though. This might be the only one. > > The use case I considered is this: I have a card I use on two PC's, but > one of the PC's also has an on-disk SSH key. Some SSH accounts will only > accept the card for authentication, but there are accounts which accept > either key. If I'm on the machine with the on-disk key and my card is > not inserted, it will pick the on-disk key. If I'm on the PC without > the on-disk key, I cannot log in to that account without inserting the > card. > > If the card were in sshcontrol, and it were offered before the on-disk > key, I would be prompted to insert the card. But this would be > unnecessary, since I have an on-disk key that will do the job just as > well. > > But I have to say I no longer actually use this scenario :-). I did in > the past, though. > > What would actually help in this use case, might be to have > --card-status accept a --with-keygrip option. Then you have the > "cardno:XXX" comment in ssh-add to pick the public key or its > fingerprint, and --card-status to find the keygrip. > > > (I don't like the base64 encoding becuase it is hard to visual compare, > > but that is how it is) > > Yes, I totally agree. And when matching stuff together like we do in > this thread, we don't actually use any cryptographic properties of the > fingerprint, there is no adversary. So MD5 might be easier on the eyes, > but it has the disadvantage that the user needs to be /aware/ that they > can get the same fingerprint format from ssh-keygen, ssh-add and > gpg-agent. If they just see one format here and another there, they > might very well not realise they can be made to match. > > So I'm inclined to think the default should be to output it in the same > format in both tools. > > Plus, when it's purely for identification purposes, you can skip reading > more letters of the base64 encoding once you've identified the right > key. > > > I fixed that for 2.2.15 so that the above option is considered. > > Further, it is also possible to use > > Neat! Thanks! > > > p.s. Eventually someone(tm) should write a GUI tool to list and manage > > all kind of private keys in GnuPG. For example to list all users of a > > certain private key. > > :-) > > Sorry for the long mail. I didn't see a lot of opportunity to shorten it > without losing clarity. If I were to introduce a misunderstanding, it > will only take even more time to sort out. > > Cheers, > > Peter. > > -- > 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 > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shweta at upayasolution.com Tue Mar 26 12:30:33 2019 From: shweta at upayasolution.com (Shweta Tyagi) Date: Tue, 26 Mar 2019 17:00:33 +0530 Subject: Please start a new thread In-Reply-To: <1cfbf9df-34c8-0c90-ae52-765450d0763f@digitalbrains.com> References: <20d02c69-3c9b-5798-b4ef-67f642b1e523@digitalbrains.com> <6b96902a-cf19-43ba-a2a6-31697195fc0d@www.fastmail.com> <5bfc24af-8b6e-a2ca-f61d-97c3409cb22b@digitalbrains.com> <87d0mfvwqm.fsf@wheatstone.g10code.de> <4b8d7681-861a-6513-37c6-9a66c5696182@digitalbrains.com> <87sgvauk2x.fsf@wheatstone.g10code.de> <1cfbf9df-34c8-0c90-ae52-765450d0763f@digitalbrains.com> Message-ID: Hi Peter, How can start a new thread? Please advise. if you any solution for this please help me find out the solution. Shweta Tyagi Netsuite Technical Consultant Upaya - The Solution Inc p: 408-868-4477 w: www.upayasolution.com e: shweta at upayasolution.com s: shweta.tyagi97 a: 4320 Stevens Creek Blvd Suite # 124, San Jose, CA 95129 On Tue, Mar 26, 2019 at 4:59 PM Peter Lebbing wrote: > Hi, > > On 26/03/2019 12:20, Shweta Tyagi wrote: > > gpg --batch --passphrase-fd n and it stops popup which asks for the > > passphrase > > Please start a new thread with your question, it is something completely > different than the thread you replied to. > > Thanks, > > Peter. > > -- > 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 -------------- An HTML attachment was scrubbed... URL: From guru at unixarea.de Tue Mar 26 13:55:07 2019 From: guru at unixarea.de (Matthias Apitz) Date: Tue, 26 Mar 2019 13:55:07 +0100 Subject: Please start a new thread In-Reply-To: References: <20d02c69-3c9b-5798-b4ef-67f642b1e523@digitalbrains.com> <6b96902a-cf19-43ba-a2a6-31697195fc0d@www.fastmail.com> <5bfc24af-8b6e-a2ca-f61d-97c3409cb22b@digitalbrains.com> <87d0mfvwqm.fsf@wheatstone.g10code.de> <4b8d7681-861a-6513-37c6-9a66c5696182@digitalbrains.com> <87sgvauk2x.fsf@wheatstone.g10code.de> <1cfbf9df-34c8-0c90-ae52-765450d0763f@digitalbrains.com> Message-ID: <20190326125507.GA7040@sh4-5.1blu.de> El d?a Tuesday, March 26, 2019 a las 05:00:33PM +0530, Shweta Tyagi escribi?: > Hi Peter, > How can start a new thread? Please advise. > if you any solution for this please help me find out the solution. > Hi, This depends on your Mail User Agent. It means "start a new mail with a new Subject" to the addr gnupg-users at gnupg.org. DO NOT reply to another thread when you have a new issue/problem/question. And, DO NOT top post, btw. matthias -- Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub October, 7 -- The GDR was different: Peace instead of Bundeswehr and wars, Druschba instead of Nazis, to live instead of to survive. From wk at gnupg.org Tue Mar 26 15:20:40 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 26 Mar 2019 15:20:40 +0100 Subject: [Announce] GnuPG 2.2.15 released Message-ID: <87y351u37r.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: version 2.2.15. This is a maintenance release; see below for a list changes. About GnuPG =========== The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation of the OpenPGP and S/MIME standards. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. The separate library GPGME provides a uniform API to use the GnuPG engine by software written in common programming languages. A wealth of frontend applications and libraries making use of GnuPG are available. As an universal crypto engine GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Noteworthy changes in version 2.2.15 ==================================== * sm: Fix --logger-fd and --status-fd on Windows for non-standard file descriptors. * sm: Allow decryption even if expired keys are configured. [#4431] * agent: Change command KEYINFO to print ssh fingerprints with other hash algos. * dirmngr: Fix build problems on Solaris due to the use of reserved symbol names. [#4420] * wkd: New commands --print-wkd-hash and --print-wkd-url for gpg-wks-client. Release-info: https://dev.gnupg.org/T4434 Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.2.15 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.15.tar.bz2 (6548k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.15.tar.bz2.sig An installer for Windows without any graphical frontend except for a very minimal Pinentry tool is available here: https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.15_20190326.exe (4078k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.15_20190326.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.2.15.tar.bz2 you would use this command: gpg --verify gnupg-2.2.15.tar.bz2.sig gnupg-2.2.15.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See the end of this mail for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.2.15.tar.bz2, you run the command like this: sha1sum gnupg-2.2.15.tar.bz2 and check that the output matches the next line: 1909afdad3cf29583126c471298da290399270f4 gnupg-2.2.15.tar.bz2 540abc655dbed525bb216c62e5e43a88f952193c gnupg-w32-2.2.15_20190326.tar.xz f5f7eeadfdf6ad971b5313f045083b4f95ace07b gnupg-w32-2.2.15_20190326.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese (traditional and simplified), Czech, French, German, Japanese, Norwegian, Russian, and Ukrainian being almost completely translated. Documentation and Support ========================= If you used GnuPG in the past you should read the description of changes and new features at doc/whats-new-in-2.1.txt or online at https://gnupg.org/faq/whats-new-in-2.1.html The file gnupg.info has the complete reference manual of the system. Separate man pages are included as well but they miss some of the details available only in thee manual. The manual is also available online at https://gnupg.org/documentation/manuals/gnupg/ or can be downloaded as PDF at https://gnupg.org/documentation/manuals/gnupg.pdf . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. You may also want to search the GnuPG mailing list archives or ask on the gnupg-users mailing list for advise on how to solve problems. Most of the new features are around for several years and thus enough public experience is available. In case of build problems specific to this release please first check https://dev.gnupg.org/T4434 for updated information. Please consult the archive of the gnupg-users mailing list before reporting a bug: . We suggest to send bug reports for a new release to this list in favor of filing a bug at . If you need commercial support check out . If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== Maintenance and development of GnuPG is mostly financed by donations. The GnuPG project currently employs two full-time developers and one contractor. They all work exclusively on GnuPG and closely related software like Libgcrypt, GPGME and Gpg4win. We have to thank all the people who helped the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Many thanks to our numerous financial supporters, both corporate and individuals. Without you it would not be possible to keep GnuPG in a good shape and to address all the small and larger requests made by our users. Thanks. Happy hacking, Your GnuPG hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users'at'gnupg.org mailing list. p.p.s List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: rsa2048 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048 2014-10-29 [expires: 2020-10-30] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa3072 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) The keys are available at and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Tue Mar 26 18:50:42 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 26 Mar 2019 18:50:42 +0100 Subject: [Announce] GnuPG Made Easy (GPGME) 1.13.0 released Message-ID: <87pnqdtthp.fsf@wheatstone.g10code.de> Hello! We are pleased to announce version 1.13.0 of GPGME. GnuPG Made Easy (GPGME) is a C language library that allows to add support for cryptography to a program. It is designed to make access to public key crypto engines like gpg and gpgsm easier for applications. GPGME provides a high-level crypto API for encryption, decryption, signing, signature verification, and key management. GPGME comes with language bindings for Common Lisp, C++, QT, Python 2 and 3. See https://gnupg.org/software/gpgme for more. Noteworthy changes in version 1.13.0 ==================================== * Support GPGME_AUDITLOG_DIAG for gpgsm. [#4426] * New context flag "trust-model". * Removed support for WindowsCE and Windows ME. * Aligned the gpgrt-config code with our other libaries. * Auto-check for all installed Python versions. [#3354] * Fixed generating card key in the C++ bindings. [#4428] * Fixed a segv due to bad parameters in genkey. [#4192] * Fixed crash if the plaintext is ignored in a CMS verify. * Fixed memleak on Windows. [T4238] * Tweaked the Windows I/O code. * Fixed random crashes on Windows due to closing an arbitrary handle. [#4237] * Fixed a segv on Windows. [#4369] * Fixed test suite problems related to dtags. [#4298] * Fixed bunch of python bugs. [#4242,commit 9de1c96ac3cf] * Several fixes to the Common Lisp bindings. * Fixed minor bugs in gpgme-json. [#4331,#4341,#4342,#4343 * Require trace level 8 to dump all I/O data. * The compiler must now support variadic macros. * Interface changes relative to the 1.12.0 release: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ gpgme_set_ctx_flag EXTENDED: New flag 'trust-model'. cpp: Context::create NEW. cpp: Key::isBad NEW. cpp: Subkey::isBad NEW. cpp: UserID::isBad NEW. cpp: UserID::Signature::isBad NEW. cpp: GenCardKeyInteractor::setAlgo NEW. [c=C33/A22/R0 cpp=C15/A9/R0 qt=C10/A3/R3] Release-info: https://dev.gnupg.org/T4376 Download ======== You may download this library and its OpenPGP signature from: https://gnupg.org/ftp/gcrypt/gpgme/gpgme-1.13.0.tar.bz2 (1777k) https://gnupg.org/ftp/gcrypt/gpgme/gpgme-1.13.0.tar.bz2.sig or from ftp.gnupg.org. The SHA-1 checksum is 4653b273fd2820ba4d5f382474b3e79a9367beb9 gpgme-1.13.0.tar.bz2 but you better check the integrity using the provided signature. See for details. Thanks ====== Maintenance and development of GnuPG is mostly financed by donations. The GnuPG project currently employs two full-time developer and one contractor. All work exclusively on GnuPG and closely related software like Libgcrypt and GPGME. We have to thank all the people who helped the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Many thanks to our numerous financial supporters, both corporate and individuals. Without you it would not be possible to keep GnuPG in a good shape and address all the small and larger requests made by our users. Thanks. Happy hacking, Your GnuPG hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-devel 'at' gnupg.org mailing list. p.p.s List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: rsa2048 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048 2014-10-29 [expires: 2020-10-30] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa3072 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) The keys are available at and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From larrywingfield67 at gmail.com Thu Mar 28 19:12:22 2019 From: larrywingfield67 at gmail.com (Mr. Wingfield) Date: Thu, 28 Mar 2019 14:12:22 -0400 Subject: No subject Message-ID: http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From telegraph at gmx.net Thu Mar 28 18:08:45 2019 From: telegraph at gmx.net (Gregor Zattler) Date: Thu, 28 Mar 2019 18:08:45 +0100 Subject: gpg-agent: different ttl for different keys possible? Message-ID: <875zs2aera.fsf@len.workgroup> Dear gnupg-users and developers, is it possible to configure gpg-agent to cache the passphrase for different OpenPGP keys for a different length of time? if so: how? Ciao, Gregor From alpine.chappa at gmx.com Wed Mar 27 21:32:32 2019 From: alpine.chappa at gmx.com (Eduardo Chappa) Date: Wed, 27 Mar 2019 14:32:32 -0600 (MDT) Subject: [Alpine-info] Native OpenPGP integration with Alpine In-Reply-To: <56328d20-b95b-fe1f-4600-04941bfc3520@andrewnesbit.org> References: <56328d20-b95b-fe1f-4600-04941bfc3520@andrewnesbit.org> Message-ID: On Wed, 27 Mar 2019, Andrew Luke Nesbit wrote: > I received many useful responses. However I would like to explore > options for native integration rather than using external filters. > > Does anybody know of any efforts to integrate OpenPGP _natively_ into > Alpine? Has anybody looked into this /at all/, or done anything like a > code review to see if this is even feasible? There was an effort to integrate OpenPGP into re-alpine. I know it was unfinished code, I think that most of what is needed is in place, so I would try to figure out what happened to that effort as a first approach into concluding that effort. If you need my assistance while working on this project, let me know. I'll be glad to help. -- Eduardo From ullbeking at andrewnesbit.org Wed Mar 27 20:58:30 2019 From: ullbeking at andrewnesbit.org (Andrew Luke Nesbit) Date: Wed, 27 Mar 2019 19:58:30 +0000 Subject: Native OpenPGP integration with Alpine Message-ID: <56328d20-b95b-fe1f-4600-04941bfc3520@andrewnesbit.org> Hello, I am gradually getting back into using Alpine for the times I need to work with email on an interactive TTY. I have written to the Alpine-info list before, asking for recommendations for using OpenPGP implementations, particularly GnuPG [1]. I received many useful responses. However I would like to explore options for native integration rather than using external filters. Does anybody know of any efforts to integrate OpenPGP _natively_ into Alpine? Has anybody looked into this /at all/, or done anything like a code review to see if this is even feasible? I've been thinking about looking into this myself, although I have to admit it's not very high on my list of priorities. If there is existing information that can give me a head start, or somebody with whom I can compare notes then it's more likely I will be able to push through the first hurdles. Kind regards, Andrew [1] https://mailman13.u.washington.edu/mailman/htdig/alpine-info/2018-May/007959.html From ullbeking at andrewnesbit.org Thu Mar 28 03:33:14 2019 From: ullbeking at andrewnesbit.org (Andrew Luke Nesbit) Date: Thu, 28 Mar 2019 02:33:14 +0000 Subject: [Alpine-info] Native OpenPGP integration with Alpine In-Reply-To: References: <56328d20-b95b-fe1f-4600-04941bfc3520@andrewnesbit.org> Message-ID: <7196ef10-3d73-67aa-06ab-41d1e5656b8a@andrewnesbit.org> On 27/03/2019 20:32, Eduardo Chappa wrote: > On Wed, 27 Mar 2019, Andrew Luke Nesbit wrote: > >> I received many useful responses.? However I would like to explore >> options for native integration rather than using external filters. >> >> Does anybody know of any efforts to integrate OpenPGP _natively_ into >> Alpine?? Has anybody looked into this /at all/, or done anything like a >> code review to see if this is even feasible? > > There was an effort to integrate OpenPGP into re-alpine. I know it was > unfinished code, I think that most of what is needed is in place, so I > would try to figure out what happened to that effort as a first approach > into concluding that effort. > > If you need my assistance while working on this project, let me know. I'll > be glad to help. Thank you, Eduardo. I'll have a look. Andrew From sp_xie at yahoo.com Sun Mar 31 14:43:30 2019 From: sp_xie at yahoo.com (Shaoping Xie) Date: Sun, 31 Mar 2019 08:43:30 -0400 Subject: Two questions about system entropy and update In-Reply-To: References: Message-ID: Good Morning , I have been tried to generate a key pair and gotten the error : Not enough random bytes available. Please do some other work to give the OS a chance to collect more entropy! (Need 300 more bytes) It seems that the error is very common by googling the internet . However, none of recommendations has worked and helped . I am using Solaris 10 X86 system . I had generated the key pair without any problem before . Can some experts explain why I have suddenly had this problem ? Does it help if I remove the old key pair ? (I had tried to run the key generation while running iostat, mpstat and using find in other windows. Is there any way I may view the system entropy in Solaris system ?) My GPG is pretty old : gpg (GnuPG) 1.4.10; Copyright (C) 2008 Free Software Foundation, Inc. How can I update GPG ? I have the file transfers with dozens of clients, which are essential for business . The update cannot affect the current public/private keys . Is it safe to upgrade on the current system or I have to build a new system ? Can the new version solve the problem with system entropy ? Thank you, Shaoping -------------- next part -------------- An HTML attachment was scrubbed... URL: