From 2014-667rhzu3dc-lists-groups at riseup.net Sun Nov 1 11:50:33 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sun, 1 Nov 2015 10:50:33 +0000 Subject: TOFU for GnuPG In-Reply-To: <87twp67pia.wl-neal@walfield.org> References: <878u6l93b8.wl-neal@walfield.org> <993404345.20151031115705@my_localhost> <87twp67pia.wl-neal@walfield.org> Message-ID: <1593601475.20151101105033@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Saturday 31 October 2015 at 8:27:09 PM, in , Neal H. Walfield wrote: > N is the number of unique signatures. If you verify > the message signature multiple times, it will only > count once. Cool. > I'm sure we could do something like this, but it sounds > like adding complexity, which doesn't seem justified. Yes, it seemed like a great suggestion until I tried to construct in my mind a way in which it would be useful. (I think the idea occurred to me when I was reading the discussion about whether GnuPG logging how often I received emails from a particular sender was problematic.) Another thought. New signatures from a key that has long been inactive may arouse suspicion. Perhaps it would be useful to output how long ago was the last message verified. For example:- "66 messages signed over the past 3 years. The last was 1 year 10 months ago." - -- Best regards MFPA Always be on the lookout for conspicuousness -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJWNe6NXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXw7PsIAKhh8R/ObXpXJfzeBoh1Jfyr hB35bJ+7rM51nH02/z28dwXas4gqq+sHG2pK4Jv7WaW4eJ5p5OUd7JyAoc6NinoT z8MpnxoYraAFr9oufxXmbShSEVdiMnFxC/wSLxQmJA+cc4xKbXUzY+Tf8xxQl+Tf WU2NGPf88FIQrTsHnILcZxfICqTYzc/RXZvpkVKdUhCgs/hPxrfU18NYwThnj9k4 nZi0zWlxsySzTN6OQZzsjxSj4U1aseUbIGnU3HJQ3x6BJ62kjuE/CzaXS+1H/4wc akxtNxBiAGJAxGhBXdFh2LnRPwp4q8X+XZZSmjocC/zldy+suPRfEEotgJ4LfpOI vgQBFgoAZgUCVjXull8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45MPhAQCvk5UQhm4oRvDjxSui3xG2aNKG fHL1ZkDIMtXQkiACVAD/WuAkwWTnjoDWww5X8VPcgqYs/TuHc/FL6uoLXFJL4wo= =fBRS -----END PGP SIGNATURE----- From yuri.kanivetsky at gmail.com Sun Nov 1 17:20:33 2015 From: yuri.kanivetsky at gmail.com (Yuri Kanivetsky) Date: Sun, 1 Nov 2015 18:20:33 +0200 Subject: ?: keys.gnupg.net: Host not found In-Reply-To: References: <5613A4CC.60204@sumptuouscapital.com> <56177CD4.1090104@sumptuouscapital.com> <56191421.5020107@sumptuouscapital.com> Message-ID: Hi, Thanks for your replies. It's vagrant's dns proxy who's at fault here: https://www.virtualbox.org/ticket/14736 https://github.com/protobox/protobox/issues/159#issuecomment-152840998 Regards, Yuri From neal at walfield.org Sun Nov 1 18:41:28 2015 From: neal at walfield.org (Neal H. Walfield) Date: Sun, 01 Nov 2015 18:41:28 +0100 Subject: TOFU for GnuPG In-Reply-To: <1593601475.20151101105033@my_localhost> References: <878u6l93b8.wl-neal@walfield.org> <993404345.20151031115705@my_localhost> <87twp67pia.wl-neal@walfield.org> <1593601475.20151101105033@my_localhost> Message-ID: <87si4p7h2v.wl-neal@walfield.org> Hi, At Sun, 1 Nov 2015 10:50:33 +0000, MFPA wrote: > Another thought. New signatures from a key that has long been inactive > may arouse suspicion. Perhaps it would be useful to output how long > ago was the last message verified. For example:- > > "66 messages signed over the past 3 years. The last was 1 year 10 > months ago." This sounds like a good idea. I'll add it. Thanks, :) Neal From gniibe at fsij.org Mon Nov 2 03:04:35 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 02 Nov 2015 11:04:35 +0900 Subject: Generating 4096 bit key fails =?windows-1252?Q?=96_why=3F?= In-Reply-To: References: <87oafk9iqh.fsf@vigenere.g10code.de> Message-ID: <5636C4B3.5050905@fsij.org> On 10/31/2015 02:18 PM, Felix E. Klee wrote: > See attachment. Thank you for the attachment. It failed when gpg frontend tried to change the key attribute for RSA-4096. > 2015-10-31 06:05:38 scdaemon[1927] DBG: chan_5 <- SETATTR KEY-ATTR --force+1+1+rsa4096 > 2015-10-31 06:05:38 scdaemon[1927] DBG: chan_5 -> ERR 100663375 Invalid data Do you happened to have (and run) old scdaemon of 2.0? In 2.1.x, this particular protocol has been changed to support ECC. It was in the format (in the syntax of scanf): setattr key-attr --force %d %d %u It was number, because we only supported RSA. Now, it's in the format: setattr key-attr --force %d %d %s It is now string, because we supports RSA and ECC. The error seems to be occurred because of this format change. Since SETATTR command uses percent-and-plus escaping, having '+' is no problem (it means space). -- From felix.klee at inka.de Mon Nov 2 10:40:39 2015 From: felix.klee at inka.de (Felix E. Klee) Date: Mon, 2 Nov 2015 10:40:39 +0100 Subject: =?UTF-8?Q?Re=3A_Generating_4096_bit_key_fails_=E2=80=93_why=3F?= In-Reply-To: <5636C4B3.5050905@fsij.org> References: <87oafk9iqh.fsf@vigenere.g10code.de> <5636C4B3.5050905@fsij.org> Message-ID: On Mon, Nov 2, 2015 at 3:04 AM, NIIBE Yutaka wrote: > It failed when gpg frontend tried to change the key attribute for > RSA-4096. > >> [?] > > Do you happened to have (and run) old scdaemon of 2.0? Unfortunately that doesn?t seem to be the explanation. After starting `gpg --card-edit`, I checked which version is running, and it?s 2.1.9: $ ps aux | grep scdaemon root 506 [?] scdaemon --multi-server felix 562 [?] grep scdaemon $ sudo ls -l /proc/506/exe [?] /proc/506/exe -> /usr/lib/gnupg/scdaemon $ /usr/lib/gnupg/scdaemon --version scdaemon (GnuPG) 2.1.9 libgcrypt 1.6.4 libksba 1.3.3 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. What else can I try? From wk at gnupg.org Mon Nov 2 15:31:20 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 02 Nov 2015 15:31:20 +0100 Subject: Generating 4096 bit key fails =?utf-8?Q?=E2=80=93?= why? In-Reply-To: <562FD4BB.7000903@dabpunkt.eu> (Daniel Baur's message of "Tue, 27 Oct 2015 20:47:07 +0100") References: <562FD4BB.7000903@dabpunkt.eu> Message-ID: <87oafczd53.fsf@vigenere.g10code.de> On Tue, 27 Oct 2015 20:47, mls at dabpunkt.eu said: > AFAIK the card doesn?t support 4096 bit keys. The webpage given by you > says the same AFAIS: The ZeitControl v2 OpenPGP cards have always supported 4096 bit RSA. However we only stated 3072 because back then GnuPG was not able to handle keys larger than 3072 (IPC issue between gpg, gpg-agent, and scdaemon). This has been resolved a long time ago. BTW, g10 code site is a bit out of date due to problems with the rewrite of org-mode's exporter system some years ago. I started to fix the site build system yesterday but it is not finished. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From d1sc1pl1n4.1nf0rm4t1c4 at gmail.com Mon Nov 2 20:15:34 2015 From: d1sc1pl1n4.1nf0rm4t1c4 at gmail.com (Julian) Date: Mon, 2 Nov 2015 20:15:34 +0100 Subject: Java library for OpenPGP Message-ID: <5637B656.40501@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear community, for my bachelor thesis I need a java library which supports basic OpenPGP functions. I need the library for encrypting mails, signing keys and recieving and uploading keys from/to a keyserver over the hkp protocol. I have already found Bouncy Castle and OpenPGP Library for Java from DidiSoft.com (uses on the lower level Bouncy Castle OpenPGP functionality). Are there still other java librarys? Which of the librarys is the best one? I would prefer a non-commercial library. Thank you for your help and kind regards Julian -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWN7ZWAAoJEDVkJsWTvshXtSUP/j64x7igk7Y2ZxxOQXX40yk5 uZwi+gxFR2zOhrx230SuF/KIlAYMCDINyw0Io9mHgGtth9l01fLnvJwak2A6HI8g f9cNbg8W/UacpP9cMkSUUnPQk1OFghiWuB2giox+K543qA4+W3MkK/5kYg4nJAri CEhJT7PFuGjjz57ITnEUHFOLdxmE/LF44PKJQzuHceMJHt27A/ReEpBs/ZO+DhUL iXVHv5BcKVzipbFDUe8Vi04v+aNPEYXi4yEFKBSbBG4tcm7f/Mp0CzYfPdw9GYBG rQ+46YupMOwD4D7e/iQhwK9DCLfXPfLgTqa/3Ped4NLeKwJCkQzPcAdjUiMlGJDU rQ6vvP8lzU3L9S6d/pcg15+HVfTYipTgxCoKfnPMfcjvFdc1DnxYeBaDFLTTr9vL Je2siSkCQszEsaTyv/RaOADVdnP60qx2WRIGixAmCWV51U6KDa0GOBV/ag31Ua3L lI1eDOOEPA3HUK/LCamQGV7UbBaFeAnNO1OxFVSpRprwAAetoIAk+8rtMlaeCfjF jplI5mGTa1F0JdZpHhD5gXFgfbf4HBHD3drHYF1OHJdJdNQr4G+4IM/uXcpsypfR TNm70KCtzH3Cd/MuicMKr6hijvUB3VoC+tdkL8+Om4u4TInoJF/6UWjzwP1EZGET br72grzc+ahrt7VMna6R =UZWK -----END PGP SIGNATURE----- --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren gepr?ft. https://www.avast.com/antivirus From antony at blazrsoft.com Mon Nov 2 21:34:39 2015 From: antony at blazrsoft.com (Antony Prince) Date: Mon, 2 Nov 2015 15:34:39 -0500 Subject: Java library for OpenPGP In-Reply-To: <5637B656.40501@gmail.com> References: <5637B656.40501@gmail.com> Message-ID: <5637C8DF.3060408@blazrsoft.com> On 11/2/2015 2:15 PM, Julian wrote: > > Are there still other java librarys? Which of the librarys is the best > one? You could take a look at the library written by guardianproject[0] and see if it meets your needs. It creates a Java interface to GPGME. [0]https://github.com/guardianproject/gnupg-for-java -- 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: 884 bytes Desc: OpenPGP digital signature URL: From 2014-667rhzu3dc-lists-groups at riseup.net Tue Nov 3 15:32:56 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Tue, 3 Nov 2015 14:32:56 +0000 Subject: TOFU for GnuPG In-Reply-To: <87y4ek7e28.wl-neal@walfield.org> References: <878u6l93b8.wl-neal@walfield.org> <1574141659.20151030120614@my_localhost> <87y4ek7e28.wl-neal@walfield.org> Message-ID: <1299877596.20151103143256@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Friday 30 October 2015 at 12:09:51 PM, in , Neal H. Walfield wrote: > The user ids are used. These are authorative. If > there are N user ids, then N bindings are maintained. Presumably if no user-id contains a readable email address, no binding is stored at all. - -- Best regards MFPA Reality is nothing but a collective hunch. -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJWOMWoXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwCvkIAIleMBEeFtnLDizhbWL+U3lZ iuw/1MFvlXPxI88R45p8u7c2DyYKII78jIGL2JbJBuaE/cJ/kc/WFsArGP+lO53W YU+7etSFyIMr15Ykn/VxgfS5hqqDLwJ5XGoxs8BHV35XZAu9SjeS+IszEDJBQ5Er 0OdlVGwTTCe+a2eGbkrv8sCy6t4b92WrvW6ag+XDYlvDNugh3w4ThXujqNvldG6r IdW54XZNnnFjjrQwUTCh5L4lM1A87RlhEJSXLyReJ/czVYJTSO9bUvplPayzv3Qe uuNJ69Kr2YD16e6/6yrXKkkkfP+RrlYUmhDSEREXwRbCSjay8LspUdNemd+wRaOI vgQBFgoAZgUCVjjFrV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45AsVAP9GUe9libeqGSVR/ZsCO1VJ7qaQ 070CM1961MKO8UdXCAD/eH9JEuNZthJMZAqW9JaWq69kMYb1RqJs7w6+BNZFPAo= =XoMO -----END PGP SIGNATURE----- From neal at walfield.org Tue Nov 3 15:38:04 2015 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 03 Nov 2015 15:38:04 +0100 Subject: TOFU for GnuPG In-Reply-To: <1299877596.20151103143256@my_localhost> References: <878u6l93b8.wl-neal@walfield.org> <1574141659.20151030120614@my_localhost> <87y4ek7e28.wl-neal@walfield.org> <1299877596.20151103143256@my_localhost> Message-ID: <87fv0n6tdf.wl-neal@walfield.org> At Tue, 3 Nov 2015 14:32:56 +0000, MFPA wrote: > On Friday 30 October 2015 at 12:09:51 PM, in > , Neal H. Walfield wrote: > > The user ids are used. These are authorative. If > > there are N user ids, then N bindings are maintained. > > Presumably if no user-id contains a readable email address, no binding > is stored at all. In this case, we store the whole user id (lower cased). Only if the user id is the empty string do we not store a binding. Neal From neal at walfield.org Tue Nov 3 15:57:05 2015 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 03 Nov 2015 15:57:05 +0100 Subject: TOFU for GnuPG In-Reply-To: <7199113.qO6LXLehuY@esus> References: <878u6l93b8.wl-neal@walfield.org> <2716269.7NmZPPvcaD@mani> <87611p8iuh.wl-neal@walfield.org> <7199113.qO6LXLehuY@esus> Message-ID: <87egg76shq.wl-neal@walfield.org> Hi Andre, At Fri, 30 Oct 2015 13:23:14 +0100, Andre Heinecke wrote: > On Thursday 29 October 2015 22:28:54 Neal H. Walfield wrote: > > At Thu, 29 Oct 2015 18:48:43 +0100, > > > > Johannes Zarl-Zierl wrote: > > > Out of curiosity: Does the TOFU implementation for gpg already allow for > > > key transition statements / is this planned for some point in the future? > > Unfortunately, it doesn't. This is because there is currently no > > standard way to communicate the id of the new key. I've proposed a > > solution for this for the next OpenPGP version, which is currently > > being work on. There appears to be some interest, but unfortunately I > > haven't had time to work on that recently. > > I don't fully understand why you need formalized transition statements. > Couldn't you just treat Key / UIDs that are signed by each other as "two valid > keys for this UID"? > > So when I transition to another key I just sign it with the old key and GnuPG > can detect that and not show a warning about it? > > This would also solve the problem that some users may have multiple keys with > the same UID's which are both valid. This could work if both keys are available locally. If you need to look up the new key, this is not so easy. Another problem is that this assumes that the new key has the exact same user ids. Oftentimes some emails will have been dropped or the person's name changed (e.g., marriage, new title, etc.). Thanks, :) Neal From aheinecke at intevation.de Tue Nov 3 16:10:24 2015 From: aheinecke at intevation.de (Andre Heinecke) Date: Tue, 03 Nov 2015 16:10:24 +0100 Subject: TOFU for GnuPG In-Reply-To: <87egg76shq.wl-neal@walfield.org> References: <878u6l93b8.wl-neal@walfield.org> <7199113.qO6LXLehuY@esus> <87egg76shq.wl-neal@walfield.org> Message-ID: <46667157.oYpmE4WqK6@esus> Hi Neal, On Tuesday 03 November 2015 15:57:05 Neal H. Walfield wrote: > > I don't fully understand why you need formalized transition statements. > > Couldn't you just treat Key / UIDs that are signed by each other as "two > > valid keys for this UID"? > > > > So when I transition to another key I just sign it with the old key and > > GnuPG can detect that and not show a warning about it? > > > > This would also solve the problem that some users may have multiple keys > > with the same UID's which are both valid. > > This could work if both keys are available locally. If you need to > look up the new key, this is not so easy. Don't we need to lookup the new key anyway to make validity decisions? Until then we assume "Unknown" trust. Well I can see that one of the features of Tofu is that Unknown trust should no longer be presented to users but in that case we could add auto-key- retrieve? :-) > Another problem is that this assumes that the new key has the exact > same user ids. Oftentimes some emails will have been dropped or the > person's name changed (e.g., marriage, new title, etc.). You have lost me here. Why does it assume that? - I send you lots of mails as aheinecke at intevation.de signed with C97822F5 - Now I send you once a mail as aheinecke at intevation.de signed with 58BD45EC -> You can check if C97822F5 signed the User ID aheinecke at intevation.de on key 58BD45EC. It has. So you can assume the new Key is also valid for that UID. Any new UID's on this key will have to be treated as first contact ID's. If the new key has less UID's I don't see a problem at all. Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From 2014-667rhzu3dc-lists-groups at riseup.net Tue Nov 3 16:18:57 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Tue, 3 Nov 2015 15:18:57 +0000 Subject: TOFU for GnuPG In-Reply-To: <87fv0n6tdf.wl-neal@walfield.org> References: <878u6l93b8.wl-neal@walfield.org> <1574141659.20151030120614@my_localhost> <87y4ek7e28.wl-neal@walfield.org> <1299877596.20151103143256@my_localhost> <87fv0n6tdf.wl-neal@walfield.org> Message-ID: <908439596.20151103151857@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Tuesday 3 November 2015 at 2:38:04 PM, in , Neal H. Walfield wrote: > In this case, we store the whole user id (lower cased). > Only if the user id is the empty string do we not store > a binding. How will TOFU react if a key for which bindings are already stored acquires a new UID? - -- Best regards MFPA The trouble with words is that you never know whose mouths they've been in. -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJWONBuXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwHZgIAJyf6mWrWI2b8QiAvyfWBq7L 5yM/jB3VzN7aWMeRndRzfipTsqT/mzsdea5bGgBDetxHgPlHjSyTPuSeifEglqft wFwiQR1pISUuHsom/HTkiymZqUr+EJCnbQAFVjhX0FoWm78iXnKNhRMP9qhtKuo8 FayHf+VMQUyWxGdVOVSSWfadge2qRLli2sEapwULbxj3sf9hY8V6j0f4HEcfu3cG BTgfg4JpywrCKhIpEjSnsZWXZ99EKLkB9KGPktvD9sPSEoIQEU7atWzqF/+RYIyB q/yNmV7NXniZVgvFI9zR0P6xUBzU5ZY705anafUX4J4mqwyyzBWd6ikHgSJnbu6I vgQBFgoAZgUCVjjQdV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45ORNAQDYPEHUMsWGXo5fnSpQ/aOi6SoA m5UiHu/rQZE2ZQM9qgEAp3k+JhqGrLfEsL5u8taOk10x6W8nUXqC5A2K01EBGgE= =gIRv -----END PGP SIGNATURE----- From neal at walfield.org Tue Nov 3 16:29:02 2015 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 03 Nov 2015 16:29:02 +0100 Subject: TOFU for GnuPG In-Reply-To: <908439596.20151103151857@my_localhost> References: <878u6l93b8.wl-neal@walfield.org> <1574141659.20151030120614@my_localhost> <87y4ek7e28.wl-neal@walfield.org> <1299877596.20151103143256@my_localhost> <87fv0n6tdf.wl-neal@walfield.org> <908439596.20151103151857@my_localhost> Message-ID: <87d1vr6r0h.wl-neal@walfield.org> At Tue, 3 Nov 2015 15:18:57 +0000, MFPA wrote: > On Tuesday 3 November 2015 at 2:38:04 PM, in > , Neal H. Walfield wrote: > > > > In this case, we store the whole user id (lower cased). > > Only if the user id is the empty string do we not store > > a binding. > > > How will TOFU react if a key for which bindings are already stored > acquires a new UID? The bindings are between user id and key. So, a new binding will be created. Neal From neal at walfield.org Tue Nov 3 16:34:39 2015 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 03 Nov 2015 16:34:39 +0100 Subject: TOFU for GnuPG In-Reply-To: <46667157.oYpmE4WqK6@esus> References: <878u6l93b8.wl-neal@walfield.org> <7199113.qO6LXLehuY@esus> <87egg76shq.wl-neal@walfield.org> <46667157.oYpmE4WqK6@esus> Message-ID: <87bnbb6qr4.wl-neal@walfield.org> At Tue, 03 Nov 2015 16:10:24 +0100, Andre Heinecke wrote: > Don't we need to lookup the new key anyway to make validity decisions? Until > then we assume "Unknown" trust. In the verify case, yes. But what about the sign case? We just see that the old key has been revoked, but we don't know what the new key is. Thanks, :) Neal From 2014-667rhzu3dc-lists-groups at riseup.net Tue Nov 3 16:37:06 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Tue, 3 Nov 2015 15:37:06 +0000 Subject: TOFU for GnuPG In-Reply-To: <87d1vr6r0h.wl-neal@walfield.org> References: <878u6l93b8.wl-neal@walfield.org> <1574141659.20151030120614@my_localhost> <87y4ek7e28.wl-neal@walfield.org> <1299877596.20151103143256@my_localhost> <87fv0n6tdf.wl-neal@walfield.org> <908439596.20151103151857@my_localhost> <87d1vr6r0h.wl-neal@walfield.org> Message-ID: <1173808583.20151103153706@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Tuesday 3 November 2015 at 3:29:02 PM, in , Neal H. Walfield wrote: > The bindings are between user id and key. So, a new > binding will be created. Will it flag up to the user that it is creating a new binding for a known key? Or will there only be a prompt in the case that the new uid matches one already stored in a binding to a different key? - -- Best regards MFPA Of course it's a good idea - it's mine! -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJWONSiXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwsF0H/2+mgi3ziNoZjQQ1SC0PRGoX JFKS4K2Q8YurNmCwJHVgMbNxvJDRKHngtJwtVvmcGTxSQQqtNM62SaoWJI3ecCBg t3YoKjf2PRcRJZiKmbNIEWZtIHserykjVtq5dXQYf/1AmxyVuUfgtRDw++e7swqN OO9q7CDTBDAQR8q1FLkGDHBJTrw3OBDdhxbNTv6FfaysNruAZqql7Od4VszhOfhK lMuSZBF/UtNyRiPj3rANN4Ske0vhbc25EBy11KZy1D54QqI3Ou+hCVALordSvos4 KZYYwgOdVFSUFsEyw9y4Ah+xrnusWBUwrDjE906e34OVm+LEShgua3Qr9c/sqYiI vgQBFgoAZgUCVjjUol8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45FfvAQCmZYAypnKeGWV9ECEc7ztM7Bi3 BkWCXZ/8wQpmNRQyZgEAhefHRAmNIR9esTrgiNSmrtmDsdkjHNJn7UShfdEqbAw= =zKox -----END PGP SIGNATURE----- From neal at walfield.org Tue Nov 3 16:38:37 2015 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 03 Nov 2015 16:38:37 +0100 Subject: TOFU for GnuPG In-Reply-To: <1173808583.20151103153706@my_localhost> References: <878u6l93b8.wl-neal@walfield.org> <1574141659.20151030120614@my_localhost> <87y4ek7e28.wl-neal@walfield.org> <1299877596.20151103143256@my_localhost> <87fv0n6tdf.wl-neal@walfield.org> <908439596.20151103151857@my_localhost> <87d1vr6r0h.wl-neal@walfield.org> <1173808583.20151103153706@my_localhost> Message-ID: <87a8qv6qki.wl-neal@walfield.org> At Tue, 3 Nov 2015 15:37:06 +0000, MFPA wrote: > On Tuesday 3 November 2015 at 3:29:02 PM, in > , Neal H. Walfield wrote: > > > > The bindings are between user id and key. So, a new > > binding will be created. > > Will it flag up to the user that it is creating a new binding for a > known key? Or will there only be a prompt in the case that the new uid > matches one already stored in a binding to a different key? It will only flag an error if there is a conflict. Neal From aheinecke at intevation.de Tue Nov 3 16:56:27 2015 From: aheinecke at intevation.de (Andre Heinecke) Date: Tue, 03 Nov 2015 16:56:27 +0100 Subject: TOFU for GnuPG In-Reply-To: <87bnbb6qr4.wl-neal@walfield.org> References: <878u6l93b8.wl-neal@walfield.org> <46667157.oYpmE4WqK6@esus> <87bnbb6qr4.wl-neal@walfield.org> Message-ID: <2112518.B9tTPOCeFx@esus> Hi, On Tuesday 03 November 2015 16:34:39 you wrote: > At Tue, 03 Nov 2015 16:10:24 +0100, > > Andre Heinecke wrote: > > Don't we need to lookup the new key anyway to make validity decisions? > > Until then we assume "Unknown" trust. > > In the verify case, yes. But what about the sign case? We just see > that the old key has been revoked, but we don't know what the new key > is. I assume you mean the encrypt case (I don't see how this affects sign)? But still I don't see a problem there. If you don't have a valid key to encrypt to. You need to get a different key. How is the trust model involved in that? Once you have that new key you can do the UID / Signature checks I suggested. Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From neal at walfield.org Tue Nov 3 20:05:12 2015 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 03 Nov 2015 20:05:12 +0100 Subject: TOFU for GnuPG In-Reply-To: <2112518.B9tTPOCeFx@esus> References: <878u6l93b8.wl-neal@walfield.org> <46667157.oYpmE4WqK6@esus> <87bnbb6qr4.wl-neal@walfield.org> <2112518.B9tTPOCeFx@esus> Message-ID: <878u6e7vkn.wl-neal@walfield.org> Hi, At Tue, 03 Nov 2015 16:56:27 +0100, Andre Heinecke wrote: > On Tuesday 03 November 2015 16:34:39 you wrote: > > At Tue, 03 Nov 2015 16:10:24 +0100, > > > > Andre Heinecke wrote: > > > Don't we need to lookup the new key anyway to make validity decisions? > > > Until then we assume "Unknown" trust. > > > > In the verify case, yes. But what about the sign case? We just see > > that the old key has been revoked, but we don't know what the new key > > is. > > I assume you mean the encrypt case (I don't see how this affects sign)? But > still I don't see a problem there. If you don't have a valid key to encrypt > to. You need to get a different key. How is the trust model involved in that? > > Once you have that new key you can do the UID / Signature checks I suggested. You're correct, I meant the encrypt case. Let's say you want to send an email to Alice and she has revoked her key. Best practice dictates that you should run something like Parcimonie to keep your keyring up to date. So, let's assume that Parcimonie has also updated Alice's key. Now, when you try to encrypt an email to Alice, GnuPG won't let you, because the key is revoked. The question then becomes: how do you discover her new key? If we had a machine readable field, as I propose, GnuPG could tell you the new key id and even automatically fetch it for you. If we are using signature cross checking, then GnuPG can't help the user, because the new key is necessarily available locally. Note: the trust model is not relevant here. The issue of determining the new key is only relevant insofar as the TOFU code can suppress spurious conflict messages if it has this information. Thanks, :) Neal From gniibe at fsij.org Wed Nov 4 03:09:45 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 04 Nov 2015 11:09:45 +0900 Subject: Generating 4096 bit key fails =?UTF-8?B?4oCTIHdoeT8=?= In-Reply-To: References: <87oafk9iqh.fsf@vigenere.g10code.de> <5636C4B3.5050905@fsij.org> Message-ID: <563968E9.6050604@fsij.org> On 11/02/2015 06:40 PM, Felix E. Klee wrote: > On Mon, Nov 2, 2015 at 3:04 AM, NIIBE Yutaka wrote: >> It failed when gpg frontend tried to change the key attribute for >> RSA-4096. >> >>> [?] >> >> Do you happened to have (and run) old scdaemon of 2.0? > > Unfortunately that doesn?t seem to be the explanation. After starting > `gpg --card-edit`, I checked which version is running, and it?s 2.1.9: Thank you. It found it's my mistake. I reproduced this bug in my environment. I don't know the reason why it worked well for me, perhaps I tested with spare space between arguments when I did with gpg-connect-agent. Here is a fix. It will be in the next release. http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=c5a9fedba66361ddd9f596528882750068543298 -- From 2014-667rhzu3dc-lists-groups at riseup.net Thu Nov 5 18:29:22 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Thu, 5 Nov 2015 17:29:22 +0000 Subject: TOFU for GnuPG In-Reply-To: <878u6l93b8.wl-neal@walfield.org> References: <878u6l93b8.wl-neal@walfield.org> Message-ID: <87320720.20151105172922@my_localhost> Hi On Thursday 29 October 2015 at 2:06:51 PM, in , Neal H. Walfield wrote: > In particular, I'm > interested in learning how well this fits into your > work flow and whether or not you'll use it. I suspect I would use it, configured to ask my decision each time it encountered a new key/UID combination. My use of GnuPG is fairly limited: mainly participation in the PGPNET encrypted discussion group, occasional other encrypted email discussions, and signatures on a couple of discussion lists. > Note: GpgME has not yet been extended to support TOFU > so these messages might not be shown. I would think that was quite important, for users whose email client uses GPGME. -- Best regards MFPA A picture is a poem without words From neal at walfield.org Fri Nov 6 07:50:44 2015 From: neal at walfield.org (Neal H. Walfield) Date: Fri, 06 Nov 2015 07:50:44 +0100 Subject: TOFU for GnuPG In-Reply-To: <87320720.20151105172922@my_localhost> References: <878u6l93b8.wl-neal@walfield.org> <87320720.20151105172922@my_localhost> Message-ID: <87ziyr62pn.wl-neal@walfield.org> At Thu, 5 Nov 2015 17:29:22 +0000, MFPA wrote: > On Thursday 29 October 2015 at 2:06:51 PM, in > , Neal H. Walfield wrote: > > Note: GpgME has not yet been extended to support TOFU > > so these messages might not be shown. > > I would think that was quite important, for users whose email client > uses GPGME. Sure :). But, it was less important than implementing TOFU in GnuPG first. Thanks! :) Neal From 2014-667rhzu3dc-lists-groups at riseup.net Fri Nov 6 16:07:02 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Fri, 6 Nov 2015 15:07:02 +0000 Subject: Trusting other keys a message was encrypted to Message-ID: <120363958.20151106150702@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 While writing in the "TOFU for GnuPG" thread it occurred to me that GnuPG does not look at whether we "trust" the other keys to which an incoming message was encrypted. GnuPG looks at whether we "trust" keys we are about to encrypt to, and whether we "trust" keys that signed messages we have received. Wouldn't it be reasonable to also look at whether we "trust" other keys that are seen to be a party to the conversation? Of course, this could only work for keys that were not obscured by the use of throw-keyids or hidden-recipient or hidden-encrypt-to. And if another copy were encrypted separately, we know nothing about it. - -- Best regards MFPA Wise men learn many things from their enemies. -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJWPMIaXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwEcAIAJ6B95iRSPA/4KuUmbFW66x4 WzQblXacS/0YuwGM/A5U/qFxWVpt4AvhxMud6L1+HO8eHRBY+symfxAdPUsyL0Jw ojJBIH6fMKRBhRbNc8oKyO4LqqHP1tf4tpk6xGltu/YBHEv8LSflRh3NLJpzggQ7 qV4OcGo5HOzk7Ahu1UnhCmbGh1xpCiWun2Ng8erODFDimsTbh4mA9Iw06Gjo9/Yk R3tr9lwEiuz1uWlobnINd7sZ2fMTv2MeGLtEGmS+FIXr1bdCi9HBaDCgsmlCqdvD 9X/CboVx8pmxRHkneahTvtoYSMPwLF30Aglsi/4P82PotjM1k+QcpwkorMhqrVCI vgQBFgoAZgUCVjzCH18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45IhNAP0UQPVdDA7SO+y89jufHPiKe8v9 QnudR30dGMdZg72/WgD+PI/MsF35tfq6Iec5pkBrEgbqHet+4ala7JFgzcG1LAc= =WxRn -----END PGP SIGNATURE----- From vedaal at nym.hush.com Fri Nov 6 16:46:21 2015 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Fri, 06 Nov 2015 10:46:21 -0500 Subject: Trusting other keys a message was encrypted to In-Reply-To: <120363958.20151106150702@my_localhost> Message-ID: <20151106154621.B1BD6202BF@smtp.hushmail.com> On 11/6/2015 at 10:11 AM, "MFPA" wrote: While writing in the "TOFU for GnuPG" thread it occurred to me that GnuPG does not look at whether we "trust" the other keys to which an incoming message was encrypted. .... Wouldn't it be reasonable to also look at whether we "trust" other keys that are seen to be a party to the conversation? ===== GnuPG already does. It will ask for each key that you want to encrypt to, if you haven't trusted it, and ask if you really want to do this. Assuming that you trusted the person who sent it to you, then it's reasonable "for that person' to encrypt to other keys that that person trusts. You should encrypt only to keys you trust, and if they trust someone else's keys they can encrypt your reply to them. This will defeat an interesting man in the middle attack: Suppose Alice wants to encrypt to Bob, and Eve, and Rumplestiltsken, and sends a signed and encrypted message to Bob showing that it was also encrypted to Rumplestiltsken, whom Bob does not know. Mallory can intercept this mail, remove the ESK packet for Rumplestiltsken, make his own fake Rumplestiltsken key, and encrypt 'any' session key to it, and then add the ESK packet, and make a new checksum and replace it, and send on the message. Since you are not able to encrypt either the real or the fake Rumplestiltsken key, you have no way of knowing if the session key is genuine or not in that packet. Now if you routinely encrypt to all the keys when you reply, then Mallory can decrypt the message. A prudent workaround when encrypting to multiple keys, is to mention in the signed plaintext which keys and fingerprints are being encrypted to, and then if there is some pressing reason to multiple encrypt, then the receiver who trusts the sender's *trust* of the other keys, can go ahead and multliple encrypt the reply. vedaal -------------- next part -------------- An HTML attachment was scrubbed... URL: From vedaal at nym.hush.com Fri Nov 6 19:37:02 2015 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Fri, 06 Nov 2015 13:37:02 -0500 Subject: Trusting other keys a message was encrypted to Message-ID: <20151106183703.241A3203ED@smtp.hushmail.com> vedaal at nym.hush.com vedaal at nym.hush.com wrote on Fri Nov 6 16:46:21 CET 2015 : Since you are not able to encrypt either the real or the fake Rumplestiltsken key, you have no way of knowing if the session key is genuine or not in that packet. ===== Sorry, typo, meant to say decrypt instead of encrypt vedaal From 2014-667rhzu3dc-lists-groups at riseup.net Fri Nov 6 22:37:58 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Fri, 6 Nov 2015 21:37:58 +0000 Subject: Trusting other keys a message was encrypted to In-Reply-To: <20151106154621.B1BD6202BF@smtp.hushmail.com> References: <120363958.20151106150702@my_localhost> <20151106154621.B1BD6202BF@smtp.hushmail.com> Message-ID: <281549641.20151106213758@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Friday 6 November 2015 at 3:46:21 PM, in , vedaal at nym.hush.com wrote: > On 11/6/2015 at 10:11 AM, "MFPA" wrote: While writing > in the "TOFU for GnuPG" thread it occurred to me that > GnuPG does not look at whether we "trust" the other > keys to which an incoming message was encrypted. .... > Wouldn't it be reasonable to also look at whether we > "trust" other keys that are seen to be a party to the > conversation? > ===== > GnuPG already does. In that case, there must be some option or setting I have missed. When decrypting incoming messages that were encrypted to multiple keys, for keys other than my own GnuPG tells me the key-id and a few other pieces of information such as size and algorithm:- :pubkey enc packet: version 3, algo 1, keyid 0123456789012345 data: [2047 bits] # off=271 ctb=85 tag=1 hlen=3 plen=524 GnuPG also tells me (for keys not on my keyring):- gpg: encrypted with RSA key, ID 0x0123456789012345 Or if the key is on my keyring, GnuPG adds the primary key this encryption key is a subkey of, creation date and user-id:- gpg: using subkey 0x0123456789012345 instead of primary key 0x5432109876543210 gpg: encrypted with 2048-bit RSA key, ID 0x0123456789012345, created 20/01/2015 "Bob Alice Mallory" As far as I know, none of that says whether GnuPG thinks I "trust" the key. Or am I missing something? > It will ask for each key that you want to encrypt to, > if you haven't trusted it, and ask if you really want > to do this. I know. My original post included the line "GnuPG looks at whether we "trust" keys we are about to encrypt to". (-; > Assuming that you trusted the person who > sent it to you, then it's reasonable "for that person' > to encrypt to other keys that that person trusts. I'll partially go along with that. It was reasonable for the sender to encrypt to those keys because the sender "trusts" them; fair enough. But that doesn't address my question of "Is it reasonable for the recipient to want to check whether or not *they* "trust" the other keys to which the sender encrypted the message?" or my assertion that GnuPG does not perform this check. > You > should encrypt only to keys you trust, and if they > trust someone else's keys they can encrypt your reply > to them. Sound advice. > This will defeat an interesting man in the middle > attack: Suppose Alice wants to encrypt to Bob, and Eve, > and Rumplestiltsken, and sends a signed and encrypted > message to Bob showing that it was also encrypted to > Rumplestiltsken, whom Bob does not know. > Mallory can intercept this mail, remove the ESK packet > for Rumplestiltsken, make his own fake Rumplestiltsken > key, and encrypt 'any' session key to it, and then add > the ESK packet, and make a new checksum and replace it, > and send on the message. Some of the detail there is beyond me, but I think I get the gist. Presumably, the packets Mallory is tampering with are not covered by the message signature? > Since you are not able to decrypt either the real or > the fake Rumplestiltsken key, you have no way of > knowing if the session key is genuine or not in that > packet. OK. Doesn't that apply to all keys for which I don't have the secret part? Wouldn't that mean any key shown on the message's encryption list is potentially suspicious, except my own (and presumably the sender's, so long as it was used to sign the message)? > Now if you routinely encrypt to all the keys when you > reply, then Mallory can decrypt the message. For me, GnuPG would flag up Mallory's key if I had it, as you stated above. I may tell it to go ahead, or may not. If doing it in my email client, it would simply refuse to encrypt to an "invalid" key, and I would have to look into which it was. > A prudent workaround when encrypting to multiple keys, > is to mention in the signed plaintext which keys and > fingerprints are being encrypted to, and then if there > is some pressing reason to multiple encrypt, then the > receiver who trusts the sender's *trust* of the other > keys, can go ahead and multliple encrypt the reply. > vedaal The recipient might already "trust" some of the other recipient keys themself without having to rely on "trusting" the sender's "trust". Or they may know a reason not to "trust" one of the keys the sender was OK with. Especially if the latter applies, wouldn't it be better to check this on receipt of the message, rather than only if sending a reply? - -- Best regards MFPA Nothing a Pan-Galactic Gargle Blaster won't cure! -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJWPR29XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwyPkH+wUb5oL7B4pVBJM02lEzO+Jb dFRgcxHBmWmgv4uGX9d5O9tN1pxVPDGQRDW7W6ZBcB22+bQsyoUwkwPndBo4z+qj vCU9HEq5V1DzkhiU4/8YQBx8s09IufOrLGIz4PkYtVcUyrbSXFKXi2gPCVbttsEi U8LjtYGZPvm4wale2FAML4LlKf0XRacKAUYcvVkviPnZlCu7HGEZ9IgFeEoXr/l3 /ZHjB/lXDov4hlYwuLHZ51lAupIaG9Dgo4Ct9ra3ObE4YSSQPAQ3w5of3JSkaNMB nkmPk6MYVe766DzZddOu+ZYKVsnKw97ceyt00x2n5v5AE5N847gnC0aoZtiCa8yI vgQBFgoAZgUCVj0dxF8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45OXBAQClKpNpjNyu6z/WTLnb8QoU+OGD ZTFpKKVV47hAaa6hqgD/ZyumVTu1t/XUtNetuPym+CT79xUjSnk1xMOD8k1l7Qs= =GKlO -----END PGP SIGNATURE----- From kristian.fiskerstrand at sumptuouscapital.com Sat Nov 7 03:01:38 2015 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Sat, 7 Nov 2015 03:01:38 +0100 Subject: Trusting other keys a message was encrypted to In-Reply-To: <281549641.20151106213758@my_localhost> References: <120363958.20151106150702@my_localhost> <20151106154621.B1BD6202BF@smtp.hushmail.com> <281549641.20151106213758@my_localhost> Message-ID: <6D794D30-C482-4819-9917-E68EE8C0A13B@sumptuouscapital.com> [Sent from my iPad, as it is not a secured device there are no cryptographic keys on this device, meaning this message is sent without an OpenPGP signature. In general you should *not* rely on any information sent over such an unsecure channel, if you find any information controversial or un-expected send a response and request a signed confirmation] > On 06 Nov 2015, at 22:37, MFPA <2014-667rhzu3dc-lists-groups at riseup.net> wrote: > > I'll partially go along with that. It was reasonable for the sender to > encrypt to those keys because the sender "trusts" them; fair enough. > But that doesn't address my question of "Is it reasonable for the > recipient to want to check whether or not *they* "trust" the other > keys to which the sender encrypted the message?" or my assertion that > GnuPG does not perform this check. > > > I'm not really sure if I understand what this would protect against; The sender can send the information in multiple emails, even forward it unencrypted without you having any control of it. From 2014-667rhzu3dc-lists-groups at riseup.net Sat Nov 7 12:10:22 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sat, 7 Nov 2015 11:10:22 +0000 Subject: Trusting other keys a message was encrypted to In-Reply-To: <6D794D30-C482-4819-9917-E68EE8C0A13B@sumptuouscapital.com> References: <120363958.20151106150702@my_localhost> <20151106154621.B1BD6202BF@smtp.hushmail.com> <281549641.20151106213758@my_localhost> <6D794D30-C482-4819-9917-E68EE8C0A13B@sumptuouscapital.com> Message-ID: <866766129.20151107111022@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Saturday 7 November 2015 at 2:01:38 AM, in , Kristian Fiskerstrand wrote: > [Sent from my iPad, as it is not a secured device there > are no cryptographic keys on this device, meaning this > message is sent without an OpenPGP signature. In > general you should *not* rely on any information sent > over such an unsecure channel, if you find any > information controversial or un-expected send a > response and request a signed confirmation] At least that's better than the usual line from such devices, which reads more like an advert than a warning. (-; > I'm not really sure if I understand what this would > protect against; The sender can send the information in > multiple emails, even forward it unencrypted without > you having any control of it. Yes, anybody who was a party to the communication can share the information outside of the encrypted messages that were exchanged. We can't do anything about that, so should not worry about it. We should only worry about the security of the specific messages that we send or receive. For messages we send, in your own words "You should encrypt only to keys you trust". That is an active measure controlled by the sender. For messages we receive, we cannot control which keys were included in the encryption list. But we *could* check to see if any of them gives us cause for concern. Maybe there is a good reason this check is not currently done. The fact that information is available and *could* be used does not mean it necessarily *should* be used. - -- Best regards MFPA Penguins are not to be trusted, especially those who listen to organ music. -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJWPdwrXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwsxAH/3YvXP+TFANx/ZNbPef9/u3E vdr6xP/8t2LKlGtJJAPEzT4SN0fgLJu+fhtVnhgNp+ECQGUFpUST8f4Ph9aHGuyX oxJ1NnLcRB/mcVscGCbLvTSv9KJgwjfCKR99kZnssV1/Na/iCIaMH1U+9QhvRzDD u9MwaVxw4iUxWPnU1w/BpAboVZh7n+KJ3v9AwaBgxZxEXoL53z657t4c0b2Ck9tQ PLQhZP/9906NaEseRG7tE426aejMFEKoUDuzxhITzcRpn1DDZRzld2jJTtN4Edep NsIRXkeFr86i0fU91eHBWzMXcH9bOwoyaiBqlNrVgizznlPqMvgZEApjtOpfANuI vgQBFgoAZgUCVj3cMV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45FSrAP4xmrcp4uNk4TLmDS98EV+5/Hzz r3EWqBHjCtJpKh95kgD8DuXpTI7Ymavvn87Qw1s4XPoaAVzsu6pr2oHRT8mUCgc= =XjXp -----END PGP SIGNATURE----- From mls at dabpunkt.eu Sat Nov 7 13:30:53 2015 From: mls at dabpunkt.eu (Daniel Baur) Date: Sat, 7 Nov 2015 13:30:53 +0100 Subject: Trusting other keys a message was encrypted to In-Reply-To: <866766129.20151107111022@my_localhost> References: <120363958.20151106150702@my_localhost> <20151106154621.B1BD6202BF@smtp.hushmail.com> <281549641.20151106213758@my_localhost> <6D794D30-C482-4819-9917-E68EE8C0A13B@sumptuouscapital.com> <866766129.20151107111022@my_localhost> Message-ID: <563DEEFD.7080404@dabpunkt.eu> Hello, Am 07.11.2015 um 12:10 schrieb MFPA: > But we *could* check to see if any of them gives > us cause for concern. I don?t really understand what is the earn here. If I send a encrypted message to you and EvilPerson (together in the same eMail), you receive the email and gpg would warn you ?Heh, you don?t trust EvilPerson!?: What would improve? The EvilPerson received already the email, neither you or I could do anything about that. Sincerely, DaB. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 880 bytes Desc: OpenPGP digital signature URL: From 2014-667rhzu3dc-lists-groups at riseup.net Sat Nov 7 18:31:38 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sat, 7 Nov 2015 17:31:38 +0000 Subject: Trusting other keys a message was encrypted to In-Reply-To: <563DEEFD.7080404@dabpunkt.eu> References: <120363958.20151106150702@my_localhost> <20151106154621.B1BD6202BF@smtp.hushmail.com> <281549641.20151106213758@my_localhost> <6D794D30-C482-4819-9917-E68EE8C0A13B@sumptuouscapital.com> <866766129.20151107111022@my_localhost> <563DEEFD.7080404@dabpunkt.eu> Message-ID: <1483841819.20151107173138@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Saturday 7 November 2015 at 12:30:53 PM, in , Daniel Baur wrote: > I don?t really understand what is the earn here. > If I send a encrypted message to you and EvilPerson > (together in the same eMail), you receive the email and > gpg would warn you ?Heh, you don?t trust EvilPerson!?: > What would improve? The EvilPerson received already the > email, neither you or I could do anything about that. Having it flagged up to me that "EvilPerson" can also read the message may cause me to act differently in response to the message contents, or to act differently in future dealings with the sender. - -- Best regards MFPA Wise men learn many things from their enemies. -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJWPjWXXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXw5OcIALwgZcLRl11WG1mwyuzjmW8i reaIKU13/9jNnak8DE2lYqYiirC8NNYsKfG1s8PJGms703BXnSkjXAw+2Rj9X09C pkQonXSDXCJ5LwkNEj0ehQKR9rOleIA+ma3tg8JoMeYAn9cYKdXmXpBrXgvZ5Cmz daxcAi0mumVw+7jnxJdiG9PJQy6l0tBHX7D9KMc043NRO7WdO7BX/JPk+7PBzIT6 nFADysQTMNmgKgITcNU3kwcH64CwnLlig51Z7OZdYzPv07zP71WnU221beywHsp2 LsNg9qriHxFbq0cuYskOQAPhdinb+24jphLtdHklBugUsZD2mrFtd9/a3g/DlQiI vgQBFgoAZgUCVj41nl8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45AZwAP9IEA1+RlGR3wfdBNFqyZZlB5Y8 ZdNG5YS8V0G40YUtGAD7BuRH1mpSrihVOQBFhBR22DGZS5NaVt8Pws6KqwMyNgA= =hwsr -----END PGP SIGNATURE----- From kloecker at kde.org Sun Nov 8 20:48:46 2015 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sun, 8 Nov 2015 20:48:46 +0100 Subject: Trusting other keys a message was encrypted to In-Reply-To: <1483841819.20151107173138@my_localhost> References: <120363958.20151106150702@my_localhost> <563DEEFD.7080404@dabpunkt.eu> <1483841819.20151107173138@my_localhost> Message-ID: <5218342.OUena8rEHD@thufir> On Saturday 07 November 2015 17:31:38 MFPA wrote: > On Saturday 7 November 2015 at 12:30:53 PM, in > , Daniel Baur wrote: > > I don?t really understand what is the earn here. > > > > If I send a encrypted message to you and EvilPerson > > (together in the same eMail), you receive the email and > > gpg would warn you ?Heh, you don?t trust EvilPerson!?: > > What would improve? The EvilPerson received already the > > email, neither you or I could do anything about that. > > Having it flagged up to me that "EvilPerson" can also read the message > may cause me to act differently in response to the message contents, > or to act differently in future dealings with the sender. As vedaal explained, anybody between the sender and you can add arbitrary fake ESK packets to the message, e.g. a packet for EvilPerson's key. So, the attacker could make you think that EvilPerson could also read the message even though EvilPerson can't. Lacking EvilPerson's private key you have no way of telling whether the ESK packet is genuine or fake. Consequently, drawing conclusions solely from the presence (or absence) of other ESK packets seems like a bad idea. 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 2014-667rhzu3dc-lists-groups at riseup.net Sun Nov 8 23:32:25 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sun, 8 Nov 2015 22:32:25 +0000 Subject: Trusting other keys a message was encrypted to In-Reply-To: <5218342.OUena8rEHD@thufir> References: <120363958.20151106150702@my_localhost> <563DEEFD.7080404@dabpunkt.eu> <1483841819.20151107173138@my_localhost> <5218342.OUena8rEHD@thufir> Message-ID: <1591975445.20151108223225@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Sunday 8 November 2015 at 7:48:46 PM, in , Ingo Kl?cker wrote: > As vedaal explained, anybody between the sender and you > can add arbitrary fake ESK packets to the message, > e.g. a packet for EvilPerson's key. So, the attacker > could make you think that EvilPerson could also read > the message even though EvilPerson can't. Lacking > EvilPerson's private key you have no way of telling > whether the ESK packet is genuine or fake. > Consequently, drawing conclusions solely from the > presence (or absence) of other ESK packets seems like a > bad idea. Fair enough. - -- Best regards MFPA The meaning of life is to find your gift. The purpose of life is to give it away. -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJWP82aXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwbWAIAJWcoF0p6dDTo0nT+dZs4jg6 10IOlugNt6i59kaSbrCA89qHrl2s1dVcdFY/d3MRZ+T0qg1MnhtzRx+iSgwU7S1P ppdSH4qSmyx4afMcjKjXQJwMLI/g95zaSQjkj0r/WDXj5OE3x9LVj0fK6LG6oCdQ J/bAIuIeeH4dH2HeXtO6OYUUTY2TvxxB2BQUGRprqnaJm1EpS4GvJVCsFcAstAx3 ETwMe4T+7cHZ3X5WEymnlPzbF5SINWobwjoouQvZWr0t1bnJYoYtAtxoUhmFs4hs YlZGHO0gGRIvbmqxNVaPXRY1+vo3eWXAWnm876kFOL1iUua70jV0/wCLb8VP3aWI vgQBFgoAZgUCVj/NoF8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45J2/AQCnOFqLRGz0anMEVeKMYhbOwiYY JLvrkcbl9829d4PH8AEAih30CpicFipsG2aSRjEvAGVqgZWlldu0DPsfK6xl3AA= =F3+u -----END PGP SIGNATURE----- From beckus at beckus.eu Mon Nov 9 15:50:11 2015 From: beckus at beckus.eu (Christopher Beck) Date: Mon, 9 Nov 2015 15:50:11 +0100 Subject: SmartCard decryption issues Message-ID: <5640B2A3.4070002@beckus.eu> Hi folks, I'am using a GnuPG smart-card for a long time and it always works except one host :-( I have got two sub-keys on the card, one for signing and one for decryption. Both keys are 4096 bit in size. The issues are only on the decrpting process: Signing works well, but when I try to decrypt something (an e-mail or an encrypted file) it just says, there is no secret key. I switched on debugging output and it tells me: "public key decryption failed: General error decryption failed: No secret key" I checked $ gpg -K and $gpg --card-status and so on, and it tells me exactly the same i can see on my other computers: there are two keys available on the smart-card. So I am wondering, what the problem is. The version of gpg is 2.0.14 on scientific linux 6. Has anybody else issues using rhel 6 based distros? Or is there another way to check out, what problems gpg has finding the key for decryption? Thanks for any hints! Christopher Beck -- I use GnuPG (GPG) for e-mail encryption and signing. If you want some privacy, my public key ID is 2F9D4F14. The file "singature.asc" this message includes contains a cryptographic signature which enables you to verify this E-Mail really was written by me. Christopher Beck, DL1CHB Gerhart-Hauptmann-Str. 1 91058 Erlangen Tel.: 09131 / 9245437 Fax.: 09131 / 8148708 Jabber: beckus at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Tue Nov 10 02:53:14 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 10 Nov 2015 10:53:14 +0900 Subject: SmartCard decryption issues In-Reply-To: <5640B2A3.4070002@beckus.eu> References: <5640B2A3.4070002@beckus.eu> Message-ID: <56414E0A.5040707@fsij.org> On 11/09/2015 11:50 PM, Christopher Beck wrote: > I have got two sub-keys on the card, one for signing and one for > decryption. Both keys are 4096 bit in size. The issues are only on the > decrpting process: Signing works well, but when I try to decrypt > something (an e-mail or an encrypted file) it just says, there is no > secret key. I switched on debugging output and it tells me: > > "public key decryption failed: General error > decryption failed: No secret key" > > I checked $ gpg -K and $gpg --card-status and so on, and it tells me > exactly the same i can see on my other computers: there are two keys > available on the smart-card. So I am wondering, what the problem is. The > version of gpg is 2.0.14 on scientific linux 6. I think that 2.0.14 doesn't work well for RSA-4096 decryption on card. It was 2.0.20 (in 2013) which fixed this problem. (The error message was not kind enough, it's not correctly describe the issue.) The problem was, in short, the size of data. Smartcard was designed to handle "small" data, but RSA-4096 is a way big for old design assumptions. In case of signing, because the signature is not that big, it works well. It doesn't work for decryption, since the data size is 4096-bit (= 512-byte). Traditionally, smartcard was designed with the assumption of 256-byte is considered "big", and host software for smartcard assumed data size is less than 256-byte. -- From beckus at beckus.eu Wed Nov 11 09:31:39 2015 From: beckus at beckus.eu (Christopher Beck) Date: Wed, 11 Nov 2015 09:31:39 +0100 Subject: SmartCard decryption issues In-Reply-To: <56414E0A.5040707@fsij.org> References: <5640B2A3.4070002@beckus.eu> <56414E0A.5040707@fsij.org> Message-ID: <5642FCEB.9010404@beckus.eu> On 11/10/15 02:53, NIIBE Yutaka wrote: > On 11/09/2015 11:50 PM, Christopher Beck wrote: >> I have got two sub-keys on the card, one for signing and one for >> decryption. Both keys are 4096 bit in size. The issues are only on the >> decrpting process: Signing works well, but when I try to decrypt >> something (an e-mail or an encrypted file) it just says, there is no >> secret key. I switched on debugging output and it tells me: >> >> "public key decryption failed: General error >> decryption failed: No secret key" >> >> I checked $ gpg -K and $gpg --card-status and so on, and it tells me >> exactly the same i can see on my other computers: there are two keys >> available on the smart-card. So I am wondering, what the problem is. The >> version of gpg is 2.0.14 on scientific linux 6. > I think that 2.0.14 doesn't work well for RSA-4096 decryption on card. > It was 2.0.20 (in 2013) which fixed this problem. (The error message > was not kind enough, it's not correctly describe the issue.) > > The problem was, in short, the size of data. Smartcard was designed > to handle "small" data, but RSA-4096 is a way big for old design > assumptions. In case of signing, because the signature is not that > big, it works well. It doesn't work for decryption, since the data > size is 4096-bit (= 512-byte). Traditionally, smartcard was designed > with the assumption of 256-byte is considered "big", and host software > for smartcard assumed data size is less than 256-byte. Hi, thanks. Then I'll have to upgrade it. Best Regards Christopher -- I use GnuPG (GPG) for E-Mail encryption and signing. If you want some privacy, my public key ID is 2F9D4F14. The file "singature.asc" this message includes contains a cryptographic signature which enables you to verify this E-Mail really was written by me. Christopher Beck, DL1CHB Gerhart-Hauptmann-Str. 1 91058 Erlangen Tel.: 09131 / 9245437 Fax.: 09131 / 8148708 Jabber: beckus at jabber.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From bernhard at intevation.de Wed Nov 11 12:35:02 2015 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 11 Nov 2015 12:35:02 +0100 Subject: wiki.gnupg.org theme? In-Reply-To: <87vbgpx15k.fsf@vigenere.g10code.de> References: <201504211026.21749.bernhard@intevation.de> <87vbgpx15k.fsf@vigenere.g10code.de> Message-ID: <201511111235.07600.bernhard@intevation.de> Hi, I've added a section on the wiki theme to: http://wiki.gnupg.org/improveThis Maybe you can help with the currently open tasks: # Research: Is there a responsive MoinMoin theme that we could base our work on? # Build a Moinmoin theme prototype customized to gnupg.org look for testing. Best, Bernhard -------------- 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 bernhard at intevation.de Wed Nov 11 12:42:50 2015 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 11 Nov 2015 12:42:50 +0100 Subject: Java library for OpenPGP In-Reply-To: <5637C8DF.3060408@blazrsoft.com> References: <5637B656.40501@gmail.com> <5637C8DF.3060408@blazrsoft.com> Message-ID: <201511111242.51828.bernhard@intevation.de> On Monday 02 November 2015 at 21:34:39, Antony Prince wrote: > On 11/2/2015 2:15 PM, Julian wrote: > > Are there still other java librarys? Which of the librarys is the best > > one? > > You could take a look at the library written by guardianproject[0] and > see if it meets your needs. It creates a Java interface to GPGME. > > [0]https://github.com/guardianproject/gnupg-for-java Note that we also collect information about this here: * http://wiki.gnupg.org/APIs * http://wiki.gnupg.org/OtherFreeSoftwareOpenPGP -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- 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 fcassia at gmail.com Wed Nov 11 12:49:58 2015 From: fcassia at gmail.com (Fernando Cassia) Date: Wed, 11 Nov 2015 08:49:58 -0300 Subject: Java library for OpenPGP In-Reply-To: <5637C8DF.3060408@blazrsoft.com> References: <5637B656.40501@gmail.com> <5637C8DF.3060408@blazrsoft.com> Message-ID: On Mon, Nov 2, 2015 at 5:34 PM, Antony Prince wrote: > You could take a look at the library written by guardianproject[0] and > see if it meets your needs. It creates a Java interface to GPGME. > It's a JNI wrapper, in other words, Java code calling native C libraries code. It's not the same as a pure-Java library that is cross platform, like BouncyCastle "The Bouncy Castle Crypto package is a Java implementation of cryptographic algorithms. The package is organised so that it contains a light-weight API suitable for use in any environment (including the J2ME) " FC -- During times of Universal Deceit, telling the truth becomes a revolutionary act Durante ?pocas de Enga?o Universal, decir la verdad se convierte en un Acto Revolucionario - George Orwell -------------- next part -------------- An HTML attachment was scrubbed... URL: From gniibe at fsij.org Thu Nov 12 03:44:19 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 12 Nov 2015 11:44:19 +0900 Subject: Java library for OpenPGP In-Reply-To: References: <5637B656.40501@gmail.com> <5637C8DF.3060408@blazrsoft.com> Message-ID: <5643FD03.1080506@fsij.org> On 11/11/2015 08:49 PM, Fernando Cassia wrote: > It's a JNI wrapper, in other words, Java code calling native C libraries > code. > It's not the same as a pure-Java library that is cross platform, like > BouncyCastle > > "The Bouncy Castle Crypto package is a Java implementation of cryptographic > algorithms. The package is organised so that it contains a light-weight API > suitable for use in any environment (including the J2ME) " Yes, it's not the same. In my own opinion, it's better. I mean, a wrapper is (far) better for handling private keys, if our major purpose is privacy. If the purpose is learning technology or education, this would be different. Crypto computation with private keys by some runtime environment with garbage collector and/or virtual machine is... considered difficult, or wrong in some cases, perhaps. While I'd understand a wrapper is a bit difficult (say, debugging, for example), I recommend a wrapper in general, so that real computation is done by some real implementation. YMMV. I provide a view point. -- From sebastian at karotte.org Sat Nov 14 21:28:09 2015 From: sebastian at karotte.org (Sebastian Wiesinger) Date: Sat, 14 Nov 2015 21:28:09 +0100 Subject: What causes this bad signature Message-ID: <20151114202809.GA7962@danton.fire-world.de> Hello, for fun I tried a German government (or public-private partnership) service that signs your PGP key if your name on a uid matches the electronic data on your ID card (Neuer Personalausweis, nPA). I tried this and got my signed key back. I tried to import it into my keyring and imagine my surprise when it didn't show up. Reason being: I have "import-options import-clean" set and the signature is somehow bad. Is there a way to see why the signature is bad? If I decide to let them know that their service fails I would like to be able to tell them what they did wrong. My key is 0x58A2D94A93A0B9CE and their signature comes from 0x5E5CCCB4A4BF43D7: pub 2048R/0x58A2D94A93A0B9CE 2009-08-11 uid [ultimate] Sebastian Wiesinger sig!3 P 0x58A2D94A93A0B9CE 2015-03-27 never Sebastian Wiesinger sig-3 1 0x5E5CCCB4A4BF43D7 2015-11-14 never Governikus OpenPGP Signaturservice (Neuer Personalausweis) I attached the signed key for your interest. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant -------------- next part -------------- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: BCPG v1.51 mQENBEqBllMBCAD32fe447us8uLI13cnGkbPwizfxt5opcqaZYYt0BU4yHEONItL W021JK4BxSbPkOMUN7DWComy3mK5NWcQu3BepcRI9wD/l+01tjN3nH+nEZzYkO63 LbjApUlqJwovln+O1pcHBF9lSj4vDtkAa64EQ6c2oVGMTmjEqgwy6LRrR7pf6hmy hUJpvd5F4BecVZTOMbeNadYEuIN4PmC7MqpZdpaKAZ0efRjH96P3GyNEFEJLzNOC PxpYfKcEV3/vbK42Nsf7wZJtxEHXBJnWUH7Ewgo4bEg7TWwNsfsUD4UPrZnesRAC iv8X8Lu6+Xwh3mGvJYQVOpfQRdgS7Vs1rJLHABEBAAG0K1NlYmFzdGlhbiBXaWVz aW5nZXIgPHNlYmFzdGlhbkBrYXJvdHRlLm9yZz6JAWcEEwECAFEpGmh0dHBzOi8v d3d3Lmthcm90dGUub3JnL3BncC1wb2xpY3kuc2h0bWwCGwMGCwkIBwMCBxUKCQgL AwIFFgIDAQACHgECF4ACGQEFAlUV6PYACgkQWKLZSpOguc7O+QgAx9JS1IQoVoRp 3AD077o/cfmvudlP1Gj4gbruICeNfaOYoSIjW5uEG8n9YJwe9TsxsQhXE3TTKYB2 FaiWXhQQPle9LGj7/8/ixBJCkueD8pYepHH7Pra0y/obROSwDI+SEjwXtUZZ/a1b 2EOYWgm1yfIXYVFYwPhxYvFIt1sCTvDYFN2U9cbciXZ4TdRcRGdEMbAa71aKNYQQ Ych9cxcLMJkLm3/P9jwTJC6tXCBTRNRZBJ0SM3XnOi3T6f+cBurvo6I1z9dKwkZ1 5UKOyEfAw/db1mklRwCOIel144fVARGU05pAv/LGkmJrJU7qk51M5/TEbLYDinYu VmSDUZW4wIhwBBMRAgAwBQJKgZiaKRpodHRwczovL3d3dy5rYXJvdHRlLm9yZy9w Z3AtcG9saWN5LnNodG1sAAoJEBtgNPR2t58gWHsAn3damhwjmzWyRaHAvfV+jk5W 3v0IAJ9+Mv3DuRJfSh0jKunsP5oVw/2AIokBHAQTAQIABgUCSoJ4LQAKCRBZluk8 EY1oCJlWB/9V9b+w1SR+TWgiVDsR7hL1OtCrY2QI5ozWn8ZBb0qU2p1eQO7sWJ8W 225NIKPIpkd2OInBK9T8HAWv9PwNfwNGXbakFk04ng9+sxwfLXASwByek+PFaNlq sLA0buGZzyfGbs6mVaAF6uBSIb0QXVyFJ7aBiQJR0+uWjLD8glivYmatfH5v9xN/ 5OrKrlkQboCqUAGfc4RmmBWQhKPH5W3jm2jIFnAikJcDm+pR7qXvy/X0eIrLRfVj 2zt4He5l6wVAFFaw1X1dGziI+idKa30Pvn26Wh90/75ckwosyEcmxfdnloyMC6RY d/OquAzMaP1U5lm2MRpdyzZ2blQkGaf/iJwEEAECAAYFAkqzZA4ACgkQxOtrl0pn ggmpaQP9HP2ugAgaIwGqBNS9zktGcy1xCJ2b9Z1CZKm4WrDEwa4YI/C5yVzk5U3O X1pJDQhhr0BgH//VSYRF5g2BNxOmEyksFCbYo1nLD+mezHMHhvw+85JB6DrZPKQx 4frBHyG1gBVP+73VO2C7ZYSvgHSry59CE9PueDnJjInDnKqOcxWIRgQQEQIABgUC SrOc0wAKCRAIP1h/MP6Y6MHZAKDx5PjB6DC3l28Xswrl2eW+i9LWrgCdE1fSLbhe Xor4bwfauZUN8V18l/6IRgQQEQIABgUCSrOpqgAKCRCTUNZUduD9JEo2AJ94Xqps sBqIwYG0WaWdMmCBjz5Y+ACgxEidmhHoZrTFkjpjs8Zn4ajvfQCIRgQQEQIABgUC SrQKhQAKCRCAVDiX2/0r+VD1AJ9HvgToljbJNZ362ZY0dwyGZ7ZiUACeNhR+I9y8 f1eapWeXP/74sIkT/0WIRgQSEQIABgUCSrSE+gAKCRCO+R71kVI8PUcbAJ9cqXAn JmjxxpeBinwIXBMkUdjKoACeMVqIDOgQ8ei/23LDlcAdpdTuj7KIRgQQEQIABgUC SraDxQAKCRDcaLNyDB5Rm2RlAJ9/ZVdthYwd0V8FpznUQj/YU7noHgCeKjU/SxyD D5EcaPErBoWEoi6v5aeIRgQQEQIABgUCSraYnQAKCRAiS2X22/0bg0CkAJ9hW8Dl 9HWWyrlVDmvy2FfVsmGbcwCfU1rId/WMm7XJrUVPuV5h9EEKqxqIRgQQEQIABgUC SraZoAAKCRDWaU/WzTDil+qLAKCsP00/PD2govwM9oYrVsRGre/9hwCg0wvTwjBj Co+NYPlsrfI/+hq8i4mIRgQQEQIABgUCSrONXwAKCRB30d815/klJW2IAKCGrBXx /NmExU2Ya0T+xUaVTSCMYgCgnNKI/dL5zQrR/4LOgsv0uYtrvjeIRgQQEQIABgUC SsDxPgAKCRDpENBFMY4o7phZAKCHE9acDHiOXjPKko3UIjk1tzbP5ACff2mqE5db hYfwYzg5nbTrwKyu7ZuIRgQSEQIABgUCStmHmgAKCRA/aDjU1k1ynjwjAJ97ojgA MOOMvDYJdrIhvhidkDbNLACeP8ryVUGcEaMtK2zY5FN06Vbcj2eInAQQAQIABgUC Sxe+MAAKCRCpLgbjZVFJdS9PA/9yPn5pON9tjOZSsoqpXUX7d7q69bX5W7Rt5WOJ VtvS+ULJi1QKdzHhqsjQDrIv7HCQZ6SHtR+0EjQgufykQfrKoedZrshoZaYt353+ 2o4++RrxgLTOamc+x2RiBRG5XsKRXV4npIubVpmEiuXAFfrxHrQXIXLQieCP5RTC Hsxp6IkCHAQTAQIABgUCTH0RYAAKCRDULGmODHBaFb9JD/0QoOh8BV887Tvh5L5A VuuuShUyMUY7PMLOnFV72PeiHzkCLvEa+1c2ovMTnIDzJkJ1yf6aOgxILsi+/Ks+ 9kKTY4hIyLU4charHYPaQcOQgXrpj0LbF9NcYSMDVA60XMPltTUstiI+mew9yWwC Y39PC3Sn6wPLZsSQVf+gQgDIjPHLSCE235mHjIgkxf0uwbjSkE62HqPw+GJhM3Nn iGIj6lHdziev17jB7pSZ6hvg8T/bJtelty2QGau6wV4ANWC1L58B6rPVMM+Iwy2H oe83IqXpr/2GBKBvCbGRRdAehbCo5ww/wQ0YsKx2tX2QGyJHYdAST5VJgwIE6v00 baf88pUn2H44f8Zx6jhPHRRIjTHpZm9G4VcNMXronvzh8ODGK0NP2AmizK4XT/79 jkBrEuPo/tr3IIJlDi49GPjbBNBqYAofno2UjFQawkXlS5D20Oh2yOnogNjr/1IM JB5My6Mcs97tVGk0hJITUxuVGX/8T9UvKlCTD8KJ28tC+/rCTYILR3FkVCYR1j6G QDZVSobLXr/sZbIiwnKlQt2zVCYcASiIqPJbg/FxEPQHdmmWyESGj9JN/6fCxJcK 2KXUABntWwde+OHg0b8wIF33929GJNUhfFTSC2EiMSFNlV+zXGTWCOrobrh2nIYy HerngQ5ICLbk3SewPWZcQldB1ohGBBIRAgAGBQJMfQnHAAoJEGIhe6FARUfu45AA n1dusMPPylCQ+BsfJ3Yt+RExE1qsAJ9g+mxHYM0Vn6DiKJO30dToSici5YhGBBIR AgAGBQJMfQomAAoJEB43AjkW1rBGvaIAoLjB8x8bdZSK+NrcfprUSgQZOiG9AJ9K cXj8xvLwfnUC9shuRb25QDCcxYhrBBARAgArBQJO4qcHBYMB4oUAHhpodHRwOi8v d3d3LmNhY2VydC5vcmcvY3BzLnBocAAKCRDSuw0BZdD9WMgyAJ48p3DiWQoUYlPo 5EXM4J4wL68tQgCdGsVF1S3x6RiLd12S7ZRFUi1svZiJAZwEEAECAAYFAk+VSqsA CgkQr90bgi2gWs1Cawv/RIVwUtyVXZyZUYYC7IMNyirBLIXHoUzswAFdADuuPOde NERipPC/644jd8QznojZXEDCMLb0H0ddNKYYM8XoQYuF0WnSg9C3pcqPQrvPMQqz /HURdXNR5lORbVqQ7d5YFHmMbgqdLnvMx6/Z06hDMYN+6b88z/e7DjOQMwaMLJvJ cLMom9EnmIsxmGkjd/ix9lQN8lbWxjuag+NigSHQ0+iTWg+SpBiXRqWB43rWtyhT AYcvDqFW21bhG9ivdH9VxbFtzY6AsqcIh7yEVzyLVrWkyhhug5FOkypDEyqjPwtL 2HWiT2ENXDyDH+a0m6knOhtBrDo8OQPBEXSsJxzDCWyCfl0bSYTRIcj1L9dPyn46 yBsLg3kHdoOT014Fpc0stH8q8qn0O2ZnyDYeMQZl9XC0IWS1rHrTJQ2X2Bwgifkg zBkR+bjUHmsk4ftcXZvHh/dfyi/iwL0hO4gf3LcuHGI//TB7XlfQurT7Aqp24NAH 2vaICulxAXZ0LGYna7SyiEYEExECAAYFAlOxbCUACgkQK6489tr/sACftQCgkmb+ jBM0iNMf97CvrQsfer+6z1MAoLqBJPT2AUsEVx7zjhxB6pOCSR9BiQIcBBABAgAG BQJUW64KAAoJEN9WwGXkzn/FxBEQAIemODJ6julzYBwdt2fULfxL/DINtj2D/QuS /v7bv/lOOVeTxCo9nEBQBFfD5gyPRPEtfGiDVmC2MqfMuv+E2obRPV1nJ4TS/zm7 2iCLPsXNoXmxml3xPpdBcWHTY1JYJlMeoFDypl0PonatPyjQWe9YjJhkb88yDnGC CC/sbQch/b5eJgKupRYBoDwDmLf8STOLOzU8nkmOWaJKKu57H47yLpPDE4u/Ui3t 7xt2aK0A9VtExT2bUnrwNGueDBnCiq8MTXF8xQ/4bIezU31pshR4EGEhixT1Pziw nxffPpn0ApVdX3YlXL08xPsz6uR8S+vfTtkbybKa6BiW6H6LUn0LEvzoXCplt0Ca RP2uaQO9whAbfCVSrL9+0qN9WYy8YKn68V5eXH1RaNeg+D3Zl6JHPd3o4ktUyrv5 ZYNx8mmbw/ufRY3Kc1HELJmUVFoY/PvVMejWriT8RAH0XUlKfvew/U44IVHvwZo4 2CD1qbIu4QLZO0izre+vg5XwqwPLHkvCtOL+/ZmcRO1SsVpOGp9FeDUxtyH/+cTy 9AuMlaiR6ModZ4CiKznh5HX6LWdIQE/xfitmeSxwXe/Opz/ch2Ovtyh7cgjRIcft pt+yKo0/QT1So4LeMMOjaVSgvMD3QpappsP4wLMTLlIQ5cRPwVVBO2nHel+TedVs BZwVPSBRiEYEExEKAAYFAlVTY7YACgkQd/oaLTD56XltIACdHM7H5yUXTUAYSvip +v8L2ymLz1gAn0JRNjX88PBAFap/Ak6oegsgIWtJiQIcBBIBCAAGBQJVVFZOAAoJ EBXgoyUMySoFdu4P/31SlEqNOwZkPgC4/ZDsHXaq5uP3hh7pvuyeHyb98BOd9y6F eBZ0pvt3ZwRjeRmKnhCFPixsDRcHzF8CvstSr/QV0mxpGSfRXgmSh6z0FnGIeT8g KY2tMv5xy7cF768kQk9GFFQpPFbO9L7TNc9Oq6CWK2++IaKl+GDLLgFEUydO9rZS qro5hVpvQgYVHiUlRgRShVHgea9lxgDxLEshnPvHLKA2J2+5T8ja8WVbpSK+gAhs tkaFZRsH6ip0t2jAM8pa3VpIDpfPz7xScvG+fNY6PQp2TR8dusy2zUi433a6oxMU 94N9MEDQXN5IxEg50XbH6UEL4ch0V3Ehc11HEtJv8cb9rw+25ZlxuMMzpmDtzygk taEUr4bOrlUJGKzDsAC+L5/eV0z4tkFLLo5U7GTFYNhyuGMsUNw4Xb1jSfOgnYzs RBuEcOsp9gE2i5ohI96QCyQH/LumcKUemgWtThnCoTAc5IXyEQ6m+Uwd1xFegNz5 fK/ET3Kexn7Nf8aJzc1f8fRvEciLJY9AomYWm62XTCWRnbbaJm836PZDoeNYDiz+ t5bDcKi3+tlScTJvdgeqyuAz2W9lgvqaROMoP2efHlmkEar9DIihuKP6iEKQV8e5 BYb/98X0t6H2+q4jpipF6E15uVMHqNYMAOIo3KsHcnMXos64i/3hWDJRB3KIiQIc BBMBAgAGBQJVVHs/AAoJEPMGt0I/M2zSjbcQAK9QhWrK7ggB7Zu1AlUhdNPTAhzJ XGzzH8+gSsso9rOXI1has9NSLKP9kRXgN0M+yCOaYPThj8TdDTDnlIBRKqZxO+OP 8oipsNDnRKQVA5kO55cd82IRi/mnBd2fau3/tlqsPqoHuRxLrVaEN3RoAzLBRPNq sDyUTTstqA258IvCLh2kB//o1WdmeVypRNBJZFd4Tl+SimdBJaag5WaasXv+WA5z sg31ih2FggqPxWs8mOh1EQYDCHR0rBO7zOCmZRmk6+SNFGp6CLcZzW649WwuKzWC myEmd9Vr4vPOEjy76XgiE/uRLjTxfdSHrQejbOumaXaBIa3BjEar7S9bKfLkjUO/ B/mhGqCuYyMcW4/tMcf8UrIqHDvWKqQV8Fdis4hGOJhv16oARyS028pFP9mQ66ij bt6wi9gmIsDcGc7wgSvKX7plVMhCnaXao+FSekMfE8dxDAyh5Lh1Rvad+4ZFd21F 0aF7pOoPy8DMrZu36gPboaa+POg72cQxLkWHeY0TOauTlAWEcW9vAkW4DJ8aB2s4 PxuY2dz9jDb+DrQlez/sb58N0vTznzVED4pVLycz6ZrGf3abXShCy32H3oM5s7BK yEn9BBETs6jiF48CMECboWoRaCO18YFivfhfKc0hSY93iYxYkmcSUj1iRmeG65EG dDrl7ROZV11uXdY5iEYEEBECAAYFAlVUsCIACgkQncI+CatY949TyACfZEodxTLq Fs4QVzLZ7+WHo5TgWUkAn2kgw3Qaa6viu2eXANLWNow9LSiCiEYEExECAAYFAlVU cOsACgkQZTaqA2+Pqi/eqQCbB22Z8uLU5VheXfuirXu/VKmqmiAAnRPBZk2CpPSX 2ZGpfTcmejSzH8qviQIcBBMBCAAGBQJVV0WmAAoJEKnY9vIUvfudkkgQAIbesxcW 5x9JYVaG+2x5FFqsAuQwUDkt6VT3VMcbtaXyJqBXdx5RoWbHT1zwNuu8k2cbqRjb r30axP6c8TVNRXuf/Vw+iXeqWS7mUUQrb39iIF/sJ6NRoxiR8y/ZupG2SmePv5MB 8CyiJDc9CRO5IzdxXshq8aCX3mRy94m1PbCDbgbM4+JrA+p3TDuWcu4AxzL97Os7 DftZYRNYJdTcRozg84JNSE5kCazFk1gJLPlb0h0x3vRyrQJwCqo8mmSM4g81SLV2 zfOt3D3yW0NnurM01g0mS8q5IzJooISbKm0/ceIx1PC9m+0+QaXZNRr+PmRiSPtr aMaDrCv+VRdjd6nIFdx5YjKE+fKGwlKgSrz60tptuSziM1bfSJoa4yozWzul05yU 1hl3nRhkP99/JGfaNrZYzrUhtEZQLHgcHHi5/mbteX17NyxSrpSM4PUOqsvpX/c4 C/lUJ0OVRhWBcH8Vw1lzxbUMoxp3UcAO2fjqbG1igGPCOT/s1PZ+Bq4smGiKDvBs zHscETjyMMBuhSxgGedPqvbStMKQqAjDuUYFdnvZXwy456pO4VX0W3tYhbwn+GDd z6Kh7LNF+u/U0l38PjeQ5d+unNbRJcMfYQ6eBHsrx+uvFZu+reF0R/Z5XWqqeG1v CQiWKAGqx3aca4izRm5tj888m4TfGY9F+/RXiQIcBBABCAAGBQJVW2miAAoJEJ0L Xlse7I8ORkkP/0jeMG+MBjzAEuGeN2RH9JRfqgUNab+j+Fg3i5KmqjMemUZa3FJU 3w08OHrCR9GuOz6zh07xwePpnQAdEflk7u4YWYssqglethNocLNKyHJODrXvwiU4 ZTWNVcxfaR7BrsSMEerQNDEtxeigSVQwskKbLf39iXFxAoNnUvj+fOS3R6nDA+ht IA+gck3BTp5iYcj3GdS+uB10yyLI0PwReDp9EyhOqB5JNI5XVDKvhxXwP1Shf7rf VamuAP+TKgb6w9rAeGt+b4qouDawiHtvgYG353HaLPqki1EeXaFRoCNe0afBIF4g L176Nl63QaNaf6vjgv0o3qAhHg5uvIGmn99JoGocFFo88re8S/L+XcKiiuAYkWLV CiIoJTpsVV5fx05G3i9JxIOBUtUXsV6+T99zbF1qOEyuaTNDpGBvEatFonkCjrro oOLH+CvUrGK5wX3Gp/dVwxHFAqVz/ZIjg9dp3ekHPXbvrXQrgOIIm9qs+bTDjlpN +rouz6SEGorAmEbjWZKKDLM9yU6ryD6a8V/FoTUfIkQCvzHCHuZO580sDc9Bmg6+ PgZuF+UzflD40p49pUHJI2bePIINB0fLaSpILQzDAJJyJQysagjLCcdO07Az6hvB mrutkYCBTQayMkrcC5bqucu6ZMbfJ0IKTGPRtb8MchsLx0wOYfV6rj5EiQEcBBMB AgAGBQJVZiSoAAoJEGKng/KOLZWZyu0IAJaRB4X3RxeSLg4yt4fmkbneeoK5CreV suWKHWvvqcUqLKUgAZPlbiC846WtK07m08kTQ/F2G6GGawq79ZSFMZp2+w0s/ZXZ rC67kHdrp9BCN7cCo8o/3mHwlBRsOfRRikKwd1ZdVO5ziWxND0IWcRmY9vOwvyuh 06/Rokno7VOGs/0Ek4HzieL1mL/M+F6aeQY8dt5IS5Yty4t+WZmTvNIo+KC4XkvH YGveNoi2RAuHgkKH7gRCJ9FYQs2rm/A+PtCQH40jVPL07KdAvUUTz2Y/Q8Us42sX jU/n1LOaLBPVNFfZCcqhg7Wdz6K72MXhq8uIeH43DaDRQz/Sl0tKmtyJAhwEEAEI AAYFAlV5tKUACgkQvP56gx/YfPudVw//XqdCLZXklffaOGajs34ptLw7BBQeyLf5 IiV9bhHKTHa821BhSbwQF1trUbsIvSK0dJ4xfSFbbKpVzcA5Yq+y25RX4vT8wlrj r9512TEr/bDv/ZhVj7Sb5G+RJpOUDQW5mhJtIfMw+KpKPAlqS+6I7KqQAoAV/k5+ llTsvoEDwAsmEA+BwuGTbRYBsWTRHbo/vqZI7ZUukXhUU3d3gV88nur8ormk+/Rx uprG5tFVADpMiAH+kXB59+ttpDxuIz6SusQTNwltUi6Ur5aP5PD6lHLqF30UuRTx ig332mTlCF8In64/PvX5N0ymyAg12sLjTJe1x0ABUbNIryfQ3qs4g50TFqswUF/a Ht3DQUljjDdHNy27KU75Z2cD3HZLHK3d5SDM6xVT7cKqw50pMru+CN0bA8peRTXK qMYVdpIJii72PUIZUlotzZVM2kqdYEK1RB4WgaYr8iYwFoLmti1HjE7dSVMJa1zC SgohdS7aidaw1yL6xLzAuL4hUxlw/iITu0f0NTxiq1Tz6Mvosqv9JOAcDjSe2vtj ZCLFjUKuRuZAGDNHNUHouUqhVm8UcgdKwF1IMdaNWaaqPmGxlnCa5Gj0Fh40wUH7 uS//f1zFCsJXdc0fib3rTpzlOeaaKYg17OWsMU65kUut7Mzj/wUOtOLlG7j4HmVn /XEOQr2/UA2JAhwEEwEKAAYFAlWc55sACgkQ1Q/9s7nk69qRlxAAmJqoZFE85+4v raIBF67KSrBo3YPmJjaViZ7bC/ORfgoSNYeu6Udw4K9/2pvKzgl8na8PRREzf3Xx x1OjtV+leROYK0lg58o6FrtoWkM8zqADMQd5mhVVNxGJ080SRnfLzSig64vx0D+B DG09aWy7OQLNVzd8yoMsGvfpxV1ALLXQmEzvqvn6MwqhJ6RnrYrAfHMs1fK8gEwy Qsb/hwhTG/FYgSHyEqH2PpWAzmOCiiHx7HsBU404js5QIdd6e2/mVov1VgZQa7U4 fvT1q0eDh1M/rYMGjxgsgw372HSac76IoTRbb+dqTszb2e8uAzu92bvByf4JPLdQ x76yI6LZeBvQWnOFGuMgQdxmFS/B9T80EUENbVVBE4IyosQHtDrPjcazMXFzVQM/ lbkxPqA1Zjol8h9ihElWXfygv6eGtYYPBRZB3oUr32U1pEsnZ1rLeULlD1u4KN2a iAoHeMyVIhTlYWJ+E+FGfBfz7SnuAakNG2l13BhsE1/JOhy7/yN95xAzqOzMkxOj Vr9f7uDSIUxsXrh6OOUJLws4qHd6Ts/xrsgh8YteuNnrSleGToskKF0VMPU4nuwe jt5MFKp1s3R6elKv4WsdNjHMu/HxheHxRH9Zo8NvjiurYQmD6sWDHWHH441lqrgj YZF2pgb8aQfsagmXvnWjFnud+94qHnCJARwEEAECAAYFAlYyQQIACgkQbOy3T2DA suuR8AgAg3ryEiubGmzdIpsO4aUVkla9Td3EdHTQiCbKIUrLRPG/tapMB/bprF1O BKfKXVig208FUuT+OOCvxeGCeMEXC9It0vur1sfSpF2ALYTssha9aYeB48z65rsv nO6R7eGTYoRhe7PXbrpM1834lXsxIsS9j9v7qcZ903MYWBTYS8rRrJ128ww3m01V l2Lx6r0FHuU5MAUUzHRgv7pgPyWA1XsT1vHAg/NcQe68Q39cCW5ZizyDR+vK/dLc 8qTYf+Vs975dfc+t6sMEJZoWnAq23tPdGpZCIiIGOX4s5zGQGhK8NziIYjX9Wih4 6hSq2dfLRL4hKCIGH2MIpQh02kmh9IhGBBARAgAGBQJWNKBvAAoJEI2OPuD3c7zg +HEAnR5YFSQ5mUbOji02V1F6whQaxnMCAJ98TwoeJMqLYh49iS+xwUK9ChAadIhG BBIRAgAGBQJWNNZZAAoJEBnPpnbbhe+R+ogAniUxe6PS98TP53f4x8HoWbf9YEdA AJoDXO6dUfayR8aW3RHVIaZPaojoo4kCHAQSAQIABgUCVjTeqwAKCRBNDL/juXHZ 5glvD/9RV+iUyfctkgbfbhbmERC9sKe8h3jZsv4CmEde0Ff+4h6UF6/vzIKY3rLI r2LfLiglc7qC055njDuUZrKvtfIGqiU0UIejpsdHXFmrU+0Zl1WSXBynlOR7s6Qt KA4K0PcRT17Stdmrjt4pQHP+rJ9O6YmZhvLJdIol6E37DkvlMZsnWMer29KpVvaI 42EyHP86Rp8ganOazpjKwZ7PU5FRceHIbkV45zzGnOx8by0xjwpHtF+sZ70r2xRp ijlbBkuQy5YPF/yxYj0L2jKk+yOZ98QDhxJmgaqJ14NQpEmwco4zmiS/MoKV2apO D3TOmop0tF7ScgLFSrrV6ndwHLSTTfYYhabF3l1OEbTEN1Lx6/bTBNIdTQqLeEvZ Ibgoca2b5jJjwyIEd8YqyuG7VptQ+T8xOR2YZKnamrFdDlZn12w6l1e7UX7RRhHT 3bcozXkx1twa0E39bHMmQVjojRO9IcI1TO9q6kl/zLRfk5ypivcfbr9ASOl84kAf TXQRt37yIQoUg1JP92tn+YkSR/KXIAbdHHdn9tJgT9GVj1KMQcq1D8DV78Gb3L5C K+ogWT9TgomPEVOUsR1P14lJ3bNZv9DkLcoqQoFd29oYdEHSDPL3C3DDKfKu8kxC Mrj1hufEeESP+nGo5TFvnaJVeJAhGSsSWXgAnIS5LuF4m9f4MYkCHAQQAQgABgUC VjX0cgAKCRA5FdNsvHr6RmG6D/9yViKWpui1lpRoeOkIITn3upXXCcjn8QfpUZoo 4uqnrtiK6qi4Of8jMiBSfwq0PZTRvVdhH22Y7i0yyUbhs5HW6PGW0GNPtznes/ay P6qkNJ572VDBHR8mOkU9M+iv680728QnKRdUv3sMvUfY7X+RMol0ZWNFrShQ3Mh8 2DUnVi58dy4s4ssfiFGnzts5hBQ0ycAcEt1w1a4ol7C3dundgZZJfjOytwSc9S3O 3jBtMYS1Fc5HVyRIB/EftDqGCKKcF9apxSO0gPI3Ho4NWPPJ1cCzEwiLP27E0KFp 0D32uhG3nB9XenpxH3fJDdfhDutC/tF5jol1/jcTRD8kYqk9zdpX81piJUfyHdlj KLytulVyBkjW84u2vMAZ3iKHwAjo3O0lRnFVrI9ikOMXlPvrzv96RsMrmuUHnVyF sddH0dKAPGu5Qm06smtkEk3IfF9IcxmuqaEzn05w4vz5W+rq/9TuUflL71IDMnxl s/J7NvCdEbeJF3BcSma+i0e9rVO7J1x/a/FJCJNrztsv8Y3vR4qBpU7F8ZYRbNVf V1sRZOAhG/gMPLXspfb94iE5XKSgCphBb7GJycOHDZilrY4hInkZYevus64G7udW IGGhbtFlTAXbcKaWBpRIWmquj3JYSqU9r1S5Rs1rK6UKI9o1AaR1P087yz0VNvF+ MDmmi4kCIAQTAwgACgUCVkeSbgMFATwACgkQXlzMtKS/Q9eMLg/7BgEAxYryZtzV R1YU/0MjSLpS8DUXZkhbIyZKLIQm0ZHbcLiXq/WUwbvfwBEvloNjS0Kz9CCk09Ro zEQKoeB7hthV6D8n3pflQB5T4GJKqwGFZy7xLN6oH7HE8gQR7DaXytcNMvBK4Sjs Fsr6EOCD3qz95bf62qiOQkek0/Xch7OB1jF/WIBVzzPUmRZeAj4QzZih2xfZ/XVW EEYRGlbH1rWwh3mNjAwoGLaeD0b7tzZFFgWONlNdr/HmU2512hhLnuuxiGBPy8L3 jDYlE3aXirfJ1gIdGx7d67qooadrVBjDoDcKzn1Q59STlzx7Lje+KYCKpC8IPcUk NZnzs15rxcO6+tAf7bHZcmIcr6jNEO9/9y3YA+4gnBTSZhUMzzPNa5H9r2LVCiqu FzAySSo8/aYCtgkLULHQcAzXR3oppQdCrtwKriQMoG84uvze/iBPxSkpOBbS8Yns /VT1ZolPvf4mX4Zra5iMK0VELCC4ivQMScsgpuzz5UrCwmtmT60Sil9XTrcJ6SL7 s3n/acdvtBN5V9mBi0BZbB1PCI3uaEWdsPaRG6SYm+5y+E88+ToIc3M7M18FvK6N ZDpwrvVkzkwgiWKUj8DhuNO7IpZvCOh08PHEvi0JGpTBIvFjxht+/Ua72HMMoBok kEF5R/djjOhg6c2XgZ61OgFpUS7j2Xy0KlNlYmFzdGlhbiBXaWVzaW5nZXIgPHNl YmFzdGlhbndAZ251cGcubmV0PokBZAQTAQIATgUCUv0heCkaaHR0cHM6Ly93d3cu a2Fyb3R0ZS5vcmcvcGdwLXBvbGljeS5zaHRtbAIbAwYLCQgHAwIHFQoJCAsDAgUW AgMBAAIeAQIXgAAKCRBYotlKk6C5zmkaB/0QBlo4v3JojJpr3TQ1BuTnbfStxVww w4TcjVTj9UHuMGgoihQvVlCXTxoTo1arq7p0A99qEyKlcrU18+jNLJQ0mpef1iCH XBXEeooYDPe/bgOpYOXNivlI6iOxwnpMahL8LWLEdsRwM5rCi0w50f0MMajM/NhX 91gVZlCVHcABt2R4H5eIuDU8y+KW/gxNgdONDLn9XlsKFT6SDvnt4iQBrY3XUxq5 ZhpEh/X3NnUajeidisKKhScOIoZjh6c/5/WbicZW12xVEPk/aLeN0UR7KqInKa0S 0ZsNLJircAJ3j6mc6SckBBFhGreWDPi4SqQrHdsZi4M1VVxEBw8GOfk9iEYEExEC AAYFAlOxbCUACgkQK6489tr/sADnRgCgn3POw2WgeUwqeqvLzOVRwOMbCJUAoIa8 aO9jwtCMR2nR/u4df43b6/TQiQIcBBABAgAGBQJUW64KAAoJEN9WwGXkzn/Fif8P /ib7H/G1pjJOklTC/EwDsAOfNRysVo6ieePjt50XyaV8mXz9mVer9a3YwI7ha9zU jKDkp/pr865/Q/YsOsOFun1dYk/cKwOJeHzYcC1vB4tdwoAFXvR4guN2d2hPKLjp f/sZ4yIORUT3XfztfgIoDtdMVFbIC6joTgPvK2RQqHWGfQ7gZcVQ7gLWoowjf4nm 6hCJ9f6q/A20z7u/UmMLv4ZLe0C0rcgRFOaIdkVqAzJgdxaisGT539dtoaZzfwd9 iT6PYCodBNfMcFYj/TCcLDQfP6rSRHbcVbTxGIwWjKcQvVYgfzOPUKdesigfVuIL ObsGidtkhKqxIMdo7B5ScscZECRPB6gnL1gGCUkTMbLaO3K+15jy00+whr9epWgJ rlJ790qfRqDKnA+AAJ+CsTGxM5i9sbBcOsQ0kltq/B1UQC21LGXJp+2Km451gk3R gX/4EdayV5Tbvifgwsm4IDRi1iSIM62H/v8BKjDAN4+e3t9nQbI5m7qG0dGG+66u HKUlTZpuBC1WRQbhbwTi/7KBxRl9+kTmy5joykX1IileBkB3HTspHV0pb3yokchh N13EQAcgtxdJJPF5kfJfNdVKaZX/QX0wO6uCnHJATI78gZZSZGOv4XnntLz2cplp KPVnu6DB18dMSWFBvNfHhsGqowG5RfA/laOZ1BowfLNFiEYEExEKAAYFAlVTY7YA CgkQd/oaLTD56Xm/nwCg0DnGCuj2fPMN9jBbpHMPZkfcvBEAn3xM8TLI4vfHYbzm u+GQPr4FbkE2iQIcBBIBCAAGBQJVVFZOAAoJEBXgoyUMySoFwi4P/0J8zSKU53pE pP9rqoyL8b4Rfy9qYYpIo4aqhO9CAyH67D/xcnGzjEZxeUIK3wtO2FqH8YTg/nyD oPfDR4JRTpdcQ9NiEsNogVz572oXHbgYF+F4P5iC07cbaQsbtR+EdPdIZzBqNlj7 nBn5ewJtyJQYwyXBFhRLivKusgvZh/Bc/+I66XOPCi7hAAlVauC3ZJGfhfpC3Dq8 w5ZA9fiFkA+VImKsh85x2bj7XbDzw4jJns5u+u7PZ2E34EE+FcYDTuW9Ndxkstfv GJCQs9g9zrcHj60F9i51Gml0YtjANWzPvVO78X2F2Z7vPPfuFQfCYvU8tlDBoXEJ 5K0DBkKzjvkW1IFyBZXY+qiPKAuWwB0H2NxRr9Fcix0/rogOjXIlw0IJE4P5XoQm UlMR8631Lmifq0Kcqk1hSuTkiPgk5Op+BrVvv6nofwoVLfanxZQHdGI2eRT+qsVg gnKMuk3H2EW6xuOjNXlKV5II/4s5SkFT57ir2gUbXiTFFby8lmj9UXZuLsTpZDdO 3T+XCnODG33qFsp3p0T5p84vUM2XcnC1AY9IwosWoTjr0dJuyr5FMOoSGcmhmD+r chgzL/QO6OnqaT0gLp/mtSev/JZKSLxydi8A2JKXIK80chWY2ZR++kXOqtkEqxri lj1fh4UAavC2zbkmrWPa0ifIUXp5ovv3iQIbBBMBAgAGBQJVVHs/AAoJEPMGt0I/ M2zSl0gP93jmthFcPx3+B7Zb9NhY5klcH7oEJMXzMoa3yYGdF0xadaLzqOUbo169 RL9xPtPdMCCv8ce6y8Ycozhpd2sJ2rbTB52ssi3qrhjgExntjloVC5i6jMKB4Ey7 yxNQRhE2GJ42CN8ac7J/xIi5mQgQJU09WtKYVdLzB/gP3d5anomKsuWEscOmpevq VK46rNgtVzeIHvzTArAqX8YZE5wS/77+ZmLqflReforY/t3Pjl8JZ0ZnPLWf+YFh y+1ojoNs5vt5zfGOy3Q1PnE+5vU8+RdRpPF8yjTT7YX6/JEuXt2q8LwGOPzAEHhc 0/WH9LnuC/i23ZDeEFIl6lJHFMesY1iDovYqAqVriedp50i6TjYvlC02ix9jVFB1 3nfSVap3WXxrKYnfqkZatOp9/45q9R/yA+xT69y7p7B9ReVcE/VC0TTEBa9DFSn1 1oMLYUYLVy4F+IxQUwikDG1jCkFbMAo6c1wP9e0yOFN84bDTB2lEweUJ8z3vJ3qh L4eL505oOphyRaPnzw++SeCizDFEY5fkLN9CaOYQAmYSOSfKLA3/r/Vac+j3/B/p 9sToasYVbb9ZVDTUlEbAYTV6YQzNbHncmITs+bdurp4os5wMLsULj4NsTkW9njMJ H+x1D19zPdGmhWpTyEBR7KX8wyIEi419W2czZdcQYXKAlHpz1JSIRgQQEQIABgUC VVSwJwAKCRCdwj4Jq1j3j4htAJ9cpJj12YpGWtgHas341YR6sn5vWgCdFUaXKdz4 tm9s470AsauTuSrsMpOIRgQTEQIABgUCVVRw6wAKCRBlNqoDb4+qLwMLAJwPT61+ EPEkRz/ZIEy2M9Jranl6XACghPzsyS77zvNRDHNitV0fOjFI1IuJAhwEEwEIAAYF AlVXRacACgkQqdj28hS9+50g1w/9HcDRcK9I1dyoDkdf7mA+Irymm7/tA3tenfrl nkRQA5CXH72PzOFr8ViwlxWiLqrIPvaXzRf/XmdBbe5R8jnmJSVRAd7aBwfE3AdV OBQRJ2jgBJZ8lDmtsSESojDk+fkjuGAvb9ocAvtLyJTEClqE3JI3+i/j6M/ziOYN jMD1lUytAk2XA7TA8d6aV/Gj4C8Qa6RHo2JGUWJZR/BmKe7St4MvUvMAWrVYy6pp ++XGUoUhgqyaoHsEZHq8LIUNiVY+ZUGxBYvEb6JDGfzWWoQn+E6SgWjF2Qt3zlvh hlW+50OJxRVZfs6dDOWGbTrueX1tLwEi9iithfDUfg+J07czp3yuBQnxqYMORy65 PJPkMFaSDAE1Qj/yzhvnKCwdgzIABt1LDMc862d9oBOFjQmuX8cxUmf7iq2zwpbR TWwx5lrhjpz13wXPFCEE+6Av0rOdK9YPXRB+R5WhFv4YLKhNsqquTYu1OKl3N373 rZubdBEDoTCxMw39WePmh/Vhkl8HzdJCPIfSEvewFwDbAuOMdWnmvu1aOtlQs1Jt AmZ8yj96k27cfwE5PvSNYgoMaJzIJ3ZcuUR9KMPtLTl2BvrzU3hA/92bF3z4bcP2 ulZ4EB1zeqy5idQyPj0YuMMnQT7buCvoazTvh3uwO8SzbpDpTz+0jKg+4pidDUIU E8B/nEuJAhwEEAEIAAYFAlVbaaIACgkQnQteWx7sjw5VMhAA2LdwiIPqtfArOMa9 FzNpSskc3E4E6k2+7yHvl3hZEOWocmj0j7uqxVCbEXSxc2bXhG6amyN0duhLoD7z 69S9N+CFR3JOSbddrAYFcsoI5yO2ckg0qzwoTzzi9USEy4SNKcKgGlXmJSTx66aw 21PiY95b7smok2KxcFnqTtkpr4ViJHF0HO62DHkY9cY//C+N2DycHhlv90oMMP2y wJQ64RRN7HajC8CMqJFEQtZETvt5vrFHadEHJ5UCugbws3iCakemnxPez2DRXyQF Q9RBHd3If9yQMZLOlYV2BWbWxzCraqOTX0DS8f4bP2/V8H2WN6nwAc/MkZ1rWjBz i9jllLIww4c1X6BshEA9sfqIKl998zv6EJILn8u10ZUecBqm/G6R8NyJ1CBiEsFw 1XUIDhil5Bmaxsus6+HCqrQzt2IlpOuRWdkubuyZ1hW4N453pZX8Tk1+FB8YbWlH 2QjWB9KEuLpsckFJhnDQL16WqtyepeTFpK1mUVxlLPmHUeO/nZTXxwLpN/cNpKMj 4Jc7pEHt5KYbnIrJx8bSiZUUJxThl6baG0ogr0mYc++l8Zdujpp8tBOlHTSC4J7M fcfl8/mFZlrcygMecBTK+7MgLIsc+uMecCJwY5zmUsOuUY9K/KOz/nkSqbWXvyRn w3pNp3GnLsx+N8rU687d7oZPYCmJARwEEwECAAYFAlVmJKkACgkQYqeD8o4tlZkC xQf8Do9IIWOOA4DxC3omvxR/fSCLWYLUOlw218UYQCpu6k0OtHn1GV+QC1oWTyuP zg1L0ewhtbHc9Cvny8BFOpo3Y0QBhs1thZoDeA7rRVyslxK2xb1dUpoBO0FTTdxy UR53vC6t3VF80BZKNddxM7HWWjRlo4kF+L9Fx4iNhfg4g5ro/Mecv1x+ifhUweIa p12qdYD1wGH9PpaNmy5oNbbSTMZcPjY7x9jUABMIVoWVSY4RB+x+5WoGQZEyWu8D 6RDGXlXuCqJJWKPW/sJAkXTSSChY2DtNBM+YOyZchwEwakP2f/SgkSPn3fGU+cy5 qbbEYZ6df1iZKGwPtHmqgAl7yIkCHAQQAQgABgUCVXm0pQAKCRC8/nqDH9h8+2Zh D/42P8z645fmhRHwZR5fyxc+BB+0ScHYdE0VTYoEXLFEturmHl7+VcP3lBlU6Jvj aaTyLFgYHYB64es/UfJ+isDcGh85oT5i8EFtaL4wjMdT5q3AXlwUdr36nhgdM0NT S+m9Af1YsmlQeRsUTuHictulSzCZiWG71imMwsh21DBERvL5y4egFr7uhbcb+BRa q4OH4tbDEtYSaLQGlrnySGp0nwWU5qkbjkj/9uuRx7eYveYMgQXzjk41xu+KcyPD emgpWUGaarTE7hnU1SemEMIbaHNXIa0bEqaB8siT4Poay2bm/LEvy7Ln8udQuDbY gsV8X3ErFbcuAPpxUzx136dHJiLqk5VEgbLnK4o2mDbaZsvr/eJf8ZBIzgUKcSAo BxYBYEmbMVvoDynsZ44r/sDMSLVg/WkTkGiIhb3iJ8bLVAU5mVgQ53FNFdTyKlSa r3KKe1J/7fNz2gojx5JkCbdT4/DYFJmtpY0ixwX8PATtIrSr3lEX1kSlpjKV+ehr DP+m8UittUObuTsPBOWsNtnHTzYaOdYj3364efJz8+zit6ANq8GdcypSpVxPQOqK hH5lrqlGgYbOxVcZzaE9a7Y1ZpbEzT9A5DMxVZVNSYs3xI9QusmMDg/9edBxYCEl eqdc6dPbk09YHIgQYx9K8BKiDxI8OMzXgrEtny6Qsqc1u4kCHAQTAQoABgUCVZzn nAAKCRDVD/2zueTr2kKOEACLIC1oQGCyseZsNhX/KZYQp5gkm7zRoF0DAed/rVTl 9alFB7IjLega6dcHa+YPpy9Cez+iWxftJRPJx6CUwdgpb8a1SByVA4MT/jkcnyW+ tkLiM5G3xMeDcOcVBxOI5zzFuSvj+UUz2BHl2sRoGiP4oYHj5nXhLQ3LOSM3Sz24 B1/0IINDeqCCJ+NXqIvm1K0A36CsbjtpYrm3qcKmhrsV43T3RrgTXzX4SUphrMXx GHF6icRNG3knZYgMtIX8DkOK1YGu23klD8XsTGffWGrCoV+9XzosvEcZv3xeEBEl L4OUE4r6Fqt1yOvmFy3ncmVDtGnOs2dV9SK/CoWb0ZWXLKXUkQ8tZtXyT2Wa74T6 2RwGPIBw0GujJqIbwYKjSk8g5VaB0WFFgkyit/o1Z4PzikgiIqBajovgvqvx/D1v qsWYrUC4WhHtKo1jL/OLqLLDd3hmA2BHRNFSX3sUhh4QqnTHFeu+ynbCODOzSgEX vspqJKEDUMFFpmflXpyBy7t3W1s6j2ipad0PoxaUTf/m0mQ0kZu9N8eSMucOu8E/ +qmRPn6aM/lyH/5q+GgbhGOz57c1F8NNxpg8Mun/dYRHHByPuoA3N2/kbp+KTcs3 cKivGJSRrmpkhmOLCwH6tHWRge1hQtA0Cm8n4yYwyGdQ5ZhcXHtWR4/1N4AH2rtg 44kBHAQQAQIABgUCVjJBAgAKCRBs7LdPYMCy6/kUB/91EhojEyvnMERrRbB7pN/7 EPtx6CAOJWSGdpVQKhJmqJSUD+WqbX6Ev6eXu+i88Ip1TA0ay+EpnBanz2eKpReq 8/1gVLNRpygiEeZI1nPiYZ9QGU54nMOtDs2zha30KWqRAD/jXvm0WX069wddsSGQ nwz9GoyKW7iw6zY5ccIy/M0sBqL2aemKH5qUb3owvzMeOU+bDtbmx4xM9EvxVcTN b1j1hg4GUfvHSkfozeq6esc3qhfdpeErfy/NnfRZ1BSP8708lc5Vu0/ltJ7O1daZ 2qtnbkprJWh2PNkgo2llDwm3C9o9hZ1oVC/AlatXADVtismtmlM2V7yC+xQ4LBm0 iEYEEBECAAYFAlY0oG8ACgkQjY4+4PdzvOAgqACfbLsjDriuotNUYArDVSwCe1EC +J8An1ItTLshVjOgTGz9UJDNZDzIlVQIiEYEEhECAAYFAlY01loACgkQGc+mdtuF 75HmSwCfVAWM2qSFiB3X0lTMoFzEwnlePOgAoK7QPABqQ9vuw705vJ+rppkH+7sg iQIcBBIBAgAGBQJWNN6rAAoJEE0Mv+O5cdnm2vgQALW008gRRSA7aergF71g/GG3 kwB7LUGrAvR2vhPfUc7gTql4J2ILTAEXMWYEBjEir73Qo92tkBHzUcJUiv72uTKh vrEqe31WJ5svw4uZP1HDz3m+PcgrdKT9c0RUL6R2F6+uzQHL77Gx1lgMZI3ZvXrG l7AdWIiu1fPsbZogwsIJhVuB56Vz2GkS4JCO7MfJZrAZewk1S5ZckdJhVv55fQcD YGhksmdrcLwFzPwVmpcwp3RziwzOj+CAkao+tWIyeFLEW0aDhCtEkjwJmA2k+SEF vUMkXTp2Y16L7RZq2SbBsvzlibRmU0f6F9UvAKml4PTqh2A0sdB+iE08M59rB5nb mTgQUc7uUubwloWnkbf/7WBBtVh59L23IWD1fX4VNNKI9KD3xkJ/9vMK5Wdw7nf0 qasQKcrfUrCEi2yh2exOwJqpTLWmlm/0GAK1y+qcwh2EntHjiCV5ili8VTzlxcFo JKXQBCiXTFovyfAbjWsfPZ7gkRKOpYB9Kf4iKY7BwnueC15jKcBrudddoCyo6OPO FxrkDO6rf2OhM7ZZBsnSp2qkzgKaAL26yzbdE8ygJqmy1yN/7jS9TDSyFnvjNK4U ktPuNFjOCjiQUsMFSOCRfddBu/Ad1+flK3S60yduDXNLAUlGUhyr2/pdeElhVIbj ok2fRNktmt0D5+qUOLCTiQIcBBABCAAGBQJWNfRyAAoJEDkV02y8evpGjiMQAJ4u GxfR9XJPxiWGEJNwSkYLpJncXivvgpuuaugtMBNzx2RSWoZkLyqB15S0Sw7GVqQ4 17KSXevQQEIZdtLT8UhHfV8ApOk6rL3IokQUDlyRkOOKUrrK/SAkGwoRr0cQhmI4 Sztk7u25c1GygICTJG0jW2kBGDxtN0QXm62t9YiV1eFfYabPiw3MN7FCU/Zj+bL4 irVXn6SM6/FoVID96Wd+xSPjiEnIgS3Tv6n8Q1DQURIt6qu7YRye5Q/A04aouf4W P0yq9LAX9MYtcOa1s1FcvTRq2K1lBwwrwR9+rXpYPUdGoYaUulzMR+jiQLnzMMAX 9QQ6cKwDfihvJbFVHt24sI/SPaDWG5yIhDdWtMHxuaJQMqElF2lV6YKgfQTovCzW ic3/zt/giJ/icRgxNHA2HC8+sd8jNcEi40oN6MMMrWwoHH3QeRj6fPNLXo17SE15 fmdlunLdLGLq8gEr847UD0VKfHfuqwxjgp0nHB5/6C/39vk3S3AlSudJSguYDN8S /1cgzMgNoqLHHNphHQnr+wlXpyuxbrxSSaWY5ekVx6P/K0GQKAQ/gzN7ktnXpwh/ 46UjxzaO2CsL95wPGXbHu5JKH0IxV5DoEwXbOtP44V7sLUVCbgSAUIm3N8ClRjt+ /FoPvBMQgGSh+P1z9d2WyYlEjmi+lZdQZya0hQLK =2w1I -----END PGP PUBLIC KEY BLOCK----- From david at gbenet.com Sun Nov 15 03:03:06 2015 From: david at gbenet.com (david at gbenet.com) Date: Sun, 15 Nov 2015 02:03:06 +0000 Subject: What causes this bad signature In-Reply-To: <20151114202809.GA7962@danton.fire-world.de> References: <20151114202809.GA7962@danton.fire-world.de> Message-ID: <5647E7DA.6020104@gbenet.com> On 14/11/15 20:28, Sebastian Wiesinger wrote: > Hello, > > for fun I tried a German government (or public-private partnership) > service that signs your PGP key if your name on a uid matches the > electronic data on your ID card (Neuer Personalausweis, nPA). I tried > this and got my signed key back. I tried to import it into my keyring > and imagine my surprise when it didn't show up. Reason being: I have > "import-options import-clean" set and the signature is somehow bad. > > Is there a way to see why the signature is bad? If I decide to let > them know that their service fails I would like to be able to tell > them what they did wrong. > > My key is 0x58A2D94A93A0B9CE and their signature comes from > 0x5E5CCCB4A4BF43D7: > > pub 2048R/0x58A2D94A93A0B9CE 2009-08-11 > uid [ultimate] Sebastian Wiesinger > sig!3 P 0x58A2D94A93A0B9CE 2015-03-27 never Sebastian Wiesinger > sig-3 1 0x5E5CCCB4A4BF43D7 2015-11-14 never Governikus OpenPGP Signaturservice (Neuer Personalausweis) > > I attached the signed key for your interest. > > Regards Sebastian > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > Sabastian, Your key has been signed by 16 other people - all unknown. No ID apart from one 65D0FD58 - CA Cert Signing Authority (Root CA) though your key is fully detailed at http://keys.gnupg.net/pks/lookup?search=+0x58A2D94A93A0B9CE&op=vindex - may be you need to download your public key from a key server - always a good idea when you have uploaded it after your key has been signed. You can only use this signature for signing (not encrypting) and for certification. Bad? There appears to be nothing bad about this public key - why would you get 16 people to sign a key if you were not going to communicate with them? David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From gnupgpacker at on.yourweb.de Sun Nov 15 09:46:47 2015 From: gnupgpacker at on.yourweb.de (gnupgpacker) Date: Sun, 15 Nov 2015 09:46:47 +0100 Subject: What causes this bad signature Message-ID: <000001d11f82$298ea9c0$7cabfd40$@on.yourweb.de> Hi, there is a German government service that signs PGP keys?? What's the way to get it signed? Which institution? Thanks, Chris > -----Original Message----- > From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of > gnupg-users-request at gnupg.org > Sent: Sunday, November 15, 2015 2:54 AM > To: gnupg-users at gnupg.org > Subject: Gnupg-users Digest, Vol 146, Issue 7 > > Today's Topics: > > 1. What causes this bad signature (Sebastian Wiesinger) > 2. Re: What causes this bad signature (david at gbenet.com) > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 14 Nov 2015 21:28:09 +0100 > From: Sebastian Wiesinger > To: GnuPG Help and Discussion > Subject: What causes this bad signature > Message-ID: <20151114202809.GA7962 at danton.fire-world.de> > Content-Type: text/plain; charset="us-ascii" > > Hello, > > for fun I tried a German government (or public-private partnership) > service that signs your PGP key if your name on a uid matches the > electronic data on your ID card (Neuer Personalausweis, nPA). I tried > this and got my signed key back. I tried to import it into my keyring > and imagine my surprise when it didn't show up. Reason being: I have > "import-options import-clean" set and the signature is somehow bad. > > Is there a way to see why the signature is bad? If I decide to let > them know that their service fails I would like to be able to tell > them what they did wrong. > > My key is 0x58A2D94A93A0B9CE and their signature comes from > 0x5E5CCCB4A4BF43D7: > > pub 2048R/0x58A2D94A93A0B9CE 2009-08-11 > uid [ultimate] Sebastian Wiesinger > sig!3 P 0x58A2D94A93A0B9CE 2015-03-27 never Sebastian Wiesinger > > sig-3 1 0x5E5CCCB4A4BF43D7 2015-11-14 never Governikus OpenPGP > Signaturservice (Neuer Personalausweis) > > I attached the signed key for your interest. > > Regards Sebastian > > -- > GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) > 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE > SCYTHE. > -- Terry Pratchett, The Fifth Elephant > ------------------------------ > > Message: 2 > Date: Sun, 15 Nov 2015 02:03:06 +0000 > From: "david at gbenet.com" > To: gnupg-users at gnupg.org > Subject: Re: What causes this bad signature > Message-ID: <5647E7DA.6020104 at gbenet.com> > Content-Type: text/plain; charset="utf-8" > > On 14/11/15 20:28, Sebastian Wiesinger wrote: > > Hello, > > > > for fun I tried a German government (or public-private partnership) > > service that signs your PGP key if your name on a uid matches the > > electronic data on your ID card (Neuer Personalausweis, nPA). I tried > > this and got my signed key back. I tried to import it into my keyring > > and imagine my surprise when it didn't show up. Reason being: I have > > "import-options import-clean" set and the signature is somehow bad. > > > > Is there a way to see why the signature is bad? If I decide to let > > them know that their service fails I would like to be able to tell > > them what they did wrong. > > > > My key is 0x58A2D94A93A0B9CE and their signature comes from > > 0x5E5CCCB4A4BF43D7: > > > > pub 2048R/0x58A2D94A93A0B9CE 2009-08-11 > > uid [ultimate] Sebastian Wiesinger > > > sig!3 P 0x58A2D94A93A0B9CE 2015-03-27 never Sebastian > Wiesinger > > sig-3 1 0x5E5CCCB4A4BF43D7 2015-11-14 never Governikus > OpenPGP Signaturservice (Neuer Personalausweis) > > > > I attached the signed key for your interest. > > > > Regards Sebastian From martin-gnupg-users at dkyb.de Sun Nov 15 10:49:01 2015 From: martin-gnupg-users at dkyb.de (Martin Behrendt) Date: Sun, 15 Nov 2015 10:49:01 +0100 Subject: What causes this bad signature In-Reply-To: <000001d11f82$298ea9c0$7cabfd40$@on.yourweb.de> References: <000001d11f82$298ea9c0$7cabfd40$@on.yourweb.de> Message-ID: <5648550D.6030004@dkyb.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14/11/15 20:28, Sebastian Wiesinger wrote: > Hello, [...] > > sig!3 P 0x58A2D94A93A0B9CE 2015-03-27 > never Sebastian Wiesinger sig-3 > 1 0x5E5CCCB4A4BF43D7 2015-11-14 never Governikus OpenPGP > Signaturservice (Neuer Personalausweis) Am 15.11.2015 um 09:46 schrieb gnupgpacker: > Hi, > > there is a German government service that signs PGP keys?? > > What's the way to get it signed? Which institution? > > Thanks, Chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlZIVQkACgkQ/6vdZgk46sjncwCcDSubMfXbxp74+8/EGHaPK1J/ doMAoMUm5sblLnvguPBrIvPzhqz7cDsP =ZbiA -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Sun Nov 15 11:51:01 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sun, 15 Nov 2015 10:51:01 +0000 Subject: What causes this bad signature In-Reply-To: <5647E7DA.6020104@gbenet.com> References: <20151114202809.GA7962@danton.fire-world.de> <5647E7DA.6020104@gbenet.com> Message-ID: <1386156266.20151115105101@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Sunday 15 November 2015 at 2:03:06 AM, in , david at gbenet.com wrote: > why would you > get 16 people to sign a key if you were not going to > communicate with them? Don't people do that at keysigning parties, to strengthen the Web of Trust? - -- Best regards MFPA Act normal and the crowd will accept you. Act deranged and they will make you their leader. -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJWSGOcXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwZUwH/jJ95fYRO4l5FVaaTHM4cebE HSI2cMU3vuyOqiVVE1kdlk17mQUHiBQ1adK4Q9ZoIPKPqiETEUtq0kK22b7rVXQC DJRWJLu9mFeqUafGpjJd3eCUFLOzws8KTfY5JY7y8lasqAaeeI9AOopv8l4GiNSm mBoMQRO5jDCrt6zM6DhgssXwweakrVbZWw7YlFS3hHD1rPHQH08xOrJ2jIH+8kRZ dmV2uiZu8eKnD7TtW5ntBYntidPy85vh1df54LRTZ8lOMy27r/hwe4KZJkUXgpY1 A9iCtRKp9tr96utyrlEvfaP7LeWkJ6HSp/4XrAiIVDgKXL1S7U3h++OhlpLWgzaI vgQBFgoAZgUCVkhjnF8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45J2DAQDSaNBhP5UOBE9vfJfyQFkOLLyu EI8T9jBhY8iuvNWRIAEAh06UeNEbWOYt13jdrTran7+mfg4Np8lpFJ8S6hBTYgA= =Z+zW -----END PGP SIGNATURE----- From sebastian at karotte.org Mon Nov 16 16:01:28 2015 From: sebastian at karotte.org (Sebastian Wiesinger) Date: Mon, 16 Nov 2015 16:01:28 +0100 Subject: What causes this bad signature In-Reply-To: <5647E7DA.6020104@gbenet.com> References: <20151114202809.GA7962@danton.fire-world.de> <5647E7DA.6020104@gbenet.com> Message-ID: <20151116150128.GA20752@danton.fire-world.de> * david at gbenet.com [2015-11-15 03:06]: > You can only use this signature for signing (not encrypting) and for certification. Bad? > There appears to be nothing bad about this public key - why would you get 16 people to sign > a key if you were not going to communicate with them? Hello, my key is not bad, the signature by 0x5E5CCCB4A4BF43D7 is bad. The question is why. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant From sebastian at karotte.org Mon Nov 16 16:03:24 2015 From: sebastian at karotte.org (Sebastian Wiesinger) Date: Mon, 16 Nov 2015 16:03:24 +0100 Subject: What causes this bad signature In-Reply-To: <000001d11f82$298ea9c0$7cabfd40$@on.yourweb.de> References: <000001d11f82$298ea9c0$7cabfd40$@on.yourweb.de> Message-ID: <20151116150324.GB20752@danton.fire-world.de> * gnupgpacker [2015-11-15 10:39]: > Hi, > > there is a German government service that signs PGP keys?? > > What's the way to get it signed? Which institution? It's here: https://pgp.governikus-eid.de/pgp/ But as you can see the signature is not working. And the signature for my @gnupg.net UID didn't arrive at all. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant From felix.klee at inka.de Tue Nov 17 10:12:53 2015 From: felix.klee at inka.de (Felix E. Klee) Date: Tue, 17 Nov 2015 10:12:53 +0100 Subject: =?UTF-8?Q?Re=3A_Generating_4096_bit_key_fails_=E2=80=93_why=3F?= In-Reply-To: <563968E9.6050604@fsij.org> References: <87oafk9iqh.fsf@vigenere.g10code.de> <5636C4B3.5050905@fsij.org> <563968E9.6050604@fsij.org> Message-ID: On Wed, Nov 4, 2015 at 3:09 AM, NIIBE Yutaka wrote: > Here is a fix. It will be in the next release. > > http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=c5a9fedba66361ddd9f596528882750068543298 Thanks! Any idea when the next release is scheduled to be available? I tried installing the Git version into `/usr/local`, but that couldn?t interface with my reader?s PIN pad. From jameszee13 at gmail.com Tue Nov 17 13:32:03 2015 From: jameszee13 at gmail.com (James) Date: Tue, 17 Nov 2015 07:32:03 -0500 Subject: best practices for creating keys Message-ID: All, I'm just dipping my toes into GPG and am making a significant effort to "do things right" out of the gate. Based on my research, it is my understanding that "best practices" dictate we should have one master key with subkeys for specific purposes (personal work, "work" work, etc.). The master key is kept on an "offline" computer and then used only to revoke particular subkeys if needed. Is this accurate? Below is an article that seems to discuss precisely this subject. It's a bit dated (2013), so am looking for clarification on whether or not this is the _best_ way to deal with GPG, key pairs, etc. https://alexcabal.com/creating-the-perfect-gpg-keypair/ I've seen a few other StackOverflow questions about this matter and they all seem to recommend the same thing: create one master key, a subkey (or more than one) and use those instead of the master key for signing as needed. I'm particularly confused regarding the lexicon used in the article above, mostly because of my ignorance (as the article is rather clearly written). The author indicates that: - we create a keypair - added signing subkey - exported complete keypair _to TWO files_ (along with a revocation certificate) - removed original signing subkey and stash that away safely (in a safe, offline) My questions (and please forgive my ignorance): (a) when you create a the original keypair and export, it exports to _two_ files; how then, after adding another signing subkey, does the export also result in two files? Are both signing subkey keys (original and additional) embedded in your private key when exported? (b) is this all really necessary? Aren't your private keys, when secured via a password, encrypted via AES256? If you have a super secure password / passphrase, is this all really necessary? (b2) can someone please explain what sort of situation would be necessary for a private key that's been secured via a password is actually compromised? Are we talking about keyloggers, etc. here? Brute force? etc. (c) if your "laptop keypair" (terminology from article above) is compromised, data encrypted against that subkey will be compromised as well, correct? The only benefit to creating subkeys is that you can then revoke the subkey using your original signing key and let the world know that you're still "in control" of your identity, correct? (d) let's say you've used the laptop keypair to encrypt a wide swath of data (emails, actual files, etc.). If you revoke the laptop subkey because it's been compromised, can you still use that compromised keypair to _decrypt_ the data, or is it lost forever? Any thoughts / clarification appreciated. James From jameszee13 at gmail.com Tue Nov 17 13:39:53 2015 From: jameszee13 at gmail.com (James) Date: Tue, 17 Nov 2015 07:39:53 -0500 Subject: backing up keys Message-ID: All, I'm new to GPG and am hoping to learn the ropes. Please forgive any ignorant questions. (a) are there any recommended methods by which to back up your private and public keys? I've seen some "paper" methods (paperkey) and some GitHub gists that have taken the private key, broken it in several pieces and used QR codes to back up. Which is better? Does it matter? (b) is your public key embedded in your private key? If you're not actually uploading your private key to a keyserver (perhaps using the key to secure data / files instead of email, thus no need for keyserver), is it sufficient to back up the private key only, or _must_ I back up both files? (c) Isn't the private key itself encrypted via AES256 when secured with a passphrase? If so, assuming the passphrase is secure enough, isn't it sufficient to upload this file to Dropbox, etc. for safe keeping? Would appreciate both real-world and theoretical commentary on this point. (d) as best I can tell, the --armor flag is used to dump the key to ASCII. The gpg documentation[1] seems to indicate that paperkey works better at backing up to paper. Is there some reason why? Can't we simply run --armor, print the output and then use OCR to pull the key back in in case of emergency? Thoughts, ideas and real world experience on securely handling backups of your sensitive GPG data would be _greatly_ appreciated! James 1 https://www.gnupg.org/documentation/manuals/gnupg/Operational-GPG-Commands.html From andrewg at andrewg.com Tue Nov 17 15:33:40 2015 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 17 Nov 2015 14:33:40 +0000 Subject: best practices for creating keys In-Reply-To: References: Message-ID: <564B3AC4.50908@andrewg.com> On 17/11/15 12:32, James wrote: > > Based on my research, it is my understanding that "best practices" > dictate we should have one master key with subkeys for specific > purposes (personal work, "work" work, etc.). The master key is kept on > an "offline" computer and then used only to revoke particular subkeys > if needed. > > Is this accurate? Pretty much. You also need your primary private key if you want to update the details of your public key (as it needs a self-signature) and for certifying other keys (web of trust). > Below is an article that seems to discuss precisely this subject. It's > a bit dated (2013), so am looking for clarification on whether or not > this is the _best_ way to deal with GPG, key pairs, etc. > > https://alexcabal.com/creating-the-perfect-gpg-keypair/ This is a fairly good article - I've used it myself for reference in the past. Also have a look at: https://help.riseup.net/en/security/message-security/openpgp/best-practices http://spin.atomicobject.com/2013/11/24/secure-gpg-keys-guide/ > My questions (and please forgive my ignorance): Nothing to forgive! > (a) when you create a the original keypair and export, it exports to > _two_ files; how then, after adding another signing subkey, does the > export also result in two files? Are both signing subkey keys > (original and additional) embedded in your private key when exported? The two files are the public key (including all public subkeys) and the private key (including all private subkeys). Think of your keypair as a pair of matching tree structures: PUBLIC | (private) -------------------- PRIMARY | (primary) --SUB-- | (--sub--) --SUB-- | (--sub--) --SUB-- | (--sub--) Each "key" (singular) really consists of multiple keys (plural), a primary and some number of subkeys that are signed by the primary. This singular/plural inconsistency in terminology is probably the confusing bit. ;-) You can create as many subkeys as you like, but they can all be considered part of your "key" (singular). GPG will by default create a subkey marked usable for encryption only (as there are attacks against keys that are used for both encryption and signing). The best practice method above creates a separate signing-only subkey so that you don't need to use your primary key for signing messages. Your "laptop key" is then just your private key-tree with the primary private key safely deleted. > (b) is this all really necessary? Aren't your private keys, when > secured via a password, encrypted via AES256? If you have a super > secure password / passphrase, is this all really necessary? You just answered yourself below. ;-) > (b2) can someone please explain what sort of situation would be > necessary for a private key that's been secured via a password is > actually compromised? Are we talking about keyloggers, etc. here? > Brute force? etc. Keeping your primary private key offline does not help against brute forcing, but it does protect against keyloggers, rootkits, physical loss/theft etc. The only protection against brute force is key complexity/length, but brute forcing a properly generated key is vanishingly rare - you are much more likely to lose it by less glamorous methods. > (c) if your "laptop keypair" (terminology from article above) is > compromised, data encrypted against that subkey will be compromised as > well, correct? The only benefit to creating subkeys is that you can > then revoke the subkey using your original signing key and let the > world know that you're still "in control" of your identity, correct? Correct. As you worked out yourself, it is of limited use in the case of encryption subkeys (as anything encrypted against that key is now exposed) but it is VERY useful for signing and authentication subkeys, so long as you notice the loss and revoke them in a timely fashion. > (d) let's say you've used the laptop keypair to encrypt a wide swath > of data (emails, actual files, etc.). If you revoke the laptop subkey > because it's been compromised, can you still use that compromised > keypair to _decrypt_ the data, or is it lost forever? You can continue to decrypt with a revoked encryption key. Revocation does not make the private key unusable, it just marks the public key as "do not use". Best practice is to regularly revoke your encryption subkeys and regenerate them so that only a finite amount of data is encrypted with each subkey, limiting the impact of a disclosure. How often you want to do this is up to you - if you rarely get encrypted emails it might not be worth your while, but if you are a heavy user then I'd strongly recommend it. 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 andrewg at andrewg.com Tue Nov 17 15:53:01 2015 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 17 Nov 2015 14:53:01 +0000 Subject: backing up keys In-Reply-To: References: Message-ID: <564B3F4D.2010701@andrewg.com> On 17/11/15 12:39, James wrote: > All, > > I'm new to GPG and am hoping to learn the ropes. Please forgive any > ignorant questions. > > (a) are there any recommended methods by which to back up your private > and public keys? I've seen some "paper" methods (paperkey) and some > GitHub gists that have taken the private key, broken it in several > pieces and used QR codes to back up. Which is better? Does it matter? "Better" really depends on your use case. Are you likely to forget your passphrase? Are you going to keep your USB backup drive in a floor safe? Are you expecting your home to be searched by the feds (or the mob)? I don't think there is One Correct Answer to that one... > (b) is your public key embedded in your private key? If you're not > actually uploading your private key to a keyserver (perhaps using the > key to secure data / files instead of email, thus no need for > keyserver), is it sufficient to back up the private key only, or > _must_ I back up both files? No, there is no public key data embedded in the private key, but you can regenerate the important mathematical bits of the public key from the private key, and you can fill in your name, email etc. from memory. So it's not absolutely necessary - but it is convenient. Of course, the backup of your public key does not need to be secure. > (c) Isn't the private key itself encrypted via AES256 when secured > with a passphrase? If so, assuming the passphrase is secure enough, > isn't it sufficient to upload this file to Dropbox, etc. for safe > keeping? Would appreciate both real-world and theoretical commentary > on this point. Brute forcing a password is always easier than brute forcing the key itself (otherwise you'd be typing in your entire private key by hand!), so if (when) dropbox do leak the key data you've given the Bad People a shortcut. > (d) as best I can tell, the --armor flag is used to dump the key to > ASCII. The gpg documentation[1] seems to indicate that paperkey works > better at backing up to paper. Is there some reason why? Can't we > simply run --armor, print the output and then use OCR to pull the key > back in in case of emergency? That's fine if your OCR is perfect and your paper never gets folded or stained or torn, but ascii-armored data has no checksum or error correction so you may suddenly discover your paper backup is unusable. And such discoveries usually happen at the worst moment. ;-) 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 pete at heypete.com Tue Nov 17 16:16:56 2015 From: pete at heypete.com (Pete Stephenson) Date: Tue, 17 Nov 2015 16:16:56 +0100 Subject: backing up keys In-Reply-To: References: Message-ID: <564B44E8.70405@heypete.com> On 11/17/2015 1:39 PM, James wrote: > All, > > I'm new to GPG and am hoping to learn the ropes. Please forgive any > ignorant questions. No need to apologize: that's how we all learn. > (a) are there any recommended methods by which to back up your private > and public keys? I've seen some "paper" methods (paperkey) and some > GitHub gists that have taken the private key, broken it in several > pieces and used QR codes to back up. Which is better? Does it matter? In addition to the security of your backups, one of your concerns should be "How easily can I recover the key?" If the procedure is complex, error-prone, and/or relies on the availability of certain software that might not be available, it may be less likely to work in the future. Also, as Andrew says, what's your use case? Protecting your backed-up private keys from you being forgetful or a destructive event like a house fire or flood is different from protecting your keys from active adversaries backed by force of law (e.g. feds with search warrants). Using myself as an example, my two primary keys are each backed up to a set containing: 1. Two CD-Rs from different manufacturers (for reliability). 2. Two USB flash drives from different manufacturers. 3. A Paperkey-produced printout. 4. A printout that consists of the ASCII-armored private key printed in an OCR-friendly font. Additionally, each printout contains a QR code of each line of the ASCII-armored private key so I can easily scan each line without having to manually type everything in. Obviously, recovering the key from #1 or #2 is the easiest, while #3 and #4 are for last-resort recovery. For my RSA primary key, I also keep a copy of the primary key on an OpenPGP Smartcard which is kept with the set. For each key, I make two such sets: one set stays at home in a locked box, while the other is in a safe deposit box in a bank thousands of miles away near my in-laws. Additionally, I store printouts of revocation certs for those keys. Since I have the private keys backed up, they shouldn't be necessary, but you never know. Overkill? Perhaps, but I've lost private keys in the past and it's a pain. My main concerns are loss/destruction of the keys and electronic compromise: thieves are more likely to care about my TV and shiny computer rather than my PGP keys, and the authorities are unlikely to care enough about me to seize the keys from my home or the bank vault (even if they did get them, they'd need to crack the passphrase). Your mileage may vary. What if you can't recall the passphrase? You may have the encrypted private key available from your backups, but if you don't have the passphrase it won't do you much good. Here's a few ideas for what you could do: 1. Split your passphrase up using something like Shamir's Secret Sharing (a handy tool for accomplishing this is http://point-at-infinity.org/ssss/) -- you can keep some shares for yourself and give others to friends for safekeeping. Shamir's Secret Sharing allows you to set a threshold for the number of shares needed to recover the secret. For example, you could generate ten shares and require three to recover the passphrase. You keep three shares for yourself (so you can recover the passphrase any time you want) and give seven to friends. If your house burns down and you lose your shares, you'd just need to ask any three of those friends to give you their share and you're good to go. Any adversary that has fewer shares than the threshold (e.g. if they only have two shares) gains no insight into your passphrase, which is useful for security. 2. Print out your passphrase and store it with the backup set. While handy, this has the disadvantage of also revealing your passphrase to anyone who has access to the backup set (e.g. a thief), though at that point you probably have bigger problems like bad guys breaking into a bank vault or your home. 3. Backup the private key with no passphrase. This is the easiest, but also the most risky: anyone who gets your key is able to use it without needing the passphrase. > (b) is your public key embedded in your private key? If you're not > actually uploading your private key to a keyserver (perhaps using the > key to secure data / files instead of email, thus no need for > keyserver), is it sufficient to back up the private key only, or > _must_ I back up both files? For clarity, the private key is *never* sent to a keyserver, only the public key. The private key and public key are mathematically related: if you have the private key, GnuPG can automatically generate the public key. The reverse, of course, is not true. Put a different way, it can be handy to backup the public key, but it's by no means necessary. > (c) Isn't the private key itself encrypted via AES256 when secured > with a passphrase? If so, assuming the passphrase is secure enough, > isn't it sufficient to upload this file to Dropbox, etc. for safe > keeping? Would appreciate both real-world and theoretical commentary > on this point. In theory, you could certainly upload the file to a semi-private service like Dropbox, or even publicly post your encrypted private key on the web and it would be secure, assuming you had a strong passphrase. I wouldn't, since I prefer to have layers of defenses. Guessing my passphrase is only useful if an adversary has my key. Short of ninjas stealthily breaking into my home or the bank vault, there shouldn't be any way of obtaining my private keys in a way that is not easily detectable. > (d) as best I can tell, the --armor flag is used to dump the key to > ASCII. The gpg documentation[1] seems to indicate that paperkey works > better at backing up to paper. Is there some reason why? Can't we > simply run --armor, print the output and then use OCR to pull the key > back in in case of emergency? Sure, you can. I do (#4 on my list above), but only as a last resort. However, OCR isn't perfect. Is that "0" the number zero or the letter "O"? Is that "1" the number one, a lowercase "ell" or an uppercase "eye"? What if there's a smudge? Do you want to go character-by-character checking that each character is correct? That's a pain, especially with large keys: DSA and ECC private keys are relatively small and can be manually entered and verified without too much trouble, but RSA keys can get positively massive. Paperkey adds some checksums that help identify errors. QR codes have redundancy and error correction and can be (relatively) quickly scanned with a common webcam. This helps reduce the possibility of error and speeds up recovery. > Thoughts, ideas and real world experience on securely handling backups > of your sensitive GPG data would be _greatly_ appreciated! Cheers! -Pete From pete at heypete.com Tue Nov 17 15:31:23 2015 From: pete at heypete.com (Pete Stephenson) Date: Tue, 17 Nov 2015 15:31:23 +0100 Subject: best practices for creating keys In-Reply-To: References: Message-ID: <564B3A3B.7090001@heypete.com> On 11/17/2015 1:32 PM, James wrote: > All, > > I'm just dipping my toes into GPG and am making a significant effort > to "do things right" out of the gate. Welcome! > Based on my research, it is my understanding that "best practices" > dictate we should have one master key with subkeys for specific > purposes (personal work, "work" work, etc.). The master key is kept on > an "offline" computer and then used only to revoke particular subkeys > if needed. > > Is this accurate? At the risk of being vague, "best practices" depend on your situation. The recommendations for someone wishing to exchange private love letters with their spouse is far different than someone who would be subject to physical harm, torture, etc. if the content of their messages were revealed, or if an adversary were able to spoof messages appearing to come from that person. That said, using encryption and signing subkeys for day-to-day operations and keeping your primary key safely stored and backed-up offline is a reasonable and sensible thing to do in nearly all circumstances. > Below is an article that seems to discuss precisely this subject. It's > a bit dated (2013), so am looking for clarification on whether or not > this is the _best_ way to deal with GPG, key pairs, etc. > > https://alexcabal.com/creating-the-perfect-gpg-keypair/ > > I've seen a few other StackOverflow questions about this matter and > they all seem to recommend the same thing: create one master key, a > subkey (or more than one) and use those instead of the master key for > signing as needed. Yes, this is a reasonable thing to do. > I'm particularly confused regarding the lexicon used in the article > above, mostly because of my ignorance (as the article is rather > clearly written). The author indicates that: > > - we create a keypair > - added signing subkey > - exported complete keypair _to TWO files_ (along with a revocation certificate) > - removed original signing subkey and stash that away safely (in a > safe, offline) > > My questions (and please forgive my ignorance): > (a) when you create a the original keypair and export, it exports to > _two_ files; how then, after adding another signing subkey, does the > export also result in two files? Are both signing subkey keys > (original and additional) embedded in your private key when exported? The two files consist of, respectively, the (a) private and (b) public components of that keypair. In the directions provided at the link you mentioned, one creates the primary key (which consists of the primary signing key and an encryption subkey) and later creates a second signing subkey. This bundle of three (sub)keys is exported for offline storage and backup. There are separate exported files for the private components and public components. Later, the primary signing key is removed from the online system and only the subkeys remain. If one later wished to backup this subkey-only set of keys, they would be able to export the public components of all three keys but only the private component to the subkeys. The private component of the primary key would not be available for export since it only exists in offline storage. > (b) is this all really necessary? Aren't your private keys, when > secured via a password, encrypted via AES256? If you have a super > secure password / passphrase, is this all really necessary? Yes, your private keys are encrypted and protected with your password. However, this does little good if an adversary is able to compromise your computer, copy the encrypted keyfile, and install a keylogger so they know what password to use to decrypt it. For typical users, this may not be an issue, but you never know. In the case where a subkey is compromised, it can be easily revoked and a new one generated. In the case where one's primary key is compromised, it would also need to be revoked and a new one generated, but it also means that one would need to start from scratch to verify their identity to correspondents and gain signatures from others -- the primary key represents one's identity and reputation, so to speak, and rebuilding that can be time-consuming and tedious. Far better to take a few extra minutes generating a signing subkey and moving the primary key to offline storage than dealing with the headache of re-bootstrapping a new primary key. > (b2) can someone please explain what sort of situation would be > necessary for a private key that's been secured via a password is > actually compromised? Are we talking about keyloggers, etc. here? > Brute force? etc. Assuming one has a strong password, brute force should be infeasible. Keyloggers are a definite risk. > (c) if your "laptop keypair" (terminology from article above) is > compromised, data encrypted against that subkey will be compromised as > well, correct? The only benefit to creating subkeys is that you can > then revoke the subkey using your original signing key and let the > world know that you're still "in control" of your identity, correct? Correct on both counts. Additionally, if the signing subkey in the "laptop keypair" is compromised, the adversary can sign messages claiming to be from you, at least until your correspondents check to see if your key is updated and are able to get the revocation notice. In some cases, this is a greater risk than the adversary being able to read private messages. > (d) let's say you've used the laptop keypair to encrypt a wide swath > of data (emails, actual files, etc.). If you revoke the laptop subkey > because it's been compromised, can you still use that compromised > keypair to _decrypt_ the data, or is it lost forever? A revoked encryption subkey can always decrypt messages that were encrypted to it. However, other users cannot encrypt new messages to a revoked encryption subkey (assuming the sender knows its revoked, which is not always the case). > Any thoughts / clarification appreciated. I hope this helps a bit. If I can clarify things more, please let me know. Again, welcome to the world of GnuPG. Cheers! -Pete From rjh at sixdemonbag.org Tue Nov 17 16:45:07 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 17 Nov 2015 10:45:07 -0500 Subject: best practices for creating keys In-Reply-To: References: Message-ID: <564B4B83.6020902@sixdemonbag.org> > Is this accurate? Not really, no. One of the weirdest things about OpenPGP (and, by extension, GnuPG) is that it provides a great deal of mechanism and very little in the way of policy. As a result, it's incredibly difficult to speak about best practices in specific terms. What's good practice for one person isn't so for another. > Below is an article that seems to discuss precisely this subject. It's > a bit dated (2013), so am looking for clarification on whether or not > this is the _best_ way to deal with GPG, key pairs, etc. > > https://alexcabal.com/creating-the-perfect-gpg-keypair/ The phrase 'perfect' in that link is a warning. There is no such thing as a perfect keypair. Everything will always involve tradeoffs. Those who claim otherwise are usually charlatans. It's worth noting, BTW, that the official guidance of the GnuPG project is, "unless you know what you're doing and why you're doing it, stick with the defaults." 8.1: Q. Does GnuPG need to be 'tuned' before use? A. No. GnuPG has sensible defaults right out of the box. You don't need to tune GnuPG before you can use it. > I've seen a few other StackOverflow questions about this matter and > they all seem to recommend the same thing: create one master key, a > subkey (or more than one) and use those instead of the master key for > signing as needed. Don't. Stick with the defaults. You'll be happier, the learning curve (which is already steep!) will be easier, and you'll enjoy wildly more safe communications with people. Once you've used GnuPG for a while, have become familiar with how it does things and why, learned what tradeoffs go into different decisions, and so on... at that point you can generate a new keypair that's made just perfectly, exactly, the way you like it. :) > (b) is this all really necessary? Aren't your private keys, when > secured via a password, encrypted via AES256? If you have a super > secure password / passphrase, is this all really necessary? It depends. For some people in particularly high-security applications, yes, it's necessary. For instance, the website kernel.org was compromised a few years ago. The prospect of an attacker being able to insert a backdoor into the Linux kernel was so dramatic that a lot of the kernel developers decided taking extreme steps was appropriate. Can't fault them for it a bit. On the other hand, if you're trading fantasy football picks with your friends, those extreme steps would just be overkill. > (b2) can someone please explain what sort of situation would be > necessary for a private key that's been secured via a password is > actually compromised? Are we talking about keyloggers, etc. here? > Brute force? etc. Keyloggers are a possibility. So are $10,000-a-night hookers. It all depends on your enemy and how much in the way of resources they're willing to throw at the task of acquiring your passphrase. Everyone always thinks I'm joking about $10,000-a-night hookers, incidentally. I'm not. If someone were to give me a $100,000 budget to acquire a secret worth $1,000,000, hiring a high-class call girl for two weeks would be a *damned* tempting attack vector. People spend so much time obsessing over technical minutiae of crypto, and so little time realizing the weakest part of the system is always the human being... so why not hire an expert in manipulating human beings? This said, brute force isn't something you need to worry about. A strong passphrase will resist brute force for, quite possibly, longer than the earth will exist. > (c) if your "laptop keypair" (terminology from article above) is > compromised, data encrypted against that subkey will be compromised as > well, correct? The only benefit to creating subkeys is that you can > then revoke the subkey using your original signing key and let the > world know that you're still "in control" of your identity, correct? That's the idea. That said, this is just one way to solve the problem of how to recover from a key compromise event. There are many others. > (d) let's say you've used the laptop keypair to encrypt a wide swath > of data (emails, actual files, etc.). If you revoke the laptop subkey > because it's been compromised, can you still use that compromised > keypair to _decrypt_ the data, or is it lost forever? You can use it to decrypt the data. From rjh at sixdemonbag.org Tue Nov 17 17:00:20 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 17 Nov 2015 11:00:20 -0500 Subject: backing up keys In-Reply-To: References: Message-ID: <564B4F14.2060409@sixdemonbag.org> > I'm new to GPG and am hoping to learn the ropes. Please forgive any > ignorant questions. Honest questions get honest and accurate answers. Can't beat that for customer service, can you? :) > (a) are there any recommended methods by which to back up your private > and public keys? Not really, although a fair number of people have written scripts and tools to help automate the process. If you were to ask (and tell people what operating system you're running), you might get some responses. > (b) is your public key embedded in your private key? Yes. > _must_ I back up both files? You don't technically need to back up your public key, but it's a good idea to back up your public keyring. As you communicate more you'll discover some of your correspondents don't have publicly-available keys and they want to keep it that way. If you lose their public key you'll have to go back to acquiring their public key however you first got it, which may be anywhere between an annoyance to an impossibility. > (c) Isn't the private key itself encrypted via AES256 when secured > with a passphrase? If so, assuming the passphrase is secure enough, > isn't it sufficient to upload this file to Dropbox, etc. for safe > keeping? Would appreciate both real-world and theoretical commentary > on this point. It depends. If the bad guys get your encrypted private key they only need one additional piece of data -- your passphrase -- to catastrophically wreck your security posture. If you're completely confident the bad guys will never get your passphrase, then sure, post your private key in the _New York Times_. But maybe you shouldn't be completely confident. Never underestimate how foolish you can be when you've had a few glasses of wine and are chatting up a pretty member-of-the-appropriate-sex. :) > (d) as best I can tell, the --armor flag is used to dump the key to > ASCII. The gpg documentation[1] seems to indicate that paperkey works > better at backing up to paper. Is there some reason why? Can't we > simply run --armor, print the output and then use OCR to pull the key > back in in case of emergency? paperkey saves you a lot of paper by stripping out everything from the key except what's absolutely necessary. This also has the effect of making the backup more reliable. If you were to print out a full dump of my entire private key, for instance, it would be hundreds of pages long -- there are a couple of JPEG images attached to it. An error on page #67 could have catastrophic consequences for restoring from backup. With paperkey, it gets reduced down to one single page of 8x11 paper. It's easier to store, easier to handle, and easier to restore from backup. From harningt at gmail.com Tue Nov 17 16:18:37 2015 From: harningt at gmail.com (Thomas Harning Jr.) Date: Tue, 17 Nov 2015 15:18:37 +0000 Subject: backing up keys In-Reply-To: <564B3F4D.2010701@andrewg.com> References: <564B3F4D.2010701@andrewg.com> Message-ID: On Tue, Nov 17, 2015 at 9:58 AM Andrew Gallagher wrote: > On 17/11/15 12:39, James wrote: > > All, > > > > I'm new to GPG and am hoping to learn the ropes. Please forgive any > > ignorant questions. > > > > (a) are there any recommended methods by which to back up your private > > and public keys? I've seen some "paper" methods (paperkey) and some > > GitHub gists that have taken the private key, broken it in several > > pieces and used QR codes to back up. Which is better? Does it matter? > > "Better" really depends on your use case. Are you likely to forget your > passphrase? Are you going to keep your USB backup drive in a floor safe? > Are you expecting your home to be searched by the feds (or the mob)? I > don't think there is One Correct Answer to that one... > > > (b) is your public key embedded in your private key? If you're not > > actually uploading your private key to a keyserver (perhaps using the > > key to secure data / files instead of email, thus no need for > > keyserver), is it sufficient to back up the private key only, or > > _must_ I back up both files? > > No, there is no public key data embedded in the private key, but you can > regenerate the important mathematical bits of the public key from the > private key, and you can fill in your name, email etc. from memory. So > it's not absolutely necessary - but it is convenient. > > Of course, the backup of your public key does not need to be secure. > > > (c) Isn't the private key itself encrypted via AES256 when secured > > with a passphrase? If so, assuming the passphrase is secure enough, > > isn't it sufficient to upload this file to Dropbox, etc. for safe > > keeping? Would appreciate both real-world and theoretical commentary > > on this point. > > Brute forcing a password is always easier than brute forcing the key > itself (otherwise you'd be typing in your entire private key by hand!), > so if (when) dropbox do leak the key data you've given the Bad People a > shortcut. > > > (d) as best I can tell, the --armor flag is used to dump the key to > > ASCII. The gpg documentation[1] seems to indicate that paperkey works > > better at backing up to paper. Is there some reason why? Can't we > > simply run --armor, print the output and then use OCR to pull the key > > back in in case of emergency? > > That's fine if your OCR is perfect and your paper never gets folded or > stained or torn, but ascii-armored data has no checksum or error > correction so you may suddenly discover your paper backup is unusable. > And such discoveries usually happen at the worst moment. ;-) > > Andrew. > I wrote up a blog post a while back illustrating some backup mechanisms: http://blog.eharning.us/2011/04/key-backup-for-paranoid.html The PaperBack (http://ollydbg.de/Paperbak/) tool creates backups for data that can span multiple sheets of paper and have a varying level of redundancy and resolution. Checking out a backup made quite a while ago, since the dots were quite large, there wasn't much degradation in decoding ...barely activating redundancy measures. It should do well even if you fold the paper as even if you fold it in quarters, many of the squares should remain unmarred.... I archived my paper backup inside a sealed document mailer - a nice help against folding and useful marker if it were opened without my knowledge. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Tue Nov 17 18:01:20 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 17 Nov 2015 18:01:20 +0100 Subject: Generating 4096 bit key fails =?utf-8?Q?=E2=80=93?= why? In-Reply-To: (Felix E. Klee's message of "Tue, 17 Nov 2015 10:12:53 +0100") References: <87oafk9iqh.fsf@vigenere.g10code.de> <5636C4B3.5050905@fsij.org> <563968E9.6050604@fsij.org> Message-ID: <8737w4h867.fsf@vigenere.g10code.de> On Tue, 17 Nov 2015 10:12, felix.klee at inka.de said: > Any idea when the next release is scheduled to be available? We encountered some regression right before the usual monthly release date and thus we postponed that release. We now plan for some time in the next week. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From peter at digitalbrains.com Wed Nov 18 13:08:14 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 18 Nov 2015 13:08:14 +0100 Subject: best practices for creating keys In-Reply-To: <564B3AC4.50908@andrewg.com> References: <564B3AC4.50908@andrewg.com> Message-ID: <564C6A2E.1050004@digitalbrains.com> On 17/11/15 15:33, Andrew Gallagher wrote: >> https://alexcabal.com/creating-the-perfect-gpg-keypair/ > > This is a fairly good article - I've used it myself for reference in the > past. Also have a look at: I disagree, I'd recommend people not to read that article, let alone follow its advice. He sounds convincing, but I'd much rather point people to Rob's answer in this very thread[1] instead. And just stick with the defaults. By the way, this "Creating the perfect keypair" webpage has come up multiple times on this list already. If you want some more thoughts about it, use your favourite search engine. HTH, Peter. [1] https://lists.gnupg.org/pipermail/gnupg-users/2015-November/054685.html -- 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 david at gbenet.com Wed Nov 18 13:53:23 2015 From: david at gbenet.com (david at gbenet.com) Date: Wed, 18 Nov 2015 12:53:23 +0000 Subject: What causes this bad signature In-Reply-To: <20151116150128.GA20752@danton.fire-world.de> References: <20151114202809.GA7962@danton.fire-world.de> <5647E7DA.6020104@gbenet.com> <20151116150128.GA20752@danton.fire-world.de> Message-ID: <564C74C3.3080401@gbenet.com> On 16/11/15 15:01, Sebastian Wiesinger wrote: > Hello, > > my key is not bad, the signature by 0x5E5CCCB4A4BF43D7 is bad. The > question is why. > > Regards > > Sebastian > Hello Sebastian, I downloaded the key and all sub-keys. Neither GPA Kgpg or Kleopatra give any warnings about this key. You don't say what's bad about it - which is why your not getting much help here. David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Wed Nov 18 15:15:40 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 18 Nov 2015 15:15:40 +0100 Subject: What causes this bad signature In-Reply-To: <564C74C3.3080401@gbenet.com> References: <20151114202809.GA7962@danton.fire-world.de> <5647E7DA.6020104@gbenet.com> <20151116150128.GA20752@danton.fire-world.de> <564C74C3.3080401@gbenet.com> Message-ID: <564C880C.2040906@digitalbrains.com> On 18/11/15 13:53, david at gbenet.com wrote: > I downloaded the key and all sub-keys. Neither GPA Kgpg or Kleopatra give any warnings > about this key. You don't say what's bad about it - which is why your not getting much help > here. Actually, I understand what he means, I just don't know how to investigate further. I tried with --debug-*, but I got no more info, and was at a loss how to continue right there and then, so I didn't post a reply. >From his original post: > My key is 0x58A2D94A93A0B9CE and their signature comes from > 0x5E5CCCB4A4BF43D7: > > pub 2048R/0x58A2D94A93A0B9CE 2009-08-11 > uid [ultimate] Sebastian Wiesinger > sig!3 P 0x58A2D94A93A0B9CE 2015-03-27 never Sebastian Wiesinger > sig-3 1 0x5E5CCCB4A4BF43D7 2015-11-14 never Governikus OpenPGP Signaturservice (Neuer Personalausweis) Note the sig-3 line; the dash indicates a bad signature, as the man page indicates for --check-sig. Additionally, GnuPG outputs the line: > gpg: 1 bad signature which he didn't include in his quote because he trimmed the console output; it would have included about 55 other signatures, so I get why he did 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 From peter at digitalbrains.com Wed Nov 18 19:33:14 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 18 Nov 2015 19:33:14 +0100 Subject: What causes this bad signature In-Reply-To: <564CA047.5070206@gbenet.com> References: <20151114202809.GA7962@danton.fire-world.de> <5647E7DA.6020104@gbenet.com> <20151116150128.GA20752@danton.fire-world.de> <564C74C3.3080401@gbenet.com> <564C880C.2040906@digitalbrains.com> <564CA047.5070206@gbenet.com> Message-ID: <564CC46A.6080000@digitalbrains.com> On 18/11/15 16:59, david at gbenet.com wrote: > 0x5E5CCCB4A4BF43D7 has expired - that's the only thing "bad" about it. I could not reproduce this: > $ gpg2 -k 2C53B2ED > pub rsa2048/2C53B2ED 2015-08-21 [expired: 2015-08-28] > uid [ expired] Test Teststra Jr. > $ gpg2 --check-sig DCDFDFA4 > gpg: 8 good signatures > pub rsa1024/DCDFDFA4 2012-03-17 [expires: 2015-11-19] > uid [ unknown] Test Teststra (Koning van Wezel) > sig!3 DCDFDFA4 2015-11-18 Test Teststra (Koning van Wezel) > sig! 2C53B2ED 2015-11-18 Test Teststra Jr. > uid [ unknown] Test Teststra > rev! DCDFDFA4 2014-08-14 Test Teststra (Koning van Wezel) > sig!3 DCDFDFA4 2014-08-13 Test Teststra (Koning van Wezel) > sig!3 DCDFDFA4 2015-11-18 Test Teststra (Koning van Wezel) > sig! 17C05EBD 2015-05-22 ceo at example.org > sig! 2C53B2ED 2015-11-18 Test Teststra Jr. > sub rsa1024/77A3395A 2012-03-17 > sig! DCDFDFA4 2012-03-17 Test Teststra (Koning van Wezel) I have just now issued a signature on 0xDCDFDFA4 with 0x2C53B2ED. To do that, I had to unexpire the latter, but I first made a backup of the expired key. After putting the expired key back, the signature is still shown as succesfully verified, not as bad. So a signature by an expired key is not necessarily seen as a bad signature. Either your explanation is incomplete or it is incorrect... But thanks for looking into it! I never thought anything of the fact it was expired; I probably never noticed? 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 flapflap at riseup.net Thu Nov 19 10:31:53 2015 From: flapflap at riseup.net (flapflap) Date: Thu, 19 Nov 2015 09:31:53 +0000 Subject: Change capabilities of main key? Message-ID: <564D9709.3080101@riseup.net> Hi, occasionally I notice someone with a public key that has the "SCE" (Sign Certify Encrypt) capabilities set for a single key pair (presumably, they did set these manually during key generation). I understood that this is not recommended because it may simplify certain attacks (but don't know any sources). Is there a possibility to modify the (main/sub) key capabilities once its generated so they can migrate away from the insecure/less secure setting to, for instance, separate subkeys for Sign and Encrypt? Cheers, ~flapflap -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From melvincarvalho at gmail.com Thu Nov 19 16:06:50 2015 From: melvincarvalho at gmail.com (Melvin Carvalho) Date: Thu, 19 Nov 2015 16:06:50 +0100 Subject: PGP people said "I will only trust people I've had a beer with." Message-ID: This is a great conversation in general, including the inventors of the web and the internet, pushing for more crypto http://www.w3.org/2015/10/27-tpac-minutes.html Vint: I would like to challenge people who are concerned about security...is there some irreducible level of inconvenience that's needed timbl: The level of convenience has also gone up so much. ... In a way, security has to be in everything. Everything you code or write in a spec can be exploited. ... the cool thing as you pointed out implicitly about RSA..... ... public key technology was a massive change. ... that has been very exciting ... I've been frustrated that we've not been able to live up to the potential of RSA ... people have said it didn't take off due to patents ... but you could also say it wasn't the technology piece, but rather the social aspect ... the PGP people said "I will only trust people I've had a beer with." ... you have a key-signing party ... and you can create a trusted infrastructure ... you had another social attitude which was that the world would have trust imposed upon them by world bodies ... these social structures came into conflict ... if you look at the security situation, one implication of moving from the Web to the social web ... is that we may be able to produce social protocols that will enable us to connect to each other or friend each other ... using standard protocols in a compatible way, and once we've done that we may realize "oh, we've all got public keys" ... so the keys could come to us through social graph, and we learn to create user interfaces that let us vouch for each others in different ways ... so we could fulfill the promise of powerful crypto -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan at nitrokey.com Thu Nov 19 22:37:51 2015 From: jan at nitrokey.com (Jan Suhr) Date: Thu, 19 Nov 2015 22:37:51 +0100 Subject: Crowdfunding USB Security Key for Email- and Data-Encryption - Nitrokey Storage Message-ID: <564E412F.5010401@nitrokey.com> Hi! Nitrokey Storage is a USB device which operates as a ?digital latchkey? to protect your data and user accounts. It allows for the secure encryption of emails, files and hard drives, secure login on the web and contains encrypted mass storage. The encryption keys are stored securely in the hardware at all times. Nitrokey is made entirely in Germany and is 100% open-source and uses 100% open hardware. It is also the first hardware worldwide with hidden storage, which enables users to plausibly deny the existence of additional encrypted data. This can be useful during border controls or similar threatening situation. The firmware and hardware of Nitrokey Storage have already been verified by Cure59, a professional third-party security auditor. Use Cases: * Encryption of emails, hard drives, SSH, and other data. Secure keys are protected by an integrated OpenPGP Card. Up to RSA 4096 bit is supported. * Secure login on the web and protection against identity theft via one-time passwords. * Secure transport and exchange of sensitive files via encrypted mass storage (up to 64 GB). (AES-256 in CBC mode) Our crowdfunding campaign just started and needs your support: http://igg.me/at/nitrokey Also, please help promoting it. Kind Regards, Jan Suhr From malte at wk3.org Fri Nov 20 11:26:26 2015 From: malte at wk3.org (Malte) Date: Fri, 20 Nov 2015 11:26:26 +0100 Subject: Crowdfunding USB Security Key for Email- and Data-Encryption - Nitrokey Storage In-Reply-To: <564E412F.5010401@nitrokey.com> References: <564E412F.5010401@nitrokey.com> Message-ID: <2552257.By6gRoOvnt@localhost> Hi, very nice! Two questions/remarks, though: On Thursday 19 November 2015 22:37 Jan Suhr wrote: > The firmware and hardware of Nitrokey Storage have already been verified > by Cure59, a professional third-party security auditor. How do you deal with the findings of the audit? (https://cure53.de/pentest-report_nitrokey.pdf and https://cure53.de/pentest-report_nitrokey-hardware.pdf, for the inclinded reader. And yes, it is cure53.) > Nitrokey is made entirely in Germany [?] Can we _please_, for the love of all that is dear to us, stop advertising with nation-states as quality property? It might sell more sticks, but it fosters a sense of trust where there must be none. Sincerely, Malte From the2nd at otpme.org Fri Nov 20 13:37:14 2015 From: the2nd at otpme.org (the2nd at otpme.org) Date: Fri, 20 Nov 2015 13:37:14 +0100 Subject: gpg-agent: error accessing card: Conflicting use In-Reply-To: <05532bd82a9b5d55402d32215487b0a7@otpme.org> References: <05532bd82a9b5d55402d32215487b0a7@otpme.org> Message-ID: Hi, now i have the same problem on my ubuntu installation at work. I've updated to ubuntu 15.10 and now it happens from time to time just like on my sabayon installation. But as i dont use the OTP feature of the yubikey at work i can say for sure that the problem exists without pressing the yubikey button. Also it happens without yubikey pull out and it is not related to my yubikey because a colleague of mine has the same problem after upgrading to ubuntu 15.10. GPG version is 1.4.18. Any help is appreciated. regards the2nd On 2015-08-11 20:10, the2nd at otpme.org wrote: > Hi again :) > > nobody else with this problem? > > > > On 2015-05-30 14:25, the2nd at otpme.org wrote: >> Hi, >> >> i have a problem with gpg-agent when using it with a yubikey neo. >> after some time gpg-agent refuses to sign any data and so any ssh >> login with my key stored on the yubikey will fail. the gpg-agent log >> shows the following messages: >> >> 2015-05-30 13:49:36 gpg-agent[3600] error accessing card: Conflicting >> use >> 2015-05-30 13:49:36 gpg-agent[3600] smartcard signing failed: >> Conflicting use >> 2015-05-30 13:49:38 gpg-agent[3600] error getting default >> authentication keyID of card: Conflicting use >> >> the command to start gpg-agent on KDE login is: >> eval "$(/usr/bin/gpg-agent --daemon --enable-ssh-support --log-file >> ~/.gnupg/gpg-agent.log)" >> >> i haven't found the exact circumstances when it happens but its more >> likely to happen when the yubikey was plugged off and re-inserted, but >> it also happens without pull off from time to time. a restart of >> gpg-agent fixes the issue. it also often happens after i've pressed >> the yubikey button to generate an OTP but not always. >> >> gnupg version is 2.0.27-r1 running on sabayon linux. >> >> when using the same yubikey on my ubuntu 14.04 notebook at work i >> never had this problem. >> >> thanks for any help. >> >> regards >> the2nd > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From biggerbadderben at gmail.com Fri Nov 20 16:26:51 2015 From: biggerbadderben at gmail.com (Ben Warren) Date: Fri, 20 Nov 2015 07:26:51 -0800 Subject: scdaemon lockup with Yubikey NEO Message-ID: Hi, I?ve noticed several other problem reports that seem similar, hopefully they?re all related and there?s a simple fix. The problem: After an indeterminate amount of time (sometimes minutes, sometimes hours), any GPG operation that uses my Yubikey NEO device hangs. The two most common operations are SSH authentication and git signing. The following sequence gets things going again: $ killall -SIGKILL scdaemon $ gpg2 ?card-status System particulars: - Host OS is OS-X Yosemite, although it is also present on Mavericks (haven?t tried El Capitan yet) - GPG 2.1.5 - Using the Yubikey?s authentication subkey to login to remote Linux hosts - Using the Yubikey?s signing subkey for git signing operations, both local and remote - Using gpg-agent for forwarding both GPG and SSH (great features, BTW!) GPG configuration file: $ cat ~/.gnupg/gpg-agent.conf default-cache-ttl 1 ignore-cache-for-signing no-allow-external-cache max-cache-ttl 1 extra-socket ${HOME}/.gnupg/S.gpg-extra-agent debug-all log-file ${HOME}/.gnupg/mygpglogfile.log enable-ssh-support I?ll be happy to help debug this, but need some guidance. thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan at nitrokey.com Sat Nov 21 09:00:55 2015 From: jan at nitrokey.com (Jan Suhr) Date: Sat, 21 Nov 2015 09:00:55 +0100 Subject: Crowdfunding USB Security Key for Email- and Data-Encryption - Nitrokey Storage In-Reply-To: <2552257.By6gRoOvnt@localhost> References: <564E412F.5010401@nitrokey.com> <2552257.By6gRoOvnt@localhost> Message-ID: <565024B7.9070300@nitrokey.com> Hi Malte! Am 20.11.2015 11:26, schrieb Malte: > Hi, > > very nice! > > Two questions/remarks, though: > > On Thursday 19 November 2015 22:37 Jan Suhr wrote: >> The firmware and hardware of Nitrokey Storage have already been >> verified >> by Cure59, a professional third-party security auditor. > > How do you deal with the findings of the audit? All serious findings are fixed already. Look for the "Note" at the end of each issue description. > (https://cure53.de/pentest-report_nitrokey.pdf and > https://cure53.de/pentest-report_nitrokey-hardware.pdf, for the > inclinded reader. And yes, it is > cure53.) > > >> Nitrokey is made entirely in Germany [?] > > Can we _please_, for the love of all that is dear to us, stop > advertising with > nation-states as quality property? It might sell more sticks, but it > fosters a > sense of trust where there must be none. This can be a hard requirement for enterprises and government institutions. So it makes sense to inform about it. Whether this matters to personal users is up to each individual decision. Regards, Jan > > Sincerely, > > Malte > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From peter at digitalbrains.com Sat Nov 21 12:07:37 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 21 Nov 2015 12:07:37 +0100 Subject: Crowdfunding USB Security Key for Email- and Data-Encryption - Nitrokey Storage In-Reply-To: <565024B7.9070300@nitrokey.com> References: <564E412F.5010401@nitrokey.com> <2552257.By6gRoOvnt@localhost> <565024B7.9070300@nitrokey.com> Message-ID: <56505079.3070805@digitalbrains.com> On 21/11/15 09:00, Jan Suhr wrote: > All serious findings are fixed already. Look for the "Note" at the end > of each issue description. I suppose by "serious" you mean "defined as 'Critical' in the pentest"? There are unfixed issues with severity "High": Firmware: NK-01-008 OTP can be unlocked by replacing Smart Card (High) Hardware: NK-02-006 Micro SD and Smartcard Slots lack ejection switch (High) Personally, I don't really see yet why the latter is so important; however, gaining the ability to issue OTP's by simply inserting my own OpenPGP card with my own PIN seems serious? Do I misunderstand it? Or is it not part of the threat model because the attacker is unable to extract the key used for OTP generation? Anyway, thanks for all your work on the Nitrokey series! I think it's great you put so much effort into creating these nifty devices. 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 peter at digitalbrains.com Sat Nov 21 13:09:57 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 21 Nov 2015 13:09:57 +0100 Subject: backing up keys In-Reply-To: <564B3F4D.2010701@andrewg.com> References: <564B3F4D.2010701@andrewg.com> Message-ID: <56505F15.3060702@digitalbrains.com> On 17/11/15 15:53, Andrew Gallagher wrote: > No, there is no public key data embedded in the private key, but you can > regenerate the important mathematical bits of the public key from the > private key, and you can fill in your name, email etc. from memory. So > it's not absolutely necessary - but it is convenient. Let's look at this at three levels: 1) What GnuPG actually does when you invoke --export-secret-key GnuPG outputs both a "Secret-Key Packet" as well as all UID's and binding signatures. It might output all certifications by others on the key as well; I'm going to write a separate mail about this. 2) What is in a "Secret-Key Packet" > 5.5.1.3. Secret-Key Packet (Tag 5) > > A Secret-Key packet contains all the information that is found in a > Public-Key packet, including the public-key material, but also > includes the secret-key material after all the public-key fields. 3) What you can do with just the RSA elements p, q, e, and optionally d and u. You could create a key that allows you to decrypt your encrypted data, although you might have to jump through some hoops regarding the fingerprint. To be able to recreate a key with the same fingerprint, you additionally need to know when you created your key down to the very second. This means that even if you can reproduce your UID from memory perfectly, any signatures you issue will not be recognised by your peers and all certifications on your UID are lost unless you have memorised the very second the key was created. All in all, I wonder: did someone tell you you could recreate your public key using just the secret parts? Have you tried it yourself? As far as decryption goes, I might agree, but when you say > you can fill in your name, email etc. from memory I think you're talking about regaining certifications from others, and for that you really do need the creation timestamp down to the second. > Brute forcing a password is always easier than brute forcing the key > itself (otherwise you'd be typing in your entire private key by hand!), This is an oversimplification. A symmetric key has no structure; it is just data. RSA, on the other hand, has specific mathematical properties. The numbers p and q are primes, which are spaced rather far apart on the number line; all numbers in between would make valid symmetric keys, but not valid primes for RSA. As a consequence, the information content in the number is lower. In practice, OpenPGP private keys also include the numbers d and u, which in fact can be computed from p and q (given e, which is usually a constant), so hold no additional information content at all. It is claimed (though not universally) a 2048-bit RSA key is about as strong as a 112-bit symmetric key. If we take this to be the truth, then remembering a cryptographically random 19-character base64 string and using it as a password for your secret key would balance the relative strengths, and brute forcing the "passphrase" is just as hard as brute-forcing the public key to reveal the secret key. 112 bits is a full order of magnitude smaller than 2048 bits; there is no need to put a passphrase with 2048 bits of randomness on your key to balance it out. >> The gpg documentation[1] seems to indicate that paperkey works >> better at backing up to paper. Is there some reason why? An OpenPGP Secret Key Packet is identical to the public key packet, but with the secret material appended to it. Paperkey just stores this appendage, and uses the public key to reconstruct the secret key from it. So when you print out the result of --export-secret-key, most of what you are printing is actually the same stuff that is in the public key, and you can just store the public key anywhere without stringent security requirements; in fact, it's often available on the keyserver network. Paperkey just stores the non-redundant bit, which is much smaller. > That's fine if your OCR is perfect and your paper never gets folded or > stained or torn, but ascii-armored data has no checksum or error > correction so you may suddenly discover your paper backup is unusable. There certainly is checksum data in OpenPGP packets, and the fact that your key doesn't work is a checksum in and of itself. There is no error correction, other than that it is mathematically possible to reconstruct a prime from a slightly corrupted copy, and furthermore that the numbers d and u can be recomputed when p and q are still intact, and that p can be computed from the public key when q is intact, and vice versa. So basically, all you need is either p or q to be intact. I'm not now going to spend time thinking about whether u or d is actually enough already. 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 peter at digitalbrains.com Sat Nov 21 13:24:50 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 21 Nov 2015 13:24:50 +0100 Subject: backing up keys In-Reply-To: <56505F15.3060702@digitalbrains.com> References: <564B3F4D.2010701@andrewg.com> <56505F15.3060702@digitalbrains.com> Message-ID: <56506292.8000904@digitalbrains.com> On 21/11/15 13:09, Peter Lebbing wrote: > GnuPG outputs both a "Secret-Key Packet" as well as all UID's and > binding signatures. It might output all certifications by others on the > key as well; I'm going to write a separate mail about this. Okay, it turns out it was a weird issue with my keyring. In fact, GnuPG would seem to always output all certifications with --export-secret-keys, and it does not honour --export-options export-minimal or export-clean. 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 the2nd at otpme.org Sat Nov 21 13:41:33 2015 From: the2nd at otpme.org (the2nd) Date: Sat, 21 Nov 2015 13:41:33 +0100 Subject: AW: scdaemon lockup with Yubikey NEO Message-ID: Hi Ben, We have a similar Problem since we've upgraded from Ubuntu 15.04 to 15.10. ?When starting gpg-agent with --log-file the log show the following: 2015-05-30 13:49:36?gpg-agent[3600] error accessing card: Conflicting?use 2015-05-30 13:49:36?gpg-agent[3600] smartcard signing failed:? Conflicting use? 2015-05-30 13:49:38?gpg-agent[3600] error getting default?authentication keyID of card: Conflicting use I've asked the list serval times about this issue but got now answer yet. So i dont have a solution but it may be interesting if your problem is the same... Regards The2nd?
-------- Urspr?ngliche Nachricht --------
Von: Ben Warren
Datum:11.20.2015 16:26 (GMT+01:00)
An: gnupg-users at gnupg.org
Betreff: scdaemon lockup with Yubikey NEO
Hi, I?ve noticed several other problem reports that seem similar, hopefully they?re all related and there?s a simple fix. The problem: After an indeterminate amount of time (sometimes minutes, sometimes hours), any GPG operation that uses my Yubikey NEO device hangs. The two most common operations are SSH authentication and git signing. The following sequence gets things going again: $ killall -SIGKILL scdaemon $ gpg2 ?card-status System particulars: Host OS is OS-X Yosemite, although it is also present on Mavericks (haven?t tried El Capitan yet) GPG 2.1.5 Using the Yubikey?s authentication subkey to login to remote Linux hosts Using the Yubikey?s signing subkey for git signing operations, both local and remote Using gpg-agent for forwarding both GPG and SSH (great features, BTW!) GPG configuration file: $ cat ~/.gnupg/gpg-agent.conf default-cache-ttl 1 ignore-cache-for-signing no-allow-external-cache max-cache-ttl 1 extra-socket ${HOME}/.gnupg/S.gpg-extra-agent debug-all log-file ${HOME}/.gnupg/mygpglogfile.log enable-ssh-support I?ll be happy to help debug this, but need some guidance. thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndk.clanbo at gmail.com Sat Nov 21 18:23:32 2015 From: ndk.clanbo at gmail.com (NdK) Date: Sat, 21 Nov 2015 18:23:32 +0100 Subject: Crowdfunding USB Security Key for Email- and Data-Encryption - Nitrokey Storage In-Reply-To: <56505079.3070805@digitalbrains.com> References: <564E412F.5010401@nitrokey.com> <2552257.By6gRoOvnt@localhost> <565024B7.9070300@nitrokey.com> <56505079.3070805@digitalbrains.com> Message-ID: <5650A894.3070808@gmail.com> Il 21/11/2015 12:07, Peter Lebbing ha scritto: > Personally, I don't really see yet why the latter is so important; > however, gaining the ability to issue OTP's by simply inserting my own > OpenPGP card with my own PIN seems serious? Do I misunderstand it? Or is > it not part of the threat model because the attacker is unable to > extract the key used for OTP generation? I didn't look at the code (so this could be completely wrong and I'd be happy!), but if the OTP key is decrypted using a key in the chip after verifying that the card accepts the PIN, then it's even worse, since that master key is in cleartext somewhere outside the smartcard. So, with some efforts and a good lab the OTP keys can be extracted. > Anyway, thanks for all your work on the Nitrokey series! I think it's > great you put so much effort into creating these nifty devices. Nifty, indeed. Too bad PGP-card spec lacks decryption key archiving (so that you can change your DEC key every year but keep using the same card year after year). BYtE, Diego From lance at lrvick.net Sun Nov 22 03:06:24 2015 From: lance at lrvick.net (Lance R. Vick) Date: Sat, 21 Nov 2015 18:06:24 -0800 Subject: scdaemon lockup with Yubikey NEO In-Reply-To: References: Message-ID: This happens to me constantly as well. I my case I frequently need to kill and restart gpg-agent to get things working again on both Arch Linux and Gentoo. On Sat, Nov 21, 2015 at 4:41 AM, the2nd wrote: > Hi Ben, > > We have a similar Problem since we've upgraded from Ubuntu 15.04 to > 15.10. When starting gpg-agent with --log-file the log show the following: > > 2015-05-30 13:49:36 gpg-agent[3600] error accessing card: Conflicting use > 2015-05-30 13:49:36 gpg-agent[3600] smartcard signing failed: > Conflicting use > 2015-05-30 13:49:38 gpg-agent[3600] error getting default authentication > keyID of card: Conflicting use > > I've asked the list serval times about this issue but got now answer yet. > So i dont have a solution but it may be interesting if your problem is the > same... > > Regards > The2nd > > > -------- Urspr?ngliche Nachricht -------- > Von: Ben Warren > Datum:11.20.2015 16:26 (GMT+01:00) > An: gnupg-users at gnupg.org > Betreff: scdaemon lockup with Yubikey NEO > > Hi, > > I?ve noticed several other problem reports that seem similar, hopefully > they?re all related and there?s a simple fix. > > The problem: > > After an indeterminate amount of time (sometimes minutes, sometimes > hours), any GPG operation that uses my Yubikey NEO device hangs. The two > most common operations are SSH authentication and git signing. The > following sequence gets things going again: > > $ killall -SIGKILL scdaemon > > $ gpg2 ?card-status > > System particulars: > > > - Host OS is OS-X Yosemite, although it is also present on Mavericks > (haven?t tried El Capitan yet) > - GPG 2.1.5 > - Using the Yubikey?s authentication subkey to login to remote Linux > hosts > - Using the Yubikey?s signing subkey for git signing operations, both > local and remote > - Using gpg-agent for forwarding both GPG and SSH (great features, > BTW!) > > > GPG configuration file: > > $ cat ~/.gnupg/gpg-agent.conf > > default-cache-ttl 1 > > ignore-cache-for-signing > > no-allow-external-cache > > max-cache-ttl 1 > > extra-socket ${HOME}/.gnupg/S.gpg-extra-agent > > debug-all > > log-file ${HOME}/.gnupg/mygpglogfile.log > > enable-ssh-support > > > I?ll be happy to help debug this, but need some guidance. > > > thanks, > > Ben > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > -- Lance R. Vick __________________________________________________ Cell - 407.283.7596 Gtalk - lance at lrvick.net Website - http://lrvick.net PGP Key - http://lrvick.net/0x36C8AAA9.asc keyserver - subkeys.pgp.net __________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at digitalbrains.com Sun Nov 22 12:55:55 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 22 Nov 2015 12:55:55 +0100 Subject: Crowdfunding USB Security Key for Email- and Data-Encryption - Nitrokey Storage In-Reply-To: <5650A894.3070808@gmail.com> References: <564E412F.5010401@nitrokey.com> <2552257.By6gRoOvnt@localhost> <565024B7.9070300@nitrokey.com> <56505079.3070805@digitalbrains.com> <5650A894.3070808@gmail.com> Message-ID: <5651AD4B.2070104@digitalbrains.com> On 21/11/15 18:23, NdK wrote: > I didn't look at the code (so this could be completely wrong and I'd be > happy!), but if the OTP key is decrypted using a key in the chip after > verifying that the card accepts the PIN, then it's even worse, since > that master key is in cleartext somewhere outside the smartcard. So, > with some efforts and a good lab the OTP keys can be extracted. My guess is the OTP shared secret is stored in the non-volatile memory of the microcontroller (in plaintext). That memory is reasonably well protected against reading out (when properly configured). Sure, it's possible with a lab, but it's not cheap. If such adversaries are in your threat model, my guess (again) is that the OTP feature of this stick is not aimed at you. 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 ndk.clanbo at gmail.com Sun Nov 22 15:30:55 2015 From: ndk.clanbo at gmail.com (NdK) Date: Sun, 22 Nov 2015 15:30:55 +0100 Subject: Crowdfunding USB Security Key for Email- and Data-Encryption - Nitrokey Storage In-Reply-To: <5651AD4B.2070104@digitalbrains.com> References: <564E412F.5010401@nitrokey.com> <2552257.By6gRoOvnt@localhost> <565024B7.9070300@nitrokey.com> <56505079.3070805@digitalbrains.com> <5650A894.3070808@gmail.com> <5651AD4B.2070104@digitalbrains.com> Message-ID: <5651D19F.8070003@gmail.com> Il 22/11/2015 12:55, Peter Lebbing ha scritto: > My guess is the OTP shared secret is stored in the non-volatile memory > of the microcontroller (in plaintext). That memory is reasonably well > protected against reading out (when properly configured). Sure, it's > possible with a lab, but it's not cheap. If such adversaries are in your > threat model, my guess (again) is that the OTP feature of this stick is > not aimed at you. The whole stick (and the current OpenPGP card spec) is not aimed at me, since it lacks the "decryption key history" that I'd need :) What I don't understand is why they did not use one of the private objects in the card to store the master key: this way, if the card gets swapped, the master key becomes inaccessible and the attacker can't use the OTP secret since it's encrypted with an unavailable key. Sure, it's not perfect (the master key gets loaded in RAM of the micro) but makes any attack harder. BYtE, Diego From jan at nitrokey.com Mon Nov 23 08:54:56 2015 From: jan at nitrokey.com (Jan Suhr) Date: Mon, 23 Nov 2015 08:54:56 +0100 Subject: Crowdfunding USB Security Key for Email- and Data-Encryption - Nitrokey Storage In-Reply-To: <56505079.3070805@digitalbrains.com> References: <564E412F.5010401@nitrokey.com> <2552257.By6gRoOvnt@localhost> <565024B7.9070300@nitrokey.com> <56505079.3070805@digitalbrains.com> Message-ID: <50018aae94f9fc6e1206aaff8aabbfd3@suhr.org> Hi Peter, Am 21.11.2015 12:07, schrieb Peter Lebbing: > On 21/11/15 09:00, Jan Suhr wrote: >> All serious findings are fixed already. Look for the "Note" at the end >> of each issue description. > > I suppose by "serious" you mean "defined as 'Critical' in the pentest"? > There are unfixed issues with severity "High": > > Firmware: > NK-01-008 OTP can be unlocked by replacing Smart Card (High) 2nd factors are usually not access protected at all e.g. may have a display (which allows funny hacks[1]). We introduced PIN-protection of OTPs as an optional feature because we don't have a physical button. If an attacker has physical access to replace the smart card, he could also press a hypothetical button or read a hypothetical display. The PIN isn't aiming to protect against physical attacks hence it's not in our threat model. > Hardware: > NK-02-006 Micro SD and Smartcard Slots lack ejection switch (High) An ejection switch doesn't make any sense to me. Note that ejection switch could only be triggered if a card is ejected while the device is powered. Furthermore any pupil would be able to use a soldering iron to circumvent an ejection switch. > Personally, I don't really see yet why the latter is so important; I agree > however, gaining the ability to issue OTP's by simply inserting my own > OpenPGP card with my own PIN seems serious? Do I misunderstand it? Or > is > it not part of the threat model because the attacker is unable to > extract the key used for OTP generation? Right, not part of the threat model and keys can't be extracted. Also an ejection switch wouldn't help here because a card could be replaced while the device is powered off which renders and ejection switch useless. > Anyway, thanks for all your work on the Nitrokey series! I think it's > great you put so much effort into creating these nifty devices. Thank you. :-) Best regards, Jan [1] https://smallhacks.wordpress.com/2012/11/11/reading-codes-from-rsa-secureid-token/ From jan at nitrokey.com Mon Nov 23 08:59:02 2015 From: jan at nitrokey.com (Jan Suhr) Date: Mon, 23 Nov 2015 08:59:02 +0100 Subject: Crowdfunding USB Security Key for Email- and Data-Encryption - Nitrokey Storage In-Reply-To: <5650A894.3070808@gmail.com> References: <564E412F.5010401@nitrokey.com> <2552257.By6gRoOvnt@localhost> <565024B7.9070300@nitrokey.com> <56505079.3070805@digitalbrains.com> <5650A894.3070808@gmail.com> Message-ID: <8e32517a4b86047c677b0e0079750a60@suhr.org> Hi Ndk, Am 21.11.2015 18:23, schrieb NdK: > Il 21/11/2015 12:07, Peter Lebbing ha scritto: > >> Personally, I don't really see yet why the latter is so important; >> however, gaining the ability to issue OTP's by simply inserting my own >> OpenPGP card with my own PIN seems serious? Do I misunderstand it? Or >> is >> it not part of the threat model because the attacker is unable to >> extract the key used for OTP generation? > I didn't look at the code (so this could be completely wrong and I'd be > happy!), but if the OTP key is decrypted using a key in the chip after > verifying that the card accepts the PIN, then it's even worse, since > that master key is in cleartext somewhere outside the smartcard. So, > with some efforts and a good lab the OTP keys can be extracted. The key is stored in the card. The (optional PIN protected and encrypted) OTP secrets are stored in the microcontroller's flash which is read-protected. Best regards, Jan >> Anyway, thanks for all your work on the Nitrokey series! I think it's >> great you put so much effort into creating these nifty devices. > Nifty, indeed. Too bad PGP-card spec lacks decryption key archiving (so > that you can change your DEC key every year but keep using the same > card > year after year). > > BYtE, > Diego > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From ndk.clanbo at gmail.com Mon Nov 23 09:42:27 2015 From: ndk.clanbo at gmail.com (NdK) Date: Mon, 23 Nov 2015 09:42:27 +0100 Subject: Crowdfunding USB Security Key for Email- and Data-Encryption - Nitrokey Storage In-Reply-To: <08fa1b54c5b6b7c99f672cb95bac8527@suhr.org> References: <564E412F.5010401@nitrokey.com> <2552257.By6gRoOvnt@localhost> <565024B7.9070300@nitrokey.com> <56505079.3070805@digitalbrains.com> <5650A894.3070808@gmail.com> <08fa1b54c5b6b7c99f672cb95bac8527@suhr.org> Message-ID: <5652D173.7010909@gmail.com> Il 23/11/2015 08:56, Jan Suhr ha scritto: >> I didn't look at the code (so this could be completely wrong and I'd be >> happy!), but if the OTP key is decrypted using a key in the chip after >> verifying that the card accepts the PIN, then it's even worse, since >> that master key is in cleartext somewhere outside the smartcard. So, >> with some efforts and a good lab the OTP keys can be extracted. > The key is stored in the card. Then, replacing the card replaces the OTP key. No? BYtE, Diego From peter at digitalbrains.com Mon Nov 23 11:15:26 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 23 Nov 2015 11:15:26 +0100 Subject: Crowdfunding USB Security Key for Email- and Data-Encryption - Nitrokey Storage In-Reply-To: <50018aae94f9fc6e1206aaff8aabbfd3@suhr.org> References: <564E412F.5010401@nitrokey.com> <2552257.By6gRoOvnt@localhost> <565024B7.9070300@nitrokey.com> <56505079.3070805@digitalbrains.com> <50018aae94f9fc6e1206aaff8aabbfd3@suhr.org> Message-ID: <5652E73E.6060404@digitalbrains.com> On 23/11/15 08:54, Jan Suhr wrote: > 2nd factors are usually not access protected at all e.g. may have a > display (which allows funny hacks[1]). Ah, that makes sense! I forgot about that because I myself would actually like an OTP protected by PIN as complete two-factor solution (have the device, know the PIN). But that is an uncommon scenario. > We introduced PIN-protection of > OTPs as an optional feature because we don't have a physical button. Can I suggest you document this well so people know the limitations of the functionality? As a part of that, I'm sure you are aware a physical button is out-of-band (a remote attacker can't press it), but a remote attacker can send a PIN to the smartcard. >> Hardware: >> NK-02-006 Micro SD and Smartcard Slots lack ejection switch (High) > > An ejection switch doesn't make any sense to me. Note that ejection > switch could only be triggered if a card is ejected while the device is > powered. > Furthermore any pupil would be able to use a soldering iron to > circumvent an ejection switch. I read this part of the pentest document as a bundle complete with a supercap to keep the power applied when unplugged and the part where there is tamper detection. All three together make sense, the tamper detection beating the pupil[1]. But the odd thing there is that the ejection switch is rated high importance, but the others medium. Thanks for your explanation! Peter. [1] With his own soldering iron, if need be ;P. -- 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 jameszee13 at gmail.com Mon Nov 23 15:22:50 2015 From: jameszee13 at gmail.com (James) Date: Mon, 23 Nov 2015 09:22:50 -0500 Subject: best practices for creating keys In-Reply-To: <564D195E.8070904@gbenet.com> References: <564B3AC4.50908@andrewg.com> <564C6A2E.1050004@digitalbrains.com> <564D195E.8070904@gbenet.com> Message-ID: All, I'm pleasantly surprised by the warm and helpful reception of this community to my many questions. Thank you all in advance for your detailed and thorough responses. The conversation thus far has been quite thought-provoking. I thoroughly read and re-read the responses in this thread, tinkered with GPG for many hours and poured over the documentation (again). I still have a few questions: - I believe that GPG has sane settings out-of-the-box, but prefer to verify that trust. ;) Why doesn't GPG set the digest algorithm to SHA512 instead of 256 out of the box? - I'm also curious why the default-preference-list isn't set to something more secure, as suggested here[1]: default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed To be perfectly clear, I am sure the folks who made the decision to choose SHA256 is _far_ more intelligent than I am and there is sound reason behind these default choices. I simply would like to better understand these design decisions. I'm also looking for some clarification around the primary key. Out of the box it appears that GPG will create a private key for signing and certification. Some documentation around the web indicates that the primary key can be stripped of all capabilities, leaving _only_ certify. What are the pros and cons of allowing the private key only to certify, then creating a subkey to sign (and another to encrypt)? To go a bit further down that rabbit hole, let's say I want to create a primary key (with certify-only capabilities), several subkeys and then remove the private key (as has been discussed ad nauseam in this thread); it appears that stripping the capabilities of the primary key to the bare minimum (i.e., no signing, no encrypting, no authenticating) would be "safer," no? My concern is that if my primary key is for certification only, how would it sign other people's certificates to expand the web of trust? I suspect that if the capabilities are set to _only_ certify, I would need to sign other people's keys using my subkey. How would this affect the notion of "even if you lose your subkeys, your identity and web of trust are not impacted as long as your primary key is not compromised?" Seems to me that the primary key /should/ have both certify and sign capabilities to really be useful, no? Any thoughts and ideas regarding these questions is greatly appreciated. James 1 https://help.riseup.net/en/security/message-security/openpgp/best-practices On Wed, Nov 18, 2015 at 7:35 PM, david at gbenet.com wrote: > On 18/11/15 12:08, Peter Lebbing wrote: >> On 17/11/15 15:33, Andrew Gallagher wrote: >>>> https://alexcabal.com/creating-the-perfect-gpg-keypair/ >>> >>> This is a fairly good article - I've used it myself for reference in the >>> past. Also have a look at: >> >> I disagree, I'd recommend people not to read that article, let alone >> follow its advice. >> >> HTH, >> >> Peter. >> >> [1] https://lists.gnupg.org/pipermail/gnupg-users/2015-November/054685.html >> > > Peter, > > When you think about it - if a person stole your laptop with your private and public key on > it - they still could not use your private key to do anything. Security is in the passphrase > one sets to use your key. Without it your buggered and so is anyone who has acquired your > private and public key. They could spend a great deal of time and money - but essentially a > good passphrase is secure. Brute force - beating the shit out of you - may work - the human > link is the weakest in the chain. > > There is no perfect key - they are all "perfect" their security depends on your passphrase. > > Be Happy > > David > -- > ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the > kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No > delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com > From rjh at sixdemonbag.org Mon Nov 23 16:52:02 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 23 Nov 2015 10:52:02 -0500 Subject: best practices for creating keys In-Reply-To: References: <564B3AC4.50908@andrewg.com> <564C6A2E.1050004@digitalbrains.com> <564D195E.8070904@gbenet.com> Message-ID: <56533622.8020408@sixdemonbag.org> > - I believe that GPG has sane settings out-of-the-box, but prefer to > verify that trust. ;) Why doesn't GPG set the digest algorithm to > SHA512 instead of 256 out of the box? For the same reason it doesn't default to RSA-4096: because the authors are unconvinced there's a need. Longer is not the same as better. At some point there's such a thing as enough. SHA-256 is (a) safe enough for essentially all purposes, (b) more interoperable with other OpenPGP implementations, and (c) better for human readability. > I'm also looking for some clarification around the primary key. Out of > the box it appears that GPG will create a private key for signing and > certification. Some documentation around the web indicates that the > primary key can be stripped of all capabilities, leaving _only_ > certify. What are the pros and cons of allowing the private key only > to certify, then creating a subkey to sign (and another to encrypt)? I'm going to repeat my earlier advice: learn to walk before you run. The defaults are safe. Use them. We can have this conversation at great length, but I don't want to encourage you to start doing this. Quite the opposite. Please don't. > thread); it appears that stripping the capabilities of the primary key > to the bare minimum (i.e., no signing, no encrypting, no > authenticating) would be "safer," no? The last word in your sentence is the answer. It's not safer. You're talking about making a bank vault door "safer" by adding a single millimeter of armor plate. Your attention is better spent elsewhere, especially right now when you're just starting out. Focusing on the technical components of the system is ... I hate to say "you're doing it wrong," but IMO, you are. The stuff you're paying attention to right now is pretty much irrelevant and unimportant. The stuff you're ignoring is relevant and important. Start focusing on that. I'd start with: * Do you have a revocation certificate generated? * Is it stored safely? * Who has access to your revocation certificate and/or private key? * How would you know if someone else had access? * How strong is your passphrase? * How do you know how strong it is? * What will you do if you forget your passphrase -- what's your fallback? * If you revoke your certificate, how will you rebuild your personal web of trust? * Is GnuPG integrated into your email workflow? If not, how can it be integrated? * Have you considered storing your certificate on a smartcard? These are the places where GnuPG fails in the real world. In 20+ years of using PGP 2.6+ and GnuPG 1.0+, I've never -- not once, not ever -- encountered anyone who has said, "man, I really wish I'd stripped my certificate, that would've saved me no end of grief," and a lot of people who have said, "man, I really wish I'd safely stored a revocation certificate, that would've saved me no end of grief." From the2nd at otpme.org Mon Nov 23 16:53:48 2015 From: the2nd at otpme.org (the2nd at otpme.org) Date: Mon, 23 Nov 2015 16:53:48 +0100 Subject: scdaemon lockup with Yubikey NEO In-Reply-To: References: Message-ID: <3a3ecea4beb0c02bc963be57ee991b06@otpme.org> Hi, i've done some more testing and found out that the problem starts to exist with openssh version 6.8p1. With 6.7p1 everything works perfect. I downloaded the openssh tarballs one by one, compiled with ./configure;make and just copied the "ssh" binary. I was able to reproduce the problem with the following steps: 1. Start gpg-agent: eval $(gpg-agent --daemon --enable-ssh-support --log-file ~/.gnupg/gpg-agent.log) 2. Login to any host with your SSH key and keep the session open: ssh -l root localhost 3. Plug your yubikey out/in 4. Try to login with your SSH key to any other host With openssh 6.8p1 this fails reproducable. With version 6.7p1 or earlier it works. As a workaround i replaced my ssh client binary with the old version. It would be great to get a real fix for this. But i am unsure where the realm problem lies, gpg or openssh. Maybe we should ask this on the openssh list? regards the2nd On 2015-11-22 03:06, Lance R. Vick wrote: > This happens to me constantly as well. I my case I frequently need to > kill and restart gpg-agent to get things working again on both Arch > Linux and Gentoo. > > On Sat, Nov 21, 2015 at 4:41 AM, the2nd wrote: > >> Hi Ben, >> >> We have a similar Problem since we've upgraded from Ubuntu 15.04 to >> 15.10.? When starting gpg-agent with --log-file the log show the >> following: >> >> 2015-05-30 13:49:36?gpg-agent[3600] error accessing card: >> Conflicting?use >> 2015-05-30 13:49:36?gpg-agent[3600] smartcard signing failed:? >> Conflicting use? >> 2015-05-30 13:49:38?gpg-agent[3600] error getting >> default?authentication keyID of card: Conflicting use >> >> I've asked the list serval times about this issue but got now answer >> yet. So i dont have a solution but it may be interesting if your >> problem is the same... >> >> Regards >> The2nd? >> >> -------- Urspr?ngliche Nachricht -------- >> Von: Ben Warren >> Datum:11.20.2015 16:26 (GMT+01:00) >> An: gnupg-users at gnupg.org >> Betreff: scdaemon lockup with Yubikey NEO >> >> Hi, >> >> I?ve noticed several other problem reports that seem similar, >> hopefully they?re all related and there?s a simple fix. >> >> The problem: >> >> After an indeterminate amount of time (sometimes minutes, sometimes >> hours), any GPG operation that uses my Yubikey NEO device hangs.? >> The two most common operations are SSH authentication and git >> signing.? The following sequence gets things going again: >> >> $ killall -SIGKILL scdaemon >> >> $ gpg2 ?card-status >> >> System particulars: >> >> * Host OS is OS-X Yosemite, although it is also present on >> Mavericks (haven?t tried El Capitan yet) >> >> * GPG 2.1.5 >> >> * Using the Yubikey?s authentication subkey to login to remote >> Linux hosts >> >> * Using the Yubikey?s signing subkey for git signing operations, >> both local and remote >> >> * Using gpg-agent for forwarding both GPG and SSH (great features, >> BTW!) >> >> GPG configuration file: >> >> $ cat ~/.gnupg/gpg-agent.conf >> >> default-cache-ttl 1 >> >> ignore-cache-for-signing >> >> no-allow-external-cache >> >> max-cache-ttl 1 >> >> extra-socket ${HOME}/.gnupg/S.gpg-extra-agent >> >> debug-all >> >> log-file ${HOME}/.gnupg/mygpglogfile.log >> >> enable-ssh-support >> >> I?ll be happy to help debug this, but need some guidance. >> >> thanks, >> >> Ben >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users [1] > > -- > > Lance R. Vick > __________________________________________________ > Cell? ? ? -? 407.283.7596 > Gtalk? ?? -? lance at lrvick.net > Website?? -? http://lrvick.net [2] > PGP Key?? -? http://lrvick.net/0x36C8AAA9.asc [3] > keyserver -? subkeys.pgp.net [4] > __________________________________________________ > > Links: > ------ > [1] http://lists.gnupg.org/mailman/listinfo/gnupg-users > [2] http://lrvick.net > [3] http://lrvick.net/0x36C8AAA9.asc > [4] http://subkeys.pgp.net From jameszee13 at gmail.com Mon Nov 23 17:20:07 2015 From: jameszee13 at gmail.com (James) Date: Mon, 23 Nov 2015 11:20:07 -0500 Subject: best practices for creating keys In-Reply-To: <56533622.8020408@sixdemonbag.org> References: <564B3AC4.50908@andrewg.com> <564C6A2E.1050004@digitalbrains.com> <564D195E.8070904@gbenet.com> <56533622.8020408@sixdemonbag.org> Message-ID: Robert, I appreciate the input and hear you loud and clear. I respect that GPG makes sane, technically secure and well-thought-out decisions. As I mentioned in my previous response, the folks that designed and coded GPG are likely far more intelligent than I. This does not assuage my deep curiosity to understand the various knobs and gears that can be tweaked. Said deep understanding also puts me in a position whereby I can more easily deal with various issues or complexities down the line. The same can be said for almost any complex system, software or not. It seems to me that, perhaps, making these sorts of decisions up front is of some value. If you create a primary key, upload it to a public keyserver and later decide: "hrm, my public key should really only certify, not sign," it's a bit too late. (although not impossible, difficult to change ex post facto). It's also worth noting that the suggestion to remove the primary key from your laptop isn't thrown up on a few random blogs; instead it is something that other projects[1] encourage. If one's primary key is his or her identity, I'd like to be certain that I correctly create the key(s). Thus being meticulous and careful in creating primary key seems like a reasonable step, IMHO. Finally, I do appreciate the list of things that I should focus on -- there are several I had not contemplated and will now do so. James https://wiki.debian.org/Subkeys On Mon, Nov 23, 2015 at 10:52 AM, Robert J. Hansen wrote: >> - I believe that GPG has sane settings out-of-the-box, but prefer to >> verify that trust. ;) Why doesn't GPG set the digest algorithm to >> SHA512 instead of 256 out of the box? > > For the same reason it doesn't default to RSA-4096: because the authors > are unconvinced there's a need. Longer is not the same as better. At > some point there's such a thing as enough. > > SHA-256 is (a) safe enough for essentially all purposes, (b) more > interoperable with other OpenPGP implementations, and (c) better for > human readability. > >> I'm also looking for some clarification around the primary key. Out of >> the box it appears that GPG will create a private key for signing and >> certification. Some documentation around the web indicates that the >> primary key can be stripped of all capabilities, leaving _only_ >> certify. What are the pros and cons of allowing the private key only >> to certify, then creating a subkey to sign (and another to encrypt)? > > I'm going to repeat my earlier advice: learn to walk before you run. > The defaults are safe. Use them. We can have this conversation at > great length, but I don't want to encourage you to start doing this. > Quite the opposite. Please don't. > >> thread); it appears that stripping the capabilities of the primary key >> to the bare minimum (i.e., no signing, no encrypting, no >> authenticating) would be "safer," no? > > The last word in your sentence is the answer. > > It's not safer. You're talking about making a bank vault door "safer" > by adding a single millimeter of armor plate. Your attention is better > spent elsewhere, especially right now when you're just starting out. > Focusing on the technical components of the system is ... I hate to say > "you're doing it wrong," but IMO, you are. The stuff you're paying > attention to right now is pretty much irrelevant and unimportant. The > stuff you're ignoring is relevant and important. Start focusing on > that. I'd start with: > > * Do you have a revocation certificate generated? > * Is it stored safely? > * Who has access to your revocation certificate and/or private key? > * How would you know if someone else had access? > * How strong is your passphrase? > * How do you know how strong it is? > * What will you do if you forget your passphrase -- what's your > fallback? > * If you revoke your certificate, how will you rebuild your personal > web of trust? > * Is GnuPG integrated into your email workflow? If not, how can it > be integrated? > * Have you considered storing your certificate on a smartcard? > > These are the places where GnuPG fails in the real world. In 20+ years > of using PGP 2.6+ and GnuPG 1.0+, I've never -- not once, not ever -- > encountered anyone who has said, "man, I really wish I'd stripped my > certificate, that would've saved me no end of grief," and a lot of > people who have said, "man, I really wish I'd safely stored a revocation > certificate, that would've saved me no end of grief." > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From peter at digitalbrains.com Mon Nov 23 17:54:51 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 23 Nov 2015 17:54:51 +0100 Subject: best practices for creating keys In-Reply-To: References: <564B3AC4.50908@andrewg.com> <564C6A2E.1050004@digitalbrains.com> <564D195E.8070904@gbenet.com> <56533622.8020408@sixdemonbag.org> Message-ID: <565344DB.2080508@digitalbrains.com> On 23/11/15 17:20, James wrote: > If you create a primary key, upload it to a public > keyserver and later decide: "hrm, my public key should really only > certify, not sign," it's a bit too late. (although not impossible, > difficult to change ex post facto). Okay, so let me answer this one detail: Separating encryption from signing is a general advice (and done by default) because there is a range of subtleties that are avoided by this simple action. This affects how your keys are actually *used*, not *usable*. However, one who has access to the private part of the primary key can easily change the capabilities of the primary key to add signing as a capability, even if you had it removed. There is not enough reason to separate certifications from data signatures to make it the default. Whether there is reason at all from a cryptographic standpoint, I do not know. But it is certainly nothing to be worried about, or it would have been dealt with in the defaults. Also, let me quote and answer a part from an earlier mail you wrote: > My concern is that if my primary key is for certification only, how > would it sign other people's certificates to expand the web of trust? > I suspect that if the capabilities are set to _only_ certify, I would > need to sign other people's keys using my subkey. No, signing other people's keys is known as certification, and is something that can *only* be done by the primary key. If you have an offline primary key, you would use an offline system that has the secret part available to sign other people's keys, and then transfer the signature from that offline system. Or if you only delete the primary key from your laptop but still have it on your desktop, you'd use the latter. For that setup, you could create a signing subkey for your laptop to use without removing signing capability from your primary key. > It's also worth noting that the suggestion to remove the primary key > from your laptop isn't thrown up on a few random blogs; instead it is > something that other projects[1] encourage. Yes, well, most importantly, maybe their threat model is different. In this specific case, note that a signature by a Debian developer means that, by and large, any Debian machine on the planet will trust the software update that that signature validates and install it on the next system upgrade. That's quite an important signature. Normally, a Debian dev can only upload source code, not binaries, but it's still a significant amount of power. > If one's primary key is his or her identity, I'd like to be certain > that I correctly create the key(s). Thus being meticulous and careful > in creating primary key seems like a reasonable step, IMHO. Yes, but the defaults are sane, so there's no need to fiddle with things that are different from the defaults. It's all the other stuff you should be meticulous about. Furthermore, all is not lost if you wish to swap your primary key. Many people will accept a transition statement and issue a signature on your new key. Also; the Web of Trust is overrated, and you can probably persuade your friends more easily to recertify. 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 From rjh at sixdemonbag.org Mon Nov 23 18:05:22 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 23 Nov 2015 12:05:22 -0500 Subject: best practices for creating keys In-Reply-To: References: <564B3AC4.50908@andrewg.com> <564C6A2E.1050004@digitalbrains.com> <564D195E.8070904@gbenet.com> <56533622.8020408@sixdemonbag.org> Message-ID: <56534752.8030000@sixdemonbag.org> > The same can be said for almost any complex system, software or not. Absolutely. Please don't misinterpret what I said as trying to dissuade you from curiosity. I'm just urging you to not let your curiosity lead you into making poor decisions from the get-go. The following anecdote is meandering, but if you'll bear with me for two paragraphs it'll make sense: I live in the United States, in a state which allows private citizens, under incredibly close regulation, to own military firearms. When I visit the rifle range, sometimes I'll spend some time with a suppressed German-made MP5SD3 submachinegun. (It's not mine: a friend owns one and we sometimes hit the range together.) It's a nice piece of kit; I like it. And quite often, other people who are at the range want to talk shop about it. We get into discussions about roller-locked firearms like the Cz52 and MG42 versus roller-delayed firearms like the MP5, how annoying it is when people get the terminology wrong, whether it's a good thing or a bad thing the MP5 uses a fluted chamber, how anyone who thinks it's okay to fire subsonic 9mm from the MP5 needs their head examined, and so on and so on. And it's fun, as far as it goes, and it's often educational for the people who've never seen an MP5 before and are fascinated to learn more about its inner workings. It's great -- up until they think they know enough to use an MP5 on the range, despite the fact they've never fired a weapon before. At that point we have to explain to them that look, yes, they know a lot more about the MP5 than most people do, but really, they need to start off with something small, like a nice .22 Ruger Mk II, develop the basic skills, learn trigger discipline and proper usage of safeties, learn how the range operates and what the various calls by the Range Safety Officers mean, etcetera. There's a huge amount to learn: they don't need to make things worse by leaping straight over this stuff straight to firing fully-automatic military hardware. That's just imprudent, and we'd be awful human beings if we permitted them to do that. That's what we're talking about here. The knobs and dials on GnuPG are great fun to learn about: you're in good company! But there's a big reason why we're urging you to not do what you want to do, and that's because you're not yet competent to do what you want to do. We'd rather see you start off with small steps, and from there move on to the big ones, than have you start off big. Admittedly, it's highly unlikely that screwing up with GnuPG will lead to a magazine of 9mm being sprayed around the room. But it's the principle of the thing. :) So: for now, please stick with the defaults. > It seems to me that, perhaps, making these sorts of decisions up front > is of some value. Not really. It's probably not worth worrying about. > If you create a primary key, upload it to a public > keyserver and later decide: "hrm, my public key should really only > certify, not sign," it's a bit too late. No. One of the important skills to learn early on is about how to migrate a certificate. You're going to make mistakes. You'll forget passphrases, you'll compromise your keys, you'll realize you made a hash of it and need to start over again. How do you recover from this? How do you communicate a change-of-certificate with your correspondents? Etc. The only reason to think "it's a bit too late" is if a) you're not allowed to change your certificate -- you *must* keep the same one for the next X years b) you don't know how to migrate to a new certificate There are almost certainly people and groups for whom (a) applies. If you're one of them, please let me know. But if (b) applies, then I suggest learning the skill, because it's important. :) > It's also worth noting that the suggestion to remove the primary key > from your laptop isn't thrown up on a few random blogs; instead it is > something that other projects[1] encourage. That wiki page is guidance *for Debian*. Debian has some very specific operating restrictions which are unlikely to apply to you. The guidelines Debian put together apply to them, in their environment, facing their threat model, which they defend with their particular set of resources. It is not guidance for you, unless you're part of Debian. By all means, study it! It's a well-written policy. Learn what goes into their policy and why they make the decisions they do. But don't think that what they recommend will automatically apply to you. Some of it will be applicable; a lot of it won't be. > If one's primary key is his or her identity, I'd like to be certain > that I correctly create the key(s). Yes. And, as several people here have told you, you correctly create it by running "gpg --gen-key" and accepting the defaults. From jameszee13 at gmail.com Mon Nov 23 21:31:10 2015 From: jameszee13 at gmail.com (James) Date: Mon, 23 Nov 2015 15:31:10 -0500 Subject: best practices for creating keys In-Reply-To: <56534752.8030000@sixdemonbag.org> References: <564B3AC4.50908@andrewg.com> <564C6A2E.1050004@digitalbrains.com> <564D195E.8070904@gbenet.com> <56533622.8020408@sixdemonbag.org> <56534752.8030000@sixdemonbag.org> Message-ID: Thank you Robert and Peter. It appears that information I had read previously was erroneous. I was under the impression the capabilities (at least for the primary key) were set in stone, hence my apprehension at avoiding those insatiable knobs and gears I like to tinker with. ;) This thread has been tremendously insightful. My thanks to all who responded and shared their perspectives. James On Mon, Nov 23, 2015 at 12:05 PM, Robert J. Hansen wrote: >> The same can be said for almost any complex system, software or not. > > Absolutely. Please don't misinterpret what I said as trying to dissuade > you from curiosity. I'm just urging you to not let your curiosity lead > you into making poor decisions from the get-go. > > The following anecdote is meandering, but if you'll bear with me for two > paragraphs it'll make sense: > > I live in the United States, in a state which allows private citizens, > under incredibly close regulation, to own military firearms. When I > visit the rifle range, sometimes I'll spend some time with a suppressed > German-made MP5SD3 submachinegun. (It's not mine: a friend owns one and > we sometimes hit the range together.) It's a nice piece of kit; I like > it. And quite often, other people who are at the range want to talk > shop about it. We get into discussions about roller-locked firearms > like the Cz52 and MG42 versus roller-delayed firearms like the MP5, how > annoying it is when people get the terminology wrong, whether it's a > good thing or a bad thing the MP5 uses a fluted chamber, how anyone who > thinks it's okay to fire subsonic 9mm from the MP5 needs their head > examined, and so on and so on. And it's fun, as far as it goes, and > it's often educational for the people who've never seen an MP5 before > and are fascinated to learn more about its inner workings. > > It's great -- up until they think they know enough to use an MP5 on the > range, despite the fact they've never fired a weapon before. At that > point we have to explain to them that look, yes, they know a lot more > about the MP5 than most people do, but really, they need to start off > with something small, like a nice .22 Ruger Mk II, develop the basic > skills, learn trigger discipline and proper usage of safeties, learn how > the range operates and what the various calls by the Range Safety > Officers mean, etcetera. There's a huge amount to learn: they don't > need to make things worse by leaping straight over this stuff straight > to firing fully-automatic military hardware. That's just imprudent, and > we'd be awful human beings if we permitted them to do that. > > That's what we're talking about here. The knobs and dials on GnuPG are > great fun to learn about: you're in good company! But there's a big > reason why we're urging you to not do what you want to do, and that's > because you're not yet competent to do what you want to do. We'd rather > see you start off with small steps, and from there move on to the big > ones, than have you start off big. > > Admittedly, it's highly unlikely that screwing up with GnuPG will lead > to a magazine of 9mm being sprayed around the room. But it's the > principle of the thing. :) > > So: for now, please stick with the defaults. > >> It seems to me that, perhaps, making these sorts of decisions up front >> is of some value. > > Not really. It's probably not worth worrying about. > >> If you create a primary key, upload it to a public >> keyserver and later decide: "hrm, my public key should really only >> certify, not sign," it's a bit too late. > > No. > > One of the important skills to learn early on is about how to migrate a > certificate. You're going to make mistakes. You'll forget passphrases, > you'll compromise your keys, you'll realize you made a hash of it and > need to start over again. How do you recover from this? How do you > communicate a change-of-certificate with your correspondents? Etc. > > The only reason to think "it's a bit too late" is if > > a) you're not allowed to change your certificate -- you > *must* keep the same one for the next X years > b) you don't know how to migrate to a new certificate > > There are almost certainly people and groups for whom (a) applies. If > you're one of them, please let me know. But if (b) applies, then I > suggest learning the skill, because it's important. :) > >> It's also worth noting that the suggestion to remove the primary key >> from your laptop isn't thrown up on a few random blogs; instead it is >> something that other projects[1] encourage. > > That wiki page is guidance *for Debian*. Debian has some very specific > operating restrictions which are unlikely to apply to you. The > guidelines Debian put together apply to them, in their environment, > facing their threat model, which they defend with their particular set > of resources. > > It is not guidance for you, unless you're part of Debian. > > By all means, study it! It's a well-written policy. Learn what goes > into their policy and why they make the decisions they do. But don't > think that what they recommend will automatically apply to you. Some of > it will be applicable; a lot of it won't be. > >> If one's primary key is his or her identity, I'd like to be certain >> that I correctly create the key(s). > > Yes. And, as several people here have told you, you correctly create it > by running "gpg --gen-key" and accepting the defaults. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From benjamin.black at gmail.com Mon Nov 23 16:18:22 2015 From: benjamin.black at gmail.com (Benjamin Black) Date: Mon, 23 Nov 2015 15:18:22 +0000 Subject: best practices for creating keys In-Reply-To: References: <564B3AC4.50908@andrewg.com> <564C6A2E.1050004@digitalbrains.com> <564D195E.8070904@gbenet.com> Message-ID: Among the privacy-concerned, there is a strong impulse to use the hardest possible cryptography. The truth is that 2048-bit keys and a 256-bit hash algorithm are completely secure against brute force attacks, and barring any surprising developments in cryptanalysis, will remain so for a good long time. If someone is really motivated to invade your privacy, they are not going to attack crypto, they are going to do an end-run around it by attacking the rest of the system. The choice of key size has never been the weak point: it doesn't matter what size key you use if there is a key logger installed on your system. Watch this excellent presentation by Peter Gutmann about this subject at Linux.conf.au 2015: https://www.youtube.com/watch?v=_ahcUuNO4so On Mon, Nov 23, 2015 at 9:25 AM James wrote: > All, > > I'm pleasantly surprised by the warm and helpful reception of this > community to my many questions. Thank you all in advance for your > detailed and thorough responses. The conversation thus far has been > quite thought-provoking. > > I thoroughly read and re-read the responses in this thread, tinkered > with GPG for many hours and poured over the documentation (again). I > still have a few questions: > > - I believe that GPG has sane settings out-of-the-box, but prefer to > verify that trust. ;) Why doesn't GPG set the digest algorithm to > SHA512 instead of 256 out of the box? > - I'm also curious why the default-preference-list isn't set to > something more secure, as suggested here[1]: > > default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES > CAST5 ZLIB BZIP2 ZIP Uncompressed > > To be perfectly clear, I am sure the folks who made the decision to > choose SHA256 is _far_ more intelligent than I am and there is sound > reason behind these default choices. I simply would like to better > understand these design decisions. > > I'm also looking for some clarification around the primary key. Out of > the box it appears that GPG will create a private key for signing and > certification. Some documentation around the web indicates that the > primary key can be stripped of all capabilities, leaving _only_ > certify. What are the pros and cons of allowing the private key only > to certify, then creating a subkey to sign (and another to encrypt)? > > To go a bit further down that rabbit hole, let's say I want to create > a primary key (with certify-only capabilities), several subkeys and > then remove the private key (as has been discussed ad nauseam in this > thread); it appears that stripping the capabilities of the primary key > to the bare minimum (i.e., no signing, no encrypting, no > authenticating) would be "safer," no? > > My concern is that if my primary key is for certification only, how > would it sign other people's certificates to expand the web of trust? > I suspect that if the capabilities are set to _only_ certify, I would > need to sign other people's keys using my subkey. How would this > affect the notion of "even if you lose your subkeys, your identity and > web of trust are not impacted as long as your primary key is not > compromised?" > > Seems to me that the primary key /should/ have both certify and sign > capabilities to really be useful, no? > > Any thoughts and ideas regarding these questions is greatly appreciated. > > James > > 1 > https://help.riseup.net/en/security/message-security/openpgp/best-practices > > On Wed, Nov 18, 2015 at 7:35 PM, david at gbenet.com > wrote: > > On 18/11/15 12:08, Peter Lebbing wrote: > >> On 17/11/15 15:33, Andrew Gallagher wrote: > >>>> https://alexcabal.com/creating-the-perfect-gpg-keypair/ > >>> > >>> This is a fairly good article - I've used it myself for reference in > the > >>> past. Also have a look at: > >> > >> I disagree, I'd recommend people not to read that article, let alone > >> follow its advice. > >> > >> HTH, > >> > >> Peter. > >> > >> [1] > https://lists.gnupg.org/pipermail/gnupg-users/2015-November/054685.html > >> > > > > Peter, > > > > When you think about it - if a person stole your laptop with your > private and public key on > > it - they still could not use your private key to do anything. Security > is in the passphrase > > one sets to use your key. Without it your buggered and so is anyone who > has acquired your > > private and public key. They could spend a great deal of time and money > - but essentially a > > good passphrase is secure. Brute force - beating the shit out of you - > may work - the human > > link is the weakest in the chain. > > > > There is no perfect key - they are all "perfect" their security depends > on your passphrase. > > > > Be Happy > > > > David > > -- > > ?See the sanity of the man! No gods, no angels, no demons, no body. > Nothing of the > > kind.Stern, sane,every brain-cell perfect and complete even at the > moment of death. No > > delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com > > > > _______________________________________________ > 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 jan at nitrokey.com Mon Nov 23 23:10:21 2015 From: jan at nitrokey.com (Jan Suhr) Date: Mon, 23 Nov 2015 23:10:21 +0100 Subject: Crowdfunding USB Security Key for Email- and Data-Encryption - Nitrokey Storage In-Reply-To: <5652D173.7010909@gmail.com> References: <564E412F.5010401@nitrokey.com> <2552257.By6gRoOvnt@localhost> <565024B7.9070300@nitrokey.com> <56505079.3070805@digitalbrains.com> <5650A894.3070808@gmail.com> <08fa1b54c5b6b7c99f672cb95bac8527@suhr.org> <5652D173.7010909@gmail.com> Message-ID: <56538ECD.6080709@nitrokey.com> Hi Diego, Am 23.11.2015 um 09:42 schrieb NdK: > Il 23/11/2015 08:56, Jan Suhr ha scritto: > >>> I didn't look at the code (so this could be completely wrong and I'd be >>> happy!), but if the OTP key is decrypted using a key in the chip after >>> verifying that the card accepts the PIN, then it's even worse, since >>> that master key is in cleartext somewhere outside the smartcard. So, >>> with some efforts and a good lab the OTP keys can be extracted. >> The key is stored in the card. > Then, replacing the card replaces the OTP key. No? If the optional PIN protection for OTPs is enabled, replacing the smart card would render the OTPs inaccessible. Regards, Jan > BYtE, > Diego > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- Jan Suhr Nitrokey UG (haftungsbeschr?nkt) Web: https://www.nitrokey.com Email: jan at nitrokey.com Phone: +49 163 7010 408 Berliner Str. 166, 10715 Berlin, Germany CEO / Gesch?ftsf?hrer: Jan Suhr Register Record: AG Charlottenburg, HRB 164549 B VAT ID / USt-IdNr.: DE300136599 From andrey.od.utkin at gmail.com Tue Nov 24 02:16:31 2015 From: andrey.od.utkin at gmail.com (Andrey Utkin) Date: Tue, 24 Nov 2015 03:16:31 +0200 Subject: Why gpg 2.1.9 cannot export secret key without passphrase? Message-ID: <5653BA6F.1040002@gmail.com> $ gpg --export-secret-keys (pops a Xorg dialog window from my console, driving me nuts) (i give empty passphrase) (it asks me whether i am sure I want no passphrase) (I say yes) gpg: key XXXXXXXX: error receiving key from agent: No passphrase given - skipped Why is there such a _policy_? Maybe I am lost and I am using Windows which re-asks everything and still refuses to do what I want? -- OpenPGP usage is appreciated (it also helps your letter to bypass spam filters). To email me with encryption easily, go https://encrypt.to/0xC6FCDB11 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From Felix.Seip at giepa.de Thu Nov 26 16:00:01 2015 From: Felix.Seip at giepa.de (Felix Seip) Date: Thu, 26 Nov 2015 16:00:01 +0100 Subject: GnuPG 2.1: --auto-key-locate dane Message-ID: <1DC3C8C67280FB4C9A402CB6DB1358F51AB22817EB@S2008SBS.intern.giepa.de> Hi, The past week I have been trying to figure out how to receive a public key from a DNS domain through GnuPG 2.1.9. The way I have been attempting to do this is by executing: gpg --auto-key-locate dane -ea -r felixseip at gmx.de However, every time I get the following error message: gpg: error retrieving 'felixseip at gmx.de' via PKA: Unknown IPC command gpg: felixseip at gmx.de: skipped: Unknown IPC command gpg: [stdin]: encryption failed: Unknown IPC command Clearly I am doing something wrong and was wondering if someone could help me with this problem. Thank you in advance, Felix Seip Verschl?sseln Sie Ihre E-Mails mit gpg4o f?r Outlook | Encrypt your email with gpg4o ------------------------------------------------------------------------------------------------------------------- Felix Seip Auszubildender [cid:image001.jpg at 01D12862.B4B67EE0]Giegerich & Partner GmbH Robert-Bosch-Stra?e 18 | D-63303 Dreieich Tel. +49 6103 5881-54 | Fax +49 6103 5881-39 felix.seip at giepa.de | http://www.giepa.de Gesch?ftsf?hrer: Dipl.-Ing. (TU) Hans-Joachim Giegerich Amtsgericht Offenbach/Main | HRB 33236 ------------------------------------------------------------------------------------------------------------------- [cid:image002.jpg at 01D12862.B4B67EE0] ------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1183 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 3170 bytes Desc: image002.jpg URL: From mls at dabpunkt.eu Thu Nov 26 23:00:04 2015 From: mls at dabpunkt.eu (Daniel Baur) Date: Thu, 26 Nov 2015 23:00:04 +0100 Subject: GnuPG 2.1: --auto-key-locate dane In-Reply-To: <1DC3C8C67280FB4C9A402CB6DB1358F51AB22817EB@S2008SBS.intern.giepa.de> References: <1DC3C8C67280FB4C9A402CB6DB1358F51AB22817EB@S2008SBS.intern.giepa.de> Message-ID: <565780E4.2070100@dabpunkt.eu> Hello, Am 26.11.2015 um 16:00 schrieb Felix Seip: > Clearly I am doing something wrong and was wondering if someone could > help me with this problem. Hello, Am 26.11.2015 um 16:00 schrieb Felix Seip: > Clearly I am doing something wrong and was wondering if someone could > help me with this problem. dig type61 1ed6d5e274e32624065e36218dd952070defca5ad2618ec8d64511c6._openpgpkey.gmx.de returns no key. So AFAIS the error is not at you or gpg, but at gmx. The OpenPGPKey-DNS-entry for my mail-adress works, if you like to test gpg. Sincerely, DaB. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 880 bytes Desc: OpenPGP digital signature URL: From anthony at cajuntechie.org Fri Nov 27 00:22:23 2015 From: anthony at cajuntechie.org (Anthony Papillion) Date: Thu, 26 Nov 2015 17:22:23 -0600 Subject: Insecure memory message on PC-BSD Message-ID: <5657942F.7000807@cajuntechie.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hey Everyone, I'm using PC-BSD 10.2 and I get the message "using insecure memory!" when I type gpg2 at the terminal. Is this a major issue or is it something I can (usually) ignore? Is there a way to use "secure" memory? Thanks, Anthony - -- Phone: 1.845.666.1114 Skype: cajuntechie PGP Key: 0x028ADF7453B04B15 Fingerprint: C5CE E687 DDC2 D12B 9063 56EA 028A DF74 53B0 4B15 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWV5QvAAoJEAKK33RTsEsVaDgQALyDmhgelWU/5d/nhqmhoxYO 5LHO5OujnnE5+acbpv03idgPBCIzcUjmpNom1ejjXs+KWdVJ6bPTYZp42G7ROA3V OcYGpKTQvFHbCEPvMhp9rpeLGE30wk5hONirhg/lBCsoghG23Ky+ovK0f/B5lKOm Wmkx4sTivf8hgSmeKjYz2KCxGPxf5GzOTSDo0bOSaaaLDhKPAtJ0giNloJ61u8+D hxpjkL03I7bnoS1wZXhJ3S0am4bOG0NGSUdEA9F3FN8gyFOL7KuL+H0Xzg08dk5m kLhgHf8s1VPLD4y+9U2tAHphaS//ycEKq2QuvPybROv6lrGHOrak0UDj0kPMZFln Y8KuZtZMfQBT8qlv/wCX70iMruBx9OFr7UIDyq1tRC4qmKCW/ksxnnAHEm4/qr5M zgrNjyuIOF2Cpw286hpuj6H+E+PGpPJG4P8X4KS45830s1HIMPFecD+VxgmuXgh4 8QmEE8+CZv6MlCzYD9L/EHhxPmggEaWmdV4eLMUOCJXdURSJ7CbllXD0Xiti8IXM nt4sfatBt8LyloFN5OpZlayuGq48TCANUXjWon0vpNhGXmuGoyhH0LU1Ly7nBdHa S3yxor/1vDx2c43+ox58XLVdnXwZ5gLHuZrMOjib1rnenK73qdXr6hW3ptTF3xxH ZEqukaaFBnCsr2T4t5Mw =NdzN -----END PGP SIGNATURE----- From wk at gnupg.org Fri Nov 27 07:58:17 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 27 Nov 2015 07:58:17 +0100 Subject: GnuPG 2.1: --auto-key-locate dane In-Reply-To: <565780E4.2070100@dabpunkt.eu> (Daniel Baur's message of "Thu, 26 Nov 2015 23:00:04 +0100") References: <1DC3C8C67280FB4C9A402CB6DB1358F51AB22817EB@S2008SBS.intern.giepa.de> <565780E4.2070100@dabpunkt.eu> Message-ID: <878u5kszcm.fsf@vigenere.g10code.de> On Thu, 26 Nov 2015 23:00, mls at dabpunkt.eu said: > returns no key. So AFAIS the error is not at you or gpg, but at gmx. > > The OpenPGPKey-DNS-entry for my mail-adress works, if you like to test gpg. Not for me: $ gpg --auto-key-locate clear,pka,dane,local -v --locate-key mls at dabpunkt.ue [...] gpg: error retrieving 'mls at dabpunkt.ue' via PKA: Not found gpg: error retrieving 'mls at dabpunkt.ue' via DANE: Not found gpg: can't handle public key algorithm 105 gpg: error retrieving 'mls at dabpunkt.ue' via Local: No public key gpg: key "mls at dabpunkt.ue" not found: No public key This is the current version but there are no changes related to DANE since 2.1.9. I redacted your address in the above transscript (eu->ue). A likely reason for the problem is a change of the algorithm from SHA-224 to a truncated SHA-256 in one of the last OpenPGP drafts. Use "gpg --print-dane-records -k mls at dabpunkt.ue" to output a suitbale DANE record. Here is a working example: $ gpg --auto-key-locate clear,dane,local -v --locate-key wk at gnupg.org [...] gpg: pub dsa2048/F2AD85AC1E42B367 2007-12-31 Werner Koch gpg: key F2AD85AC1E42B367: "Werner Koch " not changed gpg: Total number processed: 1 gpg: unchanged: 1 gpg: auto-key-locate found fingerprint 80615870F5BAD690333686D0F2AD85AC1E42B367 gpg: automatically retrieved 'wk at gnupg.org' via DANE [...] Note that using --locate-key is better because it uses the same strategy as used by -r. In the second example I left out PKA because I also have a PKA entry for my address. By using "clear" I override defaults set in gpg.conf and "local" instructs gpg to check the local keyring after "dane". Another address for testing is my g10code address. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From Felix.Seip at giepa.de Fri Nov 27 08:38:55 2015 From: Felix.Seip at giepa.de (Felix Seip) Date: Fri, 27 Nov 2015 08:38:55 +0100 Subject: AW: GnuPG 2.1: --auto-key-locate dane In-Reply-To: <878u5kszcm.fsf@vigenere.g10code.de> References: <1DC3C8C67280FB4C9A402CB6DB1358F51AB22817EB@S2008SBS.intern.giepa.de> <565780E4.2070100@dabpunkt.eu> <878u5kszcm.fsf@vigenere.g10code.de> Message-ID: <1DC3C8C67280FB4C9A402CB6DB1358F51AB22817FA@S2008SBS.intern.giepa.de> Thank you for your responses! I was receiving the unknown IPC command because I had the GnuPG 2.0 agent and the GnuPG 2.1.9 agent running at the same time Best Regards, Felix Seip -----Urspr?ngliche Nachricht----- Von: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] Im Auftrag von Werner Koch Gesendet: Freitag, 27. November 2015 07:58 An: Daniel Baur Cc: gnupg-users at gnupg.org Betreff: Re: GnuPG 2.1: --auto-key-locate dane On Thu, 26 Nov 2015 23:00, mls at dabpunkt.eu said: > returns no key. So AFAIS the error is not at you or gpg, but at gmx. > > The OpenPGPKey-DNS-entry for my mail-adress works, if you like to test gpg. Not for me: $ gpg --auto-key-locate clear,pka,dane,local -v --locate-key mls at dabpunkt.ue [...] gpg: error retrieving 'mls at dabpunkt.ue' via PKA: Not found gpg: error retrieving 'mls at dabpunkt.ue' via DANE: Not found gpg: can't handle public key algorithm 105 gpg: error retrieving 'mls at dabpunkt.ue' via Local: No public key gpg: key "mls at dabpunkt.ue" not found: No public key This is the current version but there are no changes related to DANE since 2.1.9. I redacted your address in the above transscript (eu->ue). A likely reason for the problem is a change of the algorithm from SHA-224 to a truncated SHA-256 in one of the last OpenPGP drafts. Use "gpg --print-dane-records -k mls at dabpunkt.ue" to output a suitbale DANE record. Here is a working example: $ gpg --auto-key-locate clear,dane,local -v --locate-key wk at gnupg.org [...] gpg: pub dsa2048/F2AD85AC1E42B367 2007-12-31 Werner Koch gpg: key F2AD85AC1E42B367: "Werner Koch " not changed gpg: Total number processed: 1 gpg: unchanged: 1 gpg: auto-key-locate found fingerprint 80615870F5BAD690333686D0F2AD85AC1E42B367 gpg: automatically retrieved 'wk at gnupg.org' via DANE [...] Note that using --locate-key is better because it uses the same strategy as used by -r. In the second example I left out PKA because I also have a PKA entry for my address. By using "clear" I override defaults set in gpg.conf and "local" instructs gpg to check the local keyring after "dane". Another address for testing is my g10code address. 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 From stieizc.33 at gmail.com Fri Nov 27 09:43:09 2015 From: stieizc.33 at gmail.com (Charlie Brown) Date: Fri, 27 Nov 2015 16:43:09 +0800 Subject: gpg-agent prompt slow to show up Message-ID: Hello everyone, I'm new to gpg, and I'm trying the agent. I noticed that when gpg needs to prompt me for pass phrase, the prompt shows up about 15 seconds after I issue the command (e.g. gpg --decrypt or git commit -S). The problem exists with both gpg --use-agent and gpg2. I then tried the --no-use-agent flag of gpg, and the cli prompt showed up instantly, but sadly it doesn't not use the agent by its nature. My colleagues say that they do not have such problem. Any idea, or how can I look into this problem? This is the output from gpg-agent --daemon -vv: <-- Issue a command that will prompt for pass phrase --> gpg-agent[6458]: handler 0x7f42eb30c700 for fd 5 started gpg-agent[6458]: starting a new PIN Entry <-- Long annoying delay --> <-- Then the prompt show up --> gpg-agent[6458]: handler 0x7f42ebb0d700 for fd 8 started gpg-agent[6458]: socket is still served by this server gpg-agent[6458]: handler 0x7f42ebb0d700 for fd 8 terminated Here's the version of the gpg components: gpg-agent 2.1.9 libgcrypt 1.6.4 gpg 1.4.19 gpg2 2.1.9 Sincerely, ??? Wenxin Wang Department of Electronic Engineering, Tsinghua University, Beijing 100084, P. R. China (+86)18811369901 Email?wangwx12 at mails.tsinghua.edu.cn From demfloro at demfloro.ru Fri Nov 27 10:39:30 2015 From: demfloro at demfloro.ru (Dmitrii Tcvetkov) Date: Fri, 27 Nov 2015 12:39:30 +0300 Subject: Why gpg 2.1.9 cannot export secret key without passphrase? In-Reply-To: <5653BA6F.1040002@gmail.com> References: <5653BA6F.1040002@gmail.com> Message-ID: <20151127123930.02d71cff@fire> On Tue, 24 Nov 2015 03:16:31 +0200 Andrey Utkin wrote: > $ gpg --export-secret-keys > (pops a Xorg dialog window from my console, driving me nuts) > (i give empty passphrase) > (it asks me whether i am sure I want no passphrase) > (I say yes) > gpg: key XXXXXXXX: error receiving key from agent: No passphrase > given - skipped > > Why is there such a _policy_? > Maybe I am lost and I am using Windows which re-asks everything and > still refuses to do what I want? > Hello. In this case passphrase is needed to decrypt private key from keyring. Becuase of passphrase is not provided gpg-agent can't give gpg the private key. Private key exports in cleartext. From peter at digitalbrains.com Fri Nov 27 11:32:37 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 27 Nov 2015 11:32:37 +0100 Subject: best practices for creating keys In-Reply-To: References: <564B3AC4.50908@andrewg.com> <564C6A2E.1050004@digitalbrains.com> <564D195E.8070904@gbenet.com> <56533622.8020408@sixdemonbag.org> <56534752.8030000@sixdemonbag.org> Message-ID: <56583145.7040408@digitalbrains.com> On 23/11/15 21:31, James wrote: > It appears that information I had read previously was erroneous. I was > under the impression the capabilities (at least for the primary key) > were set in stone, hence my apprehension at avoiding those insatiable > knobs and gears I like to tinker with. ;) Well, GnuPG doesn't provide an easy means to change them; it could be that you would need to edit the source. However, that is hardly an obstacle for an attacker who can write C code... It shouldn't be difficult to write an ugly little hack to replace your capabilities. The first thing that comes to mind is changing the code creating the signature that extends the expiration date to create the signature that sets capabilities. Compile, run, throw away. 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 peter at digitalbrains.com Fri Nov 27 12:28:07 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 27 Nov 2015 12:28:07 +0100 Subject: Why gpg 2.1.9 cannot export secret key without passphrase? In-Reply-To: <20151127123930.02d71cff@fire> References: <5653BA6F.1040002@gmail.com> <20151127123930.02d71cff@fire> Message-ID: <56583E47.8090307@digitalbrains.com> On 27/11/15 10:39, Dmitrii Tcvetkov wrote: > Private key exports in cleartext. Are you sure? I can't export an unprotected private key. The topic has come up earlier on this mailing list, in [1]. If I have a passphrase on a private key, and I export it, it prompts me for the passphrase and the exported key is protected by the passphrase. If I don't have a passphrase set for a key and I export it, it prompts me as follows: > This key (or subkey) is not protected with a passphrase. Please enter a new > passphrase to export it. If I don't enter a passphrase, it prompts me again warning me this is a bad idea, I stubbornly choose "Yes, protection is not needed". Then the terminal prompts: > gpg: key DCDFDFA4: error receiving key from agent: No passphrase given - skipped And it fails. I think it makes sense to be able to store a private key without a passphrase in a safe place (as in: an actual safe), so you don't run the risk that you forgot the passphrase. Currently, this is not possible, but of course you can use the passphrase "passphrase", make a note that that is your passphrase and store the note in the same safe. HTH, Peter. [1] https://lists.gnupg.org/pipermail/gnupg-devel/2014-October/028919.html -- 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 andrewg at andrewg.com Fri Nov 27 12:41:14 2015 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 27 Nov 2015 11:41:14 +0000 Subject: best practices for creating keys In-Reply-To: <56583145.7040408@digitalbrains.com> References: <564B3AC4.50908@andrewg.com> <564C6A2E.1050004@digitalbrains.com> <564D195E.8070904@gbenet.com> <56533622.8020408@sixdemonbag.org> <56534752.8030000@sixdemonbag.org> <56583145.7040408@digitalbrains.com> Message-ID: <5658415A.40607@andrewg.com> On 27/11/15 10:32, Peter Lebbing wrote: > On 23/11/15 21:31, James wrote: >> It appears that information I had read previously was erroneous. I was >> under the impression the capabilities (at least for the primary key) >> were set in stone, hence my apprehension at avoiding those insatiable >> knobs and gears I like to tinker with. ;) > > Well, GnuPG doesn't provide an easy means to change them; it could be > that you would need to edit the source. There's a post about how to do this in the list archives: https://lists.gnupg.org/pipermail/gnupg-users/2009-May/036505.html ... but it's really not worth your while. So long as your primary key doesn't have E usage set*, you can create new A and S subkeys and simply refrain from using the primary key for those functions. The only problem you might run into is if one of your correspondents is using broken client software that doesn't check signatures against multiple subkeys. I've no idea how likely this is though. Andrew. (*) HIGHLY unlikely unless you've done it on purpose, and in that case you're probably best advised to revoke it and start over. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From guilhem at fripost.org Fri Nov 27 12:05:36 2015 From: guilhem at fripost.org (Guilhem Moulin) Date: Fri, 27 Nov 2015 12:05:36 +0100 Subject: Why gpg 2.1.9 cannot export secret key without passphrase? In-Reply-To: <20151127123930.02d71cff@fire> References: <5653BA6F.1040002@gmail.com> <20151127123930.02d71cff@fire> Message-ID: <20151127110536.GA27339@localhost.localdomain> On Fri, 27 Nov 2015 at 12:39:30 +0300, Dmitrii Tcvetkov wrote: > In this case passphrase is needed to decrypt private key from keyring. > Becuase of passphrase is not provided gpg-agent can't give gpg the > private key. Or perhaps Andrey tries to export an *unprotected* private key using GnuPG 2.1. In that case this seems to be a known issue [0]. > Private key exports in cleartext. I think this is incorrect. gpg --export's output is always in the OpenPGP format (possibly armored), while as of 2.1 private material is stored in another format (in ~/.gnupg/private-keys-v1.d/$KEYGRIP.key). Thus the agent asks for the passphrase to decrypt the private key, and gpg reencrypts it on the fly (using the same passphrase). gpg2(1) also says: --export-secret-keys GnuPG may ask you to enter the passphrase for the key. This is required because the internal protection method of the secret key is different from the one specified by the OpenPGP protocol. Indeed ?gpg2 --export-secret-keys $KEYID | gpg --list-only --list-packets? tells me that the secret material is protected. -- Guilhem. [0] https://bugs.gnupg.org/gnupg/issue2070 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From neal at walfield.org Fri Nov 27 12:57:58 2015 From: neal at walfield.org (Neal H. Walfield) Date: Fri, 27 Nov 2015 12:57:58 +0100 Subject: gpg-agent prompt slow to show up In-Reply-To: References: Message-ID: <877fl3wt6h.wl-neal@walfield.org> Hi, At Fri, 27 Nov 2015 16:43:09 +0800, Charlie Brown wrote: > I'm new to gpg, and I'm trying the agent. > > I noticed that when gpg needs to prompt me for pass phrase, the prompt > shows up about 15 seconds after I issue the command (e.g. gpg > --decrypt or git commit -S). The problem exists with both gpg > --use-agent and gpg2. > > I then tried the --no-use-agent flag of gpg, and the cli prompt showed > up instantly, but sadly it doesn't not use the agent by its nature. > > My colleagues say that they do not have such problem. Any idea, or how > can I look into this problem? First, how did you install GnuPG? What OS / distribution are you using? What configuration options are you using (gpg-agent.conf and gpg.conf)? Thanks, Neal From peter at digitalbrains.com Fri Nov 27 13:10:11 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 27 Nov 2015 13:10:11 +0100 Subject: best practices for creating keys In-Reply-To: <5658415A.40607@andrewg.com> References: <564B3AC4.50908@andrewg.com> <564C6A2E.1050004@digitalbrains.com> <564D195E.8070904@gbenet.com> <56533622.8020408@sixdemonbag.org> <56534752.8030000@sixdemonbag.org> <56583145.7040408@digitalbrains.com> <5658415A.40607@andrewg.com> Message-ID: <56584823.2030902@digitalbrains.com> On 27/11/15 12:41, Andrew Gallagher wrote: > There's a post about how to do this in the list archives: > > https://lists.gnupg.org/pipermail/gnupg-users/2009-May/036505.html Thanks for the pointer! > ... but it's really not worth your while. So long as your primary key > doesn't have E usage set*, you can create new A and S subkeys and simply > refrain from using the primary key for those functions. I agree for the most part. I'm not so sure about how easy it is to refrain from using an A-capability. I think when an SSH server indicates it accepts a signature from my primary key, and that primary key is on a smartcard, GnuPG will try to do that. So that is in the hands of the server, not the client. Although you might be able to disable it with an sshcontrol file, I'm not sure of the exact way it all interacts. > The only problem you might run into is if one of your correspondents is > using broken client software that doesn't check signatures against > multiple subkeys. I've no idea how likely this is though. Kill that client software until dead. Then some more. 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 Felix.Seip at giepa.de Fri Nov 27 15:13:06 2015 From: Felix.Seip at giepa.de (Felix Seip) Date: Fri, 27 Nov 2015 15:13:06 +0100 Subject: WG: GnuPG 2.1: --auto-key-locate dane References: <1DC3C8C67280FB4C9A402CB6DB1358F51AB22817EB@S2008SBS.intern.giepa.de> <565780E4.2070100@dabpunkt.eu> <878u5kszcm.fsf@vigenere.g10code.de> Message-ID: <1DC3C8C67280FB4C9A402CB6DB1358F51AB2281840@S2008SBS.intern.giepa.de> -----Urspr?ngliche Nachricht----- Von: Felix Seip Gesendet: Freitag, 27. November 2015 15:13 An: 'Werner Koch' Betreff: AW: GnuPG 2.1: --auto-key-locate dane I tried this once again using the Werner Koch's key: gpg --auto-key-locate dane -v --locate-key wk at gnupg.org However, I didn't receive the answer that I was expecting. Here is what I got: gpg: using PGP trust model gpg: error retrieving 'wk at gnupg.org' via DANE: Not found gpg: error reading key: Not found I should have received a fingerprint with the corresponding key. I also tried: gpg --auto-key-locate pka -v --locate-key wk at gnupg.org The response I received was: gpg: using PGP trust model gpg: auto-key-locate found fingerprint 80615870F5BAD690333686D0F2AD85AC1E42B367 gpg: error retrieving 'wk at gnupg.org' via PKA: No public key gpg: key "wk at gnupg.org" not found: No public key Best Regards, Felix Seip From dkg at fifthhorseman.net Fri Nov 27 17:27:56 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 27 Nov 2015 11:27:56 -0500 Subject: gpg-agent prompt slow to show up In-Reply-To: References: Message-ID: <87two7tnjn.fsf@alice.fifthhorseman.net> On Fri 2015-11-27 03:43:09 -0500, Charlie Brown wrote: > I'm new to gpg, and I'm trying the agent. > > I noticed that when gpg needs to prompt me for pass phrase, the prompt > shows up about 15 seconds after I issue the command (e.g. gpg > --decrypt or git commit -S). The problem exists with both gpg > --use-agent and gpg2. > > I then tried the --no-use-agent flag of gpg, and the cli prompt showed > up instantly, but sadly it doesn't not use the agent by its nature. > > My colleagues say that they do not have such problem. Any idea, or how > can I look into this problem? > > This is the output from gpg-agent --daemon -vv: > <-- Issue a command that will prompt for pass phrase --> > gpg-agent[6458]: handler 0x7f42eb30c700 for fd 5 started > gpg-agent[6458]: starting a new PIN Entry > <-- Long annoying delay --> > <-- Then the prompt show up --> > gpg-agent[6458]: handler 0x7f42ebb0d700 for fd 8 started > gpg-agent[6458]: socket is still served by this server > gpg-agent[6458]: handler 0x7f42ebb0d700 for fd 8 terminated I have yet to be able to replicate this myself, but i've seen other people have this problem when they're using pinentry-gtk-2 or pinentry-gnome3 and they have something wrong with their dbus setup related to localization (l10n) or accessibility (a11y). In particular, there appears to be a 25000 millisecond (25 second) timeout in some gtk frameworks while trying to look for the dbus service named "org.a11y.Bus". I think: in a proper installation, dbus would either provide a connection to this service (if installed) or immediately reject the request (if not installed) so the 25 second timeout should never take effect. But i've never been able to replicate this problem myself. On the (debian unstable) machine of my colleague where we tracked it down this much, the problem was resolved after reinstalling at-spi2-core, but it didn't return after we removed it again. Sorry to not have a clearer diagnosis, but hopefully this will help point you in the right direction. If you figure out the problem and what it's related to, i'd love to hear more details so we can avoid it happening to other people in the future. --dkg From Jonathan-Harbord at marubeni.com Fri Nov 27 17:16:52 2015 From: Jonathan-Harbord at marubeni.com (Harbord Jonathan-EURITEC) Date: Fri, 27 Nov 2015 16:16:52 +0000 Subject: Bypass PIN entry Message-ID: I am using GPG on windows. Is there a way to pass the user PIN of a smartcard in a gpg-agent batch file or script? I am using a nitrokey as a private key store for an unattended SFTP system. It simply runs a WinSCP script to pickup and send files via SFTP. Before the script runs I launch I run a batch file to invoke the gpg-agent: gpg-connect-agent.exe" /bye WinSCP is then able to use the private key on the smartcard. However, the first time I connect the pinentry program appears and requires me to enter the user PIN. Is there a way for a script to pass this PIN and unlock the nitrokey when gpg-agent launches? -------------- next part -------------- An HTML attachment was scrubbed... URL: From stieizc.33 at gmail.com Fri Nov 27 16:40:38 2015 From: stieizc.33 at gmail.com (Charlie Brown) Date: Fri, 27 Nov 2015 23:40:38 +0800 Subject: gpg-agent prompt slow to show up In-Reply-To: <877fl3wt6h.wl-neal@walfield.org> References: <877fl3wt6h.wl-neal@walfield.org> Message-ID: > First, how did you install GnuPG? What OS / distribution are you > using? What configuration options are you using (gpg-agent.conf and > gpg.conf)? Sorry for the lack of information. I'm on Debian unstable, and installed GnuPG using apt-get. --------------gpg.conf------------- no-greeting keyserver hkp://keys.gnupg.net use-agent ----------gpg-agent.conf-------- default-cache-ttl 7200 --------------------------------------- And (again) the version of gpg components: gpg-agent 2.1.9 libgcrypt 1.6.4 gpg 1.4.19 gpg 2 2.1.9 Sincerely, ??? Wenxin Wang Department of Electronic Engineering, Tsinghua University, Beijing 100084, P. R. China (+86)18811369901 Email?wangwx12 at mails.tsinghua.edu.cn From demfloro at demfloro.ru Fri Nov 27 19:05:22 2015 From: demfloro at demfloro.ru (Dmitrii Tcvetkov) Date: Fri, 27 Nov 2015 21:05:22 +0300 Subject: Why gpg 2.1.9 cannot export secret key without passphrase? In-Reply-To: <56585359.10105@gmail.com> References: <5653BA6F.1040002@gmail.com> <20151127123930.02d71cff@fire> <56583E47.8090307@digitalbrains.com> <56585359.10105@gmail.com> Message-ID: <20151127210522.14489ab5@fire> On Fri, 27 Nov 2015 12:05:36 +0100 Guilhem Moulin wrote: >I think this is incorrect. gpg --export's output is always in the >OpenPGP format (possibly armored), while as of 2.1 private material is >stored in another format (in ~/.gnupg/private-keys-v1.d/$KEYGRIP.key). >Thus the agent asks for the passphrase to decrypt the private key, and >gpg reencrypts it on the fly (using the same passphrase). Yes, I confused it with OpenSSH key output, sorry. On Fri, 27 Nov 2015 14:58:01 +0200 Andrey Utkin wrote: > P. S. I haven't received 2 of 3 replies to my gmail mailbox, had to go > to maillist archive to review the thread. Have this happened to > anybody else, is this a known issue? > I'm sorry, reason is I replied only to mailing list without sending message directly to your address. From andrey.od.utkin at gmail.com Fri Nov 27 13:58:01 2015 From: andrey.od.utkin at gmail.com (Andrey Utkin) Date: Fri, 27 Nov 2015 14:58:01 +0200 Subject: Why gpg 2.1.9 cannot export secret key without passphrase? In-Reply-To: <56583E47.8090307@digitalbrains.com> References: <5653BA6F.1040002@gmail.com> <20151127123930.02d71cff@fire> <56583E47.8090307@digitalbrains.com> Message-ID: <56585359.10105@gmail.com> Thanks to everybody for caring about my issue, and for showing that I'm not alone with it. So this already has been reported in https://bugs.gnupg.org/gnupg/issue2070 and has been discussed in https://lists.gnupg.org/pipermail/gnupg-devel/2014-October/028919.html. So it just needs to be patched. Does anybody knows what works well if I am ready to donate (not a ton) and want to have it done soon? P. S. I haven't received 2 of 3 replies to my gmail mailbox, had to go to maillist archive to review the thread. Have this happened to anybody else, is this a known issue? -- OpenPGP usage is appreciated (it also helps your letter to bypass spam filters). To email me with encryption easily, go https://encrypt.to/0xC6FCDB11 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From stieizc.33 at gmail.com Sat Nov 28 04:33:34 2015 From: stieizc.33 at gmail.com (Charlie Brown) Date: Sat, 28 Nov 2015 11:33:34 +0800 Subject: gpg-agent prompt slow to show up In-Reply-To: <87two7tnjn.fsf@alice.fifthhorseman.net> References: <87two7tnjn.fsf@alice.fifthhorseman.net> Message-ID: > I have yet to be able to replicate this myself, but i've seen other > people have this problem when they're using pinentry-gtk-2 or > pinentry-gnome3 and they have something wrong with their dbus setup > related to localization (l10n) or accessibility (a11y). > > In particular, there appears to be a 25000 millisecond (25 second) > timeout in some gtk frameworks while trying to look for the dbus service > named "org.a11y.Bus". Thank you for pointing to dbus, that is a good place to find out what happens. And you are right, I'm using pinentry-gnome3 and there's a 25 second gap between ------------ method call time=1448678135.935348 sender=:1.30 -> destination=org.a11y.Bus serial=2 path=/org/a11y/bus; interface=org.a11y.Bus; member=GetAddress method call time=1448678160.965303 sender=:1.31 -> destination=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Hello ------------- And for me, there's *another* 25 second gap between ------------- signal time=1448678160.983489 sender=org.freedesktop.DBus -> destination=(null destination) serial=101 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string ":1.32" string ":1.32" string "" signal time=1448678185.987561 sender=org.freedesktop.DBus -> destination=:1.31 serial=6 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameLost string ":1.31" ------------- So it's not 15 seconds, it's 50 seconds in all. I wish I had timed this. If anyone is interested, the output from `dbus-monitor` between a gpg command was triggered and the passphrase prompt showed up is attached as `dbus-gpg.log`. > On the (debian unstable) machine of my colleague where we tracked it > down this much, the problem was resolved after reinstalling > at-spi2-core, but it didn't return after we removed it again. I removed at-spi2-core and save 25 seconds. But that's not a perfect solution. Then I look deeper into the gnome-keyring bug. I removed ssh, pkcs11 and secret autostart for gnome-keyring in /etc/xdg/autostart (the gnome-keyring-daemon still get launched by pam), and found that in the first time the prompt showed up quickly (and the dbus log is attached as `dbus-gpg-1.log`, that one still has the a11y problem), but following ones have the same problem. I'm not familiar with dbus, but comparing the two logs, it appears to me that gnome-keyring is setting 'org.gnome.keyring' to empty string. If anyone have seen the same problem, please help me. It seems that none of these two bugs is related to GnuPG. I will send emails to a11y and gnome-keyring and see if they have any idea. Thanks for your help! Sincerely, ??? Wenxin Wang -------------- next part -------------- method call time=1448678135.934762 sender=:1.30 -> destination=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Hello method return time=1448678135.934793 sender=org.freedesktop.DBus -> destination=:1.30 serial=1 reply_serial=1 string ":1.30" signal time=1448678135.934808 sender=org.freedesktop.DBus -> destination=(null destination) serial=98 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string ":1.30" string "" string ":1.30" signal time=1448678135.934826 sender=org.freedesktop.DBus -> destination=:1.30 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired string ":1.30" method call time=1448678135.935348 sender=:1.30 -> destination=org.a11y.Bus serial=2 path=/org/a11y/bus; interface=org.a11y.Bus; member=GetAddress method call time=1448678160.965303 sender=:1.31 -> destination=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Hello method return time=1448678160.965342 sender=org.freedesktop.DBus -> destination=:1.31 serial=1 reply_serial=1 string ":1.31" signal time=1448678160.965365 sender=org.freedesktop.DBus -> destination=(null destination) serial=99 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string ":1.31" string "" string ":1.31" signal time=1448678160.965392 sender=org.freedesktop.DBus -> destination=:1.31 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired string ":1.31" method call time=1448678160.968097 sender=:1.31 -> destination=org.freedesktop.DBus serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch string "type='signal',sender='org.freedesktop.secrets',interface='org.freedesktop.DBus.Properties',member='PropertiesChanged',path='/org/freedesktop/secrets',arg0='org.freedesktop.Secret.Service'" method return time=1448678160.968151 sender=org.freedesktop.DBus -> destination=:1.31 serial=3 reply_serial=2 method call time=1448678160.968170 sender=:1.31 -> destination=org.freedesktop.DBus serial=3 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch string "type='signal',sender='org.freedesktop.secrets',interface='org.freedesktop.Secret.Service',path='/org/freedesktop/secrets'" method return time=1448678160.968194 sender=org.freedesktop.DBus -> destination=:1.31 serial=4 reply_serial=3 method call time=1448678160.968210 sender=:1.31 -> destination=org.freedesktop.DBus serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',path='/org/freedesktop/DBus',arg0='org.freedesktop.secrets'" method return time=1448678160.968233 sender=org.freedesktop.DBus -> destination=:1.31 serial=5 reply_serial=4 method call time=1448678160.968252 sender=:1.31 -> destination=org.freedesktop.DBus serial=5 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=StartServiceByName string "org.freedesktop.secrets" uint32 0 method call time=1448678160.979902 sender=:1.32 -> destination=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Hello method return time=1448678160.980018 sender=org.freedesktop.DBus -> destination=:1.32 serial=1 reply_serial=1 string ":1.32" signal time=1448678160.980291 sender=org.freedesktop.DBus -> destination=(null destination) serial=100 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string ":1.32" string "" string ":1.32" signal time=1448678160.980475 sender=org.freedesktop.DBus -> destination=:1.32 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired string ":1.32" method call time=1448678160.981071 sender=:1.32 -> destination=org.freedesktop.DBus serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',path='/org/freedesktop/DBus',arg0='org.gnome.keyring'" method return time=1448678160.981257 sender=org.freedesktop.DBus -> destination=:1.32 serial=3 reply_serial=2 method call time=1448678160.981497 sender=:1.32 -> destination=org.freedesktop.DBus serial=3 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=GetNameOwner string "org.gnome.keyring" error time=1448678160.981662 sender=org.freedesktop.DBus -> destination=:1.32 error_name=org.freedesktop.DBus.Error.NameHasNoOwner reply_serial=3 string "Could not get owner of name 'org.gnome.keyring': no such name" signal time=1448678160.983432 sender=org.freedesktop.DBus -> destination=:1.32 serial=5 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameLost string ":1.32" signal time=1448678160.983489 sender=org.freedesktop.DBus -> destination=(null destination) serial=101 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string ":1.32" string ":1.32" string "" signal time=1448678185.987561 sender=org.freedesktop.DBus -> destination=:1.31 serial=6 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameLost string ":1.31" signal time=1448678185.987623 sender=org.freedesktop.DBus -> destination=(null destination) serial=102 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string ":1.31" string ":1.31" string "" method call time=1448678185.989570 sender=:1.33 -> destination=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Hello method return time=1448678185.989608 sender=org.freedesktop.DBus -> destination=:1.33 serial=1 reply_serial=1 string ":1.33" signal time=1448678185.989634 sender=org.freedesktop.DBus -> destination=(null destination) serial=103 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string ":1.33" string "" string ":1.33" signal time=1448678185.989668 sender=org.freedesktop.DBus -> destination=:1.33 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired string ":1.33" method call time=1448678185.990746 sender=:1.33 -> destination=org.freedesktop.DBus serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',path='/org/freedesktop/DBus',arg0='org.gnome.keyring.SystemPrompter'" method return time=1448678185.990794 sender=org.freedesktop.DBus -> destination=:1.33 serial=3 reply_serial=2 method call time=1448678185.990811 sender=:1.33 -> destination=org.freedesktop.DBus serial=3 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=GetNameOwner string "org.gnome.keyring.SystemPrompter" error time=1448678185.990834 sender=org.freedesktop.DBus -> destination=:1.33 error_name=org.freedesktop.DBus.Error.NameHasNoOwner reply_serial=3 string "Could not get owner of name 'org.gnome.keyring.SystemPrompter': no such name" method call time=1448678185.991727 sender=:1.33 -> destination=org.gnome.keyring.SystemPrompter serial=4 path=/org/gnome/keyring/Prompter; interface=org.gnome.keyring.internal.Prompter; member=BeginPrompting object path "/org/gnome/keyring/Prompt/p0" method call time=1448678186.036967 sender=:1.34 -> destination=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Hello method return time=1448678186.037002 sender=org.freedesktop.DBus -> destination=:1.34 serial=1 reply_serial=1 string ":1.34" signal time=1448678186.037024 sender=org.freedesktop.DBus -> destination=(null destination) serial=104 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string ":1.34" string "" string ":1.34" signal time=1448678186.037049 sender=org.freedesktop.DBus -> destination=:1.34 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired string ":1.34" method call time=1448678186.039034 sender=:1.34 -> destination=org.freedesktop.DBus serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RequestName string "org.gnome.keyring.SystemPrompter" uint32 2 signal time=1448678186.039072 sender=org.freedesktop.DBus -> destination=(null destination) serial=5 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string "org.gnome.keyring.SystemPrompter" string "" string ":1.34" signal time=1448678186.039094 sender=org.freedesktop.DBus -> destination=:1.34 serial=3 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired string "org.gnome.keyring.SystemPrompter" method return time=1448678186.039109 sender=org.freedesktop.DBus -> destination=:1.34 serial=4 reply_serial=2 uint32 1 method call time=1448678186.039787 sender=:1.34 -> destination=org.freedesktop.DBus serial=3 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RequestName string "org.gnome.keyring.PrivatePrompter" uint32 2 signal time=1448678186.039820 sender=org.freedesktop.DBus -> destination=(null destination) serial=105 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string "org.gnome.keyring.PrivatePrompter" string "" string ":1.34" signal time=1448678186.039842 sender=org.freedesktop.DBus -> destination=:1.34 serial=5 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired string "org.gnome.keyring.PrivatePrompter" method return time=1448678186.039856 sender=org.freedesktop.DBus -> destination=:1.34 serial=6 reply_serial=3 uint32 1 method call time=1448678186.042777 sender=:1.34 -> destination=org.freedesktop.DBus serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',path='/org/freedesktop/DBus',arg0=':1.33'" method return time=1448678186.042812 sender=org.freedesktop.DBus -> destination=:1.34 serial=7 reply_serial=4 method call time=1448678186.042823 sender=:1.34 -> destination=org.freedesktop.DBus serial=5 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=GetNameOwner string ":1.33" method return time=1448678186.042838 sender=org.freedesktop.DBus -> destination=:1.34 serial=8 reply_serial=5 string ":1.33" method return time=1448678186.042849 sender=:1.34 -> destination=:1.33 serial=6 reply_serial=4 method call time=1448678186.146370 sender=:1.34 -> destination=:1.33 serial=7 path=/org/gnome/keyring/Prompt/p0; interface=org.gnome.keyring.internal.Prompter.Callback; member=PromptReady string "" array [ ] string "[sx-aes-1] public=IcgJc2BRt0Li6WPTkkIarcv4DDICq7LvUdGdk7TH3gVm7YRoVxSPzud2lvvUURQYT7XXaaKk/rpWmxuMn7rg6Okn+KSHmvMDjVRrNIUDKiG/hlgk/Asno5o8c0mtN+pB6BiP3VnttC7WhE14PofLuCKdEmohu/bOG0p98QatTnM1tE8ssdiCrPlO0OPRpyADFmya2H8FJ33r+uMdfipTW1ufLoZlMGEDkIi7+cIv6yV4B0lsRgzLqQ2sELRCgsmp " method return time=1448678186.147439 sender=:1.33 -> destination=:1.34 serial=5 reply_serial=7 method call time=1448678186.160833 sender=:1.33 -> destination=org.freedesktop.DBus serial=6 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RemoveMatch string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',path='/org/freedesktop/DBus',arg0='org.gnome.keyring.SystemPrompter'" method return time=1448678186.160852 sender=org.freedesktop.DBus -> destination=:1.33 serial=6 reply_serial=6 method call time=1448678186.161014 sender=:1.33 -> destination=org.freedesktop.DBus serial=7 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',path='/org/freedesktop/DBus',arg0='org.gnome.keyring.SystemPrompter'" method return time=1448678186.161026 sender=org.freedesktop.DBus -> destination=:1.33 serial=7 reply_serial=7 method call time=1448678186.161245 sender=:1.33 -> destination=org.freedesktop.DBus serial=8 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=GetNameOwner string "org.gnome.keyring.SystemPrompter" method return time=1448678186.161257 sender=org.freedesktop.DBus -> destination=:1.33 serial=8 reply_serial=8 string ":1.34" method call time=1448678186.161264 sender=:1.33 -> destination=org.gnome.keyring.SystemPrompter serial=9 path=/org/gnome/keyring/Prompter; interface=org.gnome.keyring.internal.Prompter; member=PerformPrompt object path "/org/gnome/keyring/Prompt/p0" string "password" array [ dict entry( string "caller-window" variant string "" ) dict entry( string "cancel-label" variant string "_Cancel" ) dict entry( string "message" variant string "Passphrase:" ) dict entry( string "title" variant string "" ) dict entry( string "choice-label" variant string "_Save in password manager" ) dict entry( string "warning" variant string "" ) dict entry( string "description" variant string "You need a passphrase to unlock the secret key for user: "Wenxin Wang (Charlie Brown) " 4096-bit RSA key, ID DF86FCC1, created 2015-11-24 (main key ID 76D23BD4) " ) dict entry( string "continue-label" variant string "_OK" ) dict entry( string "password-new" variant boolean false ) ] string "[sx-aes-1] public=59nhv7KQ4x6Wz6F/t5mbMLVGh9hyRi4JYpAiCn0JK2iwKOxCnKrIrPOx5tmAc20reOI20029laWTaDYGNZF/yvgqnZCbgqQnjovdjLCkJPsqhVBqdKXqeWFCNtpt/MaCGvmGy8VVww09waPzCSJyuhnJAi1TrP4VTFY6gEAqyNrvxZorfSYswbOGQiTN7QJ0bS/FNwFglGNkIlOrVwEAoY5uU9beCNzgW1q5xkHxucMJLGLKQT4zoE9wITK3t3bf " method return time=1448678186.202715 sender=:1.34 -> destination=:1.33 serial=8 reply_serial=9 From andrey.od.utkin at gmail.com Fri Nov 27 22:55:18 2015 From: andrey.od.utkin at gmail.com (Andrey Utkin) Date: Fri, 27 Nov 2015 23:55:18 +0200 Subject: [RFC] Keychain for GPG, SSH, X.509 etc. (inspired by Split GPG) Message-ID: <5658D146.2070403@gmail.com> TL;DR: Generalization of "Split GPG" concept. Any comments? Anybody likes the idea? Ready to join development or early adoption? What is this: Concept of flexible solution for usage of private keys without disclosing them. Key usage is always confirmed by user (as a form of AnyNumber-factor auth). What is planned to guard: OpenPGP keys, SSH keys, X.509 client certificates. Inspiration: Split GPG (https://www.qubes-os.org/doc/split-gpg/), PGP-smartcards, SSH-smartcards. Implementation form: portable libraries/toolkit. Elements: - keychain server (KS): the process which is accessible via specified protocols and has access to the unprotected keys, so that it can use them: --- encrypt/decrypt/sign; --- create challenge responses; - keychain key usage client (KUC): the process which makes requests for key usage; - keychain confirmation server (KCS): the process conveying User's decision (approval or rejection) to each key usage request; The following elements must run in trusted environment (including trusted physical security system, trusted hypervisor, trusted machine OS); - keychain server; - keychain confirmation server. Keychain key usage client can work in entirely hostile environment. Keychain usage client (KUC) may be entirely spoofed by attacker, no data from KUC is trusted and it must be verified by User. The above restriction is not a show-stopper ("oh, too much restricted scheme - how to get such trusted environments?"). It is an improvement comparing to default scheme, which supposes secret keys exposition in same hostile environment. The point is in decoupling these three essential entities of key material, key usage agent (gpg-agent, ssh-agent) and key control (usually underdeveloped in mainstream systems - you just MAY get asked to enter passphrase if you use it). This scheme is an improvement comparing to hardware smartcard usage because it brings flexiblility and fine-grained control to key usage confirmation procedure. Q: How confirmation happens? A: This function is outsourced to plugin system. Different systems would find different ways as most fit. Used/allowed plugins configuration is set up in keychain server. It possibly will look similar to Linux PAM. Q: How to have keychain server data encrypted? A: As long as KS must actually use the keys in their unencrypted form, it is required that safety of KS is trusted. If we cannot assume KS environment trusted, then keys are compromised as soon as they get loaded in unencrypted form. See http://blog.invisiblethings.org/keys/ "I proudly use empty passphrases on all of my private keys...". Encryption of KS data is out of scope of this scheme, but it may be implemented as the adopter decides, as additional safety measure. Q: How to ensure unspoofability of confirmation dialog? A: Confirmation app must run in trusted environment, so this is not needed. If environment is not trusted, the unspoofability of confirmation dialog is only one of countless unresonvable security issues. Q: Which protocols are used to convey key usage dialogs and confirmation dialogs? A: The ones that can be considered handy and trusted in specific case. The following ones are offered for adopters consideration: - SSH; - other end-to-end (KUC-KS, KS-KCS, KUC-KCS) encrypted connections: --- XMPP via TLS chat with PGP or OTR encryption; --- HTTPS online session with realtime notifications; --- encrypted VoIP or VVoIP call communication (smart audio synthesis/recognition software are probably required); --- confirmation HTTPS link in encrypted email; - NFC (near-field communication protocol, hardware) - NFC crypto chip prepares signature which shows approval to KS; - (bad, use as fallback) SMS, PSTN call; It should be stated that KC may want to gather more than one approval, by more than one communication channel (thus we have multi-factor authorization). Or system may query several confirmation channels in parallel or serial fashion. Examples of viable platforms for trusted elements (KC, KCS), review of potential risks: - Android device: so-so to bad (depending on whether the system is fully dedicated, and on system configuration): --- risk for KC: vendor-provided OS system services tend to spy on user; --- risk for KC: normally every app has its kernel-guarded storage, but processes with system privilegee (gained by exploit or by user permission) may access this data; --- risk for KCS: potential spoofing of KCS app dialogs; - Remote sever: bad to so-so to good (depending on whether VPS or owned and guarded physical machine): --- risk for any component: remote attack (TODO elaborate, review more in-depth); - Pluggable micro-PC with dedicated system (like http://inversepath.com/usbarmory.html): potentially good, but there's lack of interactive peripheral for dialog, a gadget like androids without bloatware would be nice. - Virtual machines: good, but must be used properly - untrusted env mustn't be supervising trusted env. - Different UNIX system accounts from untrusted component: bad, trusted elements are owned on privilege escalating exploitation. - LXC: same as with UNIX accounts (kernel exploit owns everything)? Example elements layouts: - keychain server (KC) and confirmation server (KCS) on Android device, keychain usage client (KUC) on a workstation: simple, affordable, bad security; - keycnain server (KC) on remote server, usage client (KUC) on a workstation, confirmation client (KCS) on another, trusted workstation: pretty good, if remote server is safe; Further expansion of this scheme: - X.509 client cert auth challenge forwarding (using browser plugin); - HTTP DIGEST auth challenges forwarding from KUC (using browser plugin) to KS; - forwarding requests for file access, i.e. implementation of filesystem in userspace, with manual access control on sensitive data exposed to untrusted environment. -- OpenPGP usage is appreciated (it also helps your letter to bypass spam filters). To email me with encryption easily, go https://encrypt.to/0xC6FCDB11 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Sat Nov 28 16:36:11 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 28 Nov 2015 16:36:11 +0100 Subject: [RFC] Keychain for GPG, SSH, X.509 etc. (inspired by Split GPG) In-Reply-To: <5658D146.2070403@gmail.com> References: <5658D146.2070403@gmail.com> Message-ID: <5659C9EB.8080605@digitalbrains.com> On 27/11/15 22:55, Andrey Utkin wrote: > Any comments? Could you outline a sequence of steps that goes wrong without your solution and right with it? Like: - SSH to compromised PC - Use SSH agent forwarding - While logged in to compromised PC, SSH from there to another Wrong: - Compromised PC opens whole host of SSH connections purporting to be you Right: - Keychain confirmation server comes in guns blazing, data center containing compromised server turns into mushroom cloud - Mushroom clouds don't impersonate sysadmins I'd like to see a detailed usage scenario. Preferably with mushroom clouds. 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 mls at dabpunkt.eu Sun Nov 29 12:57:45 2015 From: mls at dabpunkt.eu (Daniel Baur) Date: Sun, 29 Nov 2015 12:57:45 +0100 Subject: GnuPG 2.1: --auto-key-locate dane In-Reply-To: <878u5kszcm.fsf@vigenere.g10code.de> References: <1DC3C8C67280FB4C9A402CB6DB1358F51AB22817EB@S2008SBS.intern.giepa.de> <565780E4.2070100@dabpunkt.eu> <878u5kszcm.fsf@vigenere.g10code.de> Message-ID: <565AE839.709@dabpunkt.eu> Hallo, Am 27.11.2015 um 07:58 schrieb Werner Koch: >> The OpenPGPKey-DNS-entry for my mail-adress works, if you like to test gpg. > Not for me: sorry, this is a misunderstanding. I meant: My entry is correct in the DNS, while Felix? is not. I have no such recent version of gpg to test if it is working there. Sincerely, DaB. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 880 bytes Desc: OpenPGP digital signature URL: From felix.klee at inka.de Sun Nov 29 14:36:11 2015 From: felix.klee at inka.de (Felix E. Klee) Date: Sun, 29 Nov 2015 14:36:11 +0100 Subject: =?UTF-8?Q?Re=3A_Generating_4096_bit_key_fails_=E2=80=93_why=3F?= In-Reply-To: <8737w4h867.fsf@vigenere.g10code.de> References: <87oafk9iqh.fsf@vigenere.g10code.de> <5636C4B3.5050905@fsij.org> <563968E9.6050604@fsij.org> <8737w4h867.fsf@vigenere.g10code.de> Message-ID: On Tue, Nov 17, 2015 at 6:01 PM, Werner Koch wrote: > We now plan for some time in the next week. Seems like that didn't happen. I'm without a working crypto card since August. :-( From perillamint at gentoo.moe Sat Nov 28 23:47:41 2015 From: perillamint at gentoo.moe (perillamint) Date: Sun, 29 Nov 2015 07:47:41 +0900 Subject: [PATCH] Fix bug in GnuK PIN pad support. Message-ID: <565A2F0D.1060106@gentoo.moe> Hello. I found a bug (maybe a typo?) while playing with GnuK PIN pad support. In openpgp.c L1410, it fills with bConfirmPIN with apdu.cmd_apdu_data[5]. It does not work when I gave it bPinSupport = 3 - which allows PIN modification via PIN pad. While I searching for solution, I found usb-icc.c mentions bConfirmPIN is located in cmd_apdu_data[0]. I fixed openpgp.c to use [0] and it seems to work well. I attached patch for this. Thanks. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-offset-of-bConfirmPIN.patch Type: text/x-patch Size: 740 bytes Desc: not available URL: From mailinglist at krebs.uno Mon Nov 30 00:04:58 2015 From: mailinglist at krebs.uno (Daniel Krebs) Date: Mon, 30 Nov 2015 00:04:58 +0100 Subject: How important are Admin PIN and Passphrase in this scenario? Message-ID: <565B849A.7040403@krebs.uno> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, I'm thinking about the following scenario: There is a smartcard with subkeys for encryption, signing and authentication. The secret primary key is stored encrypted (eg. a truecrypt container) and only used on an airgapped, offline machine when signing other peoples keys or changing the expiration date of the subkeys. Assuming the truecrypt container uses a really strong password (so bruteforcing is not an option), is there a need for a strong admin PIN and a strong passphrase? I'm thinking about a threat model for this and the attacker's options (BIOS/UEFI backdoor or someone just 'looking over your shoulder'). In any case there seems to be no really benefit of using extraordinary strong admin pin because there are only three tries before the card get rendered unusable. The passphrase is only used in the secure environment. So if the attacker can find out the truecrypt password he probably can capture the passphrase and/or admin PIN too. Am I missing something? dk -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJWW4SMAAoJEA7irlPqaBCOLcQP/izvG02yXN7F/zrnLq2QxbuJ 8+tcahDR/ixxt23T6GhZlpG8M0ztGi5HYtloYvzU3Xp+sGpULsJeif3eFfZ7qpT+ eNVmh0hSUs2tI14pvziuCUzr2c8c6svm55TPMMfIuupD7OyZc0Xwz+8xN5UrXz8X JtSztX9f3yesYUEAnimL072eKWetyjUVayhzVF0ZKw7DGxQZGErC+yKIHc/J1eWB SdSWO7SZpMQpXKd/u2EFkvpN+w8wm8Kbwh+CBPJqIHezqRZTEaoDh5S2H3a17UWT BxFQllL6U9/o0twXZUOt/D+FTsknj7XjMnpbXMwwTjkymvItNbmcTHmhz6kArpzS +Dvw6Nd5o+gC8RQdabGvOHl4OLJGJEQPZh3rON0yVuzZtqL/7fMjjZqSe0Nh+DV9 fKe00PQ/YUcUiDqyabBhJaKZeGDxfJFsqU3MOcX4qoKZaCSfRqaZnWKHuOhfunfk n6c3MqFgXVIRY7r2hX0VZpEdQNV0+UaofnbsG7hg/+tnAIV8r/tvld68jpeh+i4d 73J5LLrQejPMsoBEdA1MjD7eycMyyolWEzxr+OfU5COFM69HNAdrkd2zBChFcVmm pF/bBngmXAzpnfRTgwIW3glvrBuyYJxX0fehZqXcOuvFjMANvV+Zesmva+k8pPry WM+JoPPVDf5cV80UEg43 =IIug -----END PGP SIGNATURE----- From gniibe at fsij.org Mon Nov 30 05:41:29 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 30 Nov 2015 13:41:29 +0900 Subject: [Gnuk-users] [PATCH] Fix bug in GnuK PIN pad support. In-Reply-To: <565A2F0D.1060106@gentoo.moe> References: <565A2F0D.1060106@gentoo.moe> Message-ID: <565BD379.1060106@fsij.org> On 11/29/2015 07:47 AM, perillamint wrote: > erillamint > Date: Sun, 29 Nov 2015 07:32:17 +0900 > Subject: [PATCH] Fix offset of bConfirmPIN. Thank you. Applied. -- From andrey.od.utkin at gmail.com Mon Nov 30 20:10:07 2015 From: andrey.od.utkin at gmail.com (Andrey Utkin) Date: Mon, 30 Nov 2015 21:10:07 +0200 Subject: Why gpg 2.1.9 cannot export secret key without passphrase? In-Reply-To: <56583E47.8090307@digitalbrains.com> References: <5653BA6F.1040002@gmail.com> <20151127123930.02d71cff@fire> <56583E47.8090307@digitalbrains.com> Message-ID: <565C9F0F.9000806@gmail.com> On 27.11.2015 13:28, Peter Lebbing wrote: > I think it makes sense to be able to store a private key without a passphrase in > a safe place (as in: an actual safe), so you don't run the risk that you forgot > the passphrase. Currently, this is not possible Is it impossible straight from RFC 4880 in any defined mode, or is it just a wrong behaviour in GnuPG/Libgcrypt? Empty passphrases are banned in several places in this software: gnupg: agent/protect.c: 1218 (hash_passphrase()) http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=agent/protect.c;h=cdb39fd1310dd539b3fa88f55e117a9aeecdb1e9;hb=refs/heads/master#l1218 libgcrypt: cipher/kdf.c: 245 (_gcry_kdf_derive()) http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=blob;f=cipher/kdf.c;h=ad5c46efdce696896f60521f8fe856ea102e6950;hb=refs/heads/master#l245 I haven't learned the RFC yet, so any quick tips are very appreciated. From peter at digitalbrains.com Mon Nov 30 20:53:29 2015 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 30 Nov 2015 20:53:29 +0100 Subject: Why gpg 2.1.9 cannot export secret key without passphrase? In-Reply-To: <565C9F0F.9000806@gmail.com> References: <5653BA6F.1040002@gmail.com> <20151127123930.02d71cff@fire> <56583E47.8090307@digitalbrains.com> <565C9F0F.9000806@gmail.com> Message-ID: <565CA939.8020308@digitalbrains.com> On 30/11/15 20:10, Andrey Utkin wrote: > Is it impossible straight from RFC 4880 in any defined mode, or is > it just a wrong behaviour in GnuPG/Libgcrypt? It is a specific bug of GnuPG 2.1, and Werner's comment on the bug entry mentioned here makes me believe he intends to fix it eventually. GnuPG 1.4 and 2.0 can export keys without passphrases, and this is fully defined in RFC 4880. > Empty passphrases are banned in several places in this software: Yes; that's because there is a difference between not encrypting stuff and encrypting it with an empty passphrase :). The latter is just silly. The only purpose of doing that is to be able to tell your client that you "encrypted it" without technically lying. And I'm not making stuff up. This actually happens (I'm looking at you, DropBox!). When a private key is stored without a passphrase, it is stored without encryption. The actual packet looks different: it clearly indicates that what follows is plaintext. If you were to encrypt it with an empty passphrase, it would actually be encrypted, but with a key that corresponds to an empty passphrase and hence would be trivially cracked by anyone. 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 rmb.hoffman at gmail.com Mon Nov 30 17:28:52 2015 From: rmb.hoffman at gmail.com (Ryan Hoffman) Date: Mon, 30 Nov 2015 08:28:52 -0800 Subject: problems decrypting ASCII-armored file Message-ID: Hello, I encrypted a file (on Mac OSX) some time ago using: > gpg -ca filename And then uploaded the outputted file to Google Docs. Some time later I downloaded the file, and I can't even get gpg to sink its teeth in: > gpg filename gpg: no valid OpenPGP data found. gpg: processing message failed: eof I'm using the following version to decrypt: > gpg --version gpg (GnuPG) 1.4.16 Copyright (C) 2013 Free Software Foundation, Inc. Here's the file's header as viewed with "less" (the starting non-printing character is suspicious): -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.1 (Darwin) jA0EAwMCLguhB+jNpUJgye3pjG0GqOKYEV/k0xsrH1Ui+qfJd4+BQzJmoo9T+dO+ KIuPgjIgAjpIuG/Eq+za/pXROVsruw+Iw9KsJ55GhfHuFBOJnWGjeNSNn0ExO+TA And here's how the file end: fFP/Cdd8aYkpBFtuvDu9dlT9sAGbm4SfcJjjSrgBlco7LQVhKXAxzaIvit+FNg8l e9Il0fX6NVBy3hE= =LF2x -----END PGP MESSAGE----- Any suggestions? Thanks, Ryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrey.od.utkin at gmail.com Mon Nov 30 23:20:46 2015 From: andrey.od.utkin at gmail.com (Andrey Utkin) Date: Tue, 1 Dec 2015 00:20:46 +0200 Subject: [RFC] Keychain for GPG, SSH, X.509 etc. (inspired by Split GPG) In-Reply-To: <5659C9EB.8080605@digitalbrains.com> References: <5658D146.2070403@gmail.com> <5659C9EB.8080605@digitalbrains.com> Message-ID: <565CCBBE.4030207@gmail.com> On 28.11.2015 17:36, Peter Lebbing wrote: > On 27/11/15 22:55, Andrey Utkin wrote: >> Any comments? > > Could you outline a sequence of steps that goes wrong without your > solution and right with it? > > Like: > > - SSH to compromised PC > - Use SSH agent forwarding > - While logged in to compromised PC, SSH from there to another > > Wrong: > - Compromised PC opens whole host of SSH connections purporting to be you > > Right: > - Keychain confirmation server comes in guns blazing, data center > containing compromised server turns into mushroom cloud > - Mushroom clouds don't impersonate sysadmins > > I'd like to see a detailed usage scenario. Preferably with mushroom clouds. > > Peter. > Thanks for your interest. Your joke describes one of usage scenarios quite well :) Let me describe how exactly this is supposed to work when key must be used. The whole process still looks similar to smartcard key usage, especially regarding user's action to enable key access operation (PIN entry). So it is easier to start with looking at using smartcard. Note: I have no practical experience with actual OpenPGP smartcards and I'm not convinced with their usability enough to spend couple of hundreds of bucks or more (with shipping cost) to try them. As far as I see there is a common problem with reviewing what exactly is being encrypted/signed. I was told on another forum that this issue is solved by pinpads with displays, like this one (sorry for russian): http://www.rutoken.ru/products/all/rutoken-pinpad/ , but this is what I otherwise see for "pgp smartcard pinpad": https://www.google.com/search?q=pgp+smartcard+pinpad&tbm=isch Why not to make such review and confirmation operation fully software-defined, overcoming limitations of hardware appliances? This idea is even more appealing when you consider the accessibility of both VPSs and handheld devices with great displays? VPS or handhelds are attackable, but their availability allows user to set up one dedicated to keys operation, keeping attack surface of key vault minimal. This is what is wrong with the case of smartcards in my opinion. In a word: - costs money ( -> won't be chosen by a lot of people despite the rise of interest to privacy); - costs even more money and/or time to get it in far countries (good stuff is not quite available locally, or is, but for very high price); - key length limitations on certain hardware solutions (can't say for all, but I guess that 's true for majority of available hardware); - hard to use large set of keys. Let's also look at the case when we use local keys just on a local machine (as I do now, being unwilling to go with smartcards). Consider the case that user has just one full-blown workstation at hand, and needs to use untrustworthy software like browsers and closed-source apps. The workstation is not powerful enough to jail all untrusted applications to virtual machines like Qubes OS project proposes. (Even if it is powerful enough, Qubes OS is far from being production-ready, and manual AppVM handling without Qubes is pain.) In this case, what is primarily important is to store keys (and, well, all sensitive data) anywhere but locally. This looks like the situation with SSH agent forwarding to untrusted host (regarding that we don't want to store keys on it), but with the difference that we _start_ on an untrusted machine and we are not ssh-ed to it from anywhere. So even without confirmation control, remoting the keys operation is beneficial. And if we add user confirmation interface, then we eliminate the risk of what you have described as "Compromised PC opens whole host of SSH connections purporting to be you". The confirmation interface can be implemented in any convenient way. E.g. the confirmation dialog may be raised on a network-enabled smartphone; keys may be stored on smartphone or on a remote server. So, my speculations make me think that I want to implement what I have described in original posting, and that I would want it the same way even if I used smartcards daily. I am sorry if all my long posts don't explain a lot to you or don't make a lot of sense. I raised the discussion here in hope to gather opinions or get directed towards ready-to-use solutions not known to me before. Now I see that it probably makes sense to try to implement this schema in a limited scope, see how it goes, describe it comprehensively (with mushroom clouds, as requested) and present it here for review. Thanks. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Mon Nov 30 23:41:33 2015 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 30 Nov 2015 22:41:33 +0000 Subject: problems decrypting ASCII-armored file In-Reply-To: References: Message-ID: > > Here's the file's header as viewed with "less" (the starting non-printing character is suspicious): > -----BEGIN PGP MESSAGE----- That's a Unicode byte order mark. Strictly, it should only be used in UTF-16 documents but in the real world it's commonly used to mark any Unicode file. I'm assuming this is a UTF-8 file? If so, you should just be able to delete the character using vim or similar and try again. Andrew. From andrey.od.utkin at gmail.com Mon Nov 30 23:54:06 2015 From: andrey.od.utkin at gmail.com (Andrey Utkin) Date: Tue, 1 Dec 2015 00:54:06 +0200 Subject: Why gpg 2.1.9 cannot export secret key without passphrase? In-Reply-To: <565CA939.8020308@digitalbrains.com> References: <5653BA6F.1040002@gmail.com> <20151127123930.02d71cff@fire> <56583E47.8090307@digitalbrains.com> <565C9F0F.9000806@gmail.com> <565CA939.8020308@digitalbrains.com> Message-ID: <565CD38E.4060408@gmail.com> On 30.11.2015 21:53, Peter Lebbing wrote: > On 30/11/15 20:10, Andrey Utkin wrote: >> Is it impossible straight from RFC 4880 in any defined mode, or is >> it just a wrong behaviour in GnuPG/Libgcrypt? > > It is a specific bug of GnuPG 2.1, and Werner's comment on the bug entry > mentioned here makes me believe he intends to fix it eventually. > > GnuPG 1.4 and 2.0 can export keys without passphrases, and this is fully > defined in RFC 4880. Thanks for clarification. I'd be glad to help Werner to fix it if he has no time. Could you please direct me to exact S2K-stuff modes for exporting it which would be compliant with earlier GnuPG branches 1.4 and 2.0? Then I would have a chance to accomplish the fix in finite time. >> Empty passphrases are banned in several places in this software: > > Yes; that's because there is a difference between not encrypting stuff > and encrypting it with an empty passphrase :). The latter is just silly. > The only purpose of doing that is to be able to tell your client that > you "encrypted it" without technically lying. And I'm not making stuff > up. This actually happens (I'm looking at you, DropBox!). > > When a private key is stored without a passphrase, it is stored without > encryption. The actual packet looks different: it clearly indicates that > what follows is plaintext. If you were to encrypt it with an empty > passphrase, it would actually be encrypted, but with a key that > corresponds to an empty passphrase and hence would be trivially cracked > by anyone. Surely these two ways are distinguishable. But for unattended processing cases, I'd like a mode that makes utils skip all passphrase entry prompts. I guess the no-encryption case ("trivially cracked by anyone") is needed here. Which of the mentioned modes was used in 1.4 and 2.0 for exporting without passphrase? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From dasander at msn.com Mon Nov 30 23:34:11 2015 From: dasander at msn.com (Dale Sander) Date: Mon, 30 Nov 2015 15:34:11 -0700 Subject: Malware detected Message-ID: I downloaded gpupg for windows, during the installation Webroot Endpoint Protection reported that GSPAWN-WIN32-HELPER.EXE was infected with W32.Malware.Gen and was blocked.. has the source code been infected or is this some kind of false detection? Thank you, Dale -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmb.hoffman at gmail.com Mon Nov 30 23:46:38 2015 From: rmb.hoffman at gmail.com (Ryan Hoffman) Date: Mon, 30 Nov 2015 14:46:38 -0800 Subject: problems decrypting ASCII-armored file In-Reply-To: References: Message-ID: That worked! Deleting that one character made the difference. Thanks! Ryan On Mon, Nov 30, 2015 at 2:41 PM, Andrew Gallagher wrote: > > > > Here's the file's header as viewed with "less" (the starting > non-printing character is suspicious): > > -----BEGIN PGP MESSAGE----- > > That's a Unicode byte order mark. Strictly, it should only be used in > UTF-16 documents but in the real world it's commonly used to mark any > Unicode file. I'm assuming this is a UTF-8 file? If so, you should just be > able to delete the character using vim or similar and try again. > > Andrew. -------------- next part -------------- An HTML attachment was scrubbed... URL: