From wk at gnupg.org Wed Feb 1 16:56:36 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 01 Feb 2017 16:56:36 +0100 Subject: error in GPA In-Reply-To: <20170126213335.1a811abe@rsv2-Serval-Pro> (Reid Vail's message of "Thu, 26 Jan 2017 21:33:35 -0500") References: <20170126213335.1a811abe@rsv2-Serval-Pro> Message-ID: <87wpd9vr9n.fsf@wheatstone.g10code.de> On Fri, 27 Jan 2017 03:33, rsv869 at runbox.com said: > "The GPGME library returned and unexpected error at gpagenkeyadvop.c199. The error > was: General Error" That is a catch-all error message and thus we can't immediately see the problem. Please tell us more details. You should describe the problems as good as possible and try to come up with a minimal recipe on how to replicate the problem. We need to know the *version* of the software and if you are using a non-released version the GIT commit id. The type and version of your *operating system* is usually important, so please tell us. In particular tell us if you are problem occurs on a non Unix system, i.e. MS Windows. You should also tell us which version of GnuPG is used: gpg2 --version if this fails use: gpg --version Note that you need to run this on the command line (i.e. in on a terminal screen). To see the version of gpa, you may run gpa --version but you can also click on the "About" menu entry. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From el_infantil at tuta.io Wed Feb 1 14:29:11 2017 From: el_infantil at tuta.io (el_infantil at tuta.io) Date: Wed, 1 Feb 2017 14:29:11 +0100 (CET) Subject: Option print-md: outputlines (with CR/LF) vary depending on pathlenght and hash-algo Message-ID: Hello!I am using GnuPG (1.4.x) in a batch file to generate hash-sums of different files. [gpg.exe --homedir c:\path\ --print-md hashalgo c:\path\file >> output.txt]Depending on the path length to the file and the output length of the chosen hash-algorithm GnuPGs output is in one line, broken in the middle of the hash sum into two lines or the file-path and the hash-output are in two different lines (see below).This makes it different to catch the hash-output into a variable because it can not be predicted which kind of output comes.?Can I make GnuPG to write its output to a single line without "CR/LF"? Then for /f and a : as delim could possibly work. But as for /f only reads one line at a time it can not handle GnuPGs current output. E.G.:A short path and MD5 results in one line of output:c:\xyz.txt: B3 8E 8C 8E 8F C4 B2 D9 ?E9 80 CE 82 C2 F8 42 AA A short path and SHA256 results in a linebreak within the hash-output:?c:\xyz.txt: FBF0C442 98FC1E3B 9AFBF7A3 996FB924 24B3B4CE 649B1E49 A424291B?? ? ? ? A952B855 A long path and SHA256 results in two different lines: c:\X-Fold\Y-Fold\Z-Folg\ABCDEFG-PQRSTUV.TXT.TST:?FA56B431 A5AB6BCE D4D385A3 B7414AFA DB11DFB1 853E6967 10128EBF 1412B3CD Any idea how to solve this? Thanks for help! -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at digitalbrains.com Wed Feb 1 21:34:19 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 1 Feb 2017 21:34:19 +0100 Subject: Option print-md: outputlines (with CR/LF) vary depending on pathlenght and hash-algo In-Reply-To: References: Message-ID: Hello! On 01/02/17 14:29, el_infantil at tuta.io wrote: > Any idea how to solve this? Add the option --with-colons for a machine-parseable output (colon separated). 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 From ricul77 at gmail.com Thu Feb 2 13:02:18 2017 From: ricul77 at gmail.com (Richard Ulrich) Date: Thu, 02 Feb 2017 13:02:18 +0100 Subject: Estonian e-residency Message-ID: <1486036938.20899.16.camel@gmail.com> Hi, This was probably discussed here before, but I didn't find it.? So, feel free to direct me to the old feeds. I thought about applying for Estonian e-residency for the sole reason of adding credibility to my GPG key. My idea would be to sign my GPG key with the ID card. This could give people who are not in my web of trust a head start. What Do you think of that? Rgds Richard -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part URL: From andrewg at andrewg.com Thu Feb 2 14:42:35 2017 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 2 Feb 2017 13:42:35 +0000 Subject: Estonian e-residency In-Reply-To: <1486036938.20899.16.camel@gmail.com> References: <1486036938.20899.16.camel@gmail.com> Message-ID: <3a7a13e7-0208-3b54-59a8-54a64d805636@andrewg.com> On 02/02/17 12:02, Richard Ulrich wrote: > I thought about applying for Estonian e-residency for the sole > reason of adding credibility to my GPG key. My idea would be to sign > my GPG key with the ID card. This could give people who are not in > my web of trust a head start. Which particular people? And a head start at doing what? AIUI the e-residency signature is not PGP-compatible, so people will need to verify it using a separate tool. And once I have verified your e-residency signature, what does it mean to me? At best, it tells me that you are one of possibly many people known to the Estonian Government as "Richard Ulrich". Unless I have already dealt with you elsewhere via your Estonian ID, how does this help me? What particular problem are you trying to solve? It seems to me that unless you are going to use your E-identity for some other purpose, tying your GPG key to it adds little value. You say your sole reason for applying for e-residency is to add "credibility" to your existing key. But how is asking the Estonian government to verify your passport more credible than producing your passport at a keysigning party? Or better still, showing it to the actual person you want to talk to? Andrew. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Feb 2 18:47:24 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 02 Feb 2017 18:47:24 +0100 Subject: Smartcard working completely with GPG2 and incompletely with GPG1.4 In-Reply-To: <87a8ad5ne6.fsf@iwagami.gniibe.org> (NIIBE Yutaka's message of "Fri, 27 Jan 2017 09:58:57 +0900") References: <20170125201456.024b9218@Carbon> <87a8ad5ne6.fsf@iwagami.gniibe.org> Message-ID: <87k298o577.fsf@wheatstone.g10code.de> On Fri, 27 Jan 2017 01:58, gniibe at fsij.org said: > With GnuPG 1.4 for smartcard can't work well for RSA 4096-bit keys. (I > think that it can also occur with the combination of GnuPG 1.4 and GnuPG > 2.0.) In fact, we may actually want to drop card support from 1.4 because that will never be up to what we have in current GnuPG. I do not think that it is justified to allocate resources on maintaining the limited card support we have in 1.4. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Thu Feb 2 19:06:21 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 02 Feb 2017 19:06:21 +0100 Subject: Non-interactive password-change with gnupg 2.0? In-Reply-To: <2857ad40-f138-94bf-59d5-b37b520fa534@duckdalbe.org> (Pablo Santee's message of "Thu, 5 Jan 2017 21:07:04 +0100") References: <2857ad40-f138-94bf-59d5-b37b520fa534@duckdalbe.org> Message-ID: <87fujwo4bl.fsf@wheatstone.g10code.de> On Thu, 5 Jan 2017 21:07, pablo-gnupg at duckdalbe.org said: > I'm trying to write code to change the passphrase of a key without > user-interaction that works with both, gpg 2.0 and gpg 2.1. I would not invest too much time into 2.0; as stated on the website it will reach end-of-life by the end of this year. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Thu Feb 2 19:09:48 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 02 Feb 2017 19:09:48 +0100 Subject: Signatures on a subkey? In-Reply-To: <1512400762.20170114121701@riseup.net> (MFPA's message of "Sat, 14 Jan 2017 12:17:01 +0000") References: <1512400762.20170114121701@riseup.net> Message-ID: <87bmuko45v.fsf@wheatstone.g10code.de> On Sat, 14 Jan 2017 13:17, 2014-667rhzu3dc-lists-groups at riseup.net said: > I was just looking at key 0x2B9880E1E6602099 because GnuPG was > flagging up that the key is newer than some of the signatures on it. I > noticed that a large number of the signatures visible with > gpg --with-sig-list --list-keys 0x2B9880E1E6602099 > are not visible at the delsig command when editing the key. They are I also noticed quite some misplaced signature on subkeys. Those were not handled by the clean sub-command or the import clean filter. With 2.1.18 this was changed so that all wrong key binding signatures are removed. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Thu Feb 2 19:24:19 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 02 Feb 2017 19:24:19 +0100 Subject: Meaning of "text user ID's"? In-Reply-To: (Peter Lebbing's message of "Wed, 4 Jan 2017 14:53:35 +0100") References: Message-ID: <877f58o3ho.fsf@wheatstone.g10code.de> On Wed, 4 Jan 2017 14:53, peter at digitalbrains.com said: > "Really sign all text user IDs? (y/N)" > So how come that the jpeg image is about to be signed as well? What > does "TEXT user ID" mean? I would have expected only the other UID's > to be signed. Is this a bug in my head or in the code? I think this patch is wrong: commit a74aeb5dae1f673fcd98b39a6a0496f3c622709a AuthorDate: Fri Nov 6 13:14:57 2015 +0100 gpg: Add new option --only-sign-text-ids. * g10/options.h (opt): Add field only_sign_text_ids. * g10/gpg.c (enum cmd_and_opt_values): Add value oOnlySignTextIDs. (opts): Handle oOnlySignTextIDs. (main): Likewise. * g10/keyedit.c (sign_uids): If OPT.ONLY_SIGN_TEXT_IDS is set, don't select non-text based IDs automatically. (keyedit_menu): Adapt the prompt asking to sign all user ids according to OPT.ONLY_SIGN_TEXT_IDS. * doc/gpg.texi: Document the new option --only-sign-text-ids. GnuPG-bug-id: 1241 Debian-bug-id: 569702 In particular if (opt.only_sign_text_ids) result = cpr_get_answer_is_yes ("keyedit.sign_all.okay", _("Really sign all user IDs? (y/N) ")); else result = cpr_get_answer_is_yes ("keyedit.sign_all.okay", _("Really sign all text user IDs? (y/N) ")); looks wrong. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From ralph at inputplus.co.uk Fri Feb 3 21:49:45 2017 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Fri, 03 Feb 2017 20:49:45 +0000 Subject: Key Used to Lookup Symmetric Passphrase. Message-ID: <20170203204945.29331213B6@orac.inputplus.co.uk> Hi, I'm using gnupg 2.1.18-1 on Arch Linux. `gpg -c foo' asks for a passphrase. I enter `p-foo' twice. For file bar it's `p-bar'. `gpg -d foo.gpg' doesn't prompt, which is good, getting the passphrase from the agent. Ditto bar.gpg. If I rename foo.gpg to xyzzy.gpg it still doesn't prompt, finding the correct passphrase. What's the key being used to look up the symmetric passphrase? Is it something random stored in *.gpg and thus survives the rename? How can I list these in the manner of -k and -K? Very happy to read documentation on it, but haven't spotted anything so far. Cheers, Ralph. From mycraigsl at ymail.com Sat Feb 4 00:28:03 2017 From: mycraigsl at ymail.com (MyCraigs List) Date: Fri, 3 Feb 2017 23:28:03 +0000 (UTC) Subject: Paper backup of all keys References: <1349525485.953127.1486164483748.ref@mail.yahoo.com> Message-ID: <1349525485.953127.1486164483748@mail.yahoo.com> Hello all, I want a paper backup of all the keys I have for an email an address. How is this done? (I have printed out my private key in the past....don't remember how I did it or if I did it correctly). Also, let's say the key associated with the email address (not a paper backup) gets corrupted or I delete it or render the key unuseable- can the paper backup of the key be used to type the key back in? Thank you, Craig From antony at blazrsoft.com Sat Feb 4 02:23:36 2017 From: antony at blazrsoft.com (antony at blazrsoft.com) Date: Fri, 03 Feb 2017 20:23:36 -0500 Subject: Paper backup of all keys In-Reply-To: <1349525485.953127.1486164483748@mail.yahoo.com> References: <1349525485.953127.1486164483748.ref@mail.yahoo.com> <1349525485.953127.1486164483748@mail.yahoo.com> Message-ID: <99AA765B-B9B9-4FE1-8757-C8B51F562138@blazrsoft.com> On February 3, 2017 6:28:03 PM EST, MyCraigs List wrote: >I want a paper backup of all the keys I have for an email an address. > >How is this done? (I have printed out my private key in the >past....don't remember how I did it or if I did it correctly). > Just off the top of my head, I believe it can be done with: gpg -a --export-secret-keys [key-id] > secret_key.txt This creates a text file with the ASCII armored private key file which can then be printed. >Also, let's say the key associated with the email address (not a paper >backup) gets corrupted or I delete it or render the key unuseable- can >the paper backup of the key be used to type the key back in? > You can type the key into a text file, say secret_key.txt, and then do: gpg --import secret_key.txt You could name it secret_key.asc as well. Not sure if that matters (I don't think it does). This is just off the top of my head since I'm not at my computer at the moment to verify, but that's the gist of it. -- HTH, Antony From dkg at fifthhorseman.net Sat Feb 4 03:43:33 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 03 Feb 2017 21:43:33 -0500 Subject: effect of revuid In-Reply-To: References: Message-ID: <87lgtmu14a.fsf@alice.fifthhorseman.net> On Tue 2017-01-31 08:13:52 -0500, Marko Bauhardt wrote: > what is the effect when delete a UID via `revuid` from a given key. revuid does not delete a User ID, it revokes a user ID. On a typical OpenPGP certificate, a revoked User ID is still present, but it is marked clearly and verifiably as having been revoked. It's still possible to emit a "cleaned" version of the cert without any of the revoked User IDs on it, of course. Note that if you just do your revocation locally and don't find a way to get it to your correspondents (e.g. by publishing to the keyservers, and hoping that they all refresh regularly) then no one will know about it, and from their point of view the User ID will not be revoked. > My key is still valid right? The uid?s are only bound to a given key > and can be exchanged as much i want. right? Or are there some more > effects? The primary key and its subkeys are still valid, yes. If you revoke the last User ID, then arguably a cleaned version of your certificate (without any User IDs) will not be considered a valid "transferable public key" because it will have no User ID associated. > Can i still decrypt emails with my key sent to this revoked email? even if your certificate as a whole is explicitly revoked, the mathematical object that is the secret key still exists, and can still perform whatever operations you require of it. So yes, you should be able to decrypt anything encrypted to any secret key you hold, regardless of whether the certificates that contain those keys are valid, revoked, expired, or whatever. make sense? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From dkg at fifthhorseman.net Sat Feb 4 04:09:16 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 03 Feb 2017 22:09:16 -0500 Subject: GnuPG to create CSR In-Reply-To: <1E46221211FBA6429BADC35084A32174CCE149@HO-EXMBX-01.bmoman.bankmuscat.com> References: <1E46221211FBA6429BADC35084A32174CB9891@HO-EXMBX-01.bmoman.bankmuscat.com> <87ziiuocz0.fsf@alice.fifthhorseman.net> <1E46221211FBA6429BADC35084A32174CCE149@HO-EXMBX-01.bmoman.bankmuscat.com> Message-ID: <87bmuitzxf.fsf@alice.fifthhorseman.net> On Tue 2017-01-31 07:05:45 -0500, Ali Hassan Hamed Al Ajmi (eChannels) wrote: > Thanks for your response, > > I have successfully created the CSR and send it to internal CA > (Microsoft CA) team. They sent me the certificate. I have used > Kleopatra UI to import the created certificate after save it in a file > (attaching sample file). Using same Kleopatra UI, I have also imported > root & intermediate certificates for the CA. looks like attached > img(kleopatra.png): We I tried to encrypt or sign any file, it shows > this error (attached error.png) > > Is there anything wrong I have done? > Or it is just because Kleopatra does not support X.509 certificate created by Microsoft CA? I'm sorry, i don't know the answer here, as this is a platform i don't use myself. hopefully someone else on the list here who uses GnuPG on Windows and Kleopatra can give you some feedback or suggestions for how to debug further. Regards, --dkg From dkg at fifthhorseman.net Sat Feb 4 04:21:30 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 03 Feb 2017 22:21:30 -0500 Subject: Paper backup of all keys In-Reply-To: <1349525485.953127.1486164483748@mail.yahoo.com> References: <1349525485.953127.1486164483748.ref@mail.yahoo.com> <1349525485.953127.1486164483748@mail.yahoo.com> Message-ID: <8737futzd1.fsf@alice.fifthhorseman.net> On Fri 2017-02-03 18:28:03 -0500, MyCraigs List wrote: > Also, let's say the key associated with the email address (not a paper > backup) gets corrupted or I delete it or render the key unuseable- can > the paper backup of the key be used to type the key back in? Sure, but it would likely be a pain to type the whole thing in. You might be interested in the "paperkey" tool, written by David Shaw, which does a good job at minimizing the typing you'll need to do (assuming that all of the public parts of the certificate itself can be recovered from the keyservers or your correspondents). If you use debian or a debian derivative, just use "apt install paperkey", but otherwise there's: http://www.jabberwocky.com/software/paperkey/ Regards, --dkg From mycraigsl at ymail.com Sat Feb 4 03:53:05 2017 From: mycraigsl at ymail.com (MyCraigs List) Date: Sat, 4 Feb 2017 02:53:05 +0000 (UTC) Subject: Paper backup of all keys References: <1821104719.1018498.1486176785929.ref@mail.yahoo.com> Message-ID: <1821104719.1018498.1486176785929@mail.yahoo.com> Thanks Antony. I got the txt files of the secret keys.....I hope. I wonder if there's a way to get the public, private and ID and associated email addresses all backed up into a nice neat txt file? So far....so good. Thanks, Craig -------------------------------------------- On Fri, 2/3/17, antony at blazrsoft.com wrote: Subject: Re: Paper backup of all keys To: "MyCraigs List" , gnupg-users at gnupg.org Date: Friday, February 3, 2017, 8:23 PM On February 3, 2017 6:28:03 PM EST, MyCraigs List wrote: >I want a paper backup of all the keys I have for an email an address. > >How is this done?? (I have printed out my private key in the >past....don't remember how I did it or if I did it correctly). > Just off the top of my head, I believe it can be done with: gpg -a --export-secret-keys [key-id] > secret_key.txt This creates a text file with the ASCII armored private key file which can then be printed. >Also, let's say the key associated with the email address (not a paper >backup) gets corrupted or I delete it or render the key unuseable- can >the paper backup of the key be used to type the key back in? > You can type the key into a text file, say secret_key.txt, and then do: gpg --import secret_key.txt You could name it secret_key.asc as well. Not sure if that matters (I don't think it does). This is just off the top of my head since I'm not at my computer at the moment to verify, but that's the gist of it. -- HTH, Antony From antony at blazrsoft.com Sat Feb 4 05:39:11 2017 From: antony at blazrsoft.com (Antony Prince) Date: Fri, 3 Feb 2017 23:39:11 -0500 Subject: Paper backup of all keys In-Reply-To: <1821104719.1018498.1486176785929@mail.yahoo.com> References: <1821104719.1018498.1486176785929.ref@mail.yahoo.com> <1821104719.1018498.1486176785929@mail.yahoo.com> Message-ID: On 2/3/2017 9:53 PM, MyCraigs List wrote: > Thanks Antony. I got the txt files of the secret keys.....I hope. I wonder if there's a way to get the public, private and ID and associated email addresses all backed up into a nice neat txt file? > You could change: gpg -a --export-secret-keys [key-id] > secret_key.txt to: gpg -a --export-secret-keys [key-id] >> secret_key.txt With this, it will append each successive key to the end of the text file. Not the cleanest solution though. Daniel mentioned a tool meant for this purpose called paperkey in his response. I've never used it but it seems like it's definitely worth looking into if you want paper backups. As he mentioned, typing in a key manually is a PITA, especially if it has a lot of signatures and depending on the key length. The public key is derived from the private key, so the private key(s) is/are all you need since it contains all information associated with that key. -- Antony Prince Key ID: 0xAF3D4087301B1B19 Fingerprint: 591F F17F 7A4A A8D0 F659 C482 AF3D 4087 301B 1B19 URL: http://pool.sks-keyservers.net/pks/lookup?op=get&search=0xAF3D4087301B1B19 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 866 bytes Desc: OpenPGP digital signature URL: From mycraigsl at ymail.com Sat Feb 4 05:02:00 2017 From: mycraigsl at ymail.com (MyCraigs List) Date: Sat, 4 Feb 2017 04:02:00 +0000 (UTC) Subject: Paper backup of all keys References: <763104142.1030115.1486180920505.ref@mail.yahoo.com> Message-ID: <763104142.1030115.1486180920505@mail.yahoo.com> Daniel, I gave paperkey a try the other day and quickly learned, because I'm no techy (and no desire to be one), it was too difficult to figure out. Maybe I'll give it another try? Thanks, Craig -------------------------------------------- On Fri, 2/3/17, Daniel Kahn Gillmor wrote: Subject: Re: Paper backup of all keys To: "MyCraigs List" , gnupg-users at gnupg.org Date: Friday, February 3, 2017, 10:21 PM On Fri 2017-02-03 18:28:03 -0500, MyCraigs List wrote: > Also, let's say the key associated with the email address (not a paper > backup) gets corrupted or I delete it or render the key unuseable- can > the paper backup of the key be used to type the key back in? Sure, but it would likely be a pain to type the whole thing in. You might be interested in the "paperkey" tool, written by David Shaw, which does a good job at minimizing the typing you'll need to do (assuming that all of the public parts of the certificate itself can be recovered from the keyservers or your correspondents). If you use debian or a debian derivative, just use "apt install paperkey", but otherwise there's: ? http://www.jabberwocky.com/software/paperkey/ Regards, ? ? ? ? --dkg From sivmu at web.de Sat Feb 4 07:33:56 2017 From: sivmu at web.de (sivmu) Date: Sat, 4 Feb 2017 07:33:56 +0100 Subject: Unecrypted download of public keys Message-ID: <95ee17c7-e1d8-e5c8-a8dc-e4c05c8f95d2@web.de> When using --revc-key or the gpa frontend, I noticed that the target public keys are still downloded using unencrypted http. While the trnasmitted information is generally public, it doesmake things pretty easy for an adversary to collect metadata such as your contacts. This is expecially relevant if you refresh your keys all at once, as this will leak your complete contact list to the network. Is there any reason gnupg does not use https by default to connect to the keyservers? I think this is an unnecessary leak of privacy. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Sat Feb 4 08:18:39 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 04 Feb 2017 02:18:39 -0500 Subject: Unecrypted download of public keys In-Reply-To: <95ee17c7-e1d8-e5c8-a8dc-e4c05c8f95d2@web.de> References: <95ee17c7-e1d8-e5c8-a8dc-e4c05c8f95d2@web.de> Message-ID: <87k296qv8w.fsf@alice.fifthhorseman.net> On Sat 2017-02-04 01:33:56 -0500, sivmu wrote: > When using --revc-key or the gpa frontend, I noticed that the > target public keys are still downloded using unencrypted http. While the > trnasmitted information is generally public, it doesmake things pretty > easy for an adversary to collect metadata such as your contacts. > > This is expecially relevant if you refresh your keys all at once, as > this will leak your complete contact list to the network. > > Is there any reason gnupg does not use https by default to connect to > the keyservers? I think this is an unnecessary leak of privacy. as of 2.1.18, gnupg does use https by default to connect to the keyserver network. :) In particular, if you do not supply a --keyserver argument, it will use hkps://hkps.pool.sks-keyservers.net as the default keyserver, and should verify the certificates only against the pool-specific CA. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From pete at heypete.com Sat Feb 4 08:40:46 2017 From: pete at heypete.com (Pete Stephenson) Date: Sat, 4 Feb 2017 08:40:46 +0100 Subject: Paper backup of all keys In-Reply-To: <8737futzd1.fsf@alice.fifthhorseman.net> References: <1349525485.953127.1486164483748.ref@mail.yahoo.com> <1349525485.953127.1486164483748@mail.yahoo.com> <8737futzd1.fsf@alice.fifthhorseman.net> Message-ID: On Feb 4, 2017 04:33, "Daniel Kahn Gillmor" wrote: On Fri 2017-02-03 18:28:03 -0500, MyCraigs List wrote: > Also, let's say the key associated with the email address (not a paper > backup) gets corrupted or I delete it or render the key unuseable- can > the paper backup of the key be used to type the key back in? Sure, but it would likely be a pain to type the whole thing in. You might be interested in the "paperkey" tool, written by David Shaw, which does a good job at minimizing the typing you'll need to do (assuming that all of the public parts of the certificate itself can be recovered from the keyservers or your correspondents). If you use debian or a debian derivative, just use "apt install Maybe I'm doing something wrong, but paperkey only seems to produce reasonably small output for DSA keys. RSA keys are still enormous. I've had pretty good luck with something like Paperback: http://www.ollydbg.de/Paperbak/index.html -- it backs up arbitrary data to printable 2D barcodes with error correction. Simply scan the paperback it'll reconstruct the original file. Thus one can direct backup and restore the exported private key file without too much trouble. I thought there was a *nix version, but I may be in error. Alternatively, one could have a shell script generate a QR code for each line of the exported private key file, then print the resulting files 10 to a page. I did this and, while annoying, it's not hideously inconvenient to restore the QR codes using nothing more than a webcam. Cheers! -Pete -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralph at inputplus.co.uk Sat Feb 4 20:10:15 2017 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sat, 04 Feb 2017 19:10:15 +0000 Subject: Key Used to Lookup Symmetric Passphrase. In-Reply-To: <20170203204945.29331213B6@orac.inputplus.co.uk> References: <20170203204945.29331213B6@orac.inputplus.co.uk> Message-ID: <20170204191015.81499213E5@orac.inputplus.co.uk> Hi, I wrote: > What's the key being used to look up the symmetric passphrase? Is it > something random stored in *.gpg and thus survives the rename? So I used `gpg --debug-level guru -d foo.gpg' and see the GET_PASSPHRASE --data --repeat=0 -- S08635B195E745ED6 X X Enter+passphrase%0A and from that found the code that shows S086... is eight bytes of random salt used for the symmetric encryption. > How can I list these in the manner of -k and -K? That question remains. Also, say I have three files symmetrically encrypted at different times with the same passphrase. I'd like the salt used on encryption to be the same for all three so I can decrypt them as needed but only tell gpg-agent the passphrase once. I'm guessing this can't currently be done and would welcome education on why not. :-) -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy From peter at digitalbrains.com Sat Feb 4 20:26:21 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 4 Feb 2017 20:26:21 +0100 Subject: Key Used to Lookup Symmetric Passphrase. In-Reply-To: <20170204191015.81499213E5@orac.inputplus.co.uk> References: <20170203204945.29331213B6@orac.inputplus.co.uk> <20170204191015.81499213E5@orac.inputplus.co.uk> Message-ID: <9bb03739-dea3-616c-c069-32ca1789779f@digitalbrains.com> I'd like to point out that one way of solving this completely differently is to encrypt to a private key on your keyring rather than using symmetric mode. Then GnuPG can trivially recognise it all can be decrypted with cached data. It doesn't have to be your usual OpenPGP key, you could create a key specifically for this purpose (and set it to ownertrust never if you will never use it to do Web of Trust stuff, just to make this fact clear to GnuPG). 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 From sivmu at web.de Sat Feb 4 21:14:50 2017 From: sivmu at web.de (sivmu) Date: Sat, 4 Feb 2017 21:14:50 +0100 Subject: Unecrypted download of public keys In-Reply-To: <87k296qv8w.fsf@alice.fifthhorseman.net> References: <95ee17c7-e1d8-e5c8-a8dc-e4c05c8f95d2@web.de> <87k296qv8w.fsf@alice.fifthhorseman.net> Message-ID: <9057ecf7-e5ff-8f0f-c7c1-751e6e3c69d5@web.de> Am 04.02.2017 um 08:18 schrieb Daniel Kahn Gillmor: > On Sat 2017-02-04 01:33:56 -0500, sivmu wrote: >> When using --revc-key or the gpa frontend, I noticed that the >> target public keys are still downloded using unencrypted http. While the >> trnasmitted information is generally public, it doesmake things pretty >> easy for an adversary to collect metadata such as your contacts. >> >> This is expecially relevant if you refresh your keys all at once, as >> this will leak your complete contact list to the network. >> >> Is there any reason gnupg does not use https by default to connect to >> the keyservers? I think this is an unnecessary leak of privacy. > > as of 2.1.18, gnupg does use https by default to connect to the > keyserver network. :) > > In particular, if you do not supply a --keyserver argument, it will use > hkps://hkps.pool.sks-keyservers.net as the default keyserver, and should > verify the certificates only against the pool-specific CA. > > --dkg > I suppose this config did not change after upgrading from 2.1.17. Just tested it on 2.1.18 using arch and it still uses http on my setup. But this would be rather an issue with the distro, correct? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Sat Feb 4 23:27:54 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 04 Feb 2017 17:27:54 -0500 Subject: Unecrypted download of public keys In-Reply-To: <9057ecf7-e5ff-8f0f-c7c1-751e6e3c69d5@web.de> References: <95ee17c7-e1d8-e5c8-a8dc-e4c05c8f95d2@web.de> <87k296qv8w.fsf@alice.fifthhorseman.net> <9057ecf7-e5ff-8f0f-c7c1-751e6e3c69d5@web.de> Message-ID: <87r33dpp5h.fsf@alice.fifthhorseman.net> On Sat 2017-02-04 15:14:50 -0500, sivmu wrote: > I suppose this config did not change after upgrading from 2.1.17. > Just tested it on 2.1.18 using arch and it still uses http on my setup. it's not a config change -- it's a defaults change. in the old arrangement, if you didn't specify a keyserver, you couldn't get anything at all, so many people put some keyserver in their configuration manually. if you have a "keyserver" listed in your config manually, then you are *overriding* the default. And yes, if you list foo.example.com, it will connect to that server in the clear (just as if you put hkps://foo.example.com then it would connect using TLS). Did you try this with no explicit "keyserver" directive? > But this would be rather an issue with the distro, correct? It may be an issue with your distro, i don't know how arch has packaged 2.1.18. all the best, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From sivmu at web.de Sun Feb 5 00:34:40 2017 From: sivmu at web.de (sivmu) Date: Sun, 5 Feb 2017 00:34:40 +0100 Subject: Unecrypted download of public keys In-Reply-To: <87r33dpp5h.fsf@alice.fifthhorseman.net> References: <95ee17c7-e1d8-e5c8-a8dc-e4c05c8f95d2@web.de> <87k296qv8w.fsf@alice.fifthhorseman.net> <9057ecf7-e5ff-8f0f-c7c1-751e6e3c69d5@web.de> <87r33dpp5h.fsf@alice.fifthhorseman.net> Message-ID: <43c3de28-809e-ba48-9061-3a0c71eab7ef@web.de> Am 04.02.2017 um 23:27 schrieb Daniel Kahn Gillmor: > On Sat 2017-02-04 15:14:50 -0500, sivmu wrote: >> I suppose this config did not change after upgrading from 2.1.17. >> Just tested it on 2.1.18 using arch and it still uses http on my setup. > > it's not a config change -- it's a defaults change. > > in the old arrangement, if you didn't specify a keyserver, you couldn't > get anything at all, so many people put some keyserver in their > configuration manually. > > if you have a "keyserver" listed in your config manually, then you are > *overriding* the default. And yes, if you list foo.example.com, it will > connect to that server in the clear (just as if you put > hkps://foo.example.com then it would connect using TLS). > > Did you try this with no explicit "keyserver" directive? > >> But this would be rather an issue with the distro, correct? > > It may be an issue with your distro, i don't know how arch has packaged > 2.1.18. > > all the best, > > --dkg > This is the script for the arch gnupg package: https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/gnupg But I do not see any sign of overriding the defaults and I never changed the settings either. I might just setup a new arch system in a VM and test this on a clean installation to make sure I did not mess something up. Could it be that installing gpa changed the defaults? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From ricul77 at gmail.com Mon Feb 6 10:37:00 2017 From: ricul77 at gmail.com (Richard Ulrich) Date: Mon, 06 Feb 2017 10:37:00 +0100 Subject: Estonian e-residency In-Reply-To: <3a7a13e7-0208-3b54-59a8-54a64d805636@andrewg.com> References: <1486036938.20899.16.camel@gmail.com> <3a7a13e7-0208-3b54-59a8-54a64d805636@andrewg.com> Message-ID: <1486373820.4935.11.camel@gmail.com> Hi?Andrew, of course it is better to directly sign the key. And it is also better if there is a short path in the web of trust. But my use case is for when there is no path at all in the web of trust. Most people I know don't even have a GPG key. And of the ones that have a key, chances are high that they don't have any signatures on it. So we sometimes resort to keybase.io. There the key is verified by some social media. Sure, if the social media profile have existed for some years and have some legitimate looking interactions, it is a good indicator that its not a face account. But still, I would trust a government verification more than social media. For example I bought a car last week with Bitcoin. The person that handled the payment for the seller was not present, but gave me his keybase.io user name on the phone. He signed the email containing the Bitcoin address for the payments with his GPG key. He didn't have any signatures on his key.? In this scenario I'm grateful for every piece of validation to give the key more credibility. Rgds Richard Am Donnerstag, den 02.02.2017, 13:42 +0000 schrieb Andrew Gallagher: > On 02/02/17 12:02, Richard Ulrich wrote: > > > > I thought about applying for Estonian e-residency for the sole > > reason of adding credibility to my GPG key. My idea would be to > > sign > > my GPG key with the ID card. This could give people who are not in > > my web of trust a head start. > Which particular people? And a head start at doing what? > > AIUI the e-residency signature is not PGP-compatible, so people will > need to verify it using a separate tool. And once I have verified > your > e-residency signature, what does it mean to me? At best, it tells me > that you are one of possibly many people known to the Estonian > Government as "Richard Ulrich". Unless I have already dealt with you > elsewhere via your Estonian ID, how does this help me? > > What particular problem are you trying to solve? It seems to me that > unless you are going to use your E-identity for some other purpose, > tying your GPG key to it adds little value. You say your sole reason > for applying for e-residency is to add "credibility" to your existing > key. But how is asking the Estonian government to verify your > passport > more credible than producing your passport at a keysigning party? Or > better still, showing it to the actual person you want to talk to? > > Andrew. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part URL: From miro.rovis at croatiafidelis.hr Tue Feb 7 00:01:52 2017 From: miro.rovis at croatiafidelis.hr (Miroslav Rovis) Date: Tue, 7 Feb 2017 00:01:52 +0100 Subject: ? Comments re key servers? re gpg-encrypted mail? re key servers carry many phony keys? In-Reply-To: <20170131002033.GA12861@g0n.xdwgrp> References: <5itw9prsds.fsf@fencepost.gnu.org> <6ac3703c-151e-f413-00b7-1996269c29ed@gmail.com> <20161228104343.GA19104@g0n.xdwgrp> <20161228122815.GA19720@g0n.xdwgrp> <97d82431-f4a5-d815-3f93-df8078aa93e8@gmail.com> <20170130234222.GA14408@g0n.xdwgrp> <20170131002033.GA12861@g0n.xdwgrp> Message-ID: <20170206230152.GG14668@g0n.xdwgrp> ( If viewed from the web, this email is a reply to this last January's email of the same title: https://marc.info/?l=mutt-users&m=147959541728176&w=2 ) I only (probably) need to close this issue, as a lot of the reasons for failure to get some keys (not all) was the key not being uploaded, or the lack of expertize on my part. On 170131-01:20+0100, Miroslav Rovis wrote: While most of it about GnuPG key over at: The GPG key is missing from common keyservers #143 > https://github.com/Synzvato/decentraleyes/issues/143 is solved, my issues also stem the prerequisites for securing my machine with grsecurity, meaning it does take some true understanding of Linux system to do it, else you can only fail... Here's how I have, almost completely, finally configured the RBAC policies for dirmngr, gpg-agent, gpgconf and gpg2: GnuPG programs RBAC policies https://forums.grsecurity.net/viewtopic.php?f=5&t=4662 Not so simple, is it, the above? Or are all readers here experts? ... Maybe just if anybody can confirm whether another key is or is not available from the common keyservers, as that is the only one that I haven't managed to receive yet, this one: 3F533109A9509B14 (I re-tried just a few minutes ago, no luck.) Such as in this message: https://www.mail-archive.com/mutt-users at mutt.org/msg50362.html DSA 3F533109A9509B14 Which I have in my mailbox, as I am subscribed to mutt-users... 2016-09-14 It's the key by the sender of, e.g. this message, but with another key: https://www.mail-archive.com/mutt-users at mutt.org/msg50487.html RSA DF48830BABD37425 <-- This key I was able to --recv-key just fine... 2016-11-19 ( spare other address: https://marc.info/?l=mutt-users&m=147959541728176&w=2 ) It's public mailing lists, I hope I'm not invading anybody's privacy by any means... And... I think I figured this out, as I'm writing this... That one is a DSA key, that the cryptographer might not even have posted to keyservers... I'm CC'ing to David Champion too. Am I right, David? Phew! Cryptography feels hard here too... Thanks for bearing with me! -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Digital signature URL: From antony at blazrsoft.com Tue Feb 7 00:51:11 2017 From: antony at blazrsoft.com (Antony Prince) Date: Mon, 6 Feb 2017 18:51:11 -0500 Subject: ? Comments re key servers? re gpg-encrypted mail? re key servers carry many phony keys? In-Reply-To: <20170206230152.GG14668@g0n.xdwgrp> References: <5itw9prsds.fsf@fencepost.gnu.org> <6ac3703c-151e-f413-00b7-1996269c29ed@gmail.com> <20161228104343.GA19104@g0n.xdwgrp> <20161228122815.GA19720@g0n.xdwgrp> <97d82431-f4a5-d815-3f93-df8078aa93e8@gmail.com> <20170130234222.GA14408@g0n.xdwgrp> <20170131002033.GA12861@g0n.xdwgrp> <20170206230152.GG14668@g0n.xdwgrp> Message-ID: <44b3cd67-3f06-0b25-ea28-fcec28e51795@blazrsoft.com> On 2/6/2017 6:01 PM, Miroslav Rovis wrote: > Maybe just if anybody can confirm whether another key is or is not > available from the common keyservers, as that is the only one that I > haven't managed to receive yet, this one: > > 3F533109A9509B14 $gpg --keyserver hkp://pool.sks-keyservers.net --recv-keys 3F533109A9509B14 gpg: keyserver receive failed: No data $gpg --keyserver hkp://pgp.mit.edu --recv-keys 3F533109A9509B14 gpg: keyserver receive failed: No data The key does not appear to be on either of those sets of keyservers. -- Antony -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 898 bytes Desc: OpenPGP digital signature URL: From miro.rovis at croatiafidelis.hr Tue Feb 7 09:16:44 2017 From: miro.rovis at croatiafidelis.hr (Miroslav Rovis) Date: Tue, 7 Feb 2017 09:16:44 +0100 Subject: ? Comments re key servers? re gpg-encrypted mail? re key servers carry many phony keys? In-Reply-To: <44b3cd67-3f06-0b25-ea28-fcec28e51795@blazrsoft.com> References: <5itw9prsds.fsf@fencepost.gnu.org> <6ac3703c-151e-f413-00b7-1996269c29ed@gmail.com> <20161228104343.GA19104@g0n.xdwgrp> <20161228122815.GA19720@g0n.xdwgrp> <97d82431-f4a5-d815-3f93-df8078aa93e8@gmail.com> <20170130234222.GA14408@g0n.xdwgrp> <20170131002033.GA12861@g0n.xdwgrp> <20170206230152.GG14668@g0n.xdwgrp> <44b3cd67-3f06-0b25-ea28-fcec28e51795@blazrsoft.com> Message-ID: <20170207081644.GA17442@g0n.xdwgrp> On 170206-18:51-0500, Antony Prince wrote: > On 2/6/2017 6:01 PM, Miroslav Rovis wrote: > > Maybe just if anybody can confirm whether another key is or is not > > available from the common keyservers, as that is the only one that I > > haven't managed to receive yet, this one: > > > > 3F533109A9509B14 > > $gpg --keyserver hkp://pool.sks-keyservers.net --recv-keys 3F533109A9509B14 > gpg: keyserver receive failed: No data > > $gpg --keyserver hkp://pgp.mit.edu --recv-keys 3F533109A9509B14 > gpg: keyserver receive failed: No data > Thanks! > The key does not appear to be on either of those sets of keyservers. > Some likelihood now apparently being that it was kind of a user-failed key... But there are no keys that the user may create, sign messages with, and then successfully abandon and get the web to just forget about them, I'm afraid... It the case is such, should the owner revoke it and post the revocation cert? An awkward situation, isn't it... But we would need a confirmation that we are right about the unavailability of this key from keyservers, or an affirmation of the availability thereof, from the owner (CC'd all the time since the suspicion arose). But I'm fine, if this matter is now preferred left aside, as far as possible... Regards! -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Digital signature URL: From andrewg at andrewg.com Tue Feb 7 12:33:30 2017 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 7 Feb 2017 11:33:30 +0000 Subject: Estonian e-residency In-Reply-To: <1486373820.4935.11.camel@gmail.com> References: <1486036938.20899.16.camel@gmail.com> <3a7a13e7-0208-3b54-59a8-54a64d805636@andrewg.com> <1486373820.4935.11.camel@gmail.com> Message-ID: On 06/02/17 09:37, Richard Ulrich wrote: > So we sometimes resort to keybase.io. There the key is verified by > some social media. Sure, if the social media profile have existed > for some years and have some legitimate looking interactions, it is > a good indicator that its not a face account. But still, I would > trust a government verification more than social media. keybase.io is a great idea. But its main use is to tie a PGP key to a social media account or accounts that act as a surrogate web of trust (by being referenced in multiple independent places by hopefully reputable third parties). But if your correspondent's social network does not overlap with yours, again I'm not sure much value is added. > For example I bought a car last week with Bitcoin. The person that > handled the payment for the seller was not present, but gave me his > keybase.io user name on the phone. He signed the email containing > the Bitcoin address for the payments with his GPG key. He didn't > have any signatures on his key. I'm not sure I would have the cojones to follow through with this deal, signatures or no. ;-) > In this scenario I'm grateful for every piece of validation to give > the key more credibility. In a scenario where you do not know the intermediary, the only meaningful validation is whether the vendor vouches for both the intermediary's person and key. The fact that the intermediary offers you *an* identity doesn't mean you are validating the correct identity. If for example he had given you a key signed by a Russian government agency, would you have had more confidence? Granted, you like (and obviously trust to some extent) the Estonian e-ID system. Others might not have so much faith. Sorry if I'm coming across as a little harsh, but you are proposing spending hard cash and I'd hate to see you do so and not get your money's worth. By all means, get an e-ID for the fun, for experiment, or to start up a company. But signing PGP keys with it is non-standard, and it's hard enough to convince most people to verify keys via standard methods. The problem with any PKI (which we still haven't cracked) is that the motivation to get your key signed is "How do I prove my identity to others", while the motivation of the person verifying the key is "To what extent should I trust this person". And unfortunately, the two questions are far from equivalent. A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From marko.bauhardt at mailbox.org Wed Feb 8 08:23:18 2017 From: marko.bauhardt at mailbox.org (Marko Bauhardt) Date: Wed, 8 Feb 2017 08:23:18 +0100 Subject: content of private-keys-v1.d Message-ID: <70CFA0A0-41DA-4587-9E7B-DA326ABADF4C@mailbox.org> Hi, I?m using GPG 2.0.30 on osx. My goal is to not save any private key on any machine i?m using. So i bought me a smart card (yubikey) to save my private keys there. I have 3 keys, sign/encrypt/auth. Everything works so far. I?m using the gpg-agent to use my authentication subkey from my yubikey to login on a ssh machine. It works also. But in this case a new key is generated under `gnupg/private-keys-v1.d`. My question is. What is this for a key and for what is that key used for? The folder name `private-keys-v1.d` sounds like to store keys from GPG version 1.x. But i?m using 2.0.x. Any comments about his folder? As i said before, i want to not save any key on my machine. And for now i?m not sure if i reach this goal because this new key sounds like it is a private key. Thanks Marko --- Marko Bauhardt marko.bauhardt at mailbox.org Key ID: 53192101 Fingerprint: DC0F E851 82A3 72E3 7FE1 ACDB 970C FD47 5319 2101 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From marko.bauhardt at mailbox.org Wed Feb 8 08:29:33 2017 From: marko.bauhardt at mailbox.org (Marko Bauhardt) Date: Wed, 8 Feb 2017 08:29:33 +0100 Subject: effect of revuid In-Reply-To: <87lgtmu14a.fsf@alice.fifthhorseman.net> References: <87lgtmu14a.fsf@alice.fifthhorseman.net> Message-ID: <892DBF52-8465-46F3-9727-83AB84F08535@mailbox.org> > On 04 Feb 2017, at 03:43, Daniel Kahn Gillmor wrote: > > revuid does not delete a User ID, it revokes a user ID. On a typical > OpenPGP certificate, a revoked User ID is still present, but it is > marked clearly and verifiably as having been revoked. Ok. Thanks. > > Note that if you just do your revocation locally and don't find a way to > get it to your correspondents (e.g. by publishing to the keyservers, and > hoping that they all refresh regularly) then no one will know about it, > and from their point of view the User ID will not be revoked. Sure. Got it. > > > The primary key and its subkeys are still valid, yes. If you revoke the > last User ID, then arguably a cleaned version of your certificate > (without any User IDs) will not be considered a valid "transferable > public key" because it will have no User ID associated. > Oki thx. > > even if your certificate as a whole is explicitly revoked, the > mathematical object that is the secret key still exists, and can still > perform whatever operations you require of it. So yes, you should be > able to decrypt anything encrypted to any secret key you hold, > regardless of whether the certificates that contain those keys are > valid, revoked, expired, or whatever. Nice. This is an important answer. > > make sense? > Yes, totally. Thx for explanation. --- Marko Bauhardt marko.bauhardt at mailbox.org Key ID: 53192101 Fingerprint: DC0F E851 82A3 72E3 7FE1 ACDB 970C FD47 5319 2101 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ricul77 at gmail.com Wed Feb 8 09:41:33 2017 From: ricul77 at gmail.com (Richard Ulrich) Date: Wed, 08 Feb 2017 09:41:33 +0100 Subject: Estonian e-residency In-Reply-To: References: <1486036938.20899.16.camel@gmail.com> <3a7a13e7-0208-3b54-59a8-54a64d805636@andrewg.com> <1486373820.4935.11.camel@gmail.com> Message-ID: <1486543293.4353.7.camel@gmail.com> Am Dienstag, den 07.02.2017, 11:33 +0000 schrieb Andrew Gallagher: > On 06/02/17 09:37, Richard Ulrich wrote: > > > > So we sometimes resort to keybase.io. There the key is verified by? > > some social media. Sure, if the social media profile have existed? > > for some years and have some legitimate looking interactions, it is > > a good indicator that its not a face account. But still, I would? > > trust a government verification more than social media. > keybase.io is a great idea. But its main use is to tie a PGP key to a > social media account or accounts that act as a surrogate web of trust > (by being referenced in multiple independent places by hopefully > reputable third parties). But if your correspondent's social network > does not overlap with yours, again I'm not sure much value is added. Every piece adds to the probability of the key being valid. > > For example I bought a car last week with Bitcoin. The person that? > > handled the payment for the seller was not present, but gave me > > his? > > keybase.io user name on the phone. He signed the email containing? > > the Bitcoin address for the payments with his GPG key. He didn't? > > have any signatures on his key. > I'm not sure I would have the cojones to follow through with this > deal, > signatures or no. ;-) > > > > > In this scenario I'm grateful for every piece of validation to give > > the key more credibility. > In a scenario where you do not know the intermediary, the only > meaningful validation is whether the vendor vouches for both the > intermediary's person and key. The fact that the intermediary > offers you *an* identity doesn't mean you are validating the correct > identity. He is the business partner of the son of the seller. The son was present and wrote the info down for me. > If for example he had given you a key signed by a Russian government > agency, would you have had more confidence? Granted, you like (and > obviously trust to some extent) the Estonian e-ID system. Others > might > not have so much faith. > > Sorry if I'm coming across as a little harsh, but you are proposing > spending hard cash and I'd hate to see you do so and not get your > money's worth. By all means, get an e-ID for the fun, for experiment, > or to start up a company. But signing PGP keys with it is non- > standard, > and it's hard enough to convince most people to verify > keys via standard methods. > > The problem with any PKI (which we still haven't cracked) is that the > motivation to get your key signed is "How do I prove my identity to > others", while the motivation of the person verifying the key is "To > what extent should I trust this person". And unfortunately, the two > questions are far from equivalent. Usually the prove of identity is done with government issued IDs. So the estonian e-residency smart card is not so much different in that regard. Of course it would be better if every country issued something like that to its citizens. And even better if that was compatible with GPG. But until that happens we might have to improvise sometimes. There is also SuisseID somehow similar, but the cost is so high that nobody is interested.? Rgds Richard > > A > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part URL: From dgouttegattat at incenp.org Wed Feb 8 10:17:03 2017 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Wed, 8 Feb 2017 10:17:03 +0100 Subject: content of private-keys-v1.d In-Reply-To: <70CFA0A0-41DA-4587-9E7B-DA326ABADF4C@mailbox.org> References: <70CFA0A0-41DA-4587-9E7B-DA326ABADF4C@mailbox.org> Message-ID: <950fc426-29af-9045-aec8-cbb649f8bc62@incenp.org> Hi, On 02/08/2017 08:23 AM, Marko Bauhardt wrote: > My question is. What is this for a key and for what is that key used > for? The folder name `private-keys-v1.d` sounds like to store keys > from GPG version 1.x. But i?m using 2.0.x. Any comments about his > folder? This folder holds all the private keys. It was initially used only by gpgsm (for S/MIME keys), but since GnuPG 2.1 it is also used by gpg (for OpenPGP keys). The "v1" part in the name has nothing to do with the version of GnuPG. > As i said before, i want to not save any key on my machine. And for > now i?m not sure if i reach this goal because this new key sounds > like it is a private key. Even when your private keys are stored on a smartcard, you would still have a corresponding file in the private-keys-v1.d directory. But this file is only a "stub", that is, it only tells GnuPG that the actual key material is stored on a smartcard. Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From marko.bauhardt at mailbox.org Wed Feb 8 12:13:06 2017 From: marko.bauhardt at mailbox.org (Marko Bauhardt) Date: Wed, 8 Feb 2017 12:13:06 +0100 Subject: content of private-keys-v1.d In-Reply-To: <950fc426-29af-9045-aec8-cbb649f8bc62@incenp.org> References: <70CFA0A0-41DA-4587-9E7B-DA326ABADF4C@mailbox.org> <950fc426-29af-9045-aec8-cbb649f8bc62@incenp.org> Message-ID: <0308E0A6-E071-4115-B81D-51F7CE153C71@mailbox.org> > On 08 Feb 2017, at 10:17, Damien Goutte-Gattat > wrote: > > Even when your private keys are stored on a smartcard, you would still have a corresponding file in the private-keys-v1.d directory. But this file is only a "stub", that is, it only tells GnuPG that the actual key material is stored on a smart card. You mean that this ?stub? contains no information which can be use to sign/decrypt/authenticate? Or in other words in case someone steal this key, he/she can nothing do with that particular key, only in case the GPG key is located on a smartcard? But if the key is not on the smart card this corresponding key can be use to sign/enc/auth? I can not really find some detailed documentation of the `private-keys-v1.d` folder. Do you have some docu? thx Marko --- Marko Bauhardt marko.bauhardt at mailbox.org GPG Key ID: 53192101 GPG Fingerprint: DC0F E851 82A3 72E3 7FE1 ACDB 970C FD47 5319 2101 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dgouttegattat at incenp.org Wed Feb 8 13:31:25 2017 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Wed, 8 Feb 2017 13:31:25 +0100 Subject: content of private-keys-v1.d In-Reply-To: <0308E0A6-E071-4115-B81D-51F7CE153C71@mailbox.org> References: <70CFA0A0-41DA-4587-9E7B-DA326ABADF4C@mailbox.org> <950fc426-29af-9045-aec8-cbb649f8bc62@incenp.org> <0308E0A6-E071-4115-B81D-51F7CE153C71@mailbox.org> Message-ID: <9d41fe16-8a80-38f5-34d0-ce5c2e47169f@incenp.org> On 02/08/2017 12:13 PM, Marko Bauhardt wrote: > You mean that this ?stub? contains no information which can be use to > sign/decrypt/authenticate? Yes. The stub contains only the serial number of the smartcard on which the private key is stored. > Or in other words in case someone steal this key, he/she can nothing > do with that particular key, only in case the GPG key is located on > a smartcard? The stub is completely useless without the corresponding smartcard, yes. > But if the key is not on the smart card this corresponding key can > be use to sign/enc/auth? If the key is not on a smartcard, then the file contains the whole private key. Note, however, that the key is stored in an encrypted form, which means that stealing the file is not enough: your attacker would also need to know your passphrase to make any use of the key. > I can not really find some detailed documentation of the > `private-keys-v1.d` folder. Do you have some docu? I don't think it has really been documented. I guess the source code *is* the documentation. Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From jfschaff at gmail.com Wed Feb 8 12:52:27 2017 From: jfschaff at gmail.com (=?UTF-8?Q?Jean=2DFran=C3=A7ois_Schaff?=) Date: Wed, 8 Feb 2017 12:52:27 +0100 Subject: Problems with GPGME1.8 and Python 3.5 bindings Message-ID: Hi, I'm new to gpg, and trying to use the Python bindings included in PGPME. I'm using Ubuntu 16.04 LTS. I have done the following things: - compiled and installed libgpg-error-1.26 - compiled and installed libassuan-2.4.3 - installed swig2.0 (sudo apt-get install swig2.0) - installed python3-dev package (sudo apt-get install python3-dev) - compiled and installed gpgme-1.8.0 Everything seems to build and install as expected, but when I finally try to use the python package (import gpg) I get the following error: (venv) jfs at Danube-linux:~/webdev/mms$ python Python 3.5.2 (default, Nov 17 2016, 17:05:23) [GCC 5.4.0 20160609] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import gpg Traceback (most recent call last): File "", line 1, in File "/home/jfs/webdev/mms/venv/local/lib/python3.5/site-packages/gpg/__init__.py", line 101, in from . import core File "/home/jfs/webdev/mms/venv/local/lib/python3.5/site-packages/gpg/core.py", line 34, in from . import gpgme File "/home/jfs/webdev/mms/venv/local/lib/python3.5/site-packages/gpg/gpgme.py", line 28, in _gpgme = swig_import_helper() File "/home/jfs/webdev/mms/venv/local/lib/python3.5/site-packages/gpg/gpgme.py", line 24, in swig_import_helper _mod = imp.load_module('_gpgme', fp, pathname, description) File "/home/jfs/webdev/mms/venv/lib/python3.5/imp.py", line 242, in load_module return load_dynamic(name, filename, file) File "/home/jfs/webdev/mms/venv/lib/python3.5/imp.py", line 342, in load_dynamic return _load(spec) ImportError: /home/jfs/webdev/mms/venv/local/lib/python3.5/site-packages/gpg/_gpgme.cpython-35m-x86_64-linux-gnu.so: symbol gpgme_pubkey_algo_string, version GPGME_1.1 not defined in file libgpgme.so.11 with link time reference >>> Am I doing something wrong? Note that I'm running that in the virtual environment, not sure if that could be related... Any help would be greatly appreciated :-) Jean-Fran?ois Schaff From wk at gnupg.org Wed Feb 8 18:25:03 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 08 Feb 2017 18:25:03 +0100 Subject: content of private-keys-v1.d In-Reply-To: <9d41fe16-8a80-38f5-34d0-ce5c2e47169f@incenp.org> (Damien Goutte-Gattat's message of "Wed, 8 Feb 2017 13:31:25 +0100") References: <70CFA0A0-41DA-4587-9E7B-DA326ABADF4C@mailbox.org> <950fc426-29af-9045-aec8-cbb649f8bc62@incenp.org> <0308E0A6-E071-4115-B81D-51F7CE153C71@mailbox.org> <9d41fe16-8a80-38f5-34d0-ce5c2e47169f@incenp.org> Message-ID: <878tpgh9xs.fsf@wheatstone.g10code.de> On Wed, 8 Feb 2017 13:31, dgouttegattat at incenp.org said: > I don't think it has really been documented. I guess the source code > *is* the documentation. The format of the private key files is documented in gnupg/agent/keyformat.txt Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dgouttegattat at incenp.org Wed Feb 8 18:40:21 2017 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Wed, 8 Feb 2017 18:40:21 +0100 Subject: content of private-keys-v1.d In-Reply-To: <878tpgh9xs.fsf@wheatstone.g10code.de> References: <70CFA0A0-41DA-4587-9E7B-DA326ABADF4C@mailbox.org> <950fc426-29af-9045-aec8-cbb649f8bc62@incenp.org> <0308E0A6-E071-4115-B81D-51F7CE153C71@mailbox.org> <9d41fe16-8a80-38f5-34d0-ce5c2e47169f@incenp.org> <878tpgh9xs.fsf@wheatstone.g10code.de> Message-ID: <1fde4b4f-93c4-7442-cfa3-4b0ae927ccd3@incenp.org> On 02/08/2017 06:25 PM, Werner Koch wrote: > The format of the private key files is documented in > > gnupg/agent/keyformat.txt Obviously I had completely overlooked this file, my bad. Sorry for the disinformation. It's good to know that the documentation is there. Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From marko.bauhardt at mailbox.org Wed Feb 8 19:15:29 2017 From: marko.bauhardt at mailbox.org (Marko Bauhardt) Date: Wed, 8 Feb 2017 19:15:29 +0100 Subject: content of private-keys-v1.d In-Reply-To: <9d41fe16-8a80-38f5-34d0-ce5c2e47169f@incenp.org> References: <70CFA0A0-41DA-4587-9E7B-DA326ABADF4C@mailbox.org> <950fc426-29af-9045-aec8-cbb649f8bc62@incenp.org> <0308E0A6-E071-4115-B81D-51F7CE153C71@mailbox.org> <9d41fe16-8a80-38f5-34d0-ce5c2e47169f@incenp.org> Message-ID: <6E8115C7-08F9-429E-980A-FC32BB57CC71@mailbox.org> > > I don't think it has really been documented. I guess the source code *is* the documentation. ;). Understand hehe. Thanks a lot for all your answers! Marko From basil at basilbecker.de Wed Feb 8 17:34:40 2017 From: basil at basilbecker.de (Dr. Basil Becker) Date: Wed, 8 Feb 2017 17:34:40 +0100 Subject: Non-deterministic behavior using GnuPG and a smart-card Message-ID: <7e11c278-013b-6edb-6e11-b0452c79ba18@basilbecker.de> Hi everyone, since a few days I'm observing a rather non-deterministic behavior, where GnuPG sometimes fails to find my private key, that is located at a smart-card and sometimes everything works. I wrote about the problem in more detail at launchpad.net https://answers.launchpad.net/ubuntu/+source/gnupg/+question/452490 However, if anyone of you has an idea, what the problem could be, I'd be pleased to hear about it. Cheers, Basil -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 634 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Wed Feb 8 20:05:49 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 8 Feb 2017 20:05:49 +0100 Subject: Non-deterministic behavior using GnuPG and a smart-card In-Reply-To: <7e11c278-013b-6edb-6e11-b0452c79ba18@basilbecker.de> References: <7e11c278-013b-6edb-6e11-b0452c79ba18@basilbecker.de> Message-ID: <8fd6e0d6-88a1-6a9e-3782-6142a024e4f6@digitalbrains.com> Hello, > I wrote about the problem in more detail at launchpad.net > https://answers.launchpad.net/ubuntu/+source/gnupg/+question/452490 I think it is appreciated if you actually describe the problem on the mailing list itself rather than only linking to a website. And you're also losing those people who would have read the mail and had an idea but can't be bothered to chase the link. > However, if anyone of you has an idea, what the problem could be, > I'd be pleased to hear about it. Please provide error messages and other exact output, that gives people more insight than "for some others no private key could be found". And since it also happens at the command line (that's good! It makes including everything easier), you could add -vv for verbosity or even --debug-flags to dig deeper into the problematic encryptions. 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 basil at basilbecker.de Wed Feb 8 22:20:56 2017 From: basil at basilbecker.de (Dr. Basil Becker) Date: Wed, 8 Feb 2017 22:20:56 +0100 Subject: Non-deterministic behavior using GnuPG and a smart-card In-Reply-To: <8fd6e0d6-88a1-6a9e-3782-6142a024e4f6@digitalbrains.com> References: <7e11c278-013b-6edb-6e11-b0452c79ba18@basilbecker.de> <8fd6e0d6-88a1-6a9e-3782-6142a024e4f6@digitalbrains.com> Message-ID: Hello, Peter, thanks for the clarification. I understand your point ;) On 08.02.2017 20:05, Peter Lebbing wrote: > Hello, > >> I wrote about the problem in more detail at launchpad.net >> https://answers.launchpad.net/ubuntu/+source/gnupg/+question/452490 > > I think it is appreciated if you actually describe the problem on the > mailing list itself rather than only linking to a website. > I'm having a setup consisting of a main key, and three sub-keys for encryption, authorization and signature. The three sub-keys are stored on a Yubikey 4 smart-card. Authentication and signatures work like a charme. I'm only having problems concerning the decryption of mails I received. I'm using thunderbird together with enigmail to read my mails, but as the problem also occurrs at the CLI, I assume that enigmail is not part of the puzzle. Well, some messages could be successfully decrypted: bb at melmac:~$ gpg2 -vv --output /dev/null -d /tmp/message.txt gpg: armor: BEGIN PGP MESSAGE gpg: armor header: Version: GnuPG v2 # off=0 ctb=85 tag=1 hlen=3 plen=400 :pubkey enc packet: version 3, algo 1, keyid DBC1D85BA9D1D189 data: [3103 bits] gpg: public key is 0xDBC1D85BA9D1D189 gpg: using subkey 0xDBC1D85BA9D1D189 instead of primary key 0x8501968486DF0281 gpg: public key encrypted data: good DEK # off=403 ctb=d2 tag=18 hlen=2 plen=0 partial new-ctb :encrypted data packet: length: unknown mdc_method: 2 gpg: using subkey 0xDBC1D85BA9D1D189 instead of primary key 0x8501968486DF0281 gpg: encrypted with 3104-bit RSA key, ID 0xDBC1D85BA9D1D189, created 2017-01-10 "Dr. Basil Becker " gpg: AES256 encrypted data # off=424 ctb=a3 tag=8 hlen=1 plen=0 indeterminate :compressed packet: algo=2 # off=426 ctb=cb tag=11 hlen=2 plen=0 partial new-ctb :literal data packet: mode b (62), created 1486478293, name="", raw data: unknown length gpg: original file name='' gpg: decryption okay Some messages, however, fail to decrypt: bb at melmac:~$ gpg2 -vv --output /dev/null -d /tmp/message-fail.txt gpg: armor: BEGIN PGP MESSAGE gpg: armor header: Version: GnuPG v2 # off=0 ctb=85 tag=1 hlen=3 plen=400 :pubkey enc packet: version 3, algo 1, keyid DBC1D85BA9D1D189 data: [3104 bits] gpg: public key is 0xDBC1D85BA9D1D189 gpg: using subkey 0xDBC1D85BA9D1D189 instead of primary key 0x8501968486DF0281 # off=403 ctb=d2 tag=18 hlen=2 plen=0 partial new-ctb :encrypted data packet: length: unknown mdc_method: 2 gpg: using subkey 0xDBC1D85BA9D1D189 instead of primary key 0x8501968486DF0281 gpg: encrypted with 3104-bit RSA key, ID 0xDBC1D85BA9D1D189, created 2017-01-10 "Dr. Basil Becker " gpg: public key decryption failed: Hardware problem gpg: decryption failed: No secret key The only difference I see, is that the pubkey data is 3103 bits vs 3104 bits. Unfortunately, I have no idea, whether this is a meaningful difference and if this If anyone could help me identifying what my problem is or even to solve it, I'd appreciate it :) If you need any additional information or dedicated log-output, I'm happy to provide it. Cheers, Basil -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 634 bytes Desc: OpenPGP digital signature URL: From basil at basilbecker.de Wed Feb 8 23:06:28 2017 From: basil at basilbecker.de (Dr. Basil Becker) Date: Wed, 8 Feb 2017 23:06:28 +0100 Subject: Non-deterministic behavior using GnuPG and a smart-card In-Reply-To: References: <7e11c278-013b-6edb-6e11-b0452c79ba18@basilbecker.de> <8fd6e0d6-88a1-6a9e-3782-6142a024e4f6@digitalbrains.com> Message-ID: On 08.02.2017 23:03, Adam Sherman wrote: > Is it always the same files that aren't decrypting, or is it truly random? > Yes, if I'm able to decrypt a mail, I'm always able to it. Unfortunately this holds also true for those mails, I can't decrypt. I should also add, that I don't have any problems, when I read the mails on my smartphone using K9 and Openkeychain. > On Wed, Feb 8, 2017 at 16:22 Dr. Basil Becker > wrote: > > Hello, > > Peter, thanks for the clarification. I understand your point ;) > > On 08.02.2017 20:05, Peter Lebbing wrote: > > Hello, > > > >> I wrote about the problem in more detail at launchpad.net > > >> https://answers.launchpad.net/ubuntu/+source/gnupg/+question/452490 > > > > I think it is appreciated if you actually describe the problem on the > > mailing list itself rather than only linking to a website. > > > I'm having a setup consisting of a main key, and three sub-keys for > encryption, authorization and signature. The three sub-keys are stored > on a Yubikey 4 smart-card. > > Authentication and signatures work like a charme. I'm only having > problems concerning the decryption of mails I received. I'm using > thunderbird together with enigmail to read my mails, but as the problem > also occurrs at the CLI, I assume that enigmail is not part of the > puzzle. > > Well, some messages could be successfully decrypted: > bb at melmac:~$ gpg2 -vv --output /dev/null -d /tmp/message.txt > gpg: armor: BEGIN PGP MESSAGE > gpg: armor header: Version: GnuPG v2 > # off=0 ctb=85 tag=1 hlen=3 plen=400 > :pubkey enc packet: version 3, algo 1, keyid DBC1D85BA9D1D189 > data: [3103 bits] > gpg: public key is 0xDBC1D85BA9D1D189 > gpg: using subkey 0xDBC1D85BA9D1D189 instead of primary key > 0x8501968486DF0281 > gpg: public key encrypted data: good DEK > # off=403 ctb=d2 tag=18 hlen=2 plen=0 partial new-ctb > :encrypted data packet: > length: unknown > mdc_method: 2 > gpg: using subkey 0xDBC1D85BA9D1D189 instead of primary key > 0x8501968486DF0281 > gpg: encrypted with 3104-bit RSA key, ID 0xDBC1D85BA9D1D189, created > 2017-01-10 > "Dr. Basil Becker >" > gpg: AES256 encrypted data > # off=424 ctb=a3 tag=8 hlen=1 plen=0 indeterminate > :compressed packet: algo=2 > # off=426 ctb=cb tag=11 hlen=2 plen=0 partial new-ctb > :literal data packet: > mode b (62), created 1486478293, name="", > raw data: unknown length > gpg: original file name='' > gpg: decryption okay > > > Some messages, however, fail to decrypt: > bb at melmac:~$ gpg2 -vv --output /dev/null -d /tmp/message-fail.txt > gpg: armor: BEGIN PGP MESSAGE > gpg: armor header: Version: GnuPG v2 > # off=0 ctb=85 tag=1 hlen=3 plen=400 > :pubkey enc packet: version 3, algo 1, keyid DBC1D85BA9D1D189 > data: [3104 bits] > gpg: public key is 0xDBC1D85BA9D1D189 > gpg: using subkey 0xDBC1D85BA9D1D189 instead of primary key > 0x8501968486DF0281 > # off=403 ctb=d2 tag=18 hlen=2 plen=0 partial new-ctb > :encrypted data packet: > length: unknown > mdc_method: 2 > gpg: using subkey 0xDBC1D85BA9D1D189 instead of primary key > 0x8501968486DF0281 > gpg: encrypted with 3104-bit RSA key, ID 0xDBC1D85BA9D1D189, created > 2017-01-10 > "Dr. Basil Becker >" > gpg: public key decryption failed: Hardware problem > gpg: decryption failed: No secret key > > The only difference I see, is that the pubkey data is 3103 bits vs 3104 > bits. Unfortunately, I have no idea, whether this is a meaningful > difference and if this > > If anyone could help me identifying what my problem is or even to solve > it, I'd appreciate it :) If you need any additional information or > dedicated log-output, I'm happy to provide it. > > Cheers, > Basil > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > -- > Adam Sherman > Directeur des op?rations, Sauvetage b?n?vole Outaouais > Director of Operations, Ottawa Volunteer SAR > CTO, Versature Corp. > +1 613 797 6819 -- Dr. Basil Becker m: basil at basilbecker.de Haeckelstr. 12 t: 0163 6538837 14471 Potsdam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 634 bytes Desc: OpenPGP digital signature URL: From basil at basilbecker.de Wed Feb 8 23:29:40 2017 From: basil at basilbecker.de (Dr. Basil Becker) Date: Wed, 8 Feb 2017 23:29:40 +0100 Subject: Non-deterministic behavior using GnuPG and a smart-card In-Reply-To: References: <7e11c278-013b-6edb-6e11-b0452c79ba18@basilbecker.de> <8fd6e0d6-88a1-6a9e-3782-6142a024e4f6@digitalbrains.com> Message-ID: <4284fd2c-04ed-00ba-c05a-870987432a95@basilbecker.de> On 08.02.2017 23:25, Adam Sherman wrote: > Maybe there is an algorithm that the Yubukey can't handle? > Eventually, but I'm a) pretty sure that always the same software has been used to encrypt the mails (it is done by my mail provider). And I'm using the Yubikey on my smartphone, too. > Or, maybe Enigmail is calling "gpg" instead of "gpg2"? > gpg is set to be an alias for gpg2 and enigmail states in its settings, that it is running /usr/bin/gpg2 And some of my mails could be decrypted... > I'm just brainstorming. > I appreciate it :) Cheers, Basil > A. > > On Wed, Feb 8, 2017 at 17:06 Dr. Basil Becker > wrote: > > > > On 08.02.2017 23:03, Adam Sherman wrote: > > Is it always the same files that aren't decrypting, or is it truly > random? > > > Yes, if I'm able to decrypt a mail, I'm always able to it. Unfortunately > this holds also true for those mails, I can't decrypt. > > I should also add, that I don't have any problems, when I read the mails > on my smartphone using K9 and Openkeychain. > > > > On Wed, Feb 8, 2017 at 16:22 Dr. Basil Becker > > > >> wrote: > > > > Hello, > > > > Peter, thanks for the clarification. I understand your point ;) > > > > On 08.02.2017 20:05, Peter Lebbing wrote: > > > Hello, > > > > > >> I wrote about the problem in more detail at launchpad.net > > > > > >> > https://answers.launchpad.net/ubuntu/+source/gnupg/+question/452490 > > > > > > I think it is appreciated if you actually describe the > problem on the > > > mailing list itself rather than only linking to a website. > > > > > I'm having a setup consisting of a main key, and three > sub-keys for > > encryption, authorization and signature. The three sub-keys > are stored > > on a Yubikey 4 smart-card. > > > > Authentication and signatures work like a charme. I'm only having > > problems concerning the decryption of mails I received. I'm using > > thunderbird together with enigmail to read my mails, but as > the problem > > also occurrs at the CLI, I assume that enigmail is not part of the > > puzzle. > > > > Well, some messages could be successfully decrypted: > > bb at melmac:~$ gpg2 -vv --output /dev/null -d /tmp/message.txt > > gpg: armor: BEGIN PGP MESSAGE > > gpg: armor header: Version: GnuPG v2 > > # off=0 ctb=85 tag=1 hlen=3 plen=400 > > :pubkey enc packet: version 3, algo 1, keyid DBC1D85BA9D1D189 > > data: [3103 bits] > > gpg: public key is 0xDBC1D85BA9D1D189 > > gpg: using subkey 0xDBC1D85BA9D1D189 instead of primary key > > 0x8501968486DF0281 > > gpg: public key encrypted data: good DEK > > # off=403 ctb=d2 tag=18 hlen=2 plen=0 partial new-ctb > > :encrypted data packet: > > length: unknown > > mdc_method: 2 > > gpg: using subkey 0xDBC1D85BA9D1D189 instead of primary key > > 0x8501968486DF0281 > > gpg: encrypted with 3104-bit RSA key, ID 0xDBC1D85BA9D1D189, > created > > 2017-01-10 > > "Dr. Basil Becker > > >>" > > gpg: AES256 encrypted data > > # off=424 ctb=a3 tag=8 hlen=1 plen=0 indeterminate > > :compressed packet: algo=2 > > # off=426 ctb=cb tag=11 hlen=2 plen=0 partial new-ctb > > :literal data packet: > > mode b (62), created 1486478293, name="", > > raw data: unknown length > > gpg: original file name='' > > gpg: decryption okay > > > > > > Some messages, however, fail to decrypt: > > bb at melmac:~$ gpg2 -vv --output /dev/null -d /tmp/message-fail.txt > > gpg: armor: BEGIN PGP MESSAGE > > gpg: armor header: Version: GnuPG v2 > > # off=0 ctb=85 tag=1 hlen=3 plen=400 > > :pubkey enc packet: version 3, algo 1, keyid DBC1D85BA9D1D189 > > data: [3104 bits] > > gpg: public key is 0xDBC1D85BA9D1D189 > > gpg: using subkey 0xDBC1D85BA9D1D189 instead of primary key > > 0x8501968486DF0281 > > # off=403 ctb=d2 tag=18 hlen=2 plen=0 partial new-ctb > > :encrypted data packet: > > length: unknown > > mdc_method: 2 > > gpg: using subkey 0xDBC1D85BA9D1D189 instead of primary key > > 0x8501968486DF0281 > > gpg: encrypted with 3104-bit RSA key, ID 0xDBC1D85BA9D1D189, > created > > 2017-01-10 > > "Dr. Basil Becker > > >>" > > gpg: public key decryption failed: Hardware problem > > gpg: decryption failed: No secret key > > > > The only difference I see, is that the pubkey data is 3103 > bits vs 3104 > > bits. Unfortunately, I have no idea, whether this is a meaningful > > difference and if this > > > > If anyone could help me identifying what my problem is or even > to solve > > it, I'd appreciate it :) If you need any additional information or > > dedicated log-output, I'm happy to provide it. > > > > Cheers, > > Basil > > > > > > _______________________________________________ > > Gnupg-users mailing list > > Gnupg-users at gnupg.org > > > > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > > > -- > > Adam Sherman > > Directeur des op?rations, Sauvetage b?n?vole Outaouais > > Director of Operations, Ottawa Volunteer SAR > > CTO, Versature Corp. > > +1 613 797 6819 > > -- > Dr. Basil Becker m: basil at basilbecker.de > > Haeckelstr. 12 t: 0163 6538837 > 14471 Potsdam > > -- > Adam Sherman > Directeur des op?rations, Sauvetage b?n?vole Outaouais > Director of Operations, Ottawa Volunteer SAR > CTO, Versature Corp. > +1 613 797 6819 -- Dr. Basil Becker m: basil at basilbecker.de Haeckelstr. 12 t: 0163 6538837 14471 Potsdam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 634 bytes Desc: OpenPGP digital signature URL: From adam at sherman.ca Wed Feb 8 23:25:23 2017 From: adam at sherman.ca (Adam Sherman) Date: Wed, 08 Feb 2017 22:25:23 +0000 Subject: Non-deterministic behavior using GnuPG and a smart-card In-Reply-To: References: <7e11c278-013b-6edb-6e11-b0452c79ba18@basilbecker.de> <8fd6e0d6-88a1-6a9e-3782-6142a024e4f6@digitalbrains.com> Message-ID: Maybe there is an algorithm that the Yubukey can't handle? Or, maybe Enigmail is calling "gpg" instead of "gpg2"? I'm just brainstorming. A. On Wed, Feb 8, 2017 at 17:06 Dr. Basil Becker wrote: > > > On 08.02.2017 23:03, Adam Sherman wrote: > > Is it always the same files that aren't decrypting, or is it truly > random? > > > Yes, if I'm able to decrypt a mail, I'm always able to it. Unfortunately > this holds also true for those mails, I can't decrypt. > > I should also add, that I don't have any problems, when I read the mails > on my smartphone using K9 and Openkeychain. > > > > On Wed, Feb 8, 2017 at 16:22 Dr. Basil Becker > > wrote: > > > > Hello, > > > > Peter, thanks for the clarification. I understand your point ;) > > > > On 08.02.2017 20:05, Peter Lebbing wrote: > > > Hello, > > > > > >> I wrote about the problem in more detail at launchpad.net > > > > >> > https://answers.launchpad.net/ubuntu/+source/gnupg/+question/452490 > > > > > > I think it is appreciated if you actually describe the problem on > the > > > mailing list itself rather than only linking to a website. > > > > > I'm having a setup consisting of a main key, and three sub-keys for > > encryption, authorization and signature. The three sub-keys are > stored > > on a Yubikey 4 smart-card. > > > > Authentication and signatures work like a charme. I'm only having > > problems concerning the decryption of mails I received. I'm using > > thunderbird together with enigmail to read my mails, but as the > problem > > also occurrs at the CLI, I assume that enigmail is not part of the > > puzzle. > > > > Well, some messages could be successfully decrypted: > > bb at melmac:~$ gpg2 -vv --output /dev/null -d /tmp/message.txt > > gpg: armor: BEGIN PGP MESSAGE > > gpg: armor header: Version: GnuPG v2 > > # off=0 ctb=85 tag=1 hlen=3 plen=400 > > :pubkey enc packet: version 3, algo 1, keyid DBC1D85BA9D1D189 > > data: [3103 bits] > > gpg: public key is 0xDBC1D85BA9D1D189 > > gpg: using subkey 0xDBC1D85BA9D1D189 instead of primary key > > 0x8501968486DF0281 > > gpg: public key encrypted data: good DEK > > # off=403 ctb=d2 tag=18 hlen=2 plen=0 partial new-ctb > > :encrypted data packet: > > length: unknown > > mdc_method: 2 > > gpg: using subkey 0xDBC1D85BA9D1D189 instead of primary key > > 0x8501968486DF0281 > > gpg: encrypted with 3104-bit RSA key, ID 0xDBC1D85BA9D1D189, created > > 2017-01-10 > > "Dr. Basil Becker > >" > > gpg: AES256 encrypted data > > # off=424 ctb=a3 tag=8 hlen=1 plen=0 indeterminate > > :compressed packet: algo=2 > > # off=426 ctb=cb tag=11 hlen=2 plen=0 partial new-ctb > > :literal data packet: > > mode b (62), created 1486478293, name="", > > raw data: unknown length > > gpg: original file name='' > > gpg: decryption okay > > > > > > Some messages, however, fail to decrypt: > > bb at melmac:~$ gpg2 -vv --output /dev/null -d /tmp/message-fail.txt > > gpg: armor: BEGIN PGP MESSAGE > > gpg: armor header: Version: GnuPG v2 > > # off=0 ctb=85 tag=1 hlen=3 plen=400 > > :pubkey enc packet: version 3, algo 1, keyid DBC1D85BA9D1D189 > > data: [3104 bits] > > gpg: public key is 0xDBC1D85BA9D1D189 > > gpg: using subkey 0xDBC1D85BA9D1D189 instead of primary key > > 0x8501968486DF0281 > > # off=403 ctb=d2 tag=18 hlen=2 plen=0 partial new-ctb > > :encrypted data packet: > > length: unknown > > mdc_method: 2 > > gpg: using subkey 0xDBC1D85BA9D1D189 instead of primary key > > 0x8501968486DF0281 > > gpg: encrypted with 3104-bit RSA key, ID 0xDBC1D85BA9D1D189, created > > 2017-01-10 > > "Dr. Basil Becker > >" > > gpg: public key decryption failed: Hardware problem > > gpg: decryption failed: No secret key > > > > The only difference I see, is that the pubkey data is 3103 bits vs > 3104 > > bits. Unfortunately, I have no idea, whether this is a meaningful > > difference and if this > > > > If anyone could help me identifying what my problem is or even to > solve > > it, I'd appreciate it :) If you need any additional information or > > dedicated log-output, I'm happy to provide it. > > > > Cheers, > > Basil > > > > > > _______________________________________________ > > Gnupg-users mailing list > > Gnupg-users at gnupg.org > > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > > > -- > > Adam Sherman > > Directeur des op?rations, Sauvetage b?n?vole Outaouais > > Director of Operations, Ottawa Volunteer SAR > > CTO, Versature Corp. > > +1 613 797 6819 > > -- > Dr. Basil Becker m: basil at basilbecker.de > Haeckelstr. 12 t: 0163 6538837 > 14471 Potsdam > > -- Adam Sherman Directeur des op?rations, Sauvetage b?n?vole Outaouais Director of Operations, Ottawa Volunteer SAR CTO, Versature Corp. +1 613 797 6819 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at sherman.ca Wed Feb 8 23:03:56 2017 From: adam at sherman.ca (Adam Sherman) Date: Wed, 08 Feb 2017 22:03:56 +0000 Subject: Non-deterministic behavior using GnuPG and a smart-card In-Reply-To: References: <7e11c278-013b-6edb-6e11-b0452c79ba18@basilbecker.de> <8fd6e0d6-88a1-6a9e-3782-6142a024e4f6@digitalbrains.com> Message-ID: Is it always the same files that aren't decrypting, or is it truly random? On Wed, Feb 8, 2017 at 16:22 Dr. Basil Becker wrote: > Hello, > > Peter, thanks for the clarification. I understand your point ;) > > On 08.02.2017 20:05, Peter Lebbing wrote: > > Hello, > > > >> I wrote about the problem in more detail at launchpad.net > >> https://answers.launchpad.net/ubuntu/+source/gnupg/+question/452490 > > > > I think it is appreciated if you actually describe the problem on the > > mailing list itself rather than only linking to a website. > > > I'm having a setup consisting of a main key, and three sub-keys for > encryption, authorization and signature. The three sub-keys are stored > on a Yubikey 4 smart-card. > > Authentication and signatures work like a charme. I'm only having > problems concerning the decryption of mails I received. I'm using > thunderbird together with enigmail to read my mails, but as the problem > also occurrs at the CLI, I assume that enigmail is not part of the puzzle. > > Well, some messages could be successfully decrypted: > bb at melmac:~$ gpg2 -vv --output /dev/null -d /tmp/message.txt > gpg: armor: BEGIN PGP MESSAGE > gpg: armor header: Version: GnuPG v2 > # off=0 ctb=85 tag=1 hlen=3 plen=400 > :pubkey enc packet: version 3, algo 1, keyid DBC1D85BA9D1D189 > data: [3103 bits] > gpg: public key is 0xDBC1D85BA9D1D189 > gpg: using subkey 0xDBC1D85BA9D1D189 instead of primary key > 0x8501968486DF0281 > gpg: public key encrypted data: good DEK > # off=403 ctb=d2 tag=18 hlen=2 plen=0 partial new-ctb > :encrypted data packet: > length: unknown > mdc_method: 2 > gpg: using subkey 0xDBC1D85BA9D1D189 instead of primary key > 0x8501968486DF0281 > gpg: encrypted with 3104-bit RSA key, ID 0xDBC1D85BA9D1D189, created > 2017-01-10 > "Dr. Basil Becker " > gpg: AES256 encrypted data > # off=424 ctb=a3 tag=8 hlen=1 plen=0 indeterminate > :compressed packet: algo=2 > # off=426 ctb=cb tag=11 hlen=2 plen=0 partial new-ctb > :literal data packet: > mode b (62), created 1486478293, name="", > raw data: unknown length > gpg: original file name='' > gpg: decryption okay > > > Some messages, however, fail to decrypt: > bb at melmac:~$ gpg2 -vv --output /dev/null -d /tmp/message-fail.txt > gpg: armor: BEGIN PGP MESSAGE > gpg: armor header: Version: GnuPG v2 > # off=0 ctb=85 tag=1 hlen=3 plen=400 > :pubkey enc packet: version 3, algo 1, keyid DBC1D85BA9D1D189 > data: [3104 bits] > gpg: public key is 0xDBC1D85BA9D1D189 > gpg: using subkey 0xDBC1D85BA9D1D189 instead of primary key > 0x8501968486DF0281 > # off=403 ctb=d2 tag=18 hlen=2 plen=0 partial new-ctb > :encrypted data packet: > length: unknown > mdc_method: 2 > gpg: using subkey 0xDBC1D85BA9D1D189 instead of primary key > 0x8501968486DF0281 > gpg: encrypted with 3104-bit RSA key, ID 0xDBC1D85BA9D1D189, created > 2017-01-10 > "Dr. Basil Becker " > gpg: public key decryption failed: Hardware problem > gpg: decryption failed: No secret key > > The only difference I see, is that the pubkey data is 3103 bits vs 3104 > bits. Unfortunately, I have no idea, whether this is a meaningful > difference and if this > > If anyone could help me identifying what my problem is or even to solve > it, I'd appreciate it :) If you need any additional information or > dedicated log-output, I'm happy to provide it. > > Cheers, > Basil > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- Adam Sherman Directeur des op?rations, Sauvetage b?n?vole Outaouais Director of Operations, Ottawa Volunteer SAR CTO, Versature Corp. +1 613 797 6819 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gniibe at fsij.org Thu Feb 9 07:02:13 2017 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 09 Feb 2017 15:02:13 +0900 Subject: Non-deterministic behavior using GnuPG and a smart-card In-Reply-To: References: <7e11c278-013b-6edb-6e11-b0452c79ba18@basilbecker.de> <8fd6e0d6-88a1-6a9e-3782-6142a024e4f6@digitalbrains.com> Message-ID: <877f4zq4uy.fsf@fsij.org> Hello, "Dr. Basil Becker" writes: > Authentication and signatures work like a charme. I'm only having > problems concerning the decryption of mails I received. [...] > Some messages, however, fail to decrypt: > bb at melmac:~$ gpg2 -vv --output /dev/null -d /tmp/message-fail.txt > gpg: armor: BEGIN PGP MESSAGE > gpg: armor header: Version: GnuPG v2 > # off=0 ctb=85 tag=1 hlen=3 plen=400 > :pubkey enc packet: version 3, algo 1, keyid DBC1D85BA9D1D189 > data: [3104 bits] > gpg: public key is 0xDBC1D85BA9D1D189 > gpg: using subkey 0xDBC1D85BA9D1D189 instead of primary key > 0x8501968486DF0281 > # off=403 ctb=d2 tag=18 hlen=2 plen=0 partial new-ctb > :encrypted data packet: > length: unknown > mdc_method: 2 > gpg: using subkey 0xDBC1D85BA9D1D189 instead of primary key > 0x8501968486DF0281 > gpg: encrypted with 3104-bit RSA key, ID 0xDBC1D85BA9D1D189, created > 2017-01-10 > "Dr. Basil Becker " > gpg: public key decryption failed: Hardware problem > gpg: decryption failed: No secret key [...] > The only difference I see, is that the pubkey data is 3103 bits vs 3104 > bits. Unfortunately, I have no idea, whether this is a meaningful > difference and if this I think that it is deterministic; The cause is that the RSA keysize is not the one in the set of: 1024, 1536, 2048, 3072, 4096. When data to be decrypted is padded, scdaemon can't decrypt, I suppose. I am not sure the exact reason why scdaemon only supports limited set of keysize for encryption. But we have this handling of padding in the current code: https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=scd/app-openpgp.c;h=71c9e1b83003af07b0984688ba1ec5e9013b877c;hb=refs/heads/master#l4334 /* We might encounter a couple of leading zeroes in the cryptogram. Due to internal use of MPIs these leading zeroes are stripped. However the OpenPGP card expects exactly 128 bytes for the cryptogram (for a 1k key). Thus we need to fix it up. We do this for up to 16 leading zero bytes; a cryptogram with more than this is with a very high probability anyway broken. If a signed conversion was used we may also encounter one leading zero followed by the correct length. We fix that as well. */ if (indatalen >= (128-16) && indatalen < 128) /* 1024 bit key. */ fixuplen = 128 - indatalen; else if (indatalen >= (192-16) && indatalen < 192) /* 1536 bit key. */ fixuplen = 192 - indatalen; else if (indatalen >= (256-16) && indatalen < 256) /* 2048 bit key. */ fixuplen = 256 - indatalen; else if (indatalen >= (384-16) && indatalen < 384) /* 3072 bit key. */ fixuplen = 384 - indatalen; else if (indatalen >= (512-16) && indatalen < 512) /* 4096 bit key. */ fixuplen = 512 - indatalen; else if (!*(const char *)indata && (indatalen == 129 || indatalen == 193 || indatalen == 257 || indatalen == 385 || indatalen == 513)) fixuplen = -1; else fixuplen = 0; Perhaps, it was due to support all existing OpenPGP card implementations, I mean, somehow historical, and it was easier to list up specific keysizes. This should be fixed. -- From marko.bauhardt at mailbox.org Thu Feb 9 09:57:58 2017 From: marko.bauhardt at mailbox.org (Marko Bauhardt) Date: Thu, 9 Feb 2017 09:57:58 +0100 Subject: content of private-keys-v1.d In-Reply-To: <878tpgh9xs.fsf@wheatstone.g10code.de> References: <70CFA0A0-41DA-4587-9E7B-DA326ABADF4C@mailbox.org> <950fc426-29af-9045-aec8-cbb649f8bc62@incenp.org> <0308E0A6-E071-4115-B81D-51F7CE153C71@mailbox.org> <9d41fe16-8a80-38f5-34d0-ce5c2e47169f@incenp.org> <878tpgh9xs.fsf@wheatstone.g10code.de> Message-ID: Hi, > > gnupg/agent/keyformat.txt you mean here http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob_plain;f=agent/keyformat.txt ? The part i?m interested in should be this right? {quote} ** Shadowed Private Key Format To keep track of keys stored on IC cards we use a third format for private kyes which are called shadow keys as they are only a reference to keys stored on a token: (shadowed-private-key (rsa (n #00e0ce9..[some bytes not shown]..51#) (e #010001#) (shadowed protocol (info)) ) (uri http://foo.bar x-foo:whatever_you_want) (comment whatever) ) The currently used protocol is "ti-v1" (token info version 1). The second list with the information has this layout: (card_serial_number id_string_of_key fixed_pin_length) FIXED_PIN_LENGTH is optional. It can be used to store the length of the PIN; a value of 0 indicates that this information is not available. The rationale for this field is that some pinpad equipped readers don't allow passing a variable length PIN. More items may be added to the list. {quote} With this example {quote} Key: (shadowed-private-key (rsa (n #00AA1AD2A55FD8C8FDE9E1941772D9CC903FA43B268CB1B5A1BAFDC900 2961D8AEA153424DC851EF13B83AC64FBE365C59DC1BD3E83017C90D4365B4 83E02859FC13DB5842A00E969480DB96CE6F7D1C03600392B8E08EF0C01FC7 19F9F9086B25AD39B4F1C2A2DF3E2BE317110CFFF21D4A11455508FE407997 601260816C8422297C0637BB291C3A079B9CB38A92CE9E551F80AA0EBF4F0E 72C3F250461E4D31F23A7087857FC8438324A013634563D34EFDDCBF2EA80D F9662C9CCD4BEF2522D8BDFED24CEF78DC6B309317407EAC576D889F88ADA0 8C4FFB480981FB68C5C6CA27503381D41018E6CDC52AAAE46B166BDC10637A E186A02BA2497FDC5D1221#) (e #00010001#) (shadowed t1-v1 (#D2760001240102000005000011730000# OPENPGP.1) ))) {quote} > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users --- Marko Bauhardt marko.bauhardt at mailbox.org GPG Key ID: 53192101 GPG Fingerprint: DC0F E851 82A3 72E3 7FE1 ACDB 970C FD47 5319 2101 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From AliAjmi at bankmuscat.com Thu Feb 9 06:59:05 2017 From: AliAjmi at bankmuscat.com (Ali Hassan Hamed Al Ajmi (eChannels)) Date: Thu, 9 Feb 2017 05:59:05 +0000 Subject: GnuPG to create CSR In-Reply-To: <87bmuitzxf.fsf@alice.fifthhorseman.net> References: <1E46221211FBA6429BADC35084A32174CB9891@HO-EXMBX-01.bmoman.bankmuscat.com> <87ziiuocz0.fsf@alice.fifthhorseman.net> <1E46221211FBA6429BADC35084A32174CCE149@HO-EXMBX-01.bmoman.bankmuscat.com> <87bmuitzxf.fsf@alice.fifthhorseman.net> Message-ID: <1E46221211FBA6429BADC35084A32174CDE4E4@HO-EXMBX-01.bmoman.bankmuscat.com> I got the issue. Firewall was blocking the "dirmngr" from communicating with CA to validate x.509 certificates. I have solved that by disabling it. However, I am trying to use gpgsm from command line to do encryption/decryption & signing/verifying. I stuck with how to pass the passphrase in command line. I tried to use the option : passphrase-fd but I am getting this error: gpgsm --batch --passphrase-fd 0 --decrypt "C:\Test\POC.txt.p7m" gpgsm: invalid option "--passphrase-fd" Is this a bug in the tool ( on windows/ linux). Or it is not supported anyone could help me on that. The idea is to use the tool on a server where no-human-interaction is required. -----Original Message----- From: Daniel Kahn Gillmor [mailto:dkg at fifthhorseman.net] Sent: Saturday, February 04, 2017 7:09 AM To: Ali Hassan Hamed Al Ajmi (eChannels) ; gnupg-users at gnupg.org Cc: Naveen Rajghatta (Risk Management) ; Subash S (IT) Subject: RE: GnuPG to create CSR On Tue 2017-01-31 07:05:45 -0500, Ali Hassan Hamed Al Ajmi (eChannels) wrote: > Thanks for your response, > > I have successfully created the CSR and send it to internal CA > (Microsoft CA) team. They sent me the certificate. I have used > Kleopatra UI to import the created certificate after save it in a file > (attaching sample file). Using same Kleopatra UI, I have also imported > root & intermediate certificates for the CA. looks like attached > img(kleopatra.png): We I tried to encrypt or sign any file, it shows > this error (attached error.png) > > Is there anything wrong I have done? > Or it is just because Kleopatra does not support X.509 certificate created by Microsoft CA? I'm sorry, i don't know the answer here, as this is a platform i don't use myself. hopefully someone else on the list here who uses GnuPG on Windows and Kleopatra can give you some feedback or suggestions for how to debug further. Regards, --dkg "Disclaimer! This email message is intended for the named recipient only. If you are not the intended recipient and if you have received this message by error, please immediately notify us through E-Mail at notify at bankmuscat.com and please delete this message from your system. E-mail communications are insecure and capable of interception and corruption, bank muscat would not be liable for incorrect, incomplete transmission, loss or damage on this account or delayed receipt of this e-mail." From peter at digitalbrains.com Thu Feb 9 11:08:12 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 9 Feb 2017 11:08:12 +0100 Subject: Non-deterministic behavior using GnuPG and a smart-card In-Reply-To: <877f4zq4uy.fsf@fsij.org> References: <7e11c278-013b-6edb-6e11-b0452c79ba18@basilbecker.de> <8fd6e0d6-88a1-6a9e-3782-6142a024e4f6@digitalbrains.com> <877f4zq4uy.fsf@fsij.org> Message-ID: Hello, BTW, welcome to the list, Basil! I think it's interesting you encrypt each and every mail you receive. That exercises all components a lot, it might lead to some useful insights on how things might be improved. In fact, we just encountered such an insight I think! On 09/02/17 07:02, NIIBE Yutaka wrote: > This should be fixed. As a short term solution, you could revoke the encryption subkey and create a new one with a common keylength; your current subkey is 3104 bits long for some reason, but the common keylength closest would be 3072 bits. *However*, since you still want to decrypt mail already encrypted to the revoked key, you would have to store an on-disk regular copy of that subkey on your PC. If I understand correctly, you already use a regular on-disk key on your smartphone, so this might not be a problem to you. Changing subkey stuff has no effect on certifications; if people signed your key, that signature will still be valid since it is on the primary key (and an UID), subkeys are not involved in the process. I'm curious how you ended up with 3104-bits RSA keys on your smartcard in the first place, by the way! 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 basil at basilbecker.de Thu Feb 9 11:39:34 2017 From: basil at basilbecker.de (Dr. Basil Becker) Date: Thu, 09 Feb 2017 11:39:34 +0100 Subject: Non-deterministic behavior using GnuPG and a smart-card In-Reply-To: References: <7e11c278-013b-6edb-6e11-b0452c79ba18@basilbecker.de> <8fd6e0d6-88a1-6a9e-3782-6142a024e4f6@digitalbrains.com> <877f4zq4uy.fsf@fsij.org> Message-ID: <88183513-D89C-4A5A-A865-060308E5D9FE@basilbecker.de> Hi Peter et al. Am 9. Februar 2017 11:08:12 MEZ schrieb Peter Lebbing : >Hello, > I think it's interesting you encrypt >each and every mail you receive. That exercises all components a lot, >it >might lead to some useful insights on how things might be improved. In >fact, we just encountered such an insight I think! To encrypt every mail I receive is an option, that my mail - provider offers. I uploaded my public key and each incoming mail becomes encrypted. In my opinion quite a good trade off, given the general usage of mail encryption outside of this list. > >On 09/02/17 07:02, NIIBE Yutaka wrote: >> This should be fixed. > Is there anything else I could provide in order to help with the bug-fix?Logs,traces anything? Of course I can offer my environment to do some tests. Should I file a bug report for this issue? >As a short term solution, you could revoke the encryption subkey and >create a new one with a common keylength; Yes, this is an option. > >If I understand correctly, you already use a regular >on-disk key on your smartphone, so this might not be a problem to you. > Actually, I'm using my smart-card also on my phone through an USB OTG cable. Nevertheless, I have an backup of my encryption key, I could facilitate to overcome the current limitations. >Changing subkey stuff has no effect on certifications; if people signed >your key, that signature will still be valid since it is on the primary >key (and an UID), subkeys are not involved in the process. > Thanks for pointing out. I'll consider using a more standard encryption key. >I'm curious how you ended up with 3104-bits RSA keys on your smartcard >in the first place, by the way! > I decided for this unusual key length more or less for the reason of obscurity. I had the unproven hope that using an unusual key length would make attacks harder. However, I did not expect it to complicate the general usage :) Cheers Basil -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 691 bytes Desc: not available URL: From adam at sherman.ca Thu Feb 9 17:15:03 2017 From: adam at sherman.ca (Adam Sherman) Date: Thu, 9 Feb 2017 11:15:03 -0500 Subject: Is NFC Appropriate? Message-ID: <19719c6d-15ea-1374-d6b3-70eade050c34@sherman.ca> Good Morning, As a very happy Yubikey 4[2] user, where my latop does not contain any secret keys, I would now like to enjoy secure email on my smart phone and tablet(s). Enter an NFC-capable SmartCard. I have nowhere near the depth of understanding required to evaluate this. Is it reasonable and appropriate to use a sub-key on an NFC-capable SmartCard, such as the YubiKey Neo[3], in conjunction with K9 Mail[4]? This has been discussed at least once[1]. Thank you for your input, A. [1]: https://lists.gnupg.org/pipermail/gnupg-users/2015-April/053487.html [2]: https://www.yubico.com/products/yubikey-hardware/yubikey4/ [3]: https://www.yubico.com/products/yubikey-hardware/yubikey-neo/ [4]: https://k9mail.github.io/ -- Adam Sherman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From arthur at ulfeldt.com Thu Feb 9 18:39:39 2017 From: arthur at ulfeldt.com (Arthur Ulfeldt) Date: Thu, 09 Feb 2017 17:39:39 +0000 Subject: Is NFC Appropriate? In-Reply-To: <19719c6d-15ea-1374-d6b3-70eade050c34@sherman.ca> References: <19719c6d-15ea-1374-d6b3-70eade050c34@sherman.ca> Message-ID: Yes it works great, I do this with k9+openkeychain on Android Den tor. 9. feb. 2017 09.27 skrev Adam Sherman : > Good Morning, > > As a very happy Yubikey 4[2] user, where my latop does not contain any > secret keys, I would now like to enjoy secure email on my smart phone > and tablet(s). Enter an NFC-capable SmartCard. > > I have nowhere near the depth of understanding required to evaluate > this. Is it reasonable and appropriate to use a sub-key on an > NFC-capable SmartCard, such as the YubiKey Neo[3], in conjunction with > K9 Mail[4]? > > This has been discussed at least once[1]. > > Thank you for your input, > > A. > > > [1]: https://lists.gnupg.org/pipermail/gnupg-users/2015-April/053487.html > [2]: https://www.yubico.com/products/yubikey-hardware/yubikey4/ > [3]: https://www.yubico.com/products/yubikey-hardware/yubikey-neo/ > [4]: https://k9mail.github.io/ > > -- > Adam Sherman > > > > _______________________________________________ > 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 basil at basilbecker.de Thu Feb 9 20:49:35 2017 From: basil at basilbecker.de (Dr. Basil Becker) Date: Thu, 9 Feb 2017 20:49:35 +0100 Subject: Non-deterministic behavior using GnuPG and a smart-card In-Reply-To: <877f4zq4uy.fsf@fsij.org> References: <7e11c278-013b-6edb-6e11-b0452c79ba18@basilbecker.de> <8fd6e0d6-88a1-6a9e-3782-6142a024e4f6@digitalbrains.com> <877f4zq4uy.fsf@fsij.org> Message-ID: Hello, On 09.02.2017 07:02, NIIBE Yutaka wrote: > Hello, > > [...] > This should be fixed. > I opened an issue for this topic: https://bugs.gnupg.org/gnupg/issue2953 Cheers, Basil -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 634 bytes Desc: OpenPGP digital signature URL: From adam at sherman.ca Thu Feb 9 23:46:53 2017 From: adam at sherman.ca (Adam Sherman) Date: Thu, 9 Feb 2017 17:46:53 -0500 Subject: Is NFC Appropriate? In-Reply-To: <19719c6d-15ea-1374-d6b3-70eade050c34@sherman.ca> References: <19719c6d-15ea-1374-d6b3-70eade050c34@sherman.ca> Message-ID: <008945d6-0c6f-f4b8-50ed-41b6768d3413@sherman.ca> On 2017-02-09 11:15 AM, Adam Sherman wrote: > Is it reasonable and appropriate to use a sub-key on an NFC-capable > SmartCard, such as the YubiKey Neo[3], in conjunction with K9 > Mail[4]? Re-reading my own post, I realize that I was not clear on my actual question. Let me rephrase: Is using an NFC Smart Card with a smart phone for PGP secure? What pitfalls exist? Thank you, A. -- Adam Sherman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From adam at sherman.ca Fri Feb 10 01:14:46 2017 From: adam at sherman.ca (Adam Sherman) Date: Thu, 9 Feb 2017 19:14:46 -0500 Subject: Is NFC Appropriate? In-Reply-To: References: <19719c6d-15ea-1374-d6b3-70eade050c34@sherman.ca> <008945d6-0c6f-f4b8-50ed-41b6768d3413@sherman.ca> Message-ID: On 2017-02-09 06:49 PM, Arthur Ulfeldt wrote: > A hash of The message passes through near field magnetic induction which > does emit radio waves. Then a response is sent back containing the > description key for that message. Perhaps someone here knows if a > secure channel is negotiated for this exchange. I'm guessing not. > How is the PIN transmitted, does anyone know? A. -- Adam Sherman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From basil at basilbecker.de Fri Feb 10 01:18:07 2017 From: basil at basilbecker.de (Dr. Basil Becker) Date: Fri, 10 Feb 2017 01:18:07 +0100 Subject: Is NFC Appropriate? In-Reply-To: <008945d6-0c6f-f4b8-50ed-41b6768d3413@sherman.ca> References: <19719c6d-15ea-1374-d6b3-70eade050c34@sherman.ca> <008945d6-0c6f-f4b8-50ed-41b6768d3413@sherman.ca> Message-ID: Hello, On 09.02.2017 23:46, Adam Sherman wrote: > On 2017-02-09 11:15 AM, Adam Sherman wrote: >> Is it reasonable and appropriate to use a sub-key on an NFC-capable >> SmartCard, such as the YubiKey Neo[3], in conjunction with K9 >> Mail[4]? > > Re-reading my own post, I realize that I was not clear on my actual > question. Let me rephrase: > > Is using an NFC Smart Card with a smart phone for PGP secure? What > pitfalls exist? > I'm not going to answer your question directly, but if you're unsure about NFC's reliability, you could start with USB on-the-go [1]. This way you could keep your already existing Yubikey 4, which also allows stronger keys than the Yubikey NEO. Cheers, Basil [1] https://en.wikipedia.org/wiki/USB_On-The-Go > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 634 bytes Desc: OpenPGP digital signature URL: From arthur at ulfeldt.com Fri Feb 10 00:49:15 2017 From: arthur at ulfeldt.com (Arthur Ulfeldt) Date: Thu, 09 Feb 2017 23:49:15 +0000 Subject: Is NFC Appropriate? In-Reply-To: <008945d6-0c6f-f4b8-50ed-41b6768d3413@sherman.ca> References: <19719c6d-15ea-1374-d6b3-70eade050c34@sherman.ca> <008945d6-0c6f-f4b8-50ed-41b6768d3413@sherman.ca> Message-ID: So you weren't alike if you can do this (yes it works) rather you where asking if you should ;-) A hash of The message passes through near field magnetic induction which does emit radio waves. Then a response is sent back containing the description key for that message. Perhaps someone here knows if a secure channel is negotiated for this exchange. I'm guessing not. With all such things it's useful to consider the overall situation for yourself and decide if it protect against the threats that affect you. My situation is fine with that risk, because there are easier ways to get the key (rubber hoses and the usual discussion here) Den tor. 9. feb. 2017 15.40 skrev Adam Sherman : > On 2017-02-09 11:15 AM, Adam Sherman wrote: > > Is it reasonable and appropriate to use a sub-key on an NFC-capable > > SmartCard, such as the YubiKey Neo[3], in conjunction with K9 > > Mail[4]? > > Re-reading my own post, I realize that I was not clear on my actual > question. Let me rephrase: > > Is using an NFC Smart Card with a smart phone for PGP secure? What > pitfalls exist? > > Thank you, > > A. > > > -- > Adam Sherman > > _______________________________________________ > 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 adam at sherman.ca Fri Feb 10 02:17:44 2017 From: adam at sherman.ca (Adam Sherman) Date: Thu, 9 Feb 2017 20:17:44 -0500 Subject: Is NFC Appropriate? In-Reply-To: References: <19719c6d-15ea-1374-d6b3-70eade050c34@sherman.ca> <008945d6-0c6f-f4b8-50ed-41b6768d3413@sherman.ca> Message-ID: <02b9c396-ea19-bfa6-b72b-844940369fad@sherman.ca> On 2017-02-09 07:18 PM, Dr. Basil Becker wrote: > I'm not going to answer your question directly, but if you're unsure > about NFC's reliability, you could start with USB on-the-go [1]. This > way you could keep your already existing Yubikey 4, which also allows > stronger keys than the Yubikey NEO. Thanks for that pointer, it is extremely helpful. A. -- Adam Sherman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From lynx at luchs.at Fri Feb 10 13:57:44 2017 From: lynx at luchs.at (=?iso-8859-15?Q?Ren=E9?= Pfeiffer) Date: Fri, 10 Feb 2017 13:57:44 +0100 Subject: Keyring operations _very_ slow Message-ID: <20170210125743.ZE5668@many.eyes.bnd.bund.de> Hello! I am using gpg and gpg2 with mutt and Icedove/Thunderbird (with Enigmail plugin). My public keyring has grown to be very big since the email clients auto-import unknown keys. Plus I did some signing and imported keys signing keys from others. The problem is that most GPG operations Enigmail does take a lot of time, because key ring operations are very slow. I already disabled the trust check by using --no-auto-check-trustdb, but a single "gpg2 --check-trustdb" command takes a long time to complete: some at host:~$ time gpg2 --check-trustdb real 13m3.849s user 10m56.379s sys 2m7.458s some at home:~$ The pubring.gpg file has 100 MB. mutt doesn't suffer from this problem, because it calls the GPG commands differently. Enigmail apparently creates a list of all keys in the public keyring and selects from this temporary list. Since Enigmail assumes that key ring operations do not take long, gpg2 command are called and run parallel doing stuff with the key ring. I talked to the Enigmail developers, but they refuse to add a lock mechanism because key ring operations should not take this long. Is there a way to "repair" or "defragment" the key ring file? I can also provide more data if someone wants to debug this. Best regards, Ren?. -- )\._.,--....,'``. fL Let GNU/Linux work for you while you take a nap. /, _.. \ _\ (`._ ,. R. Pfeiffer + http://web.luchs.at/ `._.-(,_..'--(,_..'`-.;.' - System administration + Consulting + Teaching - Got mail delivery problems? https://web.luchs.at/information/blockedmail.php Warning: Do _NOT_ send emails with HTML content to my address! No guarantees! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: not available URL: From andrewg at andrewg.com Fri Feb 10 17:10:28 2017 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 10 Feb 2017 16:10:28 +0000 Subject: Keyring operations _very_ slow In-Reply-To: <20170210125743.ZE5668@many.eyes.bnd.bund.de> References: <20170210125743.ZE5668@many.eyes.bnd.bund.de> Message-ID: On 10/02/17 12:57, Ren? Pfeiffer wrote: > Hello! > > I am using gpg and gpg2 with mutt and Icedove/Thunderbird (with Enigmail > plugin). My public keyring has grown to be very big since the email clients > auto-import unknown keys. Plus I did some signing and imported keys signing > keys from others. > > The problem is that most GPG operations Enigmail does take a lot of time, > because key ring operations are very slow. What version of gpg are you using, and how many keys do you have? I've been suffering from similar problems for years. One thing I found that did help somewhat was to export my public keyring, delete it, and then reimport the dump. I found some keys were un-importable and (subjectively) keyring operations seem to run a little faster now. YMMV Andrew. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From mail at norbertdejonge.nl Fri Feb 10 14:06:22 2017 From: mail at norbertdejonge.nl (Norbert de Jonge) Date: Fri, 10 Feb 2017 14:06:22 +0100 Subject: GNU Privacy Handbook Message-ID: <20170210140622.409b9939@ren> Hi, https://www.gnupg.org/documentation/guides.html The "The GNU Privacy Handbook" section. Maybe add a warning that the work is somewhat outdated, as it's almost 20 years old. Also, that section says: "GPH is also available in the source repository." I can't find it at https://git.gnupg.org/cgi-bin/gitweb.cgi If it really is there, maybe include a more direct link. Best regards, Norbert From marko.bauhardt at mailbox.org Sun Feb 12 13:32:06 2017 From: marko.bauhardt at mailbox.org (Marko Bauhardt) Date: Sun, 12 Feb 2017 13:32:06 +0100 Subject: send-keys does not update my key Message-ID: <8EAA2A2C-BE7C-4028-B130-AF1CE7C7F660@mailbox.org> Hi, The amor definition of my public key i uploaded to hkps://hkps.pool.sks-keyservers.net differs to the public key definition i uploaded to another web service. When i import both key pairs the result looks the same. I don?t know exactly what the difference is. Anyway, i want to update my already uploaded key again. I used the command line (gpg ?send-keys) and i copied also the public key amor block to https://sks-keyservers.net/i/#submit but the key is not changed online. Is there a rule or something which prevents the update of a key? Are there some options i can use to force an update? Thx for any hint Marko --- Marko Bauhardt https://keybase.io/mbauhardt GPG Key ID: 53192101 GPG Fingerprint: DC0F E851 82A3 72E3 7FE1 ACDB 970C FD47 5319 2101 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From 2014-667rhzu3dc-lists-groups at riseup.net Mon Feb 13 00:35:23 2017 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sun, 12 Feb 2017 23:35:23 +0000 Subject: send-keys does not update my key In-Reply-To: <8EAA2A2C-BE7C-4028-B130-AF1CE7C7F660@mailbox.org> References: <8EAA2A2C-BE7C-4028-B130-AF1CE7C7F660@mailbox.org> Message-ID: <14610190564.20170212233523@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Sunday 12 February 2017 at 12:32:06 PM, in , Marko Bauhardt wrote:- > Is there a rule or something which prevents the > update of a key? You can add signatures, user-ids, subkeys, etc. to a key that is already on the server. But you cannot delete anything from it. - -- Best regards MFPA No matter what a man's past may have been, his future is spotless. -----BEGIN PGP SIGNATURE----- iL4EARYKAGYFAlig8URfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDMzQUNFRDRFRTkxMzRFRUJERTZBODUwNjE3 MTJCQzQ2MUFGNzc4RTQACgkQFxK8Rhr3eOSaQQEAutIAOpDZvOEWLKg2+CCUtl1c UPlrV5jnaW4LZLzA5oEA+gLlrF2OFZNyS70Mv84UUm6htBO5DJzZLLZuhXdC0zsH iQF8BAEBCgBmBQJYoPFZXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwfcAH/jNgnpUn4AxoVJneeyD5/viy tIdLeqoFUybThLcgrdFlk+5RpxBx1PQs8ly3sZVw7YGCcaFj9gL1ADCzFTBazD3E rTE6P8Q5K7ZeNRYTHsjW0+wVzAxbRgNdqjzgh12ymbBelRv7q26KtUsYxmzRgkCz 8pIyhuERdFp2MVu6XTdKOEi2l13ah2NTP7+t5ckJ2D3E5/KzPkxOLaiyZ4p+/KW0 iDoYzLmfqafRiESMxBS18ak1Y5IP6kUk0P+vpVLQJTOSN6H3OG6ArZk7saSkSsOp LEoHy2XedDIpNc4+8CfeG1rxxh+xO4G25f20JaxZ7SPkV5kMcThbWIowDgLVM8E= =Hpf3 -----END PGP SIGNATURE----- From marko.bauhardt at mailbox.org Mon Feb 13 07:45:15 2017 From: marko.bauhardt at mailbox.org (Marko Bauhardt) Date: Mon, 13 Feb 2017 07:45:15 +0100 Subject: send-keys does not update my key In-Reply-To: <14610190564.20170212233523@riseup.net> References: <8EAA2A2C-BE7C-4028-B130-AF1CE7C7F660@mailbox.org> <14610190564.20170212233523@riseup.net> Message-ID: <731E4C0F-909D-4547-9B2E-1EA6704A3AA4@mailbox.org> > > Signed PGP part > You can add signatures, user-ids, subkeys, etc. to a key that is > already on the server. But you cannot delete anything from it. Sure, understood. But this does not answer the question i have why i can not upload my current local GPG public key to a key server? Again i get no error message while sending the key, everything looks good. But the key will not change online. The representation online will stay the same. --- Marko Bauhardt https://keybase.io/mbauhardt GPG Key ID: 53192101 GPG Fingerprint: DC0F E851 82A3 72E3 7FE1 ACDB 970C FD47 5319 2101 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From lynx at luchs.at Mon Feb 13 10:53:07 2017 From: lynx at luchs.at (=?iso-8859-15?Q?Ren=E9?= Pfeiffer) Date: Mon, 13 Feb 2017 10:53:07 +0100 Subject: Keyring operations _very_ slow In-Reply-To: References: <20170210125743.ZE5668@many.eyes.bnd.bund.de> Message-ID: <20170213095307.ZC11913@many.eyes.bnd.bund.de> On Feb 10, 2017 at 1610 +0000, Andrew Gallagher appeared and said: > On 10/02/17 12:57, Ren? Pfeiffer wrote: > > Hello! > > > > I am using gpg and gpg2 with mutt and Icedove/Thunderbird (with Enigmail > > plugin). My public keyring has grown to be very big since the email clients > > auto-import unknown keys. Plus I did some signing and imported keys signing > > keys from others. > > > > The problem is that most GPG operations Enigmail does take a lot of time, > > because key ring operations are very slow. > > What version of gpg are you using, and how many keys do you have? I've > been suffering from similar problems for years. I am using Debian 8 on all platforms and sadly have gpg (1.4.18-7+deb8u3) and gpg2 (2.0.26-6+deb8u1). I am using both (gpg for mutt and gpg2 for Icedove/Thunderbird), because gpg2 relies on pinentry which completely breaks one of my workflows. I use gpg2 for key management though. > One thing I found that did help somewhat was to export my public > keyring, delete it, and then reimport the dump. I found some keys were > un-importable and (subjectively) keyring operations seem to run a > little faster now. YMMV I tried that already, will try it again. I also suspect old/"broken"/unusable keys. Best, Ren?. -- )\._.,--....,'``. fL Let GNU/Linux work for you while you take a nap. /, _.. \ _\ (`._ ,. R. Pfeiffer + http://web.luchs.at/ `._.-(,_..'--(,_..'`-.;.' - System administration + Consulting + Teaching - Got mail delivery problems? https://web.luchs.at/information/blockedmail.php Warning: Do _NOT_ send emails with HTML content to my address! No guarantees! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: not available URL: From justus at g10code.com Mon Feb 13 11:46:01 2017 From: justus at g10code.com (Justus Winter) Date: Mon, 13 Feb 2017 11:46:01 +0100 Subject: Problems with GPGME1.8 and Python 3.5 bindings In-Reply-To: References: Message-ID: <87inoe1i8m.fsf@europa.jade-hamburg.de> Hi :) Jean-Fran?ois Schaff writes: > I'm new to gpg, and trying to use the Python bindings included in > PGPME. I'm using Ubuntu 16.04 LTS. > > I have done the following things: ... > - compiled and installed gpgme-1.8.0 > > Everything seems to build and install as expected, but when I finally > try to use the python package (import gpg) I get the following error: > > (venv) jfs at Danube-linux:~/webdev/mms$ python > Python 3.5.2 (default, Nov 17 2016, 17:05:23) > [GCC 5.4.0 20160609] on linux > Type "help", "copyright", "credits" or "license" for more information. >>>> import gpg > Traceback (most recent call last): ... > ImportError: /home/jfs/webdev/mms/venv/local/lib/python3.5/site-packages/gpg/_gpgme.cpython-35m-x86_64-linux-gnu.so: > symbol gpgme_pubkey_algo_string, version GPGME_1.1 not defined in file > libgpgme.so.11 with link time reference gpgme_pubkey_algo_string is new in GPGME 1.7. This suggests that the version 1.8 that you built is not picked up. How you resolve that is really up to you and your needs. You could for example add the $your_install_prefix/lib to LD_LIBRARY_PATH in your bin/activate script. Cheers, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From peter at digitalbrains.com Mon Feb 13 12:16:40 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 13 Feb 2017 12:16:40 +0100 Subject: send-keys does not update my key In-Reply-To: <8EAA2A2C-BE7C-4028-B130-AF1CE7C7F660@mailbox.org> References: <8EAA2A2C-BE7C-4028-B130-AF1CE7C7F660@mailbox.org> Message-ID: <1319e6b1-5eca-757b-3ddc-2c904caf6403@digitalbrains.com> On 12/02/17 13:32, Marko Bauhardt wrote: > Hi, > The amor definition of my public key i uploaded > to hkps://hkps.pool.sks-keyservers.net differs to the public key > definition i uploaded to another web service. An OpenPGP public key is composed of many parts which can be reordered without changing the meaning. Keyservers do reorder stuff, so you can't just compare two keys byte by byte and say anything useful about their equivalence. A command like $ gpg2 --list-options show-unusable-subkeys,show-unusable-uids --list-sigs [KEYID] gives a pretty good overview of a public key. Here is what is on the keyserver for you: > pub rsa4096 2015-08-16 [C] > DC0FE85182A372E37FE1ACDB970CFD4753192101 > uid [ full ] Marko Bauhardt - marko.bauhardt at mailbox.org - > sig 3 970CFD4753192101 2015-08-16 Marko Bauhardt - marko.bauhardt at mailbox.org - > sig 3 970CFD4753192101 2017-02-06 Marko Bauhardt - marko.bauhardt at mailbox.org - > sig 3 970CFD4753192101 2015-08-16 Marko Bauhardt - marko.bauhardt at mailbox.org - > uid [ full ] Marko Bauhardt (Datameer GmbH) - mb at datameer.com - > sig 3 970CFD4753192101 2017-02-06 Marko Bauhardt - marko.bauhardt at mailbox.org - > sub rsa4096 2015-08-16 [S] [expired: 2016-08-15] > sig 970CFD4753192101 2015-08-16 Marko Bauhardt - marko.bauhardt at mailbox.org - > sub rsa4096 2015-08-16 [E] [expired: 2016-08-15] > sig 970CFD4753192101 2015-08-16 Marko Bauhardt - marko.bauhardt at mailbox.org - > sub rsa4096 2015-08-16 [A] [expired: 2016-08-15] > sig 970CFD4753192101 2015-08-16 Marko Bauhardt - marko.bauhardt at mailbox.org - > sub rsa4096 2017-01-28 [S] [expires: 2018-01-28] > sig 970CFD4753192101 2017-01-28 Marko Bauhardt - marko.bauhardt at mailbox.org - > sub rsa4096 2017-01-28 [E] [expires: 2018-01-28] > sig 970CFD4753192101 2017-01-28 Marko Bauhardt - marko.bauhardt at mailbox.org - > sub rsa4096 2017-01-28 [A] [expires: 2018-01-28] > sig 970CFD4753192101 2017-01-28 Marko Bauhardt - marko.bauhardt at mailbox.org - > I've changed your e-mail address so web spam scrapers can't take it easily. If you see all the components there really are on your key reflected in this output, then the keyserver is already fully up to date and any further sending of your key will not change it any further. 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 From bre at pagekite.net Mon Feb 13 12:41:51 2017 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Mon, 13 Feb 2017 11:41:51 -0000 Subject: Questions about --throw-keyids Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi folks, Context: I am trying to figure out how much visible metadata I can remove from an encrypted e-mail before it becomes completely unusable. Step one: stripping stuff from the message headers is relatively easy; minimal messages with all recipients in BCC are easy to create (yes, I know the SMTP envelope and SMTP logs still have the data - this is minimization of metadata, not eliminiation). Step two: Encrypt using gpg --throw-keyids. This is easy on the sender's end, but whether this feature can be used as a matter of course depends on how it impacts the experience of the recipient. This is where I have some questions and could use some guidance. Please feel free to correct me if I've gotten things wrong! (For those unfamiliar with --throw-keyids: it creates an encrypted message without any indicators as to which keys it is encrypted to - so the recipient has to "guess" - in practice GnuPG will try multiple secret keys until one works or it runs out of options.) Using GnuPG 1.4.20 to decrypt, there appears to be a problem where it only asks for one passphrase even if it is checking many keys. So the user has to guess which passphrase to provide and won't be asked again. Using GnuPG 2.1.11 to decrypt, I do get multiple passphrase prompts (one per key/subkey), but it doesn't seem to ask me about expired keys. I am guessing this was a usability trade-off, so long-time users of GnuPG don't have to answer dozens of passphrase prompts when decrypting. My questions: * Am I understanding the GnuPG 1.4 behaviour correctly? Is there a recommended workaround? * Will GnuPG 2.1.11 attempt to decrypt using an expired key if the message is old, or will old messages just become (effectively) inaccessible over time as keys expire? * Are the above behaviours different when using GnuPG non-interactively? * Can the caller influence these behaviours in any way? For example, can I force GnuPG to only try one specific key so my application can manage the experience and experiment with other "guessing" strategies? * How does GnuPG 2.0 behave? * Roughly when did the behaviour change between 1.4 and 2.1.11? Thanks in advance for any and all answers. :-) Cheers, - Bjarni -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYoZuHAAoJEI4ANxYAz5SRFHUH/A/TuJEusZMZ9an3ZFMT61Mi qLInlvqKkx4JXQ4A7gtwMhgjj4t3YMSq6n/VKzeSjUkGdnXdyJJ5JwxHtymV7ob8 3S+WGvxzipLNe94C/2Vz2OfCjaIjIQ/qjNtY96pSIodEv9/GUug3epzTSvFXQ4A3 4XM471FaI+oVbnJPsetu7Ngwn3TTSWBnO872DL0gHOmvZt9R0QyZ3YTRC3kiKYib 9F2taZ0iRpj4svvNyomiA/itayUJzjq60F5EwsNwzGU3gS3Ue0MZc8GrkVHFgTVo ZWkygfByM0S31aI6qQkXeJbRsZTLzpgPmqFqtqwieHQLETcaYawuvLUGW7GYh3U= =wVH1 -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Mon Feb 13 17:34:44 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 13 Feb 2017 11:34:44 -0500 Subject: Questions about --throw-keyids In-Reply-To: References: Message-ID: <878tpaoxqz.fsf@alice.fifthhorseman.net> On Mon 2017-02-13 06:41:51 -0500, Bjarni Runar Einarsson wrote: > Step two: Encrypt using gpg --throw-keyids. > > This is easy on the sender's end, but whether this feature can be > used as a matter of course depends on how it impacts the > experience of the recipient. Agreed that the recipient's side is the tough part of the problem to crack. You don't mention gpg's --try-all-secrets, --try-secret-keys, and --skip-hidden-recipients options, which are all attempts to provide some guidance to gpg about how to handle these things during decryption. Maybe you want to read up on those too? Unfortunately, I have yet to see a functional, non-aggravating workflow for users who have multiple secret keys who receive encrypted messages with hidden keyIDs. It's almost like decryption of messages with hidden keyids and per-decryption passphrase prompting (or even confirmation) are mutually incompatible workflows :/ I'd love to be convinced otherwise. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From lukele at gpgtools.org Mon Feb 13 17:54:04 2017 From: lukele at gpgtools.org (Lukas Pitschl | GPGTools) Date: Mon, 13 Feb 2017 17:54:04 +0100 Subject: Questions about --throw-keyids In-Reply-To: <878tpaoxqz.fsf@alice.fifthhorseman.net> References: <878tpaoxqz.fsf@alice.fifthhorseman.net> Message-ID: <8082F084-3A7A-4F70-893A-CF094FBB0C15@gpgtools.org> > Am 13.02.2017 um 17:34 schrieb Daniel Kahn Gillmor : > > On Mon 2017-02-13 06:41:51 -0500, Bjarni Runar Einarsson wrote: >> Step two: Encrypt using gpg --throw-keyids. >> >> This is easy on the sender's end, but whether this feature can be >> used as a matter of course depends on how it impacts the >> experience of the recipient. > > It's almost like decryption of messages with hidden keyids and > per-decryption passphrase prompting (or even confirmation) are mutually > incompatible workflows :/ Just thinking out loud here, but wouldn?t it be sensible for gnupg to have a ?silent? option, that only try keys for which a passphrase is cached in gpg-agent? While a fallback would have to be provided in case no matching key is found, it would make it easier for those users that cache their passphrases. As fallback gnupg could return the information that no cached passphrase was found, allowing the MUA or plugin to then re-try without the option that enables ?silent? checking. Best, Lukas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: Message signed with OpenPGP using GPGMail URL: From fibmoro at gmx.de Mon Feb 13 16:21:20 2017 From: fibmoro at gmx.de (Fib Moro) Date: Mon, 13 Feb 2017 16:21:20 +0100 Subject: SmartCard v2.1 : factory reset fails Message-ID: Dear GnuPG-Users List. I'm having trouble with resetting my smartcard version 2.1. After posting a bug report for GnuPG Werner Koch asked me to re-post my question on this mailing list [0]. To answer his quick hint: factory-reset did unfortunately not work as I already mentioned in my original request. Please read more for further details below. Thank you kindly for your support! ======================================== I have accidentally blocked my smartcard version 2.1 after entering AdminPIN 3 times with wrong value. According to the link on my card provider's homepage I tried to follow the instructions by Werner to reset the card [1]. I then get the state (gpg --card-edit; verify): =================== Reader ...........: Gemalto USB Shell Token V2 (78111413) 00 00 Application ID ...: D2760001240102010005000046840000 Version ..........: 2.1 Manufacturer .....: ZeitControl Serial number ....: 0000XXXX Name of cardholder: [not set] Language prefs ...: de Sex ..............: unspecified URL of public key : [not set] Login data .......: [not set] Signature PIN ....: forced Key attributes ...: rsa2048 rsa2048 rsa2048 Max. PIN lengths .: 32 32 32 PIN retry counter : 3 0 3 Signature counter : 0 Signature key ....: [none] Encryption key....: [none] Authentication key: [none] General key info..: [none] =================== I can then successfully change the PIN as well as AdminPIN. However, when I try to write a key to the card (gpg --edit-key xxx; keytocard) I get a message "Error setting the Reset Code: Bad PIN". The same issue occurs when try set a Reset Code on the card (gpg --card-edit; admin; passwd => set the Reset Code). In both cases I am very certain that I'm entering the correct PIN/AdminPIN as I have also tried to execute the reset process setting different PINs or even leaving the default PIN values multiple times. Trying to factory reset from "gpg --card-edit" menu didn't help either. Is my card bricked? Am I doing something wrong? One thing I noticed is the second 0 in the "PIN retry counter" value after reset. From [2]: "This field saves how many tries still are left to enter the right PIN. They are decremented whenever a wrong PIN is entered. They are reset whenever a correct AdminPIN is entered. The first and second PIN are for the standard PIN. gpg makes sure that the two numbers are synchronized. The second PIN is only required due to peculiarities of the ISO-7816 standard; gpg tries to keep this PIN in sync with the first PIN. The third PIN represents the retry counter for the AdminPIN." My current setup is: ==================== gpg 2.1.15 ccid 1.4.24 pcsc-lite 1.8.20 (with udev) ==================== Thank you kindly for your help and feedback. fibmoro ____________________________________________________________________________ [0] https://bugs.gnupg.org/gnupg/issue2952 [1] https://lists.gnupg.org/pipermail/gnupg-users/2009-September/037414.html [2] https://www.gnupg.org/howtos/card-howto/en/ch03.html#id2521300 From dkg at fifthhorseman.net Tue Feb 14 00:06:00 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 13 Feb 2017 18:06:00 -0500 Subject: Questions about --throw-keyids In-Reply-To: <8082F084-3A7A-4F70-893A-CF094FBB0C15@gpgtools.org> References: <878tpaoxqz.fsf@alice.fifthhorseman.net> <8082F084-3A7A-4F70-893A-CF094FBB0C15@gpgtools.org> Message-ID: <87wpctofmv.fsf@alice.fifthhorseman.net> On Mon 2017-02-13 11:54:04 -0500, Lukas Pitschl | GPGTools wrote: >> Am 13.02.2017 um 17:34 schrieb Daniel Kahn Gillmor : >> >> On Mon 2017-02-13 06:41:51 -0500, Bjarni Runar Einarsson wrote: >>> Step two: Encrypt using gpg --throw-keyids. >>> >>> This is easy on the sender's end, but whether this feature can be >>> used as a matter of course depends on how it impacts the >>> experience of the recipient. >> >> It's almost like decryption of messages with hidden keyids and >> per-decryption passphrase prompting (or even confirmation) are mutually >> incompatible workflows :/ > > Just thinking out loud here, but wouldn?t it be sensible for gnupg to have a ?silent? option, > that only try keys for which a passphrase is cached in gpg-agent? how about "--try-cached-secrets", by analogy with --try-all-secrets or --try-secret-key? I like this idea. > While a fallback would have to be provided in case no matching key is found, > it would make it easier for those users that cache their passphrases. > As fallback gnupg could return the information that no cached passphrase was found, > allowing the MUA or plugin to then re-try without the option that enables ?silent? checking. Right, this makes sense. It's also possible that the combination of the tool invoking gpg and gpg itself can be cleverer about proposing candidate keys. For example, if the PKESK uses RSA, and the value is 4096-bits in size, and the thing being decrypted is an e-mail address with a certain Date: header and specific addresses in the To: and Cc: fields, then you could filter secret key material by creation/expiration dates and User IDs and usage flags and key sizes. This might also turn out to mean that of all secret keys held, only one is even remotely likely, in which case it could just be tried anyway. You could use the inbound e-mail address (enclosed in <>s) with --try-secret-key, but i don't know how you could pass it the hints from the Date headers. I wonder whether anyone is trying to do anything like this currently. If so, i'd be happy to hear details about what you've tried and what you think might be necessary to make it even better. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From bre at pagekite.net Tue Feb 14 00:35:17 2017 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Mon, 13 Feb 2017 23:35:17 -0000 Subject: Questions about --throw-keyids In-Reply-To: <87wpctofmv.fsf@alice.fifthhorseman.net> References: <87wpctofmv.fsf@alice.fifthhorseman.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hellos! Daniel Kahn Gillmor wrote: > > how about "--try-cached-secrets", by analogy with > --try-all-secrets or --try-secret-key? > > I like this idea. Sounds like a nice optimization... but option bloat is a thing too. Would it be better if GnuPG just checked cached keys by default *first* before it falls back to trying anything else? Being smart about the order in which keys are tried seems like low hanging fruit for improving the UX. If it's not being done already, that is. I haven't looked at the code. OTOH, I would wish for the opposite: a mode where GnuPG is not clever at all and *only* tries the key specified on the command line. Currently (if I'm reading the GnuPG 2.1 man page correctly) that is impossible since the user may have a default key in his config that overrides anything on the command-line. I'd like this because... > Right, this makes sense. It's also possible that the > combination of the tool invoking gpg and gpg itself can be > cleverer about proposing candidate keys. ... of exactly what you just said. I'm not doing this now (and one of my original questions was whether GnuPG uses any such logic itself), but if I do start throwing away keyIDs, I'll be exploring strategies like this to ensure that at least Mailpile users have a pleasant experience. - Bjarni -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYokLJAAoJEI4ANxYAz5SRsREIAKP4Qs/SD4+cPvws5prr+kQR 86h4BYN5dffRty022i55o7WjbZMTcB8oFzbZx4pUl05gjJ7h/fyUtFg+QTBdUfU0 HQrGJYYVgfcu8IkVbmlmrEcIApSzqZyeBLtC16I7iyvDywqLlRzP6z4M9VqJFgaP td/lZSbr3l1vKTdSvseumhfponT/3vZMhE/PLMc6fWuTahHbn58XL3agD38ddRMG J1YF8mIgyce4mUpt/9eIgWEC14ukXTii4CIETzTEgSXyFZB0fPNSdDP30NQLuLT+ NIDEMfL9RY7dxT27/oTVR1p17uuHCSS5A55KVCMW/vIzA+RUD0ZxfRL4l+BI/3k= =Wce0 -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Tue Feb 14 01:23:37 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 13 Feb 2017 19:23:37 -0500 Subject: Questions about --throw-keyids In-Reply-To: References: <87wpctofmv.fsf@alice.fifthhorseman.net> Message-ID: <87d1eloc1i.fsf@alice.fifthhorseman.net> On Mon 2017-02-13 18:35:17 -0500, Bjarni Runar Einarsson wrote: > Sounds like a nice optimization... but option bloat is a thing too. for an API, there's nothing wrong with explicitly specifying the thing that people should *want* to be doing as a separate interface. GnuPG has some level of difficulty because it's trying to offer both an API and a user interface. For this discussion, i think we're pretty clearly talking about the API, though. > ... of exactly what you just said. I'm not doing this now (and one of > my original questions was whether GnuPG uses any such logic itself), > but if I do start throwing away keyIDs, I'll be exploring strategies > like this to ensure that at least Mailpile users have a pleasant > experience. You don't get the luxury to decide on this transition yourself, i'm afraid. Mailpile has to deal with *other* MUAs doing throw-keyids, just like those other MUAs have to deal with it if/when Mailpile starts doing it :/ --dkg From bre at pagekite.net Tue Feb 14 01:40:52 2017 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Tue, 14 Feb 2017 00:40:52 -0000 Subject: Questions about --throw-keyids In-Reply-To: <87d1eloc1i.fsf@alice.fifthhorseman.net> References: <87d1eloc1i.fsf@alice.fifthhorseman.net> Message-ID: <3hiQQTHPXReUKHy7dDgSCndZ7tuMH99IQIAyXDq4219d@mailpile> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel Kahn Gillmor wrote: > > You don't get the luxury to decide on this transition yourself, > i'm afraid. Mailpile has to deal with *other* MUAs doing > throw-keyids, just like those other MUAs have to deal with it > if/when Mailpile starts doing it :/ Of course! But I can't solve everything at once - today I feel I can quite reasonably punt on this and say "it's too hard for now, future versions will deal with it better." I can't really say that anymore if Mailpile itself is generating such content itself. :-) - B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYolIZAAoJEI4ANxYAz5SRLiUH/A6ReWbEvSHdx1+1eAWiYJy8 lPMeOsedzaDxXEAVonQMpeV5H2YmFekx297gVEtbEIyHgbxy/gY7KV8rU3ejDGYZ KCe7lsUcsqoNzeyF1EyGYQazGwzFBbRd4R7x8AUk9LoV7Bqqi1ONwbzc2+l+mHLR jcloOscHQ8mLTxk7pTITlmmrBMpatJa+Zsi9Cn43DH9uib0//tb3Wx0rXn5Wr5oA IMbHAh8MX0yCmnO9L/epGEUMOpV37IYJbQGiZmGU7Q/Mn2Q8zlInv8PFW/VU5YWm I4m/bHYXjqbsbNqnr4TlsolQoIqacEj8izwg/pL41lWnRpjbgpBOAGZyQGfvJCg= =yyvO -----END PGP SIGNATURE----- From gniibe at fsij.org Tue Feb 14 03:33:10 2017 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 14 Feb 2017 11:33:10 +0900 Subject: SmartCard v2.1 : factory reset fails In-Reply-To: References: Message-ID: <87inodzel5.fsf@iwagami.gniibe.org> Hello, Since I got 2.1 card last week, I will test with it. For time being, I say something what I know of. Fib Moro wrote: > I can then successfully change the PIN as well as AdminPIN. > > However, when I try to write a key to the card (gpg --edit-key xxx; keytocard) I > get a message "Error setting the Reset Code: Bad PIN". Umm... This error message can be only happened at setting the Reset Code. Strange. > The same issue occurs when try set a Reset Code on the card (gpg --card-edit; > admin; passwd => set the Reset Code). The length of the Reset Code should be more than or equals to 8. If it is shorter, it fails. What is your case? -- From justus at g10code.com Tue Feb 14 11:28:07 2017 From: justus at g10code.com (Justus Winter) Date: Tue, 14 Feb 2017 11:28:07 +0100 Subject: Questions about --throw-keyids In-Reply-To: <87wpctofmv.fsf@alice.fifthhorseman.net> References: <878tpaoxqz.fsf@alice.fifthhorseman.net> <8082F084-3A7A-4F70-893A-CF094FBB0C15@gpgtools.org> <87wpctofmv.fsf@alice.fifthhorseman.net> Message-ID: <87tw7xrrrc.fsf@europa.jade-hamburg.de> Daniel Kahn Gillmor writes: > [ Unknown signature status ] > On Mon 2017-02-13 11:54:04 -0500, Lukas Pitschl | GPGTools wrote: >>> Am 13.02.2017 um 17:34 schrieb Daniel Kahn Gillmor : >>> >>> On Mon 2017-02-13 06:41:51 -0500, Bjarni Runar Einarsson wrote: >>>> Step two: Encrypt using gpg --throw-keyids. >>>> >>>> This is easy on the sender's end, but whether this feature can be >>>> used as a matter of course depends on how it impacts the >>>> experience of the recipient. >>> >>> It's almost like decryption of messages with hidden keyids and >>> per-decryption passphrase prompting (or even confirmation) are mutually >>> incompatible workflows :/ >> >> Just thinking out loud here, but wouldn?t it be sensible for gnupg to have a ?silent? option, >> that only try keys for which a passphrase is cached in gpg-agent? > > how about "--try-cached-secrets", by analogy with --try-all-secrets or > --try-secret-key? > > I like this idea. I don't. I strongly believe that adding command line switches should be the absolute last resort. Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From peter at digitalbrains.com Tue Feb 14 13:10:14 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 14 Feb 2017 13:10:14 +0100 Subject: Questions about --throw-keyids In-Reply-To: <8082F084-3A7A-4F70-893A-CF094FBB0C15@gpgtools.org> References: <878tpaoxqz.fsf@alice.fifthhorseman.net> <8082F084-3A7A-4F70-893A-CF094FBB0C15@gpgtools.org> Message-ID: On 13/02/17 17:54, Lukas Pitschl | GPGTools wrote: > As fallback gnupg could return the information that no cached passphrase was found, > allowing the MUA or plugin to then re-try without the option that enables ?silent? checking. Maybe GnuPG already does this, but instead of a two-step process first trying cached keys non-interactively and then falling back to trying keys with prompting for passphrases, GnuPG could also simply, in one plain standard invocation, first try all the cached secrets and when that fails start prompting for even more secret keys. 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 dkg at fifthhorseman.net Tue Feb 14 15:27:06 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 14 Feb 2017 09:27:06 -0500 Subject: Questions about --throw-keyids In-Reply-To: <87tw7xrrrc.fsf@europa.jade-hamburg.de> References: <878tpaoxqz.fsf@alice.fifthhorseman.net> <8082F084-3A7A-4F70-893A-CF094FBB0C15@gpgtools.org> <87wpctofmv.fsf@alice.fifthhorseman.net> <87tw7xrrrc.fsf@europa.jade-hamburg.de> Message-ID: <87wpcsn8zp.fsf@alice.fifthhorseman.net> On Tue 2017-02-14 05:28:07 -0500, Justus Winter wrote: > I don't. I strongly believe that adding command line switches should be > the absolute last resort. I'm open to other suggestions about how to achieve this behavior. GnuPG's general stance appears to be that the only way to interact with the suite is through the command line. It also has historically tried to avoid making breaking changes to the behavior based on existing options. This doesn't appear to leave much room for fixing problems or adding functionality *without* new command-line switches. --dkg From justus at g10code.com Tue Feb 14 16:56:42 2017 From: justus at g10code.com (Justus Winter) Date: Tue, 14 Feb 2017 16:56:42 +0100 Subject: Questions about --throw-keyids In-Reply-To: <87wpcsn8zp.fsf@alice.fifthhorseman.net> References: <878tpaoxqz.fsf@alice.fifthhorseman.net> <8082F084-3A7A-4F70-893A-CF094FBB0C15@gpgtools.org> <87wpctofmv.fsf@alice.fifthhorseman.net> <87tw7xrrrc.fsf@europa.jade-hamburg.de> <87wpcsn8zp.fsf@alice.fifthhorseman.net> Message-ID: <87o9y4sr45.fsf@europa.jade-hamburg.de> Daniel Kahn Gillmor writes: > On Tue 2017-02-14 05:28:07 -0500, Justus Winter wrote: >> I don't. I strongly believe that adding command line switches should be >> the absolute last resort. > > I'm open to other suggestions about how to achieve this behavior. I have none, and tbh I did not even thought this through. However... > GnuPG's general stance appears to be that the only way to interact with > the suite is through the command line. It also has historically tried > to avoid making breaking changes to the behavior based on existing > options. This doesn't appear to leave much room for fixing problems or > adding functionality *without* new command-line switches. ... while adding another option may fix every small problem at hand, it creates a huge one that is even harder to fix: We have way too many options already. Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From marko.bauhardt at mailbox.org Tue Feb 14 19:51:47 2017 From: marko.bauhardt at mailbox.org (Marko Bauhardt) Date: Tue, 14 Feb 2017 19:51:47 +0100 Subject: send-keys does not update my key In-Reply-To: <1319e6b1-5eca-757b-3ddc-2c904caf6403@digitalbrains.com> References: <8EAA2A2C-BE7C-4028-B130-AF1CE7C7F660@mailbox.org> <1319e6b1-5eca-757b-3ddc-2c904caf6403@digitalbrains.com> Message-ID: <39359414-A4A8-43E7-BE94-2F065D04CCE8@mailbox.org> Hi Peter, > On 13 Feb 2017, at 12:16, Peter Lebbing wrote: > > > An OpenPGP public key is composed of many parts which can be reordered > without changing the meaning. Keyservers do reorder stuff, so you can't > just compare two keys byte by byte and say anything useful about their > equivalence. > > A command like > > $ gpg2 --list-options show-unusable-subkeys,show-unusable-uids > --list-sigs [KEYID] > > gives a pretty good overview of a public key. I tried that out with my two public key representations. There was a diff between the two keys. The trust level of my two IDs was `unknown` in the one public key and `ultimate` in the other key. Maybe this is the reason why the armor output is different. I mean it make sense when the key server will change the trust level of the given user-id to `unknown` while uploading. > I've changed your e-mail address so web spam scrapers can't take it > easily. ;) Thx! > If you see all the components there really are on your key > reflected in this output, then the keyserver is already fully up to date > and any further sending of your key will not change it any further. This was the case except of the trust level. > > HTH, > > Peter. Thank you. Very helpful. Marko --- Marko Bauhardt https://keybase.io/mbauhardt GPG Key ID: 53192101 GPG Fingerprint: DC0F E851 82A3 72E3 7FE1 ACDB 970C FD47 5319 2101 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From kristian.fiskerstrand at sumptuouscapital.com Tue Feb 14 19:53:44 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 14 Feb 2017 19:53:44 +0100 Subject: send-keys does not update my key In-Reply-To: <39359414-A4A8-43E7-BE94-2F065D04CCE8@mailbox.org> References: <8EAA2A2C-BE7C-4028-B130-AF1CE7C7F660@mailbox.org> <1319e6b1-5eca-757b-3ddc-2c904caf6403@digitalbrains.com> <39359414-A4A8-43E7-BE94-2F065D04CCE8@mailbox.org> Message-ID: <51815779-c5ff-0624-e9a8-0bceb41eba55@sumptuouscapital.com> On 02/14/2017 07:51 PM, Marko Bauhardt wrote: > The trust level of my two IDs was `unknown` in the one public key and `ultimate` in the other key. Trust level is not a property of the public key, it is stored out of band (in the local trustdb) -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Qui audet vincit Who dares wins -------------- 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 Feb 14 21:08:25 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 14 Feb 2017 21:08:25 +0100 Subject: Questions about --throw-keyids In-Reply-To: <87wpcsn8zp.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 14 Feb 2017 09:27:06 -0500") References: <878tpaoxqz.fsf@alice.fifthhorseman.net> <8082F084-3A7A-4F70-893A-CF094FBB0C15@gpgtools.org> <87wpctofmv.fsf@alice.fifthhorseman.net> <87tw7xrrrc.fsf@europa.jade-hamburg.de> <87wpcsn8zp.fsf@alice.fifthhorseman.net> Message-ID: <87poikwn5y.fsf@wheatstone.g10code.de> On Tue, 14 Feb 2017 15:27, dkg at fifthhorseman.net said: > I'm open to other suggestions about how to achieve this behavior. There is an old FIXME in the code which needs to be removed: /* FIXME: Store this all in a list and process it later so that we can prioritize what key to use. This gives a better user experience if wildcard keyids are used. */ I like your suggestion of also looking at the creation date and key size as further sort parameters. Salam-Shalom, Werner ps. I don't think that --throw-keyid is a useful thing for use of gpg in mails - it does not really help in this use case because that meta data is easier available by other means. But if people start using this more we need a solution. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From fibmoro at gmx.de Tue Feb 14 11:26:49 2017 From: fibmoro at gmx.de (Fib Moro) Date: Tue, 14 Feb 2017 11:26:49 +0100 Subject: Aw: Re: SmartCard v2.1 : factory reset fails In-Reply-To: <87inodzel5.fsf@iwagami.gniibe.org> References: , <87inodzel5.fsf@iwagami.gniibe.org> Message-ID: Hello Yutaka, > > The length of the Reset Code should be more than or equals to 8. If it > is shorter, it fails. What is your case? > -- > It doesn't even get to the point where it prompts me for the Reset Code: Here is what I do: When try to set the reset code via "passwd => 4" it prompts me for the AdminPIN. I enter the default AdminPIN value of "123456789" and get the message "Error setting the Reset Code: Bad PIN" I'm 100% sure I entered AdminPIN correctly. The same issue occurs if I set the AdminPIN manually beforehand. _____________ gpg/card> passwd gpg: OpenPGP card no. DXXX detected 1 - change PIN 2 - unblock PIN 3 - change Admin PIN 4 - set the Reset Code Q - quit Your selection? 4 Error setting the Reset Code: Bad PIN _____________ > > > However, when I try to write a key to the card (gpg --edit-key xxx; keytocard) I > > get a message "Error setting the Reset Code: Bad PIN". > I am sorry, I was a bit imprecise here. Please let me explain again: I start gpg in "--edit-key" mode. Then I select a subkey I want to move to the card by issuing command "key 1". After the "keytocard" command it asks me where to store the key for which I choose option 1 signature key. It then prompts me for the privat key passphrase which I enter successfully. Now it asks me for AdminPIN. Again with default value "123456789" I get the message "gpg: KEYTOCARD failed: Bad secret key" Also the same issue occurs if I set the AdminPIN manually beforehand. _____________ gpg> key 1 ... gpg> keytocard Please select where to store the key: (1) Signature key (3) Authentication key Your selection? 1 gpg: KEYTOCARD failed: Bad secret key ______________ Please let me know if you need more information. Thank you kindly, fibmoro From rjh at sixdemonbag.org Tue Feb 14 18:35:36 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 14 Feb 2017 12:35:36 -0500 Subject: Questions about --throw-keyids In-Reply-To: <87o9y4sr45.fsf@europa.jade-hamburg.de> References: <878tpaoxqz.fsf@alice.fifthhorseman.net> <8082F084-3A7A-4F70-893A-CF094FBB0C15@gpgtools.org> <87wpctofmv.fsf@alice.fifthhorseman.net> <87tw7xrrrc.fsf@europa.jade-hamburg.de> <87wpcsn8zp.fsf@alice.fifthhorseman.net> <87o9y4sr45.fsf@europa.jade-hamburg.de> Message-ID: <029701d286e8$c15bcfc0$44136f40$@sixdemonbag.org> > ... while adding another option may fix every small problem at hand, it > creates a huge one that is even harder to fix: We have way too many options > already. Some years ago I had the wild urge to set up Prolog code that would determine the necessary command-line flags to sustain certain operations, and which ones could be mixed-and-matched without affecting each other. After a few days of work I gave up on it: even after reading the source code, the multitude of operations seemed to be a hall of mirrors. If I could wave a magic wand, I'd make a huge number of those options just simply go away. From bre at pagekite.net Tue Feb 14 21:14:57 2017 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Tue, 14 Feb 2017 20:14:57 -0000 Subject: Questions about --throw-keyids In-Reply-To: <87o9y4sr45.fsf@europa.jade-hamburg.de> References: <87o9y4sr45.fsf@europa.jade-hamburg.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Justus, everyone, Justus Winter wrote: > > ... while adding another option may fix every small problem at hand, it > creates a huge one that is even harder to fix: We have way too > many options already. I agree with this. Features aren't free, every extra feature and option implies a long-term support burden and adds complexity to the app. Having given --throw-keyids and usability more thought, I have come to the conclusion that for the use-cases I had in mind, I won't use the feature at all. Rather than generate a single encrypted e-mail with thrown keyids and send to the entire group of recipients, it will be more user friendly and easier to reason about (and maybe even more secure in some cases) if I simply generate one e-mail per recipient. This will cost more bytes on the wire, but network speeds and disk storage have both increased many orders of magnitude faster than the size of e-mails over the past years. If there was ever an argument to complicate GnuPG in this way, in order to save some bytes, that argument probably no longer applies. Note that I don't consider it a (large enough) problem that an e-mail to user A may "leak" the key ID of user A. As long as the key IDs of other users in BCC are protected, I think that fulfils the "promise" of e-mail's BCC semanitics and is "good enough." At this stage, unless --throw-keyids (et. al) has important applications which I am unaware of *outside* the world of e-mail and BCC, I'd be tempted to suggest the whole family of options are a mistake and should be deprecated. ;-) Thanks for the useful replies and discussion! Cheers, - Bjarni -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYo2U4AAoJEI4ANxYAz5SR0WoH/RwGIKgZ80Pb0p7d4TZcxGMf 6OsQyYg1XCbebRRYoJ9QUEisAr1aa86OipTbJ2G8D60jZ6XJtOXn25FCacCERymT rvsorpS5H/1/TFf2UzX5/9mXDeGyiYJQIkAHCK6bloAUyYPkTY9Q8wbylQCJ34jL rN7/xLfdu8OW2Afcba6GbuDGfuyLoYI6oEEhCwJtKGAHNMZ02SMJ40mwwXzadyNq xuVoygH7rakPgEvj1cvyb1yxJxdDdlwMLRU3tSo5JfKQCEXEC4F6/nmJ7p7jelVv mPX4obDlOpc5sQ3u0Zskwj0C7ex/0uNyHDILuW5cXib30KXqa/3MoNHC09OlW2I= =DpjD -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Wed Feb 15 00:31:35 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 14 Feb 2017 18:31:35 -0500 Subject: Questions about --throw-keyids In-Reply-To: <87poikwn5y.fsf@wheatstone.g10code.de> References: <878tpaoxqz.fsf@alice.fifthhorseman.net> <8082F084-3A7A-4F70-893A-CF094FBB0C15@gpgtools.org> <87wpctofmv.fsf@alice.fifthhorseman.net> <87tw7xrrrc.fsf@europa.jade-hamburg.de> <87wpcsn8zp.fsf@alice.fifthhorseman.net> <87poikwn5y.fsf@wheatstone.g10code.de> Message-ID: <87efz0mjs8.fsf@alice.fifthhorseman.net> On Tue 2017-02-14 15:08:25 -0500, Werner Koch wrote: > I don't think that --throw-keyid is a useful thing for use of gpg > in mails - it does not really help in this use case because that meta > data is easier available by other means. I absolutely agree with this assessment, and i also agree with Bjarni's approach to defending bcc addresses by sending distinct e-mails. Bjarni's suggestion could theoretically be done in two ways: 0) do the symmetric encryption once, and then pick and choose which PKESK OpenPGP packets to prepend to it depending on which message is being generated. 1) simply re-encrypt the same cleartext multiple times (using different symmetric session keys) afaict, GnuPG only supports (1) at the moment (this is probably OK). Presumably each message would use the same Message-Id, so that replies thread properly, etc. However, gpg is a tool that's used not only in e-mail contexts, so it does still need to support the --throw-keyids option, since non-email contexts are not guaranteed to be wrapped in equivalent metadata the same way as an rfc822 message would be. :/ --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From wk at gnupg.org Wed Feb 15 09:45:16 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 15 Feb 2017 09:45:16 +0100 Subject: Questions about --throw-keyids In-Reply-To: <87efz0mjs8.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 14 Feb 2017 18:31:35 -0500") References: <878tpaoxqz.fsf@alice.fifthhorseman.net> <8082F084-3A7A-4F70-893A-CF094FBB0C15@gpgtools.org> <87wpctofmv.fsf@alice.fifthhorseman.net> <87tw7xrrrc.fsf@europa.jade-hamburg.de> <87wpcsn8zp.fsf@alice.fifthhorseman.net> <87poikwn5y.fsf@wheatstone.g10code.de> <87efz0mjs8.fsf@alice.fifthhorseman.net> Message-ID: <87wpcrvo4j.fsf@wheatstone.g10code.de> On Wed, 15 Feb 2017 00:31, dkg at fifthhorseman.net said: > afaict, GnuPG only supports (1) at the moment (this is probably OK). There is a plan to add a rewrite feature to gpg so that for example you can easily add an archiving key to a message. But that is something we need to shift to 2.3. > However, gpg is a tool that's used not only in e-mail contexts, so it > does still need to support the --throw-keyids option, since non-email Sure. Fully agree. And we also need to improve the handling of wildcard keyids. In particular with several smartcards this is pretty annoying. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From gniibe at fsij.org Wed Feb 15 10:42:27 2017 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 15 Feb 2017 18:42:27 +0900 Subject: Aw: Re: SmartCard v2.1 : factory reset fails In-Reply-To: References: <87inodzel5.fsf@iwagami.gniibe.org> Message-ID: <87h93viyd8.fsf@fsij.org> Hello, again, I found a bug in GnuPG 2.1.18 for factory-reset command handling (it's not in 2.1.17 or older), I fixed it today. Then, I tested my OpenPGP card 2.1. Let us fix a thing one by one. First, the Reset Code handling. Fib Moro wrote: > It doesn't even get to the point where it prompts me for the Reset Code: > > Here is what I do: > > When try to set the reset code via "passwd => 4" it prompts me for the AdminPIN. > I enter the default AdminPIN value of "123456789" and get the message "Error setting the Reset Code: Bad PIN" > I'm 100% sure I entered AdminPIN correctly. For my OpenPGP card 2.1, the Admin PIN is "12345678" (no 9). I can successfuly set the Reset Code. I confirmed that with wrong Admin PIN, I got the message "Error setting the Reset Code: Bad PIN". Please test with 12345678. -- From marko.bauhardt at mailbox.org Wed Feb 15 12:33:28 2017 From: marko.bauhardt at mailbox.org (Marko Bauhardt) Date: Wed, 15 Feb 2017 12:33:28 +0100 Subject: send-keys does not update my key In-Reply-To: <51815779-c5ff-0624-e9a8-0bceb41eba55@sumptuouscapital.com> References: <8EAA2A2C-BE7C-4028-B130-AF1CE7C7F660@mailbox.org> <1319e6b1-5eca-757b-3ddc-2c904caf6403@digitalbrains.com> <39359414-A4A8-43E7-BE94-2F065D04CCE8@mailbox.org> <51815779-c5ff-0624-e9a8-0bceb41eba55@sumptuouscapital.com> Message-ID: <75AEFA6E-C6E0-44C3-85C1-496AF1B88E94@mailbox.org> > On 14 Feb 2017, at 19:53, Kristian Fiskerstrand wrote: > > Trust level is not a property of the public key, it is stored out of > band (in the local trustdb) Ah ok. Thanks. Marko --- Marko Bauhardt https://keybase.io/mbauhardt GPG Key ID: 53192101 GPG Fingerprint: DC0F E851 82A3 72E3 7FE1 ACDB 970C FD47 5319 2101 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From didrik.nordstrom at gmail.com Wed Feb 15 04:02:08 2017 From: didrik.nordstrom at gmail.com (=?UTF-8?Q?Didrik_Nordstr=C3=B6m?=) Date: Tue, 14 Feb 2017 19:02:08 -0800 Subject: Expanding web-of-trust with subkey Message-ID: Hi, I am new to using PGP in general, but fairly confident in the cryptographic primitives and the overall concepts. I have issued a master key on cold storage, and subkeys on my primary machine (one with encryption and one with signing privileges). I wanted to send an email to a new contact (a bug report to a software project) so I added the public key and assigned it "Fully trusted" (4). Then I ran `gpg2 -esa -r ` and gpg tells me: *It is NOT certain that the key belongs to the person named in the user ID. If you *really* know what you are doing, you may answer the next question with yes.* Does this have to do with me not having signed the key? If I assigned it "Ultimate trust" (5) the warning disappeared. I tried signing the key: *Really sign? (y/N) y* *gpg: signing failed: No secret key* *gpg: signing failed: No secret key* It took me quite a while to figure out that I can't sign someones key with a master key. (Maybe the error message can be improved?) So.. Do I need access to my master key in order to expand my web of trust? This seems like quite a restriction. How do you handle key management? Let's say you just want to send a signed and encrypted email once to someone who announced their pubkey over https? What type of trust would you assign? Best, Didrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristian.fiskerstrand at sumptuouscapital.com Wed Feb 15 12:51:22 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 15 Feb 2017 12:51:22 +0100 Subject: Expanding web-of-trust with subkey In-Reply-To: References: Message-ID: <22ae4916-b4bc-c6f7-df9f-06fa7464a3f2@sumptuouscapital.com> On 02/15/2017 04:02 AM, Didrik Nordstr?m wrote: > > So.. Do I need access to my master key in order to expand my web of > trust? This seems like quite a restriction. Yes, although you can generate a local CA key to use for this purpose for short term validity considerations used for local signatures. For the visible WoT (i.e one others can use in their determination), having this limited is a very good thing. And it is one of the constructs that makes it possible to rotate subkeys due to compromise (e.g loss of a smartcard) without needing to revoke the full primary key. > > How do you handle key management? Let's say you just want to send a > signed and encrypted email once to someone who announced their pubkey > over https? What type of trust would you assign? no trust, that goes to the ability to verify third parties. Local CA and local (non-exportable) signature -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Qui audet vincit Who dares wins -------------- 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 Wed Feb 15 13:34:39 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 15 Feb 2017 13:34:39 +0100 Subject: Expanding web-of-trust with subkey In-Reply-To: References: Message-ID: On 15/02/17 04:02, Didrik Nordstr?m wrote: > I wanted to send an email to a new contact (a bug report to a software > project) so I added the public key and assigned it "Fully trusted" (4). In addition to Kristian's answer, let me clarify: "Ownertrust" is your assessment of how much you want to trust certifications *done* by this person. So if this person A signed the key of a person B, it determines whether this makes key B valid for you. It does not relate to the validity of the key of person A! I've written a bit about ownertrust for the keysigning party we held last December: In particular, the first section is relevant. > Does this have to do with me not having signed the key? If I assigned it > "Ultimate trust" (5) the warning disappeared. "Ultimate trust" is the odd one out and is generally only used for your own keys. This makes the key valid even without a signature. > So.. Do I need access to my master key in order to expand my web of > trust? This seems like quite a restriction. You could also perhaps take a look at TOFU rather than the Web of Trust. You do need GnuPG 2.1 for that. 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 peter at digitalbrains.com Wed Feb 15 13:41:58 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 15 Feb 2017 13:41:58 +0100 Subject: Expanding web-of-trust with subkey In-Reply-To: References: Message-ID: On 15/02/17 13:34, Peter Lebbing wrote: > I've written a bit about ownertrust for the keysigning party we held > last December: Additionally, this topic is also briefly covered in the FAQ[1], which is an up-to-date and maintained piece of documentation. The The GNU Privacy Handbook[2] also contains interesting information, but it hasn't been updated for a long while. It contains some outdated stuff that makes me hesitate to actually recommend it, but the Web of Trust is still the same. Peter. [1] [2] -- 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 lachlan at twopif.net Wed Feb 15 14:32:54 2017 From: lachlan at twopif.net (Lachlan Gunn) Date: Thu, 16 Feb 2017 00:02:54 +1030 Subject: Hybrid keysigning party, your opinion? In-Reply-To: References: Message-ID: <46a4ec4d-d5da-432f-7210-40141aaf15fc@twopif.net> Hello, Le 2016-12-05 ? 00:03, Peter Lebbing a ?crit : > I am asking for your thoughts on a variant of the organization of the > keysigning party. I'll explain my reasoning and intentions, and I would > like to know if you think I forgot to think of something important. Is > there a way a malicious party could get people to sign the wrong UID, > because I didn't think of that way? I'm not interested in ways people > could cheat at the usual "informal" keysigning party model, with > exchanging paper keyslips. This is because this would be my fallback > model, if the proposed model doesn't work out. So I'm only interested in > cases where the proposed model introduces extra issues compared to the > informal exchanging keyslips model. Given the discussion on the list before, now that CCC has come and gone I'm curious as to how well this worked. Is it an innovation worth perpetuating? Thanks, Lachlan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From ankostis at gmail.com Wed Feb 15 13:48:57 2017 From: ankostis at gmail.com (ankostis) Date: Wed, 15 Feb 2017 13:48:57 +0100 Subject: Should we trust "MyMail-crypt for Gmail" Chrome extension? Message-ID: Hi, I'm wondering whether this open-source Chrome-extension for GPG on GMail[1] is to be trusted; I mean, not to call home with my secret-key and passphrase. I searched through the mailing-list archives and found only one reference from 2014: https://lists.gnupg.org/pipermail/gnupg-users/2014-April.txt This extension is the only alternative to use GPG with gmail in corporate environments where SMTP ports are blocked (unless we consider as an "alternative" to manually clear-signing each message text to be sent with cmd-line). With kind regards, Kostis [1] https://chrome.google.com/webstore/detail/mymail-crypt-for-gmail/jcaobjhdnlpmopmjhijplpjhlplfkhba From adam at sherman.ca Wed Feb 15 15:27:16 2017 From: adam at sherman.ca (Adam Sherman) Date: Wed, 15 Feb 2017 09:27:16 -0500 Subject: Expanding web-of-trust with subkey In-Reply-To: <22ae4916-b4bc-c6f7-df9f-06fa7464a3f2@sumptuouscapital.com> References: <22ae4916-b4bc-c6f7-df9f-06fa7464a3f2@sumptuouscapital.com> Message-ID: On 2017-02-15 06:51 AM, Kristian Fiskerstrand wrote: >> Do I need access to my master key in order to expand my web of >> trust? This seems like quite a restriction. > Yes, although you can generate a local CA key to use for this purpose > for short term validity considerations used for local signatures. How do you do that? Is there a type of sub-key you use? A. -- Adam Sherman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Wed Feb 15 16:33:50 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 15 Feb 2017 16:33:50 +0100 Subject: Expanding web-of-trust with subkey In-Reply-To: References: <22ae4916-b4bc-c6f7-df9f-06fa7464a3f2@sumptuouscapital.com> Message-ID: <4bfe98ee-f2d3-ca27-a467-b22c29d65e4a@sumptuouscapital.com> On 02/15/2017 03:27 PM, Adam Sherman wrote: > On 2017-02-15 06:51 AM, Kristian Fiskerstrand wrote: >>> Do I need access to my master key in order to expand my web of >>> trust? This seems like quite a restriction. >> Yes, although you can generate a local CA key to use for this purpose >> for short term validity considerations used for local signatures. > > How do you do that? Is there a type of sub-key you use? > No, just a completely separated primary key with C capability, no subkeys and is never published anywhere, rotated regularly to issue lsigns for short term use -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Qui audet vincit Who dares wins -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From adam at sherman.ca Wed Feb 15 17:54:41 2017 From: adam at sherman.ca (Adam Sherman) Date: Wed, 15 Feb 2017 11:54:41 -0500 Subject: Expanding web-of-trust with subkey In-Reply-To: <4bfe98ee-f2d3-ca27-a467-b22c29d65e4a@sumptuouscapital.com> References: <22ae4916-b4bc-c6f7-df9f-06fa7464a3f2@sumptuouscapital.com> <4bfe98ee-f2d3-ca27-a467-b22c29d65e4a@sumptuouscapital.com> Message-ID: On 2017-02-15 10:33 AM, Kristian Fiskerstrand wrote: >> How do you do that? Is there a type of sub-key you use? >> > No, just a completely separated primary key with C capability, no > subkeys and is never published anywhere, rotated regularly to issue > lsigns for short term use Ah, that makes sense. Thanks. A. -- Adam Sherman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From tlikonen at iki.fi Wed Feb 15 17:54:51 2017 From: tlikonen at iki.fi (Teemu Likonen) Date: Wed, 15 Feb 2017 18:54:51 +0200 Subject: Expanding web-of-trust with subkey In-Reply-To: ("Didrik =?iso-8859-1?Q?Nordstr=F6m=22's?= message of "Tue, 14 Feb 2017 19:02:08 -0800") References: Message-ID: <87bmu3fl7o.fsf@iki.fi> Didrik Nordstr?m [2017-02-14 19:02:08-08] wrote: > How do you handle key management? Let's say you just want to send a > signed and encrypted email once to someone who announced their pubkey > over https? What type of trust would you assign? I don't personally know anybody who uses gpg. Even if I will meet someone it's unlikely that signing keys will make me part of any web. So web of trust is useless for me. That makes things very simple, in a way. I use "trust-model direct" and do some checking in web pages or check consistent use of signatures. If the key seems ok I'll "--edit-key", type "trust" and assign marginal or full trust for that key. That's it. And because I have no use for other people's signatures I also have "keyserver-options import-clean" so my keyring remains small. When Debian 9 is released, with GnuPG 2.1, I'll try "trust-model tofu+pgp" (trust on first use plus web of trust). It seems useful too. -- /// 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: 454 bytes Desc: not available URL: From dkg at fifthhorseman.net Wed Feb 15 18:12:23 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 15 Feb 2017 12:12:23 -0500 Subject: GPG homedir path length limit In-Reply-To: <87d1fmg6ib.fsf@wheatstone.g10code.de> References: <29305133-bb58-ff79-f467-12690a5f8dd2@jelmail.com> <87d1fmg6ib.fsf@wheatstone.g10code.de> Message-ID: <87k28rl6o8.fsf@alice.fifthhorseman.net> Hi all-- sorry for the late followup on this thread: On Mon 2017-01-16 14:16:28 -0500, Werner Koch wrote: > On Sun, 15 Jan 2017 00:39, gnupg at jelmail.com said: >> Just experimenting in a sandbox homedir, I noticed that the homedir path >> needs to be below a certain size. > > That is because on most Unix systems the file name for local socket is > limited in size. Local sockets are used for communication between the > components (e.g. gpg and gpg-agent). > > > The suggested solution is to create the socket in the /var/run > directory: Make sure that > > /var/run/user/$(id -u) > > exists before starting gpg or gpg-agent the socket will be created > there. Only is you use a non-default home directory (GNUPGHOME) you > need to manually create a sub-directory by using > > export GNUPGHOME=/foo/bar > gpgconf --create-socketdir Why does this need to be created manually? Why not try to create it if possible the first time there's a chance to use it, no matter what? or, if "no matter what" is too aggressive, why not at least try to create the ephemeral it if it's clear that the non-ephemeral location is longer than the max socket length? I personally like the simplicity and uniformity of "if /run/user/$(id -u)/ exists and is writable, then we will use it for the socketdir." What does GnuPG gain from having a known failure mode that requires a manual fix? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From dkg at fifthhorseman.net Wed Feb 15 18:21:20 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 15 Feb 2017 12:21:20 -0500 Subject: GPG homedir path length limit In-Reply-To: <87k28rl6o8.fsf@alice.fifthhorseman.net> References: <29305133-bb58-ff79-f467-12690a5f8dd2@jelmail.com> <87d1fmg6ib.fsf@wheatstone.g10code.de> <87k28rl6o8.fsf@alice.fifthhorseman.net> Message-ID: <87h93vl69b.fsf@alice.fifthhorseman.net> On Wed 2017-02-15 12:12:23 -0500, Daniel Kahn Gillmor wrote: > Why does this need to be created manually? Why not try to create it if > possible the first time there's a chance to use it, no matter what? [?] > What does GnuPG gain from having a known failure mode that requires a > manual fix? So one possible issue with my proposal is that by requiring explicit use of --create-socketdir you remind the user that they're also responsible for figuring out when to --remove-socketdir. However, that shouldn't be necessary either. If gpg-agent or dirmngr terminates knowing that they should remove their own sockets, they can do that and then just rmdir(2) on the ephemeral directory path. If rmdir returns ENOTEMPTY, that's fine -- presumably some other daemon is also using that path. if it returns successfully, then the directory is cleaned up, as it should be. In --supervised mode, the deamons should not be responsible for removing any sockets, so they would also not be responsible for cleaning up the parent directory either. does this make sense? Are there any downsides that i'm missing? --dkg From dkg at fifthhorseman.net Wed Feb 15 19:46:13 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 15 Feb 2017 13:46:13 -0500 Subject: Expanding web-of-trust with subkey In-Reply-To: <87bmu3fl7o.fsf@iki.fi> References: <87bmu3fl7o.fsf@iki.fi> Message-ID: <8737ffl2bu.fsf@alice.fifthhorseman.net> On Wed 2017-02-15 11:54:51 -0500, Teemu Likonen wrote: > That makes things very simple, in a way. I use "trust-model direct" and > do some checking in web pages or check consistent use of signatures. If > the key seems ok I'll "--edit-key", type "trust" and assign marginal or > full trust for that key. That's it. And because I have no use for other > people's signatures I also have "keyserver-options import-clean" so my > keyring remains small. right, so your use of "trust-model direct" switches the meaning of the "trust" flag from its usual "ownertrust" semantics to be what we'd normally call "validity". Note also that when you mark a key itself as "trusted" in this way, you're asking GnuPG to treat *all* user IDs on it as valid. So if the keyholder updates their key at some point in the future to add a new User ID, your GnuPG installation is going to blindly accept that User ID as legitimate. Please see A405E58AB3725B396ED1B85C1318EFAC5FBBDBCE as an example of this kind of thing. The keyholder cheekily added a new User ID "Satoshi Nakamoto (www.bitcoin.org) " after his OpenPGP certificate was created. I have met the keyholder, and i do not believe he is actually Satoshi Nakamoto ;) > When Debian 9 is released, with GnuPG 2.1, I'll try "trust-model > tofu+pgp" (trust on first use plus web of trust). It seems useful too. please be aware that if you switch from "trust-model direct" to "trust-model tofu+pgp", then your previous assignments of "trust" will transform into indications of "ownertrust". So someone whose OpenPGP certificate you previously meant to indicate was valid can now certify *other* OpenPGP certificates, and the pgp trust model will accept those certificates as correct :( Transitioning between trust models without overhauling the ownertrust db is not a workflow that seems particularly well-supported, unfortunately. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From jfschaff at gmail.com Wed Feb 15 19:06:36 2017 From: jfschaff at gmail.com (=?UTF-8?Q?Jean=2DFran=C3=A7ois_Schaff?=) Date: Wed, 15 Feb 2017 19:06:36 +0100 Subject: Problems with GPGME1.8 and Python 3.5 bindings In-Reply-To: <87inoe1i8m.fsf@europa.jade-hamburg.de> References: <87inoe1i8m.fsf@europa.jade-hamburg.de> Message-ID: Hi, Thanks for your advice, I could fix that and use the lib from Python. Do you know if there is any plan to better document the python bindings in the GPGME doc? I may be able to help with that if needed. Cheers Jean-Fran?ois Schaff 2017-02-13 11:46 GMT+01:00 Justus Winter : > Hi :) > > Jean-Fran?ois Schaff writes: > > > I'm new to gpg, and trying to use the Python bindings included in > > PGPME. I'm using Ubuntu 16.04 LTS. > > > > I have done the following things: > ... > > - compiled and installed gpgme-1.8.0 > > > > Everything seems to build and install as expected, but when I finally > > try to use the python package (import gpg) I get the following error: > > > > (venv) jfs at Danube-linux:~/webdev/mms$ python > > Python 3.5.2 (default, Nov 17 2016, 17:05:23) > > [GCC 5.4.0 20160609] on linux > > Type "help", "copyright", "credits" or "license" for more information. > >>>> import gpg > > Traceback (most recent call last): > ... > > ImportError: /home/jfs/webdev/mms/venv/local/lib/python3.5/site- > packages/gpg/_gpgme.cpython-35m-x86_64-linux-gnu.so: > > symbol gpgme_pubkey_algo_string, version GPGME_1.1 not defined in file > > libgpgme.so.11 with link time reference > > gpgme_pubkey_algo_string is new in GPGME 1.7. This suggests that the > version 1.8 that you built is not picked up. How you resolve that is > really up to you and your needs. You could for example add the > $your_install_prefix/lib to LD_LIBRARY_PATH in your bin/activate script. > > > Cheers, > Justus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Wed Feb 15 22:19:38 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 15 Feb 2017 16:19:38 -0500 Subject: Should we trust "MyMail-crypt for Gmail" Chrome extension? In-Reply-To: References: Message-ID: <87mvdnjgnp.fsf@alice.fifthhorseman.net> On Wed 2017-02-15 07:48:57 -0500, ankostis wrote (about "MyMail-crypt for Gmail"): > I'm wondering whether this open-source Chrome-extension for GPG on GMail[1] > is to be trusted; I mean, not to call home with my secret-key and passphrase. I've never heard of it. Mailvelope is what i've heard people recommend for the use case you describe. --dkg From fibmoro at gmx.de Wed Feb 15 13:47:53 2017 From: fibmoro at gmx.de (Fib Moro) Date: Wed, 15 Feb 2017 13:47:53 +0100 Subject: Aw: Re: Re: SmartCard v2.1 : factory reset fails In-Reply-To: <87h93viyd8.fsf@fsij.org> References: <87inodzel5.fsf@iwagami.gniibe.org> , <87h93viyd8.fsf@fsij.org> Message-ID: Hello, > > Let us fix a thing one by one. First, the Reset Code handling. > ok, let's do that. > For my OpenPGP card 2.1, the Admin PIN is "12345678" (no 9). > I can successfuly set the Reset Code. > > I confirmed that with wrong Admin PIN, I got the message "Error setting > the Reset Code: Bad PIN". > > Please test with 12345678. > -- > You are correct. I can confirm setting the Reset Code works now. Awaiting further instructions. ;-) From wolf at wolfsden.cz Wed Feb 15 23:58:26 2017 From: wolf at wolfsden.cz (Wolf) Date: Wed, 15 Feb 2017 23:58:26 +0100 Subject: Should we trust "MyMail-crypt for Gmail" Chrome extension? In-Reply-To: References: Message-ID: <20170215225826.atoxgzhugkxv2ziw@wolfsden.cz> Hi, I know nothing about the extension but would like to react to this: On , ankostis wrote: > This extension is the only alternative to use GPG with gmail in > corporate environments where SMTP ports are blocked (unless we > consider as an "alternative" to manually clear-signing each message > text to be sent with cmd-line). You can always combine virtual box, openvpn and stunnel to achieve traffic indistinguishable from https (as long as your stunnel endpoint listens on 443). No one blocks https these days. W. -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From gniibe at fsij.org Thu Feb 16 03:48:45 2017 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 16 Feb 2017 11:48:45 +0900 Subject: Aw: Re: SmartCard v2.1 : factory reset fails In-Reply-To: References: <87inodzel5.fsf@iwagami.gniibe.org> Message-ID: <87k28qonoy.fsf@iwagami.gniibe.org> Hello, Fib Moro wrote: > I start gpg in "--edit-key" mode. > Then I select a subkey I want to move to the card by issuing command "key 1". > After the "keytocard" command it asks me where to store the key for which I choose option 1 signature key. > It then prompts me for the privat key passphrase which I enter successfully. > Now it asks me for AdminPIN. Again with default value "123456789" I get the message "gpg: KEYTOCARD failed: Bad secret key" > Also the same issue occurs if I set the AdminPIN manually beforehand. > _____________ > > gpg> key 1 > ... > gpg> keytocard > Please select where to store the key: > (1) Signature key > (3) Authentication key > Your selection? 1 > gpg: KEYTOCARD failed: Bad secret key > ______________ Let us show more info about your key. I'm afraid your key size is not the one OpenPGP card supports. I tested RSA-2048 with OpenPGP card version 2.1, it works fine for me. -- From justus at g10code.com Thu Feb 16 10:12:36 2017 From: justus at g10code.com (Justus Winter) Date: Thu, 16 Feb 2017 10:12:36 +0100 Subject: GPG homedir path length limit In-Reply-To: <87k28rl6o8.fsf@alice.fifthhorseman.net> References: <29305133-bb58-ff79-f467-12690a5f8dd2@jelmail.com> <87d1fmg6ib.fsf@wheatstone.g10code.de> <87k28rl6o8.fsf@alice.fifthhorseman.net> Message-ID: <87bmu2h52z.fsf@europa.jade-hamburg.de> Daniel Kahn Gillmor writes: > [ Unknown signature status ] > Hi all-- > > sorry for the late followup on this thread: > > On Mon 2017-01-16 14:16:28 -0500, Werner Koch wrote: >> On Sun, 15 Jan 2017 00:39, gnupg at jelmail.com said: >>> Just experimenting in a sandbox homedir, I noticed that the homedir path >>> needs to be below a certain size. >> >> That is because on most Unix systems the file name for local socket is >> limited in size. Local sockets are used for communication between the >> components (e.g. gpg and gpg-agent). That is still wrong. The length of the path of the socket is not limited in any way, the length of the path passed to connect is. I still believe we could have/should have made it just work with any home directory. Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From Fredrik.Oberg at regionostergotland.se Thu Feb 16 12:13:01 2017 From: Fredrik.Oberg at regionostergotland.se (=?iso-8859-1?Q?=D6berg_Fredrik?=) Date: Thu, 16 Feb 2017 11:13:01 +0000 Subject: Cannot decrypt with 1.4.21 but with 1.2.2 Message-ID: I work in an organization where we sometimes receive and send encrypted files. This is far from our core business and we are no experts on this, so please bear with me. For managing the files, we use scripts calling gpg.exe. This is a Windows environment. We have been running version 1.2.2 for ages but as we upgraded our server, we decided to upgrade GnuPG to 1.4.21. We use the simple installer for GnuPG Classic. Yesterday we received an encrypted file which we couldn't decrypt. This is what happens: C:\>c:\GnuPG_2016\gpg --homedir=C:\Keyring -d -v -v -o output.txt input.gpg :pubkey enc packet: version 3, algo 16, keyid xxxxxxxxxxxxxxxxxxxxxxxxxxxxx data: [2048 bits] data: [2048 bits] gpg: public key is xxxxxxxx gpg: using subkey xxxxxxxx instead of primary key xxxxxxxx You need a passphrase to unlock the secret key for user: "My organization" 2048-bit ELG-E key, ID xxxxxxxx, created 2009-09-16 (main key ID xxxxxxxx) gpg: public key encrypted data: good DEK :encrypted data packet: length: unknown gpg: encrypted with 2048-bit ELG-E key, ID xxxxxxxx, created 2009-09-16 "My organization" gpg: 3DES encrypted data gpg: [don't know]: invalid packet (ctb=1b) gpg: decryption okay gpg: WARNING: message was not integrity protected gpg: [don't know]: invalid packet (ctb=68) Just to be sure, this is 1.4.21: C:\>c:\GnuPG_2016\gpg --version gpg (GnuPG) 1.4.21 My first guess was that the file was corrupted in some way, as we get if by ftp from one of our partners. After hashing and re-transfering the file we could rule out file corruption during transfer. Then I decided to try to decrypt the file using an older version of GnuPG, 1.2.2. Then decryption works with no problem: C:\>c:\gnupg\gpg -d -v -v -o output.txt input.gpg :pubkey enc packet: version 3, algo 16, keyid xxxxxxxxxxxxxxxxxxxxxxxxxxxxx data: [2048 bits] data: [2048 bits] gpg: public key is xxxxxxxx gpg: using secondary key xxxxxxxx instead of primary key xxxxxxxx You need a passphrase to unlock the secret key for user: "My organization" gpg: using secondary key xxxxxxxx instead of primary key xxxxxxxx 2048-bit ELG-E key, ID xxxxxxxx, created 2009-09-16 (main key ID xxxxxxxx) gpg: public key encrypted data: good DEK :encrypted data packet: length: unknown gpg: encrypted with 2048-bit ELG-E key, ID xxxxxxxx, created 2009-09-16 "My organization" gpg: 3DES encrypted data :literal data packet: mode b, created xxxxxxxx, name="", raw data: 0 bytes gpg: original file name='' gpg: decryption okay gpg: WARNING: message was not integrity protected Version is 1.2.2: C:\temp>c:\gnupg\gpg --version gpg (GnuPG) 1.2.2 Can anybody explain what is happening? Why can we decrypt the file with an older version, but not with the newest one? Regards /Fredrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From fibmoro at gmx.de Thu Feb 16 12:33:58 2017 From: fibmoro at gmx.de (Fib Moro) Date: Thu, 16 Feb 2017 12:33:58 +0100 Subject: Aw: Re: Re: SmartCard v2.1 : factory reset fails In-Reply-To: <87k28qonoy.fsf@iwagami.gniibe.org> References: <87inodzel5.fsf@iwagami.gniibe.org> , <87k28qonoy.fsf@iwagami.gniibe.org> Message-ID: Dear Yutaka, > > Let us show more info about your key. I'm afraid your key size > is not the one OpenPGP card supports. I tested RSA-2048 with > OpenPGP card version 2.1, it works fine for me. > -- > ================== 1. Moving keys to card ================== Using the correct default Admin PIN value of *12345678* I could now successfully move private keys to card, which also set the PIN retry counter correctly: >>>>>>>>>>>>> gpg/card> verify ... Key attributes ...: rsa4096 rsa4096 rsa4096 ... PIN retry counter : 3 3 3 ... <<<<<<<<<<<<< Sofar so good. =================== 2. Changing Admin PIN =================== However, one quite awkward behavior I noticed that I think caused a whole lot confusion on my side. On a card after fresh factory-reset, the first thing I did was trying to set Admin PIN: >>>>>>>>>>>>> gpg/card> admin Admin commands are allowed gpg/card> passwd gpg: OpenPGP card no. DXXX detected 1 - change PIN 2 - unblock PIN 3 - change Admin PIN 4 - set the Reset Code Q - quit Your selection? 3 <<<<<<<<<<<<< It then asks me to "Please enter the Admin PIN". Now, in the believe that *123456789* was the correct default Admin PIN value, I would enter this *wrong* value. I am then prompted to enter "New Admin PIN" value and confirm that. Let's say I use the value *smartcardrocks*. My change is then confirmed with; >>>>>>>>>>>>> PIN changed. <<<<<<<<<<<<< I would now be in the believe that *smartcardrocks* is the new correct Admin PIN. However, any subsequent command that would require the Admin PIN would fail (e.g. moving keys to card, setting reset code, changing admin pin). For example, when I try to set a new reset code I am asked to enter the Admin PIN. I enter *smartcardrocks* I get "Error setting the Reset Code: Bad PIN". I enter *12345678* I also get "Error setting the Reset Code: Bad PIN". I seems the Admin PIN is then broken and set to an "unknown" value. Can you replicate the above described behavior? Thank you kindly. fibmoro From jfschaff at gmail.com Thu Feb 16 15:01:31 2017 From: jfschaff at gmail.com (=?UTF-8?Q?Jean=2DFran=C3=A7ois_Schaff?=) Date: Thu, 16 Feb 2017 15:01:31 +0100 Subject: Problems with GPGME1.8 and Python 3.5 bindings In-Reply-To: <87inoe1i8m.fsf@europa.jade-hamburg.de> References: <87inoe1i8m.fsf@europa.jade-hamburg.de> Message-ID: Hi, 2017-02-13 11:46 GMT+01:00 Justus Winter : > Hi :) > > Jean-Fran?ois Schaff writes: > >> I'm new to gpg, and trying to use the Python bindings included in >> PGPME. I'm using Ubuntu 16.04 LTS. >> >> I have done the following things: > ... >> - compiled and installed gpgme-1.8.0 >> >> Everything seems to build and install as expected, but when I finally >> try to use the python package (import gpg) I get the following error: >> >> (venv) jfs at Danube-linux:~/webdev/mms$ python >> Python 3.5.2 (default, Nov 17 2016, 17:05:23) >> [GCC 5.4.0 20160609] on linux >> Type "help", "copyright", "credits" or "license" for more information. >>>>> import gpg >> Traceback (most recent call last): > ... >> ImportError: /home/jfs/webdev/mms/venv/local/lib/python3.5/site-packages/gpg/_gpgme.cpython-35m-x86_64-linux-gnu.so: >> symbol gpgme_pubkey_algo_string, version GPGME_1.1 not defined in file >> libgpgme.so.11 with link time reference > > gpgme_pubkey_algo_string is new in GPGME 1.7. This suggests that the > version 1.8 that you built is not picked up. How you resolve that is > really up to you and your needs. You could for example add the > $your_install_prefix/lib to LD_LIBRARY_PATH in your bin/activate script. > > > Cheers, > Justus Thank you Justus for your advice, I could fix that and use the lib from Python. I had not realized that both gpg and gpg2 are installed by default on Ubuntu 16.04 LTS. Do you know if there is any plan to better document the python bindings in the GPGME doc? I may be able to help with that if needed. Cheers, Jean-Fran?ois From justus at g10code.com Thu Feb 16 15:27:11 2017 From: justus at g10code.com (Justus Winter) Date: Thu, 16 Feb 2017 15:27:11 +0100 Subject: Problems with GPGME1.8 and Python 3.5 bindings In-Reply-To: References: <87inoe1i8m.fsf@europa.jade-hamburg.de> Message-ID: <878tp6gqio.fsf@europa.jade-hamburg.de> Hi, Jean-Fran?ois Schaff writes: > Thank you Justus for your advice, I could fix that and use the lib > from Python. Good. > I had not realized that both gpg and gpg2 are installed by default on > Ubuntu 16.04 LTS. How is that related to your problem? > Do you know if there is any plan to better document the python > bindings in the GPGME doc? Yes, there are plans. There currently is no documentation, because we wanted to find a solution that would cover GPGME as well as all bindings. Last year we spoke about that at one of our hackathons, and decided to give Sphinx a shot. > I may be able to help with that if needed. Help is always needed. However, the first step is to integrate Sphinx in our build system. If you feel up to that, great! We'd need a DCO From you. If you wanted to write documentation, also great, but that is not what we need right now. Cheers, Justus PS: You wrote almost the same mail yesterday. That is not helping... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From tlikonen at iki.fi Thu Feb 16 15:31:18 2017 From: tlikonen at iki.fi (Teemu Likonen) Date: Thu, 16 Feb 2017 16:31:18 +0200 Subject: Expanding web-of-trust with subkey In-Reply-To: <8737ffl2bu.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 15 Feb 2017 13:46:13 -0500") References: <87bmu3fl7o.fsf@iki.fi> <8737ffl2bu.fsf@alice.fifthhorseman.net> Message-ID: <8737feky15.fsf@iki.fi> Daniel Kahn Gillmor [2017-02-15 13:46:13-05] wrote: > right, so your use of "trust-model direct" switches the meaning of the > "trust" flag from its usual "ownertrust" semantics to be what we'd > normally call "validity". > > Note also that when you mark a key itself as "trusted" in this way, > you're asking GnuPG to treat *all* user IDs on it as valid. > So if the keyholder updates their key at some point in the future to > add a new User ID, your GnuPG installation is going to blindly accept > that User ID as legitimate. Yes. I have also considered (and used a little) local signatures for the same use case: local-sign a key after checking it on a web page or in a tofu-like manner. Local signature can obviously validate only selected user ids but so far I've concluded that signatures are too strong statement for not really checked "seems ok" keys. I know that there are certification levels (like "--default-cert-level 1") but it's just simpler to use "trust-model direct" and define the level directly. Changing the decision later is also easier. > please be aware that if you switch from "trust-model direct" to > "trust-model tofu+pgp", then your previous assignments of "trust" will > transform into indications of "ownertrust". That has been my assumption. Thanks for verifying. -- /// 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: 454 bytes Desc: not available URL: From wk at gnupg.org Thu Feb 16 17:54:33 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 16 Feb 2017 17:54:33 +0100 Subject: GPG homedir path length limit In-Reply-To: <87bmu2h52z.fsf@europa.jade-hamburg.de> (Justus Winter's message of "Thu, 16 Feb 2017 10:12:36 +0100") References: <29305133-bb58-ff79-f467-12690a5f8dd2@jelmail.com> <87d1fmg6ib.fsf@wheatstone.g10code.de> <87k28rl6o8.fsf@alice.fifthhorseman.net> <87bmu2h52z.fsf@europa.jade-hamburg.de> Message-ID: <87lgt6rs8m.fsf@wheatstone.g10code.de> On Thu, 16 Feb 2017 10:12, justus at g10code.com said: > That is still wrong. The length of the path of the socket is not > limited in any way, the length of the path passed to connect is. That is your experience from Linux but that is not in general true. The maximum length of a file length is limited and thus is the length of the socket. And that length limit depends on the file system > I still believe we could have/should have made it just work with any > home directory. The reason why we switched to /var/run is to allow the use of remotely mounted home directories without the redirect-file hack. That this also fixes build problems is merely a side effect. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Thu Feb 16 17:51:07 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 16 Feb 2017 17:51:07 +0100 Subject: GPG homedir path length limit In-Reply-To: <87k28rl6o8.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 15 Feb 2017 12:12:23 -0500") References: <29305133-bb58-ff79-f467-12690a5f8dd2@jelmail.com> <87d1fmg6ib.fsf@wheatstone.g10code.de> <87k28rl6o8.fsf@alice.fifthhorseman.net> Message-ID: <87poiirsec.fsf@wheatstone.g10code.de> On Wed, 15 Feb 2017 18:12, dkg at fifthhorseman.net said: > Why does this need to be created manually? Why not try to create it if > possible the first time there's a chance to use it, no matter what? So that the /var/run/user/ directory is not cluttered with many directories. Setting a different GNUPGHOME is an exception and thus it is fine to require an explicit creation. Remember that not /var/run does not need to be a temporary directort - there is more than Linux in this world. > I personally like the simplicity and uniformity of "if /run/user/$(id > -u)/ exists and is writable, then we will use it for the socketdir." That is non-portable. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From stefano.tranquillini at gmail.com Thu Feb 16 16:04:51 2017 From: stefano.tranquillini at gmail.com (Stefano Tranquillini) Date: Thu, 16 Feb 2017 16:04:51 +0100 Subject: GPG, subkeys smartcard and computer Message-ID: Hi all, I'm sort of new to GPG/PGP, I'm not new to the encryption/crypto world and to computers, however, some concepts are yet not clear to me. I can't get my head around on how to use GPG in the "correct" way to guarantee the maximum result. That is: protect, at the best, my privacy and also don't get the system too complicated. The problems that I've are multiple, I'll try to summarize them here asking for help. I've read the manual, but it's a bit outdated, and online I found scattered information that does not always explain why some decision are made. My ideal setup is: - Master generated on offline pc and stored in a cold storage - subkeys for the pc (main pc, that I use everyday) - i need (A)utenticate (E)encrypt (S)ign keys - subkeys for the smartcard - if I use a pc of someone else, and as backup for what is worth. (In the future I may switch to just the smartcard, removing the keys from pc, but I would like to have the keys on the pc for time being) - I would like to avoid moving the master ouside the offline pc/cold storage Create the master: I should create the master on a device that is not my primary one and that is not online. It seems kind of freak approach to me, but I can understand why. Once created, I backup it to a file which I store on a usb key or somewhere outside of computers. With the master I can create, later, subkeys for what I need and the revoke certificate in case of compromised subkeys. Other than the master key, do I've to export anything else (not talking of subkeys yet, that's next topic)? When creating the master, I've two possibility: (i) use the dafault setting that results in a (SC) key or (ii) set it as only (C). The best solution seems to be the second, right? ( http://security.stackexchange.com/questions/32386/why-do-pgp-master-keys-only-have-a-single-subkey-and-tie-certification-with-sig). Is it worth to use that approach or, as of today, the (i) is fine? I still don't get the full benefit of one or the other solution Create the subkey With the master key I can create subkeys. I should do it from the offline pc in which I created the key, or import the master in a pc and then create the subkeys (it doesn't sound so safe though). Now: - should each subkey be for only one scope (A) (S) (E) or is it fine if one key does two or three scopes (ASE) or (SE)? - once subkeys are creted I've to export them and also their revoke certifications (do they have one)? correct? - I've a smartcard, but I've also a pc, should I create 6 subkeys, 2 for A, 2 for S and 2 for E and move the 3 A S E to the yubikey and the other 3 to the pc?. - moving the keys on the smartcard is done via "keytocard" but to move the keys on the pc I've to export subkeys, will this export also the keys on the smartcard and then I'll need the smartcard to access some of those? how can I decide what to import where? - Do I've to rexport my public key or anything else to let the world know my subkeys? - Do I've to export anything else to achieve my scenario's goal? Am I missing anything? Or is there anything that can guide me to achieving my goals? PS: Sorry for the long questions, but I can't find online something that explains my scenario. Solutions are for base cases or for smart-card only. Well, probably there's a guide, but I can't find it out. -- Stefano -------------- next part -------------- An HTML attachment was scrubbed... URL: From Srikanth.Gangisetty at interoute.com Thu Feb 16 17:17:43 2017 From: Srikanth.Gangisetty at interoute.com (Srikanth Gangisetty) Date: Thu, 16 Feb 2017 16:17:43 +0000 Subject: Upgrade instructions required from GnuPG v2.0.14 to 2.1.18 Message-ID: <07ddfba6af39442eb5314b656eb2c1f3@NLPREXCH02.interoute.com> Hello Team Could you please provide us instructions how to upgrade 2.0.14 to 2.1.18 and also rollback instructions if anything goes wrong. Thank you Regards G Srikanth Srikanth Gangisetty Database Technology Consultant Interoute, New Castle House Castle Boulevard, Nottingham NG7 1FT UK direct line: +44 (0)1156847218 email: Srikanth.Gangisetty at Interoute.com [cid:image001.jpg at 01D21419.03FBFEB0]Interoute named Best Cloud Service Provider at the UK Cloud Awards 2016 [cid:image007.jpg at 01D28870.32A3DC80] [cid:image005.png at 01D28870.32A3DC80] [cid:image008.jpg at 01D28870.32A3DC80] [cid:image009.jpg at 01D28870.32A3DC80] [cid:image010.jpg at 01D28870.32A3DC80] Interoute Communications Limited is a limited company registered in England and Wales. Registered address: 31st Floor 25 Canada Square Canary Wharf London E14 5LQ Registered number: 4472687 ****************************************************************************************************** All quotes, offers or proposals are (i) made based on Interoute's standard terms and conditions (ii) subject to contract, survey and availability; and (iii) only valid for a period of 30 days from the date of this message. Information transmitted in this message is intended only for the addressee and may contain confidential and/or privileged material. If you have received this message in error, please send it back to us, and immediately and permanently delete it. Information on our terms of confidentiality & how we process data, monitor communications and for terms of use can be found on our website at www.interoute.com ****************************************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3198 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 15931 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 940 bytes Desc: image003.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 22474 bytes Desc: image004.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.png Type: image/png Size: 4140 bytes Desc: image005.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.jpg Type: image/jpeg Size: 15503 bytes Desc: image006.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image007.jpg Type: image/jpeg Size: 659 bytes Desc: image007.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image008.jpg Type: image/jpeg Size: 932 bytes Desc: image008.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image009.jpg Type: image/jpeg Size: 948 bytes Desc: image009.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image010.jpg Type: image/jpeg Size: 1009 bytes Desc: image010.jpg URL: From stardustrevolution.s.m at gmail.com Thu Feb 16 21:51:40 2017 From: stardustrevolution.s.m at gmail.com (Stephane R.) Date: Thu, 16 Feb 2017 15:51:40 -0500 Subject: Hi Message-ID: <95F52638-F1B0-4680-ACD3-E6680A04C797@gmail.com> Can I never receive a message from u again Sent from my iPad From rjh at sixdemonbag.org Thu Feb 16 23:27:25 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 16 Feb 2017 17:27:25 -0500 Subject: Upgrade instructions required from GnuPG v2.0.14 to 2.1.18 In-Reply-To: <07ddfba6af39442eb5314b656eb2c1f3@NLPREXCH02.interoute.com> References: <07ddfba6af39442eb5314b656eb2c1f3@NLPREXCH02.interoute.com> Message-ID: <0c2c6ab7-dda6-0302-ad15-1329a3d2af6c@sixdemonbag.org> > Could you please provide us instructions how to upgrade 2.0.14 to 2.1.18 > and also rollback instructions if anything goes wrong. This is a system administration question. You will have better luck asking on a mailing list devoted to your specific operating system. From fcassia at gmail.com Thu Feb 16 23:35:17 2017 From: fcassia at gmail.com (Fernando Cassia) Date: Thu, 16 Feb 2017 19:35:17 -0300 Subject: Hi In-Reply-To: <95F52638-F1B0-4680-ACD3-E6680A04C797@gmail.com> References: <95F52638-F1B0-4680-ACD3-E6680A04C797@gmail.com> Message-ID: On 2/16/17, Stephane R. wrote: > Can I never receive a message from u again You, or someone with access to your device, subscribed your e-mail address to this mailing list. A mailing list is a discussion list, based on e-mail. You need to unsubscribe yourself. Details on how to do so are at the URL linked at the bottom of every e-mail that you receive from this list FC -- During times of Universal Deceit, telling the truth becomes a revolutionary act - George Orwell From gniibe at fsij.org Fri Feb 17 01:00:00 2017 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 17 Feb 2017 09:00:00 +0900 Subject: Aw: Re: Re: SmartCard v2.1 : factory reset fails In-Reply-To: References: <87inodzel5.fsf@iwagami.gniibe.org> <87k28qonoy.fsf@iwagami.gniibe.org> Message-ID: <87h93tit4v.fsf@iwagami.gniibe.org> Hello, Thanks a lot for your report in detail, in the style which I can replicate. I'm afraid you are facing same issue what I encountered in 2011. CHANGE REFERENCE DATA (OpenPGP card specification 2.0): https://www.gniibe.org/log/bugreport/gnupg/openpgp-card-spec-2.0-chenge-reference-data.html IIUC, this protocol is due to smartcard practice and standard. I had asked Achim (the author of OpenPGPcard specification) if this could be changed. No positive answer, but I think that the problem is clear enough. Fib Moro wrote: > It then asks me to "Please enter the Admin PIN". > Now, in the believe that *123456789* was the correct default Admin PIN value, > I would enter this *wrong* value. > I am then prompted to enter "New Admin PIN" value and confirm that. > Let's say I use the value *smartcardrocks*. > My change is then confirmed with; > >>>>>>>>>>>>>> > PIN changed. > <<<<<<<<<<<<< Yes. Now, New Admin PIN is *9smartcardrocks*. > I would now be in the believe that *smartcardrocks* is the new correct Admin > PIN. I understand your expectation. It was exactly same of mine. But, new Admin PIN is *9smartcardrocks*, which is totally confusing. > However, any subsequent command that would require the Admin PIN would fail > (e.g. moving keys to card, setting reset code, changing admin pin). Naturally. > For example, when I try to set a new reset code I am asked to enter the Admin > PIN. > I enter *smartcardrocks* I get "Error setting the Reset Code: Bad PIN". > I enter *12345678* I also get "Error setting the Reset Code: Bad PIN". > > I seems the Admin PIN is then broken and set to an "unknown" value. > > Can you replicate the above described behavior? Yes. The bug (from my point of view) is still there. No, I don't have an idea to keep this problem forever. I am currently considering KDF generation scheme by host side. I'm going to send my proposal to Achim. In this new scheme, the length of string for PIN is fixed. And then, this problem will be no longer valid. That's my development now. -- From dkg at fifthhorseman.net Fri Feb 17 01:29:09 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 16 Feb 2017 19:29:09 -0500 Subject: GPG homedir path length limit In-Reply-To: <87bmu2h52z.fsf@europa.jade-hamburg.de> References: <29305133-bb58-ff79-f467-12690a5f8dd2@jelmail.com> <87d1fmg6ib.fsf@wheatstone.g10code.de> <87k28rl6o8.fsf@alice.fifthhorseman.net> <87bmu2h52z.fsf@europa.jade-hamburg.de> Message-ID: <87mvdlirsa.fsf@alice.fifthhorseman.net> On Thu 2017-02-16 04:12:36 -0500, Justus Winter wrote: > That is still wrong. The length of the path of the socket is not > limited in any way, the length of the path passed to connect is. this is a clever approach to *connect* to such a socket, on some systems. But if you ever use getsockname (e.g. common/sysutils.c and dirmngr/dns.c), the long socket path names are bound to fail on *any* system, right? --dkg From dkg at fifthhorseman.net Fri Feb 17 01:53:47 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 16 Feb 2017 19:53:47 -0500 Subject: GPG homedir path length limit In-Reply-To: <87poiirsec.fsf@wheatstone.g10code.de> References: <29305133-bb58-ff79-f467-12690a5f8dd2@jelmail.com> <87d1fmg6ib.fsf@wheatstone.g10code.de> <87k28rl6o8.fsf@alice.fifthhorseman.net> <87poiirsec.fsf@wheatstone.g10code.de> Message-ID: <87k28piqn8.fsf@alice.fifthhorseman.net> On Thu 2017-02-16 11:51:07 -0500, Werner Koch wrote: > So that the /var/run/user/ directory is not cluttered with many > directories. Setting a different GNUPGHOME is an exception and thus it > is fine to require an explicit creation. Remember that not /var/run > does not need to be a temporary directort - there is more than Linux in > this world. If it's an exception, it's infrequent. So by definition, we won't be cluttering /run/user/$(id -u)/gnupg/ with many directories. If we clean up the directories automatically as i recommended when the daemons terminate, it won't leave a cluttered residue. The one common work pattern that this misses is this one: * create a temporary GNUPGHOME for experimentation * when done, do: rm -rf "$GNUGHOME" Without the socketdir creation, the daemons will work as long the path is short enough, and they terminate cleanly when the temporary homedir is destroyed. With the socketdir creation, the daemons will work regardless of the path length, but they won't terminate cleanly if the temporary homedir is destroyed. That would be unfortunate. So my current proposal for GNU/Linux systems for daemons like gpg-agent and dirmngr when using a non-standard $GNUPGHOME is: * daemons create the ephemeral socketdir automatically if possible. * clients try the ephemeral socketdir first, then fall back to in-$GNUPGHOME sockets (i think this is already the case). * daemons watch the $GNUPGHOME with inotify, and auto-terminate if the $GNUPGHOME itself is destroyed. * daemons try to rmdir() on the ephemeral socketdir on termination, failing quietly on ENOTEMPTY. I've documented this as a bug report at: https://bugs.gnupg.org/gnupg/issue2964 >> I personally like the simplicity and uniformity of "if /run/user/$(id >> -u)/ exists and is writable, then we will use it for the socketdir." > > That is non-portable. What's non-portable about it? If it's not possible to create the directory, we don't create it, and fall back to trying locally. if it is possible, we do create it and use it. This thread should probably move over to gnupg-devel at some point, i guess... --dkg From idmsdba at nycap.rr.com Fri Feb 17 00:09:16 2017 From: idmsdba at nycap.rr.com (Michael A. Yetto) Date: Thu, 16 Feb 2017 18:09:16 -0500 Subject: Hi In-Reply-To: <95F52638-F1B0-4680-ACD3-E6680A04C797@gmail.com> References: <95F52638-F1B0-4680-ACD3-E6680A04C797@gmail.com> Message-ID: <20170216180831.5640c531@braetac.lighthouse.yetnet> On Thu, 16 Feb 2017 15:51:40 -0500 "Stephane R." writes, and having writ moves on: >Can I never receive a message from u again > >Sent from my iPad > If you look at the headers of every message, including your own, you will find the following header. List-Unsubscribe: , Use either the webpage or mailto URL to unsubscribe. If you never look back here for the answer to your question you'll have to try a different method. Mike Yetto -- "There is danger from all men. The only maxim of a free government ought to be to trust no man living with power to endanger the public liberty." - John Adams -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From justus at g10code.com Fri Feb 17 10:42:14 2017 From: justus at g10code.com (Justus Winter) Date: Fri, 17 Feb 2017 10:42:14 +0100 Subject: GPG homedir path length limit In-Reply-To: <87mvdlirsa.fsf@alice.fifthhorseman.net> References: <29305133-bb58-ff79-f467-12690a5f8dd2@jelmail.com> <87d1fmg6ib.fsf@wheatstone.g10code.de> <87k28rl6o8.fsf@alice.fifthhorseman.net> <87bmu2h52z.fsf@europa.jade-hamburg.de> <87mvdlirsa.fsf@alice.fifthhorseman.net> Message-ID: <87zihlduh5.fsf@europa.jade-hamburg.de> Daniel Kahn Gillmor writes: > On Thu 2017-02-16 04:12:36 -0500, Justus Winter wrote: >> That is still wrong. The length of the path of the socket is not >> limited in any way, the length of the path passed to connect is. > > this is a clever approach to *connect* to such a socket, Yes. > on some systems. Well, I tested it on all systems I had access to at that time. I could have written a small test program, and asked people to run it on systems we don't have access to. But we never got to that point :( > But if you ever use getsockname (e.g. common/sysutils.c and > dirmngr/dns.c), the long socket path names are bound to fail on *any* > system, right? Yes. And iirc I went over why we use getsockname and figured that we could do away with them. Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From sivmu at web.de Fri Feb 17 13:37:06 2017 From: sivmu at web.de (sivmu at web.de) Date: Fri, 17 Feb 2017 13:37:06 +0100 Subject: Download of public keys Message-ID: Some time ago I asked about the unencrypted download of public keys. The answer was that the current gnupg does use https by default to fetch the keys. I found the time to retest this on a new setup and found that gnupg 2.1.18 still uses http connections to fetch the keys. I uses a newly installes arch linux setup with basically nothing but the base linux tools and downloaded a public key whil sniffing on the network. All requests, first to keys.gnupg.net and tehn to some other keyservers were in plaintext. The default dirmngr.conf file provided by arch, which seems to use gnupg 2.1.18 without changes, contains the followging lines: # If exactly two keyservers are configured and only one is a Tor hidden # service, Dirmngr selects the keyserver to use depending on whether # Tor is locally running or not (on a per session base). keyserver hkp://jirk5u4osbsr34t5.onion keyserver hkp://keys.gnupg.net This would explain why no encryption is used. Is there something I missed or is this unintended? From stefano.tranquillini at gmail.com Fri Feb 17 12:31:07 2017 From: stefano.tranquillini at gmail.com (Stefano Tranquillini) Date: Fri, 17 Feb 2017 12:31:07 +0100 Subject: GPG, subkeys smartcard and computer Message-ID: Hi all, I'm sort of new to GPG/PGP, I'm not new to the encryption/crypto world and to computers, however, some concepts are yet not clear to me. I can't get my head around on how to use GPG in the "correct" way to guarantee the maximum result. That is: protect, at the best, my privacy and also don't get the system too complicated. The problems that I've are multiple, I'll try to summarize them here asking for help. I've read the manual, but it's a bit outdated, and online I found scattered information that does not always explain why some decision are made. My ideal setup is: - Master generated on offline pc and stored in a cold storage - subkeys for the pc (main pc, that I use everyday) - i need (A)utenticate (E)encrypt (S)ign keys - subkeys for the smartcard - if I use a pc of someone else, and as backup for what is worth. (In the future I may switch to just the smartcard, removing the keys from pc, but I would like to have the keys on the pc for time being) - I would like to avoid moving the master ouside the offline pc/cold storage Create the master: I should create the master on a device that is not my primary one and that is not online. It seems kind of freak approach to me, but I can understand why. Once created, I backup it to a file which I store on a usb key or somewhere outside of computers. With the master I can create, later, subkeys for what I need and the revoke certificate in case of compromised subkeys. Other than the master key, do I've to export anything else (not talking of subkeys yet, that's next topic)? When creating the master, I've two possibility: (i) use the dafault setting that results in a (SC) key or (ii) set it as only (C). The best solution seems to be the second, right? (http://security.stackexchange.com/questions/ 32386/why-do-pgp-master-keys-only-have-a-single-subkey-and- tie-certification-with-sig). Is it worth to use that approach or, as of today, the (i) is fine? I still don't get the full benefit of one or the other solution Create the subkey With the master key I can create subkeys. I should do it from the offline pc in which I created the key, or import the master in a pc and then create the subkeys (it doesn't sound so safe though). Now: - should each subkey be for only one scope (A) (S) (E) or is it fine if one key does two or three scopes (ASE) or (SE)? - once subkeys are creted I've to export them and also their revoke certifications (do they have one)? correct? - I've a smartcard, but I've also a pc, should I create 6 subkeys, 2 for A, 2 for S and 2 for E and move the 3 A S E to the yubikey and the other 3 to the pc?. - moving the keys on the smartcard is done via "keytocard" but to move the keys on the pc I've to export subkeys, will this export also the keys on the smartcard and then I'll need the smartcard to access some of those? how can I decide what to import where? - Do I've to rexport my public key or anything else to let the world know my subkeys? - Do I've to export anything else to achieve my scenario's goal? Am I missing anything? Or is there anything that can guide me to achieving my goals? PS: Sorry for the long questions, but I can't find online something that explains my scenario. Solutions are for base cases or for smart-card only. Well, probably there's a guide, but I can't find it out. -- Stefano -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralph at inputplus.co.uk Fri Feb 17 14:59:52 2017 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Fri, 17 Feb 2017 13:59:52 +0000 Subject: powertop(8) Points at gpg-agent. Message-ID: <20170217135952.3402B212CE@orac.inputplus.co.uk> Hi, gnupg 2.1.18-1 on Arch Linux. I noticed powertop ranking the gpg-agents, one per user, quite highly, and their impact is multiplied by their number. strace(1) showed the two-second select(2) timing out with no syscalls in between, and the forking of two siblings to have a `GETINFO pid' chat every minute. Hans-Christoph Steiner noticed back in 2012, and Werner pointed the relevant #defines. https://lists.gnupg.org/pipermail/gnupg-devel/2012-March/026589.html # define TIMERTICK_INTERVAL (2) # define CHECK_OWN_SOCKET_INTERVAL (60) #endif There's a few relevant patches by Daniel Kahn Gillmor, e.g. cancelling the socket check if inotify(7) can be used. https://lists.gnupg.org/pipermail/gnupg-devel/2016-November/032012.html Are there any plans to make gpg-agent consume less background resources? It remains running here when a user logs out. Is that common? A variety of users logging in over time divides TIMERTICK_INTERVAL quite a bit. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy From andrewg at andrewg.com Fri Feb 17 15:11:56 2017 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 17 Feb 2017 14:11:56 +0000 Subject: GPG, subkeys smartcard and computer In-Reply-To: References: Message-ID: Stefano, I meant to reply last night, but didn't fancy writing this out on a phone keyboard. No need to resend questions - this tends to be a high-latency list for people in odd time zones, working from home, on the move etc. NB all the below is IMHO, YMMV etc. :-D On 16/02/17 15:04, Stefano Tranquillini wrote: > > I can't get my head around on how to use GPG in the "correct" way to > guarantee the maximum result. That is: protect, at the best, my > privacy and also don't get the system too complicated. Both of those are subjective criteria... ;-) > My ideal setup is: > > * Master generated on offline pc and stored in a cold storage * > subkeys for the pc (main pc, that I use everyday) - i need > (A)utenticate (E)encrypt (S)ign keys * subkeys for the smartcard - > if I use a pc of someone else, and as backup for what is worth. (In > the future I may switch to just the smartcard, removing the keys > from pc, but I would like to have the keys on the pc for time being) > * I would like to avoid moving the master ouside the offline pc/cold > storage What you describe is a common scenario for those who want a little more physical security than a standard online key. If you are not an experienced gnupg user maybe you should try using the defaults for a while until you are comfortable. If you make a mess of encryption you run the risk of either a) losing access to your encrypted data or b) leaving your encrypted data wide open. You can choose for yourself which scenario is worse. ;-) But if you know what you're doing, then: Personally, if you have a smartcard I see no advantage in keeping the subkeys on your laptop (so long as you have a backup). If you want to take things one step at a time that's up to you - just understand that keeping an online copy of your subkeys negates the security advantages of having a smartcard, the point of which is that the key material never gets stored in a format accessible by malware. If you want to use your key on a friend's PC, just beware that if you don't trust it enough to keep a copy of your actual key on, you may not trust it enough to not alter your messages or keylog your PIN. Compromising the key material is the sexy bit of cryptanalysis, but it's usually much easier to work around security measures than break through them. > Create the master: > > I should create the master on a device that is not my primary one > and that is not online. It seems kind of freak approach to me, but > I can understand why. Once created, I backup it to a file which I > store on a usb key or somewhere outside of computers. With the > master I can create, later, subkeys for what I need and the revoke > certificate in case of compromised subkeys. Other than the master > key, do I've to export anything else (not talking of subkeys yet, > that's next topic)? Back up the entire .gnupg directory just to be sure. Technically, you can make do with just a backup of the secret keyring, but it will make your life a lot easier if you back up the public keyring and your trustdb also. > When creating the master, I've two possibility: (i) use the dafault > setting that results in a (SC) key or (ii) set it as only (C). The > best solution seems to be the second, right? > (http://security.stackexchange.com/questions/32386/why-do-pgp-master-keys-only-have-a-single-subkey-and-tie-certification-with-sig). > > > Is it worth to use that approach or, as of today, the (i) is fine? I > still don't get the full benefit of one or the other solution The second is a "cleaner" solution, but makes no practical difference. If you have S capability on your primary key but never use it, only your subkey signatures will ever exist, and only the subkey will therefore ever be checked. And if your primary is compromised you have worse problems. ;-) > Create the subkey > > With the master key I can create subkeys. I should do it from the > offline pc in which I created the key, or import the master in a pc > and then create the subkeys (it doesn't sound so safe though). Now: If you import your master to an online PC, you lose the advantages of keeping it offline in the first place. See below. > o should each subkey be for only one scope (A) (S) (E) or is it > fine if one key does two or three scopes (ASE) or (SE)? If you are using a smartcard, it is normal practice to generate a separate subkey for each usage. It is no harm, and has the advantage that you can rotate them separately. One thing that you should NEVER do is have E on a subkey that has any other capability, as there are known methods of tricking a user into decrypting data by getting them to sign a specially crafted plaintext. This is difficult to achieve in PGP, but better to be safe than sorry. > o once subkeys are creted I've to export them and also their revoke > certifications (do they have one)? correct? You do not create a revocation for subkeys, only for the primary. If you still have access to the primary you can revoke a subkey at any time. Revocations are only for when you lose control of your primary. I personally don't keep revocations, just multiple offline copies of my primary. This only works because I consider it vanishingly unlikely that I will forget my passphrase. YMMV. > o I've a smartcard, but I've also a pc, should I create 6 subkeys, > 2 for A, 2 for S and 2 for E and move the 3 A S E to the yubikey > and the other 3 to the pc?. Having more than one E subkey is a worthless exercise - most software will encrypt to the most recently created E subkey, meaning that whichever one you create first will never be used (and thus won't be able to decrypt anything). Having multiple S and A subkeys is doable, but this just means that your correspondents will have to check against both. Some systems will only authenticate against the most recently created A subkey. It may be more trouble than it's worth to manage multiple current subkeys this way. IMO, better stick to just one of each. > o moving the keys on the smartcard is done via "keytocard" but to > move the keys on the pc I've to export subkeys, will this export > also the keys on the smartcard and then I'll need the smartcard to > access some of those? how can I decide what to import where? If you run "keytocard" and then save your changes, you will delete the on-disk copy of those subkeys. They will only then exist on the smartcard. I normally don't recommend this, as it means you have no way to back up your E subkey, and if your smartcard breaks you then lose access to all data encrypted to it. If you are keeping your master offline, there is IMO little extra risk in also keeping an offline copy of your E subkey. In order to do this, once you run "keytocard" on all three subkeys you should immediately quit gnupg *without saving*. This will ensure that the on-disk copy is not deleted. If you need to keep a copy of your subkeys on a laptop or other device, use --export-secret-subkeys and transfer just that file to the device. Again, I don't see the point in doing this for a laptop if you have a smartcard - the only use case I have found for it is if you have a device such as a smartphone that can't read smartcards. This does of course mean that your subkeys are now more vulnerable to malware than they would be if they were stored only offline and on the smartcard. This is a compromise that you will have to decide is worth the convenience or not. On the other hand, not all software will import bare subkeys, so again this may be of little actual use. > o Do I've to rexport my public key or anything else to let the > world know my subkeys? In general, any time you create, change the expiry on or revoke a primary key, subkey or ID you should republish your public key. > Am I missing anything? Or is there anything that can guide me to > achieving my goals? If you want to keep an offline copy of your secret key material, I recommend Tails (https://tails.boum.org). There are some hoops to jump through to get a persistent storage partition set up, but it is well supported and designed for the use case of managing sensitive data offline. It has the advantage that you don't need a separate offline computer for your key storage, but can boot your normal PC from a USB key and be reasonably confident that the secret key material will stay on the USB key. I have written a tool to (mostly) automate the above procedure, but it is still not ready for production use. Contact me off-list if you'd like to help test. Andrew. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Fri Feb 17 17:31:31 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 17 Feb 2017 17:31:31 +0100 Subject: Download of public keys In-Reply-To: References: Message-ID: <892033eb-bc24-4014-a6f6-9edbf5b4188d@sumptuouscapital.com> On 02/17/2017 01:37 PM, sivmu at web.de wrote: > Is there something I missed or is this unintended? gnupg does not ship an installed dirmngr.conf, when no keyserver is specified it defaults to hkps://hkps.pool.sks-keyservers.net, the existence of a (I presume) arch installed dirmngr.conf changes this behavior. Whether that is intended or not is a question for your distribution's package maintainer. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Qui audet vincit Who dares wins -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From sivmu at web.de Fri Feb 17 19:00:04 2017 From: sivmu at web.de (sivmu at web.de) Date: Fri, 17 Feb 2017 19:00:04 +0100 Subject: Download of public keys Message-ID: Am 17.02.2017 um 17:31 schrieb Kristian Fiskerstrand: > On 02/17/2017 01:37 PM, sivmu at web.de wrote: >> Is there something I missed or is this unintended? > > gnupg does not ship an installed dirmngr.conf, when no keyserver is > specified it defaults to hkps://hkps.pool.sks-keyservers.net, the > existence of a (I presume) arch installed dirmngr.conf changes this > behavior. > > Whether that is intended or not is a question for your distribution's > package maintainer. > Arch does not ship a dirmngr.conf either as far as I can see. When running the gpg command for the first time on a new system, the dirmngr.conf file is creates together with some other files. I just tested it again on ubuntu 16.04.2 and the same file appear in the gnupg directory, so it does not seem to be a distribution issue. It seems that gnupg does ship this template file as dirmngr-conf.skel although I am not sure if the distributions have anything to do with it being copied to the user directory. In any case, it might be a good idea to change the template gnupg ships Changing the lines: keyserver hkp://jirk5u4osbsr34t5.onion keyserver hkp://keys.gnupg.net to keyserver hkps://jirk5u4osbsr34t5.onion keyserver hkps://keys.gnupg.net would solve this I guess. I will although check with the arch maintainer about this to be sure but I do not think this is a distro issue From kristian.fiskerstrand at sumptuouscapital.com Fri Feb 17 19:17:22 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 17 Feb 2017 19:17:22 +0100 Subject: Download of public keys In-Reply-To: References: Message-ID: On 02/17/2017 07:00 PM, sivmu at web.de wrote: > keyserver hkps://jirk5u4osbsr34t5.onion > keyserver hkps://keys.gnupg.net > > would solve this I guess. No, that'd result in certificate errors and non-responsive servers -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Qui audet vincit Who dares wins -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Fri Feb 17 20:43:09 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 17 Feb 2017 20:43:09 +0100 Subject: Download of public keys In-Reply-To: References: Message-ID: <576039c4-4d7d-86f0-81ac-9912ce3328f6@sumptuouscapital.com> On 02/17/2017 07:17 PM, Kristian Fiskerstrand wrote: > On 02/17/2017 07:00 PM, sivmu at web.de wrote: >> keyserver hkps://jirk5u4osbsr34t5.onion >> keyserver hkps://keys.gnupg.net >> >> would solve this I guess. > > No, that'd result in certificate errors and non-responsive servers > That said, you are indeed correct, and skel file is used to create dirmngr.conf on other systems as well (it has been a while since starting with a fresh homedir :) ) ... if wanting hkps the latter should be switched to hkps://hkps.pool.sks-keyservers.net ,the former is protected already as tor usage would be to an endpoint running a tor hidden service. That change would also be consistent with https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=8fb482252436b3b4b0b33663d95d1d17188ad1d9 -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Qui audet vincit Who dares wins -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Fri Feb 17 20:43:06 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 17 Feb 2017 14:43:06 -0500 Subject: powertop(8) Points at gpg-agent. In-Reply-To: <20170217135952.3402B212CE@orac.inputplus.co.uk> References: <20170217135952.3402B212CE@orac.inputplus.co.uk> Message-ID: <87h93shad1.fsf@alice.fifthhorseman.net> On Fri 2017-02-17 08:59:52 -0500, Ralph Corderoy wrote: > There's a few relevant patches by Daniel Kahn Gillmor, e.g. cancelling > the socket check if inotify(7) can be used. > https://lists.gnupg.org/pipermail/gnupg-devel/2016-November/032012.html We're shipping these patches in debian testing and unstable right now, and i don't think i've seen any problems with the current set. You can find the current set at: https://sources.debian.net/src/gnupg2/2.1.18-6/debian/patches/gpg-agent-idling/ You can also find a set of similar patches for dirmngr, which has the same issue: https://sources.debian.net/src/gnupg2/2.1.18-6/debian/patches/dirmngr-idling/ I would be happy to merge any of these upstream if the upstream team wants them. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From dkg at fifthhorseman.net Fri Feb 17 21:18:14 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 17 Feb 2017 15:18:14 -0500 Subject: GPG homedir path length limit In-Reply-To: <87zihlduh5.fsf@europa.jade-hamburg.de> References: <29305133-bb58-ff79-f467-12690a5f8dd2@jelmail.com> <87d1fmg6ib.fsf@wheatstone.g10code.de> <87k28rl6o8.fsf@alice.fifthhorseman.net> <87bmu2h52z.fsf@europa.jade-hamburg.de> <87mvdlirsa.fsf@alice.fifthhorseman.net> <87zihlduh5.fsf@europa.jade-hamburg.de> Message-ID: <871suwh8qh.fsf@alice.fifthhorseman.net> On Fri 2017-02-17 04:42:14 -0500, Justus Winter wrote: > Well, I tested it on all systems I had access to at that time. I could > have written a small test program, and asked people to run it on systems > we don't have access to. But we never got to that point :( That would be a way to advance this conversation, i think :) However, path length may only be one concern. What about other scenarios, like trying to operate with a read-only $GNUPGHOME ? Is that something we want to support? What about a $GNUPGHOME that resides on a network-mount drive, or a filesystem that doesn't support unix-domain sockets? >> But if you ever use getsockname (e.g. common/sysutils.c and >> dirmngr/dns.c), the long socket path names are bound to fail on *any* >> system, right? > > Yes. And iirc I went over why we use getsockname and figured that we > could do away with them. but they're still there! if they're not necessary, we should remove them. useful diffs with more -'s than +'s are very nice contributions to any complex software project :) --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From sivmu at web.de Fri Feb 17 21:46:21 2017 From: sivmu at web.de (sivmu at web.de) Date: Fri, 17 Feb 2017 21:46:21 +0100 Subject: Download of public keys Message-ID: Am 17.02.2017 um 20:43 schrieb Kristian Fiskerstrand: > On 02/17/2017 07:17 PM, Kristian Fiskerstrand wrote: >> On 02/17/2017 07:00 PM, sivmu at web.de wrote: >>> keyserver hkps://jirk5u4osbsr34t5.onion >>> keyserver hkps://keys.gnupg.net >>> >>> would solve this I guess. >> >> No, that'd result in certificate errors and non-responsive servers >> > > That said, you are indeed correct, and skel file is used to create > dirmngr.conf on other systems as well (it has been a while since > starting with a fresh homedir :) ) ... if wanting hkps the latter should > be switched to hkps://hkps.pool.sks-keyservers.net ,the former is > protected already as tor usage would be to an endpoint running a tor > hidden service. > > That change would also be consistent with > https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=8fb482252436b3b4b0b33663d95d1d17188ad1d9 > Not quite sure I get this. So what this means is that effectively gnupg still uses plaintext connections to update public keys by default, does it not? If the change I suggested is not correct, shouldn't we find another way to use secure connection by default whenever possible? As it is now, the default fallback mentioned in the referenced commit never takes effect as long as the skel file is used. From kristian.fiskerstrand at sumptuouscapital.com Fri Feb 17 21:57:42 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 17 Feb 2017 21:57:42 +0100 Subject: Download of public keys In-Reply-To: References: Message-ID: <918c95e1-a05f-695b-b4f1-72f292315dfe@sumptuouscapital.com> On 02/17/2017 09:46 PM, sivmu at web.de wrote: > Am 17.02.2017 um 20:43 schrieb Kristian Fiskerstrand: >> On 02/17/2017 07:17 PM, Kristian Fiskerstrand wrote: >> >> That change would also be consistent with >> https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=8fb482252436b3b4b0b33663d95d1d17188ad1d9 >> > >> > Not quite sure I get this. > > So what this means is that effectively gnupg still uses plaintext > connections to update public keys by default, does it not? Yes (if not a tor configuration locally) > If the > change I suggested is not correct, shouldn't we find another way to > use secure connection by default whenever possible? Probably nitpick, but it would likely increase privacy - not security. > > As it is now, the default fallback mentioned in the referenced commit > never takes effect as long as the skel file is used. > Never would be inaccurate; kristianf at ares ~/workspace $ mkdir abc kristianf at ares ~/workspace $ gpg --homedir abc --recv-key 94CBAFDD30345109561835AA0B7F8B60E3EDFAE3 -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Qui audet vincit Who dares wins -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From sivmu at web.de Fri Feb 17 22:28:19 2017 From: sivmu at web.de (sivmu at web.de) Date: Fri, 17 Feb 2017 22:28:19 +0100 Subject: Download of public keys Message-ID: Am 17.02.2017 um 21:57 schrieb Kristian Fiskerstrand: > On 02/17/2017 09:46 PM, sivmu at web.de wrote: >> Am 17.02.2017 um 20:43 schrieb Kristian Fiskerstrand: >>> On 02/17/2017 07:17 PM, Kristian Fiskerstrand wrote: > > >>> >>> That change would also be consistent with >>> https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=8fb482252436b3b4b0b33663d95d1d17188ad1d9 >>> >> >>> >> Not quite sure I get this. >> >> So what this means is that effectively gnupg still uses plaintext >> connections to update public keys by default, does it not? > > Yes (if not a tor configuration locally) > >> If the >> change I suggested is not correct, shouldn't we find another way to >> use secure connection by default whenever possible? > > Probably nitpick, but it would likely increase privacy - not security. > That was the goal all along, as mentioned in the initial post some weeks ago. Especially when the complete keyring is updated, this leaks the complete contact list to the network, which is kinda bad. And privacy is kinda also somthing people use gnupg for isn't it. So I don't know the best way to change this but I would like to suggest that future versions use https only by default, e.g. by changing the skel file. From peter at digitalbrains.com Sat Feb 18 16:15:04 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 18 Feb 2017 16:15:04 +0100 Subject: Hybrid keysigning party, your opinion? In-Reply-To: <46a4ec4d-d5da-432f-7210-40141aaf15fc@twopif.net> References: <46a4ec4d-d5da-432f-7210-40141aaf15fc@twopif.net> Message-ID: Hello Lachlan, On 15/02/17 14:32, Lachlan Gunn wrote: > Given the discussion on the list before, now that CCC has come and gone > I'm curious as to how well this worked. It failed on a trivial point: by the Friday before the congress, I had only received four signups. A list with five keys is a poor list indeed. I switched the model to the classic "bring keyslips" model. > Is it an innovation worth > perpetuating? I think it would work. I'd like to try again. In fact, given that we don't need to place trust in the paper copies, I think it would actually work if I kept sign-up open until just before the party, and printed a stack of "scrubbed" lists myself to hand out. However, it was my feeling that some people would not feel comfortable with this brand-spanking-new "no need to trust me, really! Have my stuff" type of lists, so I didn't do that. I intended to cater to the untrusting crowd by giving them enough time to print their own lists and do it the in the usual Sassaman Efficient way. Given that this would have, on the flip side, catered to the handful of people who showed up without keyslips, perhaps it would still be a fair tradeoff for limiting the untrusting people in their possibilities. You could receive sign-ups by e-mail until the latest moment, and you would print the untrusted lists so anybody who didn't bring any keyslips could still be on that list by signing up. Note that there is no value judgement in how I use "untrusting" here, it's just a way to sum up a group of people in a single adjective. Next opportunity for a keysigning party for me will be SHA 2017, starting the 4th of August in Zeewolde, The Netherlands[1]. O Come, All Ye Hackful! Adeste Fiddle-es[2]! Cheers, Peter. [1] [2] Fiddle-es: those who tinker. -- 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 philip.jackson at nordnet.fr Sat Feb 18 17:59:27 2017 From: philip.jackson at nordnet.fr (Philip Jackson) Date: Sat, 18 Feb 2017 17:59:27 +0100 Subject: Hybrid keysigning party, your opinion? In-Reply-To: References: <46a4ec4d-d5da-432f-7210-40141aaf15fc@twopif.net> Message-ID: <3d1212a0-75ba-baeb-b547-0be64a921a7a@nordnet.fr> On 18/02/17 16:15, Peter Lebbing wrote: > O Come, All Ye Hackful! Adeste Fiddle-es[2]! Yea ! Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 520 bytes Desc: OpenPGP digital signature URL: From fibmoro at gmx.de Fri Feb 17 11:35:00 2017 From: fibmoro at gmx.de (Fib Moro) Date: Fri, 17 Feb 2017 11:35:00 +0100 Subject: Aw: Re: Re: Re: SmartCard v2.1 : factory reset fails In-Reply-To: <87h93tit4v.fsf@iwagami.gniibe.org> References: <87inodzel5.fsf@iwagami.gniibe.org> <87k28qonoy.fsf@iwagami.gniibe.org> , <87h93tit4v.fsf@iwagami.gniibe.org> Message-ID: Dear Yutaka, > > Thanks a lot for your report in detail, in the style which I can replicate. > > I'm afraid you are facing same issue what I encountered in 2011. > > CHANGE REFERENCE DATA (OpenPGP card specification 2.0): > https://www.gniibe.org/log/bugreport/gnupg/openpgp-card-spec-2.0-chenge-reference-data.html > > IIUC, this protocol is due to smartcard practice and standard. I had > asked Achim (the author of OpenPGPcard specification) if this could be > changed. No positive answer, but I think that the problem is clear > enough. > Then I'm very much relieved that my issue was confirmed. :-) To reflect a little further, locking the smartcard (AdminPIN) is probably a rather rare event, it was actually a first time experience for me. However, considering the importance of a functioning and secure key, the process of restoring the key caused quite some trouble for me: The first blocking point I encountered was that when reimporting the private key (subkeys) into my keyring they would be unusable as they would still refer to the keys on the blocked smartcard. To remove these "stubs" I had to manually delete the according keygrip files in ".gnupg/private-keys-v1.d". Only then would an import of the private keys work correctly. The next challenge was to find out if and how I could actually reset my version of smartcard. Fortunately I could find the instructions by Werner Koch in a mailing list post from 2009. It was probably in this situation of stress that I entered the wrong Admin PIN of *123456789* which left me entirely confused and frustrated. Maybe I should write a little post of "How to reset your smartcard (version > 2.1) and things that could go wrong" so the next candidates can benefit from the learning? In any case, I would like to thank you and all the people who patiently helped me along the way to resolve this issue. Last but not least I'd like to thank all the GnuPG developers for creating and maintaining this technology. Often I hear or read from people that GnuPG was to "hard" and "out of date". I still consider it one of the most important tools for secure communication in our digital age. So thank you very much again for your efforts! Sincerely, fibmoro From stefano.tranquillini at gmail.com Sun Feb 19 09:41:24 2017 From: stefano.tranquillini at gmail.com (Stefano Tranquillini) Date: Sun, 19 Feb 2017 09:41:24 +0100 Subject: GPG, subkeys smartcard and computer In-Reply-To: References: Message-ID: thanks, Sorry for the double messages, I sent the first before subscribing to the list and I tought it was not forwarded to the mailing list. Briefly: - use tails to genereate master (default settings) and subkeys - export the public key and fingerprints - backup master to a cold storage - export the subkeys for later usage - move the subkeys into the laptop I'll skip the smart card now, I'll only generate and add to it a A subkeys for accessing ssh in case I'm away of the pc. I think I can have multiple A subkeys, not like E keys that only the last is used, and use them to ssh servers if all these subkeys are added to the server Regarding the rest: On Fri, Feb 17, 2017 at 3:11 PM, Andrew Gallagher wrote: > ?... cut ... > > If you run "keytocard" and then save your changes, you will delete the > on-disk copy of those subkeys. They will only then exist on the > smartcard. I normally don't recommend this, as it means you have no way > to back up your E subkey, and if your smartcard breaks you then lose > access to all data encrypted to it. If you are keeping your master > offline, there is IMO little extra risk in also keeping an offline > copy of your E subkey. In order to do this, once you run "keytocard" on > all three subkeys you should immediately quit gnupg *without saving*. > This will ensure that the on-disk copy is not deleted. > ?wait, If i've a subkey E (called E1) and I lose it (e.g. it was on the smartcard). Can't I create a new E (called E2) from my master and decrypt the data? Or the data encrypted are decriptable only by the exact E (E1 in this case) that was used to encrypt it? ?Can't I export the subkeys to a file and backup that file? and then move the keys to the card? Will I be able to restore the keys if they get lost? ?Sending you a sperarte email for the script (which seems the one you have on the website)? -- Stefano -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrewg at andrewg.com Sun Feb 19 11:24:10 2017 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sun, 19 Feb 2017 10:24:10 +0000 Subject: GPG, subkeys smartcard and computer In-Reply-To: References: Message-ID: > On 19 Feb 2017, at 08:41, Stefano Tranquillini wrote: > > wait, If i've a subkey E (called E1) and I lose it (e.g. it was on the smartcard). > Can't I create a new E (called E2) from my master and decrypt the data? Or the data encrypted are decriptable only by the exact E (E1 in this case) that was used to encrypt it? You need the *exact* subkey. This is why I make such a big deal about backups! Subkeys are not "created from" the primary, but completely at random. If you create a new subkey it will be completely different from any previous ones. Attaching the subkey to a primary is just a statement saying "don't use the primary key, use this subkey instead". The keys are not mathematically related. This is a feature! ;-) > ?Can't I export the subkeys to a file and backup that file? and then move the keys to the card? Will I be able to restore the keys if they get lost? Easier to just back up the entire .gnupg directory. Why complicate the restore process? A -------------- next part -------------- An HTML attachment was scrubbed... URL: From lachlan at twopif.net Sun Feb 19 11:53:38 2017 From: lachlan at twopif.net (Lachlan Gunn) Date: Sun, 19 Feb 2017 21:23:38 +1030 Subject: Hybrid keysigning party, your opinion? In-Reply-To: References: <46a4ec4d-d5da-432f-7210-40141aaf15fc@twopif.net> Message-ID: <170d7219-2cc1-315b-3d63-44a9512bd74e@twopif.net> Le 2017-02-19 ? 01:45, Peter Lebbing a ?crit : > It failed on a trivial point: by the Friday before the congress, I had only > received four signups. A list with five keys is a poor list indeed. I switched > the model to the classic "bring keyslips" model. Ah, fair enough. That's a bit unfortunate, but thanks for the report! Thanks, Lachlan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Sun Feb 19 12:19:35 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 19 Feb 2017 12:19:35 +0100 Subject: GPG, subkeys smartcard and computer In-Reply-To: References: Message-ID: Hi Stefano, On 19/02/17 09:41, Stefano Tranquillini wrote: > I think I can have multiple A subkeys, not like E keys that only the > last is used, and use them to ssh servers if all these subkeys are > added to the server It depends on how the authorized authentication keys are added to the server. If you just manually put them in ~/.ssh/authorized_keys, sure, no problem. But Andrew did just write: On 17/02/17 15:11, Andrew Gallagher wrote: > Some systems will only authenticate against the most recently created > A subkey. I have no personal experience, but I think it's possible this relates to MonkeySphere handling the authorized keys on the server? 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 andrewg at andrewg.com Sun Feb 19 13:45:08 2017 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sun, 19 Feb 2017 12:45:08 +0000 Subject: GPG, subkeys smartcard and computer In-Reply-To: References: Message-ID: <7B5864CB-9A8D-4407-892F-FE4AC547CD15@andrewg.com> > On 19 Feb 2017, at 11:19, Peter Lebbing wrote: > >> On 17/02/17 15:11, Andrew Gallagher wrote: >> Some systems will only authenticate against the most recently created >> A subkey. > > I have no personal experience, but I think it's possible this relates to > MonkeySphere handling the authorized keys on the server? In my personal experience, monkeysphere has correctly added all valid A subkeys. But I have a niggling doubt that I once read complaints from somebody somewhere (not helpful, I know) that whatever system they were using had trouble with multiple valid A subkeys. The main reason I am wary of having multiple subkeys for the same usage is that it just adds more complexity to an already complex system. In the case of E, multiple subkeys cause utter chaos. And in the case of A and S, there next to no benefit - if one of your subkeys is lost you should revoke it immediately anyway, and you can generate a new subkey while you're at it. Having an extra subkey generated in advance only gives you a tiny window of extra utility. Andrew. From peter at digitalbrains.com Sun Feb 19 15:11:45 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 19 Feb 2017 15:11:45 +0100 Subject: GPG, subkeys smartcard and computer In-Reply-To: <7B5864CB-9A8D-4407-892F-FE4AC547CD15@andrewg.com> References: <7B5864CB-9A8D-4407-892F-FE4AC547CD15@andrewg.com> Message-ID: <0e30accd-946b-a198-d1f7-eacb0964c2f2@digitalbrains.com> On 19/02/17 13:45, Andrew Gallagher wrote: > In my personal experience, monkeysphere has correctly added all > valid A subkeys. Thanks for the clarification. > But I have a niggling doubt that I once read complaints from somebody > somewhere (not helpful, I know) that whatever system they were using > had trouble with multiple valid A subkeys. Only one way to get this knowledge to the surface: we obviously need to advise everybody to generate multiple A subkeys so somebody will complain it doesn't work! Just kidding :). > And in the case of A and S, there next to no benefit I agree. I can't think of a compelling reason to use multiple ones; all things considered, the added hassle is the larger factor in every scenario I could think of just now. If you can't duplicate your A or S subkey when you want to, for instance because you have it on smartcard only, it's just as easy to create a new key and overwrite the old one on the smart card. Then you can just use your new subkey everywhere from now on. Just watch out you do it in the right order with respect to A keys: first roll out the new key on all systems you want to authenticate to, and only then overwrite your old key on your smartcard :-). However, maybe someone has come across a reason to do it where it would be worth the hassle. There certainly are people using multiple S subkeys. 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 dgouttegattat at incenp.org Sun Feb 19 15:58:56 2017 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sun, 19 Feb 2017 15:58:56 +0100 Subject: GPG, subkeys smartcard and computer In-Reply-To: <0e30accd-946b-a198-d1f7-eacb0964c2f2@digitalbrains.com> References: <7B5864CB-9A8D-4407-892F-FE4AC547CD15@andrewg.com> <0e30accd-946b-a198-d1f7-eacb0964c2f2@digitalbrains.com> Message-ID: <0a754032-373c-4619-705b-cc1b1427e8a5@incenp.org> On 02/19/2017 03:11 PM, Peter Lebbing wrote: > However, maybe someone has come across a reason to do it where it would > be worth the hassle. There certainly are people using multiple S subkeys. Some time ago, I did some experiments with a RSA master key with two sets of subkeys: RSA subkeys and ECC-based subkeys (ECDSA for the signing subkey, ECDH for the encryption subkey). The idea was to test whether such a setup could be used by someone wanting to use elliptic-curve cryptography, but at the same time not wanting to cut herself from people still using GnuPG 2.0.x (which has no support for ECC). Let's say Alice and Bob both use GnuPG 2.1, but Charlie uses GnuPG 2.0. And Alice uses the setup described above, where the ECC-based subkeys were created *after* the RSA-based subkeys. For encryption: When Bob wants to encrypt a message to Alice, his gpg program automatically selects the latest encryption subkey it can use, that is, the ECDH subkey. On the other hand, when Charlie wants to encrypt a message to Alice, his gpg program skips the unsupported ECDH subkey and automatically selects the remaining RSA subkey. So everything work, Alice and Bob can benefit from ECC support in GnuPG 2.1 while still allowing Charlie to use RSA. For signing: Alice signs her messages with *both* her RSA subkey and her ECDSA subkey (using multiple --local-user options), allowing both Bob and Charlie to verify her messages even though Charlie is stuck with GnuPG 2.0 and RSA. (Eventually, Charlie will upgrade to GnuPG 2.1, and Alice will then revoke her RSA subkeys.) Disclaimer: I am not advocating such a setup, that I don't even actually use. I did those tests mostly out of curiosity (I stick to RSA keys even with GnuPG 2.1, so I have no need to worry about backward compatibility). But I guess it's a possible reason for wanting more than one set of subkeys. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From nils at familievogels.nl Sun Feb 19 21:16:59 2017 From: nils at familievogels.nl (Nils Vogels) Date: Sun, 19 Feb 2017 21:16:59 +0100 Subject: Hybrid keysigning party, your opinion? In-Reply-To: References: <46a4ec4d-d5da-432f-7210-40141aaf15fc@twopif.net> Message-ID: <4be0f.02234dc6be.9633E9D0-9736-4200-97FF-9ABEE5256254@familievogels.nl> Hey Peter, I've submitted a keysigning party at sha2017 earlier, so we should have a slot to try something out. I'll read up on this thread from the archives, but I'm exploring possibilities to enhance the FOSDEM format with the use of QR for on-the-spot signing for those who want to and don't mind having signatures submitted by signers to keyservers. On 18 February 2017 16:15:04 CET, Peter Lebbing wrote: >Hello Lachlan, > > >On 15/02/17 14:32, Lachlan Gunn wrote: >> Given the discussion on the list before, now that CCC has come and >gone >> I'm curious as to how well this worked. > >It failed on a trivial point: by the Friday before the congress, I had >only >received four signups. A list with five keys is a poor list indeed. I >switched >the model to the classic "bring keyslips" model. > >> Is it an innovation worth >> perpetuating? > >I think it would work. I'd like to try again. > >In fact, given that we don't need to place trust in the paper copies, I >think it >would actually work if I kept sign-up open until just before the party, >and >printed a stack of "scrubbed" lists myself to hand out. However, it was >my >feeling that some people would not feel comfortable with this >brand-spanking-new >"no need to trust me, really! Have my stuff" type of lists, so I didn't >do that. >I intended to cater to the untrusting crowd by giving them enough time >to print >their own lists and do it the in the usual Sassaman Efficient way. > >Given that this would have, on the flip side, catered to the handful of >people >who showed up without keyslips, perhaps it would still be a fair >tradeoff for >limiting the untrusting people in their possibilities. > >You could receive sign-ups by e-mail until the latest moment, and you >would >print the untrusted lists so anybody who didn't bring any keyslips >could still >be on that list by signing up. > >Note that there is no value judgement in how I use "untrusting" here, >it's just >a way to sum up a group of people in a single adjective. > >Next opportunity for a keysigning party for me will be SHA 2017, >starting the >4th of August in Zeewolde, The Netherlands[1]. >O Come, All Ye Hackful! Adeste Fiddle-es[2]! > >Cheers, > >Peter. > >[1] >[2] Fiddle-es: those who tinker. > >-- >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 > -- Sent from my mobile device. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From 2014-667rhzu3dc-lists-groups at riseup.net Mon Feb 20 01:14:34 2017 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Mon, 20 Feb 2017 00:14:34 +0000 Subject: GPG, subkeys smartcard and computer In-Reply-To: <0a754032-373c-4619-705b-cc1b1427e8a5@incenp.org> References: <7B5864CB-9A8D-4407-892F-FE4AC547CD15@andrewg.com> <0e30accd-946b-a198-d1f7-eacb0964c2f2@digitalbrains.com> <0a754032-373c-4619-705b-cc1b1427e8a5@incenp.org> Message-ID: <1731725682.20170220001434@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Sunday 19 February 2017 at 2:58:56 PM, in , Damien Goutte-Gattat wrote:- > Disclaimer: I am not advocating such a setup, that I > don't even actually use. I use that setup. Last I heard, message recipients who use Enigmail/Thunderbird only see the verification result of one of the signatures. Which one they see depends on the order of the two local-user lines in my gpg.conf file, so if I have them in the "wrong" order an Enigmail/Thunderbird user whose GnuPG is not version 2.1.x will not see report of a valid signature. - -- Best regards MFPA The trouble with words is that you never know whose mouths they've been in. -----BEGIN PGP SIGNATURE----- iL4EARYKAGYFAliqNQRfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDMzQUNFRDRFRTkxMzRFRUJERTZBODUwNjE3 MTJCQzQ2MUFGNzc4RTQACgkQFxK8Rhr3eOQu3AEAhk6IddWOiFov15Ha5QhKe9C8 Xh3WMI8mt2H4h0hdp5IA/jGhW01UYCHDhVG4ddY2fwjjsIekcxOyE+rUcmTwueMK iQF8BAEBCgBmBQJYqjUEXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwbjYH/jUKUaX3GcfFcTpz3nsyuVqh VPwpd0WVu9Fd4s/Nbt8MOFn++mwR2J7wh3nv44QJgk5MJVFUkCpgIuavm+L8DxG1 aQ14c0bBNw+IcTLhTF8q5fvWzPsluHex6YoNpzQLXSU3bJgMogm8IT+HCQAc7ee3 pIwaFuxdW4H/p7E0OIDrJkQywcF7sXBSbr2aAtJZUWFUzeosfrxgVNE8q800elF3 8nPtlhNZJ8MGcbOohstocWEv1GCGwzT8RyEGmnGduYYG25hg33zz8mLn210E/nn0 AOZIjUd8hyxBfLZLRjufbZAHkG+/EQVQcBbk0TBmuZ80dpXFLRZ9TXA4O6OqPIA= =FW0d -----END PGP SIGNATURE----- From wk at gnupg.org Mon Feb 20 09:30:26 2017 From: wk at gnupg.org (Werner Koch) Date: Mon, 20 Feb 2017 09:30:26 +0100 Subject: powertop(8) Points at gpg-agent. In-Reply-To: <20170217135952.3402B212CE@orac.inputplus.co.uk> (Ralph Corderoy's message of "Fri, 17 Feb 2017 13:59:52 +0000") References: <20170217135952.3402B212CE@orac.inputplus.co.uk> Message-ID: <8760k5nu1p.fsf@wheatstone.g10code.de> On Fri, 17 Feb 2017 14:59, ralph at inputplus.co.uk said: > gnupg 2.1.18-1 on Arch Linux. I noticed powertop ranking the > gpg-agents, one per user, quite highly, and their impact is multiplied > by their number. strace(1) showed the two-second select(2) timing out > with no syscalls in between, and the forking of two siblings to have a > `GETINFO pid' chat every minute. What you see are not new processes but merely two threads every minute. One for doing the client part and one for the server part. Thus rewouse usage is minimal. --disable-check-own-socket can be used to disable this feature. > # define TIMERTICK_INTERVAL (2) I have not changed that interval because it is useful when you are using smartcards. What is does is to check the aliveness of scdaemon by doing a waitpid (pid, NULL, WNOHANG)). Not really resource intensive. Going down to 5 seconds would be okay but more will lead to problems with other applications which want to use a card reader. > Are there any plans to make gpg-agent consume less background resources? > It remains running here when a user logs out. Is that common? A > variety of users logging in over time divides TIMERTICK_INTERVAL quite a Note that gpg-agent makes sure that the tick happens on the full second so that gpg-agent will wakeup at the same time as other background processes wake up. I doubt that gpg-agent is in any way a resource hog even on a real multi-user system. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From stefano.tranquillini at gmail.com Mon Feb 20 09:56:11 2017 From: stefano.tranquillini at gmail.com (Stefano Tranquillini) Date: Mon, 20 Feb 2017 09:56:11 +0100 Subject: GPG, subkeys smartcard and computer In-Reply-To: <1731725682.20170220001434@riseup.net> References: <7B5864CB-9A8D-4407-892F-FE4AC547CD15@andrewg.com> <0e30accd-946b-a198-d1f7-eacb0964c2f2@digitalbrains.com> <0a754032-373c-4619-705b-cc1b1427e8a5@incenp.org> <1731725682.20170220001434@riseup.net> Message-ID: Hi, Things are getting clearer now, the fact is: subkeys are not related and basically only the last generated is used. I missunderstood this step. I need a Auth subkey on the smartcard becuase I've setup the server to access ssh only via a key. If I'm not at my pc I can't access the server, and this may be a problem. However, with a smartcard I may overcome the problem by using any pc. Probably is the same as having a ssh key stored on a usb and use it when I'm not on my laptop (and throw it away afterward, just in case). but this is outside the gpg list ;) On Mon, Feb 20, 2017 at 1:14 AM, MFPA <2014-667rhzu3dc-lists-groups@ riseup.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi > > > On Sunday 19 February 2017 at 2:58:56 PM, in > , Damien > Goutte-Gattat wrote:- > > > > Disclaimer: I am not advocating such a setup, that I > > don't even actually use. > > I use that setup. Last I heard, message recipients who use > Enigmail/Thunderbird only see the verification result of one of the > signatures. Which one they see depends on the order of the two > local-user lines in my gpg.conf file, so if I have them in the "wrong" > order an Enigmail/Thunderbird user whose GnuPG is not version 2.1.x > will not see report of a valid signature. > > > - -- > Best regards > > MFPA > > The trouble with words is that you never know whose mouths they've been in. > -----BEGIN PGP SIGNATURE----- > > iL4EARYKAGYFAliqNQRfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl > bnBncC5maWZ0aGhvcnNlbWFuLm5ldDMzQUNFRDRFRTkxMzRFRUJERTZBODUwNjE3 > MTJCQzQ2MUFGNzc4RTQACgkQFxK8Rhr3eOQu3AEAhk6IddWOiFov15Ha5QhKe9C8 > Xh3WMI8mt2H4h0hdp5IA/jGhW01UYCHDhVG4ddY2fwjjsIekcxOyE+rUcmTwueMK > iQF8BAEBCgBmBQJYqjUEXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w > ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 > QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwbjYH/jUKUaX3GcfFcTpz3nsyuVqh > VPwpd0WVu9Fd4s/Nbt8MOFn++mwR2J7wh3nv44QJgk5MJVFUkCpgIuavm+L8DxG1 > aQ14c0bBNw+IcTLhTF8q5fvWzPsluHex6YoNpzQLXSU3bJgMogm8IT+HCQAc7ee3 > pIwaFuxdW4H/p7E0OIDrJkQywcF7sXBSbr2aAtJZUWFUzeosfrxgVNE8q800elF3 > 8nPtlhNZJ8MGcbOohstocWEv1GCGwzT8RyEGmnGduYYG25hg33zz8mLn210E/nn0 > AOZIjUd8hyxBfLZLRjufbZAHkG+/EQVQcBbk0TBmuZ80dpXFLRZ9TXA4O6OqPIA= > =FW0d > -----END PGP SIGNATURE----- > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- Stefano -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralph at inputplus.co.uk Mon Feb 20 14:32:06 2017 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Mon, 20 Feb 2017 13:32:06 +0000 Subject: powertop(8) Points at gpg-agent. In-Reply-To: <8760k5nu1p.fsf@wheatstone.g10code.de> References: <20170217135952.3402B212CE@orac.inputplus.co.uk> <8760k5nu1p.fsf@wheatstone.g10code.de> Message-ID: <20170220133206.0A8D92141D@orac.inputplus.co.uk> Hi Werner, > > the forking of two siblings to have a `GETINFO pid' chat every > > minute. > > What you see are not new processes but merely two threads every > minute. Yes, sorry, I saw the clone(2) and translated to fork. > --disable-check-own-socket can be used to disable this feature. Thanks. In Arch's 2.1.18-1's agent/gpg-agent.c's handle_connections(), I see if (disable_check_own_socket) my_inotify_fd = -1; else if ((err = gnupg_inotify_watch_socket (&my_inotify_fd, socket_name))) and my_inotify_fd is used with select(2). Does the per minute sibling thread chat still need to occur in that case? > > # define TIMERTICK_INTERVAL (2) > > I have not changed that interval because it is useful when you are > using smartcards. What is does is to check the aliveness of scdaemon > by doing a waitpid (pid, NULL, WNOHANG)). I don't see a system call with strace for that waitpid though? $ strace -tt -f gpg-agent --daemon ... 13:29:23.845564 inotify_init() = 7 13:29:23.845704 inotify_add_watch(7, "/run/user/1000/gnupg", IN_DELETE|IN_DELETE_SELF|IN_EXCL_UNLINK) = 1 13:29:23.845955 pselect6(8, [3 4 5 6 7], NULL, NULL, {tv_sec=1, tv_nsec=999998782}, {[], 8}) = 0 (Timeout) 13:29:25.848353 pselect6(8, [3 4 5 6 7], NULL, NULL, {tv_sec=2, tv_nsec=30747}, {[], 8}) = 0 (Timeout) 13:29:27.850760 pselect6(8, [3 4 5 6 7], NULL, NULL, {tv_sec=2, tv_nsec=1343}, {[], 8}) = 0 (Timeout) 13:29:29.853172 pselect6(8, [3 4 5 6 7], NULL, NULL, {tv_sec=2, tv_nsec=1218}, {[], 8}) = 0 (Timeout) 13:29:31.855622 pselect6(8, [3 4 5 6 7], NULL, NULL, {tv_sec=2, tv_nsec=1263}, {[], 8}) = 0 (Timeout) 13:29:33.858052 pselect6(8, [3 4 5 6 7], NULL, NULL, {tv_sec=2, tv_nsec=1409}, {[], 8}) = 0 (Timeout) Does --disable-scdaemon mean the check isn't needed and select(2) can stretch to the next longer timeout? Either way, if the waitpid(WNOHANG) really is happening and strace isn't showing it, then could a thread not be dedicated to a hanging waitpid(), with it sending a message on a file descriptor back to the main thread's select()? > Not really resource intensive. No, I agree the work done isn't heavy; it's the regular periodic short-term wake-up that's a bit of a pain. > Note that gpg-agent makes sure that the tick happens on the full > second Noted. Though those `-tt' times from strace above have it creeping forward, off the second? -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy From kristian.fiskerstrand at sumptuouscapital.com Mon Feb 20 16:25:46 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Mon, 20 Feb 2017 16:25:46 +0100 Subject: GPG, subkeys smartcard and computer In-Reply-To: <7B5864CB-9A8D-4407-892F-FE4AC547CD15@andrewg.com> References: <7B5864CB-9A8D-4407-892F-FE4AC547CD15@andrewg.com> Message-ID: On 02/19/2017 01:45 PM, Andrew Gallagher wrote: > And in the case of A and S, there next to no benefit - if one of your > subkeys is lost you should revoke it immediately anyway Wouldn't consider this accurate, the typical use case for multiple A subkeys is per-device usage, explicitly to avoid having to revoke all if one is compromised. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Qui audet vincit Who dares wins -------------- 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 Mon Feb 20 17:49:55 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 20 Feb 2017 17:49:55 +0100 Subject: GPG, subkeys smartcard and computer In-Reply-To: References: <7B5864CB-9A8D-4407-892F-FE4AC547CD15@andrewg.com> Message-ID: On 20/02/17 16:25, Kristian Fiskerstrand wrote: > Wouldn't consider this accurate, the typical use case for multiple A > subkeys is per-device usage, explicitly to avoid having to revoke all if > one is compromised. Well, if you use only one, "revoke all" is still "revoke one" ;). It's not the revocation step that gets any bigger, it's just that you need to roll out the new key to all your client systems instead of just the server systems. Personally, the number of server systems I use is way larger than the number of client systems. Over all, I don't think it's that much more work, given it's a rare occurence anyway (I hope). With A per system: 1) Create new key on compromised system 2) Roll out new key to all server systems 3) Revoke old key on all server systems With just one A: 1) Create new key 2) Roll out new key to all client systems 3) Roll out new key to all server systems 4) Revoke old key on all server systems Steps 3 and 4 are more work than step 2. I have login credentials for at least 11 systems off the top of my head, yet only 3 client devices I regularly use [1]. When all your server systems automatically pick up on OpenPGP auth subkeys from a keyserver, or when you use OpenSSH's CA mechanism, steps 3) and 4) are pretty much automatic, in which case indeed step 2) would dominate and one key per device once again wins. So perhaps one key per device is superior, also for detecting which client system was compromised by looking at the SSH auth logs on the server (supposing the attacker didn't gain root privileges and wiped his traces immediately). But I think it's not a very significant difference, or did I miss a scenario? My 2 cents, Peter. [1] However, I have four different auth keys on those clients, three on-disk, one per system and one smartcard I only use on a single one of those systems. I actually use one key per client, but note that I don't have multiple A-capable OpenPGP subkeys. All my on-disk keys are just regular ol' OpenSSH keys, and I think then one key per device is a much cleaner setup indeed. -- 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 Mon Feb 20 17:58:01 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 20 Feb 2017 17:58:01 +0100 Subject: Hybrid keysigning party, your opinion? In-Reply-To: <4be0f.02234dc6be.9633E9D0-9736-4200-97FF-9ABEE5256254@familievogels.nl> References: <46a4ec4d-d5da-432f-7210-40141aaf15fc@twopif.net> <4be0f.02234dc6be.9633E9D0-9736-4200-97FF-9ABEE5256254@familievogels.nl> Message-ID: <8f6baa7b-c1f5-3a00-ed30-e5e7f332817b@digitalbrains.com> On 19/02/17 21:16, Nils Vogels wrote: > I'll read up on this thread from the archives, but I'm exploring possibilities > to enhance the FOSDEM format with the use of QR for on-the-spot signing for > those who want to and don't mind having signatures submitted by signers to > keyservers. Thank you for organizing a party! I'm definitely up for assisting with the organization. I'd first have to look up on the FOSDEM format. The QR codes are indeed a nice addition, however, it is inherently restricted to just a part of the attendees. I don't trust my phone with my certifications, and holding a laptop with webcam is really awkward and I might even drop it. Normally I'd leave my certification-capable smartcard at home as well. 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 sheldon.corey at openmailbox.org Mon Feb 20 16:40:01 2017 From: sheldon.corey at openmailbox.org (Personal (open)) Date: Mon, 20 Feb 2017 15:40:01 +0000 Subject: GPG, subkeys smartcard and computer In-Reply-To: References: <7B5864CB-9A8D-4407-892F-FE4AC547CD15@andrewg.com> Message-ID: <55ae036cc3b9db45259764afd7ca4759@openmailbox.org> On 20.02.2017 15:25, Kristian Fiskerstrand wrote: > On 02/19/2017 01:45 PM, Andrew Gallagher wrote: > >> And in the case of A and S, there next to no benefit - if one of your subkeys is lost you should revoke it immediately anyway > > Wouldn't consider this accurate, the typical use case for multiple A > subkeys is per-device usage, explicitly to avoid having to revoke all if > one is compromised. > > -- > ---------------------------- > Kristian Fiskerstrand > Blog: https://blog.sumptuouscapital.com [1] > Twitter: @krifisk > ---------------------------- > Public OpenPGP keyblock at hkp://pool.sks-keyservers.net > fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 > ---------------------------- > Qui audet vincit > Who dares wins > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users [2] Another use-case would be using rsa and ecc ( ecc on the laptop/desktop and rsa subs on the smartcard) sent via webmail, pardon lack of a gpg signature. -- Corey W Sheldon ph: +1 (310).909.7672 0x8B4E89435A88E539 0x59276298D2264944 Freelance IT Consultant, Multi-Discipline Tutor Fedora AmbaNA (linuxmodder) Ameridea LLC Founder, President Find me elsewhere: https://gist.github.com/linux-modder/ac5dc6fa211315c633c9 "One must never underestimate the power of boredom...from which creativity and laziness are borne, which can spark great works of chaos and genius." --Anonymous "Any man willing to retreat freedom for security is deserving of neither." (Pp) -- Benjamin Franklin. This document, including attachments, is intended for the person or company named and contains confidential and/or legally privileged information. Unauthorized disclosure, copying or use of this information may be unlawful and is prohibited. If you are not the intended recipient, please destroy this message and notify the sender. Links: ------ [1] https://blog.sumptuouscapital.com [2] http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From deg at davidegray.com Mon Feb 20 14:51:06 2017 From: deg at davidegray.com (David Gray) Date: Mon, 20 Feb 2017 08:51:06 -0500 Subject: Problems with cert validation via CRL Message-ID: <000001d28b80$62b3a1e0$281ae5a0$@davidegray.com> Hello - new user here; this may be an obvious question but I haven't been able to find the answer. Ultimately, this may just highlight some of the problems inherent in a hierarchical trust model. I've got a free x.509 email certificate generated by Comodo. I've got Ubuntu 16.04 LTS running a clean install, with gpg and gpgsm 2.1.11 installed. I imported my certificate into my keychain using gpgsm a day or two ago, and everything is working as expected - the certificate is successfully validated, and I'm able to encrypt files using the public key of this certificate, and decrypt them using the private key. I've also got a Windows 10 machine - this computer had GPG4Win installed for some time, but I've since uninstalled that, and removed all configuration directories/files I could find. I've installed GnuPG binary version 2.1.11, and I've been able to successfully import my certificate into my keychain this morning, and everything seems to work as expected - but the certificate is not successfully validated under Windows. As a result, I'm not able to encrypt anything using the public key of this certificate. I'm trying to figure out what is going on - it appears that there is problem validating the CRL available at the DP listed in my certificate regardless of whether I run the fetch-url from Ubuntu or Windows - both output files are attached. Does this suggest a problem with the CRL that the CA has published, or do I have something I need to adjust in my configs somewhere? At the same time, I'm curious as to why the Ubuntu installation is validating the certificate as 'good' while the Windows installation is not - is this just because the Ubuntu installation was able to successfully validate the certificate in the past (presumably when a previous and non-problematic CRL was published)? If the CA publishes an updated CRL that doesn't have issues, will my Windows installation be able to validate the certificate at that point? I've replaced all the email addresses in the attached files with 'user at domain.com'. I appreciate any assistance you might be able to provide. Thank you, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ubuntu-dimngr-fetchcrl-debugall.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ubuntu-listkeys-with-validation-debugall.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: windows-dirmngr-fetchcrl-debugall.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: windows-listkeys-withvalidation-debugall.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4803 bytes Desc: not available URL: From kristian.fiskerstrand at sumptuouscapital.com Mon Feb 20 22:51:08 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Mon, 20 Feb 2017 22:51:08 +0100 Subject: GPG, subkeys smartcard and computer In-Reply-To: References: <7B5864CB-9A8D-4407-892F-FE4AC547CD15@andrewg.com> Message-ID: <33f26254-359c-3b83-5b37-cd78f0c4bdc5@sumptuouscapital.com> On 02/20/2017 05:49 PM, Peter Lebbing wrote: > So perhaps one key per device is superior, also for detecting which client > system was compromised by looking at the SSH auth logs on the server (supposing > the attacker didn't gain root privileges and wiped his traces immediately). But > I think it's not a very significant difference, or did I miss a scenario? Revocation of the specific subkey is automatically picked up by all systems due to automatic refresh of the public key on regular intervals, without losing access to the system from non-compromised devices. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Qui audet vincit Who dares wins -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Tue Feb 21 03:32:46 2017 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 21 Feb 2017 11:32:46 +0900 Subject: Problems with cert validation via CRL In-Reply-To: <000001d28b80$62b3a1e0$281ae5a0$@davidegray.com> References: <000001d28b80$62b3a1e0$281ae5a0$@davidegray.com> Message-ID: <87lgt0p92p.fsf@iwagami.gniibe.org> Hello, David Gray wrote: > At the same time, I'm curious as to why the Ubuntu installation is > validating the certificate as 'good' while the Windows installation is not - > is this just because the Ubuntu installation was able to successfully > validate the certificate in the past (presumably when a previous and > non-problematic CRL was published)? If the CA publishes an updated CRL that > doesn't have issues, will my Windows installation be able to validate the > certificate at that point? Please note that my knowledge of gpgsm and X.509 is pretty much limited. Do you have .gnupg/trustlist.txt on Ubuntu machine? It can be created when you answer dialog of gpgsm by pinentry interaction. -- From ralph at inputplus.co.uk Tue Feb 21 10:56:17 2017 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Tue, 21 Feb 2017 09:56:17 +0000 Subject: powertop(8) Points at gpg-agent. In-Reply-To: <20170220133206.0A8D92141D@orac.inputplus.co.uk> References: <20170217135952.3402B212CE@orac.inputplus.co.uk> <8760k5nu1p.fsf@wheatstone.g10code.de> <20170220133206.0A8D92141D@orac.inputplus.co.uk> Message-ID: <20170221095617.3E1281FE93@orac.inputplus.co.uk> Hi, I wrote: > > Note that gpg-agent makes sure that the tick happens on the full > > second > > Noted. Though those `-tt' times from strace above have it creeping > forward, off the second? I wonder if aiming for dead on the second is a good idea. If everything did that then there might silence until the next second boundary, but many cores would wake up to work for a short time. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy From peter at digitalbrains.com Tue Feb 21 14:21:25 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 21 Feb 2017 14:21:25 +0100 Subject: GPG, subkeys smartcard and computer In-Reply-To: <33f26254-359c-3b83-5b37-cd78f0c4bdc5@sumptuouscapital.com> References: <7B5864CB-9A8D-4407-892F-FE4AC547CD15@andrewg.com> <33f26254-359c-3b83-5b37-cd78f0c4bdc5@sumptuouscapital.com> Message-ID: <0dea4338-a41a-ed75-f228-1d529e1c29ce@digitalbrains.com> On 20/02/17 22:51, Kristian Fiskerstrand wrote: > Revocation of the specific subkey is automatically picked up by all > systems due to automatic refresh of the public key on regular intervals, > without losing access to the system from non-compromised devices. Revoking the old A key and creating a new one needs to happen on the system you have the primary key on, so you need to subsequently roll out the new A key to the compromised device. Obviously I assume the primary key was not available on the compromised device, because then the whole certificate would have to be revoked. I don't see much extra effort in rolling it out to the few other systems you use as a client as well. Also, I think you need to have a way to notify servers that they need to get an updated certificate including the revoked old key *right* *now*. We're talking about a compromised A key! The attacker has full access to your login account for the time that the servers haven't checked for a new key yet! Regular intervals just won't do. This looks to be the painful step in the process. The exception might be a private keyserver that gets hammered by all the SSH servers every 10 minutes to check whether any updated keys were uploaded. I don't think it'd be kind to do that to a public keyserver. I'm not saying an A key per device is bad. Or even that it is not as good as one A key. I'm just saying that, given you need to transfer private keys anyway I don't think there's a significant difference in practice. You can't generate these new A subkeys on the client device itself, because it will not have the primary key of the OpenPGP certificate. This is where the difference with plain old OpenSSH private keys pops up: those you just generate on the client device itself and you never have to worry about exporting and importing private keys at all. In addition, it means you can then say "I'd never login to this server from this client, so it needs not be in the authorized_keys file". This kind of discrimination that provides defence in depth is not possible with A subkeys on an OpenPGP certificate that get automatically picked up by the servers, since they will always accept all A subkeys on the certificate. So you lose that etra possibility you had with plain SSH keys per client device. Cheers, Peter. PS: I realised that you can't even generate the A key on the previously compromised system only after I'd written my previous mail. So the two stepwise processes should have been: With A per system: 1) Create new key 2) Roll out new key to compromised system 3) Roll out new key to all server systems 4) Revoke old key on all server systems With just one A: 1) Create new key 2) Roll out new key to all client systems 3) Roll out new key to all server systems 4) Revoke old key on all server systems However, since Kristian is placing it in the context of servers automatically fetching keys, it could be: With A per system: 1) Create new key, revoke old 2) Roll out new key to compromised system 3) Poke every server system that they need to refresh *now* With just one A: 1) Create new key, revoke old 2) Roll out new key to all client systems 3) Poke every server system that they need to refresh *now* -- 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 kristian.fiskerstrand at sumptuouscapital.com Tue Feb 21 14:37:57 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 21 Feb 2017 14:37:57 +0100 Subject: GPG, subkeys smartcard and computer In-Reply-To: <0dea4338-a41a-ed75-f228-1d529e1c29ce@digitalbrains.com> References: <7B5864CB-9A8D-4407-892F-FE4AC547CD15@andrewg.com> <33f26254-359c-3b83-5b37-cd78f0c4bdc5@sumptuouscapital.com> <0dea4338-a41a-ed75-f228-1d529e1c29ce@digitalbrains.com> Message-ID: <586eaf38-c1b1-7553-96c6-72f38b6863a9@sumptuouscapital.com> On 02/21/2017 02:21 PM, Peter Lebbing wrote: > Revoking the old A key and creating a new one needs to happen on the > system you have the primary key on, so you need to subsequently roll out Who said anything about creating a new one in this part of the process? each device has separate A subkeys already, you lost your device, you revoke the A subkey for it (this step is actually the most tricky, as revocation certificates can't be generated for subkeys - so you need to have pre-generated versions of pubkey with it revoked created carefully manually beforehand). > the new A key to the compromised device. Obviously I assume the primary > key was not available on the compromised device, because then the whole obviously > certificate would have to be revoked. I don't see much extra effort in > rolling it out to the few other systems you use as a client as well. not following, you don't have access to the primary key at this point (say you're travelling and the primary is on smartcard in a vault) > > Also, I think you need to have a way to notify servers that they need to > get an updated certificate including the revoked old key *right* *now*. > We're talking about a compromised A key! The attacker has full access to > your login account for the time that the servers haven't checked for a Whether need for "right now" depends on severity, the compromise is in most cases a lost device, not an active attacker, so a 20-30 min timeframe is likely sufficient in most cases anyways e.g from a regular crontab run of monkeysphere, this also should fit with most key propagation across network as using a single keyserver can create a SPOF and DoS the update > new key yet! Regular intervals just won't do. This looks to be the > painful step in the process. ... it depends... -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Qui audet vincit Who dares wins -------------- 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 Feb 21 15:15:09 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 21 Feb 2017 15:15:09 +0100 Subject: GPG, subkeys smartcard and computer In-Reply-To: <586eaf38-c1b1-7553-96c6-72f38b6863a9@sumptuouscapital.com> References: <7B5864CB-9A8D-4407-892F-FE4AC547CD15@andrewg.com> <33f26254-359c-3b83-5b37-cd78f0c4bdc5@sumptuouscapital.com> <0dea4338-a41a-ed75-f228-1d529e1c29ce@digitalbrains.com> <586eaf38-c1b1-7553-96c6-72f38b6863a9@sumptuouscapital.com> Message-ID: <18ef6f5e-90a5-8fd4-56f4-3344313c17ab@digitalbrains.com> On 21/02/17 14:37, Kristian Fiskerstrand wrote: > Who said anything about creating a new one in this part of the process? Since I assumed you were siting behind a trusted machine with your primary key installed when you revoke, it made no sense to me to just revoke the key and not create a new one, as you are sitting there in "gpg --edit-key" with your primary unlocked anyway. But the rest of the mail makes clear this was not your assumption. > (this step is actually the most tricky, as > revocation certificates can't be generated for subkeys - so you need to > have pre-generated versions of pubkey with it revoked created carefully > manually beforehand). Yes, I had kinda assumed that this was not the level of trickery we were willing to go to when suggesting people to use multiple A subkeys. It's not even a feature of GnuPG, it's just being clever. >> certificate would have to be revoked. I don't see much extra effort in >> rolling it out to the few other systems you use as a client as well. > > not following, you don't have access to the primary key at this point > (say you're travelling and the primary is on smartcard in a vault) I did assume that you need the primary to do the revocations, as GnuPG does not support revocation certificates for subkeys. So I assumed you could only mitigate the compromise when seated behind your most trusted system, or something to that effect. > Whether need for "right now" depends on severity, the compromise is in > most cases a lost device I suppose we were working with different definitions of "compromise". Yours makes more sense. Mine was too narrow. > so a 20-30 min > timeframe is likely sufficient in most cases anyways e.g from a regular > crontab run of monkeysphere, this also should fit with most key > propagation across network as using a single keyserver can create a SPOF > and DoS the update If Kristian Fiskerstrand says it's okay for SSH servers to refresh their keyring every 20 or 30 minutes from the public keyserver netowrk, then I guess it really is :-). I had estimated it as inappropriate. Okay, you have convinced me. To deal with the pyhsical loss of a device or the medium holding the private key, it makes sense to create an OpenPGP auth-capable subkey per device. However, the revocation trickery limits its user-friendliness in a big way. Thanks for expanding my understanding of this area. It's still not for me though. I often need to be able to grant access on a per-client basis. I try to limit access to accounts to client devices where I actually need it, to somewhat limit the consequences of a single client machine being compromised. It's not a panacea, more of a defense in depth thing. 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 deg at davidegray.com Tue Feb 21 13:20:29 2017 From: deg at davidegray.com (David Gray) Date: Tue, 21 Feb 2017 07:20:29 -0500 Subject: Problems with cert validation via CRL In-Reply-To: <87lgt0p92p.fsf@iwagami.gniibe.org> References: <000001d28b80$62b3a1e0$281ae5a0$@davidegray.com> <87lgt0p92p.fsf@iwagami.gniibe.org> Message-ID: <87CF4606-FE26-4376-8799-7674F956D602@davidegray.com> Thank you for your response! I do have the trustlist.txt file on both computers - it was automatically populated with the root cert by pin entry when I imported my certificate on both machines, and it includes the "relax" keyword on both computers. There are 3 cents total in my hierarchy - root, intermediate, and mine. I've added the fingerprint of the intermediate and even my own cert to trustlist.txt to see if that would make a difference, but it didn't change anything. The --disable-crl-checks option allows me to use the cert for encryption, so I'm pretty sure the problem lies with the crl option...there are two files (in addition to DIR.TXT) that have been populated in crl.d, and if I do a dirmngr--flush they get cleared out and are added back fine the next time I try to validate. The root cert does NOT include a CRL DP, so I've tried turning on the option not to require a crl on trusted carts, but that didn't make a difference. I'm no expert, but when I look at the debug info (attached to original email), it appears that gpgsm is able to get the crl that my cert points to but it may be having trouble parsing it. The file itself is large, but I don't think that's uncommon, so perhaps there is a problem with the file itself. It's been updated since I started investigating, and the problem persists, so it wasn't a transient problem. Is there a way to have gpgsm (or dirmngr?) validate that it is able to parse and interpret the CRL (or the associated .db file in crl.d) to see if that is the issue? I appreciate your help very much. Thanks, Dave Sent from my Mobile Device > On Feb 20, 2017, at 9:32 PM, NIIBE Yutaka wrote: > > Hello, > > David Gray wrote: >> At the same time, I'm curious as to why the Ubuntu installation is >> validating the certificate as 'good' while the Windows installation is not - >> is this just because the Ubuntu installation was able to successfully >> validate the certificate in the past (presumably when a previous and >> non-problematic CRL was published)? If the CA publishes an updated CRL that >> doesn't have issues, will my Windows installation be able to validate the >> certificate at that point? > > Please note that my knowledge of gpgsm and X.509 is pretty much limited. > > Do you have .gnupg/trustlist.txt on Ubuntu machine? It can be created > when you answer dialog of gpgsm by pinentry interaction. > -- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2368 bytes Desc: not available URL: From andrewg at andrewg.com Tue Feb 21 15:38:39 2017 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 21 Feb 2017 14:38:39 +0000 Subject: GPG, subkeys smartcard and computer In-Reply-To: <586eaf38-c1b1-7553-96c6-72f38b6863a9@sumptuouscapital.com> References: <7B5864CB-9A8D-4407-892F-FE4AC547CD15@andrewg.com> <33f26254-359c-3b83-5b37-cd78f0c4bdc5@sumptuouscapital.com> <0dea4338-a41a-ed75-f228-1d529e1c29ce@digitalbrains.com> <586eaf38-c1b1-7553-96c6-72f38b6863a9@sumptuouscapital.com> Message-ID: <52904B95-4E1D-417E-B38C-99D9970323A7@andrewg.com> On 21 Feb 2017, at 13:37, Kristian Fiskerstrand wrote: >> On 02/21/2017 02:21 PM, Peter Lebbing wrote: >> Revoking the old A key and creating a new one needs to happen on the >> system you have the primary key on, so you need to subsequently roll out > > Who said anything about creating a new one in this part of the process? I did. In my original scenario, since you have to load up your primary key in order to revoke the compromised subkey, there's little extra effort involved in creating a new subkey while you're at it. (Yes, you could have prepared offline subkey revocations, but as you say this is very poorly supported and I wouldn't recommend it to anyone) I'm not convinced having different A subkeys for each client device is useful. If one of your A subkeys gets compromised, all your servers are vulnerable until such point as your revocation gets pushed, and after which point any new subkeys will also have been pushed. So rolling A subkeys is an atomic operation on the server no matter what way you go about it or whether you have subkeys created in advance. On the other hand, if you have separate A subkeys for each *server*, then why not make life easy for yourself and just use separate primaries? Distributing revocations is the Achilles heel of every PKI. I don't know of any that has definitively solved it. A From kristian.fiskerstrand at sumptuouscapital.com Tue Feb 21 15:58:55 2017 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 21 Feb 2017 15:58:55 +0100 Subject: GPG, subkeys smartcard and computer In-Reply-To: <18ef6f5e-90a5-8fd4-56f4-3344313c17ab@digitalbrains.com> References: <7B5864CB-9A8D-4407-892F-FE4AC547CD15@andrewg.com> <33f26254-359c-3b83-5b37-cd78f0c4bdc5@sumptuouscapital.com> <0dea4338-a41a-ed75-f228-1d529e1c29ce@digitalbrains.com> <586eaf38-c1b1-7553-96c6-72f38b6863a9@sumptuouscapital.com> <18ef6f5e-90a5-8fd4-56f4-3344313c17ab@digitalbrains.com> Message-ID: On 02/21/2017 03:15 PM, Peter Lebbing wrote: > If Kristian Fiskerstrand says it's okay for SSH servers to refresh their > keyring every 20 or 30 minutes from the public keyserver netowrk, then I > guess it really is :-). I had estimated it as inappropriate. Keep in mind, the keyring in the scope of monkeysphere is normally one keyblock :) But yeah, the crontab frequency will depend a bit on system. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Qui audet vincit Who dares wins -------------- 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 Feb 21 16:13:18 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 21 Feb 2017 16:13:18 +0100 Subject: Problems with cert validation via CRL In-Reply-To: <87CF4606-FE26-4376-8799-7674F956D602@davidegray.com> References: <000001d28b80$62b3a1e0$281ae5a0$@davidegray.com> <87lgt0p92p.fsf@iwagami.gniibe.org> <87CF4606-FE26-4376-8799-7674F956D602@davidegray.com> Message-ID: <1c850be7-426c-599e-90dc-0932a178ea1c@digitalbrains.com> On 21/02/17 13:20, David Gray wrote: > I'm no expert, but when I look at the debug info (attached to > original email), it appears that gpgsm is able to get the crl that my > cert points to but it may be having trouble parsing it. Reading that part made me think it couldn't find the issuer of the CRL: > dirmngr[3184.0]: error fetching certificate by subject: Configuration error > dirmngr[3184.0]: CRL issuer certificate {92616B82E1A2A0AA4FEC67F1C2A3F7B48000C1EC} not found When I fetch the CRL we're talking about, OpenSSL tells me about it: > Certificate Revocation List (CRL): > Version 2 (0x1) > Signature Algorithm: sha256WithRSAEncryption > Issuer: /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO SHA-256 Client Authentication and Secure Email CA > Last Update: Feb 20 16:07:34 2017 GMT > Next Update: Feb 24 16:07:34 2017 GMT > CRL extensions: > X509v3 Authority Key Identifier: > keyid:92:61:6B:82:E1:A2:A0:AA:4F:EC:67:F1:C2:A3:F7:B4:80:00:C1:EC > > X509v3 CRL Number: > 822 The issuer is the certificate that gpgsm knows about: > Certificate: > Data: > Version: 3 (0x2) > Serial Number: > e0:23:cb:15:12:83:53:89:ad:61:6e:7a:54:67:6b:21 > Signature Algorithm: sha256WithRSAEncryption > Issuer: C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, CN=AddTrust External CA Root > Validity > Not Before: Dec 22 00:00:00 2014 GMT > Not After : May 30 10:48:38 2020 GMT > Subject: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO SHA-256 Client Authentication and Secure Email CA > [...] > X509v3 extensions: > X509v3 Authority Key Identifier: > keyid:AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A > > X509v3 Subject Key Identifier: > 92:61:6B:82:E1:A2:A0:AA:4F:EC:67:F1:C2:A3:F7:B4:80:00:C1:EC > [...] > SHA1 Fingerprint=59:B8:25:FC:08:86:0B:04:B3:92:CC:25:FE:C4:8C:76:07:53:B6:89 I suspect that even though gpgsm knows about it, dirmngr might not, hence the failing CRL verification. I think you need to feed the certificate to dirmngr as well. Whether this is actually the reason you're having problems, I don't know. 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 peter at digitalbrains.com Tue Feb 21 16:17:10 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 21 Feb 2017 16:17:10 +0100 Subject: GPG, subkeys smartcard and computer In-Reply-To: References: <7B5864CB-9A8D-4407-892F-FE4AC547CD15@andrewg.com> <33f26254-359c-3b83-5b37-cd78f0c4bdc5@sumptuouscapital.com> <0dea4338-a41a-ed75-f228-1d529e1c29ce@digitalbrains.com> <586eaf38-c1b1-7553-96c6-72f38b6863a9@sumptuouscapital.com> <18ef6f5e-90a5-8fd4-56f4-3344313c17ab@digitalbrains.com> Message-ID: <2bf4fdad-e6f6-60b5-c93a-585192056441@digitalbrains.com> On 21/02/17 15:58, Kristian Fiskerstrand wrote: > Keep in mind, the keyring in the scope of monkeysphere is normally one > keyblock :) But yeah, the crontab frequency will depend a bit on system. Not for multi-user systems with many accounts; it would only be the case for personal servers. Is a personal server really "normally" the place monkeysphere is deployed? 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 andrewg at andrewg.com Tue Feb 21 16:19:34 2017 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 21 Feb 2017 15:19:34 +0000 Subject: GPG, subkeys smartcard and computer In-Reply-To: <2bf4fdad-e6f6-60b5-c93a-585192056441@digitalbrains.com> References: <7B5864CB-9A8D-4407-892F-FE4AC547CD15@andrewg.com> <33f26254-359c-3b83-5b37-cd78f0c4bdc5@sumptuouscapital.com> <0dea4338-a41a-ed75-f228-1d529e1c29ce@digitalbrains.com> <586eaf38-c1b1-7553-96c6-72f38b6863a9@sumptuouscapital.com> <18ef6f5e-90a5-8fd4-56f4-3344313c17ab@digitalbrains.com> <2bf4fdad-e6f6-60b5-c93a-585192056441@digitalbrains.com> Message-ID: On 21/02/17 15:17, Peter Lebbing wrote: > On 21/02/17 15:58, Kristian Fiskerstrand wrote: >> Keep in mind, the keyring in the scope of monkeysphere is normally one >> keyblock :) But yeah, the crontab frequency will depend a bit on system. > > Not for multi-user systems with many accounts; it would only be the case > for personal servers. Is a personal server really "normally" the place > monkeysphere is deployed? And this is the main reason I started running my own keyserver - by refreshing your monkeysphere-host keyring, you are leaking to the keyserver which user credentials have login access to your system. :-) Andrew. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Tue Feb 21 16:23:27 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 21 Feb 2017 16:23:27 +0100 Subject: GPG, subkeys smartcard and computer In-Reply-To: References: <7B5864CB-9A8D-4407-892F-FE4AC547CD15@andrewg.com> <33f26254-359c-3b83-5b37-cd78f0c4bdc5@sumptuouscapital.com> <0dea4338-a41a-ed75-f228-1d529e1c29ce@digitalbrains.com> <586eaf38-c1b1-7553-96c6-72f38b6863a9@sumptuouscapital.com> <18ef6f5e-90a5-8fd4-56f4-3344313c17ab@digitalbrains.com> <2bf4fdad-e6f6-60b5-c93a-585192056441@digitalbrains.com> Message-ID: <9be60738-703e-6822-dc68-ef3dff20ce6a@digitalbrains.com> On 21/02/17 16:19, Andrew Gallagher wrote: > And this is the main reason I started running my own keyserver - by > refreshing your monkeysphere-host keyring, you are leaking to the > keyserver which user credentials have login access to your system. :-) But if an attacker can cut off your SSH servers from the keyserver, and your SSH servers fail open, meaning that they conclude the old data is still valid when it can't get new data, an attacker can keep using a compromised and revoked subkey without the server noticing the revocation in time. It all depends on your threat model. My 2 cents, Peter. PS: Actually, on reflection, not /my/ 2 cents. I'm just repeating what Kristian said earlier with some more words attached. -- 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 andrewg at andrewg.com Tue Feb 21 16:31:50 2017 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 21 Feb 2017 15:31:50 +0000 Subject: GPG, subkeys smartcard and computer In-Reply-To: <9be60738-703e-6822-dc68-ef3dff20ce6a@digitalbrains.com> References: <7B5864CB-9A8D-4407-892F-FE4AC547CD15@andrewg.com> <33f26254-359c-3b83-5b37-cd78f0c4bdc5@sumptuouscapital.com> <0dea4338-a41a-ed75-f228-1d529e1c29ce@digitalbrains.com> <586eaf38-c1b1-7553-96c6-72f38b6863a9@sumptuouscapital.com> <18ef6f5e-90a5-8fd4-56f4-3344313c17ab@digitalbrains.com> <2bf4fdad-e6f6-60b5-c93a-585192056441@digitalbrains.com> <9be60738-703e-6822-dc68-ef3dff20ce6a@digitalbrains.com> Message-ID: On 21/02/17 15:23, Peter Lebbing wrote: > On 21/02/17 16:19, Andrew Gallagher wrote: >> And this is the main reason I started running my own keyserver - by >> refreshing your monkeysphere-host keyring, you are leaking to the >> keyserver which user credentials have login access to your system. :-) > > But if an attacker can cut off your SSH servers from the keyserver, and > your SSH servers fail open, meaning that they conclude the old data is > still valid when it can't get new data, an attacker can keep using a > compromised and revoked subkey without the server noticing the > revocation in time. Using your own keyserver(s) also helps with this, because you're not relying on external internet connectivity to get your revocations. Now, if your keyserver loses gossip with the pool you still may not get revocations, but only if your users push them to the pool and not to your keyserver, which is a question of defaults. > It all depends on your threat model. Absolutely! :-) A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From gerd.von.egidy at intra2net.com Tue Feb 21 15:34:17 2017 From: gerd.von.egidy at intra2net.com (Gerd v. Egidy) Date: Tue, 21 Feb 2017 15:34:17 +0100 Subject: Announcing paperbackup.py to backup keys as QR codes on paper Message-ID: <9664399.F7pj19RVc2@thunder.m.i2n> Hi, I'd like to announce a program I wrote to backup GnuPG and SSH keys as qrcodes on paper: paperbackup.py https://github.com/intra2net/paperbackup This is designed as fallback if all your regular backups failed to restore or were lost. Usage is like this: gpg2 --armor --export "User Name" >key.asc gpg2 --armor --export-secret-key "User Name" >>key.asc paperbackup.py key.asc paperrestore.sh key.asc.pdf | diff key.asc - lpr key.asc.pdf You'll find all the details, reasoning and examples in the README. Kind regards, Gerd From deg at davidegray.com Tue Feb 21 18:59:16 2017 From: deg at davidegray.com (David Gray) Date: Tue, 21 Feb 2017 12:59:16 -0500 Subject: Problems with cert validation via CRL In-Reply-To: <1c850be7-426c-599e-90dc-0932a178ea1c@digitalbrains.com> References: <000001d28b80$62b3a1e0$281ae5a0$@davidegray.com> <87lgt0p92p.fsf@iwagami.gniibe.org> <87CF4606-FE26-4376-8799-7674F956D602@davidegray.com> <1c850be7-426c-599e-90dc-0932a178ea1c@digitalbrains.com> Message-ID: Thanks, Peter! According to the documentation the trusted certainty need to be in a folder named "trusted-certs" in the home directory. I don't believe I've copied them there manually, so if it hasn't happened automatically that could very well be the issue. I'm at work but once I get home I'll check it out and report back. Really appreciate the help, Dave Sent from my iPhone > On Feb 21, 2017, at 10:13 AM, Peter Lebbing wrote: > >> On 21/02/17 13:20, David Gray wrote: >> I'm no expert, but when I look at the debug info (attached to >> original email), it appears that gpgsm is able to get the crl that my >> cert points to but it may be having trouble parsing it. > > Reading that part made me think it couldn't find the issuer of the CRL: > >> dirmngr[3184.0]: error fetching certificate by subject: Configuration error >> dirmngr[3184.0]: CRL issuer certificate {92616B82E1A2A0AA4FEC67F1C2A3F7B48000C1EC} not found > > When I fetch the CRL we're talking about, OpenSSL tells me about it: > >> Certificate Revocation List (CRL): >> Version 2 (0x1) >> Signature Algorithm: sha256WithRSAEncryption >> Issuer: /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO SHA-256 Client Authentication and Secure Email CA >> Last Update: Feb 20 16:07:34 2017 GMT >> Next Update: Feb 24 16:07:34 2017 GMT >> CRL extensions: >> X509v3 Authority Key Identifier: >> keyid:92:61:6B:82:E1:A2:A0:AA:4F:EC:67:F1:C2:A3:F7:B4:80:00:C1:EC >> >> X509v3 CRL Number: >> 822 > > The issuer is the certificate that gpgsm knows about: > >> Certificate: >> Data: >> Version: 3 (0x2) >> Serial Number: >> e0:23:cb:15:12:83:53:89:ad:61:6e:7a:54:67:6b:21 >> Signature Algorithm: sha256WithRSAEncryption >> Issuer: C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, CN=AddTrust External CA Root >> Validity >> Not Before: Dec 22 00:00:00 2014 GMT >> Not After : May 30 10:48:38 2020 GMT >> Subject: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO SHA-256 Client Authentication and Secure Email CA >> [...] >> X509v3 extensions: >> X509v3 Authority Key Identifier: >> keyid:AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A >> >> X509v3 Subject Key Identifier: >> 92:61:6B:82:E1:A2:A0:AA:4F:EC:67:F1:C2:A3:F7:B4:80:00:C1:EC >> [...] >> SHA1 Fingerprint=59:B8:25:FC:08:86:0B:04:B3:92:CC:25:FE:C4:8C:76:07:53:B6:89 > > I suspect that even though gpgsm knows about it, dirmngr might not, > hence the failing CRL verification. I think you need to feed the > certificate to dirmngr as well. > > Whether this is actually the reason you're having problems, I don't know. > > 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 > From joyce at joycebabu.com Tue Feb 21 18:48:06 2017 From: joyce at joycebabu.com (Joyce Babu) Date: Tue, 21 Feb 2017 23:18:06 +0530 Subject: No such file or directory error with gpgme Message-ID: I am trying to setup a signed apt repository. When I run reprepro, it is failing with error $ reprepro includedeb xenial /tmp/mod-pagespeed-stable_current_amd64.deb Exporting indices... gpgme gave error Pinentry:32849: No such file or directory ERROR: Could not finish exporting 'xenial'! I tried enabling debug log by setting GPGME_DEBUG=9:/data/mygpgme.log But I can't decipher which file is missing from the debug log ------------ GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_run_io_cb: call: item=0xe61e30, handler (0xe593d0, 8) GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_read: enter: fd=0x8, buffer=0xe57420, count=1024 GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_read: check: 5b474e5550473a5d 2050524f47524553 [GNUPG:] PROGRES GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_read: check: 53202d263132203f 203020300a5b474e S -&12 ? 0 0.[GN GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_read: check: 5550473a5d204245 47494e5f5349474e UPG:] BEGIN_SIGN GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_read: check: 494e472048380a5b 474e5550473a5d20 ING H8.[GNUPG:] GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_read: check: 50524f4752455353 202d263132203f20 PROGRESS -&12 ? GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_read: check: 3135313620300a 1516 0. GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_read: leave: result=87 GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_select: enter: fds=0xe61e60, nfds=10, nonblock=0 GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_select: check: fds=0xe61e60, select on [ r0x8 r0xe ] GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_select: check: fds=0xe61e60, select OK [ r0x8 ] GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_select: leave: result=1 GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_run_io_cb: call: item=0xe61e30, need to check GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_select: enter: fds=0x7ffe918a8f10, nfds=1, nonblock=1 GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_select: check: fds=0x7ffe918a8f10, select on [ r0x8 ] GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_select: check: fds=0x7ffe918a8f10, select OK [ r0x8 ] GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_select: leave: result=1 GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_run_io_cb: call: item=0xe61e30, handler (0xe593d0, 8) GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_read: enter: fd=0x8, buffer=0xe57420, count=1024 GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_read: check: 5b474e5550473a5d 2050494e454e5452 [GNUPG:] PINENTR GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_read: check: 595f4c41554e4348 454420393436310a Y_LAUNCHED 9461. GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_read: check: 5b474e5550473a5d 204641494c555245 [GNUPG:] FAILURE GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_read: check: 207369676e203833 3931383932390a sign 83918929. GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_read: leave: result=63 GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_select: enter: fds=0xe61e60, nfds=10, nonblock=0 GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_select: check: fds=0xe61e60, select on [ r0x8 r0xe ] GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_select: check: fds=0xe61e60, select OK [ r0x8 r0xe ] GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_select: leave: result=2 GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_run_io_cb: call: item=0xe61e30, need to check GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_select: enter: fds=0x7ffe918a8f10, nfds=1, nonblock=1 GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_select: check: fds=0x7ffe918a8f10, select on [ r0x8 ] GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_select: check: fds=0x7ffe918a8f10, select OK [ r0x8 ] GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_select: leave: result=1 GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_run_io_cb: call: item=0xe61e30, handler (0xe593d0, 8) GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_read: enter: fd=0x8, buffer=0xe57420, count=1024 GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_read: leave: result=0 GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_cancel_with_err: enter: ctx=0xe3f890, ctx_err=83918929, op_err=0 GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_close: enter: fd=0xb GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_close: check: fd=0xb, invoking close handler 0x7f4418b35800/0xe593d0 GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_close: leave: result=0 GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_close: enter: fd=0x8 GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_close: check: fd=0x8, invoking close handler 0x7f4418b35800/0xe593d0 GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_remove_io_cb: call: data=0xe61e10, setting fd 0x8 (item=0xe61e30) done GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_close: leave: result=0 GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_close: enter: fd=0xe GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_close: check: fd=0xe, invoking close handler 0x7f4418b35800/0xe593d0 GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_remove_io_cb: call: data=0xe61fb0, setting fd 0xe (item=0xe61fd0) done GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_io_close: leave: result=0 GPGME 2017-02-18 12:36:07 <0x24e7> gpgme:gpg_io_event: call: gpg=0xe593d0, event 0x7f4418b26960, type 1, type_data 0x7ffe918a8f20 GPGME 2017-02-18 12:36:07 <0x24e7> _gpgme_cancel_with_err: leave GPGME 2017-02-18 12:36:07 <0x24e7> gpgme_op_sign:476: error: No such file or directory GPGME 2017-02-18 12:36:07 <0x24e7> gpgme_data_release: call: dh=0xe5f4d0 GPGME 2017-02-18 12:36:07 <0x24e7> gpgme_release: call: ctx=0xe3f890 --------------------- Full log - http://pastebin.com/9i6AA9QQ Can someone please tell me why the above command is failing? The command is being run inside a docker container. Thanks & Regards, Joyce Babu -------------- next part -------------- An HTML attachment was scrubbed... URL: From dixonwille at gmail.com Tue Feb 21 22:27:55 2017 From: dixonwille at gmail.com (Will Dixon (Clemsonopoly94)) Date: Tue, 21 Feb 2017 16:27:55 -0500 Subject: GnuPG2.1 is using the wrong signing subkey Message-ID: So I am having an issue signing documents with gpg2.1. Every time I try and sign something, I get: ? dixonwille [~] ? gpg2 --detach-sign Images/EinsteinWP.jpg gpg: using "0xEC933DA229123788" as default secret key for signing gpg: signing failed: No secret key gpg: signing failed: No secret key As the above message specifies I do have a default key set in my config. Here is what my private listing shows: ? dixonwille [~] ? gpg2 -K --with-keygrip /home/dixonwille/.gnupg/pubring.kbx ----------------------------------- sec# rsa4096/0x496AC5165C585343 2017-01-14 [SC] Key fingerprint = 2092 7961 2A0C EF20 83D0 8244 496A C516 5C58 5343 Keygrip = 308FF7DD37FB9E175378D76125FCB2BC4C5C225C uid [ultimate] William E. Dixon uid [ultimate] William E. Dixon uid [ultimate] William E. Dixon uid [ultimate] [jpeg image of size 5910] ssb rsa4096/0xD3522B485A800AFD 2017-01-14 [E] [expires: 2018-01-14] Keygrip = 178AB20F816E5FAA31440968AD6EA06B0340FB90 ssb rsa4096/0xEC933DA229123788 2017-01-14 [S] [expires: 2018-01-14] Keygrip = 89A90662E5908D5F271B87A5DC6D26F01B53C9EC ssb rsa4096/0xBAA693EC561AD6D9 2017-01-14 [A] [expires: 2018-01-14] Keygrip = 9D48688AF67C407BB91900BA07725CCE7E08B546 ssb rsa4096/0x7A3D17611B1FFDD2 2017-01-14 [S] [expires: 2018-01-14] Keygrip = 50EE902E41E323600B02769FA2A96FE8C51D5A35 ssb rsa4096/0xB64824658CE421C8 2017-01-14 [A] [expires: 2018-01-14] Keygrip = D3BD87D77B844A5AE54CEC0466353030A816441B ssb rsa4096/0x7642000294227858 2017-01-16 [S] [expires: 2018-01-14] Keygrip = B10269A98E3D357F3B32C155367B1CEDCAE998E8 ssb rsa4096/0x32C4DD59E753B43B 2017-01-16 [A] [expires: 2018-01-14] Keygrip = 40E86DAAEDEE6BA714F26B09FBA38C35C4E4F264 Now all these keys do not have a private conterpart. Only three of them do (0xD3522B485A800AFD, 0xEC933DA229123788, 0xBAA693EC561AD6D9). To make sure I ran gpg-connect-agent then ran keyinfo --list. ? dixonwille [~] ? gpg-connect-agent > keyinfo --list S KEYINFO 178AB20F816E5FAA31440968AD6EA06B0340FB90 D - - - P - - - S KEYINFO 89A90662E5908D5F271B87A5DC6D26F01B53C9EC D - - - P - - - S KEYINFO 9D48688AF67C407BB91900BA07725CCE7E08B546 D - - - P - - - OK > So as you can see my secrets are stored in the gpg-agent. Running echo foo | gpg --clearsign -v --debug ipc for debug information showed these intresting lines: gpg: DBG: chan_5 -> HAVEKEY 308FF7DD37FB9E175378D76125FCB2BC4C5C225C gpg: DBG: chan_5 <- ERR 67108881 No secret key gpg: DBG: chan_5 -> HAVEKEY 89A90662E5908D5F271B87A5DC6D26F01B53C9EC gpg: DBG: chan_5 <- OK gpg: using "0xEC933DA229123788" as default secret key for signing gpg: DBG: chan_5 -> HAVEKEY 308FF7DD37FB9E175378D76125FCB2BC4C5C225C 178AB20F816E5FAA31440968AD6EA06B0340FB90 89A90662E5908D5F271B87A5DC6D26F01B53C9EC 9D48688AF67C407BB91900BA07725CCE7E08B546 50EE902E41E323600B02769FA2A96FE8C51D5A35 D3BD87D77B844A5AE54CEC0466353030A816441B B10269A98E3D357F3B32C155367B1CEDCAE998E8 40E86DAAEDEE6BA714F26B09FBA38C35C4E4F264 gpg: DBG: chan_5 <- OK gpg: using subkey 0x7642000294227858 instead of primary key 0x496AC5165C585343 gpg: writing to stdout gpg: DBG: chan_5 -> KEYINFO B10269A98E3D357F3B32C155367B1CEDCAE998E8 gpg: DBG: chan_5 <- ERR 67108891 Not found Which confuses me. It first checks my Primary Master key for secret, it can't find it so fails. Then it checks the keygrip for my default key and then states using "0xEC933DA229123788" as default secret key for signing. That sounds good please do. But then it sends another HAVEKEY for what looks like all my keygrips. This returns true as one of them does have a secret. So it then states using subkey 0x7642000294227858 instead of primary key 0x496AC5165C585343which is the latest signing key I did make. My real question is how can I force GnuPG2.1 to use the key I specified in the default-key. Seems like it gets over written with whatever GnuPG2.1 feels like. To debunk the pinentry answer I know someone might mention if I don't mention it now. If I run ssh git at github.com I get popped up a dialog to input my key password (I use the Authentication key for my ssh keys and store in gpg-agent as well). So I know my gpg-agent.conf is set correctly and gpg.conf is set correctly. I have a stack overflow question open for about 8 days with no response. Much help is appreciated. http://stackoverflow.com/questions/42195987/gnupg2-1-is-using-the-wrong-signing-subkey Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gniibe at fsij.org Wed Feb 22 03:31:54 2017 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 22 Feb 2017 11:31:54 +0900 Subject: Problems with cert validation via CRL In-Reply-To: <000001d28b80$62b3a1e0$281ae5a0$@davidegray.com> References: <000001d28b80$62b3a1e0$281ae5a0$@davidegray.com> Message-ID: <87wpcjq7l1.fsf@iwagami.gniibe.org> Hello, again, David Gray wrote: > dave at dave-VirtualBox:~/.gnupg/crls.d$ dirmngr --debug-all --fetch-crl http://crl.comodoca.com/COMODOSHA256ClientAuthenticationandSecureEmailCA.crl Reading the code of dirmngr, I think that --fetch-crl (or dirmngr-client --load-crl) doesn't work well for a CRL which is not signed by system CA directly. When dirmngr doesn't know the issuer, it inquires back to the client, and it fails as: > dirmngr[3184.0]: DBG: find_cert_bysubject: certificate not returned by caller - doing lookup > dirmngr[3184.0]: error fetching certificate by subject: Configuration error > dirmngr[3184.0]: CRL issuer certificate {92616B82E1A2A0AA4FEC67F1C2A3F7B48000C1EC} not found > dirmngr[3184.0]: crl_parse_insert failed: Missing certificate When it is gpgsm which asks dirmngr to validate a certificate, I think it works. I think that you once successfully did that on this box: > dave at dave-VirtualBox:~/.gnupg/crls.d$ gpgsm --debug-all --list-keys --with-validation And the CRL is cached. Thus, > gpgsm: DBG: chan_6 -> ISVALID 685A02B9E2BD4B5EE1FA51739B8882AEA38FB3C8.3FAADAD7DD3F946B114321153B76F88C This is gpgsm asking if your X.509 client certificate is valid or not. > gpgsm: DBG: chan_6 <- INQUIRE ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868 Here, I think that the CRL for your X.509 client certificate is cached and checked. dirmngr does not ask about anything about your X.509 client certificate or its issuer. dirmngr inquires back to gpgsm if the root issuer is trusted. CN=AddTrust External CA Root,OU=AddTrust External TTP Network,O=AddTrust AB,C=SE fingerprint=02FAF3E291435468607857694DF5E45B68851868 then, gpgsm asks to gpg-agent. > gpgsm: DBG: chan_7 -> ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868 > gpgsm: DBG: chan_7 <- S TRUSTLISTFLAG relax > gpgsm: DBG: chan_7 <- OK It is trusted. Then, gpgsm replies back to dirmngr. > gpgsm: DBG: chan_6 -> D 1 > gpgsm: DBG: chan_6 -> END It's trusted. > gpgsm: DBG: chan_6 <- OK Then, dirmngr answers OK for the validation of your X.509 client certificate. > gpgsm: DBG: chan_6 -> ISVALID 14673DA5792E145E9FA1425F9EF3BFC1C4B4957C.00E023CB1512835389AD616E7A54676B21 This is gpgsm asking if the intermediate certificate of following is valid or not: CN=COMODO SHA-256 Client Authentication and Secure Email CA,O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB fingerprint=59B825FC08860B04B392CC25FEC48C760753B689 > gpgsm: DBG: chan_6 <- INQUIRE ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868 > gpgsm: DBG: chan_7 -> ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868 > gpgsm: DBG: chan_7 <- S TRUSTLISTFLAG relax > gpgsm: DBG: chan_7 <- OK > gpgsm: DBG: chan_6 -> D 1 > gpgsm: DBG: chan_6 -> END > gpgsm: DBG: chan_6 <- OK Similar interactions between gpg-agent<->gpgsm<->dirmngr. > gpgsm: DBG: chan_7 -> ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868 > gpgsm: DBG: chan_7 <- S TRUSTLISTFLAG relax > gpgsm: DBG: chan_7 <- OK I don't know the exact reason, but gpgsm again asks gpg-agent. And gpgsm shows your X.509 client certificate: > ID: 0x2F5900E9 > S/N: 3FAADAD7DD3F946B114321153B76F88C > Issuer: /CN=COMODO SHA-256 Client Authentication and Secure Email CA/O=COMODO CA Limited/L=Salford/ST=Greater Manchester/C=GB > Subject: /EMail=user at domain.com > aka: user at domain.com > validity: 2017-01-02 00:00:00 through 2018-01-02 23:59:59 > key type: 2048 bit RSA > key usage: digitalSignature keyEncipherment > ext key usage: emailProtection (suggested), 1.3.6.1.4.1.6449.1.3.5.2 (suggested) > policies: 1.3.6.1.4.1.6449.1.2.1.1.1:N: > fingerprint: 4A:53:A9:E6:51:32:23:DF:B4:7D:B8:A3:19:F1:3E:A3:2F:59:00:E9 > [Note: non-critical certificate policy not allowed] > [Note: non-critical certificate policy not allowed] > [validation model used: shell] > [certificate is good] On the other hand, on your Windows... > C:\Users\dave\Downloads>gpgsm --list-keys --with-validation --debug-all [...] > gpgsm: DBG: chan_0x000001c0 -> ISVALID 14673DA5792E145E9FA1425F9EF3BFC1C4B4957C.00E023CB1512835389AD616E7A54676B21 > gpgsm: DBG: chan_0x000001c0 <- INQUIRE ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868 [...] > gpgsm: DBG: chan_0x000001e8 -> ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868 > gpgsm: DBG: chan_0x000001e8 <- S TRUSTLISTFLAG relax > gpgsm: DBG: chan_0x000001e8 <- OK > gpgsm: DBG: chan_0x000001c0 -> D 1 > gpgsm: DBG: chan_0x000001c0 -> END > gpgsm: DBG: chan_0x000001c0 <- OK > gpgsm: DBG: chan_0x000001e8 -> ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868 > gpgsm: DBG: chan_0x000001e8 <- S TRUSTLISTFLAG relax > gpgsm: DBG: chan_0x000001e8 <- OK [...] > gpgsm: DBG: chan_0x000001e8 -> ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868 > gpgsm: DBG: chan_0x000001e8 <- S TRUSTLISTFLAG relax > gpgsm: DBG: chan_0x000001e8 <- OK [...] > gpgsm: DBG: chan_0x000001c0 -> ISVALID 685A02B9E2BD4B5EE1FA51739B8882AEA38FB3C8.3FAADAD7DD3F946B114321153B76F88C > gpgsm: DBG: chan_0x000001c0 <- INQUIRE SENDCERT > gpgsm: DBG: chan_000001C0 -> [ 44 20 30 82 05 3b 30 82 04 23 a0 03 02 01 02 02 ...(982 byte(s) skipped) ] > gpgsm: DBG: chan_000001C0 -> [ 44 20 74 69 6f 6e 61 6e 64 53 65 63 75 72 65 45 ...(361 byte(s) skipped) ] > gpgsm: DBG: chan_0x000001c0 -> END Here, gpgsm asking if your X.509 client certificate is valid or not. And then, dirmngr inquires back to gpgsm about the certificate. Then gpgsm sends it to dirmngr. > gpgsm: DBG: chan_0x000001c0 <- INQUIRE ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868 > gpgsm: DBG: chan_0x000001e8 -> ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868 > gpgsm: DBG: chan_0x000001e8 <- S TRUSTLISTFLAG relax > gpgsm: DBG: chan_0x000001e8 <- OK > gpgsm: DBG: chan_0x000001c0 -> D 1 > gpgsm: DBG: chan_0x000001c0 -> END And then, dirmngr inquires back to gpgsm if the root issuer is trusted. CN=AddTrust External CA Root,OU=AddTrust External TTP Network,O=AddTrust AB,C=SE fingerprint=02FAF3E291435468607857694DF5E45B68851868 then, gpgsm asks to gpg-agent. It is trusted. Then, gpgsm replies back to dirmngr. > gpgsm: DBG: chan_0x000001c0 <- ERR 167772255 No CRL known But, dirmngr says no CRL known for your X.509 client certificate. I don't know what's going on here. You can enable debug option of dirmngr (debug-level, log-file, debug-all) in your dirmngr.conf. [...] > gpgsm: DBG: chan_0x000001c0 -> ISVALID 14673DA5792E145E9FA1425F9EF3BFC1C4B4957C.00E023CB1512835389AD616E7A54676B21 > gpgsm: DBG: chan_0x000001c0 <- INQUIRE ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868 > gpgsm: DBG: chan_0x000001e8 -> ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868 > gpgsm: DBG: chan_0x000001e8 <- S TRUSTLISTFLAG relax > gpgsm: DBG: chan_0x000001e8 <- OK > gpgsm: DBG: chan_0x000001c0 -> D 1 > gpgsm: DBG: chan_0x000001c0 -> END > gpgsm: DBG: chan_0x000001c0 <- OK > gpgsm: DBG: chan_0x000001e8 -> ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868 > gpgsm: DBG: chan_0x000001e8 <- S TRUSTLISTFLAG relax > gpgsm: DBG: chan_0x000001e8 <- OK This is the interaction for the intermediate certificate. Nothing wrong here. > ID: 0x2F5900E9 > S/N: 3FAADAD7DD3F946B114321153B76F88C > Issuer: /CN=COMODO SHA-256 Client Authentication and Secure Email CA/O=COMODO CA Limited/L=Salford/ST=Greater Manchester/C=GB > Subject: /EMail=user at domain.com > aka: user at domain.com > validity: 2017-01-02 00:00:00 through 2018-01-02 23:59:59 > key type: 2048 bit RSA > key usage: digitalSignature keyEncipherment > ext key usage: emailProtection (suggested), 1.3.6.1.4.1.6449.1.3.5.2 (suggested) > policies: 1.3.6.1.4.1.6449.1.2.1.1.1:N: > fingerprint: 4A:53:A9:E6:51:32:23:DF:B4:7D:B8:A3:19:F1:3E:A3:2F:59:00:E9 > [Note: non-critical certificate policy not allowed] > [no CRL found for certificate] > [Note: non-critical certificate policy not allowed] > [validation model used: shell] > [certificate is bad: No CRL known] You can check your X.509 client certificate by $ gpgsm --verbose --dump-cert 0x2F5900E9 to see its CRL or more information. -- From dkg at fifthhorseman.net Wed Feb 22 04:24:36 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 21 Feb 2017 22:24:36 -0500 Subject: GnuPG2.1 is using the wrong signing subkey In-Reply-To: References: Message-ID: <87lgsyaowb.fsf@alice.fifthhorseman.net> On Tue 2017-02-21 16:27:55 -0500, Will Dixon (Clemsonopoly94) wrote: > So I am having an issue signing documents with gpg2.1. Every time I try and sign something, I get: > > ? dixonwille [~] ? gpg2 --detach-sign Images/EinsteinWP.jpg > gpg: using "0xEC933DA229123788" as default secret key for signing > gpg: signing failed: No secret key > gpg: signing failed: No secret key > As the above message specifies I do have a default key set in my config. Here is what my private listing shows: > > ? dixonwille [~] ? gpg2 -K --with-keygrip > /home/dixonwille/.gnupg/pubring.kbx > ----------------------------------- > sec# rsa4096/0x496AC5165C585343 2017-01-14 [SC] > Key fingerprint = 2092 7961 2A0C EF20 83D0 8244 496A C516 5C58 5343 > Keygrip = 308FF7DD37FB9E175378D76125FCB2BC4C5C225C > uid [ultimate] William E. Dixon > uid [ultimate] William E. Dixon > uid [ultimate] William E. Dixon > uid [ultimate] [jpeg image of size 5910] > ssb rsa4096/0xD3522B485A800AFD 2017-01-14 [E] [expires: 2018-01-14] > Keygrip = 178AB20F816E5FAA31440968AD6EA06B0340FB90 > ssb rsa4096/0xEC933DA229123788 2017-01-14 [S] [expires: 2018-01-14] > Keygrip = 89A90662E5908D5F271B87A5DC6D26F01B53C9EC > ssb rsa4096/0xBAA693EC561AD6D9 2017-01-14 [A] [expires: 2018-01-14] > Keygrip = 9D48688AF67C407BB91900BA07725CCE7E08B546 > ssb rsa4096/0x7A3D17611B1FFDD2 2017-01-14 [S] [expires: 2018-01-14] > Keygrip = 50EE902E41E323600B02769FA2A96FE8C51D5A35 > ssb rsa4096/0xB64824658CE421C8 2017-01-14 [A] [expires: 2018-01-14] > Keygrip = D3BD87D77B844A5AE54CEC0466353030A816441B > ssb rsa4096/0x7642000294227858 2017-01-16 [S] [expires: 2018-01-14] > Keygrip = B10269A98E3D357F3B32C155367B1CEDCAE998E8 > ssb rsa4096/0x32C4DD59E753B43B 2017-01-16 [A] [expires: 2018-01-14] > Keygrip = 40E86DAAEDEE6BA714F26B09FBA38C35C4E4F264 > Now all these keys do not have a private conterpart. Only three of them do (0xD3522B485A800AFD, 0xEC933DA229123788, 0xBAA693EC561AD6D9). To make sure I ran gpg-connect-agent then ran keyinfo --list. When signing, gpg prefers the most recent subkey that is signing-capable. Please see: https://bugs.gnupg.org/gnupg/issue1967 for ongoing discussion and a possible patch that's waiting for review by more knowledgable developers. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From dkg at fifthhorseman.net Wed Feb 22 05:25:44 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 21 Feb 2017 23:25:44 -0500 Subject: Announcing paperbackup.py to backup keys as QR codes on paper In-Reply-To: <9664399.F7pj19RVc2@thunder.m.i2n> References: <9664399.F7pj19RVc2@thunder.m.i2n> Message-ID: <87a89eam2f.fsf@alice.fifthhorseman.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Gerd-- On Tue 2017-02-21 09:34:17 -0500, Gerd v. Egidy wrote: > I'd like to announce a program I wrote to backup GnuPG and SSH keys as > qrcodes on paper: > > paperbackup.py > https://github.com/intra2net/paperbackup > > This is designed as fallback if all your regular backups failed to restore or > were lost. > > Usage is like this: > > gpg2 --armor --export "User Name" >key.asc > gpg2 --armor --export-secret-key "User Name" >>key.asc > paperbackup.py key.asc > paperrestore.sh key.asc.pdf | diff key.asc - > lpr key.asc.pdf this is a cool idea. however, it seems like you might be backing up more than most people would need. For most folks, their OpenPGP certificates (public keys) are stored on the public keyservers. Or at least their friends have a copy of them :) Even if you want the whole certificate, you've duplicated most of the material here -- just the data produced by --export-secret-key should be sufficient to reconstruct everything. Probably, putting less data in your qrcode backup will make the backup more robust during recovery.. So for most folks, the critical backup that they need is likely to be only the secret key material itself, since the public key material and signatures and the like can all be retrieved from from the keyserver network or from friends. Are you aware of David Shaw's paperkey? http://www.jabberwocky.com/software/paperkey/ This produces significantly less data (still in text form, though), so it could be combined with your approach to have a nice big, robust, scannable recovery mechanism. thanks for publishing your work! --dkg -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAlitEsgACgkQFJitxsGS MjfnZQ//ediyODKSSDEj3wEEobXd+27VTv3oOS6EpBUDxyse3ttMAb1q9EBgzJC/ DJAYC1vOqyYzQ7+7uLVAKShE2rMWDhTnxAbIYsbqRpxeS0vGsn5L3yWpiT+u5LkN sBXONHO5MxDH1kQDZ9+muFZWYUBTSKbJLLHN0R5uk1PqvVRXBMT3HDFusqeS0EBI W+lBKGGABBGk1P8/Sc1tOX9WbkA5aQxNhGq5Rq0E4FUrR7J6IlAKGDqjVmCHs1++ BzMVKqkfZm2++PQXpGyzCadkTL9oTK4+zMz3E6cvQtwlNWZBZLW1vPZPNwRWBekK VNbZEyIOuSSZTR/jmDyh7dNDAzsjjKF+1Gspu9uDFWVHUbz72hdUzmyRB0RG8DfN XfE8zscyJlmJfTccgRYzfuTNXU9QtnlwyThvYyrvZOQ/WMSxfYe+ST3neJOGGB7j UFnhj4DgfSNVbXT6mEOLWEos3S21YSN8hMiLkOqvyF7+Tnuq98hyEESAX0BRLAjw Jo1eLkkgdAaB5Ww08VoxrmArSS7dCpvyn1OpeuOvC0BZuKBKJI+93ZuWSAKDRdNr ouI355qDnOun7ut9cAl1fC0r6ws9qjeGNXTgQUHGAu43bs0A2rkhzaPg0DdHYvrQ ME3mdC45HOT+EYCysJj9DNueD9ZO/W235MPWTHOcD17uBi5iHr4= =DPyt -----END PGP SIGNATURE----- From gerd.von.egidy at intra2net.com Wed Feb 22 09:38:51 2017 From: gerd.von.egidy at intra2net.com (Gerd v. Egidy) Date: Wed, 22 Feb 2017 09:38:51 +0100 Subject: Announcing paperbackup.py to backup keys as QR codes on paper In-Reply-To: <87a89eam2f.fsf@alice.fifthhorseman.net> References: <9664399.F7pj19RVc2@thunder.m.i2n> <87a89eam2f.fsf@alice.fifthhorseman.net> Message-ID: <1635365.VMeaqTAsHE@thunder.m.i2n> Hi Daniel, > > gpg2 --armor --export "User Name" >key.asc > > gpg2 --armor --export-secret-key "User Name" >>key.asc > > paperbackup.py key.asc > > this is a cool idea. however, it seems like you might be backing up > more than most people would need. For most folks, their OpenPGP > certificates (public keys) are stored on the public keyservers. Or at > least their friends have a copy of them :) > > Even if you want the whole certificate, you've duplicated most of the > material here -- just the data produced by --export-secret-key should be > sufficient to reconstruct everything. Probably, putting less data in > your qrcode backup will make the backup more robust during recovery.. You are right that this is probably more than strictly neccessary. But if you look at my example output on github, a regular public and private key in qrcodes and plain is just 9 pages. If some of the qrcodes containing the public key could not be decoded during recovery, it won't affect the codes of the private key. The user will just have to remove the ascii armored remnants of the public key. So adding the public key won't hurt. paperbackup.py doesn't know or understand public or private keys, it just cares about text files. So the user is always free to decide what parts to back up. > Are you aware of David Shaw's paperkey? > > http://www.jabberwocky.com/software/paperkey/ Yes, I have linked it in the README on github, section "Similar projects". > This produces significantly less data (still in text form, though), so > it could be combined with your approach to have a nice big, robust, > scannable recovery mechanism. Correct. But unless you want to backup hundreds of keys I don't think it is necessary to think much about data reduction. It is just a few pages of paper and printing and scanning them is just a matter of a few minutes. This is the beauty of qrcodes in contrast to OCR and manually typing. Kind regards, Gerd From peter at digitalbrains.com Wed Feb 22 13:56:22 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 22 Feb 2017 13:56:22 +0100 Subject: Announcing paperbackup.py to backup keys as QR codes on paper In-Reply-To: <1635365.VMeaqTAsHE@thunder.m.i2n> References: <9664399.F7pj19RVc2@thunder.m.i2n> <87a89eam2f.fsf@alice.fifthhorseman.net> <1635365.VMeaqTAsHE@thunder.m.i2n> Message-ID: Hello Gerd! Thank you for sharing your program with the world! I'm sure it will be useful. On 22/02/17 09:38, Gerd v. Egidy wrote: > You are right that this is probably more than strictly neccessary. But if you > look at my example output on github, a regular public and private key in > qrcodes and plain is just 9 pages. I beg to differ. Following your instructions, my PDF is 208 pages long! The certificate (aka public key) includes all signatures, all the data on the keyserver. It's data you don't really need to back up since it is public, and it can be huge. My key.asc file is 137,424 bytes following your instructions. Additionally, --export-secret-key actually includes everything from --export, it just *adds* the secret key material to it. So there is no need to do both --export and --export-secret-key; it just doubles the information from --export. What you're probably looking for is: $ gpg2 --armour --output key.asc --export-options export-minimal --export-secret-key [KEYID] $ paperbackup.py key.asc $ paperrestore.sh key.asc.pdf | diff key.asc - $ lpr key.asc.pdf However, I'm running into a little problem here myself... GnuPG 2.1.18 does not respect the "export-minimal" option for --export-secret-key, only for --export. So if you are using GnuPG 2.1, this will not work as intended. This is in all likelihood a bug in GnuPG 2.1, and I'll report it right now. Leaving aside this bug, export-minimal will achieve your goal: it will only include the currently valid parts of the key without any certifications by other keys. It is all you need to have a working key. The certifications by other keys are on the keyservers. Oh, as an aside, the advantage of paperkey is that it is self-describing. No matter what happens, as long as we can still use hexadecimal digits to describe binary content (which would be trivial to reimplement), we can reconstruct the binary private key file. Using QR codes has the disadvantage that if you cannot find a QR-code decoder for your platform in the future, reimplementing one is far from trivial. You are dependent on QR codes surviving as an actually supported data format. Finally, I remember something about QR codes inherently supporting splitting data over multiple individual code blocks, specifically for data that is too large to fit in a single block. I don't know if it supports the number of blocks you need, but you might want to check it out. Also, you say large QR codes are easily damaged by wrinkles and deformations. Is this perhaps related to the amount of error correction data included? You can tune the ratio of content data to error correction data, making a QR code more resilient to damage. However, if you find that it is not unreadable individual pixels but rather the deformation of the total that is throwing off decoders, than I suppose the ratio doesn't help: it either can reduce it to the required square or it cannot, I'd think. 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 peter at digitalbrains.com Wed Feb 22 14:12:31 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 22 Feb 2017 14:12:31 +0100 Subject: export-minimal doesn't affect export-secret-key? Message-ID: <680160cc-58e7-4f03-1624-e3a642791d75@digitalbrains.com> I just found out that the following two commands are equivalent: > $ gpg2 -o full.gpg --export-secret-keys ac46efe6de500b3e > $ gpg2 -o minimal.gpg --export-options export-minimal --export-secret-keys ac46efe6de500b3e > $ ll > total 104 > -rw------- 1 peter peter 50731 Feb 22 14:00 full.gpg > -rw------- 1 peter peter 50731 Feb 22 14:00 minimal.gpg > $ gpg2 --version > gpg (GnuPG) 2.1.18 > libgcrypt 1.7.6-beta > [...] I thought "well this is surely a bug in the new 2.1, what with the new secret key storage". But: > $ gpg -o full.gpg --export-secret-keys ac46efe6de500b3e > $ gpg -o minimal.gpg --export-options export-minimal --export-secret-keys ac46efe6de500b3e > $ ll > total 88 > -rw-r--r-- 1 peter peter 41465 Feb 22 14:02 full.gpg > -rw-r--r-- 1 peter peter 41465 Feb 22 14:02 minimal.gpg > $ gpg --version > gpg (GnuPG) 1.4.18 > [...] And now I'm confused... surely export-minimal is useful when backing up your secret key and storage is limited? We just encountered this with the paperbackup.py thread... This works fine, BTW: > $ gpg2 -o minimal.gpg --export-options export-minimal --export ac46efe6de500b3e$ ll > total 56 > -rw-r--r-- 1 peter peter 50631 Feb 22 14:06 full.gpg > -rw-r--r-- 1 peter peter 2623 Feb 22 14:06 minimal.gpg 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 Wed Feb 22 14:18:15 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 22 Feb 2017 14:18:15 +0100 Subject: Announcing paperbackup.py to backup keys as QR codes on paper In-Reply-To: References: <9664399.F7pj19RVc2@thunder.m.i2n> <87a89eam2f.fsf@alice.fifthhorseman.net> <1635365.VMeaqTAsHE@thunder.m.i2n> Message-ID: On 22/02/17 13:56, Peter Lebbing wrote: > Leaving aside this bug, export-minimal will achieve your goal: it will > only include the currently valid parts of the key without any > certifications by other keys. Whoops! I made a mistake here. export-minimal does not remove "parts of the key that are currently not valid". I wrote that, immediately thought "I don't know that", looked it up and edited my text accordingly. Except I forgot to change this sentence. The quote should have read: > Leaving aside this bug, export-minimal will achieve your goal: it will > only include the basic parts of the key without any certifications by > other keys. 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 rjh at sixdemonbag.org Wed Feb 22 14:25:08 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 22 Feb 2017 08:25:08 -0500 Subject: Announcing paperbackup.py to backup keys as QR codes on paper In-Reply-To: References: <9664399.F7pj19RVc2@thunder.m.i2n> <87a89eam2f.fsf@alice.fifthhorseman.net> <1635365.VMeaqTAsHE@thunder.m.i2n> Message-ID: <1cbc2772-0d28-0b9b-dbe6-7b5792628225@sixdemonbag.org> > Oh, as an aside, the advantage of paperkey is that it is > self-describing. I'll chime in with another recommendation for Paperkey. I'm a little surprised that your code is as large as it is, too: using an alternate pipeline you might be able to significantly reduce code size. (a) use Python 3's gpg module to export the secret key (b) paperkey --output-type raw --secret-key key.gpg --output key.raw (c) use Python 3's QR library to create a series of PNGs (d) use Wand or PythonMagick to convert the PNGs to PDF (e) save the PDF and you're done From thomas.jarosch at intra2net.com Wed Feb 22 16:10:51 2017 From: thomas.jarosch at intra2net.com (Thomas Jarosch) Date: Wed, 22 Feb 2017 16:10:51 +0100 Subject: Announcing paperbackup.py to backup keys as QR codes on paper In-Reply-To: References: <9664399.F7pj19RVc2@thunder.m.i2n> <1635365.VMeaqTAsHE@thunder.m.i2n> Message-ID: <2550076.1cMusrXu2u@storm.m.i2n> Hi Peter, On Wednesday, 22 February 2017 13:56:22 CET Peter Lebbing wrote: > Oh, as an aside, the advantage of paperkey is that it is > self-describing. I've tried paperkey with Gnupg 2.1.13 and it had trouble parsing the secret key data. May be the internal packet format changed or needs adaption. When I think about long term storage, I'd rather rely on the full data instead of a snippet of the openpgp packets. The argument about re-downloading the public key from the keyservers is valid though, but for the secret key a full backup is preferred in our use case. It's easy for the user to skip the public key backup. Also if the QR code scanning ever fails: There is base64 encoded text output at the end, too. That could be OCRed or typed in by hand if ever needed. (we use paperbackup.py just as additional backup) You can even use paperbackup.py to back up your ssh key :) Cheers, Thomas From deg at davidegray.com Wed Feb 22 02:03:19 2017 From: deg at davidegray.com (David Gray) Date: Tue, 21 Feb 2017 20:03:19 -0500 Subject: Problems with cert validation via CRL In-Reply-To: <1c850be7-426c-599e-90dc-0932a178ea1c@digitalbrains.com> References: <000001d28b80$62b3a1e0$281ae5a0$@davidegray.com> <87lgt0p92p.fsf@iwagami.gniibe.org> <87CF4606-FE26-4376-8799-7674F956D602@davidegray.com> <1c850be7-426c-599e-90dc-0932a178ea1c@digitalbrains.com> Message-ID: <004401d28ca7$75e402f0$61ac08d0$@davidegray.com> You were correct, Peter. I haven't had a chance to verify on Ubuntu yet, but on Windows the following steps did the trick: - there was no 'trusted-certs' directory in my existing home directory (C:\users\dave\appdata\Roaming\gnupg\), so I created one. I also went ahead and created a 'logs' directory. - I added the line "log-file C:\Users\dave\AppData\Roaming\gnupg\logs\dirmngrlog.txt" to my dirmngr.conf file to capture what I wanted - I saved a copy of the root cert with fingerprint 02FAF3E291435468607857694DF5E45B68851868 to a DER-encoded file with .crt extension to the 'trusted-certs' directory. - I executed the 'gpgsm --list-keys --with-validation --debug-all' command, and all keys were shown to be good. I've attached the debug output from the command as well as the dirmngrlog.txt file that was generated in case it is of interest. (As an aside, you may notice that I've installed version 2.1.18 since the last output was provided). I don't fully understand everything that is shown in these files, but it sure seems to me like you were exactly right - dirmngr did not know to trust that root cert, so it couldn't verify that the CRL was signed by a trustworthy party. Once I told dirmngr that the root cert could be trusted, it could verify the CRL. I've since been able to encrypt data using this key, so things are looking good. I can't thank you enough - this has been extremely helpful. Thanks! Dave -----Original Message----- From: Peter Lebbing [mailto:peter at digitalbrains.com] Sent: Tuesday, February 21, 2017 10:13 AM To: David Gray ; NIIBE Yutaka Cc: gnupg-users at gnupg.org Subject: Re: Problems with cert validation via CRL On 21/02/17 13:20, David Gray wrote: > I'm no expert, but when I look at the debug info (attached to original > email), it appears that gpgsm is able to get the crl that my cert > points to but it may be having trouble parsing it. Reading that part made me think it couldn't find the issuer of the CRL: > dirmngr[3184.0]: error fetching certificate by subject: Configuration > error > dirmngr[3184.0]: CRL issuer certificate > {92616B82E1A2A0AA4FEC67F1C2A3F7B48000C1EC} not found When I fetch the CRL we're talking about, OpenSSL tells me about it: > Certificate Revocation List (CRL): > Version 2 (0x1) > Signature Algorithm: sha256WithRSAEncryption > Issuer: /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA > Limited/CN=COMODO SHA-256 Client Authentication and Secure Email CA > Last Update: Feb 20 16:07:34 2017 GMT > Next Update: Feb 24 16:07:34 2017 GMT > CRL extensions: > X509v3 Authority Key Identifier: > > keyid:92:61:6B:82:E1:A2:A0:AA:4F:EC:67:F1:C2:A3:F7:B4:80:00:C1:EC > > X509v3 CRL Number: > 822 The issuer is the certificate that gpgsm knows about: > Certificate: > Data: > Version: 3 (0x2) > Serial Number: > e0:23:cb:15:12:83:53:89:ad:61:6e:7a:54:67:6b:21 > Signature Algorithm: sha256WithRSAEncryption > Issuer: C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, > CN=AddTrust External CA Root > Validity > Not Before: Dec 22 00:00:00 2014 GMT > Not After : May 30 10:48:38 2020 GMT > Subject: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA > Limited, CN=COMODO SHA-256 Client Authentication and Secure Email CA [...] > X509v3 extensions: > X509v3 Authority Key Identifier: > > keyid:AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A > > X509v3 Subject Key Identifier: > > 92:61:6B:82:E1:A2:A0:AA:4F:EC:67:F1:C2:A3:F7:B4:80:00:C1:EC > [...] > SHA1 > Fingerprint=59:B8:25:FC:08:86:0B:04:B3:92:CC:25:FE:C4:8C:76:07:53:B6:8 > 9 I suspect that even though gpgsm knows about it, dirmngr might not, hence the failing CRL verification. I think you need to feed the certificate to dirmngr as well. Whether this is actually the reason you're having problems, I don't know. 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 -------------- An embedded and charset-unspecified text was scrubbed... Name: windows-listkeys-withvalidation-02212017-success.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dirmngrlog.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4803 bytes Desc: not available URL: From peter at digitalbrains.com Wed Feb 22 20:23:26 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 22 Feb 2017 20:23:26 +0100 Subject: Announcing paperbackup.py to backup keys as QR codes on paper In-Reply-To: <2550076.1cMusrXu2u@storm.m.i2n> References: <9664399.F7pj19RVc2@thunder.m.i2n> <1635365.VMeaqTAsHE@thunder.m.i2n> <2550076.1cMusrXu2u@storm.m.i2n> Message-ID: On 22/02/17 16:10, Thomas Jarosch wrote: > When I think about long term storage, I'd rather rely on the full data > instead of a snippet of the openpgp packets. I understand that. However, let me point out that any errors parsing will only occur while *creating* a backup with paperkey. Once it succesfully parses the data, the result can be used without the program, it is stand-alone and complete. No further "parsing errors" can occur. Rejoining the private key can be done by hand. Could you share a bit more details about the error you encountered? If it is a problem with paperkey, I think we (as a community) would like to know about it and hopefully fix it. > The argument about re-downloading the public key from the keyservers is valid > though, but for the secret key a full backup is preferred in our use case. All public data can be scattered all over the world and the internet, and backed up and replicated in all manner of forms for resiliency. In theory this goes for a private key with a good passphrase as well, but that moves the point of failure to remembering the passphrase. paperkey however can be used without a passphrase, and the result should be guarded really well, unlike all the public data. I'm not trying to convince you to do something differently than you do now, I'm just trying to make the picture more complete. However, it seems your solution to your use case depends on there being few signatures on a key, as evidenced by my key needing 104 pages (that's without the unnecessary duplication that resulted in the 208 pages I mentioned earlier). I would not enjoy the amount of room this book occupies in my safe, or scanning it. > It's easy for the user to skip the public key backup. Hmmmmm....... once we have export-minimal for --export-secret-key :-). > Also if the QR code scanning ever fails: There is base64 encoded text output > at the end, too. That could be OCRed or typed in by hand if ever needed. > (we use paperbackup.py just as additional backup) You might consider using a font designed for OCR rather than the current font. Additionally, base64 has look-alike characters, and the only checksum is for the whole key. So if it says "checksum failed" you've only learned that factoid. A checksum per line would be better, so you can say "checksum failed in line n". > You can even use paperbackup.py to back up your ssh key :) Yep. But if you trust GnuPG, and you have a paper backup of your OpenPGP key, you could encrypt a copy of your SSH key with your OpenPGP key and publish the encrypted file. Then as long as you have a paper backup of your OpenPGP encryption subkey, you can just fetch and decrypt the SSH key. This by the way goes for any piece of data, no matter how large, including all the videos you shot of your children while they grew up and would really dread to lose. Just encrypt them, back them up with several backup providers online, and as long as your paper backup of your OpenPGP key survives, so do the videos. It might even provide that little extra motivation to be extra sure the backup of your OpenPGP key can be depended on, now that you really do depend on it for something you care deeply about! ;-D 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 Wed Feb 22 20:34:22 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 22 Feb 2017 20:34:22 +0100 Subject: Announcing paperbackup.py to backup keys as QR codes on paper In-Reply-To: <2550076.1cMusrXu2u@storm.m.i2n> References: <9664399.F7pj19RVc2@thunder.m.i2n> <1635365.VMeaqTAsHE@thunder.m.i2n> <2550076.1cMusrXu2u@storm.m.i2n> Message-ID: <815e7fac-c04d-cb92-7ff2-744d307177b4@digitalbrains.com> On 22/02/17 16:10, Thomas Jarosch wrote: > May be the internal packet format changed or needs adaption. It is not an internal packet format by the way, it is defined in RFC 4880 (OpenPGP Message Format). And all GnuPG versions output their keys formatted according to OpenPGP, so the problem you're experiencing is more subtle. 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 antony at blazrsoft.com Wed Feb 22 20:51:22 2017 From: antony at blazrsoft.com (antony at blazrsoft.com) Date: Wed, 22 Feb 2017 14:51:22 -0500 Subject: Announcing paperbackup.py to backup keys as QR codes on paper In-Reply-To: <9664399.F7pj19RVc2@thunder.m.i2n> References: <9664399.F7pj19RVc2@thunder.m.i2n> Message-ID: <864EE0C3-2BDE-471E-B0C9-EC0B1D9E2AB3@blazrsoft.com> On February 21, 2017 9:34:17 AM EST, "Gerd v. Egidy" wrote: >Hi, > >I'd like to announce a program I wrote to backup GnuPG and SSH keys as >qrcodes on paper: > >paperbackup.py >https://github.com/intra2net/paperbackup > Just wanted to say thanks for sharing your work. As for paperkey, I have an RSA 4096 bit key. Without paperkey, the output for my key was around 23-24 pages. With paperkey (using base64 output), the output was around 19 pages, so the benefit was minimal. Also, the first time I tried, the decode process kept failing on one barcode from the output pdf, but I re-encoded it and tried again and the decode process verified correctly. The ability of zbar to process the images directly from the pdf was impressive IMO. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 854 bytes Desc: not available URL: From dkg at fifthhorseman.net Wed Feb 22 23:48:27 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 22 Feb 2017 17:48:27 -0500 Subject: export-minimal doesn't affect export-secret-key? In-Reply-To: <680160cc-58e7-4f03-1624-e3a642791d75@digitalbrains.com> References: <680160cc-58e7-4f03-1624-e3a642791d75@digitalbrains.com> Message-ID: <87h93l970k.fsf@alice.fifthhorseman.net> On Wed 2017-02-22 08:12:31 -0500, Peter Lebbing wrote: > I just found out that the following two commands are equivalent: > >> $ gpg2 -o full.gpg --export-secret-keys ac46efe6de500b3e >> $ gpg2 -o minimal.gpg --export-options export-minimal --export-secret-keys ac46efe6de500b3e I just confirmed this. I've put it in the bugtracker so it doesn't get lost: https://bugs.gnupg.org/gnupg/issue2973 Thanks for reporting it, Peter. --dkg From gerd.von.egidy at intra2net.com Thu Feb 23 11:00:54 2017 From: gerd.von.egidy at intra2net.com (Gerd v. Egidy) Date: Thu, 23 Feb 2017 11:00:54 +0100 Subject: Announcing paperbackup.py to backup keys as QR codes on paper In-Reply-To: References: <9664399.F7pj19RVc2@thunder.m.i2n> <1635365.VMeaqTAsHE@thunder.m.i2n> Message-ID: <7556571.gQyiDygHL8@thunder.m.i2n> Hi Peter, > The certificate (aka public key) includes all signatures, all the data > on the keyserver. It's data you don't really need to back up since it is > public, and it can be huge. My key.asc file is 137,424 bytes following > your instructions. Seems you are trusted by much more people than me ;) > $ gpg2 --armour --output key.asc --export-options export-minimal > --export-secret-key [KEYID] Thank you for your explanation and recommendation. I have adapted the readme on github. > However, I'm running into a little problem here myself... GnuPG 2.1.18 > does not respect the "export-minimal" option for --export-secret-key, > only for --export. So if you are using GnuPG 2.1, this will not work as > intended. > > This is in all likelihood a bug in GnuPG 2.1, and I'll report it right now. Thank you for checking and reporting this. As it will not leave out important information, just add more data that is not strictly needed, it won't hurt the affected users much. Just a few more dead trees... > Oh, as an aside, the advantage of paperkey is that it is > self-describing. No matter what happens, as long as we can still use > hexadecimal digits to describe binary content (which would be trivial to > reimplement), we can reconstruct the binary private key file. Using QR > codes has the disadvantage that if you cannot find a QR-code decoder for > your platform in the future, reimplementing one is far from trivial. You > are dependent on QR codes surviving as an actually supported data format. What timespan are we talking about? If we are talking decades, I have no doubts that some qrcode decoder will still be available, even if qrcodes aren't used anymore. There are several open source decoders available and included in linux distributions. Stuff like that tends to be available for a long time: you can still download packaged linux distros like Red Hat Linux 1.0 (released 1995) or Debian 0.91 (released 1994) today, about 23 years afterwards. If we are talking centuries, I'd worry about the availability of gnupg as much as qrcodes. Both are publicly available standards, but I don't know if they are still available and understandable by then. I'd recommend going to plaintext on glass etched microfiche if you really want to cover that timespan. > Finally, I remember something about QR codes inherently supporting > splitting data over multiple individual code blocks, specifically for > data that is too large to fit in a single block. I don't know if it > supports the number of blocks you need, but you might want to check it > out. I know of that feature and have deliberately decided against it: Not all decoders are capable of it, and if one qrcode is missing, the linking is broken and you have to patch the decoder to still get some data. I consider the plaintext linking and ordering I used more robust, see https://github.com/intra2net/paperbackup#encoding-and-data-format > Also, you say large QR codes are easily damaged by wrinkles and > deformations. Is this perhaps related to the amount of error correction > data included? You can tune the ratio of content data to error > correction data, making a QR code more resilient to damage. I used the largest error correction ratio possible. > However, if > you find that it is not unreadable individual pixels but rather the > deformation of the total that is throwing off decoders, than I suppose > the ratio doesn't help: it either can reduce it to the required square > or it cannot, I'd think. I haven't studied the decoding algorithms at that level of detail. If the deformation is irregular, I guess it affects some parts of a code more than others. Then a higher error correction ration will help. Kind regards, Gerd From gerd.von.egidy at intra2net.com Thu Feb 23 11:06:47 2017 From: gerd.von.egidy at intra2net.com (Gerd v. Egidy) Date: Thu, 23 Feb 2017 11:06:47 +0100 Subject: Announcing paperbackup.py to backup keys as QR codes on paper In-Reply-To: <1cbc2772-0d28-0b9b-dbe6-7b5792628225@sixdemonbag.org> References: <9664399.F7pj19RVc2@thunder.m.i2n> <1cbc2772-0d28-0b9b-dbe6-7b5792628225@sixdemonbag.org> Message-ID: <1640856.M2KsOuFQEH@thunder.m.i2n> > I'm a little > surprised that your code is as large as it is, too: using an alternate > pipeline you might be able to significantly reduce code size. > > (a) use Python 3's gpg module to export the secret key > (b) paperkey --output-type raw --secret-key key.gpg --output key.raw I want paperbackup.py to be independent and agnostic of gnupg. It should also be usable for e.g. ssh keys or ciphertext. > (c) use Python 3's QR library to create a series of PNGs > (d) use Wand or PythonMagick to convert the PNGs to PDF > (e) save the PDF and you're done I had some problems creating proper multipage pdfs, so I used PyX. If you can come up with shorter sourcecode or less dependencies, I'm happy to take patches. Kind regards, Gerd From thomas.jarosch at intra2net.com Thu Feb 23 09:54:12 2017 From: thomas.jarosch at intra2net.com (Thomas Jarosch) Date: Thu, 23 Feb 2017 09:54:12 +0100 Subject: Announcing paperbackup.py to backup keys as QR codes on paper In-Reply-To: <87vas27xwy.fsf@alice.fifthhorseman.net> References: <9664399.F7pj19RVc2@thunder.m.i2n> <2550076.1cMusrXu2u@storm.m.i2n> <87vas27xwy.fsf@alice.fifthhorseman.net> Message-ID: <1915776.UAOep1tI2n@storm.m.i2n> Hi Daniel, On Wednesday, 22 February 2017 15:50:21 CET Daniel Kahn Gillmor wrote: > On Wed 2017-02-22 10:10:51 -0500, Thomas Jarosch wrote: > > I've tried paperkey with Gnupg 2.1.13 and it had trouble parsing the > > secret > > key data. May be the internal packet format changed or needs adaption. > > Can you replicate this problem with a dummy/throwaway key? If so, can > you report this problem explicitly please? I don't know how David Shaw > wants bug reports upstream, but sending mail to the debian BTS would > also be fine. If you do that, you'd mail to "submit at bugs.debian.org" > with a reasonable subject about what's going wrong, and the first two > lines of your mail would be something like: In the interest of humanity and the cause of science, I've just tried again with a throwaway key :) This time it worked just fine. The "only" thing that's changed is that I've upgraded from Fedora 22 to Fedora 25 since I last tried. Let's consider this matter solved. Cheers, Thomas From gerd.von.egidy at intra2net.com Thu Feb 23 13:36:53 2017 From: gerd.von.egidy at intra2net.com (Gerd v. Egidy) Date: Thu, 23 Feb 2017 13:36:53 +0100 Subject: Announcing paperbackup.py to backup keys as QR codes on paper In-Reply-To: References: <9664399.F7pj19RVc2@thunder.m.i2n> <2550076.1cMusrXu2u@storm.m.i2n> Message-ID: <1499394.yZ8kfsQv5G@thunder.m.i2n> > You might consider using a font designed for OCR rather than the current > font. I tried to change to OCR-B or Inconsolata http://stackoverflow.com/questions/316068/what-is-the-ideal-font-for-ocr but getting that to work with enscript is not easy, as you have to find and install afm and pfb into the correct directories. This goes a lot deeper than just installing packages provided by whatever disto you are using. So I think that this would move the bar for a possible user of paperbackup.py higher than I want to. > Additionally, base64 has look-alike characters, and the only checksum is > for the whole key. So if it says "checksum failed" you've only learned > that factoid. A checksum per line would be better, so you can say > "checksum failed in line n". Can you recommend a tool to create a short checksum (crc32?) for each line? Ideally it is a tool or combination of tools already deployed widely, like sed and sort I used in paperrestore. This would make the checksums still usable even when the source to paperbackup.py isn't available anymore. Kind regards, Gerd From deg at davidegray.com Thu Feb 23 03:12:42 2017 From: deg at davidegray.com (David Gray) Date: Wed, 22 Feb 2017 21:12:42 -0500 Subject: Problems with cert validation via CRL In-Reply-To: <87wpcjq7l1.fsf@iwagami.gniibe.org> References: <000001d28b80$62b3a1e0$281ae5a0$@davidegray.com> <87wpcjq7l1.fsf@iwagami.gniibe.org> Message-ID: Thanks very much for getting back to me - I really appreciate your help. I have been able to get the validation to work by adding the trusted root certificate to the "trusted-certs" folder under the gnupg directory on my windows box. The directory wasn't there but I was able to add it and as long as the cert is there dirmngr knows that it can trust the CRL that has been issued. I haven't had a chance to circle back on my Linux installation, but I'm sure the same approach will work. I'm also not sure how/why the Linux installation was originally able to validate the cert, but I will dig into that. Thanks again for your help - it's very much appreciated! Sent from my Mobile Device > On Feb 21, 2017, at 9:31 PM, NIIBE Yutaka wrote: > > Hello, again, > > David Gray wrote: >> dave at dave-VirtualBox:~/.gnupg/crls.d$ dirmngr --debug-all --fetch-crl http://crl.comodoca.com/COMODOSHA256ClientAuthenticationandSecureEmailCA.crl > > Reading the code of dirmngr, I think that --fetch-crl (or dirmngr-client > --load-crl) doesn't work well for a CRL which is not signed by system CA > directly. When dirmngr doesn't know the issuer, it inquires back to the > client, and it fails as: > >> dirmngr[3184.0]: DBG: find_cert_bysubject: certificate not returned by caller - doing lookup >> dirmngr[3184.0]: error fetching certificate by subject: Configuration error >> dirmngr[3184.0]: CRL issuer certificate {92616B82E1A2A0AA4FEC67F1C2A3F7B48000C1EC} not found >> dirmngr[3184.0]: crl_parse_insert failed: Missing certificate > > When it is gpgsm which asks dirmngr to validate a certificate, I think > it works. > > I think that you once successfully did that on this box: > >> dave at dave-VirtualBox:~/.gnupg/crls.d$ gpgsm --debug-all --list-keys --with-validation > > And the CRL is cached. Thus, > >> gpgsm: DBG: chan_6 -> ISVALID 685A02B9E2BD4B5EE1FA51739B8882AEA38FB3C8.3FAADAD7DD3F946B114321153B76F88C > > This is gpgsm asking if your X.509 client certificate is valid or not. > >> gpgsm: DBG: chan_6 <- INQUIRE ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868 > > Here, I think that the CRL for your X.509 client certificate is cached > and checked. dirmngr does not ask about anything about your X.509 > client certificate or its issuer. > > dirmngr inquires back to gpgsm if the root issuer is trusted. > > CN=AddTrust External CA Root,OU=AddTrust External TTP Network,O=AddTrust AB,C=SE > fingerprint=02FAF3E291435468607857694DF5E45B68851868 > > then, gpgsm asks to gpg-agent. > >> gpgsm: DBG: chan_7 -> ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868 >> gpgsm: DBG: chan_7 <- S TRUSTLISTFLAG relax >> gpgsm: DBG: chan_7 <- OK > > It is trusted. Then, gpgsm replies back to dirmngr. > >> gpgsm: DBG: chan_6 -> D 1 >> gpgsm: DBG: chan_6 -> END > > It's trusted. > >> gpgsm: DBG: chan_6 <- OK > > Then, dirmngr answers OK for the validation of your X.509 client certificate. > >> gpgsm: DBG: chan_6 -> ISVALID 14673DA5792E145E9FA1425F9EF3BFC1C4B4957C.00E023CB1512835389AD616E7A54676B21 > > This is gpgsm asking if the intermediate certificate of following is > valid or not: > > CN=COMODO SHA-256 Client Authentication and Secure Email CA,O=COMODO CA Limited, > L=Salford, ST=Greater Manchester, C=GB > fingerprint=59B825FC08860B04B392CC25FEC48C760753B689 > >> gpgsm: DBG: chan_6 <- INQUIRE ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868 >> gpgsm: DBG: chan_7 -> ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868 >> gpgsm: DBG: chan_7 <- S TRUSTLISTFLAG relax >> gpgsm: DBG: chan_7 <- OK >> gpgsm: DBG: chan_6 -> D 1 >> gpgsm: DBG: chan_6 -> END >> gpgsm: DBG: chan_6 <- OK > > Similar interactions between gpg-agent<->gpgsm<->dirmngr. > >> gpgsm: DBG: chan_7 -> ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868 >> gpgsm: DBG: chan_7 <- S TRUSTLISTFLAG relax >> gpgsm: DBG: chan_7 <- OK > > I don't know the exact reason, but gpgsm again asks gpg-agent. > > And gpgsm shows your X.509 client certificate: > >> ID: 0x2F5900E9 >> S/N: 3FAADAD7DD3F946B114321153B76F88C >> Issuer: /CN=COMODO SHA-256 Client Authentication and Secure Email CA/O=COMODO CA Limited/L=Salford/ST=Greater Manchester/C=GB >> Subject: /EMail=user at domain.com >> aka: user at domain.com >> validity: 2017-01-02 00:00:00 through 2018-01-02 23:59:59 >> key type: 2048 bit RSA >> key usage: digitalSignature keyEncipherment >> ext key usage: emailProtection (suggested), 1.3.6.1.4.1.6449.1.3.5.2 (suggested) >> policies: 1.3.6.1.4.1.6449.1.2.1.1.1:N: >> fingerprint: 4A:53:A9:E6:51:32:23:DF:B4:7D:B8:A3:19:F1:3E:A3:2F:59:00:E9 >> [Note: non-critical certificate policy not allowed] >> [Note: non-critical certificate policy not allowed] >> [validation model used: shell] >> [certificate is good] > > On the other hand, on your Windows... > >> C:\Users\dave\Downloads>gpgsm --list-keys --with-validation --debug-all > [...] >> gpgsm: DBG: chan_0x000001c0 -> ISVALID 14673DA5792E145E9FA1425F9EF3BFC1C4B4957C.00E023CB1512835389AD616E7A54676B21 >> gpgsm: DBG: chan_0x000001c0 <- INQUIRE ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868 > [...] >> gpgsm: DBG: chan_0x000001e8 -> ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868 >> gpgsm: DBG: chan_0x000001e8 <- S TRUSTLISTFLAG relax >> gpgsm: DBG: chan_0x000001e8 <- OK >> gpgsm: DBG: chan_0x000001c0 -> D 1 >> gpgsm: DBG: chan_0x000001c0 -> END >> gpgsm: DBG: chan_0x000001c0 <- OK >> gpgsm: DBG: chan_0x000001e8 -> ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868 >> gpgsm: DBG: chan_0x000001e8 <- S TRUSTLISTFLAG relax >> gpgsm: DBG: chan_0x000001e8 <- OK > [...] >> gpgsm: DBG: chan_0x000001e8 -> ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868 >> gpgsm: DBG: chan_0x000001e8 <- S TRUSTLISTFLAG relax >> gpgsm: DBG: chan_0x000001e8 <- OK > [...] >> gpgsm: DBG: chan_0x000001c0 -> ISVALID 685A02B9E2BD4B5EE1FA51739B8882AEA38FB3C8.3FAADAD7DD3F946B114321153B76F88C >> gpgsm: DBG: chan_0x000001c0 <- INQUIRE SENDCERT >> gpgsm: DBG: chan_000001C0 -> [ 44 20 30 82 05 3b 30 82 04 23 a0 03 02 01 02 02 ...(982 byte(s) skipped) ] >> gpgsm: DBG: chan_000001C0 -> [ 44 20 74 69 6f 6e 61 6e 64 53 65 63 75 72 65 45 ...(361 byte(s) skipped) ] >> gpgsm: DBG: chan_0x000001c0 -> END > > Here, gpgsm asking if your X.509 client certificate is valid or not. > And then, dirmngr inquires back to gpgsm about the certificate. > > Then gpgsm sends it to dirmngr. > >> gpgsm: DBG: chan_0x000001c0 <- INQUIRE ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868 >> gpgsm: DBG: chan_0x000001e8 -> ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868 >> gpgsm: DBG: chan_0x000001e8 <- S TRUSTLISTFLAG relax >> gpgsm: DBG: chan_0x000001e8 <- OK >> gpgsm: DBG: chan_0x000001c0 -> D 1 >> gpgsm: DBG: chan_0x000001c0 -> END > > And then, dirmngr inquires back to gpgsm if the root issuer is trusted. > > CN=AddTrust External CA Root,OU=AddTrust External TTP Network,O=AddTrust AB,C=SE > fingerprint=02FAF3E291435468607857694DF5E45B68851868 > > then, gpgsm asks to gpg-agent. It is trusted. Then, gpgsm replies back to dirmngr. > >> gpgsm: DBG: chan_0x000001c0 <- ERR 167772255 No CRL known > > But, dirmngr says no CRL known for your X.509 client certificate. > > I don't know what's going on here. You can enable debug option of > dirmngr (debug-level, log-file, debug-all) in your dirmngr.conf. > > > [...] >> gpgsm: DBG: chan_0x000001c0 -> ISVALID 14673DA5792E145E9FA1425F9EF3BFC1C4B4957C.00E023CB1512835389AD616E7A54676B21 >> gpgsm: DBG: chan_0x000001c0 <- INQUIRE ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868 >> gpgsm: DBG: chan_0x000001e8 -> ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868 >> gpgsm: DBG: chan_0x000001e8 <- S TRUSTLISTFLAG relax >> gpgsm: DBG: chan_0x000001e8 <- OK >> gpgsm: DBG: chan_0x000001c0 -> D 1 >> gpgsm: DBG: chan_0x000001c0 -> END >> gpgsm: DBG: chan_0x000001c0 <- OK >> gpgsm: DBG: chan_0x000001e8 -> ISTRUSTED 02FAF3E291435468607857694DF5E45B68851868 >> gpgsm: DBG: chan_0x000001e8 <- S TRUSTLISTFLAG relax >> gpgsm: DBG: chan_0x000001e8 <- OK > > This is the interaction for the intermediate certificate. Nothing wrong here. > >> ID: 0x2F5900E9 >> S/N: 3FAADAD7DD3F946B114321153B76F88C >> Issuer: /CN=COMODO SHA-256 Client Authentication and Secure Email CA/O=COMODO CA Limited/L=Salford/ST=Greater Manchester/C=GB >> Subject: /EMail=user at domain.com >> aka: user at domain.com >> validity: 2017-01-02 00:00:00 through 2018-01-02 23:59:59 >> key type: 2048 bit RSA >> key usage: digitalSignature keyEncipherment >> ext key usage: emailProtection (suggested), 1.3.6.1.4.1.6449.1.3.5.2 (suggested) >> policies: 1.3.6.1.4.1.6449.1.2.1.1.1:N: >> fingerprint: 4A:53:A9:E6:51:32:23:DF:B4:7D:B8:A3:19:F1:3E:A3:2F:59:00:E9 >> [Note: non-critical certificate policy not allowed] >> [no CRL found for certificate] >> [Note: non-critical certificate policy not allowed] >> [validation model used: shell] >> [certificate is bad: No CRL known] > > You can check your X.509 client certificate by > > $ gpgsm --verbose --dump-cert 0x2F5900E9 > > to see its CRL or more information. > -- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2368 bytes Desc: not available URL: From ndk.clanbo at gmail.com Thu Feb 23 18:25:32 2017 From: ndk.clanbo at gmail.com (NdK) Date: Thu, 23 Feb 2017 18:25:32 +0100 Subject: Announcing paperbackup.py to backup keys as QR codes on paper In-Reply-To: <7556571.gQyiDygHL8@thunder.m.i2n> References: <9664399.F7pj19RVc2@thunder.m.i2n> <1635365.VMeaqTAsHE@thunder.m.i2n> <7556571.gQyiDygHL8@thunder.m.i2n> Message-ID: <125c6cca-a4b3-f08d-cfd5-2a7c85145b3d@gmail.com> Il 23/02/2017 11:00, Gerd v. Egidy ha scritto: > If we are talking centuries, I'd worry about the availability of gnupg as much > as qrcodes. Both are publicly available standards, but I don't know if they > are still available and understandable by then. I'd recommend going to > plaintext on glass etched microfiche if you really want to cover that > timespan. Well, when considering such a timespan there could be other (bigger) issues... How long a today 'secure' key will remain secure? When will quantum computers be widely available? The only "guaranteed" crypto is information-theoretic one (neural networks mutual learning, distant noisy sources, etc), where adversary's probability of success is a function of the system parameters. But it's quite impractical and AFAIK covers only interactive key agreement. PS: in 100 years surely I won't (be here to) care if someone will be able to read my mails or not :) BYtE, Diego From sivmu at web.de Thu Feb 23 19:24:02 2017 From: sivmu at web.de (sivmu at web.de) Date: Thu, 23 Feb 2017 19:24:02 +0100 Subject: SHA1 collision found Message-ID: Today was announced that SHA1 is now completely broken https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html A few weeks back it was mentioned that there is a new proposal for a openpgp standart including a new algorithm for pgp fingerprints. As this is currently not applicable in practice, I would like to know what this new development means for pgp-gnupg and the use of SHA1 for key identification. After researching how the fingerprint is generated, I think it would be easy to include a new option in gnupg to print a fingerprint using sha256. Would that be something that will/can be included in future versions of gnupg? That way users could publish both the sha1 and sha256 finderprint in the future. From peter at digitalbrains.com Thu Feb 23 19:48:13 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 23 Feb 2017 19:48:13 +0100 Subject: SHA1 collision found In-Reply-To: References: Message-ID: <16f1edbf-9b5c-d5ef-3c5c-0624c852fb56@digitalbrains.com> On 23/02/17 19:24, sivmu at web.de wrote: > As this is currently not applicable in practice, I would like to know > what this new development means for pgp-gnupg and the use of SHA1 for > key identification. I already answered that here[1]. The use of SHA-1 in fingerprints is not susceptible to a collision attack, so it's still safe. SHA-1 in fingerprints is only susceptible to a second-preimage attack which is much harder than a collision attack and unheard of for SHA-1. > After researching how the fingerprint is generated, I think it would > be easy to include a new option in gnupg to print a fingerprint using > sha256. Would that be something that will/can be included in future > versions of gnupg? It wouldn't help because of all the places SHA-1 is used internally if you just change how it is displayed to the user. Disclaimer: I'm not a developer, but this is my understanding of it. I can't say for sure. HTH, Peter. [1] -- 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 rjh at sixdemonbag.org Thu Feb 23 19:58:06 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 23 Feb 2017 13:58:06 -0500 Subject: SHA1 collision found In-Reply-To: References: Message-ID: <0adf01d28e06$c51150c0$4f33f240$@sixdemonbag.org> > Today was announced that SHA1 is now completely broken > https://security.googleblog.com/2017/02/announcing-first-sha1- > collision.html SHA-1 is broken *for some purposes*. That's scary enough, trust me. Let's not overstate things. For the last ten years I've been saying, "The smoke alarm has gone off and we think there's a fire. There's no danger to anyone right now, but we need to move to the exits in an orderly fashion. Start migrating away from SHA-1 right now, so that when the collisions happen you've already been using SHA256 for years." Today we've seen the fire. It's not surprising. We knew this was coming, we just didn't know when. If you're still using SHA-1, you probably need to begin migrating *right now* before the fire gets worse. If you don't know how, ask on this list and we'll help you. But don't panic: we can help. A question for the list: should we put a "Migrating to SHA256" section in the FAQ? From sivmu at web.de Thu Feb 23 20:26:37 2017 From: sivmu at web.de (sivmu at web.de) Date: Thu, 23 Feb 2017 20:26:37 +0100 Subject: SHA1 collision found Message-ID: Am 23.02.2017 um 19:48 schrieb Peter Lebbing: > On 23/02/17 19:24, sivmu at web.de wrote: >> After researching how the fingerprint is generated, I think it would >> be easy to include a new option in gnupg to print a fingerprint using >> sha256. Would that be something that will/can be included in future >> versions of gnupg? > > It wouldn't help because of all the places SHA-1 is used internally if > you just change how it is displayed to the user. Disclaimer: I'm not a > developer, but this is my understanding of it. I can't say for sure. > I would rather see this as a means to manually check the key to enable users to potentially discover fake keys. Since I did not find a simple way to generate the fingerprint and identifying the key contents to be hashed seems really tricky, putting an additional option in gnupg to generate a longer fingerprint seems like the easiest solution. Having an option like --fingerprint would allow users to use any hash they want until a new openpgp standard is published. This is not something that needs to be used by default, just something that can be used by those who look for it. After looking into second-preimage attacks the issue does not seem to be that critical though. Still it would be a nice feature and if I did not misunderstand the how the fingerprint is generated it could be implemented by adding very little code. From dkg at fifthhorseman.net Thu Feb 23 20:40:51 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 23 Feb 2017 14:40:51 -0500 Subject: Announcing paperbackup.py to backup keys as QR codes on paper In-Reply-To: <1915776.UAOep1tI2n@storm.m.i2n> References: <9664399.F7pj19RVc2@thunder.m.i2n> <2550076.1cMusrXu2u@storm.m.i2n> <87vas27xwy.fsf@alice.fifthhorseman.net> <1915776.UAOep1tI2n@storm.m.i2n> Message-ID: <87zihclmpo.fsf@alice.fifthhorseman.net> On Thu 2017-02-23 03:54:12 -0500, Thomas Jarosch wrote: > In the interest of humanity and the cause of science, I've just tried again > with a throwaway key :) This time it worked just fine. The "only" thing that's > changed is that I've upgraded from Fedora 22 to Fedora 25 since I last tried. humanity and science thank you for your efforts :) happy hacking, --dkg From rjh at sixdemonbag.org Thu Feb 23 21:00:05 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 23 Feb 2017 15:00:05 -0500 Subject: SHA1 collision found In-Reply-To: <16f1edbf-9b5c-d5ef-3c5c-0624c852fb56@digitalbrains.com> References: <16f1edbf-9b5c-d5ef-3c5c-0624c852fb56@digitalbrains.com> Message-ID: <0b2601d28e0f$6dad4010$4907c030$@sixdemonbag.org> (I originally sent this off-list by mistake. Peter was kind enough to respond off-list and to suggest we take it back on-list. This email is a distillation of three different emails: my original, Peter's response, and a response to Peter.) ===== > I already answered that here[1]. The use of SHA-1 in fingerprints is > not susceptible to a collision attack, so it's still safe. SHA-1 in > fingerprints is only susceptible to a second-preimage attack which is > much harder than a collision attack and unheard of for SHA-1. To which I said, "Create two keys with the same fingerprint. Sign a contract with one, then renege on the deal. When you get called into court, say "I never signed that, Your Honor!" and present the second key. This collision pretty much shatters the nonrepudiability of SHA-1 signatures." To which Peter quite reasonably answered that the other person has a copy of the public key which was used to sign the document originally. Why should the fraudster's denial be believed? The answer is that to enforce a contract (at least here in the United States) you must be able to prove, based on a preponderance of the evidence, that the other person entered into a contract with you. So imagine this conversation: PLAINTIFF: "Your Honor, the defendant reneged on a $10,000 contract. Make him pay up." DEFENDANT: "I never signed anything, Your Honor." PLAINTIFF: "I have his key, it's right here." DEFENDANT: "That's not my key. This is my key." PLAINTIFF: "Of course that's what he claims! They have the same SHA-1 fingerprint! He did that in order to deny his signature!" JUDGE: "So these keys are uniquely identified by the fingerprint?" (both parties agree) JUDGE: "And you have two keys that are identified by the same fingerprint?" (both parties agree) JUDGE: "And there's no way to tell which key is real?" (both parties agree) JUDGE: "Then we're stuck. There's no reason to prefer one key over another. Plaintiff, you have failed your burden of proof in establishing the defendant signed the contract." Now, you could establish proof some other way: let's say you made a videotape of the defendant signing the document. If you could introduce other supporting evidence (which might include other signatures on keys) you might be able to convince the judge the signature is enforceable. But there's nothing intrinsic to the signature itself which could convince the judge. So Peter is completely right to say "but there's no reason to believe one person over the other." Completely, absolutely right. But the person asking the court to enforce a contract must present a reason to believe them over the defendant. I hope this clarifies my answer! (Peter also rightly remarked that he thought nonrepudiability in OpenPGP was kind of iffy anyway. He and I are in complete agreement on this. OpenPGP has always had very iffy nonrepudiability. With this SHA-1 attack, I feel the threshold has been crossed and we need to consider it repudiable.) From vedaal at nym.hush.com Thu Feb 23 20:09:59 2017 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Thu, 23 Feb 2017 14:09:59 -0500 Subject: SHA1 collision found In-Reply-To: Message-ID: <20170223191000.2CD7FE0163@smtp.hushmail.com> On 2/23/2017 at 1:27 PM, sivmu at web.de wrote:Today was announced that SHA1 is now completely broken https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html A few weeks back it was mentioned that there is a new proposal for a openpgp standart including a new algorithm for pgp fingerprints. As this is currently not applicable in practice, I would like to know what this new development means for pgp-gnupg and the use of SHA1 for key identification. After researching how the fingerprint is generated, I think it would be easy to include a new option in gnupg to print a fingerprint using sha256. Would that be something that will/can be included in future versions of gnupg ===== The Openpgp standards group is working on this. The link you give for the collision used 2 PDF's. Using a PDF is sort-of 'cheating', and does not extrapolate to being 'completely broken'. Assuming that it is possible to find a pre-image collision, i.e: [1] m1.txt 1 has an SHA1 hash of H1 [2] m2.txt will now have the same SHA1 hash H1 What will happen to in order to generate m2.txt is that there will be many trials of a gibberrish string added to the plaintext of m2.txt until one is found that has the same SHA1 hash as m1.txt BUT This will be quite visible in the plaintext of m2.txt, and won't fool anyone. With a PDF, the 'extra gibberish string' is 'hidden'. It is not in the actual PDF the receiver reads, only in the meta-data, the appended PDF 'Suffix'. While this is *do-able* and a good reason to move on to a future SHA256 hash, it would not be transferable (at this time, based on the PDF collision data), to find a fingerprint collision for any v4 key. vedaal -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Thu Feb 23 20:47:05 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 23 Feb 2017 14:47:05 -0500 Subject: OpenPGP third-party certifications do not imply trust [was: Re: Announcing paperbackup.py to backup keys as QR codes on paper] In-Reply-To: <7556571.gQyiDygHL8@thunder.m.i2n> References: <9664399.F7pj19RVc2@thunder.m.i2n> <1635365.VMeaqTAsHE@thunder.m.i2n> <7556571.gQyiDygHL8@thunder.m.i2n> Message-ID: <87wpcglmfa.fsf@alice.fifthhorseman.net> [ not on-topic for this thread, hence the subject change ] On Thu 2017-02-23 05:00:54 -0500, Gerd v. Egidy wrote: >> The certificate (aka public key) includes all signatures, all the data >> on the keyserver. It's data you don't really need to back up since it is >> public, and it can be huge. My key.asc file is 137,424 bytes following >> your instructions. > > Seems you are trusted by much more people than me ;) I'm calling this out because it's a common misconception, and i don't want it to lie here unchallenged when someone is browsing the archives. The people who "sign your key" (who have created an OpenPGP certification that binds your primary key to your User ID) are only identifying you and your key. They have said nothing about "trust" by making those certifications. For example, I am happy to certify the identity and key of someone who i do not trust at all, as long as i know who they are and they've asserted their key to me in-person, or across some reliable, non-forgeable transport. So the fact that Alice has a dozen certifications on her key and Bob has two doesn't mean that Alice is trusted by more people than Bob at all. It just means that more people have been willing to publicly assert that they know Alice's identity and key than have been willing to publicly assert the same information about Bob. --dkg From sivmu at web.de Thu Feb 23 22:50:44 2017 From: sivmu at web.de (sivmu at web.de) Date: Thu, 23 Feb 2017 22:50:44 +0100 Subject: SHA1 collision found Message-ID: Am 23.02.2017 um 20:09 schrieb vedaal at nym.hush.com: > The Openpgp standards group is working on this. Yes but who know how many years it will take until a new standard is accepted... > > The link you give for the collision used 2 PDF's. > Using a PDF is sort-of 'cheating', and does not extrapolate to being > 'completely broken'. > > Assuming that it is possible to find a pre-image collision, i.e: > > [1] m1.txt 1 has an SHA1 hash of H1 > [2] m2.txt will now have the same SHA1 hash H1 > > What will happen to in order to generate m2.txt is that there will be > many trials of a gibberrish string added to the plaintext of m2.txt > until one is found that has the same SHA1 hash as m1.txt > BUT > This will be quite visible in the plaintext of m2.txt, and won't fool > anyone. > > With a PDF, the 'extra gibberish string' is 'hidden'. It is not in the > actual PDF the receiver reads, only in the meta-data, the appended PDF > 'Suffix'. Not sure about you but I am not able to see the difference between a valid pgp key and "gibberish" ;) > > While this is *do-able* and a good reason to move on to a future > SHA256 hash, it would not be transferable (at this time, based on the > PDF collision data), to find a fingerprint collision for any v4 key. > vedaal The question is how many tries it takes until a colliding key is found that is accepted by common pgp implementations when imported, is it not? As said, if it is as easy as i think it is, providing an option for different hash algos to generate fingerprints would be a nice solution until a new standard is established. From leo at gaspard.io Thu Feb 23 23:38:36 2017 From: leo at gaspard.io (Leo Gaspard) Date: Thu, 23 Feb 2017 23:38:36 +0100 Subject: SHA1 collision found In-Reply-To: <0b2601d28e0f$6dad4010$4907c030$@sixdemonbag.org> References: <16f1edbf-9b5c-d5ef-3c5c-0624c852fb56@digitalbrains.com> <0b2601d28e0f$6dad4010$4907c030$@sixdemonbag.org> Message-ID: On 02/23/2017 09:00 PM, Robert J. Hansen wrote: > [...] > > To which I said, "Create two keys with the same fingerprint. Sign a contract with one, then renege on the deal. When you get called into court, say "I never signed that, Your Honor!" and present the second key. This collision pretty much shatters the nonrepudiability of SHA-1 signatures." > > To which Peter quite reasonably answered that the other person has a copy of the public key which was used to sign the document originally. Why should the fraudster's denial be believed? > > The answer is that to enforce a contract (at least here in the United States) you must be able to prove, based on a preponderance of the evidence, that the other person entered into a contract with you. So imagine this conversation: > > PLAINTIFF: "Your Honor, the defendant reneged on a $10,000 contract. Make him pay up." > DEFENDANT: "I never signed anything, Your Honor." > PLAINTIFF: "I have his key, it's right here." > DEFENDANT: "That's not my key. This is my key." > PLAINTIFF: "Of course that's what he claims! They have the same SHA-1 fingerprint! He did that in order to deny his signature!" > JUDGE: "So these keys are uniquely identified by the fingerprint?" > (both parties agree) > JUDGE: "And you have two keys that are identified by the same fingerprint?" > (both parties agree) > JUDGE: "And there's no way to tell which key is real?" > (both parties agree) > JUDGE: "Then we're stuck. There's no reason to prefer one key over another. Plaintiff, you have failed your burden of proof in establishing the defendant signed the contract." I'd like to respectfully disagree on this point. SHA1 is currently vulnerable only to collision attacks, which means that in order to have two keys with the same fingerprint they both have to be created by the same person (up to a random collision). Thus the defendant. And this is enough to prove that he did sign the contract with the key he claims he doesn't own. Is there any flaw in this logic? > [...] -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From calestyo at scientia.net Fri Feb 24 00:39:17 2017 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Fri, 24 Feb 2017 00:39:17 +0100 Subject: SHA1 collision found In-Reply-To: <0adf01d28e06$c51150c0$4f33f240$@sixdemonbag.org> References: <0adf01d28e06$c51150c0$4f33f240$@sixdemonbag.org> Message-ID: <1487893157.18251.2.camel@scientia.net> On Thu, 2017-02-23 at 13:58 -0500, Robert J. Hansen wrote: > > "Migrating to SHA256" > section in > the FAQ? What I always kinda wonder is, why crypto or security experts, at least in some sense never seem to learn. When MD5 got it's first scratches, some people started to demanded for it's ASAP retirement (which didn't happen... partially also with arguments that it's not yet broken for these and that purposes in practise)... in the end people waited so long until it was in a way already too late. Remember the forged MD5 based X509 cert? And this was made by some "good guys" god know how many actual attacks may have been driven by much stronger organisations where people actually were harmed in the end. SHA1 may have been phased out (more or less) in the X.509 world, but it's still pretty present in many other places. It's known to having issues for some years and for the same number of years many experts still defended it as not being broken for these and that use cases... And now were again in the situation that it's still used in production (probably for years to come), and we have at least a collision. That may not be the one big fire alert where everything burns down... but it should be really a ringing bell... Now every time when new algos come up or e.g. when ideas for the next OpenPGP version is started,.. a big bunch of experts seem to go for the most conservative way possible. And I'm not talking about the good conservatism (i.e. using algos based on long standing and well understood math)... but rather things like let's better not use SHA512 or SHA3 when we could also just use SHA256... let's better not specify large curves when we can go by a much smaller one. And every time the same argument is brought up, that these would be still way enough to take hundreds of years to be cracked... but so far (as with SHA1) it was always broken much earlier. The last time when I followed discussion about the next OpenPGP it seemed people rather wanted to hard-wire only a few algos for everything, which would be just the same problem as with SHA1,... instead all algos should be pretty easily exchangeable. So when the same happens for the next OpenPGP version just with SHA256 I'll bet that we face the same problems with SHA256 far earlier than everyone wishes. Not to talk about the more and more realistic threat posed by quantum computers. IMO we should rather go for the stronger algos, or even combine algos when this makes sense because their underlying math is different that breaking one would still not directly affect the other. And we should rather make any crypto algo as easily exchangeable as possible. Cheers, Chris. From rjh at sixdemonbag.org Fri Feb 24 03:49:46 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 23 Feb 2017 21:49:46 -0500 Subject: SHA1 collision found In-Reply-To: <1487893157.18251.2.camel@scientia.net> References: <0adf01d28e06$c51150c0$4f33f240$@sixdemonbag.org> <1487893157.18251.2.camel@scientia.net> Message-ID: > What I always kinda wonder is, why crypto or security experts, at least > in some sense never seem to learn. You kidding me? MD5 hashes are still the standard tool of computer forensics. It's appalling. The reasons why are fascinating, though: it's largely for judicial reasons, not technical ones. It took a lot of work to get courts to accept MD5 as a hash algorithm, but now it's the judicially-approved standard. So if you're a forensics nerd who talks about how we need to migrate to SHA256, you can expect every prosecutor to roll their eyes and say, "not this thing again!" If you say that MD5 is no longer trusted as a hash, suddenly they get downright panicked. "Hush! Do you want every previous case in which we used MD5 to certify evidence hadn't been tampered with to come into question?" From peter at digitalbrains.com Fri Feb 24 11:32:33 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 24 Feb 2017 11:32:33 +0100 Subject: Announcing paperbackup.py to backup keys as QR codes on paper In-Reply-To: <7556571.gQyiDygHL8@thunder.m.i2n> References: <9664399.F7pj19RVc2@thunder.m.i2n> <1635365.VMeaqTAsHE@thunder.m.i2n> <7556571.gQyiDygHL8@thunder.m.i2n> Message-ID: <326870a5-6b7e-e9d8-c50e-b3632cf27b8d@digitalbrains.com> On 23/02/17 11:00, Gerd v. Egidy wrote: > Seems you are trusted by much more people than me ;) More people trust that that key is mine, they don't trust me as a person, my actions or my certifications. dkg already answered that bit :-). These are mostly people I've met at a keysigning party. They have seen my passport and asserted that "Peter Lebbing" is as far as they can tell indeed the person in possession of that key. They don't trust me more than the next guy, because they don't know me personally. > If we are talking centuries, I'd worry about the availability of gnupg as much > as qrcodes. If there is still software that can work with OpenPGP v4 keys, then you can restore your private key from your paperkey-style backup. If there is no more software that can work with OpenPGP v4 keys, what are you going to do with your restored private key? Frame it and put it on the wall? ;-) > Not all decoders are capable of it, and if one qrcode is missing, the linking > is broken and you have to patch the decoder to still get some data. Understood. Good to see you've thought it through. > I used the largest error correction ratio possible. Given the size of those QR codes on paper, you could use a camera that is so elderly it has developed presbyopia and cataract and still scan them succesfully! :-D 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 kloecker at kde.org Fri Feb 24 11:47:35 2017 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Fri, 24 Feb 2017 11:47:35 +0100 Subject: SHA1 collision found In-Reply-To: References: <0b2601d28e0f$6dad4010$4907c030$@sixdemonbag.org> Message-ID: <1543025.k6ihMGmn7g@collossus.ingo-kloecker.de> On Thursday 23 February 2017 23:38:36 Leo Gaspard wrote: > On 02/23/2017 09:00 PM, Robert J. Hansen wrote: > > [...] > > > > To which I said, "Create two keys with the same fingerprint. Sign a > > contract with one, then renege on the deal. When you get called > > into court, say "I never signed that, Your Honor!" and present the > > second key. This collision pretty much shatters the > > nonrepudiability of SHA-1 signatures." > > > > To which Peter quite reasonably answered that the other person has a > > copy of the public key which was used to sign the document > > originally. Why should the fraudster's denial be believed? > > > > The answer is that to enforce a contract (at least here in the > > United States) you must be able to prove, based on a preponderance > > of the evidence, that the other person entered into a contract with > > you. So imagine this conversation: > > > > PLAINTIFF: "Your Honor, the defendant reneged on a $10,000 contract. > > Make him pay up." DEFENDANT: "I never signed anything, Your > > Honor." > > PLAINTIFF: "I have his key, it's right here." > > DEFENDANT: "That's not my key. This is my key." > > PLAINTIFF: "Of course that's what he claims! They have the same > > SHA-1 fingerprint! He did that in order to deny his signature!" > > JUDGE: "So these keys are uniquely identified by the fingerprint?" > > (both parties agree) > > JUDGE: "And you have two keys that are identified by the same > > fingerprint?" (both parties agree) > > JUDGE: "And there's no way to tell which key is real?" > > (both parties agree) > > JUDGE: "Then we're stuck. There's no reason to prefer one key over > > another. Plaintiff, you have failed your burden of proof in > > establishing the defendant signed the contract." > I'd like to respectfully disagree on this point. SHA1 is currently > vulnerable only to collision attacks, which means that in order to > have two keys with the same fingerprint they both have to be created > by the same person (up to a random collision). Thus the defendant. > And this is enough to prove that he did sign the contract with the > key he claims he doesn't own. > > Is there any flaw in this logic? The second key the defendant created won't have his name as user id. Moreover, after creating this second key he will have disposed of the private key (and after uploading the public key to a keyserver probably also of the public key), so that there's no proof that he was ever in possession of this key. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From vedaal at nym.hush.com Fri Feb 24 16:15:23 2017 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Fri, 24 Feb 2017 10:15:23 -0500 Subject: SHA1 collision found In-Reply-To: Message-ID: <20170224151523.B27CFE05F7@smtp.hushmail.com> On 2/23/2017 at 4:52 PM, sivmu at web.de wrote:... Not sure about you but I am not able to see the difference between a valid pgp key and "gibberish" ;) ... ===== In the example of the 2 pdf's, they started with one pdf, made another pdf, then multiple (more than billions) trials of adding a string to the second pdf so that it hashes to the first. With regard to generating a new key that hashes to a known specific key, the forger must do 2 things simultaneously; [1] generating new key material [2] seeing that the hashed fingerprint of the new key matches that of the first key The forger does not start with a newly generated key and add material so that the hash would match the first key (the case of the pdf's). If that were the case, then the key system would be broken now for the SHA1 hash. Even for v3 keys, which were not SHA1 hashed, the only way to generate a new key with the same fingerprint, would be to allow the key size to vary (usually to a bizarre key size that would be quite suspect, and not believed). Now, for a V4 key with an SHA1 hash, and a further restriction that the forged key size be the same as the first key, this is not known to be doable day, even with the google cloud computer sharing efforts, and the breakthrough of finding pdf's with the same hash. Again, I fully support moving to a secure hash, but I do think that users have more than enough time until the open-pgp group issues the official standard. vedaal -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at digitalbrains.com Fri Feb 24 17:17:01 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 24 Feb 2017 17:17:01 +0100 Subject: Announcing paperbackup.py to backup keys as QR codes on paper In-Reply-To: <1499394.yZ8kfsQv5G@thunder.m.i2n> References: <9664399.F7pj19RVc2@thunder.m.i2n> <2550076.1cMusrXu2u@storm.m.i2n> <1499394.yZ8kfsQv5G@thunder.m.i2n> Message-ID: On 23/02/17 13:36, Gerd v. Egidy wrote: > So I think that this would move the bar for a possible user of paperbackup.py > higher than I want to. Yes, it should be easy to use. In fact, I've sometimes heard the complaint that "paperkey is not easy to install and/or use". That's really too bad that those people feel that way. > Ideally it is a tool or combination of tools already deployed widely, like sed > and sort I used in paperrestore. This would make the checksums still usable > even when the source to paperbackup.py isn't available anymore. It took me some fiddling... but using CRC RevEng[1] I got a checksum in Python that is compatible to POSIX cksum. The following Python: >>> from posixcksum import PosixCkSum >>> from base64 import b64encode >>> crc, _ = PosixCkSum.sum_whole(bytearray(b'123456789')) >>> b64encode(crc.to_bytes(4,byteorder='big'))[:4] b'N3pg' generates the same checksums as the following Bash code: $ printf $(printf '%08x' $(echo -n 123456789 | cksum | cut -d' ' -f1) | sed 's/../\\x\0/g')|base64|cut -b-4 N3pg This is done with the attached Python code. It is written for compactness rather than speed. Just re-implementing the crc function would probably be quicker. HTH, Peter. [1] -- 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: posixcksum.py Type: text/x-python Size: 3560 bytes Desc: not available URL: -------------- 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 Fri Feb 24 17:21:38 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 24 Feb 2017 17:21:38 +0100 Subject: Announcing paperbackup.py to backup keys as QR codes on paper In-Reply-To: References: <9664399.F7pj19RVc2@thunder.m.i2n> <2550076.1cMusrXu2u@storm.m.i2n> <1499394.yZ8kfsQv5G@thunder.m.i2n> Message-ID: <6198707d-0b7a-0428-56a4-8ddc6e340ba1@digitalbrains.com> Crap, silly me... why do I always notice these things only after I've hit send? On 24/02/17 17:17, Peter Lebbing wrote: > The following Python: > >>>> from posixcksum import PosixCkSum >>>> from base64 import b64encode >>>> crc, _ = PosixCkSum.sum_whole(bytearray(b'123456789')) >>>> b64encode(crc.to_bytes(4,byteorder='big'))[:4] > b'N3pg' Let's make that: >>> from posixcksum import PosixCkSum >>> from base64 import b64encode >>> crc, _ = PosixCkSum.sum_whole(bytearray(b'123456789')) >>> print(b64encode(crc.to_bytes(4,byteorder='big'))[:6]) b'N3pgEQ' > $ printf $(printf '%08x' $(echo -n 123456789 | cksum | cut -d' ' -f1) | sed 's/../\\x\0/g')|base64|cut -b-4 > N3pg And this one: $ printf $(printf '%08x' $(echo -n 123456789 | cksum | cut -d' ' -f1) | sed 's/../\\x\0/g')|base64|cut -b-6 N3pgEQ Oh, and by the way, when the python module is invoked as the main module, it mimics the working of cksum, so the following two are roughly equivalent: $ cksum *.c $ posixcksum.py *.c 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 melvincarvalho at gmail.com Fri Feb 24 16:43:37 2017 From: melvincarvalho at gmail.com (Melvin Carvalho) Date: Fri, 24 Feb 2017 16:43:37 +0100 Subject: SHA1 collision found In-Reply-To: References: Message-ID: On 23 February 2017 at 19:24, wrote: > Today was announced that SHA1 is now completely broken > https://security.googleblog.com/2017/02/announcing-first- > sha1-collision.html This is nonsense. Google security team calling sha1 "completely broken" simply means google's security team is completely broken. Fearmongering like this unhelpful to the open source community. GPG is sound because you can only find a collision which is no big deal and we knew already, but you cannot compromise a hash. This simply wastes everyone's time. > > > A few weeks back it was mentioned that there is a new proposal for a > openpgp standart including a new algorithm for pgp fingerprints. > As this is currently not applicable in practice, I would like to know what > this new development means for pgp-gnupg and the use of SHA1 for key > identification. > > After researching how the fingerprint is generated, I think it would be > easy to include a new option in gnupg to print a fingerprint using sha256. > Would that be something that will/can be included in future versions of > gnupg? > > That way users could publish both the sha1 and sha256 finderprint in the > future. > > _______________________________________________ > 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 glenn at rempe.us Fri Feb 24 19:26:14 2017 From: glenn at rempe.us (Glenn Rempe) Date: Fri, 24 Feb 2017 10:26:14 -0800 Subject: SHA1 collision found In-Reply-To: References: Message-ID: <21ad8d04-98a6-415b-b7c4-60663766feda@Spark> If you read the announcement Google never uses the words "completely broken" that you attribute to them. I believe that was someone else's characterization. Mis-attribution and name calling can also be unhelpful. Google's security team has been the driving force behind two major security issues this week alone (SHA1 and Cloudflare) and with SHA1 they made concrete something that was only theoretical before. Let's give credit where credit is due. On Feb 24, 2017, 09:27 -0800, Melvin Carvalho , wrote: > > > On 23 February 2017 at 19:24, wrote: > > Today was announced that SHA1 is now completely broken > > https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html > > This is nonsense. > > Google security team calling sha1 "completely broken" simply means google's security team is completely broken. > > Fearmongering like this unhelpful to the open source community. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnupg-users at spodhuis.org Fri Feb 24 18:37:34 2017 From: gnupg-users at spodhuis.org (Phil Pennock) Date: Fri, 24 Feb 2017 12:37:34 -0500 Subject: Real-world current impact of disabling SHA1 Message-ID: <20170224173733.GA10344@breadbox.private.spodhuis.org> There are various claims going around about how GnuPG should be disabling SHA1 now; the competent cryptographers I know are pointing out that a collision is not a second pre-image, don't panic and cargo-cult (but also yes it's time and past time to be making sure we have a clear path away). I'm not a cryptographer. I do like to have hard facts to base decisions on when I can. This email is to summarize the current practical reality of trying to move away; I took a copy of my ~/.gnupg directory, pointed the `GNUPGHOME` environment variable to that copy, and set `weak-digest SHA1` in the `gpg.conf` in that is used, then invoked `gpg --update-trustdb`. % gpg --version gpg (GnuPG) 2.1.18 libgcrypt 1.7.6 pubring.kbx is 195 MiB. There are a few secret keys in this keyring, including some expired but with signatures out expanding the trust set; the primary key is MSD ranking 6544 in the strong-set. So in a "normal" world, I can verify trust-paths to a lot of keys and I would expect a lot of verifiable keys. The _only_ difference in `gpg.conf` is the `weak-digest SHA1` setting. -------------------------8< weak-digest SHA1 >8------------------------- gpg: Note: signatures using the SHA1 algorithm are rejected gpg: marginals needed: 3 completes needed: 1 trust model: pgp gpg: Note: signatures using the MD5 algorithm are rejected gpg: depth: 0 valid: 4 signed: 16 trust: 0-, 0q, 0n, 0m, 0f, 4u gpg: depth: 1 valid: 16 signed: 9 trust: 0-, 3q, 1n, 7m, 5f, 0u gpg: depth: 2 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 1f, 0u gpg: next trustdb check due at 2017-03-12 gpg2.1 --update-trustdb 3831.13s user 8877.51s system 99% cpu 3:31:49.39 total -------------------------8< weak-digest SHA1 >8------------------------- ----------------------8< normal, SHA1 not weak >8----------------------- gpg: Note: signatures using the MD5 algorithm are rejected gpg: depth: 0 valid: 4 signed: 78 trust: 0-, 0q, 0n, 0m, 0f, 4u gpg: depth: 1 valid: 78 signed: 576 trust: 0-, 29q, 2n, 27m, 20f, 0u gpg: depth: 2 valid: 303 signed: 1478 trust: 0-, 173q, 2n, 90m, 38f, 0u gpg: depth: 3 valid: 788 signed: 1445 trust: 0-, 479q, 3n, 270m, 36f, 0u gpg: depth: 4 valid: 442 signed: 927 trust: 0-, 320q, 6n, 96m, 20f, 0u gpg: next trustdb check due at 2017-02-25 gpg2.1 --update-trustdb 595.94s user 125.16s system 99% cpu 12:01.38 total ----------------------8< normal, SHA1 not weak >8----------------------- For those interested in the time-discrepancies: this is a 3.13.0-110-generic kernel for Ubuntu on an Atom computer which is a few years old; /proc/cpuinfo reports two cores, as: Intel(R) Atom(TM) CPU D2500 @ 1.86GHz Summary: * Normally, I have 1611 valid non-ultimate keys in my keyring * This drops to 17 keys without trusting SHA1 * So I get to keep trust-paths to just over 1% of my keyring; I lose trust-paths to 98.9% of my trusted links * Disabling SHA1 today utterly breaks the current web-of-trust * We're going to need to spend _years_ re-issuing signatures with a newer hash algorithm before we can safely disable SHA1 without totally destroying WoT (unless a crypto break does appear and we have to disable it for the other kind of safety) Also: * Something about disabling SHA1 does nasty things to GnuPG's performance, as scanning two more depth levels takes 12 minutes instead of 222 minutes for just two depth levels Regards, -Phil -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 996 bytes Desc: Digital signature URL: From clime at redhat.com Sat Feb 25 13:16:23 2017 From: clime at redhat.com (Michal Novotny) Date: Sat, 25 Feb 2017 13:16:23 +0100 Subject: file size change after trustdb recovery In-Reply-To: References: Message-ID: Where I mentioned "otrust.gpg" in the description, that should have been otrust.txt. I am very sorry for that. Michal Novotny On Sat, Feb 25, 2017 at 1:14 PM, Michal Novotny wrote: > Hello, > > I have got a trustdb that gives the following output on --check-trustdb: > > gpg: public key of ultimately trusted key 3ADE2987ABBFDB66 not found > gpg: public key of ultimately trusted key 831FE43EDDD16F3D not found > gpg: marginals needed: 3 completes needed: 1 trust model: pgp > gpg: depth: 0 valid: 6468 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 6468u > gpg: next trustdb check due at 2021-01-18 > > There are two public keys that are not found in public keyring (nor secret > keyring actually) but there is a record for them in the trustdb. I have a > vague idea how this could have happened, however what I would like to get > is a trustdb without the two records. > > For that, I > > - called gpg2 --export-ownertrust > otrust.txt > - manually removed the two records for which there is no public key > - moved current trustdb.gpg to trustdb.gpg.bak > - and finally called gpg2 --import-ownertrust < otrust.gpg > > The output of --check-trustdb with the new db is now okay: > > gpg: marginals needed: 3 completes needed: 1 trust model: pgp > gpg: depth: 0 valid: 6466 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 6466u > gpg: next trustdb check due at 2021-01-18 > > However what bugs me slightly is that trustdb.gpg is now of much smaller > size. Before it was: 908K, now it is 554K. > > There is pretty much the same size decrease if I do not remove the records > for missing public keys and just do: > > - called gpg2 --export-ownertrust > otrust.txt > - move current trustdb.gpg to trustdb.gpg.bak > - and finally call gpg2 --import-ownertrust < otrust.gpg. > > The output of --check-trustdb is now: > > gpg: public key of ultimately trusted key 3ADE2987ABBFDB66 not found > gpg: public key of ultimately trusted key 831FE43EDDD16F3D not found > gpg: marginals needed: 3 completes needed: 1 trust model: pgp > gpg: depth: 0 valid: 6468 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 6468u > gpg: next trustdb check due at 2021-01-18 > > Again, the new trustdb.gpg has 554K, while the original had 908K. And also > what is curious is that the new file had 301K before calling > --check-trustdb and 554K after. > > Anyway, it seems the original trustdb is not fully restored after > --export-ownertrust and --import-ownertrust even though the output of > --check-trustdb gives the same output for the original and new file (6468 > valid ultimately trusted keys). > > I know this is a bit complicated description but could anyone explain > what's going on with the changes in the trustdb.gpg file size? > > Thank you > Michal Novotny > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clime at redhat.com Sat Feb 25 13:23:39 2017 From: clime at redhat.com (Michal Novotny) Date: Sat, 25 Feb 2017 13:23:39 +0100 Subject: file size change in trustdb.gpg after recovery Message-ID: Hello, I have got a trustdb that gives the following output on --check-trustdb: gpg: public key of ultimately trusted key 3ADE2987ABBFDB66 not found gpg: public key of ultimately trusted key 831FE43EDDD16F3D not found gpg: marginals needed: 3 completes needed: 1 trust model: pgp gpg: depth: 0 valid: 6468 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 6468u gpg: next trustdb check due at 2021-01-18 There are two public keys that are not found in public keyring (nor secret keyring actually) but there is a record for them in the trustdb. I have a vague idea how this could have happened, however what I would like to get is a trustdb without the two records. For that, I - called gpg2 --export-ownertrust > otrust.txt - manually removed the two records in otrust.txt for which there is no public key - moved current trustdb.gpg to trustdb.gpg.bak - and finally called gpg2 --import-ownertrust < otrust.txt The output of --check-trustdb with the new db is now okay: gpg: marginals needed: 3 completes needed: 1 trust model: pgp gpg: depth: 0 valid: 6466 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 6466u gpg: next trustdb check due at 2021-01-18 However what bugs me slightly is that trustdb.gpg is now of much smaller size. Before it was: 908K, now it is 554K. There is pretty much the same size decrease if I do not remove the records for missing public keys and just do: - called gpg2 --export-ownertrust > otrust.txt - move current trustdb.gpg to trustdb.gpg.bak - and finally call gpg2 --import-ownertrust < otrust.txt The output of --check-trustdb is now: gpg: public key of ultimately trusted key 3ADE2987ABBFDB66 not found gpg: public key of ultimately trusted key 831FE43EDDD16F3D not found gpg: marginals needed: 3 completes needed: 1 trust model: pgp gpg: depth: 0 valid: 6468 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 6468u gpg: next trustdb check due at 2021-01-18 Again, the new trustdb.gpg has 554K, while the original had 908K. And also what is curious is that the new file had 301K before calling --check-trustdb and 554K after. Anyway, it seems the original trustdb is not fully restored after --export-ownertrust and --import-ownertrust even though the output of --check-trustdb gives the same output for the original and new file (6468 valid ultimately trusted keys). I know this is a bit complicated description but could anyone explain what's going on with the changes in the trustdb.gpg file size? Thank you Michal Novotny -------------- next part -------------- An HTML attachment was scrubbed... URL: From clime at redhat.com Sat Feb 25 13:14:17 2017 From: clime at redhat.com (Michal Novotny) Date: Sat, 25 Feb 2017 13:14:17 +0100 Subject: file size change after trustdb recovery Message-ID: Hello, I have got a trustdb that gives the following output on --check-trustdb: gpg: public key of ultimately trusted key 3ADE2987ABBFDB66 not found gpg: public key of ultimately trusted key 831FE43EDDD16F3D not found gpg: marginals needed: 3 completes needed: 1 trust model: pgp gpg: depth: 0 valid: 6468 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 6468u gpg: next trustdb check due at 2021-01-18 There are two public keys that are not found in public keyring (nor secret keyring actually) but there is a record for them in the trustdb. I have a vague idea how this could have happened, however what I would like to get is a trustdb without the two records. For that, I - called gpg2 --export-ownertrust > otrust.txt - manually removed the two records for which there is no public key - moved current trustdb.gpg to trustdb.gpg.bak - and finally called gpg2 --import-ownertrust < otrust.gpg The output of --check-trustdb with the new db is now okay: gpg: marginals needed: 3 completes needed: 1 trust model: pgp gpg: depth: 0 valid: 6466 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 6466u gpg: next trustdb check due at 2021-01-18 However what bugs me slightly is that trustdb.gpg is now of much smaller size. Before it was: 908K, now it is 554K. There is pretty much the same size decrease if I do not remove the records for missing public keys and just do: - called gpg2 --export-ownertrust > otrust.txt - move current trustdb.gpg to trustdb.gpg.bak - and finally call gpg2 --import-ownertrust < otrust.gpg. The output of --check-trustdb is now: gpg: public key of ultimately trusted key 3ADE2987ABBFDB66 not found gpg: public key of ultimately trusted key 831FE43EDDD16F3D not found gpg: marginals needed: 3 completes needed: 1 trust model: pgp gpg: depth: 0 valid: 6468 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 6468u gpg: next trustdb check due at 2021-01-18 Again, the new trustdb.gpg has 554K, while the original had 908K. And also what is curious is that the new file had 301K before calling --check-trustdb and 554K after. Anyway, it seems the original trustdb is not fully restored after --export-ownertrust and --import-ownertrust even though the output of --check-trustdb gives the same output for the original and new file (6468 valid ultimately trusted keys). I know this is a bit complicated description but could anyone explain what's going on with the changes in the trustdb.gpg file size? Thank you Michal Novotny -------------- next part -------------- An HTML attachment was scrubbed... URL: From 2014-667rhzu3dc-lists-groups at riseup.net Sat Feb 25 15:09:20 2017 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sat, 25 Feb 2017 14:09:20 +0000 Subject: SHA1 collision found In-Reply-To: <20170224151523.B27CFE05F7@smtp.hushmail.com> References: <20170224151523.B27CFE05F7@smtp.hushmail.com> Message-ID: <159793783.20170225140920@riseup.net> Hi On Friday 24 February 2017 at 3:15:23 PM, in , vedaal at nym.hush.com wrote:- > Even for v3 keys, which were not SHA1 hashed, the > only way to > generate a new key with the same fingerprint, would > be to allow the > key size to vary (usually to a bizarre key size that > would be quite suspect, and not believed). Is that why the majority of keys are exactly 1024, 2048, etc. bits, or is there a technical reason? -- Best regards MFPA War is a matter of vital importance to the State. From peter at digitalbrains.com Sat Feb 25 16:26:34 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 25 Feb 2017 16:26:34 +0100 Subject: export-minimal doesn't affect export-secret-key? In-Reply-To: <87h93l970k.fsf@alice.fifthhorseman.net> References: <680160cc-58e7-4f03-1624-e3a642791d75@digitalbrains.com> <87h93l970k.fsf@alice.fifthhorseman.net> Message-ID: <58ac102c-e77b-2f32-dbcc-222138022350@digitalbrains.com> On 22/02/17 23:48, Daniel Kahn Gillmor wrote: > I just confirmed this. I've put it in the bugtracker so it doesn't get > lost: > > https://bugs.gnupg.org/gnupg/issue2973 Thanks! I'd like to add to the bug report that I also observe this behaviour with GnuPG 1.4.18 on Debian jessie/stable (package 1.4.18-7+deb8u3) and GnuPG 2.0.26 on the same (package 2.0.26-6+deb8u1). So it is not just 2.1. However, I think I can't actually add that to the bug report myself because I only just created an account on bugs.gnupg.org :-). 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 dkg at fifthhorseman.net Sat Feb 25 20:08:10 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 25 Feb 2017 14:08:10 -0500 Subject: Real-world current impact of disabling SHA1 In-Reply-To: <20170224173733.GA10344@breadbox.private.spodhuis.org> References: <20170224173733.GA10344@breadbox.private.spodhuis.org> Message-ID: <8760jyum05.fsf@alice.fifthhorseman.net> On Fri 2017-02-24 12:37:34 -0500, Phil Pennock wrote: > There are various claims going around about how GnuPG should be > disabling SHA1 now; [ ... ] To be fair, we should have been *deprecating* SHA1 many years ago (since Wang et al in 2005). we're late. if we'd been deprecating it for years it would be easier to consider disabling it now. > This email is to summarize the current practical reality of trying > to move away; Thanks for doing this, it's good to have concrete datapoints. fwiw, i ran with --weak-digest SHA1 for several months back when we introduced --weak-digest to see how it would work for me. It turned out to be a rough user experience, because there were enough tools out there that were still generating things with SHA1 :/ I just ran some similar tests myself with GnuPG 2.1.18 (libgcrypt 1.7.6-beta) on a keyring with 3402 OpenPGP certificates. In preparation, i did the following in an empty directory on a tmpfs (if everything is RAM-backed i don't have to worry that i'm confounding measurements with with disk I/O performance): gpg --export > keys-to-import.txt gpg --export-ownertrust > ownertrust.txt mkdir -m 0700 normal without-sha1 echo weak-digest SHA1 > without-sha1/gpg.conf Then i ran my comparison tests, like so: for GNUPGHOME in normal without-sha1; do export GNUPGHOME printf "=====%s=====\n" "$GNUPGHOME" time gpg --quiet --batch --import < keys-to-import.gpg time gpg --quiet --batch --import-ownertrust < ownertrust.txt time gpg --batch --check-trustdb time gpg --with-colons --list-keys | grep -c ^pub: done Full output is at the end of this e-mail. Phil wrote: > * Normally, I have 1611 valid non-ultimate keys in my keyring > * This drops to 17 keys without trusting SHA1 > * So I get to keep trust-paths to just over 1% of my keyring; I lose > trust-paths to 98.9% of my trusted links > * Disabling SHA1 today utterly breaks the current web-of-trust > * We're going to need to spend _years_ re-issuing signatures with a > newer hash algorithm before we can safely disable SHA1 without > totally destroying WoT (unless a crypto break does appear and we have > to disable it for the other kind of safety) A little more than half of the certificates in my test keyring had no self-sigs with anything other than SHA1. Since GnuPG discards certs with no valid self-sig at import time, the without-sha1 keyring is significantly smaller. Still, i went from 123 valid certificates to 89 valid certificates when i dropped SHA1. I suspect that the self-sig issue is the main concern -- *not* links between keys. People can fix their self-sigs just by re-signing their own keys. it's also possible that debian developers are disproportionately overrepresented in my keyring, and this is a group of folks who have been actively migrating away from SHA1 already, which would explain why my results aren't quite as terrible as Phil's are. > * Something about disabling SHA1 does nasty things to GnuPG's > performance, as scanning two more depth levels takes 12 minutes > instead of 222 minutes for just two depth levels For m, the timing for each stage of the test is comparable for what we'd expect, given the sizes of the different keyrings -- so the timing is significantly faster for the SHA1-less keyring, not the other way around. i don't see any evidence that the workflow i used shows any performance degradation when used with --weak-digest sha1. The difference between my test and Phil's test is that i've done a clean import, so the keyring i'm working with is already pruned. i wonder if the performance penalty comes from gpg discovering keys that it considers invalid already in the keyring. If so, it'd be nice to find a way to fix this performance problem. At the very least, Regards, --dkg Here's the results from my own tests: ---------------------------------------- =====normal===== gpg: Note: signatures using the MD5 algorithm are rejected real 3m48.197s user 0m46.316s sys 3m0.476s gpg: inserting ownertrust of 128 gpg: inserting ownertrust of 3 gpg: inserting ownertrust of 6 gpg: inserting ownertrust of 128 gpg: inserting ownertrust of 128 gpg: inserting ownertrust of 128 gpg: inserting ownertrust of 3 gpg: inserting ownertrust of 3 gpg: inserting ownertrust of 128 gpg: inserting ownertrust of 3 gpg: inserting ownertrust of 2 real 0m0.003s user 0m0.000s sys 0m0.004s gpg: marginals needed: 3 completes needed: 1 trust model: pgp gpg: Note: signatures using the MD5 algorithm are rejected gpg: depth: 0 valid: 1 signed: 123 trust: 0-, 0q, 0n, 0m, 0f, 1u gpg: depth: 1 valid: 123 signed: 577 trust: 122-, 0q, 1n, 0m, 0f, 0u gpg: next trustdb check due at 2017-03-07 real 0m6.341s user 0m5.316s sys 0m1.024s gpg: Note: signatures using the MD5 algorithm are rejected 3402 real 0m2.011s user 0m1.940s sys 0m0.076s =====without-sha1===== gpg: Note: signatures using the SHA1 algorithm are rejected gpg: key 4E3E63D49A17C533: no valid user IDs [ ?hundreds more "no valid user IDs"? ] gpg: Note: signatures using the MD5 algorithm are rejected [ ?hundreds more "no valid user IDs"? ] real 0m53.606s user 0m13.460s sys 0m39.004s gpg: inserting ownertrust of 128 gpg: inserting ownertrust of 3 gpg: inserting ownertrust of 6 gpg: inserting ownertrust of 128 gpg: inserting ownertrust of 128 gpg: inserting ownertrust of 128 gpg: inserting ownertrust of 3 gpg: inserting ownertrust of 3 gpg: inserting ownertrust of 128 gpg: inserting ownertrust of 3 gpg: inserting ownertrust of 2 real 0m0.006s user 0m0.004s sys 0m0.000s gpg: Note: signatures using the SHA1 algorithm are rejected gpg: marginals needed: 3 completes needed: 1 trust model: pgp gpg: depth: 0 valid: 1 signed: 89 trust: 0-, 0q, 0n, 0m, 0f, 1u gpg: depth: 1 valid: 89 signed: 320 trust: 88-, 0q, 1n, 0m, 0f, 0u gpg: next trustdb check due at 2017-03-12 real 0m2.496s user 0m2.200s sys 0m0.292s gpg: Note: signatures using the SHA1 algorithm are rejected 1399 real 0m0.816s user 0m0.764s sys 0m0.052s ---------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From dkg at fifthhorseman.net Sat Feb 25 16:52:40 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 25 Feb 2017 10:52:40 -0500 Subject: file size change in trustdb.gpg after recovery In-Reply-To: References: Message-ID: <87tw7ifet3.fsf@alice.fifthhorseman.net> On Sat 2017-02-25 07:23:39 -0500, Michal Novotny wrote: > I have got a trustdb that gives the following output on --check-trustdb: > > gpg: public key of ultimately trusted key 3ADE2987ABBFDB66 not found > gpg: public key of ultimately trusted key 831FE43EDDD16F3D not found > gpg: marginals needed: 3 completes needed: 1 trust model: pgp > gpg: depth: 0 valid: 6468 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 6468u > gpg: next trustdb check due at 2021-01-18 I don't know about the size change of the trustdb.gpg -- hopefully someone else can weigh in on that. But i want to point out that 6468 ulimately-trusted keys is a *very* unusual arrangement. any one of these keys can certify any other key and gpg will rely on those certifications. You should think of ultimate ownertrust in the same way that you think of adding a new root CA to your X.509 certificate validation stack (e.g. for your web browser). Anyone with this capacity can pretty easily inject itself in your communications stream by adding OpenPGP public keys ("OpenPGP certificates") that your tools will happily believe are valid for the identities they claim. I'm not saying that this is *never* what anyone would want to do, but i've never seen a use case present itself where this was what the user actually wanted to enable > 6K parties to be able to do. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From dkg at fifthhorseman.net Sat Feb 25 16:45:31 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 25 Feb 2017 10:45:31 -0500 Subject: SHA1 collision found In-Reply-To: <159793783.20170225140920@riseup.net> References: <20170224151523.B27CFE05F7@smtp.hushmail.com> <159793783.20170225140920@riseup.net> Message-ID: <87wpceff50.fsf@alice.fifthhorseman.net> On Sat 2017-02-25 09:09:20 -0500, MFPA wrote: > On Friday 24 February 2017 at 3:15:23 PM, in , vedaal at nym.hush.com wrote:- > >> Even for v3 keys, which were not SHA1 hashed, the only way to >> generate a new key with the same fingerprint, would be to allow the >> key size to vary (usually to a bizarre key size that would be quite >> suspect, and not believed). > > Is that why the majority of keys are exactly 1024, 2048, etc. bits, or > is there a technical reason? I think the reason that a majority of keys have "round" key sizes is habit, and that the tools make it easy to generate them that way. The size variation that vedaal describes is due to the definition of the v3 fingerprint: https://tools.ietf.org/html/rfc2440#section-11.2 The fingerprint of a V3 key is formed by hashing the body (but not the two-octet length) of the MPIs that form the key material (public modulus n, followed by exponent e) with MD5. As a toy example, consider the case where p = 0x1411304f and q = 0x141120c5, so n = 0x0192af7bf8830ccb and e = 0x010001 These MPIs are stored in full octets, so the material hashed for the v3 fingerprint is (in hex) 01 92 af 7b f8 83 0c cb 01 00 01 |--------- n -----------|-- e ---| if i want to find a key with the same v3 fingerprint, i just need to vary the boundary between the two, for example like this: 01 92 af 7b f8 83 0c cb 01 00 01 |--------- n --------|---- e ----| the bytestring hashed (and therefore the fingerprint) is exactly the same as before, but n is 8 bits shorter, and e is 8 bits longer. now, it's probably obvious to anyone who bothers to inspect the public key that this is not a good key -- at the very least, n is clearly not the product of two primes ;) But RSA will still work with it. If the goal is to produce a key with the same fingerprint, it's trivial to do. This is one of the reasons why the modern GnuPG suite no longer supports these archaic keys. it's simply not a reasonable or safe-to-use format. The OpenPGPv4 fingerprint includes explicit sizes of the components in the material hashed, so it doesn't have this problem. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From peter at digitalbrains.com Sun Feb 26 12:01:05 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 26 Feb 2017 12:01:05 +0100 Subject: Announcing paperbackup.py to backup keys as QR codes on paper In-Reply-To: References: <9664399.F7pj19RVc2@thunder.m.i2n> <2550076.1cMusrXu2u@storm.m.i2n> <1499394.yZ8kfsQv5G@thunder.m.i2n> Message-ID: <335a1fa8-d98d-bd2e-11bb-f2b35f51cfab@digitalbrains.com> By the way, don't worry about the license. I just slapped it on there because you need /something/. (I didn't even look at paperbackup.py's license, which was dumb, I would have put an MIT license on it otherwise.) If you're going to use it, I assume you're just going to embed the few lines of code there are into paperbackup.py. You have my permission to use the code in posixcksum.py in paperbackup.py *without attribution*. You don't have to name me, just use it. 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 jerry at seibercom.net Sun Feb 26 11:30:20 2017 From: jerry at seibercom.net (Jerry) Date: Sun, 26 Feb 2017 05:30:20 -0500 Subject: gpg2 on a Windows 10 Pro 64 bit machine Message-ID: <20170226053020.00000755@seibercom.net> On a Windows 10 PRO 64 bit machine, when I run the following command: gpg2.exe --refresh-keys I receive the following error message: gpg: can't handle key algorithm 22 gpg: can't handle key algorithm 18 I am not sure what that is referring to. Also, there are numerous keys listed as revoked or expired. Is there a anything I can run from the command line that will automatically remove all revoked or expired keys? This is the gpg2 info. C:\WINDOWS\system32>gpg2.exe --version gpg (GnuPG) 2.0.30 (Gpg4win 2.3.3) libgcrypt 1.6.6 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: C:/Users/Gerard/AppData/Roaming/gnupg Supported algorithms: Pubkey: RSA, RSA, RSA, ELG, DSA Cipher: IDEA (S1), 3DES (S2), CAST5 (S3), BLOWFISH (S4), AES (S7), AES192 (S8), AES256 (S9), TWOFISH (S10), CAMELLIA128 (S11), CAMELLIA192 (S12), CAMELLIA256 (S13) Hash: MD5 (H1), SHA1 (H2), RIPEMD160 (H3), SHA256 (H8), SHA384 (H9), SHA512 (H10), SHA224 (H11) Compression: Uncompressed (Z0), ZIP (Z1), ZLIB (Z2), BZIP2 (Z3) Thanks -- Jerry From antony at blazrsoft.com Sun Feb 26 21:52:28 2017 From: antony at blazrsoft.com (antony at blazrsoft.com) Date: Sun, 26 Feb 2017 15:52:28 -0500 Subject: gpg2 on a Windows 10 Pro 64 bit machine In-Reply-To: <20170226053020.00000755@seibercom.net> References: <20170226053020.00000755@seibercom.net> Message-ID: <7305E494-4F52-4FDC-81B9-FD8607E01BBD@blazrsoft.com> On February 26, 2017 5:30:20 AM EST, Jerry wrote: > >gpg: can't handle key algorithm 22 >gpg: can't handle key algorithm 18 > >I am not sure what that is referring to. Also, there are numerous keys >listed as revoked or expired. Is there a anything I can run from the >command line that will automatically remove all revoked or expired >keys? Not sure on that one. >gpg (GnuPG) 2.0.30 (Gpg4win 2.3.3) >libgcrypt 1.6.6 For your original issue, IIRC, that version of libgcrypt can't handle the elliptic curve algorithms that were added in libgcrypt 1.7 and gnupg 2.1. It just means that there are keys on your keyring that use these algorithms and gnupg doesn't understand them. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From rjh at sixdemonbag.org Mon Feb 27 02:56:55 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 26 Feb 2017 20:56:55 -0500 Subject: gpg2 on a Windows 10 Pro 64 bit machine In-Reply-To: <20170226053020.00000755@seibercom.net> References: <20170226053020.00000755@seibercom.net> Message-ID: > I am not sure what that is referring to. Also, there are numerous keys > listed as revoked or expired. Is there a anything I can run from the > command line that will automatically remove all revoked or expired keys? Kinda-sorta, but yes! WARNING: this works on my laptop for both GnuPG 2.0 and 2.1. It may not work on yours. Save everything between the "=====" marks to a file named "gpgclean.ps1". ===== # gpgclean.ps1 -- cleans expired/revoked keys from GnuPG # Requires GnuPG 2.0 or later. # # Copyright 2017, Rob Hansen # # Permission to use, copy, modify, and/or distribute this # software for any purpose with or without fee is hereby # granted, provided that the above copyright notice and # this permission notice appear in all copies. # # THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS # ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO # EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, # INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES # WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, # WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER # TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE # USE OR PERFORMANCE OF THIS SOFTWARE. # Use the Windows Registry to find GnuPG's location ## Start by looking for GnuPG 2.1. If we can't find ## it, fall back to looking for 2.0. If (Test-Path "HKLM:\Software\WOW6432Node\GnuPG") { $gpgdir = Join-Path ` -Path (Get-ItemPropertyValue ` -Path "HKLM:\Software\WOW6432Node\GnuPG" ` "Install Directory") ` -ChildPath "bin" $gpg = Join-Path -Path $gpgdir "gpg.exe" } ElseIf (Test-Path "HKLM:\Software\WOW6432Node\GNU\GnuPG") { $gpgdir = Get-ItemPropertyValue ` -Path "HKLM:\Software\WOW6432Node\Gnu\GnuPG" ` "Install Directory" $gpg = Join-Path -Path $gpgdir "gpg2.exe" } # Create the two Lists we're going to use to store the # revoked/expired private keys and the revoked/expired # public keys $private_keys = New-Object ` -TypeName System.Collections.Generic.List[string] $public_keys = New-Object ` -TypeName System.Collections.Generic.List[string] # Many of our "expired" keys will have new, duration- # extending signatures. We do a keyring refresh from the # keyservers to ensure we don't delete anything we don't # have to. &$gpg --keyserver pool.sks-keyservers.net ` --refresh # Get the expired/revoked private and public keys (&$gpg --keyid-format long ` --fixed-list-mode ` --with-colons --list-key | ` Select-String -Pattern "^pub:(r|e)").ForEach({ $match = [regex]::match($_, "([A-F0-9]{16})") $keyid = $match.Groups[1].Value $public_keys.Add($keyid) } ) ## In GnuPG 2.0, you can't figure out whether a private ## key is expired except by looking at its corresponding ## public key. In GnuPG 2.1, you can, but the old way ## still works. This code will therefore work with both. If ($public_keys.Count -gt 0) { (&$gpg --keyid-format long ` --fixed-list-mode ` --with-colons --list-secret-key $public_keys | ` Select-String -Pattern "^sec").ForEach({ $match = [regex]::match($_, "([A-F0-9]{16})") $keyid = $match.Groups[1].Value $private_keys.Add($keyid) } ) } # If we have revoked/expired private keys, get rid # of them first. if ($private_keys.Count -gt 0) { &$gpg --yes --delete-secret-keys $private_keys } # Follow up with revoked/expired public keys if ($public_keys.Count -gt 0) { &$gpg --yes --delete-keys $public_keys } ===== Save that. Then, in the "Ask me anything" box, type "Windows PowerShell". Launch the program that comes up. You'll see a prompt like: PS C:\Users\rjh> Then just type the path to gpgclean.ps1 and hit RETURN. PS C:\Users\rjh> .\Documents\gpgclean.ps1 It will likely appear to hang for a few minutes. That's normal. It's refreshing your keyring in order to see if any certs have revised expiration dates. Once it finishes that, the rest goes quickly. If there's interest, I'll put a good-looking GUI on this. From gerd.von.egidy at intra2net.com Mon Feb 27 11:50:31 2017 From: gerd.von.egidy at intra2net.com (Gerd v. Egidy) Date: Mon, 27 Feb 2017 11:50:31 +0100 Subject: Announcing paperbackup.py to backup keys as QR codes on paper In-Reply-To: <20170224161709.9FC018A5@intranator.m.i2n> References: <9664399.F7pj19RVc2@thunder.m.i2n> <1499394.yZ8kfsQv5G@thunder.m.i2n> <20170224161709.9FC018A5@intranator.m.i2n> Message-ID: <2661606.PZSOA07WEn@thunder.m.i2n> Hi Peter, thank you very much for helping with paperbackup.py and sending your python code. > > Ideally it is a tool or combination of tools already deployed widely, like > > sed and sort I used in paperrestore. This would make the checksums still > > usable even when the source to paperbackup.py isn't available anymore. > > It took me some fiddling... but using CRC RevEng[1] I got a checksum in > Python that is compatible to POSIX cksum. [...] > $ printf $(printf '%08x' $(echo -n 123456789 | cksum | cut -d' ' -f1) | > sed 's/../\\x\0/g')|base64|cut -b-6 Yesterday, with your solution in mind, I had an idea how we could even further reduce dependencies and ease the use: echo -n "line content to check" | md5sum | cut -c -6 MD5 may be broken as a secure hash, but it still makes a very good checksum. MD5 is well standardized and available and hashlib.md5() is included in python. Your solution uses base64 to show more bits of the checksum than my hex chars. But I think a collision at the first 3 bytes is less likely with MD5 than one with CRC. The MD5 sum changes drastically if just one bit flips. What do you think? Kind regards, Gerd From jerry at seibercom.net Mon Feb 27 11:59:09 2017 From: jerry at seibercom.net (Jerry) Date: Mon, 27 Feb 2017 05:59:09 -0500 Subject: gpg2 on a Windows 10 Pro 64 bit machine In-Reply-To: References: <20170226053020.00000755@seibercom.net> Message-ID: <20170227055909.000033d9@seibercom.net> On Sun, 26 Feb 2017 20:56:55 -0500, Robert J. Hansen stated: >> I am not sure what that is referring to. Also, there are numerous >> keys listed as revoked or expired. Is there a anything I can run >> from the command line that will automatically remove all revoked or >> expired keys? > >Kinda-sorta, but yes! > >WARNING: this works on my laptop for both GnuPG 2.0 and 2.1. It may >not work on yours. > >Save everything between the "=====" marks to a file named >"gpgclean.ps1". > > >===== ># gpgclean.ps1 -- cleans expired/revoked keys from GnuPG ># Requires GnuPG 2.0 or later. ># ># Copyright 2017, Rob Hansen ># ># Permission to use, copy, modify, and/or distribute this ># software for any purpose with or without fee is hereby ># granted, provided that the above copyright notice and ># this permission notice appear in all copies. ># ># THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ># ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL ># IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO ># EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, ># INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES ># WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, ># WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER ># TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE ># USE OR PERFORMANCE OF THIS SOFTWARE. > > > ># Use the Windows Registry to find GnuPG's location > >## Start by looking for GnuPG 2.1. If we can't find >## it, fall back to looking for 2.0. > >If (Test-Path "HKLM:\Software\WOW6432Node\GnuPG") { > $gpgdir = Join-Path ` > -Path (Get-ItemPropertyValue ` > -Path "HKLM:\Software\WOW6432Node\GnuPG" ` > "Install Directory") ` > -ChildPath "bin" > $gpg = Join-Path -Path $gpgdir "gpg.exe" >} >ElseIf (Test-Path "HKLM:\Software\WOW6432Node\GNU\GnuPG") { > $gpgdir = Get-ItemPropertyValue ` > -Path "HKLM:\Software\WOW6432Node\Gnu\GnuPG" ` > "Install Directory" > $gpg = Join-Path -Path $gpgdir "gpg2.exe" >} > ># Create the two Lists we're going to use to store the ># revoked/expired private keys and the revoked/expired ># public keys >$private_keys = New-Object ` > -TypeName System.Collections.Generic.List[string] >$public_keys = New-Object ` > -TypeName System.Collections.Generic.List[string] > ># Many of our "expired" keys will have new, duration- ># extending signatures. We do a keyring refresh from the ># keyservers to ensure we don't delete anything we don't ># have to. >&$gpg --keyserver pool.sks-keyservers.net ` > --refresh > ># Get the expired/revoked private and public keys >(&$gpg --keyid-format long ` > --fixed-list-mode ` > --with-colons --list-key | ` > Select-String -Pattern "^pub:(r|e)").ForEach({ > $match = [regex]::match($_, "([A-F0-9]{16})") > $keyid = $match.Groups[1].Value > $public_keys.Add($keyid) > } >) > >## In GnuPG 2.0, you can't figure out whether a private >## key is expired except by looking at its corresponding >## public key. In GnuPG 2.1, you can, but the old way >## still works. This code will therefore work with both. >If ($public_keys.Count -gt 0) { > (&$gpg --keyid-format long ` > --fixed-list-mode ` > --with-colons --list-secret-key $public_keys | ` > Select-String -Pattern "^sec").ForEach({ > $match = [regex]::match($_, "([A-F0-9]{16})") > $keyid = $match.Groups[1].Value > $private_keys.Add($keyid) > } > ) >} > ># If we have revoked/expired private keys, get rid ># of them first. >if ($private_keys.Count -gt 0) { > &$gpg --yes --delete-secret-keys $private_keys >} ># Follow up with revoked/expired public keys >if ($public_keys.Count -gt 0) { > &$gpg --yes --delete-keys $public_keys >} >===== > > >Save that. Then, in the "Ask me anything" box, type "Windows >PowerShell". Launch the program that comes up. You'll see a prompt >like: > > PS C:\Users\rjh> > >Then just type the path to gpgclean.ps1 and hit RETURN. > > PS C:\Users\rjh> .\Documents\gpgclean.ps1 > >It will likely appear to hang for a few minutes. That's normal. It's >refreshing your keyring in order to see if any certs have revised >expiration dates. Once it finishes that, the rest goes quickly. > >If there's interest, I'll put a good-looking GUI on this. I just ran the program, and it seems to work fine. Using Windows 10 PRO 64 bit, users can simply locate the program and right click on it. A menu will come up. One of the selections is to run with Windows Power Shell. Simple click on that and you are off to the races. The first time you run the program Windows will ask if you want to change the permissions on the program so it can be run. At least it did on my machine. A GUI might be interesting. I would be willing to beta test it for you. Thanks for your hard work on this. -- Jerry From jerry at seibercom.net Mon Feb 27 12:07:34 2017 From: jerry at seibercom.net (Jerry) Date: Mon, 27 Feb 2017 06:07:34 -0500 Subject: gpg2 on a Windows 10 Pro 64 bit machine In-Reply-To: <20170227055909.000033d9@seibercom.net> References: <20170226053020.00000755@seibercom.net> <20170227055909.000033d9@seibercom.net> Message-ID: <20170227060734.00005ef2@seibercom.net> On Mon, 27 Feb 2017 05:59:09 -0500, Jerry stated: >On Sun, 26 Feb 2017 20:56:55 -0500, Robert J. Hansen stated: <> I was just thinking that it might be nice to have a way to "LOG" the output of the program so that a user could inspect it later to see what transpired or if an error occurred. There are several ways to accomplish this With Windows Power Shell. I am not all that familiar with it though. In any case, it is just a thought. -- Jerry From peter at digitalbrains.com Mon Feb 27 13:30:13 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 27 Feb 2017 13:30:13 +0100 Subject: Announcing paperbackup.py to backup keys as QR codes on paper In-Reply-To: <2661606.PZSOA07WEn@thunder.m.i2n> References: <9664399.F7pj19RVc2@thunder.m.i2n> <1499394.yZ8kfsQv5G@thunder.m.i2n> <20170224161709.9FC018A5@intranator.m.i2n> <2661606.PZSOA07WEn@thunder.m.i2n> Message-ID: On 27/02/17 11:50, Gerd v. Egidy wrote: > echo -n "line content to check" | md5sum | cut -c -6 Yes, that should work just as well in practice, I think. 24 bits of checksum is slightly weaker than 32, but I don't think it matters. > But I think a collision at the first 3 bytes is less likely with MD5 than one > with CRC. The MD5 sum changes drastically if just one bit flips. I doubt CRC-32 would be worse than 32 bits of MD5, since CRC-32 is designed to catch accidental errors[1]. I don't know how a CRC-32 truncated to 24 bits would behave. A truncated MD5 should be fine for detecting accidental errors, though. So I think the three initial bytes of an MD5 would work well to detect typing errors. Cheers, Peter. [1] Although it's probably better at physical noise in the transfer of individual bits than typing mistakes in base64 data. -- 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 jestedfa at microsoft.com Mon Feb 27 15:20:38 2017 From: jestedfa at microsoft.com (Jeffrey Stedfast) Date: Mon, 27 Feb 2017 14:20:38 +0000 Subject: Problems with GPGME returning "Not Implemented" or "Configuration error" Message-ID: Hi all, I'm working on re-implementing GMime to use libgpgme (1.8.0 on Fedora 25) instead of using my own custom logic for fork()ing/exec()ing gpg & parsing the status-fd output to do PGP encryption and I've gotten that to work just fine for PGP, but I am having trouble using nearly identical logic (only diff is armor/textmode state) to sign or encrypt using the CMS backend. For some reason, gpgme_op_sign() is returning GPG_ERR_NOT_IMPLEMENTED while gpgme_op_encrypt() is returning "Configuration error". >From what I can deduce by scouring the web for information, it seems like NOT_IMPLEMENTED should never get returned unless I am using options that just haven't been implemented yet but that doesn't seem like it should be the case since I don't think I'm doing anything out of the ordinary. When signing, I've set armor=0, textmode=0, mode=DETACH (or NORMAL), and added a signer to the context. For encrypting, I am getting "Configuration error" which I'm also confused about because I don't know what configuration options could be causing this. Once again, armor=0, textmode=0, flags=0, and I've created a NULL-terminated list of recipient keys to pass to gpgme_op_encrypt(). Since my unit tests are re-using the same gpgme context to import some smime certs, then export some certs, then sign some streams, etc - could that be the problem? As I write this email, I realize that's something I haven't yet checked... All I can think of is that perhaps there is some leftover state from gpgme_op_import() or gpgme_op_export_ext() that is breaking the gpgme_op_sign() when run at a later point? Thanks for any help or guidance in tracking down these issues, Jeff From rsvx at riseup.net Mon Feb 27 16:07:12 2017 From: rsvx at riseup.net (rsvx at riseup.net) Date: Mon, 27 Feb 2017 16:07:12 +0100 Subject: help Message-ID: <974a1560e5198f59f241336baeb09e1f@riseup.net> Hi, i'm configuring my gnupg using 2.1.11 I'll use my master key offline. Following this guidelines: https://incenp.org/notes/2015/using-an-offline-gnupg-master-key.html I also implemented the Appelbaum's config.(Riseup Best Practices) Will it work properly if the Master Key isn't on my machine? And the following faults are coming: gpg: keyserver option 'ca-cert-file' is obsolete; please use 'hkp-cacert' in dirmngr.conf gpg: keyserver option 'no-try-dns-srv' is unknown Please see the screenshot from my terminal. Many thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: terminal Type: image/png Size: 42950 bytes Desc: not available URL: From gniibe at fsij.org Tue Feb 28 00:28:21 2017 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 28 Feb 2017 08:28:21 +0900 Subject: How U2F works Message-ID: <878tortdre.fsf@fsij.org> Hello, Let me ask a question about U2F. Or, more generally, possibility to enhance GnuPG for web authentication. While I maintain scdaemon of GnuPG and develop Gnuk (an OpenPGPcard implementation), I sometimes am asked about U2F support, these days. (I think that this is due to Yubikey.) IIUC, major use case of U2F is web authentication. It seems for me that it doesn't fit directly to OpenPGPcard use case. Anyhow, it would be possible for Gnuk to add U2F support (somehow limited, because of available resource on board). Also, it would be possible for scdaemon (or other application) to emulate U2F protocol (just like Scute does emulate PKCS#11). Well, I have two concerns for U2F. (1) Atterstation key In the document of U2F: https://fidoalliance.org/specs/fido-u2f-v1.1-id-20160915/fido-u2f-overview-v1.1-id-20160915.html#verifying-that-a-u2f-device-is-genuine It explains about Atterstation key. If it were common for services to do this Atterstation key check, U2F emulation or free U2F implementation will be no real use with no private key of the vendor. (It reminds me the old days when Apache couldn't serve https because no certificate authority issued certificate for servers with Apache.) I wondor if Atterstation key check is common or not. (2) JavaScript It seems for me that there are special JavaScript(s) to offer access API to U2F. I don't quite understand how it works to the physical device. I don't like nonfree JavaScript which may interfere user' control. Is it easy for free script (as in freedom) to integrate a script for U2F access? Any such example scripts or any such services which do so? Here, my concern is that if it is all for proprietary world, I am reluctant to consider seriously about U2F. And finally, if web authentication is important, I would like to use the infrastructure of GnuPG to manage my own crypto computation and my own private keys. Currently, we can use GnuPG for SSH authentication by its ssh-agent emulation. I would like to extend this. Any thoughts? Thanks in advance. -- From dgouttegattat at incenp.org Tue Feb 28 00:35:31 2017 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Tue, 28 Feb 2017 00:35:31 +0100 Subject: help In-Reply-To: <974a1560e5198f59f241336baeb09e1f@riseup.net> References: <974a1560e5198f59f241336baeb09e1f@riseup.net> Message-ID: Hi, On 02/27/2017 04:07 PM, rsvx at riseup.net wrote: > I'll use my master key offline. Following this guidelines: > https://incenp.org/notes/2015/using-an-offline-gnupg-master-key.html > > I also implemented the Appelbaum's config.(Riseup Best Practices) Will > it work properly if the Master Key isn't on my machine? It should. Note, however, that Riseup's Best Practices [1] and proposed configuration file [2] are partially obsolete, *especially* if you are using GnuPG 2.1. Many of the proposed options and advices are not needed anymore, as GnuPG already does The Right Thing. > And the following faults are coming: > gpg: keyserver option 'ca-cert-file' is obsolete; please use > 'hkp-cacert' in dirmngr.conf If you're using the sks-keyservers.net pool you no longer need to provide GnuPG with the CA certificate file, as it is now bundled with GnuPG (>= 2.1.11) and automatically used when needed. (And with GnuPG >= 2.1.16 you will no longer even need to explicity set the keyserver option, as hkps.pool.sks-keyservers.net is already the default.) > gpg: keyserver option 'no-try-dns-srv' is unknown This option no longer exists, but I *think* that if you really want to, you can disable SRV lookups by explicitly specifying a port number when setting the keyserver, as in: keyserver hkps.pool.sks-keyservers.net:443 Damien -- [1] https://riseup.net/en/security/message-security/openpgp/best-practices [2] https://raw.githubusercontent.com/ioerror/duraconf/master/configs/gnupg/gpg.conf -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From glenn at rempe.us Tue Feb 28 01:28:25 2017 From: glenn at rempe.us (Glenn Rempe) Date: Mon, 27 Feb 2017 16:28:25 -0800 Subject: How U2F works In-Reply-To: <878tortdre.fsf@fsij.org> References: <878tortdre.fsf@fsij.org> Message-ID: Just chiming in here with some comments below. I am an active U2F user and have played around with the server API's and read some of the specs. Just to be clear, not an expert on U2F. On 2/27/17 3:28 PM, NIIBE Yutaka wrote: > Hello, > > Let me ask a question about U2F. Or, more generally, possibility > to enhance GnuPG for web authentication. > > Anyhow, it would be possible for Gnuk to add U2F support (somehow > limited, because of available resource on board). Also, it would > be possible for scdaemon (or other application) to emulate U2F > protocol (just like Scute does emulate PKCS#11). > > Well, I have two concerns for U2F. > > (1) Atterstation key > > In the document of U2F: > > https://fidoalliance.org/specs/fido-u2f-v1.1-id-20160915/fido-u2f-overview-v1.1-id-20160915.html#verifying-that-a-u2f-device-is-genuine > > It explains about Atterstation key. > > If it were common for services to do this Atterstation key check, > U2F emulation or free U2F implementation will be no real use with > no private key of the vendor. (It reminds me the old days when > Apache couldn't serve https because no certificate authority issued > certificate for servers with Apache.) I wondor if Atterstation key > check is common or not. Well, the attestation key would be checked by the server side process right? And that is optional to check (but perhaps not optional to send). So you probably would need to ask those that are integrating U2F as a server auth method. Sending this seems to be a requirement based on the spec link you sent. Couldn't you get a vendor specific attestation key in any case for GnuK and use the same key across all devices? Yubico describes something about the attestation metadata they use here: https://developers.yubico.com/U2F/Attestation_and_Metadata/ > > > (2) JavaScript > > It seems for me that there are special JavaScript(s) to offer > access API to U2F. I don't quite understand how it works to the > physical device. > > I don't like nonfree JavaScript which may interfere user' control. > > Is it easy for free script (as in freedom) to integrate a script > for U2F access? Any such example scripts or any such services > which do so? I believe that at this point almost all use of U2F is through web browsers that support talking to the U2F hardware API's directly. Only Chrome has full support now, and Firefox and Opera are working on it but are not yet generally available. The web Javascript API's are just for requesting registration of a token or authentication. So you can't use U2F in a browser that does not have support for it no matter what JS you load in your page. Browser support: https://www.yubico.com/support/knowledge-base/categories/articles/browsers-support-u2f/ Yubico Demo Code and JS API https://developers.yubico.com/U2F/Libraries/Using_a_library.html JS Polyfill https://github.com/mastahyeti/u2f-api > > Here, my concern is that if it is all for proprietary world, I am > reluctant to consider seriously about U2F. FIDO U2F is based on an openly published standard but only for you to 'read and analyze'. Seems like you have to become a member of the FIDO alliance to be protected. Its not an Internet RFC. "FIDO's specifications are public and available for anyone to read and analyze. But only FIDO Alliance Members benefit from ?the promise? to not assert patent rights against other members? implementations (see the FIDO Alliance Membership Agreement for details). Anyone may join the FIDO Alliance; we encourage even very small companies with a very low cost to join at the entry level. Members at all levels not only benefit from the mutual non-assert protection, but also participate with FIDO Alliance members, activities and developments; Associates have more limited participation benefits. All are invited to join the FIDO Alliance and participate." https://fidoalliance.org/faqs/ > > > And finally, if web authentication is important, I would like to > use the infrastructure of GnuPG to manage my own crypto computation > and my own private keys. Currently, we can use GnuPG for SSH > authentication by its ssh-agent emulation. I would like to extend > this. Wouldn't making this work require the browser vendors to support some kind of 'pluggable local auth' that gnupg would emulate, and not only support for hardware tokens like Yubikey? I don't know if they support this broader concept or not. https://fidoalliance.org/specifications/overview/ What though is the benefit of using gnupg key as the crypto behind the client auth? Seems like you are more exposed by having a portable gpg key as opposed to a hardware embedded key. U2F makes it so easy to add a backup key, and most implementations let you drop and add keys pretty easily. Just trying to figure out if backing U2F with gpg, if that is what you are proposing, is worth it? > > Any thoughts? Thanks in advance. > Cheers. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Tue Feb 28 11:04:08 2017 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 28 Feb 2017 19:04:08 +0900 Subject: How U2F works In-Reply-To: References: <878tortdre.fsf@fsij.org> Message-ID: <877f4apr6v.fsf@fsij.org> Hello, Thanks a lot for your explanation. Glenn Rempe wrote: > Well, the attestation key would be checked by the server side process > right? And that is optional to check (but perhaps not optional to > send). So you probably would need to ask those that are integrating > U2F as a server auth method. Sending this seems to be a requirement > based on the spec link you sent. Couldn't you get a vendor specific > attestation key in any case for GnuK and use the same key across all > devices? I see. I read the spec. again, IIUC, the generated keys in token will be all signed by the attestation key. I think that it is better for the server side to check the signature so that it can detect possible MitM attack. I don't think it can be "optional" in real fields. It would be possible to arrange a vendor attestation key of U2F for Gnuk. We did in a different level; We got USB vendor ID for our devices. However, with the OpenPGP background, I feel that it sounds wrong to allow such an idea of a single secret shared among many devices. If we do something like that (to assure authentication key generated by a specific device), possible method for OpenPGP would be: (1) Gnuk will have a feature of "device specific key". (2) As initialization procedure, a distributor let a token generate "device specific key" when they ship the device to a customer. They record the public key of each "device specific key" of customer. (3) The distributor signs a public key of the "device specific key". (4) When Gnuk generates authentication key, a signature by "device specific key" is also generated. (5) It is up to a user to use distributor's generated "device specific key" and their signature. A user can let a token generate new "device specific key", and anyone can sign the public key of "device specific key". (6) Servers can check if an authentication key is signed by "device specific key" which is signed by trustworthy distributor. Well, probably, description above would be a different attestation key for each device, in terms of U2F. > I believe that at this point almost all use of U2F is through web > browsers that support talking to the U2F hardware API's directly. Only > Chrome has full support now, and Firefox and Opera are working on it > but are not yet generally available. The web Javascript API's are just > for requesting registration of a token or authentication. So you can't > use U2F in a browser that does not have support for it no matter what > JS you load in your page. I see. I was afraid that a user has to accept nonfree JavaScript from server when she wants to use U2F authentication. > What though is the benefit of using gnupg key as the crypto behind the > client auth? Seems like you are more exposed by having a portable gpg > key as opposed to a hardware embedded key. U2F makes it so easy to add > a backup key, and most implementations let you drop and add keys > pretty easily. Just trying to figure out if backing U2F with gpg, if > that is what you are proposing, is worth it? It is because of a simple reason. I can't check the hardware and the firmware in the current implementations of U2F devices. I would like to control my crypto computation in a way I can examine. --