From tom at ritter.vg Sun Jan 3 17:25:19 2016 From: tom at ritter.vg (Tom Ritter) Date: Sun, 3 Jan 2016 10:25:19 -0600 Subject: Certification Subkey Message-ID: I'm curious about creating a subkey capable of certifying other PGP keys. I don't think this is disallowed by the spec (although I'm not certain about that). It's easy enough to create a subkey with the certification bit by hacking the source. I haven't quite gotten the signing-with-a-subkey component working, but it's obviously possible. The signer would need the custom version of gpg, but that's easy. I know it goes against the standard practice model of OpenPGP, but short of replicating a x509 hierarchy in OpenPGP (which would not work well, due to requiring clients to download the 'intermediate' keys for 'leaf' verification) - this seems like my best bet at the moment... What I'm mostly interested in it _verifying_ signatures made with a subkey. Has anyone attempted this before, and know if default gpg and/or other tools completely choke on this? It obviously wouldn't be worth attempting if no one could verify the signatures. -tom From tk at giga.or.at Sun Jan 3 22:23:56 2016 From: tk at giga.or.at (Thomas Klausner) Date: Sun, 3 Jan 2016 22:23:56 +0100 Subject: S/MIME questions: how to set default key? Message-ID: <20160103212356.GF21633@danbala.tuwien.ac.at> Hi! I'm trying to set up mutt with gpgsm for S/MIME. The documentation was not easy to get together, but I'm now in a state where I can read signed and even encrypted emails I already had. Currently I'm stumped at signing new mails. I always get "error signing data: Certificate expired?" I do have two certificates, one that is expired and one that is not. # gpgsm -K tk at giga .../.gnupg/pubring.kbx ---------------------------- ID: 0xID1 S/N: 0... Issuer: /CN=CA Cert Signing Authority/OU=http:\x2f\x2fwww.cacert.org/O=Root CA/EMail=support at cacert.org Subject: /CN=CAcert WoT User/EMail=tk at giga.or.at aka: tk at giga.or.at validity: 2013-... through 2015-... key type: 2048 bit RSA key usage: digitalSignature keyEncipherment keyAgreement ext key usage: emailProtection (suggested), clientAuth (suggested), 1.3.6.1.4.1.311.10.3.4 (suggested), serverGatedCrypto.ms (suggested), serverGatedCrypto.ns (suggested) fingerprint: FI:NG:ER:PR:IN:T1 ID: 0xID2 S/N: ... Issuer: /CN=CA Cert Signing Authority/OU=http:\x2f\x2fwww.cacert.org/O=Root CA/EMail=support at cacert.org Subject: /CN=CAcert WoT User/EMail=tk at giga.or.at aka: tk at giga.or.at validity: 2015-... through 2017-... key type: 2048 bit RSA key usage: digitalSignature keyEncipherment keyAgreement ext key usage: emailProtection (suggested), clientAuth (suggested), 1.3.6.1.4.1.311.10.3.4 (suggested), serverGatedCrypto.ms (suggested), serverGatedCrypto.ns (suggested) fingerprint: FI:NG:ER:PR:IN:T2 I guess the wrong one is chosen; so I tried setting in .muttrc: set smime_default_key=0xID2 but this doesn't change anything, nor did set smime_default_key=FI:NG:ER:PR:IN:T2 Does anyone here know how to fix this? Thanks, Thomas From joshua at bachmeier.cc Mon Jan 4 00:59:36 2016 From: joshua at bachmeier.cc (Joshua Bachmeier) Date: Mon, 4 Jan 2016 00:59:36 +0100 Subject: Remote gpg-agent and pinentry Message-ID: <5689B5E8.3040105@bachmeier.cc> Hello everybody, following Neals talk "An Advanced Introduction to GnuPG" at 32C3, I tried to configure myself a remote gpg-agent. I wasn't quiet able to figure out how this is supposed to work (or if it even can) with pinentry and only found an ugly sometimes-working workaround. Anyway here is what i did (sorry for the long text): On my remote machine: $ su gpg $ echo 'extra-socket /home/gpg/.gnupg/S.gpg-agent-remote' \ >> /home/gpg/.gnupg/gpg-agent.conf $ gpg-agent --daemon On my local machine I used ssh to forward the gpg-agent socket: $ ssh -o ExitOnForwardFailure=yes -o StreamLocalBindUnlink=yes \ -L /home/joshua/.gnupg/S.gpg-agent:/home/gpg/.gnupg/S.gpg-agent-remote \ gpg "bash -c 'while sleep 5; do echo NOP; done | gpg-connect-agent'" `gpg` is known by ssh (~/.ssh/config) with all the correct settings (Host, Keyfile, etc). So far, everything as Neal explained. This works as long as the remote gpg-agent does not try to invoke pinentry (even if it is installed on the remote machine). For example, if i try to import an (encrypted) secret key: $ gpg --import /tmp/secret.key gpg: key D585E323: "Joshua Bachmeier " not changed gpg: error getting the KEK: Forbidden gpg: Total number processed: 1 gpg: unchanged: 1 gpg: secret keys read: 1 Makes sense, since pinentry can't be invoked on the remote machine. So, now the workaround, using the pinentry loopback: On the remote machine: $ killall gpg-agent $ gpg-agent --daemon --allow-loopback-pinentry Back on the local machine, we first need to adapt the ssh tunnel, since the extra-socket runs in "restricted mode", wich disallows loopback. Just use the standard socket (on the remote machine) then: $ ssh ... -L /home/joshua/.gnupg/S.gpg-agent:/home/gpg/.gnupg/S.gpg-agent \ ... Try again: $ gpg --pinentry-mode=loopback -v --import /tmp/secret.key gpg: armor header: Version: GnuPG v2 gpg: sec rsa4096/D585E323 2015-01-15 Joshua Bachmeier gpg: pub rsa4096/D585E323 2015-01-15 Joshua Bachmeier gpg: key D585E323: removed multiple subkey binding gpg: key D585E323: "Joshua Bachmeier " not changed Enter passphrase: <...> gpg: key D585E323/D585E323: secret key imported gpg: key D585E323/258377D5: secret key imported gpg: key D585E323: secret key imported gpg: Total number processed: 3 gpg: unchanged: 1 gpg: secret keys read: 3 gpg: secret keys imported: 2 This also works for --sign, but not for --delete-secret-keys. tl;dr If you got here, thanks! So the loopback trick is rather ugly, since it won't work with e.g. Enigmail, and requires to disable the "restricted mode" (which i'm sure is there for a reason). What I would find ideal would be to somehow let the remote gpg-agent trigger a pinentry on the local machine (maybe via looping back to the local gpg and letting that invoke pinentry?). Thanks in advance for answers / help / suggestions. Regards, Joshua Remote version: $ gpg-agent --version gpg-agent (GnuPG) 2.1.10 libgcrypt 1.6.4 Copyright... Local version: $ gpg --version gpg (GnuPG) 2.1.9 libgcrypt 1.6.4 Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From stebe at mailbox.org Mon Jan 4 14:12:18 2016 From: stebe at mailbox.org (stebe at mailbox.org) Date: Mon, 4 Jan 2016 14:12:18 +0100 (CET) Subject: S/MIME questions: how to set default key? In-Reply-To: <20160103212356.GF21633@danbala.tuwien.ac.at> References: <20160103212356.GF21633@danbala.tuwien.ac.at> Message-ID: <419766599.669.8bce28ca-e337-4ab2-a78c-9facd1501f8b.open-xchange@office.mailbox.org> Hi Thomas, > Currently I'm stumped at signing new mails. > I always get "error signing data: Certificate expired?" > > I do have two certificates, one that is expired and one that is not. (...) > I guess the wrong one is chosen; so I tried setting in .muttrc: > > set smime_default_key=0xID2 > > but this doesn't change anything, nor did > > set smime_default_key=FI:NG:ER:PR:IN:T2 > > Does anyone here know how to fix this? I haven't used gpgsm yet, but in section 4.2.3 of the info gnupg manual it is indicated the following. --default-key USER_ID' Use USER_ID as the standard key for signing. This key is used if no other key has been defined as a signing key. Note, that the first `--local-users' option also sets this key if it has not yet been set; however `--default-key' always overrides this. --local-user USER_ID' -u USER_ID' Set the user(s) to be used for signing. The default is the first secret key found in the database. It seems that gpgsm takes the first entry in the keyring as the one to use. --> see 4.1.2 Commands to select the type of operation: `--sign' Create a digital signature. The key used is either the fist one found in the keybox or those set with the `--local-user' option. So you might set --default-key USER_ID to the one of your new certificate (second in your output list) and add it to gpgsm.conf; you might as well use --local-users instead. Section 4.8.3 Signing a Message also details that you can modify your gpgsm.conf to have gpgsm sign with your new key. "The key used for signing is the default one or the one specified in the configuration file." So it's here and not the .muttrc file where you have to change it. Hope that helps. Stebe From tk at giga.or.at Mon Jan 4 15:27:27 2016 From: tk at giga.or.at (Thomas Klausner) Date: Mon, 4 Jan 2016 15:27:27 +0100 Subject: S/MIME questions: how to set default key? In-Reply-To: <419766599.669.8bce28ca-e337-4ab2-a78c-9facd1501f8b.open-xchange@office.mailbox.org> References: <20160103212356.GF21633@danbala.tuwien.ac.at> <419766599.669.8bce28ca-e337-4ab2-a78c-9facd1501f8b.open-xchange@office.mailbox.org> Message-ID: <20160104142727.GA21130@danbala.tuwien.ac.at> On Mon, Jan 04, 2016 at 02:12:18PM +0100, stebe at mailbox.org wrote: > So you might set --default-key USER_ID to the one of your new certificate > (second in your output list) and add it to gpgsm.conf; you might as well > use --local-users instead. I don't understand what 'local-user' wants to signify as a parameter, but I can confirm that adding local-user FI:NG:ER:PR:IN:T2:... to my .gnupg/gpgsm.conf does indeed work. Thank you very much! Thomas From wk at gnupg.org Mon Jan 4 17:03:13 2016 From: wk at gnupg.org (Werner Koch) Date: Mon, 04 Jan 2016 17:03:13 +0100 Subject: Certification Subkey In-Reply-To: (Tom Ritter's message of "Sun, 3 Jan 2016 10:25:19 -0600") References: Message-ID: <87poxhl4ce.fsf@vigenere.g10code.de> On Sun, 3 Jan 2016 17:25, tom at ritter.vg said: > I'm curious about creating a subkey capable of certifying other PGP > keys. I don't think this is disallowed by the spec (although I'm not > certain about that). It is not explicitly stated about self-signatures on user ids but it is stated for key binding signatures. Thus you might be right that it is not disallowed. However, allowing this would very likely violate our security model and thus sensible implementations will only self- or key-binding signatures done using the primary key. The only exception I see are Embedded Signature sub-packets (5.2.3.26) > It's easy enough to create a subkey with the certification bit by > hacking the source. I haven't quite gotten the signing-with-a-subkey FWIW, recent versions of gpg allow you to enter =c for a certification only key on the key capability prompt - but it is only honored for the primary key. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mwood at IUPUI.Edu Wed Jan 6 16:20:11 2016 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Wed, 6 Jan 2016 10:20:11 -0500 Subject: about cartoon in FAQ 10.1. 'Correct, horse! Battery staple!' In-Reply-To: <20151225235617.GA16126@raf.org> References: <20151224160254.GA2153@c720-r285885-amd64> <2294973.TDpHq92AEh@collossus.ingo-kloecker.de> <20151225191103.GA1930@c720-r285885-amd64> <20151225235617.GA16126@raf.org> Message-ID: <20160106152011.GA29329@IUPUI.Edu> For years I've used a gadget that generates random pronounceable strings for creating passwords. Eventually word came down from on high: "thou shalt use passphrases". So now I generate one of those random pronounceables and substitute it for a word in a sentence: "Never stop leyphohap number 3!" I can learn that just about as quickly as "leyphohap" alone. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: Digital signature URL: From Lars.Hollenbach at giepa.de Wed Jan 6 17:03:43 2016 From: Lars.Hollenbach at giepa.de (Lars Hollenbach) Date: Wed, 6 Jan 2016 17:03:43 +0100 Subject: gpg --encrypt-to says a key by fingerprint is ambigous Message-ID: <1DC3C8C67280FB4C9A402CB6DB1358F51AB228216D@S2008SBS.intern.giepa.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, When I use gpg --encrypt-to I am getting this: gpg --encrypt-to 06195004D8FBF459786B2CA2D731496480A63D5A gpg: key specification '06195004D8FBF459786B2CA2D731496480A63D5A' is ambiguous gpg: (check argument of option '--encrypt-to') gpg: '06195004D8FBF459786B2CA2D731496480A63D5A' matches at least: gpg: 06195004D8FBF459786B2CA2D731496480A63D5A gpg: 06195004D8FBF459786B2CA2D731496480A63D5A I'm using gnupg 2.1.10 on Windows 8.1 Verschl?sseln Sie Ihre E-Mails mit gpg4o f?r Outlook | Encrypt your email with gpg4o - ------------------------------------------------------------------------------------------------------------------- Lars Hollenbach Auszubildender Giegerich & Partner GmbH Robert-Bosch-Stra?e 18 | D-63303 Dreieich Tel. +49 6103 5881-0 | Fax +49 6103 5881-49 lars.hollenbach at giepa.de | http://www.giepa.de Gesch?ftsf?hrer: Dipl.-Ing. (TU) Hans-Joachim Giegerich Amtsgericht Offenbach/Main | HRB 33236 TeleTrusT Quality Seal ?IT Security made in Germany? www.teletrust.de/itsmig - ------------------------------------------------------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using gpg4o v3.5.53.6558 - http://www.gpg4o.com/ Charset: utf-8 iQIcBAEBCAAGBQJWjTreAAoJEOuEWOo7QtbaqYIQAJEwgTeVdT69+77vwYk/WCJO 09qRRA8fBXcDhrAc2hzqlZ2gc/oD8KuKzumlupuZjP8LZtO0N+Zg/CjrgdO3LJp2 tWmUgI3aKdw1NU2+Y3JviySvqTMvI5cd73Ei7nUVK3rwMOFMbLKc7j/3K5GGH0ux BtCs0cYYvDIf4wAfIOBSxsM4g/HLwiF7QvK8I+S0qCvtHfjsQUuES80kmtaXbntV IO/AgyZ0/WVKU28z2SnLxtlJS0Y9SsyJvboKjCF6An9A0bNWL0lhqWcsCFQr18XN A4apGCq2NaLv4poLEv1TAJk9m6sXxn6FVbtyPzejoDs18iBhv+0cxv1k+UtN+yy2 490aS10ttDYQNPOVNW334AvJgYu8s3IY5AuASwiQzqntulo7lL2vCO5th20VnOAC 4bapp/beC96WuKgBfMCKTl5zP3z10croc8X/9yTBvxcbsyw5/b7M7Bri9iYlsO4o OTiBflXL9gaTyDFDMoHThIj6oNLb47CcIqR0zQbzIECpkgN3SV7w45AlWufr/yzy b1NqKUiLH+fXv7KEAP14afnK9t9eziIKircSRAq2BYm5fspFUxbDahf4qi5MGqTa 2wBFYR5BNchQTITmE8a/dmD+hkqpjHqeORWh5MJgfGIBgOUwdNRHKndVU4l85YjA 5DrKD1tRUy3wVvM1Di0P =QmHc -----END PGP SIGNATURE----- From dougb at dougbarton.email Wed Jan 6 21:00:13 2016 From: dougb at dougbarton.email (Doug Barton) Date: Wed, 6 Jan 2016 12:00:13 -0800 Subject: gpg --encrypt-to says a key by fingerprint is ambigous In-Reply-To: <1DC3C8C67280FB4C9A402CB6DB1358F51AB228216D@S2008SBS.intern.giepa.de> References: <1DC3C8C67280FB4C9A402CB6DB1358F51AB228216D@S2008SBS.intern.giepa.de> Message-ID: <568D724D.4010904@dougbarton.email> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 1/6/2016 8:03 AM, Lars Hollenbach wrote: | Hello, When I use gpg --encrypt-to I am getting | this: | | gpg --encrypt-to 06195004D8FBF459786B2CA2D731496480A63D5A gpg: key | specification '06195004D8FBF459786B2CA2D731496480A63D5A' is | ambiguous gpg: (check argument of option '--encrypt-to') gpg: | '06195004D8FBF459786B2CA2D731496480A63D5A' matches at least: gpg: | 06195004D8FBF459786B2CA2D731496480A63D5A gpg: | 06195004D8FBF459786B2CA2D731496480A63D5A The error message seems pretty straightforward ... can you show us the output of --list-keys for that fingerprint? Doug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBCAAGBQJWjXJNAAoJEFzGhvEaGryErNkH/2e81P2zaHt+EM0gvJp9VgrD BqdiH6p8pzYLvQK1iVgMRymQXCjFhJWDFvWl1enOIeJbiO5OVHiK9vIuRRC7O3mF mN0s84illeJfIHBjYANt7fdpUhHr/rQ+KYuAZ7yrbKVeQbZ47HfKpvhOf1ANb5nR 3xgGek4qD7lVSWmAMEKoDOmUqVlf3vq76pTYtce7R/kWrZVnlm2+PnkZ06PvB0ye 7eDkis1J3FBzCxHpdDCExjyh02QHwxBnqgu2MTusrtFY34JMWB/LBjeAwFf6Dy1M 6HcvzwY2M+8Fp6KK2Ift44jrMy8eEbXGqC2oGsw9S5MPIrn6XCI7fF2jie3/P9w= =xxIx -----END PGP SIGNATURE----- From ludwig at enigmail.net Thu Jan 7 09:38:23 2016 From: ludwig at enigmail.net (=?UTF-8?B?THVkd2lnIEjDvGdlbHNjaMOkZmVy?=) Date: Thu, 7 Jan 2016 09:38:23 +0100 Subject: gpg --encrypt-to says a key by fingerprint is ambigous In-Reply-To: <1DC3C8C67280FB4C9A402CB6DB1358F51AB228216D@S2008SBS.intern.giepa.de> References: <1DC3C8C67280FB4C9A402CB6DB1358F51AB228216D@S2008SBS.intern.giepa.de> Message-ID: <568E23FF.8070709@enigmail.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 06.01.16 17:03, Lars Hollenbach wrote: > I'm using gnupg 2.1.10 on Windows 8.1 That's a known bug in 2.1.10 Workaround till 2.1.11: use the short key-Id. Ludwig -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWjiP7AAoJEDrb+m0Aoeb+uIwQAIeUVR2vigb9sJxGH5rAYAYV 35Azpgo1VRWyIIc/XtZ6eFRW3tlj5MZju1GjZ1NJQygbTJvvqqMA9gqdAkF6IaDI +3nwjbjRzRtyTiDJRkBtai4/UGuCWNzJDZ7c+kO5ZOXEJSYk5gW27LCjlEza+J9y OpDV+2NONV4qG3mYGzQIBvXtT7IsyGD/3X+67LzlOZOtvJ2UGEn0ggoWAu+DhISz VgODOdFK+cVmgOYd9XvtlQpc+W2yapTjaam5Xj3IdRo/gkdo5jU8CxUF37Tg0eJu xjEdR+52ejuM9xrHmmHKSirg1G7kCi7TBkj/MiMLfckqFHfd/dtFWpMPPHpeS9mb XY967AsXy3zuTR8r0oLMDzRXahWeyOmjec4wQBxF6L/Kk9CqviY8+ffCX9QAjFSr clhUnSNm4FeFpm1kjUOgRbiMIZnT9feeDZQHGM9Th8CP3vES9djZHjJadrd+zpWT AoIIpB87TwigbwlyMk6z6sf9DjJW+J9OCWCVCIA2FTS1CzZwK6Z5dfvm4F1gECtD 9/B0dQmYwFGsfvnW9mvshV9vijZp5lEW/tx2MJl+2aPtI+s0CwjSGa15eewIlvrP C5N83hOCnonA4MU95kiFEUpZAxAY7fq546Y+CSjFW0A1xipziNhu+pJQJZPwvQ9I Oh5bGQ56KXes5hcteizw =JCUu -----END PGP SIGNATURE----- From aheinecke at intevation.de Thu Jan 7 10:38:06 2016 From: aheinecke at intevation.de (Andre Heinecke) Date: Thu, 07 Jan 2016 10:38:06 +0100 Subject: Obtaining SSH Key format from OpenPGP public certificate without gpgkey2ssh Message-ID: <3180889.NqOGdysozZ@esus> Hi, In a previous thread it was noted that gpgkey2ssh is deprecated and will likely be removed. Niibe pointed out how to add a key to GnuPG sshcontrol and obtain the SSH key format from ssh-add -L https://lists.gnupg.org/pipermail/gnupg-users/2015-December/054871.html This works for myself. But I'm missing a way for someone that has only my public key to add this key to an SSH authorized_keys file without input from me. E.g. Another person has verified / signed my PGP key that has an Authentication Subkey. How can this Person get the SSH Key representation without having to ask me to provide it? (Assuming the person has my public key and without gpgkey2ssh) I think this use case is one of the nice features you get by associating an OpenPGP key with SSH Authentication and I would miss it if gpgkey2ssh is removed. 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: 648 bytes Desc: This is a digitally signed message part. URL: From gniibe at fsij.org Thu Jan 7 12:48:48 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 07 Jan 2016 20:48:48 +0900 Subject: Obtaining SSH Key format from OpenPGP public certificate without gpgkey2ssh In-Reply-To: <3180889.NqOGdysozZ@esus> References: <3180889.NqOGdysozZ@esus> Message-ID: <568E50A0.9020401@fsij.org> On 01/07/2016 06:38 PM, Andre Heinecke wrote: > E.g. Another person has verified / signed my PGP key that has an Authentication > Subkey. How can this Person get the SSH Key representation without having to > ask me to provide it? (Assuming the person has my public key and without > gpgkey2ssh) > > I think this use case is one of the nice features you get by associating an > OpenPGP key with SSH Authentication and I would miss it if gpgkey2ssh is > removed. Exactly, this is very useful. In the past, I wrote an article: http://www.gniibe.org/memo/software/ssh/using-gpgkey-for-ssh.html Alternatively, we have openpgp2ssh utility in monkeysphere. http://web.monkeysphere.info/ I think that it's worth to keep gpgkey2ssh in GnuPG and to enhance it to support ECC. -- From aheinecke at intevation.de Thu Jan 7 14:43:51 2016 From: aheinecke at intevation.de (Andre Heinecke) Date: Thu, 07 Jan 2016 14:43:51 +0100 Subject: Obtaining SSH Key format from OpenPGP public certificate without gpgkey2ssh In-Reply-To: <568E50A0.9020401@fsij.org> References: <3180889.NqOGdysozZ@esus> <568E50A0.9020401@fsij.org> Message-ID: <6664647.bR6S5eXtkx@esus> Hi, On Thursday 07 January 2016 20:48:48 NIIBE Yutaka wrote: > Exactly, this is very useful. In the past, I wrote an article: > > http://www.gniibe.org/memo/software/ssh/using-gpgkey-for-ssh.html This article describes exactly my use case :-) > I think that it's worth to keep gpgkey2ssh in GnuPG and to enhance it > to support ECC. I would not expect it to be It's own tool. But rather in GnuPG proper so that the documentation for this is also part of GnuPG and can be found when you look for SSH. Maybe as an Export option? I've opened a wish for this: https://bugs.gnupg.org/gnupg/issue2212 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: 648 bytes Desc: This is a digitally signed message part. URL: From thomas.hartmann at desy.de Thu Jan 7 17:17:53 2016 From: thomas.hartmann at desy.de (Thomas Hartmann) Date: Thu, 7 Jan 2016 17:17:53 +0100 Subject: Creating encryption subkey with C25519 fails [gpg2 2.1.9, libgcrypt 1.6.4] Message-ID: <568E8FB1.1040601@desy.de> Hi all, probably a newbie question: I have just been trying to create a curve 25519 subkey for encryption (I have already a RSA key for encryption-only and a c25519 for sign/auth). However, when going for the ECC encryption only fails always for me due to an invalid flag [1]? (gpg2 2.1.9, libgcrypt 1.6.4 on Fedora 23 on 4.2.8-300) Actually, setting own capabilities for elliptic curves only offers signing and authentification as switchable options but no encryption? Maybe I did not get ECC correctly, but I assumed that ECC should in general fit all three uses, or? Cheers and thanks for ideas, Thomas [1] gpg2 --homedir=/FOOPATH/gnupg --expert --edit-key 0xLONGMASTERID gpg (GnuPG) 2.1.9; Copyright (C) 2015 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Secret key is available. sec ed25519/0xLONGMASTERID created: 2016-01-07 expires: 2023-01-05 usage: SCA trust: ultimate validity: ultimate ssb rsa4096/0xLONGSUBID created: 2016-01-07 expires: 2022-01-05 usage: E ssb ed25519/0xLONGSUBID2 created: 2016-01-07 expires: 2022-01-05 usage: SA [ultimate] (1). Thomas Hartmann gpg> addkey Please select what kind of key you want: (3) DSA (sign only) (4) RSA (sign only) (5) Elgamal (encrypt only) (6) RSA (encrypt only) (7) DSA (set your own capabilities) (8) RSA (set your own capabilities) (10) ECC (sign only) (11) ECC (set your own capabilities) (12) ECC (encrypt only) (13) Existing key Your selection? 12 Please select which elliptic curve you want: (1) Curve 25519 (2) NIST P-256 (3) NIST P-384 (4) NIST P-521 Your selection? 1 gpg: WARNING: Curve25519 is not yet part of the OpenPGP standard. Use this curve anyway? (y/N) y Please specify how long the key should be valid. 0 = key does not expire = key expires in n days w = key expires in n weeks m = key expires in n months y = key expires in n years Key is valid for? (0) 6y Key expires at Wed Jan 5 17:06:52 2022 CET Is this correct? (y/N) y Really create? (y/N) y We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. gpg: agent_genkey failed: Invalid flag gpg: Key generation failed: Invalid flag gpg> save Key not changed so no update needed. Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5095 bytes Desc: S/MIME Cryptographic Signature URL: From kristian.fiskerstrand at sumptuouscapital.com Thu Jan 7 18:13:42 2016 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Thu, 7 Jan 2016 18:13:42 +0100 Subject: Creating encryption subkey with C25519 fails [gpg2 2.1.9, libgcrypt 1.6.4] In-Reply-To: <568E8FB1.1040601@desy.de> References: <568E8FB1.1040601@desy.de> Message-ID: <568E9CC6.7010600@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 01/07/2016 05:17 PM, Thomas Hartmann wrote: > Hi all, > > probably a newbie question: I have just been trying to create a > curve 25519 subkey for encryption (I have already a RSA key for > encryption-only and a c25519 for sign/auth). However, when going > for the ECC encryption only fails always for me due to an invalid > flag [1]? (gpg2 2.1.9, libgcrypt 1.6.4 on Fedora 23 on 4.2.8-300) you need libgcrypt 1.7 (git master) for curve25519 encryption - -- - ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- "Leadership is a potent combination of strategy and character. But if you must be without one, be without the strategy." (Norman Schwarzkopf) -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJWjpzCAAoJECULev7WN52F9tkIAMHGa88D8fOo3i20nC0fvbwJ RYBxJ2joSZzik2t1tGojwCxwS97fY23homhVFieJCbaZu1QcsmcvruOcjjmVWAJM xPZpNhkFlgkmwX4JRVPhXq0l+XrFRO0QGPaVJZFrJ4F0SLd/bzAI9FjF6wgVTOW7 egbVWnWFZ9jYLv6NbTTfD7+CMrWKtIFApHwEI/njVSTcLwv8ZnUCq5EB3dx2z55X r7UtvZZ92Fi9p6+WpE/UbxTnbkWWzcilg02mjv+K9pMZ+MY9AOQp0eFE6noENlXY A0RUHoea83yW/t5db7xuLpyXqjecv9cKjoXEwuUniA40LUfTM1ar0eTnDpGYc50= =Ke/M -----END PGP SIGNATURE----- From mvatis at steptoe.com Thu Jan 7 21:53:54 2016 From: mvatis at steptoe.com (Vatis, Michael) Date: Thu, 7 Jan 2016 20:53:54 +0000 Subject: Declaration in France Message-ID: <7C3A964A617FDE4A8629F91FEE94A88ECEFB588E@SJUSMAIL01.steptoe.com> Does anyone know whether a declaration has ever been filed by anyone with the French "L'Agence Nationale de la S?curit? des Syst?mes d'information" (ANSSI) for GnuPG version 2.0.16 to allow import of the software into France? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mvatis at steptoe.com Thu Jan 7 23:04:26 2016 From: mvatis at steptoe.com (Vatis, Michael) Date: Thu, 7 Jan 2016 22:04:26 +0000 Subject: Declaration of version 2.0.16 in France Message-ID: <7C3A964A617FDE4A8629F91FEE94A88ECEFB59AD@SJUSMAIL01.steptoe.com> Does anyone know whether a declaration has ever been filed by anyone with the French "L'Agence Nationale de la S?curit? des Syst?mes d'information" (ANSSI) for GnuPG version 2.0.16 to allow import of the software into France? -------------- next part -------------- An HTML attachment was scrubbed... URL: From stebe at mailbox.org Fri Jan 8 13:44:40 2016 From: stebe at mailbox.org (stebe at mailbox.org) Date: Fri, 8 Jan 2016 13:44:40 +0100 (CET) Subject: Declaration of version 2.0.16 in France In-Reply-To: <7C3A964A617FDE4A8629F91FEE94A88ECEFB59AD@SJUSMAIL01.steptoe.com> References: <7C3A964A617FDE4A8629F91FEE94A88ECEFB59AD@SJUSMAIL01.steptoe.com> Message-ID: <1135750810.22271.1675247d-815f-4c4b-9c93-3aa94b8d08fb.open-xchange@office.mailbox.org> Hi Michael, > "Vatis, Michael" hat am 7. Januar 2016 um 23:04 > geschrieben: > > > Does anyone know whether a declaration has ever been filed by anyone > with the French "L'Agence Nationale de la S?curit? des Syst?mes > d'information" (ANSSI) for GnuPG version 2.0.16 to allow import of the > software into France? According to a quick lookup of the issue at (1) it seems that the importation of cryptographic software that goes beyond authentication and verification (of signatures) has to be declared in advance to the French Prime Minister. Quote from (1) (sorry for putting it here in the original version) Ainsi, la fourniture et l?importation depuis un ?tat membre de l?Union europ?enne ou depuis un pays tiers, de moyens de cryptologie n?assurant pas exclusivement des fonctions d?authentification ou de contr?le d?int?grit?, sont soumis ? une d?claration pr?alable aupr?s de Premier ministre. Cette d?claration comprend la mise ? disposition de la description des caract?ristiques techniques du moyen de cryptologie en cause, ainsi que du code source des logiciels. But, taking into consideration that GnuPG is free software, does not have any distributing agent neither in France (nor in other any country) and its potential users download it at their own discretion from servers located outside France (so there isn't taking place any import in the commercial/legal sense) I think that this specific French legislation is not applicable to GnuPG. Cheers Stebe (1) http://dwavocat.blogspot.com/2014/02/la-cryptologie-une-reglementation-qui.html From thomas.hartmann at desy.de Fri Jan 8 15:23:01 2016 From: thomas.hartmann at desy.de (Thomas Hartmann) Date: Fri, 8 Jan 2016 15:23:01 +0100 Subject: Creating encryption subkey with C25519 fails [gpg2 2.1.9, libgcrypt 1.6.4] In-Reply-To: <568E9CC6.7010600@sumptuouscapital.com> References: <568E8FB1.1040601@desy.de> <568E9CC6.7010600@sumptuouscapital.com> Message-ID: <568FC645.4030605@desy.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Ah, OK many thanks for the info! I got confused with the option already available in gpg2 --expert Cheers and thanks, Thomas Am 07.01.2016 um 18:13 schrieb Kristian Fiskerstrand: > On 01/07/2016 05:17 PM, Thomas Hartmann wrote: >> Hi all, > >> probably a newbie question: I have just been trying to create a >> curve 25519 subkey for encryption (I have already a RSA key for >> encryption-only and a c25519 for sign/auth). However, when going >> for the ECC encryption only fails always for me due to an >> invalid flag [1]? (gpg2 2.1.9, libgcrypt 1.6.4 on Fedora 23 on >> 4.2.8-300) > > you need libgcrypt 1.7 (git master) for curve25519 encryption > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EARYKAAYFAlaPxjkACgkQxra5y5ss1GsWEQEAo91LaZILlsvLI5KQMsPPlNJU PKj12rwdo/6Gkk8IZIcA/3+xlRLu8kQ//PE2zCMhwTkggDWljuLH98G1eFmJTmkE =jG+G -----END PGP SIGNATURE----- From wk at gnupg.org Sat Jan 9 12:00:31 2016 From: wk at gnupg.org (Werner Koch) Date: Sat, 09 Jan 2016 12:00:31 +0100 Subject: Declaration of version 2.0.16 in France In-Reply-To: <7C3A964A617FDE4A8629F91FEE94A88ECEFB59AD@SJUSMAIL01.steptoe.com> (Michael Vatis's message of "Thu, 7 Jan 2016 22:04:26 +0000") References: <7C3A964A617FDE4A8629F91FEE94A88ECEFB59AD@SJUSMAIL01.steptoe.com> Message-ID: <87twmnf25s.fsf@vigenere.g10code.de> On Thu, 7 Jan 2016 23:04, mvatis at steptoe.com said: > Does anyone know whether a declaration has ever been filed by anyone > with the French "L'Agence Nationale de la S?curit? des Syst?mes > d'information" (ANSSI) for GnuPG version 2.0.16 to allow import of the > software into France? The only info I have is for version 1.4.10. IIRC, this goes back to Loic Dachary's efforts to get such a declaration many more years ago. You may want to check with him whether there are any updates. However, 2.0.16 is way to old to put any work into it. Better wait for 2.2. I have put some documents up here: Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From tom at ritter.vg Sat Jan 9 23:54:45 2016 From: tom at ritter.vg (Tom Ritter) Date: Sat, 9 Jan 2016 16:54:45 -0600 Subject: Certification Subkey In-Reply-To: <87poxhl4ce.fsf@vigenere.g10code.de> References: <87poxhl4ce.fsf@vigenere.g10code.de> Message-ID: On 4 January 2016 at 10:03, Werner Koch wrote: > On Sun, 3 Jan 2016 17:25, tom at ritter.vg said: >> I'm curious about creating a subkey capable of certifying other PGP >> keys. I don't think this is disallowed by the spec (although I'm not >> certain about that). > > It is not explicitly stated about self-signatures on user ids but it is > stated for key binding signatures. Thus you might be right that it is > not disallowed. However, allowing this would very likely violate our > security model and thus sensible implementations will only self- or > key-binding signatures done using the primary key. The only exception I > see are Embedded Signature sub-packets (5.2.3.26) So I did it... =) It seems to work. I've attached the keys if anyone wants to examine/test them. It contains: - The Signing Key (Primary key and Subkey both with Sign/Certify capability) - Test Key, signed by the Signing Key's subkey - Test Key Two, signed by the Signing Key's subkey, then the signature was revoked -tom -------------- next part -------------- -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFaRf78BEACTpudw1k3rt6/z/SGJNDNh8sXSC2s46MBtA33O6fd9F5Dz98Ys PHWlds+ixFRuAidozGJkYqU2wXvmnGIPHT5UM0/L5ARKbgbX77ca+Oxt1ClpQbXY H+XedX+uw9mSgD3+BX68Vylp7tIIjNmWgB+k72He6F0Vw2h/NOYd5TyV+aiAIZnc LTwESExBUXDMbViVl1fJglfTmOTzOgCPjCOUrqHiLAeQ/POy2YyvMsJKZkWzf11p PbBidKl5u3YSc2ooTlUEFGrO42R0/IVhjetbAWwqhqNyOVlO9pg3kzz4B42nins2 jcPk1+pG1SCpMEw+3WMrIaVmD/cKMv6hfLj3O5uOdOVgfx9wfp/+f9lu4kEcf3yB rWV0eRuCbpuyf6v+d5+oAF4vxPDmdFFiL8Bw2pKj+fq6BAsrtluLFM00T6V7Cuj7 lwpThRIuQ/8iGuSqYGn8zDQKZS4v/5IS8k8RCvK22Y7w/DwXRrlIl/nVwnasAcLK WAlCJPvvB/RZI6tvNQhIIFE9R8Gzl1jjM1AilmkEfxxpkmHBGhtslOgWq5KLr68b dRsBipqYaG0+5jUp8STS28h1hbIb7fIJ2EajCIGhc9mcwIvivU/v19tcd678fjpF qon65yVd7P49P3hUl4aDvr3JSaTWCcUu7no5BDXZRQDCxzJqOmHbTXnkkwARAQAB tBBUZXN0IFNpZ25pbmcgS2V5iQI4BBMBAgAiBQJWkX+/AhsDBgsJCAcDAgYVCAIJ CgsEFgIDAQIeAQIXgAAKCRAjVwBFdpcNSns4D/4i/Dpa8AnefSvxzeyqLkJBVreg gB8BHp1WknehBEi0fAxDfKxOkgt7uqzDSIy8QFX8bYFUqfKLdZu0veuCjOoZwRDh v8BNVan3XkTBlQp/HeuwlpFbbj8+gkOzC/aQdvL6bdYAWbvNsH0kxgCO+c5Bn0rC Y6y3nSd0Np9tXuBJaeCLQCO9sJIkTH5/DB58Vw349ib5JbxAWVa5Bit5GpOr29sh lR9VOBSkh2/I/uXyT6s4EJbyuVfuIEuex3MY66Ls6rea0bnWZDUIA4c+pq/SbZUc iM/yYx7Sdop1MG09vKQRUNlRwCt5tWfhHvBIDvXJgxvoyw1aOs5Xxxr5FXcT4WQs 3iJNh5zHxmlxjHtjYUxTj438s+QX+/O+iK0bw5e0oql69kCqIT6be4BpWf7aqwhL HAm27KDxcjTQBZQdzTFo9+pGcujjZg+Q8jxsYqZbR9ZnI6++3y7TVt9/OucD6EmM c+ixiRSzdrhY+QXCgncuJD+RGUhURDNfCdLXFOKFPdiglWzv8PUIYuQofyqV9Eea fH7Jwe7+JUONU6g/EScMXpsoFnvYdSeoxlBesUznwegHkAq9S9cWOSyfgwARH5Bf JUf8egfrNTJM4TpUfVNCyB03WAP54ulSW74fbRkoVq2sWhSkS5ZS1YCl6Qc77H5y MtcB7mXxkDhRxl74ULkCDQRWkYnAARAAskbvbwfYnIk+1M8N4oyAjU4W6x2sLheQ I/7ZH1tJMwnFD3Dxq7qMRmiILZ9HoJ6sY7VIUuyX2U08vojs3uy3hNabZdqdeg25 R6Hk6yOR0L3urSq6YWZ00qpdxhVfc8XGiT2LphgKxm8/mOXiabMyMm98d8kGDCv+ bTwAPF3v5GRzN2bs5prrjMoufH/lqQaFvgNRM+WnqaoXPSlcQSUdvkfdxIPTSoV0 9M/OwfmMkZMSGhKkYooNnfx7UfqPTuQP3expGLl9XbtM1udPxJl6WnO3hvlERMC6 SRWwsHBqnYQGF2CrgAMvSqRbeLXiPH+mrIpGDq6+CaGnFU6yR2XT2uvkqhEXkGxW zFzLcVf6gu4rVE4H1KYG6CTLXKWtp+2X5a8j3V/iUpMSgozqpztoiQcMsaxoK/l7 gvKFMRyHrNDYrRNmk/7TO4F7GWPpNY0OOjqYjDyQE9E7RIDILcxqwdc6RyPRqiZe oFVXEeJHd9V6QiCJmQUj49PQ68Y6G09SnPdeZ2OnKLwPiEcVuRztJAZ0K6/4gpud zbtYxHMAs4FVkmiwRwr776nu2s85jwkoxP306TylWRv5Xa/e2ZNvZkxVgm9oJrTX bn/B6zM2Epkus348I/nCc61cZJH37byQzoj4GfmdVyvFX93+WHyoo7ph8aipr/TW oX85YFhhHucAEQEAAYkEPgQYAQIACQUCVpGJwAIbAwIpCRAjVwBFdpcNSsFdIAQZ AQIABgUCVpGJwAAKCRB1uAUjWwI13xnIEACPkaRoitPbJZ+D6lGi7f9MwzhTbpCP rKejARmWd7tyscZVFi9k5uId5crc+5+yK/oYVX4hQ2I8vAKdx1aXVloqhryBqtDC iJihPE9b7cTdQfYv87LXM2N1/0mRI8xyrFlDwq4IlxASsFd16u45Kb0FODmXIqLE UQ+QNIBWsHBPoOgHdyfRVIV52yJUBo4NhwQHZB45CYJ30tCQzK0AGYZp1T/fbt51 NHVhD+q7ngfHICBGASDlVG0yZxDkBUIxQ/dO/hA7Js1awLdWQo43+DOk6+st2jyw dBb1DAmxOlNUpXeoyLKgfJDbUgT5wvLJe4ldyENzCQpq4+T91FoULsXrXTeVSFIP 4K1RDtvh1uFDz8R10poukVw9xX1MRKHmfq8mLzFBpeQSXfcdxrtCmp+emgtxdSmA /QZ3FBsEKZhDu4hgAjyady8xjWO21jyVZb7RRHTKPkTv56dBdIH0Y68+1FZrSyG9 PCEL3FT9vIYNLCCQ/dTxGznzN7zf2nYeoayZ3SJr0Wkg49+NbOHm/iSRFI6LJnzF ghHoAMBZ2djR3IH992htViUpxUaKGnNlbVe894xhG8qGUnvI8JC4j7kXN+RgtgP1 CADbPcIvUK9sxOxONSzNkoOBLG2PjGNF0XANMZfdOFgjv1CA9lSMdpkJIo8kAPqx pkSvLVXS+HdUygOuD/9mNBh9ifbUgdpirxv6wb1oYl51M56ErWcPi+Fcg5BdZkG7 4sIy/9QDnCAtRiRaqUv2w9EvZImQAOin16HCt9mGFClqjmgrYKXIeoFPZ0T0u2QX APKEFpStFeM4rWjAuOAF8SHdy/jGzB6RyleBEmUXP3sPOSOC2qQcJbFeh0fjprP6 A3a1yvlfKA6qc+ImjisclWL1lSjj91dhhl5EX/bSDlE3Ovamy8l286kWFn0nZsBk dnM+C56Y0rwNs8vbGQNDqasDhPWVp0dENPviyTcuDR4yC2/buBSYsRc2boSiDYML y5MhsttLiOVls0yWep+BZoGSDtrwgFnw8zrWkk/Bv5JimMQZKyc5qm6f83qNG5JY +IezQTZSMXXSvgTGFkhH6NeIbIjABbgebC560sIGwbwTQkIxTuMCQ2Y4SRjbwDGV AQT6WzHeGDBfuV2rFz3vEEGhO0S2e4rUMUfh5CI1kMPkwPGb6KcnQJGSHf1eZFEz xLKJDCEQQJ9lqPped1+8XkKk+O2GiIH/9b/ATP4c8JeD2zAtwf7N5aia+sIxCoj5 JCtAK8lxuQ1ADBn3goaFoktiPPwxtLaUfRjO5q00Opc9K0ZXTUQpnN2aPyRkFTTP FpOF4abN7uFG+RKETCdJZEOlG7JyREEFklp5PidWuAFb3xy4cJGAtVUVy9uc0pkB DQRWkYqSAQgA80ZsWQslBife2ekQ0dvLA0aCVrufI1mz04zFBPBuJ7gugW5PYXYj lKwOJgyhRbVdI0gvhcLCLg5EKcOickfMTN3kDJ56oTcN0TfgK4CVH4RDk4ujh0tH Lq4L/ooo8l+DGnVKU57pKNcPkzmzlFVKxayTJ8DPB4nZJrzUxrGHWexCGP4MM5r7 9GKfi2sBLUjY0s4IrjF01rzwO2IKwioFMhMGCd8e63emeIKjkS7y/yyen0jfyIA7 ARZtpJq7omOFBN4wwWcKjt8RLxWt9LG+WHPI8yApGiSAvaxhaYyqlE73ILdoaPL/ 4sF/4TFLOfRRm50QqC8gHWS9EyVuvVP8ewARAQABtAhUZXN0IEtleYkBOQQTAQgA IwUCVpGKkgIbAwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEPAuX/13m41A oPIIAKG0e2+LUmXLZVUUv4uBL06FtJYnYB4U+sv4VHAoxGokR7I5Q3qpHwfUacF4 MASUCFQn0NuYGXC+LWysUcTeAUwlvXWJMfptzrVsP/pc7pvSLWI7xIWyRry8Au/O fzmZqZHxMYFwcDpV5A9hAax1j65IJBP2mBweBXoGXKdy5uqSNlwlIkQpYcMHUVRE 68JCYBDTwNQO0zHgflZXUan7PGTQgGXuyOgNZ/8AgPNlik26cPOYvcD8x/6t/91l FdRC9iJCCC9c3DMQoYXfiQV5cDEsDZwc+iG89M7ol9AvGDejM8oeNVKf4EOttosM p7CuEGG/0j/ck9H5ZuxPy5A374uJAhwEEAECAAYFAlaRitMACgkQdbgFI1sCNd/i cw//Zkv9rZ+R5syE6t509GlJTamnA4PRQJWY8PJE4aesTCPD33gxeNeA9O1HAAKc Ni1MFD3rIkETWmNs8O7Z+SZb8CjCdd27svYJVU5yEmjBtOOWSk4LlLNm4p5r8ouj 9o6NsnoFcnkN+/f3cnxaR+wO9Kqt+0ueSJH3MwXFMzY6ef3P/IgnLnJ/d0pwcOa2 L+utN6xez51YzAE+h0ldPqqszSU0eT5EFGIEJW/rCI8/GMSKLjR2jmBjOcMWcfmY 12/WTOwVMNn82YJf3rO9STdBYtB7m9FfpHc45y53DTPx5t0maKQ5ETHlVhZebiH0 6tasnork28D0JsdEDZ2hsZImpclkLURlB6ySMZyhwUJecRHe6LqiAOieV1r1ayFU TYiCqfzLLO0eKcFznHTukWfeJ/17s8hDPxO2XD3sWYXRvVY6UV5NATS2L3pDtz/M +dcO0+ppwuWrk1GLtLxyz7+uJaIWJMuwc1MfaqAt4cOo/96Qz7x6hhpKZbCEamHA vByTpaTEllQUdKrVhfFiTo+Xffj8GU2lSDS1PusMj24z1mft1XajBZQzKOub5/kJ acpdAPqt9r8bQiW8Ubi1+GDSeqK8r1rvgDYtSidEPS+L+l1UmOCvlmpD6dKHjKlJ ai32Y3R0177PRgi5SQDuENs6Kj8RU+/y3BDhahUugxQz1U+5AQ0EVpGKkgEIAK5R i1LjIamSJ/bHVp/a4UihBNvAPrda0MsyDw8vIuQd958BDzcgA673rDxf7LW2FYP1 TWdiUkbBwvN4c7EZGh/ujJ4Y9fokv6vNdRE6+gW6TiMe2GoY5cBt3xnbMWQ0TPF0 5XWCiMc2Mft25NQvNu//B2nbPA+o9ju2w9s+qQVEcM7LVvsDLvpGw4ka40dMU0gB G5azOx//s24W7dBaujpdANclQdWVXkf1qJbhyWhGhMfND1cAmd5RajR/dToxz7XS CvzLEdNupp7rWxhEesZMnSlVj500pkfB+MpAA8BPaAFBBJjtgx55UG8AkpVLNB/n ugsw95S1T3f9NE1RxYEAEQEAAYkBHwQYAQgACQUCVpGKkgIbDAAKCRDwLl/9d5uN QPnqCADdegwXY8EhZrUa+hLR3ZNVkG3y5tSagpBzYcWvZR2xYHFdA68VZEl9WeS7 I0SvL7ONhpxvGPOkU9Yrr8IjQXYhTHUkezF3gSv+0qEFjGT2GsSWX5+/93KTYSBM 4Lan7Cn4epwhzWI8Xh+vH394mstDwnuJC/rX7ahC2OaWFTM9N1S3Qi4FapHgJ03Z iN60AwYCx4//PzrAAeSB4I3suHSj9d0T3HLdGZ2SehDtmU4V/EOASSHAloljRDeU C848RpJOaz1lzjFdZCjXZGYp5mL3L9iUsjwbxDHZtYdjGowgvFCSxoTa9aEZl/uq 9HXh+NzvR2mXWdcLGnRVo0b/vZn1mQENBFaRjAoBCADl+XZW+pRKSjbFTf3H5P/H hLuieO1RT9POreH4rVQ+XKtvgpIBBj02gzSrRM/GtNX6aJQweNjH7Re4fUhQbIgh ySJ+S07zXkf4lRBpa3IM35kBn93TbwSuq1VPq2yI1KUitwrXIgSY/YDK54wMA+3m 2VD/cQ2kgIQ1xAyoDE3LRGw1KT2SBOtpVdcMLw+PL/m6HRvhcyY8CCwrGfvkljJn sVDHZPsAkL61WWkfGddVMJkTJwDs2MnbhbVDGnL2jPp79tbb3SBkfHPZE3oG5cVb x3mFfryGzhF/qwpTZ+K3Epi80QvqAhwQ4bIHTeehRS1HY7QhcNRJWzDPs0FrDP1N ABEBAAG0DFRlc3QgS2V5IFR3b4kCHwQwAQgACQUCVpGMhgIdAAAKCRB1uAUjWwI1 3zl2D/4n+qIS2v/95vcDgAcKIWpmzQry2TAla1veI6fbjamZnBIkOQ0OCtga/AnC IoL2dieJaw66BjHiHsxvN0k3ZhZeg2fupw+itTWJicWY1JweU3egDGMCBz4bpz5d FjvMPN7Bn/CjXgnP924+/8W+5/qljwoyQ6NgUSYf7It0bkdjZphpfaIrbzQmDZK5 uYv/8Z7J9Yu9KlTXtgNdGxMaq9kWbMIZiyKj+quElLe4X6eLWrFHijv/AjNT4sQr txJ7FmcAzGZitCLDtdL2FurZd4eBVGFmpO9DSQZHhrMNPasFL7S7Kqcp57Fg7ZY6 fz3ptE1X1wRRqTCSKSrNMP+9ZQQhSIkM/HCCw/ljyaIX9cff1CaCynQZnISU1tAN kc2GJ9y7RxKqYs91pgDeIHfhOc0qphrv6C3ejYZHEyTgdIuUIOAtUPPTaBXgA0I6 R+qLD9rUga34Bvaa4f417V+ZViiAfWLgU1/9KejVEKNzy4CwJzv0A8sYw2jLamAG frPHhOSLyPh/k1yb72GhsPcJ7QWkZubdnSzZEE0aqKMwoo8ITeH2YjSnQCM0AXMs DwKFZiTCzylCygQsgssJNtmiCUxsa/oWpEDA4KhOsHYzrcvmTTJZ0IhMqCUiDbQb 6W6ckxJdqbmTi/Ug50FL2Ze5tkQ7owil9B9M2eaYIrDj/zjUq4kBOQQTAQgAIwUC VpGMCgIbAwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEKWjt6McVEax08wI AKLjvarnAj+jt6pEkOktxKw0g+a/6aazrSPv6D0BgmU92WI8/3DZENqShuLk7+Kl mmKGU9k/QfAKXQG674qMlgfqo6u73M6z1FmcRoxMvAR/0UOkjn6PkMcXNn0HmweT h9iNhGb4+hjU+js2y7fJYZxSCg0cRFfkzRtGQ3onUEOotu3K5z3CLget+NTqNghE KvGAFKOjpPOUpXeZgpqDEuP3WMf1nUJ9xlHJTfE3RBRU85CnPFF/HwlSa2KPjviC zcO0QqjXYi/PyhcejchABqCV+ce6oJ7Qp1RvfgN70cB2HnIVt93MX937HqLdTX/a 7GmDsW1j0uo6bM6NCHSptwWJAhwEEAECAAYFAlaRjDcACgkQdbgFI1sCNd+N6w/9 F6jVVoGsrUBuEcrRJR0O1FIZWHgpkf/dJWM2L2H2WFjEvJNZMDO0PQGSEpMcvF3r 0tYnBz3X+/4wi71gOnJ7bUuksaz1auXXbuK2p3JmnaVDjVo2/B3i7zzpSm+VL58u C8eBaRC6LHCOHEHUgPmh49wV6/pRLU7mbs9od3Ep2SN/Da411ImIqmCwstQX71y/ VFCkLWMJhzLiD/7vpHlgvFQOqE3h/NaqudnR+BzX0O/BRgUL3Dg4cdDdx5gfIS3e LTDvA6lTT+5NLBZNy7E8fudS7HNEHCRkWnvXC3NjylurHlOs7bzgEoVnFIjdfhaJ 214sVKsstAmWHfQ5iR82tzlYn2vb596uNxN/kBpshNpBh7orrVshg0vhC6aPQKmr IBrzAQ9ZDTMHuZQ2pH1D+LXfGTiY3IHFi/tkfrMNnDcsrFhOQd446e6xiZt7Ci2J B0AO5nMup0h7FTnA5MpSBoNiNwPOke3c9k9+q0nzRuw3VYLPhbk6HGL2ovTdvKuY pOqiM4zzsw/xP7YXcBFcI27Y6z/bc5cxORE2juCWjcBzlaDR4JC5YyfVOXhwkQDz 9jXNO34wrHPlC7SVggexwphzocqTkP5hYyrhUPb9mBrE6e5Vcxs0/Mixfu/UwZeV bvFVRhaS19P4MsajuDsw269GiOyjCQ3KZPhFMI1Wrf65AQ0EVpGMCgEIAMBMUK94 zpsTxymQVRE4ttFdJGGemiTEKK5PjrCaymZPGqHtiBYGdt0WtlNnIWOUzLoObFFc +Yn7UQme+O0Qz73EFhamYIUhRZhgS7jneADod/2XiIs0E76svX1Zb2Gm6EowJq4k iLGcvIkdpbaVUwbdTfU+ZUeBJVHvq62gsiZS/dU52ZK8o1e4ObgAUZmARP6fdKV6 KkXGhma7dKWDDPABaRJiWU0HdwUgHG8d3YqIPrc2lbkwCo7u3s7c193DgCujDkp+ CsxzF44hd/BNq5vNzg8tI/0cRuT0woTFaSvKty+DhI2thnM55ccxw4JSRyqHWCGr pew8lbvkBFzF18cAEQEAAYkBHwQYAQgACQUCVpGMCgIbDAAKCRClo7ejHFRGscbk B/0TEEZexfnbvtjQ5biKfuwnv5xG6vTSI+sIa9W0HSOGl2q0zlWgI+tV/Pr00PpN 5/axNMfMrHYyztSCMOW7ZaOpXLiF7dNkgLW2YzHzhA9dQsLXprvs1aFNwC540R18 KX190+lzQHCkjONS7eGhLCM7G156Xc11SABbTcqPpYLbsnNhFERe3BkzVUsuclAB QshA/DG61wkp6axuTYMCrM3nKPjKn3peibc7gAaBklN5xf9/H2lBEKQ8RncUAH77 hV4cfGI3+aSGNkBQN7na1vZK8qO0uZXQN30SpHUkoRokOBtys/7u2+XpnhsdkqZS fa4oRnT6D2bGbbXdehs6T3iZ =plWJ -----END PGP PUBLIC KEY BLOCK----- From fulanoperez at cryptolab.net Mon Jan 11 09:52:52 2016 From: fulanoperez at cryptolab.net (Fulano Diego Perez) Date: Mon, 11 Jan 2016 19:52:52 +1100 Subject: compile 2.1.10 no bzip2 ? Message-ID: <56936D64.1070102@cryptolab.net> Hi, This must be something simple I'm missing but on a debian stretch 64 machine i cannot get gpg 2.1.10 compiled with bzip2 support which prevents me from reading bzip2 compressed files - they can decrypt but: gpg: uncompressing failed: Unknown compression algorithm ./configure --build=x86_64-pc-linux-gnu --prefix=/builds/gnupg21x --enable-large-secmem --with-pinentry-pgm=/usr/bin/pinentry config.log configure:5840: checking whether to enable the BZIP2 compression algorithm configure:5847: result: yes ENABLE_BZIP2_SUPPORT_FALSE='' ENABLE_BZIP2_SUPPORT_TRUE='#' surely don't require --with-bzip2 option ? From wendyoberg at excite.com Sun Jan 10 23:01:43 2016 From: wendyoberg at excite.com (Full Name) Date: Sun, 10 Jan 2016 17:01:43 -0500 Subject: basic identity mgmt Message-ID: <20160110170143.11899@web003.roc2.bluetie.com> Hi, Hi, Someone just gave me their key fingerprint. I want to record that the info in the key is correct. It's unclear to me how I do so. I've done recv-key, and list-key, and verified the fingerprint by hand, and confirmed the person's name and contact details. Do I have to sign it? Is there no way to configure gpg locally to say "the info in this key (fingerprint) is accurate", without having to sign? Is the semantics of signing with lsign or sign "the info in this key is accurate"? Is this separate from the "trust" thing, which is for trusting this key to certify others? When I had first signed an imported key, it showed "trust: unknown". But when I did "trust", then "1 = I don't know or won't say", it showed "trust: undefined". What is the difference between these two values? Am I right in thinking it's the "validity" field which is affected by "sign"? Why is this not updated at all until the program is restarted? Keeping the model of one having to save one's changes, couldn't the program display "validity: unknown (unsaved: full)" or somesuch, thus showing the user what change has been performed by their action? thanks, W. From peter at digitalbrains.com Mon Jan 11 12:19:14 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 11 Jan 2016 12:19:14 +0100 Subject: basic identity mgmt In-Reply-To: <20160110170143.11899@web003.roc2.bluetie.com> References: <20160110170143.11899@web003.roc2.bluetie.com> Message-ID: <56938FB2.9030308@digitalbrains.com> Hi! > Do I have to sign it? Is there no way to configure gpg locally to > say "the info in this key (fingerprint) is accurate", without having > to sign? You have to sign it; that's how it works :). > Is the semantics of signing with lsign or sign "the info in this key > is accurate"? Yes. "The info" is contained in a UID, and you separately sign any UID's you've verified. A signature done with lsign will not be exported to others (unless you force GnuPG to do so), so you use it if you want the fact that you verified it to only be known to yourself. A regular "sign" command marks it exportable. > Is this separate from the "trust" thing, which is for trusting this > key to certify others? Yes, exactly. I can see you've read documentation! People always get confused by ownertrust and validity; you've got it right in one go. Since "trust" is such a broad concept, I always try to refer to it as "ownertrust", to narrow it down to the specifics. > When I had first signed an imported key, it > showed "trust: unknown". But when I did "trust", then "1 = I don't > know or won't say", it showed "trust: undefined". What is the > difference between these two values? It makes no difference with regard to validity calculations. It's just for your own information. The former would imply you still need to assess the trust, where the latter means you assessed it and still don't know, or won't say. There's a command to set the trust for all keys for which it hasn't been set yet; this command would skip "undefined" but ask you about "unknown". > Am I right in thinking it's the "validity" field which is affected by > "sign"? Yes. > Why is this not updated at all until the program is restarted? My guess is that it's because it's quite an intensive calculation, and you don't want to have that slowing down your interaction with the program in this run. Any change of trust or validity requires re-calculating all validity values for keys, since a newly valid, trusted key may in turn make other keys valid, which in turn... Obviously, it would be possible to recalculate only the affected part, but that's not how it's implemented: it will recalculate everything. > Keeping the model of one having to save one's changes, couldn't the > program display "validity: unknown (unsaved: full)" or somesuch, thus > showing the user what change has been performed by their action? It would technically be possible. But I don't think it would be high on a TODO list :). 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 dgouttegattat at incenp.org Mon Jan 11 12:24:09 2016 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Mon, 11 Jan 2016 12:24:09 +0100 Subject: basic identity mgmt In-Reply-To: <20160110170143.11899@web003.roc2.bluetie.com> References: <20160110170143.11899@web003.roc2.bluetie.com> Message-ID: <569390D9.3010006@incenp.org> On 01/10/2016 11:01 PM, Full Name wrote: > Do I have to sign it? Is there no way to configure gpg locally to > say "the info in this key (fingerprint) is accurate", without having > to sign? If you are using the default trust model ("pgp"), no. In this model, the validity of a key is only determined by its signatures. If you are using GnuPG 2.1.10, you could have a look at the "tofu" or "tofu+pgp" trust models, which allow you to do something like this: gpg2 --tofu-policy good 0xKEYID to say that the specified key is fully valid. > Is the semantics of signing with lsign or sign "the info in this key > is accurate"? Yes. "Signing" (or, more accurately, "certifying") a key roughly means "I certify that this public key belongs to the person correctly identified in the User ID". > Is this separate from the "trust" thing, which is for trusting this > key to certify others? This is completely separate. Unfortunately, the word or verb "trust" is sometimes used to refer to the *validity* of a key (as in the sentence "I *trust* that this key belongs to the person specified in the User ID"). > When I had first signed an imported key, it showed "trust: unknown". > But when I did "trust", then "1 = I don't know or won't say", it > showed "trust: undefined". What is the difference between these two > values? "Unknown" means that no trust has yet been explicitly assigned to the key; "undefined" means you explicitly said that you didn't know how much to trust the key. Both values imply that any certification emitted by this key will be ignored. > Am I right in thinking it's the "validity" field which is affected by > "sign"? Yes. In the "classic" or "pgp" trust models, the validity of a key is calculated by looking at the certifications carried by that key. By signing the key, you add to it a certification emitted by your own key; since your key has ultimate trust, that certification is enough to fully validate the target key. Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From fulanoperez at cryptolab.net Mon Jan 11 15:23:11 2016 From: fulanoperez at cryptolab.net (Fulano Diego Perez) Date: Tue, 12 Jan 2016 01:23:11 +1100 Subject: compile 2.1.10 with libgcrypt 1.7.0-beta300 Message-ID: <5693BACF.5070005@cryptolab.net> Can anybody confirm on debian stretch 64 a successful build with libgcrypt beta ? checking for LIBGCRYPT - version >= 1.6.0... yes (1.7.0-beta300) checking LIBGCRYPT API version... okay i cannot create curve25519 encryption sub keys gpg: agent_genkey failed: Invalid flag gpg: Key generation failed: Invalid flag but i could create NIST and Brainpool enc sub keys something's not right... still using 1.6.4 according to --version any ideas how i could further troubleshoot ? FYI for debian stretch - libgcrypt beta needed manual install of transfig package that includes fig2dev From dougb at dougbarton.email Mon Jan 11 17:23:52 2016 From: dougb at dougbarton.email (Doug Barton) Date: Mon, 11 Jan 2016 08:23:52 -0800 Subject: basic identity mgmt In-Reply-To: <20160110170143.11899@web003.roc2.bluetie.com> References: <20160110170143.11899@web003.roc2.bluetie.com> Message-ID: <5693D718.7070309@dougbarton.email> On 01/10/2016 02:01 PM, Full Name wrote: > Do I have to sign it? Is there no way to configure gpg locally to > say "the info in this key (fingerprint) is accurate", without having > to sign? > > Is the semantics of signing with lsign or sign "the info in this key > is accurate"? You've already received good answers on your questions, so some questions for you. :) What is your concern about signing the key? And are you aware that local signatures will not be communicated beyond your keyring? Doug From lachlan at twopif.net Mon Jan 11 17:35:42 2016 From: lachlan at twopif.net (Lachlan Gunn) Date: Mon, 11 Jan 2016 17:35:42 +0100 Subject: basic identity mgmt In-Reply-To: <5693D718.7070309@dougbarton.email> References: <20160110170143.11899@web003.roc2.bluetie.com> <5693D718.7070309@dougbarton.email> Message-ID: > > >> You've already received good answers on your questions, so some questions > for you. :) What is your concern about signing the key? And are you aware > that local signatures will not be communicated beyond your keyring? I actually ran into this issue the other day. For me it's problematic because my certification key is on an offline machine, so it's inconvenient to have to power it up and do a round-trip through the airgap when I'm not going to propagate the signature anyway. It's not a dealbreaker but it's still a bit irritating. Thanks, Lachlan -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin-gnupg-users at dkyb.de Mon Jan 11 18:06:51 2016 From: martin-gnupg-users at dkyb.de (Martin Behrendt) Date: Mon, 11 Jan 2016 18:06:51 +0100 Subject: basic identity mgmt In-Reply-To: References: <20160110170143.11899@web003.roc2.bluetie.com> <5693D718.7070309@dougbarton.email> Message-ID: <5693E12B.7040406@dkyb.de> Am 11.01.2016 um 17:35 schrieb Lachlan Gunn: >> >> >>> You've already received good answers on your questions, so some questions >> for you. :) What is your concern about signing the key? And are you aware >> that local signatures will not be communicated beyond your keyring? > > > I actually ran into this issue the other day. For me it's problematic > because my certification key is on an offline machine, so it's inconvenient > to have to power it up and do a round-trip through the airgap when I'm not > going to propagate the signature anyway. It's not a dealbreaker but it's > still a bit irritating. > > Thanks, > Lachlan > Without thinking a lot about it on my part, but wouldn't a separate signing sub-key help with this? Greetings Martin From stebe at mailbox.org Mon Jan 11 18:41:44 2016 From: stebe at mailbox.org (stebe at mailbox.org) Date: Mon, 11 Jan 2016 18:41:44 +0100 (CET) Subject: Problem while installing NitrokeyPro's App Message-ID: <1226309814.11404.d7a1f161-8283-45b3-a435-6d4a1aca2bb2.open-xchange@office.mailbox.org> Hi GnuPG users, (sorry for this long posting) I'm about to create a new key using NitrokeyPro and its app but I have some problems with installing the app. I am not sure if this is more a Nitrokey or a Debian issue. I'm using Debian oldstable (7.9.) 32 bits on a 64 bit processor and a 64 bit kernel. The app is only available as a 64 bit version for jessieamd64. I first considered compiling a 32 bit version for my needs, but then I accidentally learned (1) that the i386 version of i386 has a (basic) support for running 64bit third-party binaries. At least in (1) it is indicated that there is such a "minmilastic runtime support". sudo dpkg -i nitrokey-app-0.2-debian-jessie-amd64.deb && apt-get install -f resulted in (original in German; configuration failed due to dependency issues) Entpacken von nitrokey-app (aus nitrokey-app-0.2-debian-jessie-amd64.deb) ... dpkg: Abh?ngigkeitsprobleme verhindern Konfiguration von nitrokey-app: nitrokey-app h?ngt ab von libappindicator1. nitrokey-app h?ngt ab von libnotify4. nitrokey-app h?ngt ab von libqt5widgets5. nitrokey-app h?ngt ab von libqt5gui5. nitrokey-app h?ngt ab von libqt5core5a. So I updated my sources.list with wheezy-backports, eager to install the lacking dependencies libqt5widgets5, libqt5gui5, libqt5core5a from there, but that did not help. libappindicator1 and libnotify4 were already installed on my oldstable system, but the app, as one can see in the output above, ignored them, i.e. maybe needs another version (I installed all these 5 dependencies first as 32 bits, thinking that if the 64 bit app accepted all the other 32 bit stuff it now will only need the 32 bit version of them. I was still thinking that the referred i386 support for 64bit 3rd party binaries could be enabled by this. I ran sudo dpkg -i nitrokey-app-0.2-debian-jessie-amd64.deb && apt-get install -f again, but again (original in German) Entpacken von nitrokey-app (aus nitrokey-app-0.2-debian-jessie-amd64.deb) ... dpkg: Abh?ngigkeitsprobleme verhindern Konfiguration von nitrokey-app: nitrokey-app h?ngt ab von libappindicator1. nitrokey-app h?ngt ab von libnotify4. nitrokey-app h?ngt ab von libqt5widgets5. nitrokey-app h?ngt ab von libqt5gui5. nitrokey-app h?ngt ab von libqt5core5a. In a desperate attempt to solve the issue :-) I did a dpkg --add-architecture amd64 to do the best possible to have the dependencies installed, if not in a 32 bit version (ignored by the app), using the 64 bit versions in backports and oldstable, respectively: this damned app should run with it, I thought! But then there were even more dependency issues, requiring me to install even more 64 bit packages to solve even more dependency problems. I told apt to resolve the dependency issues (even if it had to install all that bunch of 64 bit versions of the dependencies of the app's dependencies) but apt's output was that it was not possible to get the dep. issues resolved. :-( Any ideas how to solve this within 32 bit oldstable? Is it better to post it on a Debian specific forum/mailing list? Or to upgrade right away to 64 bit jessie using apt --dist-upgrade? Any ideas welcome. Cheers, Stebe (1) https://www.debian.org/ports/amd64/index.en.html From peter at digitalbrains.com Mon Jan 11 21:42:21 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 11 Jan 2016 21:42:21 +0100 Subject: basic identity mgmt In-Reply-To: <5693E12B.7040406@dkyb.de> References: <20160110170143.11899@web003.roc2.bluetie.com> <5693D718.7070309@dougbarton.email> <5693E12B.7040406@dkyb.de> Message-ID: <569413AD.4080304@digitalbrains.com> On 11/01/16 18:06, Martin Behrendt wrote: > Without thinking a lot about it on my part, but wouldn't a separate > signing sub-key help with this? Signing other people's keys is called certifying, and certification is a capability only the primary key has. The "Sign" capability indicates it can create data signatures: files, e-mails, that kind of thing. 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 Mon Jan 11 21:46:54 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 11 Jan 2016 21:46:54 +0100 Subject: basic identity mgmt In-Reply-To: References: <20160110170143.11899@web003.roc2.bluetie.com> <5693D718.7070309@dougbarton.email> Message-ID: <569414BE.2040801@digitalbrains.com> On 11/01/16 17:35, Lachlan Gunn wrote: > I actually ran into this issue the other day. For me it's problematic because > my certification key is on an offline machine, so it's inconvenient to have to > power it up and do a round-trip through the airgap when I'm not going to > propagate the signature anyway. You can only do an uncommon all-or-nothing change: with --trust-model direct, you can set key validity directly, just like ownertrust in most other models, but this means the Web of Trust and certification signatures are completely unused, AFAIK. I'm not recommending either for or against it, I'm just throwing it out there as an available option. This apart from the already mentioned tofu+pgp. 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 gniibe at fsij.org Tue Jan 12 01:53:44 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 12 Jan 2016 09:53:44 +0900 Subject: compile 2.1.10 with libgcrypt 1.7.0-beta300 In-Reply-To: <5693BACF.5070005@cryptolab.net> References: <5693BACF.5070005@cryptolab.net> Message-ID: <56944E98.5000307@fsij.org> On 01/11/2016 11:23 PM, Fulano Diego Perez wrote: > Can anybody confirm on debian stretch 64 a successful build with > libgcrypt beta ? GnuGP and libgcrypt development version build successfully on my 32-bit ARMv7l. > checking for LIBGCRYPT - version >= 1.6.0... yes (1.7.0-beta300) > checking LIBGCRYPT API version... okay Good, you have the libgcrypt development version installed. > i cannot create curve25519 encryption sub keys > > gpg: agent_genkey failed: Invalid flag > gpg: Key generation failed: Invalid flag > > but i could create NIST and Brainpool enc sub keys > > something's not right... > > still using 1.6.4 according to --version How do you install the libgcrypt on your system? If it's /usr/local/lib, you would need LD_LIBRARY_PATH setting. $ export LD_LIBRARY_PATH=/usr/local/lib For me, with LD_LIBRARY_PATH, it goes: $ gpg2 --version gpg (GnuPG) 2.1.11-beta67 libgcrypt 1.7.0-beta298 NOTE: THIS IS A DEVELOPMENT VERSION! It is only intended for test purposes and should NOT be used in a production environment or with production keys! Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 Please note that you need to invoke gpg-agent with LD_LIBRARY_PATH, too. -- From gniibe at fsij.org Tue Jan 12 02:11:09 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 12 Jan 2016 10:11:09 +0900 Subject: compile 2.1.10 no bzip2 ? In-Reply-To: <56936D64.1070102@cryptolab.net> References: <56936D64.1070102@cryptolab.net> Message-ID: <569452AD.9030007@fsij.org> On 01/11/2016 05:52 PM, Fulano Diego Perez wrote: > This must be something simple I'm missing but on a debian stretch 64 > machine i cannot get gpg 2.1.10 compiled with bzip2 support which > prevents me from reading bzip2 compressed files - they can decrypt but: [...] > ENABLE_BZIP2_SUPPORT_FALSE='' > ENABLE_BZIP2_SUPPORT_TRUE='#' It seems for me that you don't have libbz2-dev package installed. $ sudo apt-get install libbz2-dev ? -- From felix.klee at inka.de Tue Jan 12 11:03:37 2016 From: felix.klee at inka.de (Felix E. Klee) Date: Tue, 12 Jan 2016 11:03:37 +0100 Subject: =?UTF-8?Q?Re=3A_Generating_4096_bit_key_fails_=E2=80=93_why=3F?= In-Reply-To: References: <87oafk9iqh.fsf@vigenere.g10code.de> <5636C4B3.5050905@fsij.org> <563968E9.6050604@fsij.org> Message-ID: After the second attempt with GnuPG 2.1.10, I got all three 4096 bit keys generated on card, which took a while: > admin [?] > generate [?] gpg: key 28C1B3D1 marked as ultimately trusted public and secret key created and signed. gpg: checking the trustdb gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 2 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 2u gpg: next trustdb check due at 2017-10-30 Following initialization, I could finally import the backup of my 4096 bit keys. :-D From jacques.kotze at gmail.com Tue Jan 12 12:58:57 2016 From: jacques.kotze at gmail.com (Jacques Kotze) Date: Tue, 12 Jan 2016 11:58:57 +0000 Subject: GPG-Agent not recognising SSH keys Message-ID: Hi All, First time post, so please excuse me if it is a ignorant noob question :) I am using gpg-agent (GnuPG) 2.1.9 with libgcrypt 1.6.4 on a Mac OS 10.10. I have created a pgp subkey that is intended for use as an ssh key. This subkey's keygrip has been added to $> ~/.gnupgp/sshcontrol I would assume that this would then allow the pgp subkey to be added as a ssh key automatically that I can use... but when I run $> ssh-add -L The agent has no identities. I expected it to output the Public Key intended for ssh use (and keygrip listed in sshcontrol) I first suspected that gpp-agent wasn't thus running properly or something else was amiss. Here is what I checked: $> echo $SSH_AUTH_SOCK /private/tmp/com.apple.launchd.gTFZghO8E7/Listeners Looks fine.. how about killing everything and starting it again: $> unset GPG_AGENT_INFO SSH_AGENT_PID SSH_AUTH_SOCK $> eval $(/usr/local/MacGPG2/bin/gpg-agent --daemon --enable-ssh-support) Lets check that I always enable ssh support on gpg-agent: $> cat ~/.gnupg/gpg-agent.conf enable-ssh-support Ok.. so I am stumped. Any help appreciated :) Regards Jacques -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at digitalbrains.com Tue Jan 12 19:37:52 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 12 Jan 2016 19:37:52 +0100 Subject: GPG-Agent not recognising SSH keys In-Reply-To: References: Message-ID: <56954800.9000507@digitalbrains.com> On 12/01/16 12:58, Jacques Kotze wrote: > Hi All, Hi, > First time post, so please excuse me if it is a ignorant noob question :) It's not an ignorant question, and even if it were, that wouldn't be a problem :). > $> unset GPG_AGENT_INFO SSH_AGENT_PID SSH_AUTH_SOCK > $> eval $(/usr/local/MacGPG2/bin/gpg-agent --daemon --enable-ssh-support) Which version of GnuPG are you using, by the way? > Ok.. so I am stumped. Any help appreciated :) Did it go something like this? I'm "quoting" the terminal interaction and writing comments in between. You can see I'm using GnuPG 2.1, but I think it should go the same for 2.0. There /is/ a difference with regard to the agent configuration, though, which is why I ask about your version above. > $ gpg2 --expert --edit-key DCDFDFA4 > gpg (GnuPG) 2.1.10; Copyright (C) 2015 Free Software Foundation, Inc. > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > > Secret key is available. > > sec rsa1024/DCDFDFA4 > created: 2012-03-17 expires: 2016-01-13 usage: SC > trust: never validity: unknown > ssb rsa1024/77A3395A > created: 2012-03-17 expires: never usage: E > [ unknown] (1). Test Teststra (Koning van Wezel) > [ unknown] (2) Test Teststra This is a testkey. It doesn't have an authentication capable subkey yet, so let's add one (for that, we need --expert, hence my use of it). > gpg> addkey > Please select what kind of key you want: > (3) DSA (sign only) > (4) RSA (sign only) > (5) Elgamal (encrypt only) > (6) RSA (encrypt only) > (7) DSA (set your own capabilities) > (8) RSA (set your own capabilities) > (10) ECC (sign only) > (11) ECC (set your own capabilities) > (12) ECC (encrypt only) > (13) Existing key > Your selection? 8 > > Possible actions for a RSA key: Sign Encrypt Authenticate > Current allowed actions: Sign Encrypt > > (S) Toggle the sign capability > (E) Toggle the encrypt capability > (A) Toggle the authenticate capability > (Q) Finished > > Your selection? =a I just noticed this possibility in a recent post by Werner to this list... I don't know if it's a new 2.1 feature, but instead of first toggling S and E, you can prepend an = to your A and presto, the key is for A only. > RSA keys may be between 1024 and 4096 bits long. > What keysize do you want? (2048) > Requested keysize is 2048 bits > Please specify how long the key should be valid. > 0 = key does not expire > = key expires in n days > w = key expires in n weeks > m = key expires in n months > y = key expires in n years > Key is valid for? (0) > Key does not expire at all > Is this correct? (y/N) y > Really create? (y/N) y > We need to generate a lot of random bytes. It is a good idea to perform > some other action (type on the keyboard, move the mouse, utilize the > disks) during the prime generation; this gives the random number > generator a better chance to gain enough entropy. > > sec rsa1024/DCDFDFA4 > created: 2012-03-17 expires: 2016-01-13 usage: SC > trust: never validity: unknown > ssb rsa1024/77A3395A > created: 2012-03-17 expires: never usage: E > ssb rsa2048/38EF7410 > created: 2016-01-12 expires: never usage: A > [ unknown] (1). Test Teststra (Koning van Wezel) > [ unknown] (2) Test Teststra > > gpg> Save changes? (y/N) y So now we need the keygrip for this new authentication subkey: > $ gpg2 --with-keygrip -k DCDFDFA4 > pub rsa1024/DCDFDFA4 2012-03-17 [expires: 2016-01-13] > Keygrip = 2F677680CA15F6F7B963AF35822E8EC01FBF840A > uid [ unknown] Test Teststra (Koning van Wezel) > uid [ unknown] Test Teststra > sub rsa1024/77A3395A 2012-03-17 > Keygrip = 15CB764B81D542CF921978CA89910C69D53F4E2D > sub rsa2048/38EF7410 2016-01-12 > Keygrip = 3D88DC9D60F791821AF8D537EEAC3C8DF7720D63 The keygrip /follows/ the line with the short key ID; we need the keygrip for the key with ID 38EF7410, so it's the very last line. The other keygrips are for keys that don't have the authentication capability and are hence useless to add to sshcontrol. I used a screen editor, but let's pretend I used the command line... In fact, all further lines have been edited to hide my real SSH keys. It's probably overkill, but let's be cautious with what we broadcast on the internet. > $ cd .gnupg > $ echo '3D88DC9D60F791821AF8D537EEAC3C8DF7720D63 0' >>sshcontrol > $ cat .gnupg/sshcontrol > # List of allowed ssh keys. Only keys present in this file are used > # in the SSH protocol. The ssh-add tool may add new entries to this > # file to enable them; you may also add them manually. Comment > # lines, like this one, as well as empty lines are ignored. Lines do > # have a certain length limit but this is not serious limitation as > # the format of the entries is fixed and checked by gpg-agent. A > # non-comment line starts with optional white spaces, followed by the > # keygrip of the key given as 40 hex digits, optionally followed by a > # the caching TTL in seconds and another optional field for arbitrary > # flags. Prepend the keygrip with an '!' mark to disable it. > > 3D88DC9D60F791821AF8D537EEAC3C8DF7720D63 0 Now let's see if it's known: > $ ssh-add -L > ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC9V1hmvs5Gg8OqmtHDXfIAKA5Ji0z0+ib5m7DRjX/KXXZvOtwR8QOvsFxffJsXpmp1m7nL/gw+EcjbMDAbo+X05UWKiMwyVdinbnaupFDtk7Z+KBEAYLsvUml23jiBzitLbURC7wFrMTFPVzGY/5ZHw0LaWjSPuQxltjPTnMUcL4F4eyDD2TkmsxmAgNy5xMAjHmGdEaBnFent2hBTMETyeWKlP6glKT67eL2SQn5viHSXK6nVlXsyYsJBIhSPjAagPv1qRtkhinSJaKDUGWZ0vxMpNHscjG4DreWKlzew5UQcBBKleYPl7mSf1Z8UJnwLnYdC0OhjC1dMfyitByhV (none) \o/ If you did it just like this, there's an issue in your setup, as it works for me. If you didn't do it like this, ... you probably should ;P. 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 jacques.kotze at gmail.com Thu Jan 14 14:48:33 2016 From: jacques.kotze at gmail.com (Jacques Kotze) Date: Thu, 14 Jan 2016 13:48:33 +0000 Subject: GPG-Agent not recognising SSH keys In-Reply-To: <56954800.9000507@digitalbrains.com> References: <56954800.9000507@digitalbrains.com> Message-ID: Hi Peter Thanks for your comments and help. Your guide highlighted a silly error where I had accidentally chopped some of the trailing characters of the appropriate keygrip in sshcontrol (Doh!). BTW I am using GnuPG 2.1.9 I can now successfully get the response to ssh-add -L as expected. Great! I do have a problem with this setup still not working as expected i.e. I have the exported pub key (from ssh-add -L) copied to the external servers ~/.ssh/authorized_keys.. but still being prompted for a user password upon ssh'ing to the server. Anything there I am perhaps missing? Kind regards Jacques On 12 January 2016 at 18:37, Peter Lebbing wrote: > On 12/01/16 12:58, Jacques Kotze wrote: > > Hi All, > > Hi, > > > First time post, so please excuse me if it is a ignorant noob question :) > > It's not an ignorant question, and even if it were, that wouldn't be a > problem :). > > > $> unset GPG_AGENT_INFO SSH_AGENT_PID SSH_AUTH_SOCK > > $> eval $(/usr/local/MacGPG2/bin/gpg-agent --daemon --enable-ssh-support) > > Which version of GnuPG are you using, by the way? > > > Ok.. so I am stumped. Any help appreciated :) > > Did it go something like this? > > I'm "quoting" the terminal interaction and writing comments in between. > You can see I'm using GnuPG 2.1, but I think it should go the same for > 2.0. There /is/ a difference with regard to the agent configuration, > though, which is why I ask about your version above. > > > $ gpg2 --expert --edit-key DCDFDFA4 > > gpg (GnuPG) 2.1.10; Copyright (C) 2015 Free Software Foundation, Inc. > > This is free software: you are free to change and redistribute it. > > There is NO WARRANTY, to the extent permitted by law. > > > > Secret key is available. > > > > sec rsa1024/DCDFDFA4 > > created: 2012-03-17 expires: 2016-01-13 usage: SC > > trust: never validity: unknown > > ssb rsa1024/77A3395A > > created: 2012-03-17 expires: never usage: E > > [ unknown] (1). Test Teststra (Koning van Wezel) > > [ unknown] (2) Test Teststra > > This is a testkey. It doesn't have an authentication capable subkey yet, > so let's add one (for that, we need --expert, hence my use of it). > > > gpg> addkey > > Please select what kind of key you want: > > (3) DSA (sign only) > > (4) RSA (sign only) > > (5) Elgamal (encrypt only) > > (6) RSA (encrypt only) > > (7) DSA (set your own capabilities) > > (8) RSA (set your own capabilities) > > (10) ECC (sign only) > > (11) ECC (set your own capabilities) > > (12) ECC (encrypt only) > > (13) Existing key > > Your selection? 8 > > > > Possible actions for a RSA key: Sign Encrypt Authenticate > > Current allowed actions: Sign Encrypt > > > > (S) Toggle the sign capability > > (E) Toggle the encrypt capability > > (A) Toggle the authenticate capability > > (Q) Finished > > > > Your selection? =a > > I just noticed this possibility in a recent post by Werner to this > list... I don't know if it's a new 2.1 feature, but instead of first > toggling S and E, you can prepend an = to your A and presto, the key is > for A only. > > > RSA keys may be between 1024 and 4096 bits long. > > What keysize do you want? (2048) > > Requested keysize is 2048 bits > > Please specify how long the key should be valid. > > 0 = key does not expire > > = key expires in n days > > w = key expires in n weeks > > m = key expires in n months > > y = key expires in n years > > Key is valid for? (0) > > Key does not expire at all > > Is this correct? (y/N) y > > Really create? (y/N) y > > We need to generate a lot of random bytes. It is a good idea to perform > > some other action (type on the keyboard, move the mouse, utilize the > > disks) during the prime generation; this gives the random number > > generator a better chance to gain enough entropy. > > > > sec rsa1024/DCDFDFA4 > > created: 2012-03-17 expires: 2016-01-13 usage: SC > > trust: never validity: unknown > > ssb rsa1024/77A3395A > > created: 2012-03-17 expires: never usage: E > > ssb rsa2048/38EF7410 > > created: 2016-01-12 expires: never usage: A > > [ unknown] (1). Test Teststra (Koning van Wezel) > > [ unknown] (2) Test Teststra > > > > gpg> Save changes? (y/N) y > > So now we need the keygrip for this new authentication subkey: > > > $ gpg2 --with-keygrip -k DCDFDFA4 > > pub rsa1024/DCDFDFA4 2012-03-17 [expires: 2016-01-13] > > Keygrip = 2F677680CA15F6F7B963AF35822E8EC01FBF840A > > uid [ unknown] Test Teststra (Koning van Wezel) > > > uid [ unknown] Test Teststra > > sub rsa1024/77A3395A 2012-03-17 > > Keygrip = 15CB764B81D542CF921978CA89910C69D53F4E2D > > sub rsa2048/38EF7410 2016-01-12 > > Keygrip = 3D88DC9D60F791821AF8D537EEAC3C8DF7720D63 > > The keygrip /follows/ the line with the short key ID; we need the > keygrip for the key with ID 38EF7410, so it's the very last line. The > other keygrips are for keys that don't have the authentication > capability and are hence useless to add to sshcontrol. > > I used a screen editor, but let's pretend I used the command line... In > fact, all further lines have been edited to hide my real SSH keys. It's > probably overkill, but let's be cautious with what we broadcast on the > internet. > > > $ cd .gnupg > > $ echo '3D88DC9D60F791821AF8D537EEAC3C8DF7720D63 0' >>sshcontrol > > $ cat .gnupg/sshcontrol > > # List of allowed ssh keys. Only keys present in this file are used > > # in the SSH protocol. The ssh-add tool may add new entries to this > > # file to enable them; you may also add them manually. Comment > > # lines, like this one, as well as empty lines are ignored. Lines do > > # have a certain length limit but this is not serious limitation as > > # the format of the entries is fixed and checked by gpg-agent. A > > # non-comment line starts with optional white spaces, followed by the > > # keygrip of the key given as 40 hex digits, optionally followed by a > > # the caching TTL in seconds and another optional field for arbitrary > > # flags. Prepend the keygrip with an '!' mark to disable it. > > > > 3D88DC9D60F791821AF8D537EEAC3C8DF7720D63 0 > > Now let's see if it's known: > > > $ ssh-add -L > > ssh-rsa > AAAAB3NzaC1yc2EAAAADAQABAAABAQC9V1hmvs5Gg8OqmtHDXfIAKA5Ji0z0+ib5m7DRjX/KXXZvOtwR8QOvsFxffJsXpmp1m7nL/gw+EcjbMDAbo+X05UWKiMwyVdinbnaupFDtk7Z+KBEAYLsvUml23jiBzitLbURC7wFrMTFPVzGY/5ZHw0LaWjSPuQxltjPTnMUcL4F4eyDD2TkmsxmAgNy5xMAjHmGdEaBnFent2hBTMETyeWKlP6glKT67eL2SQn5viHSXK6nVlXsyYsJBIhSPjAagPv1qRtkhinSJaKDUGWZ0vxMpNHscjG4DreWKlzew5UQcBBKleYPl7mSf1Z8UJnwLnYdC0OhjC1dMfyitByhV > (none) > > \o/ > > If you did it just like this, there's an issue in your setup, as it > works for me. If you didn't do it like this, ... you probably should ;P. > > HTH, > > Peter. > > -- > I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. > You can send me encrypted mail if you want some privacy. > My key is available at > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at digitalbrains.com Thu Jan 14 15:58:15 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 14 Jan 2016 15:58:15 +0100 Subject: GPG-Agent not recognising SSH keys In-Reply-To: References: <56954800.9000507@digitalbrains.com> Message-ID: <4662a58df6d9e150cbb3611a33291c4a@butters.digitalbrains.com> Hi Jacques, > Your guide highlighted a silly error where I had accidentally chopped > some of the trailing characters of the appropriate keygrip in > sshcontrol (Doh!). BTW I am using GnuPG 2.1.9 That's hard to spot... "Is this jumble of characters the same as the one I just saw?" > I can now successfully get the response to ssh-add -L as expected. > Great! Yep! > Anything there I am perhaps missing? Is the server and the user account configured to accept authorized keys? Are the permissions on ~/.ssh acceptable? Do you have administrative access to a server in question? The configuration for sshd can configure different authentication possibilities to be offered, even per-user (or per-IP range). But perhaps more likely is that ~/.ssh doesn't have the correct permissions. If you have access to sshd's log: it will likely complain verbally in the log about permission errors, even though you as a client don't see it. From the sshd manpage: > ~/.ssh/authorized_keys > Lists the public keys (DSA, ECDSA, ED25519, RSA) that can be used > for logging in as this user. The format of this file is > described above. The content of the file is not highly sensi? > tive, but the recommended permissions are read/write for the > user, and not accessible by others. > > If this file, the ~/.ssh directory, or the user's home directory > are writable by other users, then the file could be modified or > replaced by unauthorized users. In this case, sshd will not > allow it to be used unless the StrictModes option has been set to > ?no?. A good permission for ~/.ssh is 700. authorized_keys can be 755 or less[1]. From the way the manpage is phrased, one would think one's home directory can't be 775, even though that actually might make sense in some setups. But if you don't want to be able to appoint people with write permission, keep it on 755 or less. I think 755 is quite common; 750, 710 and 700 make sense as well. HTH, Peter. [1] Less permissions, not numerically less. Don't go saying "677 is less"! :) -- 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 lachlan at twopif.net Thu Jan 14 17:03:54 2016 From: lachlan at twopif.net (Lachlan Gunn) Date: Thu, 14 Jan 2016 17:03:54 +0100 Subject: Key selection order Message-ID: Hello, Through my searches online and looking at g10/getkey.c, it seems that when multiple keys exist with the same name/email/etc., gpg will use the first one that it finds in the database. Is this correct? If so, suppose an attacker inserted a fake key with my details into an HKP keyserver. What should I do? Keys could be returned in any order, and HKP gives no indication of when they were last updated, so the client can't separate them that way. Is there an obvious way to deal with this that I'm missing, or once a false key is uploaded is it game-over, and I just have to hope that people will be able to work out which is which through other means? Apologies if this is covered in the documentation and I have failed to find it in my reading. Thanks, Lachlan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Thu Jan 14 17:27:40 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 14 Jan 2016 11:27:40 -0500 Subject: Key selection order In-Reply-To: References: Message-ID: <5697CC7C.7040603@sixdemonbag.org> > If so, suppose an attacker inserted a fake key with my details into an > HKP keyserver. What should I do? First, recognize that this has likely already happened, and the world hasn't ended. :) Look at how many certificates there are for president at whitehouse.gov, for instance. > Is there an obvious way to deal with this that I'm missing Fingerprint verification. An attacker can create a fraudulent certificate, but an attacker cannot (to the best of our knowledge) create a certificate that has an identical fingerprint to the real one. And if you're concerned about this, then retrieve certificates based on fingerprints, not on email addresses. From lachlan at twopif.net Thu Jan 14 17:58:22 2016 From: lachlan at twopif.net (Lachlan Gunn) Date: Thu, 14 Jan 2016 17:58:22 +0100 Subject: Key selection order In-Reply-To: <5697CC7C.7040603@sixdemonbag.org> References: <5697CC7C.7040603@sixdemonbag.org> Message-ID: Le 14 janv. 2016 17:30, "Robert J. Hansen" a ?crit : > Fingerprint verification. An attacker can create a fraudulent > certificate, but an attacker cannot (to the best of our knowledge) > create a certificate that has an identical fingerprint to the real one. Yes, of course. I'm just wondering whether there's anything that I can do to increase the probability that a user who looks me up and emails me out of nowhere will get the right key. > And if you're concerned about this, then retrieve certificates based on > fingerprints, not on email addresses. This breaks the "look up key and then just use ToFU" workflow though, which is what I was more worried about. You can't _guarantee_ that other users will receive the same key, but it would be nice if there were some possibility that a long-ago added key without an expiry date wouldn't be at risk of being automatically chosen until the end of time. Thanks, Lachlan -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrewg at andrewg.com Thu Jan 14 18:04:07 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 14 Jan 2016 17:04:07 +0000 Subject: Key selection order In-Reply-To: References: <5697CC7C.7040603@sixdemonbag.org> Message-ID: <5697D507.6020501@andrewg.com> On 14/01/16 16:58, Lachlan Gunn wrote: > > This breaks the "look up key and then just use ToFU" workflow though ... which is why you should never use ToFU. There is no known method of secure communication that does not involve out of band verification. A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Thu Jan 14 19:09:20 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 14 Jan 2016 13:09:20 -0500 Subject: Key selection order In-Reply-To: References: <5697CC7C.7040603@sixdemonbag.org> Message-ID: <5697E450.50003@sixdemonbag.org> > Yes, of course. I'm just wondering whether there's anything that I can > do to increase the probability that a user who looks me up and emails me > out of nowhere will get the right key. Tell them to look you up by fingerprint. Problem solved. > This breaks the "look up key and then just use ToFU" workflow... No, it breaks up the "grab a random certificate that claims to be mine and just use it" workflow, which is stupid, and isn't even what the TOFU advocates suggest. TOFU is built on trusting certificates that are used in received mail. If you receive a mail signed by 0xB44427C7, TOFU says "you should probably trust this is from rjh at sixdemonbag.org." But if you don't already have the certificate, and you're looking for it on a keyserver, TOFU says "you should really pull it down by long key ID or fingerprint." From lachlan at twopif.net Thu Jan 14 19:48:29 2016 From: lachlan at twopif.net (Lachlan Gunn) Date: Thu, 14 Jan 2016 19:48:29 +0100 Subject: Key selection order In-Reply-To: <5697E450.50003@sixdemonbag.org> References: <5697CC7C.7040603@sixdemonbag.org> <5697E450.50003@sixdemonbag.org> Message-ID: Sure, but you have to bootstrap somehow. TOFU doesn't come into play until after you've received a response anyway, so unless you can find the key through some out-of-band source, then for the initial contact you have to choose between either making an educated guess as to what the key is, or sending in the clear. Even if the key ends up being wrong then at least there's only one potential attacker, and the game is up the moment you get an unmodified email from the real guy via mailing lists, forwarding, etc. I'm not saying that we should all just blindly accept whatever the keyservers say, I just wanted to know whether there was anything useful that one could do with the current infrastructure when they _knew_ that they were already under attack. Thanks, Lachlan 2016-01-14 19:09 GMT+01:00 Robert J. Hansen : > > Yes, of course. I'm just wondering whether there's anything that I can > > do to increase the probability that a user who looks me up and emails me > > out of nowhere will get the right key. > > Tell them to look you up by fingerprint. Problem solved. > > > This breaks the "look up key and then just use ToFU" workflow... > > No, it breaks up the "grab a random certificate that claims to be mine > and just use it" workflow, which is stupid, and isn't even what the TOFU > advocates suggest. > > TOFU is built on trusting certificates that are used in received mail. > If you receive a mail signed by 0xB44427C7, TOFU says "you should > probably trust this is from rjh at sixdemonbag.org." > > But if you don't already have the certificate, and you're looking for it > on a keyserver, TOFU says "you should really pull it down by long key ID > or fingerprint." > > _______________________________________________ > 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 peter at digitalbrains.com Thu Jan 14 19:59:50 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 14 Jan 2016 19:59:50 +0100 Subject: Key selection order In-Reply-To: References: <5697CC7C.7040603@sixdemonbag.org> <5697E450.50003@sixdemonbag.org> Message-ID: <5697F026.9050805@digitalbrains.com> On 14/01/16 19:48, Lachlan Gunn wrote: > so unless you can find the key through some out-of-band source, then for the > initial contact you have to choose between either making an educated guess as > to what the key is, or sending in the clear. Or send them an e-mail saying "I've got something to say I don't want in cleartext for passive attackers to read; could you send me your key ID?" > I just wanted to know whether there was anything useful that one could do > with the current infrastructure when they _knew_ that they were already > under attack. When you know the channel is being modified, you need an out-of-band something to bootstrap. I think this is fundamental, independent of infrastructure. But I'm too tired and hungry to think about it much :). Should eat... By the way, "under attack" is a too generic term to usefully discuss stuff. 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 ndk.clanbo at gmail.com Thu Jan 14 20:11:33 2016 From: ndk.clanbo at gmail.com (NdK) Date: Thu, 14 Jan 2016 20:11:33 +0100 Subject: Key selection order In-Reply-To: <5697D507.6020501@andrewg.com> References: <5697CC7C.7040603@sixdemonbag.org> <5697D507.6020501@andrewg.com> Message-ID: <5697F2E5.5060409@gmail.com> Il 14/01/2016 18:04, Andrew Gallagher ha scritto: > ... which is why you should never use ToFU. There is no known method of > secure communication that does not involve out of band verification. I disagree. TOFU is what many users do anyway: identity persistence is often more important than "real" identity... And harder to fake by any opponent (governments would have no problem creating "fake" identity cards, passports or anything -- after all that's what they usually do for "real" ones!). On the other hand, if you saw mails from a single address signed by the same identity for years, chances are that it's the same person, even if the name on the identity card is different. BYtE, Diego From rjh at sixdemonbag.org Thu Jan 14 20:37:47 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 14 Jan 2016 14:37:47 -0500 Subject: Key selection order In-Reply-To: References: <5697CC7C.7040603@sixdemonbag.org> <5697E450.50003@sixdemonbag.org> Message-ID: <5697F90B.4020909@sixdemonbag.org> > Sure, but you have to bootstrap somehow. That's when you ask your correspondent, "I need your certificate fingerprint, please." I don't see what the problem is. > I'm not saying that we should all just blindly accept whatever the > keyservers say, I just wanted to know whether there was anything useful > that one could do with the current infrastructure when they _knew_ that > they were already under attack. And you've been told! If you know you're being targeted by a malicious actor, stop using TOFU and fall back to fingerprint verification. Why are we still talking about this? From andrewg at andrewg.com Thu Jan 14 21:06:38 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 14 Jan 2016 20:06:38 +0000 Subject: Key selection order In-Reply-To: <5697F2E5.5060409@gmail.com> References: <5697CC7C.7040603@sixdemonbag.org> <5697D507.6020501@andrewg.com> <5697F2E5.5060409@gmail.com> Message-ID: <477F0326-6B69-47D6-84F2-0888EF21944D@andrewg.com> > On 14 Jan 2016, at 19:11, NdK wrote: > > Il 14/01/2016 18:04, Andrew Gallagher ha scritto: > >> ... which is why you should never use ToFU. There is no known method of >> secure communication that does not involve out of band verification. > I disagree. > TOFU is what many users do anyway: Granted. And it does provide a speed bump to a potential attacker, so is preferable to nothing. But it's not a long term solution. > identity persistence is often more > important than "real" identity... Tofu does not guarantee identity persistence. Just because your correspondence hasn't been obviously tampered with (yet) does not mean that someone hasn't been MITMing you all along and biding their time. A From wendyoberg at excite.com Thu Jan 14 20:35:39 2016 From: wendyoberg at excite.com (Wendy Oberg) Date: Thu, 14 Jan 2016 14:35:39 -0500 Subject: basic identity mgmt Message-ID: <20160114143539.11449@web005.roc2.bluetie.com> From: "Doug Barton" [dougb at dougbarton.email] > What is your concern about signing the key? Not so much a concern. But I might want to make use of the predicate "key X is valid" without having to sign anything, and without even having a key. Sounds like the "--tofu-policy good ..." in recent versions, as suggested by Damien, may do the trick for this. > And are you aware that local signatures will not be communicated beyond your > keyring? Yes, thanks, W. From peter at digitalbrains.com Thu Jan 14 22:26:19 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 14 Jan 2016 22:26:19 +0100 Subject: Key selection order In-Reply-To: <477F0326-6B69-47D6-84F2-0888EF21944D@andrewg.com> References: <5697CC7C.7040603@sixdemonbag.org> <5697D507.6020501@andrewg.com> <5697F2E5.5060409@gmail.com> <477F0326-6B69-47D6-84F2-0888EF21944D@andrewg.com> Message-ID: <89f6fb0a548fda8e19ccd0ae22a33161@butters.digitalbrains.com> On 2016-01-14 21:06, Andrew Gallagher wrote: > Granted. And it does provide a speed bump to a potential attacker, so > is preferable to nothing. But it's not a long term solution. I disagree. It's a "good enough" solution for many circumstances. And we know by now how well the WoT works in many circumstances. Both have their uses. But this has been discussed on the list multiple times. It's fine if you disagree; but please don't phrase your words as fact when it's such a contended issue. > Tofu does not guarantee identity persistence. Just because your > correspondence hasn't been obviously tampered with (yet) does not > mean > that someone hasn't been MITMing you all along and biding their time. Isn't "MITM'ing all along" identity persistence then? It's quite unfortunate it's the /wrong/ identity, but it's identity persistence in my book, so I think you're using the terminology wrongly. 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 ndk.clanbo at gmail.com Thu Jan 14 22:41:57 2016 From: ndk.clanbo at gmail.com (NdK) Date: Thu, 14 Jan 2016 22:41:57 +0100 Subject: Key selection order In-Reply-To: <477F0326-6B69-47D6-84F2-0888EF21944D@andrewg.com> References: <5697CC7C.7040603@sixdemonbag.org> <5697D507.6020501@andrewg.com> <5697F2E5.5060409@gmail.com> <477F0326-6B69-47D6-84F2-0888EF21944D@andrewg.com> Message-ID: <56981625.8030400@gmail.com> Il 14/01/2016 21:06, Andrew Gallagher ha scritto: > Tofu does not guarantee identity persistence. Just because your correspondence hasn't been obviously tampered with (yet) does not mean that someone hasn't been MITMing you all along and biding their time. As usual, it depends on your attack scenario. If I have 10-years-old mails from someone I've never met, and all use the same key, I can assume that either 1) that identity belongs to the same person or 2) that an attacker MITMed *all* my connections (from every device I've had wherever I was and to every service I used). Occam's razor and my "exposure profile" make me think it's 1) :) In other words, *time* can be considered an 'out of band' channel. For others, very "high profile", it could be possible that such an attack might be performed, even if it's quite unlikely, unless there's *a lot* of money involved. What I learnt from OpenAlarm is that there's always to balance cost and security: over a certain limit, costs grow exponentially for marginal gains in security. So the different options have to be weighted carefully: you'll have to make different choices if you have to protect a bank instead of a garage. BYtE, Diego From rjh at sixdemonbag.org Thu Jan 14 23:36:00 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 14 Jan 2016 17:36:00 -0500 Subject: Key selection order In-Reply-To: <477F0326-6B69-47D6-84F2-0888EF21944D@andrewg.com> References: <5697CC7C.7040603@sixdemonbag.org> <5697D507.6020501@andrewg.com> <5697F2E5.5060409@gmail.com> <477F0326-6B69-47D6-84F2-0888EF21944D@andrewg.com> Message-ID: <569822D0.8060702@sixdemonbag.org> > Granted. And it does provide a speed bump to a potential attacker, so > is preferable to nothing. But it's not a long term solution. Beware all absolutes. There are lots of situations in which TOFU works *just fine* as a long-term solution. Remember, the truest answer in cryptography is, "It depends a lot on the situation." I've known vedaal for what, coming up on 20 years now, vedaal? I've never used any verification for him besides TOFU. Works just fine for us. There's a decent chance it's been working for us longer than you've been alive. :) I think people have a vast misunderstanding about the TOFU threat model. If you are already under active attack by a well-funded adversary, then yes, you're screwed: don't use TOFU. But if you're not, then TOFU allows you a much easier way to build and develop your own personal Web of Trust in ways that make it much harder for an active attacker to later on subvert your communications. > Tofu does not guarantee identity persistence. Neither does the WoT. What does, for that matter? From andrewg at andrewg.com Fri Jan 15 00:12:32 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 14 Jan 2016 23:12:32 +0000 Subject: Key selection order In-Reply-To: <89f6fb0a548fda8e19ccd0ae22a33161@butters.digitalbrains.com> References: <5697CC7C.7040603@sixdemonbag.org> <5697D507.6020501@andrewg.com> <5697F2E5.5060409@gmail.com> <477F0326-6B69-47D6-84F2-0888EF21944D@andrewg.com> <89f6fb0a548fda8e19ccd0ae22a33161@butters.digitalbrains.com> Message-ID: <4BC6AFD1-AC0C-4A44-93B2-F12493F5941F@andrewg.com> > On 14 Jan 2016, at 21:26, Peter Lebbing wrote: > please don't phrase your words as fact when it's such a contended issue. Fair enough, let me rephrase: I don't believe it's a long term solution, particularly as the capabilities of well-funded attackers to mitm multiple network paths simultaneously appear to be still growing. But yes, in many cases it is good enough to be getting on with. >> Tofu does not guarantee identity persistence. Just because your >> correspondence hasn't been obviously tampered with (yet) does not mean >> that someone hasn't been MITMing you all along and biding their time. > > Isn't "MITM'ing all along" identity persistence then? It's quite unfortunate it's the /wrong/ identity, but it's identity persistence in my book, No, because mitm doesn't mean one identity replaces another, but that the two identities become conflated. A signature that could have been created by one of two people does not identify either person. If I faithfully transcribe every email that I mitm apart from one, it does not make me the author of the faithful mails; only of the one that I alter. A From andrewg at andrewg.com Fri Jan 15 00:15:15 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 14 Jan 2016 23:15:15 +0000 Subject: Key selection order In-Reply-To: <569822D0.8060702@sixdemonbag.org> References: <5697CC7C.7040603@sixdemonbag.org> <5697D507.6020501@andrewg.com> <5697F2E5.5060409@gmail.com> <477F0326-6B69-47D6-84F2-0888EF21944D@andrewg.com> <569822D0.8060702@sixdemonbag.org> Message-ID: On 14 Jan 2016, at 22:36, Robert J. Hansen wrote: There's a decent chance it's been working for us longer than you've > been alive. :) I'm afraid I predate not just PGP but also RSA. Just about. ;-) A From glenn at rempe.us Fri Jan 15 01:08:04 2016 From: glenn at rempe.us (Glenn Rempe) Date: Fri, 15 Jan 2016 00:08:04 +0000 Subject: Yubikey, GnuPG 2.1 Modern, and SSH on OS X Message-ID: I recently setup my own Mac w/ gnupg 2.1.10, and I am using a Yubikey to manage my gpg private keys and I am using that key for SSH auth. I have it all up and running but I ran into some issues as well so I wrote up a blog post. I'd appreciate any suggestions for improvement and especially for any ideas for a better fix for the workaround I had to do that I documented at the end of the post. Maybe this will be of some use to those wanting to use the latest gpg for SSH auth on a Mac with a Yubikey. https://www.rempe.us/blog/yubikey-gnupg-2-1-and-ssh/ Here is a discussion thread that describes *exactly* the issue I am still having (if I don't use my workaround to kill and restart gpg-agent on every yubikey insertion and deletion): https://lists.gnupg.org/pipermail/gnupg-users/2015-June/053796.html Glenn -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at josefsson.org Fri Jan 15 10:29:13 2016 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 15 Jan 2016 10:29:13 +0100 Subject: Yubikey, GnuPG 2.1 Modern, and SSH on OS X In-Reply-To: (Glenn Rempe's message of "Fri, 15 Jan 2016 00:08:04 +0000") References: Message-ID: <871t9jfaxi.fsf@latte.josefsson.org> Glenn Rempe writes: > I recently setup my own Mac w/ gnupg 2.1.10, and I am using a Yubikey to > manage my gpg private keys and I am using that key for SSH auth. I have it > all up and running but I ran into some issues as well so I wrote up a blog > post. I'd appreciate any suggestions for improvement and especially for > any ideas for a better fix for the workaround I had to do that I documented > at the end of the post. Maybe this will be of some use to those wanting to > use the latest gpg for SSH auth on a Mac with a Yubikey. > > https://www.rempe.us/blog/yubikey-gnupg-2-1-and-ssh/ Have you tried killing/restarting scdaemon only, not gpg-agent? Try: gpgconf --reload scdaemon or gpg-connect-agent "SCD KILLSCD" "SCD BYE" /bye Why do you add the keygrip to the sshcontrol file? I have never needed that step. For me it uses the right key directly. Is it because you have another (revoked) A subkey? It sounds somewhat of sub-optimal behaviour for gpg-agent's SSH support to use a revoked key instead of the non-revoked key. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From peter at digitalbrains.com Fri Jan 15 13:08:49 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 15 Jan 2016 13:08:49 +0100 Subject: Key selection order In-Reply-To: <4BC6AFD1-AC0C-4A44-93B2-F12493F5941F@andrewg.com> References: <5697CC7C.7040603@sixdemonbag.org> <5697D507.6020501@andrewg.com> <5697F2E5.5060409@gmail.com> <477F0326-6B69-47D6-84F2-0888EF21944D@andrewg.com> <89f6fb0a548fda8e19ccd0ae22a33161@butters.digitalbrains.com> <4BC6AFD1-AC0C-4A44-93B2-F12493F5941F@andrewg.com> Message-ID: <5698E151.8050907@digitalbrains.com> On 15/01/16 00:12, Andrew Gallagher wrote: > No, because mitm doesn't mean one identity replaces another, but that the two > identities become conflated. Ah, we are ascribing different attributes to an "identity". I think you mean an identity belongs to a specific person, an individual. If you MITM, there are two people, so two identities. I describe an "identity" as "this person who's been giving me good advice on topic X for several months", for example. Note that I cannot differentiate between someone who thought up the advice from someone who is just forwarding someone else's advice. If there's this individual A who has been giving me great advice, but all their mails were MITM'ed such that individual B put their signature under it, B could at any moment abuse this trust that A built and give me horrible advice that results in something that is useful for B. But the same could happen with A! I know the guy/girl only from their e-mails. For all I know, A is biding their time to eventually screw me over. And they could be asking someone else and only writing down their advice. 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 Fri Jan 15 14:34:28 2016 From: the2nd at otpme.org (the2nd at otpme.org) Date: Fri, 15 Jan 2016 14:34:28 +0100 Subject: Yubikey, GnuPG 2.1 Modern, and SSH on OS X In-Reply-To: References: Message-ID: You might hit this bug: http://lists.gnupg.org/pipermail/gnupg-users/2015-December/054756.html On 2016-01-15 01:08, Glenn Rempe wrote: > I recently setup my own Mac w/ gnupg 2.1.10, and I am using a Yubikey > to manage my gpg private keys and I am using that key for SSH auth.? > I have it all up and running but I ran into some issues as well so I > wrote up a blog post.? I'd appreciate any suggestions for improvement > and especially for any ideas for a better fix for the workaround I had > to do that I documented at the end of the post.? Maybe this will be > of some use to those wanting to use the latest gpg for SSH auth on a > Mac with a Yubikey. > > https://www.rempe.us/blog/yubikey-gnupg-2-1-and-ssh/ [1] > > Here is a discussion thread that describes *exactly* the issue I am > still having (if I don't use my workaround to kill and restart > gpg-agent on every yubikey insertion and deletion): > > https://lists.gnupg.org/pipermail/gnupg-users/2015-June/053796.html > [2] > > Glenn > > > > Links: > ------ > [1] https://www.rempe.us/blog/yubikey-gnupg-2-1-and-ssh/ > [2] https://lists.gnupg.org/pipermail/gnupg-users/2015-June/053796.html > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From dougb at dougbarton.email Fri Jan 15 20:27:43 2016 From: dougb at dougbarton.email (Doug Barton) Date: Fri, 15 Jan 2016 11:27:43 -0800 Subject: Key selection order In-Reply-To: <56981625.8030400@gmail.com> References: <5697CC7C.7040603@sixdemonbag.org> <5697D507.6020501@andrewg.com> <5697F2E5.5060409@gmail.com> <477F0326-6B69-47D6-84F2-0888EF21944D@andrewg.com> <56981625.8030400@gmail.com> Message-ID: <5699482F.7070306@dougbarton.email> On 01/14/2016 01:41 PM, NdK wrote: > Il 14/01/2016 21:06, Andrew Gallagher ha scritto: > >> >Tofu does not guarantee identity persistence. Just because your correspondence hasn't been obviously tampered with (yet) does not mean that someone hasn't been MITMing you all along and biding their time. > As usual, it depends on your attack scenario. > If I have 10-years-old mails from someone I've never met, and all use > the same key, I can assume that either 1) that identity belongs to the > same person or 2) that an attacker MITMed*all* my connections (from > every device I've had wherever I was and to every service I used). > Occam's razor and my "exposure profile" make me think it's 1):) There are several more possible scenarios. The most plausible of which would be 3) Your correspondent is being coerced, and 4) Your correspondent has lost control of the key, and the new correspondent is skilled at mimicking the "real" one. Of course neither of those scenarios is defensible with either key verification strategy. > In other words,*time* can be considered an 'out of band' channel. It really can't ... if anything time increases the likelihood that the original key holder has lost control of the key. Doug From dougb at dougbarton.email Fri Jan 15 20:32:02 2016 From: dougb at dougbarton.email (Doug Barton) Date: Fri, 15 Jan 2016 11:32:02 -0800 Subject: basic identity mgmt In-Reply-To: <20160114143539.11449@web005.roc2.bluetie.com> References: <20160114143539.11449@web005.roc2.bluetie.com> Message-ID: <56994932.7080707@dougbarton.email> On 01/14/2016 11:35 AM, Wendy Oberg wrote: > From: "Doug Barton" [dougb at dougbarton.email] >> What is your concern about signing the key? > > Not so much a concern. But I might want to make use of the predicate > "key X is valid" without having to sign anything, and without even having a > key. You still haven't answered the "Why?" question. I'm not trying to badger you, I'm trying to find out if there is a use case that we're missing here. > Sounds like the "--tofu-policy good ..." in recent versions, as suggested > by Damien, may do the trick for this. Unless I'm missing something that's not different in any material way from '--trust-model always'. >> And are you aware that local signatures will not be communicated beyond your >> keyring? > > Yes, thanks, W. Ok, so why is that not the right solution for you? Doug From dougb at dougbarton.email Fri Jan 15 20:33:20 2016 From: dougb at dougbarton.email (Doug Barton) Date: Fri, 15 Jan 2016 11:33:20 -0800 Subject: basic identity mgmt In-Reply-To: References: <20160110170143.11899@web003.roc2.bluetie.com> <5693D718.7070309@dougbarton.email> Message-ID: <56994980.8090901@dougbarton.email> On 01/11/2016 08:35 AM, Lachlan Gunn wrote: > > You've already received good answers on your questions, so some > questions for you. :) What is your concern about signing the key? > And are you aware that local signatures will not be communicated > beyond your keyring? > > > I actually ran into this issue the other day. For me it's problematic > because my certification key is on an offline machine, so it's > inconvenient to have to power it up and do a round-trip through the > airgap when I'm not going to propagate the signature anyway. It's not a > dealbreaker but it's still a bit irritating. This is a good example of why that method of working with your keys is pointlessly complicated. :) Doug From andrewg at andrewg.com Fri Jan 15 21:21:55 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 15 Jan 2016 20:21:55 +0000 Subject: basic identity mgmt In-Reply-To: <56994980.8090901@dougbarton.email> References: <20160110170143.11899@web003.roc2.bluetie.com> <5693D718.7070309@dougbarton.email> <56994980.8090901@dougbarton.email> Message-ID: <569954E3.2010101@andrewg.com> On 15/01/16 19:33, Doug Barton wrote: > On 01/11/2016 08:35 AM, Lachlan Gunn wrote: >> For me it's problematic >> because my certification key is on an offline machine, so it's >> inconvenient to have to power it up and do a round-trip through the >> airgap when I'm not going to propagate the signature anyway. It's not a >> dealbreaker but it's still a bit irritating. > > This is a good example of why that method of working with your keys is > pointlessly complicated. :) It's complicated, but not necessarily _pointlessly_ so. Depending on circumstances it could be considered minimally prudent. I've worked on several projects for more than one financial institution, and airgaps like this are considered barely sufficient for some important keys. (Of course in such projects the idea of a certification subkey not on the airgapped machine would be completely unacceptable...) A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From simon at josefsson.org Fri Jan 15 21:30:36 2016 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 15 Jan 2016 21:30:36 +0100 Subject: Yubikey, GnuPG 2.1 Modern, and SSH on OS X In-Reply-To: <20160115201713.GA76517@potion-factory.local> References: <871t9jfaxi.fsf@latte.josefsson.org> <20160115201713.GA76517@potion-factory.local> Message-ID: <20160115213036.23f0a0a7@latte.josefsson.org> > > Why do you add the keygrip to the sshcontrol file? I have never > > needed that step. For me it uses the right key directly. Is it > > because you have another (revoked) A subkey? It sounds somewhat of > > sub-optimal behaviour for gpg-agent's SSH support to use a revoked > > key instead of the non-revoked key. > > I do have a revoked Authentication sub-key on my primary key, but I > no longer use it and that is also not why I added the keygrip entry to > sshcontrol file. I added it at the suggestion of Werner in this post: > > https://lists.gnupg.org/pipermail/gnupg-users/2012-July/045059.html > > And these blog posts: > http://incenp.org/notes/2015/gnupg-for-ssh-authentication.html > http://budts.be/weblog/2012/08/ssh-authentication-with-your-pgp-key > > Is this suggestion outdated? I don't recall ever using it, and I've been using SSH with smartcards through gpg-agent for over 10 years. What happens if you drop that part? For me it has always selected the right subkey automatically. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signatur URL: From dougb at dougbarton.email Fri Jan 15 22:02:19 2016 From: dougb at dougbarton.email (Doug Barton) Date: Fri, 15 Jan 2016 13:02:19 -0800 Subject: basic identity mgmt In-Reply-To: <569954E3.2010101@andrewg.com> References: <20160110170143.11899@web003.roc2.bluetie.com> <5693D718.7070309@dougbarton.email> <56994980.8090901@dougbarton.email> <569954E3.2010101@andrewg.com> Message-ID: <56995E5B.4020701@dougbarton.email> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 01/15/2016 12:21 PM, Andrew Gallagher wrote: | On 15/01/16 19:33, Doug Barton wrote: |> This is a good example of why that method of working with your |> keys is pointlessly complicated. :) | | It's complicated, but not necessarily _pointlessly_ so. Depending | on circumstances it could be considered minimally prudent. I've | worked on several projects for more than one financial institution, | and airgaps like this are considered barely sufficient for some | important keys. (Of course in such projects the idea of a | certification subkey not on the airgapped machine would be | completely unacceptable...) That's interesting, and you have made me curious ... what's the threat model? And what is that key certifying? Doug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWmV5bAAoJEFzGhvEaGryE0DUH/ikPiqoloNaGaKLbhffEdbOy Vwu/AmBIzqAgG9PRrOMQs0YVu0m+i5LaQiJ+ofiL/6ohWQWk2T5jny4mL+n2I/BP Mposz7GYQcTHM0+4Dn7CTuEkGow0afOCqFte1FTibGb8amDquExn9EpfvBJeTde3 +Tfkh8HJFgWj/Kc1dxz4QR9bt7M5Z++XdstjOBE4vkJHsnbb8RsPMO6ammS5Vncf EHJpmwNjz67p5dWyi2DsHA5q7epW02tpqqwQCpRbZzf2Qd/t6k9glGuk3kZMkI6T x57YyOCO4J8skDQbffmqk0u7vb5Ogt4CdcyM8NKRZVo+DRV/pojt3tDuwXiX//E= =Y3Xu -----END PGP SIGNATURE----- From glenn at rempe.us Fri Jan 15 21:17:13 2016 From: glenn at rempe.us (Glenn Rempe) Date: Fri, 15 Jan 2016 12:17:13 -0800 Subject: Yubikey, GnuPG 2.1 Modern, and SSH on OS X In-Reply-To: <871t9jfaxi.fsf@latte.josefsson.org> References: <871t9jfaxi.fsf@latte.josefsson.org> Message-ID: <20160115201713.GA76517@potion-factory.local> On Fri, Jan 15, 2016 at 10:29:13AM +0100, Simon Josefsson wrote: > Glenn Rempe writes: > > > I recently setup my own Mac w/ gnupg 2.1.10, and I am using a Yubikey to > > manage my gpg private keys and I am using that key for SSH auth. I have it > > all up and running but I ran into some issues as well so I wrote up a blog > > post. I'd appreciate any suggestions for improvement and especially for > > any ideas for a better fix for the workaround I had to do that I documented > > at the end of the post. Maybe this will be of some use to those wanting to > > use the latest gpg for SSH auth on a Mac with a Yubikey. > > > > https://www.rempe.us/blog/yubikey-gnupg-2-1-and-ssh/ > > Have you tried killing/restarting scdaemon only, not gpg-agent? > > Try: > > gpgconf --reload scdaemon > > or > > gpg-connect-agent "SCD KILLSCD" "SCD BYE" /bye I am on OS X, and just so you know I have turned off the OS X system scdaemon per this blog post (I did this before upgrading to GnuPG 2.1): https://gpgtools.tenderapp.com/discussions/problems/28634-gpg-agent-stops-working-after-osx-upgrade-to-yosemite#comment_35808149 So I am using just the scdaemon embedded with GPG I believe. I just tried your suggestion to reload the internal scdaemon with 'gpgconf --reload scdaemon' and that also worked just as well as killing gpg-agent, and probably without some side effects, none of which I've noticed yet. So that is a step in the right direction, but I still have to run it every time I remove/reinsert the card and SSH to a remote host or it fails with a 'Permission denied (publickey)' error. So this seems like a step in the right direction, but I still have to use ControlPlane to restart scdaemon on insert/remove events. > > Why do you add the keygrip to the sshcontrol file? I have never needed > that step. For me it uses the right key directly. Is it because you > have another (revoked) A subkey? It sounds somewhat of sub-optimal > behaviour for gpg-agent's SSH support to use a revoked key instead of > the non-revoked key. I do have a revoked Authentication sub-key on my primary key, but I no longer use it and that is also not why I added the keygrip entry to sshcontrol file. I added it at the suggestion of Werner in this post: https://lists.gnupg.org/pipermail/gnupg-users/2012-July/045059.html And these blog posts: http://incenp.org/notes/2015/gnupg-for-ssh-authentication.html http://budts.be/weblog/2012/08/ssh-authentication-with-your-pgp-key Is this suggestion outdated? > > /Simon -- Glenn Rempe email : glenn at rempe.us voice : (415) 613-1653 twitter : @grempe gpg key id : 0xA4A288A3BECCAE17 gpg fingerprint : 497A 6138 963D 6C47 202B 238B A4A2 88A3 BECC AE17 From glenn at rempe.us Fri Jan 15 22:29:55 2016 From: glenn at rempe.us (Glenn Rempe) Date: Fri, 15 Jan 2016 21:29:55 +0000 Subject: Yubikey, GnuPG 2.1 Modern, and SSH on OS X In-Reply-To: <20160115213036.23f0a0a7@latte.josefsson.org> References: <871t9jfaxi.fsf@latte.josefsson.org> <20160115201713.GA76517@potion-factory.local> <20160115213036.23f0a0a7@latte.josefsson.org> Message-ID: I'm not sure when the use of sshcontrol emerged. My impression was that it is only used as part of GnuPG 'Modern' 2.1.x versions. That being said, If I remove the keygrip entry from the sshcontrol file it appears to work fine. The only difference I've just noticed is in the output of 'ssh-add -l': with keygrip in sshcontrol: ~/.gnupg$ ssh-add -l error fetching identities for protocol 1: agent refused operation 2048 SHA256:X3YiWulZ1xJlqGRFqeaQOmLuZvyfJV/r7Qwo/kmUgCg cardio:000MYCARDNUM (RSA) 2048 SHA256:X3YiWulZ1xJlqGRFqeaQOmLuZvyfJV/r7Qwo/kmUgCg (none) (RSA) without key grip in sshcontrol: ~/.gnupg$ ssh-add -l error fetching identities for protocol 1: agent refused operation 2048 SHA256:X3YiWulZ1xJlqGRFqeaQOmLuZvyfJV/r7Qwo/kmUgCg cardno:000MYCARDNUM (RSA) Any ideas for also eliminating that error message, or understanding why its there are appreciated. As for the suggestion by the2nd at otpme.org regarding the scdaemon bug. This sounded promising, but when I investigated a bit it seems that the commit in that thread that indicated this issue might be fixed on master (f42c50dbf00c2e6298ca6830cbe6d36805fa54a3) was committed on Dec 2, 2015, and gnupg version 2.1.10 was tagged on Dec 4, 2015. So that fix should already be in the version of GnuPG I am using (2.1.10) and yet I am still seeing a problem. /tmp/gnupg (master ?)$ git log f42c50dbf00c2e6298ca6830cbe6d36805fa54a3 commit f42c50dbf00c2e6298ca6830cbe6d36805fa54a3 Author: NIIBE Yutaka Date: Thu Dec 3 11:26:24 2015 +0900 scd: Fix "Conflicting usage" bug. * scd/apdu.c (apdu_close_reader): Call CLOSE_READER method even if we got an error from apdu_disconnect. * scd/app-common.h (no_reuse): Remove. * scd/app.c (application_notify_card_reset): Deallocate APP here. (select_application, release_application): Don't use NO_REUSE. -- Reproducible scenario: Invoke gpg --card-edit session from a terminal. Invoke another gpg --card-edit session from another. Remove a token. Insert a token again. Type RET on both terminals. One of terminal answers "Conflicting usage". Perhaps, having NO_REUSE field was to avoid race conditions. Now, APP can be safely deallocated by application_notify_card_reset. Thanks to the2nd. I installed 2.1.10 from this homebrew recipe: https://github.com/Homebrew/homebrew-versions/blob/master/gnupg21.rb My SSH client is the one that comes with OS X 'El Capitan': /tmp/gnupg (master ?)$ ssh -V OpenSSH_6.9p1, LibreSSL 2.1.8 On Fri, Jan 15, 2016 at 12:31 PM Simon Josefsson wrote: > > > Why do you add the keygrip to the sshcontrol file? I have never > > > needed that step. For me it uses the right key directly. Is it > > > because you have another (revoked) A subkey? It sounds somewhat of > > > sub-optimal behaviour for gpg-agent's SSH support to use a revoked > > > key instead of the non-revoked key. > > > > I do have a revoked Authentication sub-key on my primary key, but I > > no longer use it and that is also not why I added the keygrip entry to > > sshcontrol file. I added it at the suggestion of Werner in this post: > > > > https://lists.gnupg.org/pipermail/gnupg-users/2012-July/045059.html > > > > And these blog posts: > > http://incenp.org/notes/2015/gnupg-for-ssh-authentication.html > > http://budts.be/weblog/2012/08/ssh-authentication-with-your-pgp-key > > > > Is this suggestion outdated? > > I don't recall ever using it, and I've been using SSH with smartcards > through gpg-agent for over 10 years. What happens if you drop that > part? For me it has always selected the right subkey automatically. > > /Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrewg at andrewg.com Fri Jan 15 22:37:38 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 15 Jan 2016 21:37:38 +0000 Subject: basic identity mgmt In-Reply-To: <56995E5B.4020701@dougbarton.email> References: <20160110170143.11899@web003.roc2.bluetie.com> <5693D718.7070309@dougbarton.email> <56994980.8090901@dougbarton.email> <569954E3.2010101@andrewg.com> <56995E5B.4020701@dougbarton.email> Message-ID: <569966A2.3040005@andrewg.com> On 15/01/16 21:02, Doug Barton wrote: > On 01/15/2016 12:21 PM, Andrew Gallagher wrote: > | I've > | worked on several projects for more than one financial institution, > | and airgaps like this are considered barely sufficient for some > | important keys. (Of course in such projects the idea of a > | certification subkey not on the airgapped machine would be > | completely unacceptable...) > > That's interesting, and you have made me curious ... what's the threat > model? And what is that key certifying? Most relevant example, a system where users can register their authorisation keys against a semi-automated authority which signs them for trust by a third system. The root key that certifies the automated authority keys is offline. Essentially a private root CA. Now, this example is using x509 rather than pgp, but the threat model is the same. Bad guys hack into the system, they can fake a trust relationship, which in turn compromises a different system. To put this into PGP terms, say Lachlann were Stallman (ok, I'm stretching a bit!). Then say someone wants to impersonate Linus. If they could root RMS's laptop they could certify a key in Linus's name and many people would say "RMS is paranoid, so it really must be Linus!". ;-) But if RMS keeps his certification key offline, the best the hackers can do is impersonate him - until he notices of course, at which point he can roll his subkeys and draw a line under the incident. Of course if a C-capable subkey were to exist, Linus would lose the benefit of the airgap. RMS would still be able to roll his subkeys, but that would also revoke all the trust relationships that depended on the C-subkey. So both of them are worse off. A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Sat Jan 16 00:08:51 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 16 Jan 2016 00:08:51 +0100 Subject: Yubikey, GnuPG 2.1 Modern, and SSH on OS X In-Reply-To: <20160115201713.GA76517@potion-factory.local> References: <871t9jfaxi.fsf@latte.josefsson.org> <20160115201713.GA76517@potion-factory.local> Message-ID: <56997C03.8000405@digitalbrains.com> On 15/01/16 21:17, Glenn Rempe wrote: > I added it at the suggestion of Werner in this post: > > https://lists.gnupg.org/pipermail/gnupg-users/2012-July/045059.html > > And these blog posts: > http://incenp.org/notes/2015/gnupg-for-ssh-authentication.html > http://budts.be/weblog/2012/08/ssh-authentication-with-your-pgp-key > > Is this suggestion outdated? No, but I'm fairly sure Werner did not realise you were using a smartcard when he wrote that. Obviously, I can't look into the man's mind, but that's my guess. For regular, on-disk keys, it is necessary to add the keygrip to sshcontrol. For smartcards, it's automatically added when the smartcard is inserted. I guess it fits with automatically added secret key stubs when the smartcard is inserted (to use a smartcard on a fresh PC, import your own public key, insert your smartcard, and you're done). 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 glenn at rempe.us Sat Jan 16 00:47:07 2016 From: glenn at rempe.us (Glenn Rempe) Date: Fri, 15 Jan 2016 23:47:07 +0000 Subject: Yubikey, GnuPG 2.1 Modern, and SSH on OS X In-Reply-To: <56997C03.8000405@digitalbrains.com> References: <871t9jfaxi.fsf@latte.josefsson.org> <20160115201713.GA76517@potion-factory.local> <56997C03.8000405@digitalbrains.com> Message-ID: Thanks Peter, I was not aware of that (and it certainly explains the double entry in ssh-add -l. btw, Werner was not writing that response to me. It was just pointed out to me, so yes it was probably not smart card specific I would guess. I'll update the blog post to reflect that we probably do not need to modify sshcontrol for use with Yubikey. Back to the main issue I am having. I followed the instructions to output a verbose scdaemon log which I was exercising this issue. Here is a gist with the commands I was running and the resulting logfile. https://gist.github.com/grempe/e143796b8f399f5fa391 Perhaps NIIBE Yutaka or someone else more knowledgable than I can take a look and get us closer to resolution. :-) Thanks for everyone who is helping. On Fri, Jan 15, 2016 at 3:08 PM Peter Lebbing wrote: > On 15/01/16 21:17, Glenn Rempe wrote: > > I added it at the suggestion of Werner in this post: > > > > https://lists.gnupg.org/pipermail/gnupg-users/2012-July/045059.html > > > > And these blog posts: > > http://incenp.org/notes/2015/gnupg-for-ssh-authentication.html > > http://budts.be/weblog/2012/08/ssh-authentication-with-your-pgp-key > > > > Is this suggestion outdated? > > No, but I'm fairly sure Werner did not realise you were using a smartcard > when > he wrote that. Obviously, I can't look into the man's mind, but that's my > guess. > > For regular, on-disk keys, it is necessary to add the keygrip to > sshcontrol. For > smartcards, it's automatically added when the smartcard is inserted. I > guess it > fits with automatically added secret key stubs when the smartcard is > inserted > (to use a smartcard on a fresh PC, import your own public key, insert your > smartcard, and you're done). > > HTH, > > Peter. > > -- > I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. > You can send me encrypted mail if you want some privacy. > My key is available at > -------------- next part -------------- An HTML attachment was scrubbed... URL: From the2nd at otpme.org Sat Jan 16 02:28:17 2016 From: the2nd at otpme.org (the2nd at otpme.org) Date: Sat, 16 Jan 2016 02:28:17 +0100 Subject: Yubikey, GnuPG 2.1 Modern, and SSH on OS X In-Reply-To: References: <871t9jfaxi.fsf@latte.josefsson.org> <20160115201713.GA76517@potion-factory.local> <56997C03.8000405@digitalbrains.com> Message-ID: <8dd332647579ea34bd5be1db56952945@otpme.org> I just want to point out that one may want to add the keygrip to the sshcontrol file along with the "confirm" option to get asked by pinentry each time ssh requests gpg-agent to sign an ssh challenge (e.g. a ssh login). This is at least a useful option if you login to a remote host with agent forwarding enabled. I know that there are more secure alternatives to agent forwarding but i guess it is still used because of its simplicity. I also use it from time to time *shame* But thats the only reason in know why one would add it to sshcontrol. Regards the2nd On 2016-01-16 00:47, Glenn Rempe wrote: > Thanks Peter, I was not aware of that (and it certainly explains the > double entry in ssh-add -l. > > btw, Werner was not writing that response to me. It was just pointed > out to me, so yes it was > probably not smart card specific I would guess. I'll update the blog > post to reflect that we > probably do not need to modify sshcontrol for use with Yubikey. > > Back to the main issue I am having. I followed the instructions to > output a verbose scdaemon log > which I was exercising this issue.? Here is a gist with the commands > I was running and the resulting > logfile. > > https://gist.github.com/grempe/e143796b8f399f5fa391 [5] > > Perhaps?NIIBE Yutaka or someone else more knowledgable than I can > take a look and? > get us closer to resolution. :-) > > Thanks for everyone who is helping. > > On Fri, Jan 15, 2016 at 3:08 PM Peter Lebbing > wrote: > >> On 15/01/16 21:17, Glenn Rempe wrote: >>> I added it at the suggestion of Werner in this post: >>> >>> >> https://lists.gnupg.org/pipermail/gnupg-users/2012-July/045059.html >> [1] >>> >>> And these blog posts: >>> http://incenp.org/notes/2015/gnupg-for-ssh-authentication.html >> [2] >>> >> http://budts.be/weblog/2012/08/ssh-authentication-with-your-pgp-key >> [3] >>> >>> Is this suggestion outdated? >> >> No, but I'm fairly sure Werner did not realise you were using a >> smartcard when >> he wrote that. Obviously, I can't look into the man's mind, but >> that's my guess. >> >> For regular, on-disk keys, it is necessary to add the keygrip to >> sshcontrol. For >> smartcards, it's automatically added when the smartcard is >> inserted. I guess it >> fits with automatically added secret key stubs when the smartcard >> is inserted >> (to use a smartcard on a fresh PC, import your own public key, >> insert your >> smartcard, and you're done). >> >> 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 >> > > > Links: > ------ > [1] https://lists.gnupg.org/pipermail/gnupg-users/2012-July/045059.html > [2] http://incenp.org/notes/2015/gnupg-for-ssh-authentication.html > [3] http://budts.be/weblog/2012/08/ssh-authentication-with-your-pgp-key > [4] http://digitalbrains.com/2012/openpgp-key-peter > [5] https://gist.github.com/grempe/e143796b8f399f5fa391 > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From dougb at dougbarton.email Sun Jan 17 03:19:32 2016 From: dougb at dougbarton.email (Doug Barton) Date: Sat, 16 Jan 2016 18:19:32 -0800 Subject: basic identity mgmt In-Reply-To: <569966A2.3040005@andrewg.com> References: <20160110170143.11899@web003.roc2.bluetie.com> <5693D718.7070309@dougbarton.email> <56994980.8090901@dougbarton.email> <569954E3.2010101@andrewg.com> <56995E5B.4020701@dougbarton.email> <569966A2.3040005@andrewg.com> Message-ID: <569AFA34.70002@dougbarton.email> On 01/15/2016 01:37 PM, Andrew Gallagher wrote: > On 15/01/16 21:02, Doug Barton wrote: > >> On 01/15/2016 12:21 PM, Andrew Gallagher wrote: >> | I've >> | worked on several projects for more than one financial institution, >> | and airgaps like this are considered barely sufficient for some >> | important keys. (Of course in such projects the idea of a >> | certification subkey not on the airgapped machine would be >> | completely unacceptable...) >> >> That's interesting, and you have made me curious ... what's the threat >> model? And what is that key certifying? > > Most relevant example, a system where users can register their > authorisation keys against a semi-automated authority which signs them > for trust by a third system. The root key that certifies the automated > authority keys is offline. Essentially a private root CA. > > Now, this example is using x509 rather than pgp, Right, that's what I suspected. I have set up similar systems myself, and I'm very familiar with security requirements there. X.509 is very different from PGP, although I do understand that in some ways the semantics are the same. Most particularly X.509 is used primarily to establish trust relationships between systems, not people. So the ability for a system to identify itself to another system, without human review being involved, is something much more precious that deserves a higher degree of protection. OTOH, PGP is designed primarily to establish trust relationships between people, with human review of the results an integral part of the process. I read your example, and there are numerous flaws with your theoretical threat model. Let's assume your premise, that someone could root a laptop, and by so doing gain access to use all of the PGP keys on that laptop (Note, I disagree with this premise, but let's grant it for argument's sake). There is no need to deal with the certification key at all in order to do the kind of damage you proposed. All you need to do is sign a message that authorizes your nefarious deeds. Said attacker would also have the ability to decrypt all manner of messages and/or data, all of which are likely to be vastly more interesting than what you propose. In fact, I assert with a great deal of confidence that *for PGP*, the certification key is the least interesting key of the bunch, and yet it's the one that people have created this intricate protection mechanism for. Further I don't see signing as all that interesting either. As has been discussed several times on this list the primary area of reliability for signing is to make sure that the message that arrived was the one that was sent. But it provides no guarantee about who was in control of the key when the message was signed, whether the signer was coerced, etc. We can infer things about these topics from our knowledge/beliefs about the sender, but I can't think of any rational person would go along with a request to "Pay Joe $10,000" just because the message was PGP signed. Forget the validity of the key, that kind of request would require serious OOB authentication. Glossing over authentication (because there's no real use case for those keys yet), that leaves us with encryption, and that's where it's at, my friends. But unless you really enjoy making your life harder than it has to be, you can't routinely use encryption with an air-gapped key, so I remain unconvinced that there is a use case for air-gapping PGP keys. But I'm still willing to listen. :) Doug From andrewg at andrewg.com Sun Jan 17 04:06:36 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sun, 17 Jan 2016 03:06:36 +0000 Subject: basic identity mgmt In-Reply-To: <569AFA34.70002@dougbarton.email> References: <20160110170143.11899@web003.roc2.bluetie.com> <5693D718.7070309@dougbarton.email> <56994980.8090901@dougbarton.email> <569954E3.2010101@andrewg.com> <56995E5B.4020701@dougbarton.email> <569966A2.3040005@andrewg.com> <569AFA34.70002@dougbarton.email> Message-ID: <4306608A-F40C-4167-8F35-7A5A45D30C93@andrewg.com> > On 17 Jan 2016, at 02:19, Doug Barton wrote:. > > OTOH, PGP is designed primarily to establish trust relationships between people, with human review of the results an integral part of the process. That may have been the initial motivation. But consider that the most common real world use of PGP today is verification of code signatures - many of which are generated semi-automatically by build infrastructures such as Debian and verified by install tools. The trust relationship here is between your client and a build server, not people. > Glossing over authentication (because there's no real use case for those keys yet), Two factor ssh smart card auth? I use it nearly every day - much more often than encrypted mail. I don't think anyone has sent me an encrypted mail in over a year, and the last one was about signing a PGP key. ;-) A From dougb at dougbarton.email Sun Jan 17 04:32:28 2016 From: dougb at dougbarton.email (Doug Barton) Date: Sat, 16 Jan 2016 19:32:28 -0800 Subject: basic identity mgmt In-Reply-To: <4306608A-F40C-4167-8F35-7A5A45D30C93@andrewg.com> References: <20160110170143.11899@web003.roc2.bluetie.com> <5693D718.7070309@dougbarton.email> <56994980.8090901@dougbarton.email> <569954E3.2010101@andrewg.com> <56995E5B.4020701@dougbarton.email> <569966A2.3040005@andrewg.com> <569AFA34.70002@dougbarton.email> <4306608A-F40C-4167-8F35-7A5A45D30C93@andrewg.com> Message-ID: <569B0B4C.90207@dougbarton.email> On 01/16/2016 07:06 PM, Andrew Gallagher wrote: > >> On 17 Jan 2016, at 02:19, Doug Barton wrote:. >> >> OTOH, PGP is designed primarily to establish trust relationships between people, with human review of the results an integral part of the process. > > That may have been the initial motivation. But consider that the most common real world use of PGP today is verification of code signatures - many of which are generated semi-automatically by build infrastructures such as Debian and verified by install tools. The trust relationship here is between your client and a build server, not people. True enough, but what do those signatures actually mean? But more importantly, what security measures are in place to prevent a rogue key from entering that WOT, in addition to a certification signature from a random key? Is the only thing someone would need to do to compromise a single certification key? >> Glossing over authentication (because there's no real use case for those keys yet), > > Two factor ssh smart card auth? I use it nearly every day - much more often than encrypted mail. Sorry, all that does is replace something that already existed, works well, and is widely supported; with something more complex, often buggy, and not widely supported. That's not a use case, that's a solution looking for a problem. That's not to say that someday there won't be a use case for authentication keys, but I haven't seen one yet. > I don't think anyone has sent me an encrypted mail in over a year, and the last one was about signing a PGP key. ;-) You're corresponding with the wrong people. :) Doug From peter at digitalbrains.com Sun Jan 17 11:17:58 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 17 Jan 2016 11:17:58 +0100 Subject: basic identity mgmt In-Reply-To: <569AFA34.70002@dougbarton.email> References: <20160110170143.11899@web003.roc2.bluetie.com> <5693D718.7070309@dougbarton.email> <56994980.8090901@dougbarton.email> <569954E3.2010101@andrewg.com> <56995E5B.4020701@dougbarton.email> <569966A2.3040005@andrewg.com> <569AFA34.70002@dougbarton.email> Message-ID: <569B6A56.6070605@digitalbrains.com> On 17/01/16 03:19, Doug Barton wrote: > Further I don't see signing as all that interesting either. > [...] > We can infer things about these topics from our knowledge/beliefs > about the sender, but I can't think of any rational person would go > along with a request to "Pay Joe $10,000" just because the message > was PGP signed. Forget the validity of the key, that kind of request > would require serious OOB authentication. I'm sorry, this feels forced. I suppose the payment is meant to be an outlandish request. I've heard about banks using OpenPGP, I don't know what is usually in that correspondence. It might be just bank statements. So let's suppose it is an outlandish request. Just because someone would not agree to an outlandish request based on a valid signature, this doesn't mean there aren't reasonable requests that are horribly bad. Let's take two political dissidents in a totalitarian regime. They sometimes wish to meet up in real life, so one sends the other a signed, encrypted request to "meet at 13:00 at X", and they talk. Now a government agency sends one an encrypted message to "meet at 15:00 at Y" (you might notice I'm not a morning person). Then they wait for him or her to pick them up and throw them in jail. In this scenario, I'd say the signature key is damn important. It's on par with the encryption key; if they had that, they could wait for them at 13:00 at X, which is just as bad. But the signature key is equally important, because they can sign a message to meet at 15:00 at Y with that. So I think it's incorrect to say signatures are unimportant because you can't get people to follow insane instructions. You need to look at the sane ones. 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 stebe at mailbox.org Sun Jan 17 21:00:38 2016 From: stebe at mailbox.org (stebe at mailbox.org) Date: Sun, 17 Jan 2016 21:00:38 +0100 (CET) Subject: Bounces-address Message-ID: <292242799.818.12382ab8-e59e-44ae-8532-2f8d001320a6.open-xchange@office.mailbox.org> Hi, why have I been receiving the mails of this list via gnupg-users-bounces for a couple of months now, whereas before that I had been receiving them from the gnupg-users? Is there any reason for this? TIA Stebe From dougb at dougbarton.email Sun Jan 17 21:00:45 2016 From: dougb at dougbarton.email (Doug Barton) Date: Sun, 17 Jan 2016 12:00:45 -0800 Subject: basic identity mgmt In-Reply-To: <569B6A56.6070605@digitalbrains.com> References: <20160110170143.11899@web003.roc2.bluetie.com> <5693D718.7070309@dougbarton.email> <56994980.8090901@dougbarton.email> <569954E3.2010101@andrewg.com> <56995E5B.4020701@dougbarton.email> <569966A2.3040005@andrewg.com> <569AFA34.70002@dougbarton.email> <569B6A56.6070605@digitalbrains.com> Message-ID: <569BF2ED.4080408@dougbarton.email> On 1/17/2016 2:17 AM, Peter Lebbing wrote: > On 17/01/16 03:19, Doug Barton wrote: >> Further I don't see signing as all that interesting either. >> [...] >> We can infer things about these topics from our knowledge/beliefs >> about the sender, but I can't think of any rational person would go >> along with a request to "Pay Joe $10,000" just because the message >> was PGP signed. Forget the validity of the key, that kind of request >> would require serious OOB authentication. > > Just because someone would > not agree to an outlandish request based on a valid signature, this > doesn't mean there aren't reasonable requests that are horribly bad. [after lots of snipping] Your example is a good one, but again I assert that it would be overwhelmingly foolish to rely on *just the signature* to indicate that the request to meet is a legitimate one. You glossed over the points in my previous messages about the fact that we cannot know for sure if the person sending the message is actually who we think it is (i.e., that the legitimate correspondent has not lost control of the key), and that they are not being coerced, based on the signature alone. At minimum there should be some sort of "steganography" based on how the message is constructed, certain words or phrases, etc. That combined with the signature may be enough to prove the validity of the message. But this thread started trying to refute my assertion that keeping certification keys air-gapped is pointlessly complicated. I haven't seen a refutation of that premise yet. :) Doug From gabri.philippe at gmail.com Sun Jan 17 19:32:01 2016 From: gabri.philippe at gmail.com (Gabriel Philippe) Date: Sun, 17 Jan 2016 19:32:01 +0100 Subject: Key selection order In-Reply-To: <5698E151.8050907@digitalbrains.com> References: <5697CC7C.7040603@sixdemonbag.org> <5697D507.6020501@andrewg.com> <5697F2E5.5060409@gmail.com> <477F0326-6B69-47D6-84F2-0888EF21944D@andrewg.com> <89f6fb0a548fda8e19ccd0ae22a33161@butters.digitalbrains.com> <4BC6AFD1-AC0C-4A44-93B2-F12493F5941F@andrewg.com> <5698E151.8050907@digitalbrains.com> Message-ID: On Fri, Jan 15, 2016 at 1:08 PM, Peter Lebbing wrote: > I describe an "identity" as "this person who's been giving me good advice on > topic X for several months", for example. I find quite funny reading from people advocating for ToFU while not even signing their e-mails. Come on, ToFU is very interesting from an intellectual point of view, but has almost no practical use: almost nobody sends signed e-mails. People don't here on this very particular ML, where do you expect finding some? G. From wk at gnupg.org Mon Jan 18 09:20:29 2016 From: wk at gnupg.org (Werner Koch) Date: Mon, 18 Jan 2016 09:20:29 +0100 Subject: Bounces-address In-Reply-To: <292242799.818.12382ab8-e59e-44ae-8532-2f8d001320a6.open-xchange@office.mailbox.org> (stebe@mailbox.org's message of "Sun, 17 Jan 2016 21:00:38 +0100 (CET)") References: <292242799.818.12382ab8-e59e-44ae-8532-2f8d001320a6.open-xchange@office.mailbox.org> Message-ID: <874meb5meq.fsf@vigenere.g10code.de> On Sun, 17 Jan 2016 21:00, stebe at mailbox.org said: > why have I been receiving the mails of this list via gnupg-users-bounces > for a couple of months now, whereas before that I had been receiving them > from the gnupg-users? Is there any reason for this? Mailman always uses a *-bounces address so to make bounce detection easier. Nothing has ever changed. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From peter at digitalbrains.com Mon Jan 18 11:43:01 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 18 Jan 2016 11:43:01 +0100 Subject: basic identity mgmt In-Reply-To: <569BF2ED.4080408@dougbarton.email> References: <20160110170143.11899@web003.roc2.bluetie.com> <5693D718.7070309@dougbarton.email> <56994980.8090901@dougbarton.email> <569954E3.2010101@andrewg.com> <56995E5B.4020701@dougbarton.email> <569966A2.3040005@andrewg.com> <569AFA34.70002@dougbarton.email> <569B6A56.6070605@digitalbrains.com> <569BF2ED.4080408@dougbarton.email> Message-ID: <569CC1B5.7040308@digitalbrains.com> On 17/01/16 21:00, Doug Barton wrote: > You glossed over the points in my previous messages about the fact > that we cannot know for sure if the person sending the message is > actually who we think it is [...] Well, to me it sounded like you said "Signature subkeys aren't enough by themselves, so they don't matter". Whereas they are a necessary part of the puzzle. > But this thread started trying to refute my assertion that keeping > certification keys air-gapped is pointlessly complicated. I haven't > seen a refutation of that premise yet. :) The only good argument (IMO) I can think of is: ease of replacement. If you have an online primary key, and your computer is hacked, you have to revoke the whole key, since the attacker got the private material. This means you need to meet up with at least some of your contacts again to exchange fingerprints. You can't do a key transition, because so could your attacker; if you know your private material is out there, you need to discard the key wholly. Now, if you have an offline main key, on an air-gapped system, that makes it a lot more difficult to attack. When your online, Internet connected system gets hacked, you have a big problem. All your encrypted stuff the attacker can get is readable to them, and as long as you don't know yet, they can issue your signatures. But when you discover it, you can reinstall or throw out the hacked hardware, issue new subkeys and be done with it. Since your primary key was still safe, your correspondents know it's still you. And luckily, your certification key is also the one you use least of all. Issuing new subkeys and certifying other people's keys; the most rare of occurences, I think. But as I wrote, this is what I can think of. I'm inclined to think there are other reasons why an offline primary key can give a significant advantage over an online one. I just haven't thought of them. Similarly, I'm not convinced there aren't good reasons why a smartcard for SSH authentication is indeed an advantage over on-disk keys. So your characterization: On 17/01/16 04:32, Doug Barton wrote: > Sorry, all that does is replace something that already existed, works > well, and is widely supported; with something more complex, often > buggy, and not widely supported. That's not a use case, that's a > solution looking for a problem. is going to far for me, but obviously you're free to be of a different opinion :). 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 andrewg at andrewg.com Mon Jan 18 14:10:14 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 18 Jan 2016 13:10:14 +0000 Subject: Key selection order In-Reply-To: References: <5697CC7C.7040603@sixdemonbag.org> <5697D507.6020501@andrewg.com> <5697F2E5.5060409@gmail.com> <477F0326-6B69-47D6-84F2-0888EF21944D@andrewg.com> <89f6fb0a548fda8e19ccd0ae22a33161@butters.digitalbrains.com> <4BC6AFD1-AC0C-4A44-93B2-F12493F5941F@andrewg.com> <5698E151.8050907@digitalbrains.com> Message-ID: <569CE436.6090202@andrewg.com> On 17/01/16 18:32, Gabriel Philippe wrote: > > I find quite funny reading from people advocating for ToFU while not > even signing their e-mails. I find it funny that on a gpg users mailing list, out of 80 emails since new year, only 15 have signatures at all, and three of those are mine*. Even Werner doesn't sign his mails. I'm reminded of the story (possibly apocryphal) of a delegation of local notables travelling up to Belfast in the 1960s to petition the transport minister not to close their local railway line. The minister asked them how they got to Belfast that morning and they all said "the motorway". A (*) Granted, I don't always sign mine but you can blame the iPhone for that. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Mon Jan 18 15:06:56 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 18 Jan 2016 15:06:56 +0100 Subject: Key selection order In-Reply-To: <569CE436.6090202@andrewg.com> References: <5697CC7C.7040603@sixdemonbag.org> <5697D507.6020501@andrewg.com> <5697F2E5.5060409@gmail.com> <477F0326-6B69-47D6-84F2-0888EF21944D@andrewg.com> <89f6fb0a548fda8e19ccd0ae22a33161@butters.digitalbrains.com> <4BC6AFD1-AC0C-4A44-93B2-F12493F5941F@andrewg.com> <5698E151.8050907@digitalbrains.com> <569CE436.6090202@andrewg.com> Message-ID: <569CF180.2070501@digitalbrains.com> On 18/01/16 14:10, Andrew Gallagher wrote: > I find it funny that on a gpg users mailing list, out of 80 emails since > new year, only 15 have signatures at all, and three of those are mine*. > Even Werner doesn't sign his mails. Since it's been debated over and over again on this mailing list, I have nothing to add but: search the archives. I find it funny that people always dredge up the same old discussions. Hmmmm. Maybe not that funny, actually. I suppose we'll see more of this specific one now since TOFU makes people think of the discussion of signing all e-mails to mailing lists. 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 Jan 18 15:17:31 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 18 Jan 2016 09:17:31 -0500 Subject: Key selection order In-Reply-To: <569CE436.6090202@andrewg.com> References: <5697CC7C.7040603@sixdemonbag.org> <5697D507.6020501@andrewg.com> <5697F2E5.5060409@gmail.com> <477F0326-6B69-47D6-84F2-0888EF21944D@andrewg.com> <89f6fb0a548fda8e19ccd0ae22a33161@butters.digitalbrains.com> <4BC6AFD1-AC0C-4A44-93B2-F12493F5941F@andrewg.com> <5698E151.8050907@digitalbrains.com> <569CE436.6090202@andrewg.com> Message-ID: <569CF3FB.3050709@sixdemonbag.org> > I find it funny that on a gpg users mailing list, out of 80 emails since > new year, only 15 have signatures at all, and three of those are mine*. > Even Werner doesn't sign his mails. This is because in the absence of trust, signatures are meaningless. Who on this list has verified my certificate to any real degree? Samir Nassar, Patrick Brunschwig, maybe one or two others. Who on this list would invest my messages with a degree of trust they shouldn't? Many many more. For that reason, I show some caution with what messages I sign. I suspect many others are likewise. From samir at samirnassar.com Mon Jan 18 18:39:14 2016 From: samir at samirnassar.com (Samir Nassar) Date: Mon, 18 Jan 2016 18:39:14 +0100 Subject: Key selection order In-Reply-To: <569CF3FB.3050709@sixdemonbag.org> References: <569CE436.6090202@andrewg.com> <569CF3FB.3050709@sixdemonbag.org> Message-ID: <2525384.lCEbzBNMGu@forge> On Monday, January 18, 2016 09:17:31 AM Robert J. Hansen wrote: > This is because in the absence of trust, signatures are meaningless. > Who on this list has verified my certificate to any real degree? Samir > Nassar, Patrick Brunschwig, maybe one or two others. Who on this list > would invest my messages with a degree of trust they shouldn't? Many > many more. I can confirm this. Robert J. Hansen is indeed a real life human being and not a bot. -- Samir Nassar email: samir at samirnassar.com XMPP: samir at samirnassar.com web: samirnassar.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From andrey.od.utkin at gmail.com Mon Jan 18 21:40:06 2016 From: andrey.od.utkin at gmail.com (Andrey Utkin) Date: Mon, 18 Jan 2016 22:40:06 +0200 Subject: Constant "gpg: keyserver refresh failed: Invalid IPC response" Message-ID: <569D4DA6.3020407@gmail.com> This happens all the time with default key server hkp://keys.gnupg.net, with pgp.mit.edu it's the same, but slightly higher chance to get a proper result. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From stebe at mailbox.org Tue Jan 19 12:32:00 2016 From: stebe at mailbox.org (stebe at mailbox.org) Date: Tue, 19 Jan 2016 12:32:00 +0100 (CET) Subject: Bounces-address Message-ID: <271927060.5183.20c65a6a-d56f-4256-9df8-2ec826636d95.open-xchange@office.mailbox.org> On Sun, 17 Jan 2016 21:00, stebe at mailbox.org said: > why have I been receiving the mails of this list via gnupg-users-bounces > for a couple of months now, whereas before that I had been receiving > them > from the gnupg-users? Is there any reason for this? Mailman always uses a *-bounces address so to make bounce detection easier. Nothing has ever changed. Shalom-Salam, Werner I am sorry, that was my fault, you're obviously right. Sorry for simply pasting your answer into this new mail: at the moment I cannot send mails from my email client over smtp, only from the webmail interface. I already contacted my mail provider about ten days ago, they are still into it. There are two servers my computer connects to when I use tor (besides the entry guard): 1) 69.30.249.50 (ewaycia.com) 2)212.47.241.21 (sa1.sblo.ch) We're all still trying to find out whether it has something to do with them or not. Cheers, Stebe P.S. I plan to write a HowTo concerning installation and usage of NitrokeyPro with the latest gnupg2.1.10 version for the wiki, from the point of view of a beginner/medium-skilled user, if it fits in with the wiki's needs. From g.thaler at arcor.de Tue Jan 19 15:29:10 2016 From: g.thaler at arcor.de (=?UTF-8?Q?G=c3=bcnter_Thaler?=) Date: Tue, 19 Jan 2016 15:29:10 +0100 Subject: In wich commands can a certain option be used? Message-ID: <569E4836.7080009@arcor.de> Hello everyone, GnuPG version: 2.029 I'm new to GnuPG and so I have some questions that I cannot answer by reading the documentation. GnuPG supports a lot of options and many commands. Is there anywhere in one of the the documentations a list of commands, for wchich a certain option can be used? Maybe I have read the documentation too less carefully. In the description of the options tghere are mentioned some commands sometimes. But this seems to be an exeption. Best regards G?nter -- Mag. G?nter Thaler Dr.-Robert-Graf-Stra?e 25/7/45 A-8010 Graz E-Mail: g.thaler at arcor.de Tel.: +43 664 / 20 63 047 Fax: +49 69 / 13 30 30 42 844 Wie verschl?sselt man E-Mails? http://www.crypto-fuer-alle.de/ From wub at partyvan.eu Tue Jan 19 23:55:27 2016 From: wub at partyvan.eu (Juuso Lapinlampi) Date: Tue, 19 Jan 2016 22:55:27 +0000 (UTC) Subject: New GnuPG FTP mirror: mirror.se.partyvan.eu Message-ID: <12463124908579336241.enqueue@partyvan.eu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 It's been a few weeks since my previous post to this list. > I noticed the FTP Mirrors page [1] is outdated. Many mirrors are dead, > some have not existed for perhaps years. The fair amount of confusion > that came from that page made me initially delay with the decision to > host a new mirror - I wasn't sure where to start. > - ftp: n/a > - http: http://mirror.se.partyvan.eu/pub/ftp.gnupg.org/gcrypt/ > - https: https://mirror.se.partyvan.eu/pub/ftp.gnupg.org/gcrypt/ > - onion: http://tpvj6abq225m5pcf.onion/pub/ftp.gnupg.org/gcrypt/ > - rsync: rsync://mirror.se.partyvan.eu/pub/ftp.gnupg.org/gcrypt/ Is this the appropriate list to suggest adding a mirror, or should I try in gnupg-devel instead? I don't even know where the source code for the GnuPG website is to submit patches for, or if anyone is paying attention to the dead mirrors. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWnr6JAAoJEJiZcbKmt69LygQQAICPisdwk8VXPDqi/ZA4ZPQK qJ0Ei95/7LRbgW0FFg0CCEEtek4jgnh7QgwIqO5ysfGA8EMstc4haWeqKK+ScUf1 grMyI10ALl/pYW3FwGCVv+7ddDEl9seocpOfNA7RgHCXgAUawFf0jPJJP7OOFVPE ymidI3P3aHiY1tqXO6krKB7GUUNzSOLh5/aGNTj8SfM4VxTGbFhQToD697dM0cC8 9wosPYwoPdnCnGzriXNMmVLbn938u+T9mY1XBAxmKlYr8sxFSAhSi3s39urEric9 7Palk1uKHp+gfvGXG06nltrnUYqySHSusW1E7Lyq9RrGahq4sTHradM+bJo21pqm K+X0wbgLrv3CrP7mXD9t85valpDtpLousRQ+XAdnclOswtJr9vdNA5rXMp8Yp0VZ OCyhr/qgexCC6qcN2+nCwAxj4mKpkPyZsXrUEpPBySY3zQf1hOnxYu6pQrnCTryh d+E6lH56Inm6a/LAsTRPlRtobqsQKbjo6v87jsxA7CMhufpgxOzBuYOIrCYAVSY5 8oEigosv/DkrwLGlprUzmqFHQYVr4QmhjputmmsT7jCHjR7GUR7HP5X0qwEy6C65 y2u0AF9FwYcjBZt93U5gE/WtsMO/1k2F9FeS9DApTW8rcwULP9pDW4s89fBueDaj PDNhj3SaCNoqMs91XcGZ =CzCN -----END PGP SIGNATURE----- From felix.klee at inka.de Wed Jan 20 17:48:21 2016 From: felix.klee at inka.de (Felix E. Klee) Date: Wed, 20 Jan 2016 17:48:21 +0100 Subject: How to export ASCII armored secret key without passphrase? Message-ID: There?s a known issue: Is there any workaround? For example, could I export an ASCII armored key with a passphrase, then decrypt the exported key? Command that failed without passphrase (the key doesn't have one): $ gpg --armor --export-secret-keys >key.txt Affected version of GnuPG is 2.1.10. With 2.0.19 I did not run into this issue. From peter at digitalbrains.com Wed Jan 20 18:13:47 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 20 Jan 2016 18:13:47 +0100 Subject: How to export ASCII armored secret key without passphrase? In-Reply-To: References: Message-ID: <569FC04B.6000604@digitalbrains.com> On 20/01/16 17:48, Felix E. Klee wrote: > Is there any workaround? Install GnuPG 1.4 alongside your 2.1.10 (they co-exist perfectly, but they store keys separately). It then should be something like this: $ gpg2 --export-secret-keys | gpg --import Give some temporary passphrase, passes key from 2.1.10 to 1.4. $ gpg --edit-key [...] gpg> passwd Enter temporary passphrase to unlock, then give new, empty passphrase, confirm empty passphrase. gpg> save Now 1.4 has a passphraseless copy of the key $ gpg --armour -o key.asc --export-secret-keys Now key.asc should hold a passphraseless copy of your keys. Remember that it is also still passphraseless in the key storage of 1.4, in case that matters. An alternative if you only want passphraseless subkeys would be: $ gpg2 --export-secret-subkeys | gpg --import $ gpg --armour -o key.asc --export-options export-reset-subkey-password --export-secret-subkeys This merely holds a stub for the primary key: there is no secret material for the primary key. > Command that failed without passphrase (the key doesn't have one): > > $ gpg --armor --export-secret-keys >key.txt Is your GnuPG 2.1.10 binary invoked as "gpg", not as "gpg2"? Which OS is this and where did you get GnuPG 2.1.10? This might be an issue if you want to install GnuPG 1.4 alongside. I believe in Debian, the plan is to name the 2.1 binary gpg and the 1.4 binary gpg1, but that hasn't been done yet AFAIK. 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 okhin at okhin.fr Wed Jan 20 16:05:40 2016 From: okhin at okhin.fr (Okhin) Date: Wed, 20 Jan 2016 16:05:40 +0100 Subject: libgcrypt and decrypting Session Key of Symmetrically Encrypted Messages Message-ID: <1453302340.2639.14.camel@okhin.fr> Hello list, I'm currently working on a library to be able to encrypt/decrypt data server side in python. I've already binded (using python cffi) the libgcrypt code (code is available on?https://git.okhin.fr/?p=okhin/pygc rypt.git). I can decrypt messages Symmetrically Encrypted (tag 9 or 18 according to RFC4880), I can also symmetrically encrypt and decrypt random bytes of text using the libgcrypt function : gcry_error_t gcry_pk_decrypt (gcry_sexp_t *r_plain, gcry_sexp_t data, gcry_sexp_t skey) (from the online documentation:?https://www.gnupg.org/documentation/man uals/gcrypt/Cryptographic-Functions.html#Cryptographic-Functions). I'm using GnuPG 2.1.0 and libgcrypt 1.6.4. My issue is that, when I try to decrypt the public key encrypted essage (message_ok.asc attached, private_key_ok.asc attached, protected with passphrase 'passphrase') I cannot manage to extract the session key from the packet tagged 1. I can extract the session key from teh command line $ gpg --show-session-key testdata/message_ok.asc? gpg: encrypted with 2048-bit RSA key, ID 0x0162F5906FA9F361, created 2015-11-10 ??????"test at example.com" gpg: session key: '9:83DBAB3308B34C1A0ABB6B0C086EF822E3ECC52AAC5A8F17EE69EF2317617A01' But I cannot extract it from the code. If I'm reading the RFC4880 correctly, the session key is EME PKC1 v1.5 encoded. So it should start with a 0x00 and followed by a 0x02 which is not. The decryption gave me the following S-Expression, and I do not understand how to convert it into a session-key. (value #00CDB5663396D77319CD6CD76A34A254946A88B6932808D4BA975984F3340364090BED E92460288E162976113EB499A0C35B86C2F9560C7BCE201081E5A49CF434093D4304831 E1AA5EDB1D4F15C61ABD9615F707E6BE694C1E7E9D764514900A8AC47575566BBE8205F D885E5146164BD04D77F1D1EC2F2BF4F1B5AD5A55E75A44911941097CF8AEC5C28FB4F9 DD2647DA60C59317601F3832DD845E51F06EB7753C0C1449E32E164B339182261613070 3F21E09979D0CE270B6684DF510064427B101D19AC820B3363E784F238A7A0C5AF787A6 3B060DE74C77F243C770E05704941185D26E63464AFD6F10DD751CDF1F7429A614DD0A1 E91173E0C83CE08646#) The gcry_pk_encrypt is called with those two S-Expression: data = (enc-val? ?(flags) ?(rsa? ? (a #1024BEF1B6A8EE811A0E8587E31CC993B07AD446A05EA3B03CDA22317835EBC32B8610 C7C9C8D034BA13744219F020379C9FA0FCE782C2BA5E91A52B18ADA21D101A4AF66D58E 840E6CBC7863FD701574FF447368E03421DF428653D9F5E391A539297AAC8DCDA27CCA2 6DBF8DF5942B501C52CE5BD3B161D96E8C79F687559B04055F2FC9E3F9FBABEC3B75AAB 1C62AE714977F44862860BC05B098FD9C7465B3197A27CBC36F23DC64D691E6CA4A9E76 28FE73C78B3022DAA91876CFFC8F2F124D4056AD9A866FADCF98754F94D361510BF352A EE8929F9118DAB0B830DCB1A3252B14EADB3EBCEF2FB909F73418E4A83CD61A98627D58 E2F53569B20C53D0#) ? ) ?) skey = ?(private-key? ?(rsa? ? (q #F9F2DB0F0246757FDB453A2368F208C23DC8560448B009A3A84A2C25692F881790B1E0 E0CBB2B83F99C5AAA21577FF8675ABFA19BA74F542274695F2C4D096598CA74E4F1F50F 410221FA7D63B57082D2BB4797ECFA5DBB65B032320F02BD192337DD1BE8E3518FCADF2 A859D91DA50E1753AA6E40D538B4E233228DD86AE6D1#) ? (n #F142B7BFB87F2E4FF33DFCCA59CD644E05B88B322B2BDBBD51DC7B9374D465253DBCE4 1DF53AA023CA2B8ECBE5A4D209329FB34D3E2977F6EA4CB4B5C4948FE406DF76B9F28C4 468D155E14FF71284E55B0996A3851F7B5D56B7298402169CD612A687F291617D1F7D03 5D4D29AA0157B7497B09462DD8B99FB0083C636F734551AA9C1F7B2CCB6A97A93502EA8 5706EE5742B0BC8CD4085E856C14C4F85D228FD42EFC9DC3C523CEAE17EC0FDA2E79CE9 03B86EDB122F07E4A9EAB0FD34CE208DFF54A4C27728690DAEFCA4175F0E8C1244885F8 28A4F26678EF766F09605AD0C281A94DEF01371DEFFA934893A439D375545BB7EF99CA8 7C35011F74BCB1EF#) ? (d #2DCAA303B1A9FA0954BAC43B47F632FE981961DA20D58F3C8CC81370767145CD5EBD76 72B533EE673C9D2DDA4779142088CA4506F93077C396CEFE51ADC120DA7FEF74227105E C8A14897F5D6520CFB694A3EA429926D38C70C40D0E3033488B5D38DC7ECED7391F7BE3 E2969DBCD5CA67507C18D3882A257948B917752C172D87AE08D879FF178A501ECE34C72 2459F0F6D99C986B0CEAACFABCC99AB2669394CB6C4C4B9116FD70FBC49BC991A465D41 C4DEE763B9BF5F77A7DCC1E7B7303789C692C9666944483C4732FFEFED2E828B717A165 112615EC880B616DFD5C75269563951DFE9C6580BC3B9B83E138B1C615A17089308C5FA 85C0C4CF07B17AA1#) ? (p #F71A03D11678F087864D7FDA10E056F4CF16F82D95C203DF6C7840FD2AF359FB91A6B2 ED24945DF2364E4837A0976AE8148167AEFD3BCBBEB8A5D16207E1A8317D12344FCF186 6BD0D920586877C071E02F154B61D5732C5467309C540826C68B58AB8A0C7E5F7306E1E 1DC53A0BD7ABDDCA129D081C8203743C788E4429BCBF#) ? (u #0F68FEC7E73657FB4456A7CBF4110D845FD6CACD1783F330F149D0BDF877AFA620A9E6 3D322CB482056EA788D3D3135D58C3C120A1FA25B30CF556040DF538D90621889E5065B 1EC8D2621B99A4BC0AEE325E164894FFAEC442E864361418774620BA85D6575AA7E2DAF 4B197BF83F8AE1FA6EA4C9F9FA77FF34CDF30785E3BF#) ? (e #010001#) ? ) ?) I'm attaching the armored message and private_key (passphrase protected, passphrase is: 'passphrase' wthout quotes). I suspect there's an issue with my data S-expression, I'm perhap's missing some parameters here ? Thanks for your patience and help, Regards Okhin -------------- next part -------------- A non-text attachment was scrubbed... Name: message_ok.asc Type: application/pgp-encrypted Size: 608 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: private_key_block_ok.asc Type: application/pgp-keys Size: 3569 bytes Desc: not available URL: From stebe at mailbox.org Wed Jan 20 21:19:05 2016 From: stebe at mailbox.org (stebe at mailbox.org) Date: Wed, 20 Jan 2016 21:19:05 +0100 (CET) Subject: In wich commands can a certain option be used? Message-ID: <1687533008.1065.de08ed73-f9ab-4718-b848-5569387fe7fe.open-xchange@office.mailbox.org> Hi, >Hello everyone, >GnuPG version: 2.029 >I'm new to GnuPG and so I have some questions that I cannot answer by >reading the documentation. >GnuPG supports a lot of options and many commands. Is there anywhere in >one of the the documentations a list of commands, for wchich a certain >option can be used? >Maybe I have read the documentation too less carefully. In the >description of the options tghere are mentioned some commands sometimes. >But this seems to be an exeption. I see that none of the experts has answered you so far, so I'll give it a try. As far as I know, there is no complete listing of all the commands detailing all possible options to use with each of them. In the manpages the commands and options are grouped depending on the context, i.e. the operation you want to carry out. The "list-options parameters" given in line 912 (more or less) of the manpages detail the options to use with the different --list commands, further on there is a section that explains the options to use with the verify command. The info gnupg manual gives you another option summary (in chapter 3.2) detailing the available options depending on the context. So, it is more focused on what you actually want to do. You may only use one command (at a time) but you can combine it with several options. There may be options you may not want to use together as they make no sense, but, in general, gpg/gpg2 will let you know. So, what is it that you actually want to do? Or was it just a general question? Cheers, Stebe From tzafrir at cohens.org.il Thu Jan 21 06:54:19 2016 From: tzafrir at cohens.org.il (Tzafrir Cohen) Date: Thu, 21 Jan 2016 06:54:19 +0100 Subject: problem signing with a smart card Message-ID: <20160121055418.GJ7630@lemon.cohens.org.il> Hi, I have a g10code PGP smart card. Recently I have not been able to sign using the card. I generated a test gnupg directory to test stuff on a copy of the data: I tried using various versions of gpg1 and gpg2 (.0), and all seem to behave similarly, though I checked gpg (1.4.20) and gpg2 (2.0.28) most extensively. $ gpg2 --home $PWD --list-secret-keys /home/tzafrir/gpgtest/secring.gpg --------------------------------- sec 4096R/19765111 2013-08-08 [expires: 2023-08-06] uid Tzafrir Cohen uid Tzafrir Cohen uid Tzafrir Cohen ssb> 3072R/0325A0CE 2014-09-29 ssb> 3072R/AFFB7FAE 2014-09-29 ssb> 3072R/07DAF838 2014-09-29 ssb 2048R/BBB53C25 2016-01-21 gpg2 --card-status shows keys matching to those three keys. The last subkey is one I generated for testing. The following work as expected: echo hi | /usr/bin/gpg --home $PWD --default-key '19765111!' --sign -a echo hi | /usr/bin/gpg --home $PWD --default-key 'BBB53C25!' --sign -a However: echo hi | /usr/bin/gpg --home $PWD --default-key '0325A0CE!' --sign -a Gives: gpg: no default secret key: unusable secret key gpg: signing failed: unusable secret key If I omit the option --default-key or give there 19765111, I get a signature by BBB53C25 (and before I created it: by the main key). I did verify I can use the encryption key to decrypt some encrypted files I had (this works just fine). What more can I do to check where the problem is? System is Debian Testing. -- Tzafrir Cohen | tzafrir at jabber.org | VIM is http://tzafrir.org.il | | a Mutt's tzafrir at cohens.org.il | | best tzafrir at debian.org | | friend From gniibe at fsij.org Thu Jan 21 08:50:37 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 21 Jan 2016 16:50:37 +0900 Subject: problem signing with a smart card In-Reply-To: <20160121055418.GJ7630@lemon.cohens.org.il> References: <20160121055418.GJ7630@lemon.cohens.org.il> Message-ID: <56A08DCD.4050202@fsij.org> On 01/21/2016 02:54 PM, Tzafrir Cohen wrote: > $ gpg2 --home $PWD --list-secret-keys > /home/tzafrir/gpgtest/secring.gpg > --------------------------------- > sec 4096R/19765111 2013-08-08 [expires: 2023-08-06] > uid Tzafrir Cohen > uid Tzafrir Cohen > uid Tzafrir Cohen > ssb> 3072R/0325A0CE 2014-09-29 > ssb> 3072R/AFFB7FAE 2014-09-29 > ssb> 3072R/07DAF838 2014-09-29 > ssb 2048R/BBB53C25 2016-01-21 > > gpg2 --card-status shows keys matching to those three keys. In the above example, you have a primary key and four sub keys. How three keys are on your card? Please don't omit the output of gpg2 --card-status. That's mostly important to answer your question(s). It seems that you would confuse the capability of OpenPGPcard. It has three key slots, but the usage is defined as: sign, decrypt, and authentication. When you store your private key to signing slot, you can sign. When you store your private key to decryption slot, you can decrypt. When you store your private key to authenticationslot, you can authenticate (say, with SSH). I mean, you can only store a single signing key on your card. -- From tzafrir at cohens.org.il Thu Jan 21 09:54:19 2016 From: tzafrir at cohens.org.il (Tzafrir Cohen) Date: Thu, 21 Jan 2016 09:54:19 +0100 Subject: problem signing with a smart card In-Reply-To: <56A08DCD.4050202@fsij.org> References: <20160121055418.GJ7630@lemon.cohens.org.il> <56A08DCD.4050202@fsij.org> Message-ID: <20160121085419.GK7630@lemon.cohens.org.il> On Thu, Jan 21, 2016 at 04:50:37PM +0900, NIIBE Yutaka wrote: > On 01/21/2016 02:54 PM, Tzafrir Cohen wrote: > > $ gpg2 --home $PWD --list-secret-keys > > /home/tzafrir/gpgtest/secring.gpg > > --------------------------------- > > sec 4096R/19765111 2013-08-08 [expires: 2023-08-06] > > uid Tzafrir Cohen > > uid Tzafrir Cohen > > uid Tzafrir Cohen > > ssb> 3072R/0325A0CE 2014-09-29 > > ssb> 3072R/AFFB7FAE 2014-09-29 > > ssb> 3072R/07DAF838 2014-09-29 > > ssb 2048R/BBB53C25 2016-01-21 > > > > gpg2 --card-status shows keys matching to those three keys. > > In the above example, you have a primary key and four sub keys. How > three keys are on your card? Please don't omit the output of gpg2 > --card-status. That's mostly important to answer your question(s). > > It seems that you would confuse the capability of OpenPGPcard. It has > three key slots, but the usage is defined as: sign, decrypt, and > authentication. > > When you store your private key to signing slot, you can sign. > When you store your private key to decryption slot, you can decrypt. > When you store your private key to authenticationslot, you can > authenticate (say, with SSH). > > I mean, you can only store a single signing key on your card. Thanks. It seems I missed the obvious. The key on the card expired. And indeed: $ echo hi | faketime 'last year' /usr/bin/gpg --home $PWD --sign -a # Works So I guess I should just create new subkeys in the card. Thanks for your reply. -- Tzafrir Cohen | tzafrir at jabber.org | VIM is http://tzafrir.org.il | | a Mutt's tzafrir at cohens.org.il | | best tzafrir at debian.org | | friend From peter at digitalbrains.com Thu Jan 21 11:13:47 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 21 Jan 2016 11:13:47 +0100 Subject: problem signing with a smart card In-Reply-To: <20160121085419.GK7630@lemon.cohens.org.il> References: <20160121055418.GJ7630@lemon.cohens.org.il> <56A08DCD.4050202@fsij.org> <20160121085419.GK7630@lemon.cohens.org.il> Message-ID: <56A0AF5B.3060809@digitalbrains.com> On 21/01/16 09:54, Tzafrir Cohen wrote: > So I guess I should just create new subkeys in the card. That's fine for the signature key, although you could also extend its expiration date. But rotating signature keys is generally no more work than distributing the extended expiration date, so IMHO you might as well generate a new one. But do note well that if you generate a new encryption subkey, you can no longer use the smartcard to decrypt stuff encrypted to the old encryption subkey! I'd hate for you to just go ahead and discover you've just thrown out your only copy of the encryption subkey... By the way, in my opinion, you should always have a backup of your encryption subkey if it's on a card, because cards can break. 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 lachlan at twopif.net Thu Jan 21 12:32:14 2016 From: lachlan at twopif.net (Lachlan Gunn) Date: Thu, 21 Jan 2016 12:32:14 +0100 Subject: Rotating encryption keys (was: problem signing with a smart card) In-Reply-To: <482f4f17254a2b3c8faa2b32715e9773@butters.digitalbrains.com> References: <20160121055418.GJ7630@lemon.cohens.org.il> <56A08DCD.4050202@fsij.org> <20160121085419.GK7630@lemon.cohens.org.il> <56A0AF5B.3060809@digitalbrains.com> <482f4f17254a2b3c8faa2b32715e9773@butters.digitalbrains.com> Message-ID: > Not that I'm aware of. Ok, thanks, might make an interesting project then if I get some more free time. > Without any rigorous thought having yet gone into it, it seems they have the same /effective/ properties. The first reason is that you can't do it if the key only exists on a smart card. The second is that you now have to do one decryption per message, so if the key is on a smartcard then it becomes more time-consuming to compromise the whole database, but this is kind of marginal, I admit. You can safely put the database on Dropbox or something because it contains the same information as in the encrypted messages, just with a different recipient effectively. Thanks, Lachlan -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at digitalbrains.com Thu Jan 21 13:07:11 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 21 Jan 2016 13:07:11 +0100 Subject: Rotating encryption keys In-Reply-To: References: <20160121055418.GJ7630@lemon.cohens.org.il> <56A08DCD.4050202@fsij.org> <20160121085419.GK7630@lemon.cohens.org.il> <56A0AF5B.3060809@digitalbrains.com> <482f4f17254a2b3c8faa2b32715e9773@butters.digitalbrains.com> Message-ID: <56A0C9EF.5070909@digitalbrains.com> On 21/01/16 12:32, Lachlan Gunn wrote: > The first reason is that you can't do it if the key only exists on a > smart card. I'd say that's a bad idea anyway. What if the smartcard breaks? > The second is that you now have to do one decryption per > message, so if the key is on a smartcard then it becomes more > time-consuming to compromise the whole database, but this is kind of > marginal, I admit. I don't understand. The log with session keys requires one smartcard decryption to decrypt the whole log. The old private subkey requires one smartcard decryption to decrypt the material, and then one "computer" decryption per item encrypted to it, so it takes more time. Also, we're talking about compromise, but instead of measuring the amount of time it takes to crack something, we're talking about the amount of time it takes to do regular crypto? That seems silly, is the only attacker in your threat model using a Commodore 64 or other homecomputer from the 80's to access your encrypted material? > You can safely put the database on Dropbox or something because it > contains the same information as in the encrypted messages, just with a > different recipient effectively. Effectively, the same goes for the encrypted old subkey, AFAICS. Both hold a session key encrypted to the new subkey, and a symmetrically encrypted payload that serves to decrypt all your old data. This symmetric encryption is the same as used on the encrypted messages, so if it's not trustworthy, you're in trouble anyway. HTH, Peter. PS: One way to broadly approximate the "there is no other copy of this key" behaviour of a smartcard is: Buy two smartcards, use both regularly so you quickly notice one dying. Put the key on both, and also encrypt a copy of the key to itself, store the encrypted copy somewhere. When one smartcard breaks, buy a new one immediately. Take a secure system, use the other smartcard to decrypt the key and install it on the new smartcard. For a secure system, you can install a fresh copy of an operating system and thoroughly scrub it with itself afterwards. I think it's fun to watch an OS overwrite itself! Firmware-based exploits remain a problem, though. But I'm rapidly going into a wholly different topic. -- 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 Thu Jan 21 13:09:53 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 21 Jan 2016 13:09:53 +0100 Subject: Rotating encryption keys (was: problem signing with a smart card) In-Reply-To: References: <20160121055418.GJ7630@lemon.cohens.org.il> <56A08DCD.4050202@fsij.org> <20160121085419.GK7630@lemon.cohens.org.il> <56A0AF5B.3060809@digitalbrains.com> Message-ID: <56A0CA91.3050009@digitalbrains.com> (oops, accidentally forgot copy to list, sorry for thread breaks) On 2016-01-21 11:29, Lachlan Gunn wrote: > Speaking of which, is there any solution around for session key > archiving? Not that I'm aware of. > Key transition would be a bit more convenient if there > were some way to automatically maintain a log of (encrypted) session > keys for messages that youve seen, since you could then > mass-re-encrypt them when you change key. That's an interesting solution, I hadn't thought of that! But does it have better security properties than simply encrypting an on-disk copy of the old encryption subkey, encrypted to the new encryption subkey? That is a whole lot simpler. If somebody is able to decrypt the log of session keys, they can effectively decrypt everything encrypted to the old subkey. This is presuming the old encryption subkey is no longer used, so all data that was ever encrypted to the old subkey is in one of the logs (multiple, if the user has more than one computer). And if they can decrypt the on-disk copy of the old subkey, they can decrypt everything ever encrypted to the old subkey, and anything new that will be encrypted to the old subkey. But the latter is not going to happen. Without any rigorous thought having yet gone into it, it seems they have the same /effective/ properties. On the issue of usability: right now, an encrypted copy of an old subkey is a hassle to work with. But GnuPG could implement a feature that it automatically decrypts it using the current subkey, and then uses the old subkey to decrypt the data. In a generic form, this means that the private key storage, which currently only supports symmetric encryption in OpenPGP parlance, also supports public-key encryption. 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 lachlan at twopif.net Thu Jan 21 13:34:43 2016 From: lachlan at twopif.net (Lachlan Gunn) Date: Thu, 21 Jan 2016 13:34:43 +0100 Subject: Rotating encryption keys In-Reply-To: <56A0C9EF.5070909@digitalbrains.com> References: <20160121055418.GJ7630@lemon.cohens.org.il> <56A08DCD.4050202@fsij.org> <20160121085419.GK7630@lemon.cohens.org.il> <56A0AF5B.3060809@digitalbrains.com> <482f4f17254a2b3c8faa2b32715e9773@butters.digitalbrains.com> <56A0C9EF.5070909@digitalbrains.com> Message-ID: > > I'd say that's a bad idea anyway. What if the smartcard breaks? > Then you rotate to the new key with little or no data loss because all of the session keys are logged. You can generate the key on-chip so that it is unable to ever leave the smartcard, which is obviously desirable from a security point of view. > I don't understand. The log with session keys requires one smartcard > decryption to decrypt the whole log. The old private subkey requires one > smartcard decryption to decrypt the material, and then one "computer" > decryption per item encrypted to it, so it takes more time. Also, we're > talking about compromise, but instead of measuring the amount of time it > takes to crack something, we're talking about the amount of time it > takes to do regular crypto? That seems silly, is the only attacker in > your threat model using a Commodore 64 or other homecomputer from the > 80's to access your encrypted material? > I was suggesting that rather than having one big encrypted file with all the session keys, you public-key reencrypt each one as you decrypt it and then add it to the log. Putting the entire log under the same symmetric key is problematic because then you need to decrypt it every time you receive a message. As far as performance, yes, it's marginal, as I said originally. But if you have thousands of messages to decrypt using only a slow smartcard, maybe it will make a difference. The reason for separately doing each using public-key crypto is that you can add keys to the log without having the log's decryption key available. Effectively, the same goes for the encrypted old subkey, AFAICS. Both > hold a session key encrypted to the new subkey, and a symmetrically > encrypted payload that serves to decrypt all your old data. This > symmetric encryption is the same as used on the encrypted messages, so > if it's not trustworthy, you're in trouble anyway. > Yes, you're right, actually, I failed to account for the extra entropy involved over the passphrase-encrypted version. Thanks, Lachlan -------------- next part -------------- An HTML attachment was scrubbed... URL: From felix.klee at inka.de Thu Jan 21 12:45:43 2016 From: felix.klee at inka.de (Felix E. Klee) Date: Thu, 21 Jan 2016 12:45:43 +0100 Subject: How to export ASCII armored secret key without passphrase? In-Reply-To: <569FC04B.6000604@digitalbrains.com> References: <569FC04B.6000604@digitalbrains.com> Message-ID: On Wed, Jan 20, 2016 at 6:13 PM, Peter Lebbing wrote: > $ gpg2 --export-secret-keys | gpg --import Thanks! On my system, Arch, that?s: $ gpg --export-secret-keys | gpg1 --import From antoine.michard at chezgeek.fr Thu Jan 21 13:01:39 2016 From: antoine.michard at chezgeek.fr (Antoine Michard) Date: Thu, 21 Jan 2016 13:01:39 +0100 Subject: problem signing with a smart card In-Reply-To: <56A0AF5B.3060809@digitalbrains.com> References: <20160121055418.GJ7630@lemon.cohens.org.il> <56A08DCD.4050202@fsij.org> <20160121085419.GK7630@lemon.cohens.org.il> <56A0AF5B.3060809@digitalbrains.com> Message-ID: <56A0C8A3.5050608@chezgeek.fr> > But do note well that if you generate a new encryption subkey, you can > no longer use the smartcard to decrypt stuff encrypted to the old > encryption subkey! I'd hate for you to just go ahead and discover you've > just thrown out your only copy of the encryption subkey... I've made my master key on a computer offline and then use addcardkey command to add subkey on my card. I don't have backup and you say that if I lost my card I lost my encrypt file ?? So why people use subkey ?? Maybe only for people who have his key sign by other... :( I love GnuPG and crypto, but it's hard to find good information on it Antoine Michard GPG Key: 0xF5C9E7CD0882B381 Le 21/01/2016 11:13, Peter Lebbing a ?crit : > On 21/01/16 09:54, Tzafrir Cohen wrote: >> So I guess I should just create new subkeys in the card. > > That's fine for the signature key, although you could also extend its > expiration date. But rotating signature keys is generally no more work > than distributing the extended expiration date, so IMHO you might as > well generate a new one. > > But do note well that if you generate a new encryption subkey, you can > no longer use the smartcard to decrypt stuff encrypted to the old > encryption subkey! I'd hate for you to just go ahead and discover you've > just thrown out your only copy of the encryption subkey... > > By the way, in my opinion, you should always have a backup of your > encryption subkey if it's on a card, because cards can break. > > HTH, > > Peter. > -------------- 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 Thu Jan 21 14:23:38 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 21 Jan 2016 13:23:38 +0000 Subject: problem signing with a smart card In-Reply-To: <56A0C8A3.5050608@chezgeek.fr> References: <20160121055418.GJ7630@lemon.cohens.org.il> <56A08DCD.4050202@fsij.org> <20160121085419.GK7630@lemon.cohens.org.il> <56A0AF5B.3060809@digitalbrains.com> <56A0C8A3.5050608@chezgeek.fr> Message-ID: <56A0DBDA.2010504@andrewg.com> On 21/01/16 12:01, Antoine Michard wrote: > > I've made my master key on a computer offline and then use addcardkey > command to add subkey on my card. I don't have backup and you say that > if I lost my card I lost my encrypt file ?? So why people use subkey ?? The main reason for using an encryption subkey is that there is a known vulnerability where an attacker tricks a victim into signing a "message" that is actually the encrypted payload that the attacker wants to decrypt. This works a) because signing and decryption are equivalent mathematically and b) iff the victim uses the same key to both decrypt and sign. Using a separate subkey for encryption removes prerequisite b. A secondary reason for using a subkey (and this applies to signing and authentication subkeys also) is that if it gets compromised, you can revoke just that one subkey, rather than your entire key. This means that your trust relationships don't have to be rebuilt from scratch. As Peter said earlier, a smartcard key without a backup is inadvisable for most users. It's not so bad for a signing or authentication subkey, but if you lose your encryption key you've lost access to historical data. This is why I keep a copy of all my private key material on two Tails* encrypted partitions, stored separately. The easiest way to copy a key to a smartcard without losing the on-disk copy is to create an on-disk subkey, save, use "keytocard" to transfer it to the card and then quit without saving again. A (*) https://tails.boum.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Thu Jan 21 14:39:25 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 21 Jan 2016 14:39:25 +0100 Subject: Rotating encryption keys In-Reply-To: References: <20160121055418.GJ7630@lemon.cohens.org.il> <56A08DCD.4050202@fsij.org> <20160121085419.GK7630@lemon.cohens.org.il> <56A0AF5B.3060809@digitalbrains.com> <482f4f17254a2b3c8faa2b32715e9773@butters.digitalbrains.com> <56A0C9EF.5070909@digitalbrains.com> Message-ID: <56A0DF8D.7030001@digitalbrains.com> On 21/01/16 13:34, Lachlan Gunn wrote: > Then you rotate to the new key with little or no data loss because all of > the session keys are logged. You can generate the key on-chip so that it is > unable to ever leave the smartcard, which is obviously desirable from a > security point of view. I don't understand, what are the session keys encrypted with? I thought they were encrypted to the original smartcard subkey, which is dead. With two smartcards, you might be able to get by if you get all your correspondents to use the new subkey before the second smartcard dies. It seems much less of a problem, though, because you could ask them explicitly to re-encrypt if they encrypt to the old key. That construction would have it merits, but it seems complex. Complex things in crypto are best treated carefully. Or dismissed. All functionality introduces new places to make mistakes and kill security. > I was suggesting that rather than having one big encrypted file with all the > session keys, you public-key reencrypt each one as you decrypt it and then > add it to the log. Ah! Okay. I'm still not sure what you mean by re-encrypting; it seems you could just add the OpenPGP Public-Key Encrypted Session Key packet (along with an identifier to find it again on use). > Putting the entire log under the same symmetric key is problematic because > then you need to decrypt it every time you receive a message. That depends on the cipher mode; appending might be cheap. But this is academical; your construction seems better. Also, this means you can append to the log as soon as you see a message, rather then the first time the user decrypts it. That does, however, introduce the problem that you can't verify the correctness of the packet, meaning you just created a free append-only datastore for everyone to use since they can just send you data disguised as a packet encrypted to your key :). So I think that's not such a good idea after all. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Thu Jan 21 14:42:03 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 21 Jan 2016 14:42:03 +0100 Subject: On-card key generation (was: Rotating encryption keys) In-Reply-To: References: <20160121055418.GJ7630@lemon.cohens.org.il> <56A08DCD.4050202@fsij.org> <20160121085419.GK7630@lemon.cohens.org.il> <56A0AF5B.3060809@digitalbrains.com> <482f4f17254a2b3c8faa2b32715e9773@butters.digitalbrains.com> <56A0C9EF.5070909@digitalbrains.com> Message-ID: <56A0E02B.80102@digitalbrains.com> On 21/01/16 13:34, Lachlan Gunn wrote: > You can generate the key on-chip so that it is unable to ever leave the > smartcard, which is obviously desirable from a security point of view. I think I prefer off-card generation, with GnuPG's random number generator, rather than some low-power, proprietary hardware random number generator on a smartcard. 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 lachlan at twopif.net Thu Jan 21 15:06:43 2016 From: lachlan at twopif.net (Lachlan Gunn) Date: Thu, 21 Jan 2016 15:06:43 +0100 Subject: Rotating encryption keys In-Reply-To: <56A0DF8D.7030001@digitalbrains.com> References: <20160121055418.GJ7630@lemon.cohens.org.il> <56A08DCD.4050202@fsij.org> <20160121085419.GK7630@lemon.cohens.org.il> <56A0AF5B.3060809@digitalbrains.com> <482f4f17254a2b3c8faa2b32715e9773@butters.digitalbrains.com> <56A0C9EF.5070909@digitalbrains.com> <56A0DF8D.7030001@digitalbrains.com> Message-ID: > > I don't understand, what are the session keys encrypted with? I thought > they > were encrypted to the original smartcard subkey, which is dead. With two > smartcards, you might be able to get by if you get all your correspondents > to > use the new subkey before the second smartcard dies. It seems much less of > a > problem, though, because you could ask them explicitly to re-encrypt if > they > encrypt to the old key. > That's one way to do it, the other option is to use some other key that you have the option to keep offline. > That construction would have it merits, but it seems complex. Complex > things in > crypto are best treated carefully. Or dismissed. All functionality > introduces > new places to make mistakes and kill security. I agree. If I were implementing it then I'd save it with the same key by default and, with the option to encrypt to an arbitrary other key. Then you can keep it offline if so inclined, or have one common to an organisation or something. > Ah! Okay. I'm still not sure what you mean by re-encrypting; it seems you > could > just add the OpenPGP Public-Key Encrypted Session Key packet (along with an > identifier to find it again on use). Yes, if you're using the recipient's subkey then this is the easiest way. > That depends on the cipher mode; appending might be cheap. But this is > academical; your construction seems better. > I wasn't as clear as I should have been---I mean the session key gets decrypted, meaning that an attacker can get access to it in normal operation. If you use public-key encryption then the private key doesn't need to be used except during key transition. > Also, this means you can append to the log as soon as you see a message, > rather > then the first time the user decrypts it. That does, however, introduce the > problem that you can't verify the correctness of the packet, meaning you > just > created a free append-only datastore for everyone to use since they can > just > send you data disguised as a packet encrypted to your key :). So I think > that's > not such a good idea after all. That's true, though you can always deal with it in software. If you try to decrypt and it fails, then remove the key from the database. That said, it doesn't mesh well with hidden recipients and such so it's probably best to wait until it's decrypted. Thanks, Lachlan -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine.michard at chezgeek.fr Thu Jan 21 15:27:29 2016 From: antoine.michard at chezgeek.fr (Antoine Michard) Date: Thu, 21 Jan 2016 15:27:29 +0100 Subject: problem signing with a smart card In-Reply-To: <56A0DBDA.2010504@andrewg.com> References: <20160121055418.GJ7630@lemon.cohens.org.il> <56A08DCD.4050202@fsij.org> <20160121085419.GK7630@lemon.cohens.org.il> <56A0AF5B.3060809@digitalbrains.com> <56A0C8A3.5050608@chezgeek.fr> <56A0DBDA.2010504@andrewg.com> Message-ID: <56A0EAD1.4040205@chezgeek.fr> OK I've test it just to be sure, and you were right !! I need my smartcard event if my master key is in my keyring. So, what is the best to do ?? Restard my masterkey from scratch (nobody sign my key...) or delete my subkey on my card and copy my new subkey like you said ?? PS: I store my Master key on tail too and thinking to print it with paperkey. PS2: I can do the same with my authentication key, because if my key is compromise, my SSH server don't know it ! Right? Antoine Michard GPG Key: 0xF5C9E7CD0882B381 Le 21/01/2016 14:23, Andrew Gallagher a ?crit : > On 21/01/16 12:01, Antoine Michard wrote: >> >> I've made my master key on a computer offline and then use addcardkey >> command to add subkey on my card. I don't have backup and you say that >> if I lost my card I lost my encrypt file ?? So why people use subkey ?? > > The main reason for using an encryption subkey is that there is a known > vulnerability where an attacker tricks a victim into signing a "message" > that is actually the encrypted payload that the attacker wants to > decrypt. This works a) because signing and decryption are equivalent > mathematically and b) iff the victim uses the same key to both decrypt > and sign. Using a separate subkey for encryption removes prerequisite b. > > A secondary reason for using a subkey (and this applies to signing and > authentication subkeys also) is that if it gets compromised, you can > revoke just that one subkey, rather than your entire key. This means > that your trust relationships don't have to be rebuilt from scratch. > > As Peter said earlier, a smartcard key without a backup is inadvisable > for most users. It's not so bad for a signing or authentication subkey, > but if you lose your encryption key you've lost access to historical > data. This is why I keep a copy of all my private key material on two > Tails* encrypted partitions, stored separately. > > The easiest way to copy a key to a smartcard without losing the on-disk > copy is to create an on-disk subkey, save, use "keytocard" to transfer > it to the card and then quit without saving again. > > A > > (*) https://tails.boum.org > > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Thu Jan 21 15:47:27 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 21 Jan 2016 14:47:27 +0000 Subject: problem signing with a smart card In-Reply-To: <56A0EAD1.4040205@chezgeek.fr> References: <20160121055418.GJ7630@lemon.cohens.org.il> <56A08DCD.4050202@fsij.org> <20160121085419.GK7630@lemon.cohens.org.il> <56A0AF5B.3060809@digitalbrains.com> <56A0C8A3.5050608@chezgeek.fr> <56A0DBDA.2010504@andrewg.com> <56A0EAD1.4040205@chezgeek.fr> Message-ID: <56A0EF7F.7040505@andrewg.com> On 21/01/16 14:27, Antoine Michard wrote: > > So, what is the best to do ?? Restard my masterkey from scratch (nobody > sign my key...) or delete my subkey on my card and copy my new subkey > like you said ?? You shouldn't need to regenerate your master key, unless something else is wrong with it ;-). Just revoke the subkey you created on the smartcard, overwrite the smartcard key with a newly generated key (making sure NOT to "save" afterwards, see previous email) and republish. Maybe try the process out with a new temporary key to be sure you're doing it right (don't publish it, of course). > PS2: I can do the same with my authentication key, because if my key is > compromise, my SSH server don't know it ! Right? Yes. In addition, if you want the ssh server to automatically update your auth subkeys as you create and revoke them, you could try installing monkeysphere. A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Thu Jan 21 16:13:14 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 21 Jan 2016 16:13:14 +0100 Subject: problem signing with a smart card In-Reply-To: <56A0EF7F.7040505@andrewg.com> References: <20160121055418.GJ7630@lemon.cohens.org.il> <56A08DCD.4050202@fsij.org> <20160121085419.GK7630@lemon.cohens.org.il> <56A0AF5B.3060809@digitalbrains.com> <56A0C8A3.5050608@chezgeek.fr> <56A0DBDA.2010504@andrewg.com> <56A0EAD1.4040205@chezgeek.fr> <56A0EF7F.7040505@andrewg.com> Message-ID: <56A0F58A.3050105@digitalbrains.com> On 21/01/16 15:47, Andrew Gallagher wrote: > overwrite the smartcard key with a newly generated key Wait... Maybe I'm not following correctly, but to me it sounds like: - Antoine has an encryption key on his smartcard, but no backup. - If it is no longer possible to use the smartcard to decrypt data with, Antoine will lose access to all his previously encrypted data. - So to remedy, you suggest he replaces the *only copy* he has of that key with a new one which does have a backup. In effect, removing the fear of losing the key in the future by getting it over with and losing the key now. That's rather cynical. Is there any data already encrypted to that key?! > (making sure NOT to "save" afterwards, see previous email) and republish. If you do save accidentally, remove they newly generated subkey before publishing and start over. If you haven't published it yet, there's no need for revocation, just remove it with delkey. > Maybe try the process out with a new temporary key to be sure you're > doing it right (don't publish it, of course). That is very good advice in general. >> PS2: I can do the same with my authentication key, because if my key is >> compromise, my SSH server don't know it ! Right? > > Yes. Let's talk about two separate issues: - If the smartcard breaks, you don't have access to the key anymore and you need some alternative way of getting a new key authorized (the normal way being to log in and add it to authorized_keys, but you can't login with the old key anymore because the smartcard broke). - If your authentication subkey is /compromised/, you can still log in to the SSH server, install a new key by editing authorized_keys, and at the same time remove the old key from there. However, so can your attacker. Having a key backup doesn't help against compromise. 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 andrewg at andrewg.com Thu Jan 21 16:15:16 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 21 Jan 2016 15:15:16 +0000 Subject: problem signing with a smart card In-Reply-To: <56A0F58A.3050105@digitalbrains.com> References: <20160121055418.GJ7630@lemon.cohens.org.il> <56A08DCD.4050202@fsij.org> <20160121085419.GK7630@lemon.cohens.org.il> <56A0AF5B.3060809@digitalbrains.com> <56A0C8A3.5050608@chezgeek.fr> <56A0DBDA.2010504@andrewg.com> <56A0EAD1.4040205@chezgeek.fr> <56A0EF7F.7040505@andrewg.com> <56A0F58A.3050105@digitalbrains.com> Message-ID: <56A0F604.5000002@andrewg.com> On 21/01/16 15:13, Peter Lebbing wrote: > On 21/01/16 15:47, Andrew Gallagher wrote: >> overwrite the smartcard key with a newly generated key > Is there any data already encrypted to that key?! Good point! I understood that this was a fresh key. If it is not then no, overwriting it is a bad idea. A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Thu Jan 21 16:17:55 2016 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Thu, 21 Jan 2016 16:17:55 +0100 Subject: Rotating encryption keys In-Reply-To: <56A0CA91.3050009@digitalbrains.com> References: <20160121055418.GJ7630@lemon.cohens.org.il> <56A08DCD.4050202@fsij.org> <20160121085419.GK7630@lemon.cohens.org.il> <56A0AF5B.3060809@digitalbrains.com> <56A0CA91.3050009@digitalbrains.com> Message-ID: <56A0F6A3.9060805@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 01/21/2016 01:09 PM, Peter Lebbing wrote: > (oops, accidentally forgot copy to list, sorry for thread breaks) > > On 2016-01-21 11:29, Lachlan Gunn wrote: >> Speaking of which, is there any solution around for session key >> archiving? > > Not that I'm aware of. Not following this thread too closely, but I expect --show-session-key and --override-session-key has been discussed. - -- - ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Acta est fabula So ends the story -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJWoPaeAAoJECULev7WN52Fqd8H/j5aen0Ipnrqy26Zy7lyCvcb OPn/22auavq6/mzLAmz9FAaaCJCYUCJgBn4YWo2s3N7Ez8ytZsrpmcfQ/OQ0GCJL I8jIcft/iFOS/g+5O1Rf+r43+wYHNXLEs+Z1mUH18L520Erv/tmV0VZNkqNV0mNe bdq58ZXL1xsOa87dxjBtaFLNef0qH1w5lsYEN7+JmDxTZSSy/ea0J1jCwtKT0C6/ Uu60UGAtkpODvE98Q+SwcLFyc1BU+SdqeLu4buaCKFjKCm39wuXYRGfyhOVKdSsp tNt0BAQuZQ6RH8oKAOrxoL+DDQaxX8IDZ2eU3cI6Ka7d5sidg78d7uvaxr0yZpg= =C3Ro -----END PGP SIGNATURE----- From andrewg at andrewg.com Thu Jan 21 16:24:12 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 21 Jan 2016 15:24:12 +0000 Subject: problem signing with a smart card In-Reply-To: <56A0F58A.3050105@digitalbrains.com> References: <20160121055418.GJ7630@lemon.cohens.org.il> <56A08DCD.4050202@fsij.org> <20160121085419.GK7630@lemon.cohens.org.il> <56A0AF5B.3060809@digitalbrains.com> <56A0C8A3.5050608@chezgeek.fr> <56A0DBDA.2010504@andrewg.com> <56A0EAD1.4040205@chezgeek.fr> <56A0EF7F.7040505@andrewg.com> <56A0F58A.3050105@digitalbrains.com> Message-ID: <56A0F81C.9020302@andrewg.com> On 21/01/16 15:13, Peter Lebbing wrote: > On 21/01/16 15:47, Andrew Gallagher wrote: > >>> PS2: I can do the same with my authentication key, because if my key is >>> compromise, my SSH server don't know it ! Right? >> >> Yes. > > Let's talk about two separate issues: > > - If the smartcard breaks, you don't have access to the key anymore and > you need some alternative way of getting a new key authorized (the > normal way being to log in and add it to authorized_keys, but you can't > login with the old key anymore because the smartcard broke). > > - If your authentication subkey is /compromised/, you can still log in > to the SSH server, install a new key by editing authorized_keys, and at > the same time remove the old key from there. However, so can your > attacker. Having a key backup doesn't help against compromise. Yes to all the above. I'd just point out that the same considerations apply to any lost vs. stolen authentication token (e.g. password). A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Thu Jan 21 17:01:52 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 21 Jan 2016 17:01:52 +0100 Subject: Rotating encryption keys In-Reply-To: <56A0F6A3.9060805@sumptuouscapital.com> References: <20160121055418.GJ7630@lemon.cohens.org.il> <56A08DCD.4050202@fsij.org> <20160121085419.GK7630@lemon.cohens.org.il> <56A0AF5B.3060809@digitalbrains.com> <56A0CA91.3050009@digitalbrains.com> <56A0F6A3.9060805@sumptuouscapital.com> Message-ID: <56A100F0.8060300@digitalbrains.com> On 21/01/16 16:17, Kristian Fiskerstrand wrote: > Not following this thread too closely, but I expect --show-session-key > and --override-session-key has been discussed. No, not in this thread. I hadn't mentioned it since I focussed on the archival and rotation aspect, not access to a specific session key. But yes, there are those options to use. 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 antoine.michard at chezgeek.fr Thu Jan 21 17:30:55 2016 From: antoine.michard at chezgeek.fr (Antoine Michard) Date: Thu, 21 Jan 2016 17:30:55 +0100 Subject: problem signing with a smart card In-Reply-To: <56A0F81C.9020302@andrewg.com> References: <20160121055418.GJ7630@lemon.cohens.org.il> <56A08DCD.4050202@fsij.org> <20160121085419.GK7630@lemon.cohens.org.il> <56A0AF5B.3060809@digitalbrains.com> <56A0C8A3.5050608@chezgeek.fr> <56A0DBDA.2010504@andrewg.com> <56A0EAD1.4040205@chezgeek.fr> <56A0EF7F.7040505@andrewg.com> <56A0F58A.3050105@digitalbrains.com> <56A0F81C.9020302@andrewg.com> Message-ID: <56A107BF.1060800@chezgeek.fr> Thanks Andrew and Peter for your advice. Of course it is my old encryption key and have data encrypted with it, but there is not a lot file (maybe except for pass* :-/ ) I will thinking how to procede, backup masterkey before begin and hope I haven't forget encrypted data... I haven't heard about monkeysphere but I've found website so I will study it :) Thanks for every thing :D Antoine Michard GPG Key: 0xF5C9E7CD0882B381 Le 21/01/2016 16:24, Andrew Gallagher a ?crit : > On 21/01/16 15:13, Peter Lebbing wrote: >> On 21/01/16 15:47, Andrew Gallagher wrote: >> >>>> PS2: I can do the same with my authentication key, because if my key is >>>> compromise, my SSH server don't know it ! Right? >>> >>> Yes. >> >> Let's talk about two separate issues: >> >> - If the smartcard breaks, you don't have access to the key anymore and >> you need some alternative way of getting a new key authorized (the >> normal way being to log in and add it to authorized_keys, but you can't >> login with the old key anymore because the smartcard broke). >> >> - If your authentication subkey is /compromised/, you can still log in >> to the SSH server, install a new key by editing authorized_keys, and at >> the same time remove the old key from there. However, so can your >> attacker. Having a key backup doesn't help against compromise. > > Yes to all the above. I'd just point out that the same considerations > apply to any lost vs. stolen authentication token (e.g. password). > > A > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Fri Jan 22 13:32:27 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 Jan 2016 13:32:27 +0100 Subject: New GnuPG FTP mirror: mirror.se.partyvan.eu In-Reply-To: <17093789854478232448.enqueue@partyvan.eu> (Juuso Lapinlampi's message of "Thu, 24 Dec 2015 03:29:09 +0000 (UTC)") References: <17093789854478232448.enqueue@partyvan.eu> Message-ID: <87wpr1ztes.fsf@vigenere.g10code.de> On Thu, 24 Dec 2015 04:29, wub at partyvan.eu said: > Sunet announced to decommission last year, although it still seems to be They recently told me that and I removed that mirror. > This led me to believe there is no active GnuPG mirror available in > Sweden/Finland, so I have setup one for GnuPG on our mirror server in > Stockholm, Sweden. This mirror server is connected to a 1 Gbps > connection at AS42708 Portlane AB. Thanks you. > - https: https://mirror.se.partyvan.eu/pub/ftp.gnupg.org/gcrypt/ > - onion: http://tpvj6abq225m5pcf.onion/pub/ftp.gnupg.org/gcrypt/ > - rsync: rsync://mirror.se.partyvan.eu/pub/ftp.gnupg.org/gcrypt/ I have listed those. > If interested, I can setup syncing to happen more frequently too, e.g. > twice or four times a day. I don't think that is needed. I'll check the otehr servers later the day. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From fulanoperez at cryptolab.net Sat Jan 23 13:44:40 2016 From: fulanoperez at cryptolab.net (Fulano Diego Perez) Date: Sat, 23 Jan 2016 23:44:40 +1100 Subject: compile 2.1.10 no bzip2 ? In-Reply-To: <569452AD.9030007@fsij.org> References: <56936D64.1070102@cryptolab.net> <569452AD.9030007@fsij.org> Message-ID: <56A375B8.1000305@cryptolab.net> NIIBE Yutaka: > It seems for me that you don't have libbz2-dev package installed. > > $ sudo apt-get install libbz2-dev right /etc/apt/sources.list.bk From fulanoperez at cryptolab.net Sat Jan 23 14:11:28 2016 From: fulanoperez at cryptolab.net (Fulano Diego Perez) Date: Sun, 24 Jan 2016 00:11:28 +1100 Subject: 2.1.10 with libgcrypt 1.7.0-beta300 In-Reply-To: <56944E98.5000307@fsij.org> References: <5693BACF.5070005@cryptolab.net> <56944E98.5000307@fsij.org> Message-ID: <56A37C00.5080905@cryptolab.net> NIIBE Yutaka: > On 01/11/2016 11:23 PM, Fulano Diego Perez wrote: >> Can anybody confirm on debian stretch 64 a successful build with >> libgcrypt beta ? > > GnuGP and libgcrypt development version build successfully on my > 32-bit ARMv7l. > >> checking for LIBGCRYPT - version >= 1.6.0... yes (1.7.0-beta300) >> checking LIBGCRYPT API version... okay > > Good, you have the libgcrypt development version installed. > >> i cannot create curve25519 encryption sub keys >> >> gpg: agent_genkey failed: Invalid flag >> gpg: Key generation failed: Invalid flag >> >> but i could create NIST and Brainpool enc sub keys >> >> something's not right... >> >> still using 1.6.4 according to --version > > How do you install the libgcrypt on your system? > > If it's /usr/local/lib, you would need LD_LIBRARY_PATH setting. > > $ export LD_LIBRARY_PATH=/usr/local/lib > > For me, with LD_LIBRARY_PATH, it goes: > > $ gpg2 --version > gpg (GnuPG) 2.1.11-beta67 > libgcrypt 1.7.0-beta298 > NOTE: THIS IS A DEVELOPMENT VERSION! > It is only intended for test purposes and should NOT be > used in a production environment or with production keys! > Copyright (C) 2015 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > > Home: ~/.gnupg > Supported algorithms: > Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA > Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, > CAMELLIA128, CAMELLIA192, CAMELLIA256 > Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 > Compression: Uncompressed, ZIP, ZLIB, BZIP2 > > Please note that you need to invoke gpg-agent with LD_LIBRARY_PATH, too. can explain how you mean to invoke ? i export library path for gpg2 and shows expected libgcrypt version i can clearsign with ed25519 EDDSA subkey i have problem testing encryption with cv25519 subkey tried to test with $ fortune | gpg2 --sign --encrypt -u abc --recipient 123 --recipient 456 | gpg2 --decrypt gpg: ecdh failed in gcry_cipher_decrypt: Checksum error gpg: ecdh failed in gcry_cipher_decrypt: Checksum error gpg: encrypted with 256-bit ECDH key, ID test, created 2016 "test" gpg: public key decryption failed: Checksum error gpg: encrypted with 256-bit ECDH key, ID test, created 2016 test2 gpg: public key decryption failed: Checksum error gpg: decryption failed: No secret key i have secret key tried list-packets & -vvv - nothing more on errors maybe this is conflict with persistent gpg-agent and ssh-agent they are listed in htop with PID but no RAM use how can to figure this out ? same error is if i run thunderbird from terminal, with LD path i can run enigmail beta and see EDDSA and ECDH subkeys ok can sign EDDSA mail but no encrypt From wwongwong2013 at gmail.com Sat Jan 23 11:58:49 2016 From: wwongwong2013 at gmail.com (W Wong) Date: Sat, 23 Jan 2016 21:58:49 +1100 Subject: Different SHA1 Checksum using Microsoft file checksum integrity verifier Message-ID: Greeting all: I downloaded the Gpg4win 2.3.0 (Released: 2015-11-25) from https://www.gpg4win.org/download.html I did a checksum using Microsoft file checksum integrity verifier as follows: C:\Users\edsw\utility>fciv.exe ..\..\Downloads\gpg4win-2.3.0.exe // // File Checksum Integrity Verifier version 2.05. // 4a88f90a01b0ba8e3eb0073f7b6a4bfb ..\..\downloads\gpg4win-2.3.0.exe The checksum is different from the one announced on the site SHA1 checksum (for gpg4win2.3.0.exe): 88d90ee9a1ea3e66b198ea866063140b882444d5 I believe that nothing has been tampered with the version gpg4win-2.3.0.exe that I have downloaded. Is there any reason why the Microsoft file checksum integrity verifier (fciv) will produce a different checksum? May be the checksum announced on the https://www.gpg4win.org/download.html has not been updated for a while??? Please comment. Thanks in advance for your assistance with my query Best regards, Wyatt -------------- next part -------------- An HTML attachment was scrubbed... URL: From przemoc at gmail.com Sat Jan 23 12:29:25 2016 From: przemoc at gmail.com (=?UTF-8?Q?Przemys=C5=82aw_Pawe=C5=82czyk?=) Date: Sat, 23 Jan 2016 12:29:25 +0100 Subject: Key signing with non-primary UID Message-ID: Hi! I would like to sign someone's key with my non-primary UID. Why? To reflect that given UID is the one I use when contacting owner of the key I want to sign. I failed to find how I can do it, though. Previously, I asked about this on #gnupg IRC channel a few days ago. aef wrote there: > your user ID is usually not attached to the certification signature Later he added: > afaik, the RFC4880 5.2.3.22. "Signer's User ID" subpacket is not supported by GnuPG In the end he also wrote: > stay around, maybe i'm mistaken and someone corrects my words later > i'm not fully up-to-date on the state. though i'm rather convinced that it's not implemented The topic has not been brought up later, so now I'm reaching the ML. I'm using GnuPG 2.1.10. Is it possible nowadays to do what I want in it? If we can select whether we want to sign particular UID of someone's key, then I think we should be able to select which our UID will be used during key signing. P.S. Please CC me, I'm not on the ML. -- Przemys?aw 'Przemoc' Pawe?czyk http://przemoc.net/ From dkg at fifthhorseman.net Sun Jan 24 00:01:26 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 23 Jan 2016 18:01:26 -0500 Subject: Different SHA1 Checksum using Microsoft file checksum integrity verifier In-Reply-To: References: Message-ID: <87si1n99yx.fsf@alice.fifthhorseman.net> Hi Wyatt-- On Sat 2016-01-23 05:58:49 -0500, W Wong wrote: > I downloaded the Gpg4win 2.3.0 (Released: 2015-11-25) > from https://www.gpg4win.org/download.html > > I did a checksum using Microsoft file checksum integrity verifier as > follows: on any modern version of windows, you should be able to do checksum verification with certutil.exe using the -hashfile subcommand: https://technet.microsoft.com/en-us/library/cc732443.aspx#BKMK_hashfile > C:\Users\edsw\utility>fciv.exe ..\..\Downloads\gpg4win-2.3.0.exe > // > // File Checksum Integrity Verifier version 2.05. > // > 4a88f90a01b0ba8e3eb0073f7b6a4bfb ..\..\downloads\gpg4win-2.3.0.exe > > The checksum is different from the one announced on the site > > SHA1 checksum (for gpg4win2.3.0.exe): > 88d90ee9a1ea3e66b198ea866063140b882444d5 Note that the lengths are different, which suggests that they might be different digest algorithms entirely. I believe that fciv.exe is calculating the MD5 checksum, while the download site is using the SHA1 checksum. Indeed, i see the MD5 sum matching the value you found with fciv.exe, while the SHA1 sum matches the published data: 0 dkg at alice:~$ gpg2 --print-md MD5 < gpg4win-2.3.0.exe 4A 88 F9 0A 01 B0 BA 8E 3E B0 07 3F 7B 6A 4B FB 0 dkg at alice:~$ gpg2 --print-md SHA1 < gpg4win-2.3.0.exe 88D9 0EE9 A1EA 3E66 B198 EA86 6063 140B 8824 44D5 0 dkg at alice:~$ So i think your download is most likely ok (assuming that fciv is doing what i believe it is). fwiw, MD5 and SHA1 are both old digest algorithms, and are not as strong as they should be. I recommend that anyone using checksums for file integrity switch to SHA256 as soon as possible. Also, the OpenPGP signature published at https://files.gpg4win.org/gpg4win-2.3.0.exe.sig itself uses SHA1 internally. This is also a bad idea. signatures published today should use at least SHA256, as every modern OpenPGP implementation has been capable of verifying SHA256 signatures for years now. hth, --dkg From tom.browder at gmail.com Sat Jan 23 23:14:42 2016 From: tom.browder at gmail.com (Tom Browder) Date: Sat, 23 Jan 2016 16:14:42 -0600 Subject: Different SHA1 Checksum using Microsoft file checksum integrity verifier In-Reply-To: References: Message-ID: On Sat, Jan 23, 2016 at 4:58 AM, W Wong wrote: > I downloaded the Gpg4win 2.3.0 (Released: 2015-11-25) > from https://www.gpg4win.org/download.html ... > I did a checksum using Microsoft file checksum integrity verifier as > follows: > > C:\Users\edsw\utility>fciv.exe ..\..\Downloads\gpg4win-2.3.0.exe > > // > > // File Checksum Integrity Verifier version 2.05. > > // > > 4a88f90a01b0ba8e3eb0073f7b6a4bfb ..\..\downloads\gpg4win-2.3.0.exe Wyatt, that checksum is shorter than the one on the site. Make sure you use the '-sha1' option. -Tom From andrey.od.utkin at gmail.com Sat Jan 23 23:41:24 2016 From: andrey.od.utkin at gmail.com (Andrey Utkin) Date: Sun, 24 Jan 2016 00:41:24 +0200 Subject: How to export ASCII armored secret key without passphrase? In-Reply-To: <569FC04B.6000604@digitalbrains.com> References: <569FC04B.6000604@digitalbrains.com> Message-ID: <56A40194.50503@gmail.com> On 01/20/2016 07:13 PM, Peter Lebbing wrote: > Is your GnuPG 2.1.10 binary invoked as "gpg", not as "gpg2"? Which OS is this > and where did you get GnuPG 2.1.10? This might be an issue if you want to > install GnuPG 1.4 alongside. I believe in Debian, the plan is to name the 2.1 > binary gpg and the 1.4 binary gpg1, but that hasn't been done yet AFAIK. In Gentoo this is the case. And it also currently doesn't allow to have two installation at the same time. There's concept of slots, but nobody has cared enough to implement different slots for it. -- xmpp:andrey.utkin at decent.im -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From cmt at burggraben.net Sun Jan 24 12:54:34 2016 From: cmt at burggraben.net (Christoph Moench-Tegeder) Date: Sun, 24 Jan 2016 12:54:34 +0100 Subject: Different SHA1 Checksum using Microsoft file checksum integrity verifier In-Reply-To: References: Message-ID: <20160124115434.GB1532@elch.exwg.net> ## W Wong (wwongwong2013 at gmail.com): > 4a88f90a01b0ba8e3eb0073f7b6a4bfb ..\..\downloads\gpg4win-2.3.0.exe That is the MD5 checksum of the gpg4win-2.3.0.exe file, which has the SHA1 checksum 88d90ee9a1ea3e66b198ea866063140b882444d5. Regards, Christoph -- Spare Space From lists at ggp2.com Sun Jan 24 10:37:01 2016 From: lists at ggp2.com (lists at ggp2.com) Date: Sun, 24 Jan 2016 09:37:01 +0000 Subject: gpg: signing failed: Invalid IPC response Message-ID: <20160124093701.GA23193@ggp2.com> Hello! After upgrading my packages (now on gnupg 2.1.9), I am getting an error when trying to sign: $ echo "test"|gpg2 -sa gpg: signing failed: Invalid IPC response -----BEGIN PGP MESSAGE----- gpg: signing failed: Invalid IPC response gpg-agent.conf contains: pinentry-program /usr/local/bin/pinentry-gtk-2 and pinentry-gtk2 is asking for the passphrase properly. This is all on OpenBSD, and everything has been working fine prior to updating to 2.1.9. Here is some debug info from gpg-agent: 2016-01-24 09:26:33 gpg-agent[9415] listening on socket '/home/XX/.gnupg/S.gpg-agent' 2016-01-24 09:26:33 gpg-agent[13435] gpg-agent (GnuPG) 2.1.9 started 2016-01-24 09:26:34 gpg-agent[13435] handler 0x1817b661300 for fd 5 started 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 -> OK Pleased to meet you, process 12746 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 <- RESET 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 -> OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 <- OPTION ttytype=xterm 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 -> OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 <- OPTION display=:0 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 -> OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 <- OPTION xauthority=/home/XX/.Xauthority 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 -> OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 <- OPTION allow-pinentry-notify 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 -> OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 <- OPTION agent-awareness=2.1.0 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 -> OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 <- AGENT_ID 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 -> ERR 67109139 Unknown IPC command 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 <- HAVEKEY XXXXX 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 -> OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 <- RESET 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 -> OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 <- SIGKEY XXXXX 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 -> OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 <- SETKEYDESC Please+enter+the+passphrase+to+unlock+the+OpenPGP+secret+key:%0A%22XXXX%22%0A256-bit+EDDSA+key,+ID+XXXX,%0Acreated+XXX+(main+key+ID+XXXX).%0A 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 -> OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 <- SETHASH 10 XXXX 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 -> OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 <- PKSIGN 2016-01-24 09:26:34 gpg-agent[13435] starting a new PIN Entry 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 <- OK Pleased to meet you, process 13435 2016-01-24 09:26:34 gpg-agent[13435] DBG: connection to PIN entry established 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 -> OPTION grab 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 <- OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 -> OPTION ttytype=xterm 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 <- OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 -> OPTION allow-external-password-cache 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 <- OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 -> OPTION default-ok=_OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 <- OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 -> OPTION default-cancel=_Cancel 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 <- OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 -> OPTION default-yes=_Yes 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 <- ERR 83886254 Unknown option 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 -> OPTION default-no=_No 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 <- ERR 83886254 Unknown option 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 -> OPTION default-prompt=PIN: 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 <- OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 -> OPTION default-pwmngr=_Save in password manager 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 <- OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 -> OPTION default-cf-visi=Do you really want to make your passphrase visible on the screen? 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 <- ERR 83886254 Unknown option 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 -> OPTION default-tt-visi=Make passphrase visible 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 <- ERR 83886254 Unknown option 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 -> OPTION default-tt-hide=Hide passphrase 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 <- ERR 83886254 Unknown option 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 -> OPTION touch-file=/home/XX/.gnupg/S.gpg-agent 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 <- OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 -> GETINFO pid 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 <- D 14005 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 <- OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 -> INQUIRE PINENTRY_LAUNCHED 14005 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_5 <- END 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 -> SETKEYINFO n/XXX 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 <- OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 -> SETDESC Please enter the passphrase to unlock the OpenPGP secret key:%0A%22XXXX%22%0A256-bit EDDSA key, ID XXX,%0Acreated XXX (main key ID XXX).%0A 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 <- OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 -> SETPROMPT Passphrase: 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 <- OK 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 -> [[Confidential data not shown]] 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 <- [[Confidential data not shown]] 2016-01-24 09:26:34 gpg-agent[13435] DBG: error calling pinentry: Invalid IPC response 2016-01-24 09:26:34 gpg-agent[13435] DBG: chan_6 -> BYE 2016-01-24 09:26:40 gpg-agent[13435] failed to unprotect the secret key: Invalid IPC response 2016-01-24 09:26:40 gpg-agent[13435] failed to read the secret key 2016-01-24 09:26:40 gpg-agent[13435] command 'PKSIGN' failed: Invalid IPC response 2016-01-24 09:26:40 gpg-agent[13435] DBG: chan_5 -> ERR 83886340 Invalid IPC response 2016-01-24 09:26:40 gpg-agent[13435] DBG: chan_5 <- [eof] From wk at gnupg.org Sun Jan 24 19:55:38 2016 From: wk at gnupg.org (Werner Koch) Date: Sun, 24 Jan 2016 19:55:38 +0100 Subject: SHA-1 vs. SHA-256 checksums (was: Different SHA1 Checksum using Microsoft file checksum integrity verifier) In-Reply-To: <87si1n99yx.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Sat, 23 Jan 2016 18:01:26 -0500") References: <87si1n99yx.fsf@alice.fifthhorseman.net> Message-ID: <87si1myfh1.fsf_-_@vigenere.g10code.de> On Sun, 24 Jan 2016 00:01, dkg at fifthhorseman.net said: > fwiw, MD5 and SHA1 are both old digest algorithms, and are not as strong > as they should be. I recommend that anyone using checksums for file > integrity switch to SHA256 as soon as possible. That is correct for MD5 given how easy it is to create collisions. For SHA-1 the case is different because there is _currently_ no known way to create a collisions let alone creating a second pre-image. As soon as it will be possible to create collisions for SHA-1 the world does not break apart regarding the use of SHA-1 checksums to verify the integrity and origin of distributed files: Only those who are anyway distributing the file will be able to create two different files resulting in the same SHA-1 digest. Right, they could do interesting things with that capability (providing a different file for certain requesting IPs) but that is a pretty limited use case given that interesting targets would anyway not rely on simple checksums. Checksums are used as a stop-gap for those who are not able to verify a digital signature [1]. The problem is that there is no bulletproof way of verifying the checksum - we post it on the website and we distribute it via the announcement mail. Both are not very secure - if you are able to break SHA-1 today you will also be able to modify these resources. There are many easier ways to attack software distributions: I would start with one of the libraries or tools required in the build process where we have no way to check for tampering. It is wishful thinking that the development process of all the, say, several hundred developers with commit access to the software or the tools required in the build process would withstand a targeted attack. If you talk to people on how they verify SSH fingerprints (that is even MD5 for most installations), you will so often hear: ?Oh, I look at the first and a few of the last digits only?. We can assume that this won't be different for SHA-1 checksums - does anyone believe that by switching to SHA-256 they would check many more digits? I would even postulate that we will often hear a ?SHA-256 is more secure than SHA-1, thus I do not need to compare more digits?. Running empirical tests might result in an interesting paper. Such a research should then also look at the new hard to compare base-64 encoded SHA-256 fingerprints of OpenSSH). > Also, the OpenPGP signature published at > https://files.gpg4win.org/gpg4win-2.3.0.exe.sig itself uses SHA1 > internally. This is also a bad idea. signatures published today should Yes, that should be fixed because it is easy and not subject to the UX problems described above. FWIW, for GnuPG proper we switched to SHA-256 in 2012 (gnupg 1.4.12). Salam-Shalom, Werner [1] Right, the GnuPG speedo build script with its signed and published list of package versions also uses SHA-1 and that should be fixed before 2.2. (filed as bug at 2226) -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Sun Jan 24 20:08:21 2016 From: wk at gnupg.org (Werner Koch) Date: Sun, 24 Jan 2016 20:08:21 +0100 Subject: Key signing with non-primary UID In-Reply-To: (=?utf-8?Q?=22Przemys=C5=82aw_Pawe=C5=82czyk=22's?= message of "Sat, 23 Jan 2016 12:29:25 +0100") References: Message-ID: <87oacayevu.fsf@vigenere.g10code.de> On Sat, 23 Jan 2016 12:29, przemoc at gmail.com said: > I would like to sign someone's key with my non-primary UID. > Why? To reflect that given UID is the one I use when contacting owner You do not sign a key with a user id but with your key. Thus it does not make sense to declare which user id made the key-signature. There are too many cases which one would need to decide to make use of such a feature: What if the user id has been revoked or if the verifier does not got hold of that user id (it may be newer or removed later). Why should a key signature I once made with my revoked openit.de address gets void after the revocation of the address. It is still my key and thus me who certified your key+user-id. The Web-of-Trust as implemented by PGP and GnuPG can't make use of this info. You would need to come up with an extend WoT taking this in account. Given that the WoT does not really scale and is already complicated enough it is doubtful what the advantages of such a new trust model are. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Sun Jan 24 20:30:07 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 24 Jan 2016 14:30:07 -0500 Subject: SHA-1 vs. SHA-256 checksums (was: Different SHA1 Checksum using Microsoft file checksum integrity verifier) In-Reply-To: <87si1myfh1.fsf_-_@vigenere.g10code.de> References: <87si1n99yx.fsf@alice.fifthhorseman.net> <87si1myfh1.fsf_-_@vigenere.g10code.de> Message-ID: <87r3h67p34.fsf@alice.fifthhorseman.net> On Sun 2016-01-24 13:55:38 -0500, Werner Koch wrote: > If you talk to people on how they verify SSH fingerprints (that is even > MD5 for most installations) SSH key fingerprints are a different thing than software distribution checksums because the material digested in ssh originates entirely from one party, whereas the software distribution checksums can potentially be influenced by multiple parties. > you will so often hear: ?Oh, I look at the first and a few of the > last digits only?. right, this is not a cryptographically-strong verification :) > We can assume that this won't be different for SHA-1 checksums - does > anyone believe that by switching to SHA-256 they would check many more > digits? if they don't check more digits, then we can't help them. but it'd be nice to offer a way for people to do a cryptographically-strong check if they decide to do so. but in general, i agree with you that published checksums are stopgap measures at best, mainly fit for detecting corrupted downloads, and not particularly useful against a targeted attack. >> Also, the OpenPGP signature published at >> https://files.gpg4win.org/gpg4win-2.3.0.exe.sig itself uses SHA1 >> internally. This is also a bad idea. signatures published today should > > Yes, that should be fixed because it is easy and not subject to the UX > problems described above. FWIW, for GnuPG proper we switched to > SHA-256 in 2012 (gnupg 1.4.12). [...] > [1] Right, the GnuPG speedo build script with its signed and published > list of package versions also uses SHA-1 and that should be fixed > before 2.2. (filed as bug at 2226) great, thanks! --dkg From gniibe at fsij.org Mon Jan 25 02:33:40 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 25 Jan 2016 10:33:40 +0900 Subject: 2.1.10 with libgcrypt 1.7.0-beta300 In-Reply-To: <56A37C00.5080905@cryptolab.net> References: <5693BACF.5070005@cryptolab.net> <56944E98.5000307@fsij.org> <56A37C00.5080905@cryptolab.net> Message-ID: <56A57B74.80007@fsij.org> On 01/23/2016 10:11 PM, Fulano Diego Perez wrote: > NIIBE Yutaka: >> Please note that you need to invoke gpg-agent with LD_LIBRARY_PATH, too. > > can explain how you mean to invoke ? Well, it seems terminology issue. I mean, to start, to kick the service, and to run the service. In general, there are multiple ways. In my case on Debian, I have a startup script, /etc/X11/Xsession.d/90gpg-agent, which invokes gpg-agent. > i export library path for gpg2 and shows expected libgcrypt version Exporting library path is also needed for gpg-agent. > i can clearsign with ed25519 EDDSA subkey This can be done with libgcrypt 1.6.4. > i have problem testing encryption with cv25519 subkey > > > tried to test with $ fortune | gpg2 --sign --encrypt -u abc --recipient > 123 --recipient 456 | gpg2 --decrypt > > gpg: ecdh failed in gcry_cipher_decrypt: Checksum error > gpg: ecdh failed in gcry_cipher_decrypt: Checksum error > gpg: encrypted with 256-bit ECDH key, ID test, created 2016 > "test" > gpg: public key decryption failed: Checksum error > gpg: encrypted with 256-bit ECDH key, ID test, created 2016 > test2 > gpg: public key decryption failed: Checksum error > gpg: decryption failed: No secret key > > i have secret key I know. The problem is the version of libgcrypt of gpg-agent. Public key handling is the role of gpg frontend, while secret key handling is done by gpg-agent. With no newer libgcrypt, gpg-agent can't handle CV25519 keys. > tried list-packets & -vvv - nothing more on errors Yes. > maybe this is conflict with persistent gpg-agent and ssh-agent > they are listed in htop with PID but no RAM use > > how can to figure this out ? If you can check the process's memory maps of gpg-agent, you can see the maps to libgcrypt. In my case, I can see the entries in /proc//maps like: b7617000-b76d5000 r-xp 00000000 08:01 35743 /usr/local/lib/libgcrypt.so.20.1.0 b76d5000-b76d9000 rw-p 000bd000 08:01 35743 /usr/local/lib/libgcrypt.so.20.1.0 b76e7000-b76ef000 rw-p 00000000 00:00 0 -- From antoine.michard at chezgeek.fr Mon Jan 25 11:08:31 2016 From: antoine.michard at chezgeek.fr (Antoine Michard) Date: Mon, 25 Jan 2016 11:08:31 +0100 Subject: Master Key Best Practice with SmartCard Message-ID: <56A5F41F.6050005@chezgeek.fr> Hi all, In July when I've created my Master Key, I didn't use --expert option and now my master key is Cert and Sign and got 2 subkey for encryption (+1 revoke). pub 4096R/0882B381 cr?? : 2015-07-04 expire : jamais utilisation : SC confiance : ultime validit? : ultime sub 4096R/D693C37C cr?? : 2015-07-04 expire : jamais utilisation : E sub 4096R/AF2FF242 cr?? : 2015-07-04 expire : 2018-07-03 utilisation : S La clef suivante a ?t? r?voqu?e le 2016-01-21 par la clef RSA 0882B381 Antoine Michard sub 4096R/8FB824DE cr?? : 2015-07-04 r?voqu?e : 2016-01-21 utilisation : E sub 4096R/48D8D3B6 cr?? : 2015-07-05 expire : 2018-07-04 utilisation : A sub 4096R/DDCE51A2 cr?? : 2016-01-21 expire : 2018-07-03 utilisation : E [ ultime ] (1). Antoine Michard [ ultime ] (2) Antoine Michard [ ultime ] (3) Mitch It's work well except that for https://encrypt.to, he use my first encryption key and I can't decrypt it with my Smartcard. So I thinking what is the best to do next: - Delete my useless first subkey encryption from my keyring and send update to key server. - Recreate a new master key with only cert role and create all my subkey (S E A) and copy it to my Smart Card. What your advice on it ?? Nobody have sign my key and I can rencrypt my data. -- Antoine Michard GPG Key: 0xF5C9E7CD0882B381 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From list.gnupg-users at acme.nu Mon Jan 25 10:46:32 2016 From: list.gnupg-users at acme.nu (Jorgen Ottosson) Date: Mon, 25 Jan 2016 10:46:32 +0100 Subject: Problems with 4096 keys on 2.1 card Message-ID: Hi, I've been having some problems using a GPG card 2.1 with Ubuntu repo GPG, think it was 2.0.22. I noticed some discussions in Sept-15 about this and got the impression that it should work. Can someone just make a short comment on this, should a 2.0.22 be able to generate 4096 keys and/or import 4096 subkeys from keyring? The card and reader work ok and imports of shorter keys (like 3072) work without issues. This particular system is an Ubuntu 14.04 and the card is an OpenPGP Smartcard V2.1. TIA, From gniibe at fsij.org Mon Jan 25 13:07:31 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 25 Jan 2016 21:07:31 +0900 Subject: Problems with 4096 keys on 2.1 card In-Reply-To: References: Message-ID: <56A61003.203@fsij.org> On 01/25/2016 06:46 PM, Jorgen Ottosson wrote: > I noticed some discussions in Sept-15 about this and got the impression > that it should work. > > Can someone just make a short comment on this, should a 2.0.22 be able to > generate 4096 keys and/or import 4096 subkeys from keyring? > > The card and reader work ok and imports of shorter keys (like 3072) work > without issues. This particular system is an Ubuntu 14.04 and the card is > an OpenPGP Smartcard V2.1. I think that GnuPG 2.0.22 itself should work well. However, please note that many card readers have problems with larger APDU. Generating keys on card should be ok, but importing keys would be failed with bad reader. Signing should be ok, but decryption would be failed with bad reader. That's because of length of APDU. -- From andrey.od.utkin at gmail.com Mon Jan 25 14:17:40 2016 From: andrey.od.utkin at gmail.com (Andrey Utkin) Date: Mon, 25 Jan 2016 15:17:40 +0200 Subject: Master Key Best Practice with SmartCard In-Reply-To: <56A5F41F.6050005@chezgeek.fr> References: <56A5F41F.6050005@chezgeek.fr> Message-ID: <56A62074.1020701@gmail.com> On 25.01.2016 12:08, Antoine Michard wrote: > It's work well except that for https://encrypt.to, he use my first > encryption key and I can't decrypt it with my Smartcard. I'd report an issue to encrypt.to maintainer. encrypt.to also doesn't handle correctly the case when more than one key matches speceificed short key id, e.g. https://encrypt.to/0x70096AD1, the shown fingerprint doesn't change when you change selection. -- xmpp:andrey.utkin at decent.im -------------- 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 Jan 25 14:55:26 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 25 Jan 2016 13:55:26 +0000 Subject: Master Key Best Practice with SmartCard In-Reply-To: <56A5F41F.6050005@chezgeek.fr> References: <56A5F41F.6050005@chezgeek.fr> Message-ID: <56A6294E.8030007@andrewg.com> On 25/01/16 10:08, Antoine Michard wrote: > > So I thinking what is the best to do next: > - Delete my useless first subkey encryption from my keyring and send > update to key server. Once you've published a subkey it stays published. Deleting a previously published subkey only removes it from your local machine. It won't stop others from finding it on the keyservers and trying to use it. If you want to explicitly mark a subkey as "do not use" (but you do not believe that it has been compromised), then give it an expiration date of yesterday and republish. There's no particular reason to delete your local copy of the subkey (and there may be very good reasons not to, e.g. old encrypted data). NB expiration can be undone, but revocation cannot. (Remembering our previous conversation, you may instead want to expire your smartcard encryption subkey, and copy the other encryption subkey to the smartcard - but only if you have made a decrypted copy of all your sensitive data first.) > - Recreate a new master key with only cert role and create all my subkey > (S E A) and copy it to my Smart Card. If there's nothing wrong with your primary key there's no need to make a new one. I personally don't think having an extra usage flag counts as sufficiently "wrong" (so long as it's not "E"!). It may not be neat and tidy, but modern implementations should happily verify/auth against multiple subkeys. My current primary key has S,C,A usage and the S,A subkeys haven't caused me any issues so far. A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Mon Jan 25 14:59:53 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 25 Jan 2016 08:59:53 -0500 Subject: Master Key Best Practice with SmartCard In-Reply-To: <56A5F41F.6050005@chezgeek.fr> References: <56A5F41F.6050005@chezgeek.fr> Message-ID: <87k2mx69pi.fsf@alice.fifthhorseman.net> On Mon 2016-01-25 05:08:31 -0500, Antoine Michard wrote: > So I thinking what is the best to do next: > - Delete my useless first subkey encryption from my keyring and send > update to key server. If you don't want people to encrypt messages to your D693C37C subkey, you should revoke that subkey (and only that subkey), and publish your updated certificate to the keyservers. Just deleting the subkey from your certificate locally won't delete the associated copy on the keyserver, or provide anyone else with any indication that you don't intend to continue using it. > - Recreate a new master key with only cert role and create all my subkey > (S E A) and copy it to my Smart Card. This will just create additional confusion for you, because there will now be two certificates associated with your name. It's not the end of the world, but i don't think it would solve your problem as cleanly as the above approach. hth, --dkg From antoine.michard at chezgeek.fr Mon Jan 25 15:50:45 2016 From: antoine.michard at chezgeek.fr (Antoine Michard) Date: Mon, 25 Jan 2016 15:50:45 +0100 Subject: Master Key Best Practice with SmartCard In-Reply-To: <87k2mx69pi.fsf@alice.fifthhorseman.net> References: <56A5F41F.6050005@chezgeek.fr> <87k2mx69pi.fsf@alice.fifthhorseman.net> Message-ID: <56A63645.3040209@chezgeek.fr> >> It's work well except that for https://encrypt.to, he use my first >> encryption key and I can't decrypt it with my Smartcard. > > I'd report an issue to encrypt.to maintainer. > encrypt.to also doesn't handle correctly the case when more than one key > matches speceificed short key id, e.g. https://encrypt.to/0x70096AD1, > the shown fingerprint doesn't change when you change selection. I've previously report my problem too but I don't have any reply yet !! >> So I thinking what is the best to do next: >> - Delete my useless first subkey encryption from my keyring and send >> update to key server. > > Once you've published a subkey it stays published. Deleting a previously > published subkey only removes it from your local machine. It won't stop > others from finding it on the keyservers and trying to use it. > > If you want to explicitly mark a subkey as "do not use" (but you do not > believe that it has been compromised), then give it an expiration date > of yesterday and republish. There's no particular reason to delete your > local copy of the subkey (and there may be very good reasons not to, > e.g. old encrypted data). > > NB expiration can be undone, but revocation cannot. > > (Remembering our previous conversation, you may instead want to expire > your smartcard encryption subkey, and copy the other encryption subkey > to the smartcard - but only if you have made a decrypted copy of all > your sensitive data first.) I've already revoke my encryption key on my smartcard, thanks to you and it works like a charm. (like I said in my previous mail :) ). And I didn't know if you delete a subkey you won't delete it on key server. Thx Again Andrew. You are an incredible source of GPG knowledge >> - Recreate a new master key with only cert role and create all my subkey >> (S E A) and copy it to my Smart Card. > > This will just create additional confusion for you, because there will > now be two certificates associated with your name. It's not the end of > the world, but i don't think it would solve your problem as cleanly as > the above approach. You were right !! Bad idea ^_^ Thanks all again !! Maybe I will revoke my first encryption key. It's on my offline Master key so I will not use it day-to-day. And recreate my master key is not a good idea. Last question: Clean option will only clean locally or on key server too ?? Antoine Michard GPG Key: 0xF5C9E7CD0882B381 Le 25/01/2016 14:59, Daniel Kahn Gillmor a ?crit : > On Mon 2016-01-25 05:08:31 -0500, Antoine Michard wrote: >> So I thinking what is the best to do next: >> - Delete my useless first subkey encryption from my keyring and send >> update to key server. > > If you don't want people to encrypt messages to your D693C37C subkey, > you should revoke that subkey (and only that subkey), and publish your > updated certificate to the keyservers. > > Just deleting the subkey from your certificate locally won't delete the > associated copy on the keyserver, or provide anyone else with any > indication that you don't intend to continue using it. > >> - Recreate a new master key with only cert role and create all my subkey >> (S E A) and copy it to my Smart Card. > > This will just create additional confusion for you, because there will > now be two certificates associated with your name. It's not the end of > the world, but i don't think it would solve your problem as cleanly as > the above approach. > > hth, > > --dkg > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Mon Jan 25 14:58:05 2016 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Mon, 25 Jan 2016 14:58:05 +0100 Subject: Master Key Best Practice with SmartCard In-Reply-To: <56A6294E.8030007@andrewg.com> References: <56A5F41F.6050005@chezgeek.fr> <56A6294E.8030007@andrewg.com> Message-ID: <56A629ED.6080207@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 01/25/2016 02:55 PM, Andrew Gallagher wrote: > On 25/01/16 10:08, Antoine Michard wrote: >> >> So I thinking what is the best to do next: - Delete my useless >> first subkey encryption from my keyring and send update to key >> server. > > Once you've published a subkey it stays published. Deleting a > previously published subkey only removes it from your local > machine. It won't stop others from finding it on the keyservers and > trying to use it. > > If you want to explicitly mark a subkey as "do not use" (but you do > not believe that it has been compromised), then give it an > expiration date of yesterday and republish. There's no particular > reason to delete your local copy of the subkey (and there may be > very good reasons not to, e.g. old encrypted data). > > NB expiration can be undone, but revocation cannot. While this is correct in a perfect world, in practice it depends on the context as expirations can only effectively be extended due to possibility for an attacker to remove the new self-sig and presenting an older copy of the certificate to a third party. The same goes for revocation, it is true that the keyservers are add-only and provides some protection against it, but it is feasable for an attacker to present this certificate without revocation data to a user that isn't diligent with regards to keyring refreshes or by manipulation of the update channel (e.g. a preference for fetching from non-tls URI rather than a keyserver). - -- - ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- "Expect the best. Prepare for the worst. Capitalize on what comes." (Zig Ziglar) -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJWpinoAAoJECULev7WN52Fza0H/Axr/cFYUcEwbTrnK/nldKkr Qp8PuspNNYTsZzugfD6rOU4OamVStbhxKNHuBu72gRc90RtCHsS3K9mFumyuu9ce 1rTuTiFEBvTAfbsSUrFKjXJstm3DaG4uM5su6DMb671A/UmSdB2uJyVglAGhDAIM y+ugSMoySHxjCGb2BTSVbmrn0TCUFosPZSx6KkzCuOByXCI/V2dMRadsZBMd2+1V o2p1PCVoauugePCLMU7naguOjDOFRbKLOIZG0Lxy9fXwrckko1qYDBrY6Fdx1g4j xC5XVZA6ne1IcsRbvTEmwGJ6gmnKed12BKvMZ4XuNiEJP3ymRFWssflCFvZTt2c= =/X7N -----END PGP SIGNATURE----- From andrewg at andrewg.com Mon Jan 25 16:15:19 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 25 Jan 2016 15:15:19 +0000 Subject: Master Key Best Practice with SmartCard In-Reply-To: <56A63645.3040209@chezgeek.fr> References: <56A5F41F.6050005@chezgeek.fr> <87k2mx69pi.fsf@alice.fifthhorseman.net> <56A63645.3040209@chezgeek.fr> Message-ID: <1D82C0AC-3076-410A-910E-4BD909D0EC6A@andrewg.com> On 25 Jan 2016, at 14:50, Antoine Michard wrote: > Thx Again Andrew. You are an incredible source of GPG knowledge I'm really not. Just trying to be helpful. Don't trust me any more than any other random person on the Internet. I'm quite likely to make a mistake or leave out something important. > Last question: Clean option will only clean locally or on key server too ?? Just locally. You can't delete stuff from the keyservers, as they're a distributed database with no central control, and they have no method of confirming you are the key's owner. Even if you could get one server to delete your key, it would be resynchronised almost immediately from another server. In general, you should assume that anything that goes on the Internet is there forever, as you have no way of knowing who has made a copy for their own use, let alone do much about it. ;-) A From list.gnupg-users at acme.nu Tue Jan 26 00:18:26 2016 From: list.gnupg-users at acme.nu (Jorgen Ottosson) Date: Tue, 26 Jan 2016 00:18:26 +0100 Subject: Problems with 4096 keys on 2.1 card Message-ID: <3e0f6297c30e7e766a420b859a14279a.squirrel@10.99.199.22> On 25 Jan 2016 at 21:07, NIIBE Yutaka wrote: > However, please note that many card readers have problems with larger > APDU. Generating keys on card should be ok, but importing keys would > be failed with bad reader. Signing should be ok, but decryption would > be failed with bad reader. That's because of length of APDU. > -- Can't really confirm that here, generating seem not to work either. gpg --card-status .. Version ..........: 2.1 Manufacturer .....: ZeitControl .. Name of cardholder: [not set] Language prefs ...: de Sex ..............: unspecified URL of public key : [not set] Login data .......: [not set] Private DO 1 .....: [not set] Private DO 2 .....: [not set] Signature PIN ....: not forced Key attributes ...: 2048R 2048R 2048R Max. PIN lengths .: 32 32 32 PIN retry counter : 3 0 3 Signature counter : 0 Signature key ....: [none] Encryption key....: [none] Authentication key: [none] General key info..: [none] gpg --card-edit gpg/card> admin gpg/card> generate Make off-card backup of encryption key? (Y/n) n .. Please enter the PIN What keysize do you want for the Signature key? (2048) 4096 RSA keysizes must be in the range 1024-3072 What keysize do you want for the Signature key? (2048) gpg: Interrupt caught ... exiting SO: it seems the card will not generate larger keys then. I have several readers but am testing here with SCR335. Any way to pin-point my issue in more detail? Is my reader known to not support 4096? Info on readers who will? I also have a scr3500 somewhere but think I'll have to install drivers for that one to work, the SCR335 work with internal gpg drivers if I'm not mistaken whereas the 3500 don't work when attached as is. I also find it somewhat hard to get info on support for "Extended length" in several card reader's product-info pdfs I've looked at. TIA, From gniibe at fsij.org Tue Jan 26 02:06:19 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 26 Jan 2016 10:06:19 +0900 Subject: Problems with 4096 keys on 2.1 card In-Reply-To: <3e0f6297c30e7e766a420b859a14279a.squirrel@10.99.199.22> References: <3e0f6297c30e7e766a420b859a14279a.squirrel@10.99.199.22> Message-ID: <56A6C68B.3050400@fsij.org> On 01/26/2016 08:18 AM, Jorgen Ottosson wrote: > Can't really confirm that here, generating seem not to work either. > > gpg --card-status Please note that GnuPG 1.4 supports up to 3072-bit. This is because of internal library limitation. I believe that "gpg" in Ubuntu is GnuPG 1.4. It is "gpg2" when we want to use GnuPG 2.0. > gpg/card> generate > Make off-card backup of encryption key? (Y/n) n Besides, generating a key with off-card backup is actually done by two steps: * generating a key on host PC * importing that key to card If your choice is "Yes" for the question above, the key for encryption is not generated on card, but generated on host PC. > I have several readers but am testing here with SCR335. > > Any way to pin-point my issue in more detail? Is my reader known to not > support 4096? Info on readers who will? I also have a scr3500 somewhere > but think I'll have to install drivers for that one to work, the SCR335 > work with internal gpg drivers if I'm not mistaken whereas the 3500 don't > work when attached as is. Unfortunately, I don't have specific information (if card reader works with RSA-4096 or not), either. I maintain this list for internal driver. https://wiki.debian.org/GnuPG/CCID_Driver According to this list, SCR3500 works well with the internal driver of GnuPG. In general, the list by PCSC-lite helps. https://pcsclite.alioth.debian.org/ccid/supported.html Looking the device info, both of SCR335 and SCR3500 work with TPDU level exchange. Thus, I believe that both works well for RSA-4096 keys. > I also find it somewhat hard to get info on support for "Extended length" > in several card reader's product-info pdfs I've looked at. I think that it's "Extended APDU level exchange"? There are two level exchanges; one is TPDU level exchange (lower layer) and another is APDU level exchange. For longer APDU with original OpenPGPcard (i.e., in the communication of RSA-4096), the reader should support: TPDU level exchange or Extended APDU level exchange with enough dwMaxCCIDMessageLength If the reader only support short APDU level exchange, original OpenPGPcard doesn't work well for longer APDU. -- From stebe at mailbox.org Tue Jan 26 02:49:30 2016 From: stebe at mailbox.org (stebe at mailbox.org) Date: Tue, 26 Jan 2016 02:49:30 +0100 (CET) Subject: Key signing with non-primary UID Message-ID: <1684562155.774.9e287754-b220-484c-a3d5-869b57b55ffb.open-xchange@office.mailbox.org> Hi, some ways to achieve what you pretend, # sign (effectively) gpg2 --edit-key [name or email address or short/long keyID or, better, fingerprint of your contact] gpg> sign -u [your non-primary uid for signing given as name or email address] # sign only locally, i.e. it does not leave your computer gpg2 --edit-key [name or email address or short/long keyID or, better, fingerprint of your contact] gpg> lsign -u [your non-primary uid for signing given as name and/or email address] # checking it gpg2 --list-sigs [name or email address or short/long keyID or, better, fingerprint of your contact] # between "sig" and the keyID of your contact you should see an "L" now # You might as well use gpg2 --local-user [your non-primary uid for signing given as name and/or email address] --edit-key [name or email address or short/long keyID or, better, fingerprint of your contact] --lsign-key [name or email address or short/long keyID or, better, fingerprint of your contact] References: (1) README of 1.4.20, but it works with 2.0.x and 2.1.x versions of GnuPG as well (see quote below) (2) manpages (3) gnupg.info (1) GnuPG - The GNU Privacy Guard ------------------------------- Version 1.4.20 Copyright 1998-2015 Free Software Foundation, Inc. Copyright 1997-2015 Werner Koch [...] Okay, here is how GnuPG helps you with key management. Most stuff is done with the --edit-key command gpg --edit-key GnuPG displays some information about the key and then prompts for a command (enter "help" to see a list of commands and see the man page for a more detailed explanation). To sign a key you select the user ID you want to sign by entering the number that is displayed in the leftmost column (or do nothing if the key has only one user ID) and then enter the command "sign" and follow all the prompts. When you are ready, give the command "save" (or use "quit" to cancel your actions). If you want to sign the key with another of your user IDs, you must give an "-u" option on the command line together with the "--edit-key". HTH Stebe From aarontovo at gmail.com Tue Jan 26 05:41:41 2016 From: aarontovo at gmail.com (Aaron Tovo) Date: Mon, 25 Jan 2016 22:41:41 -0600 Subject: BAD signatures for GnuPG Stable Message-ID: <56A6F905.9060309@gmail.com> I downloaded gnupg-2.0.29.tar.bz2 and libgpg-error-1.21.tar.bz2 and their corresponding .sig files from www.gnupg.org/download. I tried to verify them using the gnupg (version 1.4.16) that came with my Ubuntu 14.04 distribution and got bad signature messages for both files: $ gpg --verify gnupg-2.0.29.tar.bz2.sig gnupg-2.0.29.tar.bz2 gpg: Signature made Tue 08 Sep 2015 09:38:22 AM CDT using RSA key ID 4F25E3B6 gpg: BAD signature from "Werner Koch (dist sig)" gpg: Signature made Wed 09 Sep 2015 05:30:24 AM CDT using RSA key ID 33BD3F06 gpg: requesting key 33BD3F06 from hkp server keys.gnupg.net gpg: key 33BD3F06: public key "NIIBE Yutaka (GnuPG Release Key) " imported gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 3 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 3u gpg: next trustdb check due at 2018-08-19 gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) gpg: BAD signature from "NIIBE Yutaka (GnuPG Release Key) " $ gpg --verify libgpg-error-1.21.tar.bz2.sig libgpg-error-1.21.tar.bz2 gpg: Signature made Sat 12 Dec 2015 06:03:30 AM CST using RSA key ID 4F25E3B6 gpg: BAD signature from "Werner Koch (dist sig)" What are some likely causes of this? I also checked the sha1sum and md5sum and they didn't match either. I didn't try the other gnupg packages. Aaron From wk at gnupg.org Tue Jan 26 10:26:09 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 26 Jan 2016 10:26:09 +0100 Subject: BAD signatures for GnuPG Stable In-Reply-To: <56A6F905.9060309@gmail.com> (Aaron Tovo's message of "Mon, 25 Jan 2016 22:41:41 -0600") References: <56A6F905.9060309@gmail.com> Message-ID: <87h9i0vgi6.fsf@vigenere.g10code.de> On Tue, 26 Jan 2016 05:41, aarontovo at gmail.com said: > $ gpg --verify libgpg-error-1.21.tar.bz2.sig libgpg-error-1.21.tar.bz2 > gpg: Signature made Sat 12 Dec 2015 06:03:30 AM CST using RSA key ID > 4F25E3B6 > gpg: BAD signature from "Werner Koch (dist sig)" Please check the length of the file to make sure you downloaded it complelety. The size of libgpg-error-1.21.tar.bz2 is 763186 bytes. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Jan 26 10:31:52 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 26 Jan 2016 10:31:52 +0100 Subject: Problems with 4096 keys on 2.1 card In-Reply-To: <56A6C68B.3050400@fsij.org> (NIIBE Yutaka's message of "Tue, 26 Jan 2016 10:06:19 +0900") References: <3e0f6297c30e7e766a420b859a14279a.squirrel@10.99.199.22> <56A6C68B.3050400@fsij.org> Message-ID: <87d1sovg8n.fsf@vigenere.g10code.de> On Tue, 26 Jan 2016 02:06, gniibe at fsij.org said: > Looking the device info, both of SCR335 and SCR3500 work with TPDU > level exchange. Thus, I believe that both works well for RSA-4096 > keys. Older SCR335 (version < 5.14) have a bug in the USB stack - they do not work reliable with PCSCD but they work with GnuPG's internal driver (I developed the smartcard and driver code using such old SCR335 and added a workaround). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From sasc0041 at stud.hs-kl.de Tue Jan 26 09:54:17 2016 From: sasc0041 at stud.hs-kl.de (Sandra Schreiner) Date: Tue, 26 Jan 2016 08:54:17 +0000 Subject: Key generation with GPGME and GnuPG hangs at gpgme_op_genkey Message-ID: Hello, This is my first message to an e-mail list ever. I don't even know if this is the right e-mail list for me, please forgive me if I'm wrong, but unfortunately I didn't found a GPGME e-mail list. Currently I'm trying to use GPGME in my C++ application with GnuPG for key-management and encryption. Sadly I'm not able to create a new key, because my code hangs at gpgme_op_genkey. I have gpg 1.4.18 and gpg2 2.0.26 and GPGME 1.5.1 on my 64 bit Debian VM system (version Jesse) available. This is how I initialize the library: gpgme_engine_info_t info; gpgme_error_t error; const char * CONFIG_DIR = "/"; // Initializes gpgme gpgme_check_version(NULL); // Initialize the locale environment. setlocale(LC_ALL, ""); gpgme_set_locale(NULL, LC_CTYPE, setlocale(LC_CTYPE, NULL)); #ifdef LC_MESSAGES gpgme_set_locale(NULL, LC_MESSAGES, setlocale(LC_MESSAGES, NULL)); #endif error = gpgme_set_engine_info(GPGME_PROTOCOL_OpenPGP, NULL, CONFIG_DIR); if(error) return false; error = gpgme_new(&mContext); if(error) return false; // Check OpenPGP error = gpgme_engine_check_version(GPGME_PROTOCOL_OpenPGP); if(error) return false; // load engine info error = gpgme_get_engine_info(&info); if(error) return false; while(info && info->protocol != gpgme_get_protocol(mContext)) { info = info->next; } // set path to our config file error = gpgme_ctx_set_engine_info(mContext, GPGME_PROTOCOL_OpenPGP, NULL, CONFIG_DIR); if(error) return false; ----------------------------------------------------------------------------------------------------------------------------- Here I try to create the key: std::string def = " \n" " Key-Type: default \n" " Subkey-Type: default \n" " Name-Real: Joe Tester3 \n" " Name-Comment: with stupid passphrase \n" " Name-Email: joe3 at foo.bar \n" " Expire-Date: 0 \n" " Passphrase: abc \n" " \n"; gpgme_error_t error = gpgme_op_genkey(mContext, def.c_str(), NULL, NULL); if(GPG_ERR_INV_VALUE == gpgme_err_code(error)){ std::cout << "Value error"; } if(GPG_ERR_NOT_SUPPORTED == gpgme_err_code(error)){ std::cout << "Not supported error"; } if(GPG_ERR_GENERAL == gpgme_err_code(error)){ std::cout << "general error"; } if(error == gpgme_err_code(GPG_ERR_NO_ERROR)){ gpgme_genkey_result_t res = gpgme_op_genkey_result(mContext); if(res->primary && res->sub){ result = true; } } There is no error while initialising the library, so I don't know why it stops at gpgme_op_genkey. Maybe GnuPG is trying to collect entropie? If I generate a key using the GnuPG command line it tooks a very long time to collect entropie. But after ~15 minutes the key generation completes successfully (I didn't noticed that my program finished so far, even after 15 minutes+). I already tried to remove the \n in each line, but I received a general error in this case. Am I doing something wrong? Any help or hint is highly appreciated. Best regards, Sandra -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Tue Jan 26 11:43:46 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 26 Jan 2016 05:43:46 -0500 Subject: Key generation with GPGME and GnuPG hangs at gpgme_op_genkey In-Reply-To: References: Message-ID: <56A74DE2.7060003@sixdemonbag.org> > This is my first message to an e-mail list ever. I don't even know if > this is the right e-mail list for me, please forgive me if I'm wrong, > but unfortunately I didn't found a GPGME e-mail list. Welcome! You're in the right place, and we'll be happy to help you out. You may wish to switch from HTML email to plain-text; that's the standard for this list. > There is no error while initialising the library, so I don't know why it > stops at gpgme_op_genkey. Maybe GnuPG is trying to collect entropie? If > I generate a key using the GnuPG command line it tooks a very long time > to collect entropie. But after ~15 minutes the key generation completes > successfully (I didn't noticed that my program finished so far, even > after 15 minutes+). If it's taking your GnuPG setup ~15 minutes to generate a new certificate, that indicates to me your GnuPG installation has a problem. Let's tackle that one first before we start looking at your code. Are you getting periodic messages about "Not enough random bytes available. Please do some other work to give the OS a chance to collect more entropy! (Need 167 more bytes)" or something like that? From sasc0041 at stud.hs-kl.de Tue Jan 26 12:02:09 2016 From: sasc0041 at stud.hs-kl.de (Sandra Schreiner) Date: Tue, 26 Jan 2016 11:02:09 +0000 Subject: AW: Key generation with GPGME and GnuPG hangs at gpgme_op_genkey In-Reply-To: <56A74DE2.7060003@sixdemonbag.org> References: , <56A74DE2.7060003@sixdemonbag.org> Message-ID: ________________________________________ Von: Gnupg-users [gnupg-users-bounces at gnupg.org]" im Auftrag von "Robert J. Hansen [rjh at sixdemonbag.org] Gesendet: Dienstag, 26. Januar 2016 11:43 An: gnupg-users at gnupg.org Betreff: Re: Key generation with GPGME and GnuPG hangs at gpgme_op_genkey > This is my first message to an e-mail list ever. I don't even know if > this is the right e-mail list for me, please forgive me if I'm wrong, > but unfortunately I didn't found a GPGME e-mail list. Welcome! You're in the right place, and we'll be happy to help you out. You may wish to switch from HTML email to plain-text; that's the standard for this list. > There is no error while initialising the library, so I don't know why it > stops at gpgme_op_genkey. Maybe GnuPG is trying to collect entropie? If > I generate a key using the GnuPG command line it tooks a very long time > to collect entropie. But after ~15 minutes the key generation completes > successfully (I didn't noticed that my program finished so far, even > after 15 minutes+). If it's taking your GnuPG setup ~15 minutes to generate a new certificate, that indicates to me your GnuPG installation has a problem. Let's tackle that one first before we start looking at your code. Are you getting periodic messages about "Not enough random bytes available. Please do some other work to give the OS a chance to collect more entropy! (Need 167 more bytes)" or something like that? _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users ______________________________________________________________________________________________ > Are you getting periodic messages about "Not enough random bytes > available. Please do some other work to give the OS a chance to > collect more entropy! (Need 167 more bytes)" or something like that? Yes. You are right. These messages appear often. Moreover I noticed that GPGME 1.5 may be outdated. I saw that e.g. the mode GPGME_EXPORT_MODE_SECRET is missing for exporting private keys. Therefore I would like to update GnuPG and GPGME together. Sadly there is no new version of them available in the debian package manager. How can I manage to update them? I found the tarball of GPGME 1.6 but don't know which version of GnuPG would match this GPGME version. From fulanoperez at cryptolab.net Tue Jan 26 12:27:36 2016 From: fulanoperez at cryptolab.net (Fulano Diego Perez) Date: Tue, 26 Jan 2016 22:27:36 +1100 Subject: 2.1.10 with libgcrypt 1.7.0-beta300 In-Reply-To: <56A57B74.80007@fsij.org> References: <5693BACF.5070005@cryptolab.net> <56944E98.5000307@fsij.org> <56A37C00.5080905@cryptolab.net> <56A57B74.80007@fsij.org> Message-ID: <56A75828.1040508@cryptolab.net> NIIBE Yutaka: > On 01/23/2016 10:11 PM, Fulano Diego Perez wrote: >> NIIBE Yutaka: >>> Please note that you need to invoke gpg-agent with LD_LIBRARY_PATH, too. >> >> can explain how you mean to invoke ? > > Well, it seems terminology issue. I mean, to start, to kick the service, > and to run the service. > > In general, there are multiple ways. In my case on Debian, I have a > startup script, /etc/X11/Xsession.d/90gpg-agent, which invokes > gpg-agent. > >> i export library path for gpg2 and shows expected libgcrypt version > > Exporting library path is also needed for gpg-agent. > >> i can clearsign with ed25519 EDDSA subkey > > This can be done with libgcrypt 1.6.4. > >> i have problem testing encryption with cv25519 subkey >> >> >> tried to test with $ fortune | gpg2 --sign --encrypt -u abc --recipient >> 123 --recipient 456 | gpg2 --decrypt >> >> gpg: ecdh failed in gcry_cipher_decrypt: Checksum error >> gpg: ecdh failed in gcry_cipher_decrypt: Checksum error >> gpg: encrypted with 256-bit ECDH key, ID test, created 2016 >> "test" >> gpg: public key decryption failed: Checksum error >> gpg: encrypted with 256-bit ECDH key, ID test, created 2016 >> test2 >> gpg: public key decryption failed: Checksum error >> gpg: decryption failed: No secret key >> >> i have secret key > > I know. The problem is the version of libgcrypt of gpg-agent. > > Public key handling is the role of gpg frontend, while secret key > handling is done by gpg-agent. With no newer libgcrypt, gpg-agent > can't handle CV25519 keys. > >> tried list-packets & -vvv - nothing more on errors > > Yes. > >> maybe this is conflict with persistent gpg-agent and ssh-agent >> they are listed in htop with PID but no RAM use >> >> how can to figure this out ? > > If you can check the process's memory maps of gpg-agent, you can see > the maps to libgcrypt. In my case, I can see the entries in > /proc//maps like: > > b7617000-b76d5000 r-xp 00000000 08:01 35743 /usr/local/lib/libgcrypt.so.20.1.0 > b76d5000-b76d9000 rw-p 000bd000 08:01 35743 /usr/local/lib/libgcrypt.so.20.1.0 > b76e7000-b76ef000 rw-p 00000000 00:00 0 > $ cat /proc/PID-of-local-[gpg-ssh]agent/maps nada $ /builds/gpg21x/bin/gpg-agent --daemon $ cat /proc/PID/maps 55fb967f7000-55fb96849000 r-xp 00000000 fc:02 2098759 /builds/gpg21x/bin/gpg-agent 55fb96a48000-55fb96a4a000 r--p 00051000 fc:02 2098759 /builds/gpg21x/bin/gpg-agent 55fb96a4a000-55fb96a4b000 rw-p 00053000 fc:02 2098759 /builds/gpg21x/bin/gpg-agent 55fb96a4b000-55fb96a4c000 rw-p 00000000 00:00 0 55fb98220000-55fb98241000 rw-p 00000000 00:00 0 [heap] 7f714b7e4000-7f714b97e000 r-xp 00000000 fc:02 2229058 /lib/x86_64-linux-gnu/libc-2.21.so 7f714b97e000-7f714bb7e000 ---p 0019a000 fc:02 2229058 /lib/x86_64-linux-gnu/libc-2.21.so 7f714bb7e000-7f714bb82000 r--p 0019a000 fc:02 2229058 /lib/x86_64-linux-gnu/libc-2.21.so 7f714bb82000-7f714bb84000 rw-p 0019e000 fc:02 2229058 /lib/x86_64-linux-gnu/libc-2.21.so 7f714bb84000-7f714bb88000 rw-p 00000000 00:00 0 7f714bb88000-7f714bba0000 r-xp 00000000 fc:02 2229034 /lib/x86_64-linux-gnu/libpthread-2.21.so 7f714bba0000-7f714bd9f000 ---p 00018000 fc:02 2229034 /lib/x86_64-linux-gnu/libpthread-2.21.so 7f714bd9f000-7f714bda0000 r--p 00017000 fc:02 2229034 /lib/x86_64-linux-gnu/libpthread-2.21.so 7f714bda0000-7f714bda1000 rw-p 00018000 fc:02 2229034 /lib/x86_64-linux-gnu/libpthread-2.21.so 7f714bda1000-7f714bda5000 rw-p 00000000 00:00 0 7f714bda5000-7f714bda8000 r-xp 00000000 fc:02 271554 /usr/lib/x86_64-linux-gnu/libnpth.so.0.0.5 7f714bda8000-7f714bfa8000 ---p 00003000 fc:02 271554 /usr/lib/x86_64-linux-gnu/libnpth.so.0.0.5 7f714bfa8000-7f714bfa9000 r--p 00003000 fc:02 271554 /usr/lib/x86_64-linux-gnu/libnpth.so.0.0.5 7f714bfa9000-7f714bfaa000 rw-p 00004000 fc:02 271554 /usr/lib/x86_64-linux-gnu/libnpth.so.0.0.5 7f714bfaa000-7f714bfbc000 r-xp 00000000 fc:02 269865 /usr/lib/x86_64-linux-gnu/libassuan.so.0.7.2 7f714bfbc000-7f714c1bb000 ---p 00012000 fc:02 269865 /usr/lib/x86_64-linux-gnu/libassuan.so.0.7.2 7f714c1bb000-7f714c1bc000 r--p 00011000 fc:02 269865 /usr/lib/x86_64-linux-gnu/libassuan.so.0.7.2 7f714c1bc000-7f714c1bd000 rw-p 00012000 fc:02 269865 /usr/lib/x86_64-linux-gnu/libassuan.so.0.7.2 7f714c1bd000-7f714c1cf000 r-xp 00000000 fc:02 2233335 /lib/x86_64-linux-gnu/libgpg-error.so.0.17.0 7f714c1cf000-7f714c3cf000 ---p 00012000 fc:02 2233335 /lib/x86_64-linux-gnu/libgpg-error.so.0.17.0 7f714c3cf000-7f714c3d0000 r--p 00012000 fc:02 2233335 /lib/x86_64-linux-gnu/libgpg-error.so.0.17.0 7f714c3d0000-7f714c3d1000 rw-p 00013000 fc:02 2233335 /lib/x86_64-linux-gnu/libgpg-error.so.0.17.0 7f714c3d1000-7f714c4ce000 r-xp 00000000 fc:02 2098729 /builds/libgcrypt/lib/libgcrypt.so.20.1.0 7f714c4ce000-7f714c6ce000 ---p 000fd000 fc:02 2098729 /builds/libgcrypt/lib/libgcrypt.so.20.1.0 7f714c6ce000-7f714c6d0000 r--p 000fd000 fc:02 2098729 /builds/libgcrypt/lib/libgcrypt.so.20.1.0 7f714c6d0000-7f714c6d6000 rw-p 000ff000 fc:02 2098729 /builds/libgcrypt/lib/libgcrypt.so.20.1.0 7f714c6d6000-7f714c6f8000 r-xp 00000000 fc:02 2229042 /lib/x86_64-linux-gnu/ld-2.21.so 7f714c741000-7f714c8ca000 r--p 00000000 fc:02 262206 /usr/lib/locale/locale-archive 7f714c8ca000-7f714c8cf000 rw-p 00000000 00:00 0 7f714c8ed000-7f714c8f5000 rw-p 00000000 00:00 0 7f714c8f5000-7f714c8f7000 rw-p 00000000 00:00 0 7f714c8f7000-7f714c8f8000 r--p 00021000 fc:02 2229042 /lib/x86_64-linux-gnu/ld-2.21.so 7f714c8f8000-7f714c8f9000 rw-p 00022000 fc:02 2229042 /lib/x86_64-linux-gnu/ld-2.21.so 7f714c8f9000-7f714c8fa000 rw-p 00000000 00:00 0 7ffe65c44000-7ffe65c65000 rw-p 00000000 00:00 0 [stack] 7ffe65ddb000-7ffe65ddd000 r--p 00000000 00:00 0 [vvar] 7ffe65ddd000-7ffe65ddf000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] above is showing systems libraries and not the prefix i used at install time i compiled gpg2 and libgcrypt with DEB_BUILD_HARDENING=1 from HARDENED-CC(1) From girish.kumar at al-enterprise.com Tue Jan 26 16:05:51 2016 From: girish.kumar at al-enterprise.com (Girish Kumar) Date: Tue, 26 Jan 2016 15:05:51 +0000 Subject: Cross Compiling libgpg-error-1.21 for rsyslog-8.15.0: unrecognized option '--64'. Message-ID: Dear All, I am compiling libgpg-error-1.21 which is a dependency library for libgcrypt-1.6.4 . This for armv7 platform Found some info on cross compilation, but was not able to understand. I am getting "unrecognized option '--64'" when compiling libgpg-error-1.21. Could you please help me on this.? gawk -f /home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/libgpg-error-1.21/src/mkerrnos.awk /home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/libgpg-error-1.21/src/errnos.in >code-to-errno.h gawk -f /home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/libgpg-error-1.21/src/mkerrcodes1.awk /home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/libgpg-error-1.21/src/errnos.in >_mkerrcodes.h arm-unknown-linux-gnueabi-gcc -E -mcpu=cortex-a9 -mabi=aapcs-linux -msoft-float -O -fno-omit-frame-pointer -mapcs-frame -mno-sched-prolog -I/soft/gnu/cross/linux_64/13/arm/sysroot/usr/include -I/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/built/46/7.X.X.R01/armv7/include -P _mkerrcodes.h | grep GPG_ERR_ | \ gawk -f /home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/libgpg-error-1.21/src/mkerrcodes.awk >mkerrcodes.h rm _mkerrcodes.h cc -I. -I/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/libgpg-error-1.21/src -o mkerrcodes /home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/libgpg-error-1.21/src/mkerrcodes.c as: unrecognized option '--64' make[4]: *** [mkerrcodes] Error 1 make[4]: Leaving directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/objs/46/7.X.X.R01/armv7/libgpg-error/src' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/objs/46/7.X.X.R01/armv7/libgpg-error' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/objs/46/7.X.X.R01/armv7/libgpg-error' make[2]: Entering directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/objs/46/7.X.X.R01/armv7/libgpg-error' Making install in m4 make[3]: Entering directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/objs/46/7.X.X.R01/armv7/libgpg-error/m4' make[4]: Entering directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/objs/46/7.X.X.R01/armv7/libgpg-error/m4' make[4]: Nothing to be done for `install-exec-am'. make[4]: Nothing to be done for `install-data-am'. make[4]: Leaving directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/objs/46/7.X.X.R01/armv7/libgpg-error/m4' make[3]: Leaving directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/objs/46/7.X.X.R01/armv7/libgpg-error/m4' Making install in src make[3]: Entering directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/objs/46/7.X.X.R01/armv7/libgpg-error/src' cc -I. -I/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/libgpg-error-1.21/src -o mkerrcodes /home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/libgpg-error-1.21/src/mkerrcodes.c as: unrecognized option '--64' make[3]: *** [mkerrcodes] Error 1 make[3]: Leaving directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/objs/46/7.X.X.R01/armv7/libgpg-error/src' make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/objs/46/7.X.X.R01/armv7/libgpg-error' make[1]: *** [/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/installed/46/7.X.X.R01/armv7/ramdisk/lib/libgpg-error.so] Error 2 make[1]: Leaving directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps' make: *** [tps-build] Error 2 + set +x Regards, Girish -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Tue Jan 26 19:30:13 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 26 Jan 2016 13:30:13 -0500 Subject: AW: Key generation with GPGME and GnuPG hangs at gpgme_op_genkey In-Reply-To: References: <56A74DE2.7060003@sixdemonbag.org> Message-ID: <87twm06vnu.fsf@alice.fifthhorseman.net> On Tue 2016-01-26 06:02:09 -0500, Sandra Schreiner wrote: [ Robert J. Hansen wrote: ] >> Are you getting periodic messages about "Not enough random bytes >> available. Please do some other work to give the OS a chance to >> collect more entropy! (Need 167 more bytes)" or something like that? > > Yes. You are right. These messages appear often. You said that you are running in a Jessie VM. Depending on the type of VM, it's possible that there are few events that are feeding the kernel's entropy pool (no virtualized hardware or software or anything similar). GnuPG relies on the kernel's entropy to initialize the key generation process, and it consumes rather a lot of it. I don't know what kind of virtualization you're using, so i have no concrete suggestions for how you could increase the entropy in the VM you're using, other than the usual tricks of typing into keyboard and wiggling the mouse. you can see the state of the Linux kernel's entropy by looking at the contents of the file /proc/sys/kernel/random/entropy_avail -- if that is staying close to 0, it's likely that this is the problem. For testing purposes only, you might be interested in using the --debug-quick-random flag, which would avoid waiting on the kernel's blocking RNG. I note that you're passing the root of the filesystem as your preferred CONFIG_DIR: const char * CONFIG_DIR = "/"; This might be a mistake, because it's unlikely that a normal user can write to the root directory, and you almost certainly don't *want* to use the root directory as your gpg config dir. gpgme_set_engine_info() accepts NULL as the HOME_DIR parameter, which asks for the engine' default homedir to be used. > Moreover I noticed that GPGME 1.5 may be outdated. I saw that e.g. the > mode GPGME_EXPORT_MODE_SECRET is missing for exporting private > keys. Therefore I would like to update GnuPG and GPGME together. Sadly > there is no new version of them available in the debian package > manager. How can I manage to update them? I found the tarball of GPGME > 1.6 but don't know which version of GnuPG would match this GPGME > version. gpgme and gnupg are not intentionally tightly coupled. I wouldn't try to update them until you've figured out what's going on here. If the delay is still happening for you even with a system with entropy available, you might also try looking at the process table to see what is going on -- if there's a backgrounded gpg or gpg2 process, you could try attaching to it with strace ("strace -p $PID", where $PID is the process ID of the gpg process) to see what it's doing. hth, --dkg From list.gnupg-users at acme.nu Tue Jan 26 23:59:22 2016 From: list.gnupg-users at acme.nu (Jorgen Ottosson) Date: Tue, 26 Jan 2016 23:59:22 +0100 Subject: Problems with 4096 keys on 2.1 card In-Reply-To: <56A6C68B.3050400@fsij.org> References: <3e0f6297c30e7e766a420b859a14279a.squirrel@10.99.199.22> <56A6C68B.3050400@fsij.org> Message-ID: <2b9a0ff157abb7087340c60db3873602.squirrel@10.99.199.22> Thanks to you both for commenting on this, I do remember the 335 being one of the most original readers to work without much hazzle. > Please note that GnuPG 1.4 supports up to 3072-bit. This is because > of internal library limitation. > > I believe that "gpg" in Ubuntu is GnuPG 1.4. It is "gpg2" when we > want to use GnuPG 2.0. Ok, well I thought it kinda used the 2 branch anyway when doing stuff with cards, I may have misunderstood that - see commands further down though, switching to "gpg2" does not work. > Besides, generating a key with off-card backup is actually done by two > steps: > > * generating a key on host PC > * importing that key to card I know, that was just for showing generate command bailing. > Unfortunately, I don't have specific information (if card reader works > with RSA-4096 or not), either. I maintain this list for internal > driver. > > https://wiki.debian.org/GnuPG/CCID_Driver Nice link. > According to this list, SCR3500 works well with the internal driver of > GnuPG. That's weird. Dead here without additional drivers, used it on another installation, also Ubuntu but installed some kind of driver so guess I didn't use the internal then either. > In general, the list by PCSC-lite helps. > > https://pcsclite.alioth.debian.org/ccid/supported.html > > Looking the device info, both of SCR335 and SCR3500 work with TPDU > level exchange. Thus, I believe that both works well for RSA-4096 > keys. Then I should be able to do some things differently.. Some misc. commands: $ gpg --version gpg (GnuPG) 1.4.16 .. $ gpg2 --version gpg (GnuPG) 2.0.22 .. $ gpg --list-keys -> works $ gpg2 --list-keys also works However: $ gpg --card-status -> works whereas gpg2 does NOT. (should it really? - but it is listed in help output though) $ gpg2 --card-status gpg: selecting openpgp failed: Unsupported certificate gpg: OpenPGP card not available: Unsupported certificate NOTE: v2.1 card inserted in attached SCR335 reader all the time above. Not sure if there's something here confusing me or I need to buy (yet) another reader or what.. Maybe I can turn on debugging somewhere to solve this, really need to use a couple of 4096 subkeys so this is kinda bugging me. TIA, From wk at gnupg.org Tue Jan 26 23:50:21 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 26 Jan 2016 23:50:21 +0100 Subject: [Announce] GnuPG 2.1.11 released Message-ID: <87r3h4t0pe.fsf@vigenere.g10code.de> Hello! The GnuPG team is pleased to announce the availability of a new release of GnuPG modern: Version 2.1.11. See below for new features and bug fixes. The GNU Privacy Guard (GnuPG) is a complete and free implementation of the OpenPGP standard which is commonly abbreviated as PGP. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries making use of GnuPG are available. Since version 2 GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Three different branches of GnuPG are actively maintained: - GnuPG "modern" (2.1) is the latest development with a lot of new features. This announcement is about this branch. - GnuPG "stable" (2.0) is the current stable version for general use. This is what most users are currently using. - GnuPG "classic" (1.4) is the old standalone version which is most suitable for older or embedded platforms. You may not install "modern" (2.1) and "stable" (2.0) at the same time. However, it is possible to install "classic" (1.4) along with any of the other versions. Noteworthy changes in version 2.1.11 ==================================== * gpg: New command --export-ssh-key to replace the gpgkey2ssh tool. * gpg: Allow to generate mail address only keys with --gen-key. * gpg: "--list-options show-usage" is now the default. * gpg: Make lookup of DNS CERT records holding an URL work. * gpg: Emit PROGRESS status lines during key generation. * gpg: Don't check for ambigious or non-matching key specification in the config file or given to --encrypt-to. This feature will return in 2.3.x. * gpg: Lock keybox files while updating them. * gpg: Solve rare error on Windows during keyring and Keybox updates. * gpg: Fix possible keyring corruption. (bug#2193) * gpg: Fix regression of "bkuptocard" sub-command in --edit-key and remove "checkbkupkey" sub-command introduced with 2.1. (bug#2169) * gpg: Fix internal error in gpgv when using default keyid-format. * gpg: Fix --auto-key-retrieve to work with dirmngr.conf configured keyservers. (bug#2147). * agent: New option --pinentry-timeout. * scd: Improve unplugging of USB readers under Windows. * scd: Fix regression for generating RSA keys on card. * dirmmgr: All configured keyservers are now searched. * dirmngr: Install CA certificate for hkps.pool.sks-keyservers.net. Use this certiticate even if --hkp-cacert is not used. * gpgtar: Add actual encryption code. gpgtar does now fully replace gpg-zip. * gpgtar: Fix filename encoding problem on Windows. * Print a warning if a GnuPG component is using an older version of gpg-agent, dirmngr, or scdaemon. A detailed description of the changes found in the 2.1 branch can be found at . Please be aware that there are still known bugs which we are working on. Check https://bugs.gnupg.org, https://wiki.gnupg.org, and the mailing list archives for known problems and workarounds. Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.1.11 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.11.tar.bz2 (5102k) ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.11.tar.bz2.sig or here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.11.tar.bz2 (5102k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.11.tar.bz2.sig An installer for Windows without any graphical frontend except for a basic Pinentry tool is available here: ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.11_20160126.exe (2630k) ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.11_20160126.exe.sig or here https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.11_20160126.exe (2630k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.11_20160126.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. This Windows installer is missing translations, it has no TOFU support, and no HKPS support. However, it fully supports Tor and the Tor browser. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.1.11.tar.bz2 you would use this command: gpg --verify gnupg-2.1.11.tar.bz2.sig gnupg-2.1.11.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See below for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.1.11.tar.bz2, you run the command like this: sha1sum gnupg-2.1.11.tar.bz2 and check that the output matches the next line: 4af2032a60ff22e322b1c5b270d6d2228f59a3a3 gnupg-2.1.11.tar.bz2 ed237ba7bf8fd4fd3f2688ddd46b949dd15ebdd6 gnupg-w32-2.1.11_20160126.exe 6e7e5f6e296dc4b2317ce2023afa08b5a721e243 gnupg-w32-2.1.11_20160126.tar.xz Release Signing Keys ==================== To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: 2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31] Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 Werner Koch (Release Signing Key) You may retrieve these keys from a keyserver using this command gpg --keyserver hkp://keys.gnupg.net --recv-keys \ 249B39D24F25E3B6 04376F3EE0856959 \ 2071B08A33BD3F06 8A861B1C7EFD60D9 The keys are also available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese, Czech, French, German, Japanese, Russian, and Ukrainian being almost completely translated (2156 different strings). Documentation ============= If you used GnuPG in the past you should read the description of changes and new features at doc/whats-new-in-2.1.txt or online at https://gnupg.org/faq/whats-new-in-2.1.html The file gnupg.info has the complete user manual of the system. Separate man pages are included as well but they have not all the details available as are the manual. It is also possible to read the complete manual online in HTML format at https://gnupg.org/documentation/manuals/gnupg/ or in Portable Document Format at https://gnupg.org/documentation/manuals/gnupg.pdf . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. You may also want search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. You may also want to follow postings at . Support ======== Please consult the archive of the gnupg-users mailing list before reporting a bug . We suggest to send bug reports for a new release to this list in favor of filing a bug at . For commercial support requests we keep a list of known service companies at: https://gnupg.org/service.html If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Maintenance and development of GnuPG is mostly financed by donations. As of today we employ 3 full-time developers, one part-timer, and one contractor. They all work on GnuPG and closely related software like Enigmail. Please see https://gnupg.org/donate/ on how you can help. Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, answering questions on the mailing lists, and donating money. For the GnuPG hackers, Werner p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users'at'gnupg.org mailing list. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From rjh at sixdemonbag.org Wed Jan 27 00:41:21 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 26 Jan 2016 18:41:21 -0500 Subject: NSA Civil Liberties & Privacy Report Message-ID: <56A80421.708@sixdemonbag.org> The United States National Security Agency was required by Congress to assemble a report on how they conduct electronic surveillance and the measures taken to preserve the privacy of U.S. citizens. It was released last Friday, but I've yet to see it in the press. It's very dry reading, but there are some interesting nuggets within. https://www.nsa.gov/civil_liberties/_files/UFA_Civil_Liberties_and_Privacy_Report.pdf From gniibe at fsij.org Wed Jan 27 00:52:32 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 27 Jan 2016 08:52:32 +0900 Subject: Problems with 4096 keys on 2.1 card In-Reply-To: <2b9a0ff157abb7087340c60db3873602.squirrel@10.99.199.22> References: <3e0f6297c30e7e766a420b859a14279a.squirrel@10.99.199.22> <56A6C68B.3050400@fsij.org> <2b9a0ff157abb7087340c60db3873602.squirrel@10.99.199.22> Message-ID: <56A806C0.9010102@fsij.org> On 01/27/2016 07:59 AM, Jorgen Ottosson wrote: > $ gpg --card-status > > -> works Yes. GnuPG 1.4 works here, but it doesn't work for RSA-4096 keys. I guess that you don't configure GnuPG 1.4 to use gpg-agent. In that setting, gpg tries to connect your reader directly. > $ gpg2 --card-status > gpg: selecting openpgp failed: Unsupported certificate > gpg: OpenPGP card not available: Unsupported certificate This is different thing. It is the problem of smartcard, not specific to RSA-4096. I think you are using GNOME keyring. Old versions of GNOME keyring had a feature to try to replace a part of functionality of gpg-agent, it was a kind of emulation of gpg-agent. And it doesn't support any commands for smartcard, and it resulted mysterious errors like above. It had been difficult to configure GNOME keyring (to stop the feature of gpg-agent) properly. Here is some info: http://www.gniibe.org/memo/notebook/gnome3-gpg-settings.html In the days of GNOME 2.x, it was gconftool-2. In the days of GNOME 3.0, it was gnome-session-properties. For GNOME 3.1 or later, we need to change the way how to invoke gnome-keyring. Fortunately, I've heard that gnome-keyring is fixed now. I, for myself, gave up with GNOME and currently using XFCE4. However, I encountered another: https://bugs.debian.org/791378 -- From robertc at broadcom.com Wed Jan 27 02:35:17 2016 From: robertc at broadcom.com (Bob (Robert) Cavanaugh) Date: Wed, 27 Jan 2016 01:35:17 +0000 Subject: Migrating to Gmail. Recommendations? Message-ID: <8F0B09FC6339FA439524099BFCABC11F2D4FCB53@IRVEXCHMB11.corp.ad.broadcom.com> Hi All, My company is merging with another and the new corporate e-mail will use Gmail. Is there a group consensus as to which client uses GPG most efficiently/securely? What about the UI? Thanks, Bob Cavanaugh -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: image001.gif URL: From aarontovo at gmail.com Wed Jan 27 05:44:52 2016 From: aarontovo at gmail.com (Aaron Tovo) Date: Tue, 26 Jan 2016 22:44:52 -0600 Subject: BAD signatures for GnuPG Stable In-Reply-To: <87h9i0vgi6.fsf@vigenere.g10code.de> References: <56A6F905.9060309@gmail.com> <87h9i0vgi6.fsf@vigenere.g10code.de> Message-ID: <56A84B44.1020604@gmail.com> Interesting. The file I downloaded is actually larger than what it should be! -rw-rw-r-- 1 aaron aaron 855815 Jan 25 21:44 libgpg-error-1.21.tar.bz2 On 01/26/2016 03:26 AM, Werner Koch wrote: > On Tue, 26 Jan 2016 05:41, aarontovo at gmail.com said: > >> $ gpg --verify libgpg-error-1.21.tar.bz2.sig libgpg-error-1.21.tar.bz2 >> gpg: Signature made Sat 12 Dec 2015 06:03:30 AM CST using RSA key ID >> 4F25E3B6 >> gpg: BAD signature from "Werner Koch (dist sig)" > Please check the length of the file to make sure you downloaded it > complelety. > > The size of libgpg-error-1.21.tar.bz2 is 763186 bytes. > > > Shalom-Salam, > > Werner > From girish.kumar at al-enterprise.com Wed Jan 27 07:09:06 2016 From: girish.kumar at al-enterprise.com (Girish Kumar) Date: Wed, 27 Jan 2016 06:09:06 +0000 Subject: Cross Compiling libgpg-error-1.21 for rsyslog-8.15.0: unrecognized option '--64'. In-Reply-To: References: Message-ID: Hi All, I found following in README doc. Could you please explain what I should for armv7. Cross-Compiling --------------- Libgpg-error needs to figure out some platform specific properties. These are used to build the platform specific gpg-error.h file. The detection is done during build time but can't be done when cross-compiling. Thus if you run into an error during building you need to figure out these values. You may use these commands: build="$(build-aux/config.guess)" ./configure --prefix=TARGETDIR --host=TARGET --build=$build cd src make gen-posix-lock-obj scp gen-posix-lock-obj TARGET: ssh TARGET ./gen-posix-lock-obj >tmp.h mv tmp.h "syscfg/$(awk 'NR==1 {print $2}' tmp.h)" If you are using a VPATH build adjust accordingly. If this all works for you (make sure to run the test programs on the target platform), please send the generated file to the gnupg-devel mailing list so that we can include it in the next release. Note that in addition to the aliasing done by config.sub the src/mkheader build tool does some extra aliasing to avoid having too much identical syscfg files. Regards, Girish From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Girish Kumar Sent: Tuesday, January 26, 2016 8:36 PM To: gnupg-users at gnupg.org Subject: Cross Compiling libgpg-error-1.21 for rsyslog-8.15.0: unrecognized option '--64'. Dear All, I am compiling libgpg-error-1.21 which is a dependency library for libgcrypt-1.6.4 . This for armv7 platform Found some info on cross compilation, but was not able to understand. I am getting "unrecognized option '--64'" when compiling libgpg-error-1.21. Could you please help me on this.? gawk -f /home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/libgpg-error-1.21/src/mkerrnos.awk /home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/libgpg-error-1.21/src/errnos.in >code-to-errno.h gawk -f /home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/libgpg-error-1.21/src/mkerrcodes1.awk /home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/libgpg-error-1.21/src/errnos.in >_mkerrcodes.h arm-unknown-linux-gnueabi-gcc -E -mcpu=cortex-a9 -mabi=aapcs-linux -msoft-float -O -fno-omit-frame-pointer -mapcs-frame -mno-sched-prolog -I/soft/gnu/cross/linux_64/13/arm/sysroot/usr/include -I/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/built/46/7.X.X.R01/armv7/include -P _mkerrcodes.h | grep GPG_ERR_ | \ gawk -f /home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/libgpg-error-1.21/src/mkerrcodes.awk >mkerrcodes.h rm _mkerrcodes.h cc -I. -I/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/libgpg-error-1.21/src -o mkerrcodes /home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/libgpg-error-1.21/src/mkerrcodes.c as: unrecognized option '--64' make[4]: *** [mkerrcodes] Error 1 make[4]: Leaving directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/objs/46/7.X.X.R01/armv7/libgpg-error/src' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/objs/46/7.X.X.R01/armv7/libgpg-error' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/objs/46/7.X.X.R01/armv7/libgpg-error' make[2]: Entering directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/objs/46/7.X.X.R01/armv7/libgpg-error' Making install in m4 make[3]: Entering directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/objs/46/7.X.X.R01/armv7/libgpg-error/m4' make[4]: Entering directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/objs/46/7.X.X.R01/armv7/libgpg-error/m4' make[4]: Nothing to be done for `install-exec-am'. make[4]: Nothing to be done for `install-data-am'. make[4]: Leaving directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/objs/46/7.X.X.R01/armv7/libgpg-error/m4' make[3]: Leaving directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/objs/46/7.X.X.R01/armv7/libgpg-error/m4' Making install in src make[3]: Entering directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/objs/46/7.X.X.R01/armv7/libgpg-error/src' cc -I. -I/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/libgpg-error-1.21/src -o mkerrcodes /home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/libgpg-error-1.21/src/mkerrcodes.c as: unrecognized option '--64' make[3]: *** [mkerrcodes] Error 1 make[3]: Leaving directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/objs/46/7.X.X.R01/armv7/libgpg-error/src' make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/objs/46/7.X.X.R01/armv7/libgpg-error' make[1]: *** [/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/installed/46/7.X.X.R01/armv7/ramdisk/lib/libgpg-error.so] Error 2 make[1]: Leaving directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps' make: *** [tps-build] Error 2 + set +x Regards, Girish -------------- next part -------------- An HTML attachment was scrubbed... URL: From farhanible at gmail.com Wed Jan 27 06:06:40 2016 From: farhanible at gmail.com (F Rafi) Date: Wed, 27 Jan 2016 00:06:40 -0500 Subject: Migrating to Gmail. Recommendations? In-Reply-To: <8F0B09FC6339FA439524099BFCABC11F2D4FCB53@IRVEXCHMB11.corp.ad.broadcom.com> References: <8F0B09FC6339FA439524099BFCABC11F2D4FCB53@IRVEXCHMB11.corp.ad.broadcom.com> Message-ID: If IMAP or ActiveSync are enabled for that Gmail ("Gmail for Work") account, you may continue using whatever client you're using today. -Farhab On Tuesday, January 26, 2016, Bob (Robert) Cavanaugh wrote: > Hi All, > > My company is merging with another and the new corporate e-mail will use > Gmail. Is there a group consensus as to which client uses GPG most > efficiently/securely? What about the UI? > > > > Thanks, > > Bob Cavanaugh > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2310 bytes Desc: not available URL: From sasc0041 at stud.hs-kl.de Wed Jan 27 09:54:40 2016 From: sasc0041 at stud.hs-kl.de (Sandra Schreiner) Date: Wed, 27 Jan 2016 08:54:40 +0000 Subject: AW: AW: Key generation with GPGME and GnuPG hangs at gpgme_op_genkey In-Reply-To: <87twm06vnu.fsf@alice.fifthhorseman.net> References: <56A74DE2.7060003@sixdemonbag.org> , <87twm06vnu.fsf@alice.fifthhorseman.net> Message-ID: Von: Daniel Kahn Gillmor [dkg at fifthhorseman.net] Gesendet: Dienstag, 26. Januar 2016 19:30 An: Sandra Schreiner; Robert J. Hansen; gnupg-users at gnupg.org Betreff: Re: AW: Key generation with GPGME and GnuPG hangs at gpgme_op_genkey On Tue 2016-01-26 06:02:09 -0500, Sandra Schreiner wrote: [ Robert J. Hansen wrote: ] >> Are you getting periodic messages about "Not enough random bytes >> available. Please do some other work to give the OS a chance to >> collect more entropy! (Need 167 more bytes)" or something like that? > > Yes. You are right. These messages appear often. You said that you are running in a Jessie VM. Depending on the type of VM, it's possible that there are few events that are feeding the kernel's entropy pool (no virtualized hardware or software or anything similar). GnuPG relies on the kernel's entropy to initialize the key generation process, and it consumes rather a lot of it. I don't know what kind of virtualization you're using, so i have no concrete suggestions for how you could increase the entropy in the VM you're using, other than the usual tricks of typing into keyboard and wiggling the mouse. you can see the state of the Linux kernel's entropy by looking at the contents of the file /proc/sys/kernel/random/entropy_avail -- if that is staying close to 0, it's likely that this is the problem. For testing purposes only, you might be interested in using the --debug-quick-random flag, which would avoid waiting on the kernel's blocking RNG. I note that you're passing the root of the filesystem as your preferred CONFIG_DIR: const char * CONFIG_DIR = "/"; This might be a mistake, because it's unlikely that a normal user can write to the root directory, and you almost certainly don't *want* to use the root directory as your gpg config dir. gpgme_set_engine_info() accepts NULL as the HOME_DIR parameter, which asks for the engine' default homedir to be used. > Moreover I noticed that GPGME 1.5 may be outdated. I saw that e.g. the > mode GPGME_EXPORT_MODE_SECRET is missing for exporting private > keys. Therefore I would like to update GnuPG and GPGME together. Sadly > there is no new version of them available in the debian package > manager. How can I manage to update them? I found the tarball of GPGME > 1.6 but don't know which version of GnuPG would match this GPGME > version. gpgme and gnupg are not intentionally tightly coupled. I wouldn't try to update them until you've figured out what's going on here. If the delay is still happening for you even with a system with entropy available, you might also try looking at the process table to see what is going on -- if there's a backgrounded gpg or gpg2 process, you could try attaching to it with strace ("strace -p $PID", where $PID is the process ID of the gpg process) to see what it's doing. hth, --dkg ________________________________________ > you can see the state of the Linux kernel's entropy by looking at the > contents of the file /proc/sys/kernel/random/entropy_avail -- if that is > staying close to 0, it's likely that this is the problem. This file is empty. So entropie problems might be the reason. I'm using a 64 bit Debian Image (Jesse) provided by Virtual Box inside Virtual Box VM Manager. > For testing purposes only, you might be interested in using the > --debug-quick-random flag, which would avoid waiting on the kernel's > blocking RNG. I don't know how and where I should use this flag. I tried to generate a new key using GnuPG command line tool, but it doesn't recognize it: user at PC-ID-0050a-vm:~$ gpg --gen-key --debug-quick-random gpg: Invalid option "--debug-quick-random" Also I can't pass it as a compiler flag in my c++ project. My compiler doesn't know the flag either. Where does this flag belong? > I note that you're passing the root of the filesystem as your preferred > CONFIG_DIR: I removed the specific path of the directory, because it contains the project and user name. Sorry, I didn't mentioned that earlier. However I also tried to use the default path and didn't get any results from the key generation in the c++ application. I would really like to test if I could generate a key with the --debug-quick-random flag and see if entropie is the only show-stopper here. Could this entropie issue also stop the application from generating a key on a freshly booted system, say a mobile phone or a 'normal' (not VM) pc system? From wk at gnupg.org Wed Jan 27 10:39:50 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 27 Jan 2016 10:39:50 +0100 Subject: Problems with 4096 keys on 2.1 card In-Reply-To: <2b9a0ff157abb7087340c60db3873602.squirrel@10.99.199.22> (Jorgen Ottosson's message of "Tue, 26 Jan 2016 23:59:22 +0100") References: <3e0f6297c30e7e766a420b859a14279a.squirrel@10.99.199.22> <56A6C68B.3050400@fsij.org> <2b9a0ff157abb7087340c60db3873602.squirrel@10.99.199.22> Message-ID: <8760yftl7d.fsf@vigenere.g10code.de> On Tue, 26 Jan 2016 23:59, list.gnupg-users at acme.nu said: > $ gpg2 --card-status > gpg: selecting openpgp failed: Unsupported certificate That is an interesting error message because that one is only used by gpgsm and not by any components involved in gpg2 --card-status. Please enter gpg-connect-agent -v and on its prompt SCD GETINFO version Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rjh at sixdemonbag.org Wed Jan 27 11:06:09 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 27 Jan 2016 05:06:09 -0500 Subject: AW: AW: Key generation with GPGME and GnuPG hangs at gpgme_op_genkey In-Reply-To: References: <56A74DE2.7060003@sixdemonbag.org> <87twm06vnu.fsf@alice.fifthhorseman.net> Message-ID: <56A89691.4070700@sixdemonbag.org> For the record -- I used the code you provided with three minor changes: (a) in lieu of CONFIG_DIR, I used nullptr, (b) I released the context at the end of the code, and (c) I used C++14isms like nullptr, auto, and so on. It compiled and ran just fine. This makes me think the problem is in GnuPG's entropy collection and/or key generation -- not your code. From andrewg at andrewg.com Wed Jan 27 11:45:39 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 27 Jan 2016 10:45:39 +0000 Subject: AW: AW: Key generation with GPGME and GnuPG hangs at gpgme_op_genkey In-Reply-To: <56A89691.4070700@sixdemonbag.org> References: <56A74DE2.7060003@sixdemonbag.org> <87twm06vnu.fsf@alice.fifthhorseman.net> <56A89691.4070700@sixdemonbag.org> Message-ID: > On 27 Jan 2016, at 10:06, Robert J. Hansen wrote: > > It compiled and ran just fine. This makes me think the problem is in > GnuPG's entropy collection and/or key generation -- not your code. If your problem is merely lack of entropy on a VM, then I'd recommend installing haveged, available in Jessie. It broadens the sources used by the kernel for the entropy pool. A From sasc0041 at stud.hs-kl.de Wed Jan 27 13:49:51 2016 From: sasc0041 at stud.hs-kl.de (Sandra Schreiner) Date: Wed, 27 Jan 2016 12:49:51 +0000 Subject: AW: AW: AW: Key generation with GPGME and GnuPG hangs at gpgme_op_genkey In-Reply-To: References: <56A74DE2.7060003@sixdemonbag.org> <87twm06vnu.fsf@alice.fifthhorseman.net> <56A89691.4070700@sixdemonbag.org>, Message-ID: > If your problem is merely lack of entropy on a VM, then I'd recommend installing haveged, available in Jessie. It > broadens the sources used by the kernel for the entropy pool. Yes, that was the problem. I installed haveged and it worked. But it seems that the key generation in my C++ application will not work, if a custom passphrase callback is set. The key generation code is unchanged, but with the callback I get an GPG_ERR_GENERAL error. The init and callback code is as follows: // Initializes gpgme gpgme_check_version(NULL); // Initialize the locale environment. setlocale(LC_ALL, ""); gpgme_set_locale(NULL, LC_CTYPE, setlocale(LC_CTYPE, NULL)); #ifdef LC_MESSAGES gpgme_set_locale(NULL, LC_MESSAGES, setlocale(LC_MESSAGES, NULL)); #endif gpgme_error_t error = gpgme_new(&mContext); if(error) return false; // Check OpenPGP error = gpgme_engine_check_version(GPGME_PROTOCOL_OpenPGP); if(error) return false; // load engine info error = gpgme_get_engine_info(&info); if(error) return false; while(info && info->protocol != gpgme_get_protocol(mContext)) { info = info->next; } //callback for user passphrase gpgme_set_passphrase_cb(mContext, passphrase_cb, NULL); And the callback (similar to gpgme++): ----------------------------- static gpgme_error_t passphrase_cb(void *hook, const char *uid_hint, const char *passphrase_info, int prev_was_bad, int fd){ std::string passphraseString; std::cout<< "Enter your password:"; std::cin >> passphraseString; if(passphraseString.empty()){ return GPG_ERR_CANCELED; } size_t passphraseLength = passphraseString.size(); char* passphrase = new char[passphraseLength + 1]; std::copy(passphraseString.begin(), passphraseString.end(), passphrase); size_t written = 0; do { size_t nowWritten = gpgme_io_write(fd, passphrase + written, passphraseLength - written); if(nowWritten < 0) { break; } written += nowWritten; } while(written < passphraseLength); free(passphrase); gpgme_io_write(fd, "\n", 1); return 0; } -------------------------- From rjh at sixdemonbag.org Wed Jan 27 14:25:59 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 27 Jan 2016 08:25:59 -0500 Subject: AW: AW: AW: Key generation with GPGME and GnuPG hangs at gpgme_op_genkey In-Reply-To: References: <56A74DE2.7060003@sixdemonbag.org> <87twm06vnu.fsf@alice.fifthhorseman.net> <56A89691.4070700@sixdemonbag.org> Message-ID: <56A8C567.1030909@sixdemonbag.org> I don't have a solution for you, but -- > static gpgme_error_t passphrase_cb(void *hook, const char *uid_hint, const char *passphrase_info, > int prev_was_bad, int fd){ > > std::string passphraseString; > std::cout<< "Enter your password:"; > std::cin >> passphraseString; Use std::getline(), not >>. >> terminates at the first whitespace character; you want to read in a full line. > char* passphrase = new char[passphraseLength + 1]; Don't do this. C-style memory allocation is technically legal in C++, but *strongly* advised against. For that matter, you don't need to do it at all: you can rely on the fact the string address-of-element operator returns a char*. Consider the following trivial C++14 program: #include #include int main() { std::string foo { "Zaphod Beeblebrox for President\n" }; char* bar { &foo[0] }; for (size_t index = 0 ; index < foo.size() ; index += 1) { std::cout << *(bar + index); } return 0; } From andrewg at andrewg.com Wed Jan 27 15:20:37 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 27 Jan 2016 14:20:37 +0000 Subject: Problems with 4096 keys on 2.1 card In-Reply-To: <56A806C0.9010102@fsij.org> References: <3e0f6297c30e7e766a420b859a14279a.squirrel@10.99.199.22> <56A6C68B.3050400@fsij.org> <2b9a0ff157abb7087340c60db3873602.squirrel@10.99.199.22> <56A806C0.9010102@fsij.org> Message-ID: <56A8D235.5000409@andrewg.com> On 26/01/16 23:52, NIIBE Yutaka wrote: > > It had been difficult to configure GNOME keyring (to stop the feature > of gpg-agent) properly. Here is some info: > > http://www.gniibe.org/memo/notebook/gnome3-gpg-settings.html I fixed it by disabling gnome-keyring at system level. The following works under Jessie: echo "X-GNOME-Autostart-enabled=false" >> /etc/xdg/autostart/gnome-keyring-ssh.desktop echo "X-GNOME-Autostart-enabled=false" >> /etc/xdg/autostart/gnome-keyring-gpg.desktop NB this will affect all users. A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Wed Jan 27 15:42:54 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 27 Jan 2016 09:42:54 -0500 Subject: Key generation with GPGME and GnuPG hangs at gpgme_op_genkey In-Reply-To: References: <56A74DE2.7060003@sixdemonbag.org> <87twm06vnu.fsf@alice.fifthhorseman.net> <56A89691.4070700@sixdemonbag.org> Message-ID: <56A8D76E.3070306@sixdemonbag.org> > Yes, that was the problem. I installed haveged and it worked. But it seems > that the key generation in my C++ application will not work, if a custom passphrase > callback is set. The key generation code is unchanged, but with the callback I get an > GPG_ERR_GENERAL error. The init and callback code is as follows: I cleaned your code up a bit and it works fine. Compile with: $ g++ foo.cc -O2 -o foo -std=c++11 `gpgme-config --cflags --libs` or $ clang++ foo.cc -O2 -o foo -std=c++11 `gpgme-config --cflags --libs` #include #include #include #include using std::string; using std::cin; using std::cout; using std::cerr; using std::getline; static gpgme_error_t passphrase_cb(void *hook, const char *uid_hint, const char *passphrase_info, int prev_was_bad, int fd) { string passphrase { "" }; size_t written { 0 }; cout << "Enter your passphrase: "; getline(cin, passphrase); if (passphrase.empty()) return GPG_ERR_CANCELED; while (written < passphrase.size()) { ssize_t bytesWritten = gpgme_io_write(fd, &passphrase[0] + written, passphrase.size() - written); if (bytesWritten == 0) break; written += bytesWritten; } gpgme_io_write(fd, "\n", 1); return GPG_ERR_NO_ERROR; } int main() { int rv = -1; gpgme_ctx_t mContext; gpgme_engine_info_t info; gpgme_error_t error; bool contextInitialized { false }; const char* def = " \n" " Key-Type: default \n" " Subkey-Type: default \n" " Name-Real: Joe Tester3 \n" " Name-Comment: with stupid passphrase \n" " Name-Email: joe3 at foo.bar \n" " Expire-Date: 0 \n" " Passphrase: abc \n" " \n"; gpgme_check_version(nullptr); error = gpgme_new(&mContext); if (GPG_ERR_NO_ERROR != gpgme_err_code(error)) { cerr << "Couldn't create new context.\n"; goto BAIL_OUT; } contextInitialized = true; error = gpgme_engine_check_version(GPGME_PROTOCOL_OpenPGP); if (GPG_ERR_NO_ERROR != gpgme_err_code(error)) { cerr << "GPGME doesn't support OpenPGP.\n"; goto BAIL_OUT; } error = gpgme_get_engine_info(&info); if (GPG_ERR_NO_ERROR != gpgme_err_code(error)) { cerr << "Couldn't get engine information.\n"; goto BAIL_OUT; } error = gpgme_ctx_set_engine_info(mContext, GPGME_PROTOCOL_OpenPGP, nullptr, nullptr); if (GPG_ERR_NO_ERROR != gpgme_err_code(error)) { cerr << "Couldn't set engine to OpenPGP.\n"; goto BAIL_OUT; } gpgme_set_passphrase_cb(mContext, passphrase_cb, nullptr); error = gpgme_op_genkey(mContext, def, nullptr, nullptr); if (GPG_ERR_INV_VALUE == gpgme_err_code(error)) cerr << "Value error\n"; else if (GPG_ERR_NOT_SUPPORTED == gpgme_err_code(error)) cerr << "Not supported error\n"; else if (GPG_ERR_GENERAL == gpgme_err_code(error)) cerr << "general error\n"; else if (GPG_ERR_NO_ERROR == gpgme_err_code(error)) { gpgme_genkey_result_t res = gpgme_op_genkey_result(mContext); if (res->primary && res->sub) { rv = 0; } } BAIL_OUT: if (contextInitialized) gpgme_release(mContext); return rv; } From sbutler at fchn.com Wed Jan 27 15:53:31 2016 From: sbutler at fchn.com (Steve Butler) Date: Wed, 27 Jan 2016 14:53:31 +0000 Subject: BAD signatures for GnuPG Stable In-Reply-To: <56A84B44.1020604@gmail.com> References: <56A6F905.9060309@gmail.com> <87h9i0vgi6.fsf@vigenere.g10code.de> <56A84B44.1020604@gmail.com> Message-ID: <4b3eea0371f84248ab0e514092e2fd2d@t1l1exchmbs-01.fchn.com> Perhaps an ASCII download instead of binary? That would make the download file larger! -----Original Message----- From: Gnupg-users [mailto:gnupg-users-bounces+sbutler=fchn.com at gnupg.org] On Behalf Of Aaron Tovo Sent: Tuesday, January 26, 2016 8:45 PM To: gnupg-users at gnupg.org Subject: Re: BAD signatures for GnuPG Stable Interesting. The file I downloaded is actually larger than what it should be! -rw-rw-r-- 1 aaron aaron 855815 Jan 25 21:44 libgpg-error-1.21.tar.bz2 On 01/26/2016 03:26 AM, Werner Koch wrote: > On Tue, 26 Jan 2016 05:41, aarontovo at gmail.com said: > >> $ gpg --verify libgpg-error-1.21.tar.bz2.sig >> libgpg-error-1.21.tar.bz2 >> gpg: Signature made Sat 12 Dec 2015 06:03:30 AM CST using RSA key ID >> 4F25E3B6 >> gpg: BAD signature from "Werner Koch (dist sig)" > Please check the length of the file to make sure you downloaded it > complelety. > > The size of libgpg-error-1.21.tar.bz2 is 763186 bytes. > > > Shalom-Salam, > > Werner > _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users -- CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. From sasc0041 at stud.hs-kl.de Wed Jan 27 16:58:30 2016 From: sasc0041 at stud.hs-kl.de (Sandra Schreiner) Date: Wed, 27 Jan 2016 15:58:30 +0000 Subject: Key generation with GPGME and GnuPG hangs at gpgme_op_genkey In-Reply-To: <56A8D76E.3070306@sixdemonbag.org> References: <56A74DE2.7060003@sixdemonbag.org> <87twm06vnu.fsf@alice.fifthhorseman.net> <56A89691.4070700@sixdemonbag.org> , <56A8D76E.3070306@sixdemonbag.org> Message-ID: >> Yes, that was the problem. I installed haveged and it worked. But it seems >> that the key generation in my C++ application will not work, if a custom passphrase >> callback is set. The key generation code is unchanged, but with the callback I get an >> GPG_ERR_GENERAL error. The init and callback code is as follows: >I cleaned your code up a bit and it works fine. I can't get that work. I copy pasted you code in my project and executed your main, but I still get a 'general error'. In the meanwhile I upgraded my system from jesse to debian 'testing'. I'm now using GnuPG 2.0.28 and GPGME 1.6 but the problem stays the same. I build the application with QT Creator 3.6 without any specific flags for GnuPG. Is there anything left I could check or try to figure out where the problem is? Moreover I experience a very strange behaviour if i use my callback and a existing key for encryption. I want to encrypt a string only for a specific lists of recipients, but I get a password request for a uid that wasn't even included in the recipients list. It is always the same key with the uid 'dummy dummy...' (it was the first key ever created). The request is a window opened by GnuPG Agent, which seems to ingore my custom password callback. The window will sometimes just reopen periodically. I thought GnuPG might include this dummy key by default so I tried to use the GPGME_ENCRYPT_NO_ENCRYPT_TO flag... but the result stays the same. I feel like I should resign. The code for encryption is: encrypt(const std::string &plaintext, std::set uids, std::string &ciphertext) const{ bool result = false; //create a null terminated recipients array including current user int recipientsCount = uids.size() + 1; gpgme_key_t* recipients = new gpgme_key_t[recipientsCount]; int i = 0; for(auto const &curUid: uids){ //this will return the first gpgme key with exactly the given uid if(getGPGMEKey(curUid.c_str(), recipients[i], false)){ i++; } } recipients[i] = NULL; // null terminate the array gpgme_data_t plain; gpgme_data_t cipher; if(!convertStringToData(plaintext, plain) || gpgme_data_new(&cipher)){ //todo error code: data allocation error } else{ //at this point GnuPG Agents asks for 'dummy dummy' password if(gpgme_op_encrypt_sign(mContext, recipients, (gpgme_encrypt_flags_t)(GPGME_ENCRYPT_NO_ENCRYPT_TO), plain, cipher) || gpgme_op_encrypt_result(mContext)->invalid_recipients) { //todo error code: encryption error }else{ //now fetch the encrypted data if(convertDataToString(cipher, ciphertext)){ result = true; } } } //release references and buffer //... return result; } From sasc0041 at stud.hs-kl.de Wed Jan 27 18:12:26 2016 From: sasc0041 at stud.hs-kl.de (Sandra Schreiner) Date: Wed, 27 Jan 2016 17:12:26 +0000 Subject: AW: Key generation with GPGME and GnuPG hangs at gpgme_op_genkey In-Reply-To: References: <56A74DE2.7060003@sixdemonbag.org> <87twm06vnu.fsf@alice.fifthhorseman.net> <56A89691.4070700@sixdemonbag.org> , <56A8D76E.3070306@sixdemonbag.org>, Message-ID: >I can't get that work. I copy pasted you code in my project and executed your main, >but I still get a 'general error'. In the meanwhile I upgraded my system from jesse to >debian 'testing'. I'm now using GnuPG 2.0.28 and GPGME 1.6 but the problem stays the >same. I build the application with QT Creator 3.6 without any specific flags for GnuPG. >Is there anything left I could check or try to figure out where the problem is? I figured out what the problem was. I went back to Jessie with the old GnuPG and GPGME version and it worked fine, as you said. Unfortunately the other problem is not solved with the rollback to Jessie. Where does the 'unspecified' recipient come from? Does GnuPG use any defaults which can't be disabled by the flag GPGME_ENCRYPT_NO_ENCRYPT_TO? From rjh at sixdemonbag.org Wed Jan 27 21:12:38 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 27 Jan 2016 15:12:38 -0500 Subject: Key generation with GPGME and GnuPG hangs at gpgme_op_genkey In-Reply-To: References: <56A74DE2.7060003@sixdemonbag.org> <87twm06vnu.fsf@alice.fifthhorseman.net> <56A89691.4070700@sixdemonbag.org> <56A8D76E.3070306@sixdemonbag.org> Message-ID: <56A924B6.1080408@sixdemonbag.org> > I feel like I should resign. Without exception, *every* good programmer I know feels this way on a regular basis. Writing good software is hard and frustrating. I've been writing C++ since 1989, and I still frequently feel like an idiot. And I'm not one, and neither are you. Don't give up! So far we've cleared two major problems: the first was GnuPG taking ~15 minutes to generate a certificate, and the second was GPGME not working with your callback. Two major problems solved in two days. Imagine what we can get solved by the end of the week. Programming is hard, but you're not stupid, and you're in a place where you can get help. Stick with it. Things will be okay. From anushaph2 at gmail.com Wed Jan 27 14:04:45 2016 From: anushaph2 at gmail.com (anusha hegde) Date: Wed, 27 Jan 2016 18:34:45 +0530 Subject: GPG Installation in Solaris system Message-ID: Hi, I would like to install GPG Console in Solaris 10 system. Please give the the information regarding the source code file name and the installation steps. I am new to Unix and don't know much about it. Please help me out. Thanks & Regards, Anusha Hegde -------------- next part -------------- An HTML attachment was scrubbed... URL: From list.gnupg-users at acme.nu Wed Jan 27 23:39:03 2016 From: list.gnupg-users at acme.nu (Jorgen Ottosson) Date: Wed, 27 Jan 2016 23:39:03 +0100 Subject: Problems with 4096 keys on 2.1 card In-Reply-To: <8760yftl7d.fsf@vigenere.g10code.de> References: <3e0f6297c30e7e766a420b859a14279a.squirrel@10.99.199.22> <56A6C68B.3050400@fsij.org> <2b9a0ff157abb7087340c60db3873602.squirrel@10.99.199.22> <8760yftl7d.fsf@vigenere.g10code.de> Message-ID: >> $ gpg2 --card-status >> gpg: selecting openpgp failed: Unsupported certificate > > That is an interesting error message because that one is only used by > gpgsm and not by any components involved in gpg2 --card-status. Please > enter > > gpg-connect-agent -v > > and on its prompt > > SCD GETINFO version Well.. $ gpg-connect-agent -v gpg-connect-agent: connection to agent established > SCD GETINFO version ERR 103 unknown command > I'll try to do some testing with gnome keyrings etc too and get back later. Cheers, From dsaklad at gnu.org Thu Jan 28 03:08:43 2016 From: dsaklad at gnu.org (Don Saklad) Date: Wed, 27 Jan 2016 21:08:43 -0500 Subject: What's the contextual definition of the term?... signature Message-ID: <5ioac6a21g.fsf@fencepost.gnu.org> What's the contextual definition of the term?... signature as this term is used for GNUpg From girish.kumar at al-enterprise.com Thu Jan 28 05:55:49 2016 From: girish.kumar at al-enterprise.com (Girish Kumar) Date: Thu, 28 Jan 2016 04:55:49 +0000 Subject: Cross Compiling libgpg-error-1.21 for rsyslog-8.15.0: unrecognized option '--64'. In-Reply-To: References: Message-ID: Could you please guide me on the following . From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Girish Kumar Sent: Wednesday, January 27, 2016 11:39 AM To: gnupg-users at gnupg.org Subject: Cross Compiling libgpg-error-1.21 for rsyslog-8.15.0: unrecognized option '--64'. Hi All, I found following in README doc. Could you please explain what I should for armv7. Cross-Compiling --------------- Libgpg-error needs to figure out some platform specific properties. These are used to build the platform specific gpg-error.h file. The detection is done during build time but can't be done when cross-compiling. Thus if you run into an error during building you need to figure out these values. You may use these commands: build="$(build-aux/config.guess)" ./configure --prefix=TARGETDIR --host=TARGET --build=$build cd src make gen-posix-lock-obj scp gen-posix-lock-obj TARGET: ssh TARGET ./gen-posix-lock-obj >tmp.h mv tmp.h "syscfg/$(awk 'NR==1 {print $2}' tmp.h)" If you are using a VPATH build adjust accordingly. If this all works for you (make sure to run the test programs on the target platform), please send the generated file to the gnupg-devel mailing list so that we can include it in the next release. Note that in addition to the aliasing done by config.sub the src/mkheader build tool does some extra aliasing to avoid having too much identical syscfg files. Regards, Girish From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Girish Kumar Sent: Tuesday, January 26, 2016 8:36 PM To: gnupg-users at gnupg.org Subject: Cross Compiling libgpg-error-1.21 for rsyslog-8.15.0: unrecognized option '--64'. Dear All, I am compiling libgpg-error-1.21 which is a dependency library for libgcrypt-1.6.4 . This for armv7 platform Found some info on cross compilation, but was not able to understand. I am getting "unrecognized option '--64'" when compiling libgpg-error-1.21. Could you please help me on this.? gawk -f /home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/libgpg-error-1.21/src/mkerrnos.awk /home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/libgpg-error-1.21/src/errnos.in >code-to-errno.h gawk -f /home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/libgpg-error-1.21/src/mkerrcodes1.awk /home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/libgpg-error-1.21/src/errnos.in >_mkerrcodes.h arm-unknown-linux-gnueabi-gcc -E -mcpu=cortex-a9 -mabi=aapcs-linux -msoft-float -O -fno-omit-frame-pointer -mapcs-frame -mno-sched-prolog -I/soft/gnu/cross/linux_64/13/arm/sysroot/usr/include -I/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/built/46/7.X.X.R01/armv7/include -P _mkerrcodes.h | grep GPG_ERR_ | \ gawk -f /home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/libgpg-error-1.21/src/mkerrcodes.awk >mkerrcodes.h rm _mkerrcodes.h cc -I. -I/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/libgpg-error-1.21/src -o mkerrcodes /home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/libgpg-error-1.21/src/mkerrcodes.c as: unrecognized option '--64' make[4]: *** [mkerrcodes] Error 1 make[4]: Leaving directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/objs/46/7.X.X.R01/armv7/libgpg-error/src' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/objs/46/7.X.X.R01/armv7/libgpg-error' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/objs/46/7.X.X.R01/armv7/libgpg-error' make[2]: Entering directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/objs/46/7.X.X.R01/armv7/libgpg-error' Making install in m4 make[3]: Entering directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/objs/46/7.X.X.R01/armv7/libgpg-error/m4' make[4]: Entering directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/objs/46/7.X.X.R01/armv7/libgpg-error/m4' make[4]: Nothing to be done for `install-exec-am'. make[4]: Nothing to be done for `install-data-am'. make[4]: Leaving directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/objs/46/7.X.X.R01/armv7/libgpg-error/m4' make[3]: Leaving directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/objs/46/7.X.X.R01/armv7/libgpg-error/m4' Making install in src make[3]: Entering directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/objs/46/7.X.X.R01/armv7/libgpg-error/src' cc -I. -I/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/libgpg-error-1.21/src -o mkerrcodes /home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/libgpg-error-1.21/src/mkerrcodes.c as: unrecognized option '--64' make[3]: *** [mkerrcodes] Error 1 make[3]: Leaving directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/objs/46/7.X.X.R01/armv7/libgpg-error/src' make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/objs/46/7.X.X.R01/armv7/libgpg-error' make[1]: *** [/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps/installed/46/7.X.X.R01/armv7/ramdisk/lib/libgpg-error.so] Error 2 make[1]: Leaving directory `/home/gkuma020/PERFORCE/7.X.X.R01-gkuma020-new/engr/sw/tps' make: *** [tps-build] Error 2 + set +x Regards, Girish -------------- next part -------------- An HTML attachment was scrubbed... URL: From aarontovo at gmail.com Thu Jan 28 06:12:36 2016 From: aarontovo at gmail.com (Aaron Tovo) Date: Wed, 27 Jan 2016 23:12:36 -0600 Subject: BAD signatures for GnuPG Stable In-Reply-To: <4b3eea0371f84248ab0e514092e2fd2d@t1l1exchmbs-01.fchn.com> References: <56A6F905.9060309@gmail.com> <87h9i0vgi6.fsf@vigenere.g10code.de> <56A84B44.1020604@gmail.com> <4b3eea0371f84248ab0e514092e2fd2d@t1l1exchmbs-01.fchn.com> Message-ID: <56A9A344.1040606@gmail.com> It's definitely not an ascii file (having taken a peek at its content). I downloaded libgpg-error-1.21.tar.bz2 again today and it has a the correct size (763186) -rw-rw-r-- 1 aaron aaron 763186 Jan 27 22:53 libgpg-error-1.21(1).tar.bz2 I re-downloaded sig file and it still fails the gpg --verify test. $ gpg --verify libgpg-error-1.21.tar.bz2.sig gpg: Signature made Sat 12 Dec 2015 06:03:30 AM CST using RSA key ID 4F25E3B6 gpg: BAD signature from "Werner Koch (dist sig)" Could this be some kind of man-in-the-middle attack? I don't recall having seen a signature fail like this before. Aaron On 01/27/2016 08:53 AM, Steve Butler wrote: > Perhaps an ASCII download instead of binary? That would make the download file larger! > > > -----Original Message----- > From: Gnupg-users [mailto:gnupg-users-bounces+sbutler=fchn.com at gnupg.org] On Behalf Of Aaron Tovo > Sent: Tuesday, January 26, 2016 8:45 PM > To: gnupg-users at gnupg.org > Subject: Re: BAD signatures for GnuPG Stable > > Interesting. The file I downloaded is actually larger than what it should be! > > -rw-rw-r-- 1 aaron aaron 855815 Jan 25 21:44 libgpg-error-1.21.tar.bz2 > > > On 01/26/2016 03:26 AM, Werner Koch wrote: >> On Tue, 26 Jan 2016 05:41, aarontovo at gmail.com said: >> >>> $ gpg --verify libgpg-error-1.21.tar.bz2.sig >>> libgpg-error-1.21.tar.bz2 >>> gpg: Signature made Sat 12 Dec 2015 06:03:30 AM CST using RSA key ID >>> 4F25E3B6 >>> gpg: BAD signature from "Werner Koch (dist sig)" >> Please check the length of the file to make sure you downloaded it >> complelety. >> >> The size of libgpg-error-1.21.tar.bz2 is 763186 bytes. >> >> >> Shalom-Salam, >> >> Werner >> > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From antony at blazrsoft.com Thu Jan 28 06:45:02 2016 From: antony at blazrsoft.com (Antony Prince) Date: Thu, 28 Jan 2016 00:45:02 -0500 Subject: BAD signatures for GnuPG Stable In-Reply-To: <56A9A344.1040606@gmail.com> References: <56A6F905.9060309@gmail.com> <87h9i0vgi6.fsf@vigenere.g10code.de> <56A84B44.1020604@gmail.com> <4b3eea0371f84248ab0e514092e2fd2d@t1l1exchmbs-01.fchn.com> <56A9A344.1040606@gmail.com> Message-ID: <56A9AADE.9030802@blazrsoft.com> On 1/28/2016 12:12 AM, Aaron Tovo wrote: > It's definitely not an ascii file (having taken a peek at its content). > > I downloaded libgpg-error-1.21.tar.bz2 again today and it has a the > correct size (763186) > > -rw-rw-r-- 1 aaron aaron 763186 Jan 27 22:53 libgpg-error-1.21(1).tar.bz2 > > I re-downloaded sig file and it still fails the gpg --verify test. > > $ gpg --verify libgpg-error-1.21.tar.bz2.sig gpg: Signature made Sat 12 > Dec 2015 06:03:30 AM CST using RSA key ID 4F25E3B6 > gpg: BAD signature from "Werner Koch (dist sig)" > > Could this be some kind of man-in-the-middle attack? I don't recall > having seen a signature fail like this before. > I just downloaded both from the gnupg download site and the signature verified just fine. That is odd is about all I can say. Are you downloading it via FTP, HTTP, etc.? The results I got are pasted below. Maybe someone else has more insight. F:\Downloads>gpg --version gpg (GnuPG) 2.1.10 libgcrypt 1.6.4 Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: C:/Users/antony/AppData/Roaming/gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 F:\Downloads>gpg --verify libgpg-error-1.21.tar.bz2.sig gpg: assuming signed data in 'libgpg-error-1.21.tar.bz2' gpg: Signature made 12/12/15 07:03:30 Eastern Standard Time gpg: using RSA key 0x249B39D24F25E3B6 gpg: Good signature from "Werner Koch (dist sig)" [full] Primary key fingerprint: D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 -- 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 antony at blazrsoft.com Thu Jan 28 06:54:35 2016 From: antony at blazrsoft.com (Antony Prince) Date: Thu, 28 Jan 2016 00:54:35 -0500 Subject: BAD signatures for GnuPG Stable In-Reply-To: <56A9AADE.9030802@blazrsoft.com> References: <56A6F905.9060309@gmail.com> <87h9i0vgi6.fsf@vigenere.g10code.de> <56A84B44.1020604@gmail.com> <4b3eea0371f84248ab0e514092e2fd2d@t1l1exchmbs-01.fchn.com> <56A9A344.1040606@gmail.com> <56A9AADE.9030802@blazrsoft.com> Message-ID: <56A9AD1B.8000108@blazrsoft.com> On 1/28/2016 12:45 AM, Antony Prince wrote: > F:\Downloads>gpg --version > gpg (GnuPG) 2.1.10 I also just realized that you said BAD signature with gnupg _stable_ and my test was not with stable. My apologies. -- 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 rjh at sixdemonbag.org Thu Jan 28 06:56:31 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 28 Jan 2016 00:56:31 -0500 Subject: BAD signatures for GnuPG Stable In-Reply-To: <56A9A344.1040606@gmail.com> References: <56A6F905.9060309@gmail.com> <87h9i0vgi6.fsf@vigenere.g10code.de> <56A84B44.1020604@gmail.com> <4b3eea0371f84248ab0e514092e2fd2d@t1l1exchmbs-01.fchn.com> <56A9A344.1040606@gmail.com> Message-ID: <56A9AD8F.8050007@sixdemonbag.org> > Could this be some kind of man-in-the-middle attack? I don't recall > having seen a signature fail like this before. MitM is theoretically possible, but unlikely: an attacker would have to be both technically sophisticated and profoundly stupid. It's far more likely there's an innocuous explanation. The MD5 and SHA256 digests of it are: ab0b5aba6d0a185b41d07bda804fd8b2 b7dbdb3cad63a740e9f0c632a1da32d4afdb694ec86c8625c98ea0691713b84d I just downloaded it and was able to verify Werner's signature. From dgouttegattat at incenp.org Thu Jan 28 09:03:35 2016 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Thu, 28 Jan 2016 09:03:35 +0100 Subject: BAD signatures for GnuPG Stable In-Reply-To: <56A9A344.1040606@gmail.com> References: <56A6F905.9060309@gmail.com> <87h9i0vgi6.fsf@vigenere.g10code.de> <56A84B44.1020604@gmail.com> <4b3eea0371f84248ab0e514092e2fd2d@t1l1exchmbs-01.fchn.com> <56A9A344.1040606@gmail.com> Message-ID: <56A9CB57.4040908@incenp.org> On 01/28/2016 06:12 AM, Aaron Tovo wrote: > I downloaded libgpg-error-1.21.tar.bz2 again today and it has a the > correct size (763186) > > -rw-rw-r-- 1 aaron aaron 763186 Jan 27 22:53 libgpg-error-1.21(1).tar.bz2 > > I re-downloaded sig file and it still fails the gpg --verify test. Is the old libgpg-error-1.21.tar.bz2 (the one you downloaded before, with the wrong size) still present in the same directory? (I assume it is, based on the '(1)' suffix that has been appended to the new file you have just downloaded.) If that's the case, what happens when you call gpg like this: $ gpg --verify libgpg-error-1.21.tar.bz2.sig is that gpg will assume the signed file to verify is libgpg-error-1.21.tar.bz2. (Recent versions of GnuPG print a warning in situation like this, but older versions are silent about that assumption.) Either get rid of the old file, or explicitly tell gpg which file it should verify: $ gpg --verify libgpg-error-1.21.tar.bz2.sig libgpg-error-1.21(1).tar.bz2 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From fulanoperez at cryptolab.net Thu Jan 28 09:26:28 2016 From: fulanoperez at cryptolab.net (Fulano Diego Perez) Date: Thu, 28 Jan 2016 19:26:28 +1100 Subject: 2.1.10 with libgcrypt 1.7.0-beta300 In-Reply-To: <56A75828.1040508@cryptolab.net> References: <5693BACF.5070005@cryptolab.net> <56944E98.5000307@fsij.org> <56A37C00.5080905@cryptolab.net> <56A57B74.80007@fsij.org> <56A75828.1040508@cryptolab.net> Message-ID: <56A9D0B4.8030609@cryptolab.net> Fulano Diego Perez: > In my case on Debian, Are you on Debian stretch amd64 ? What are the versions of your dependencies ? We should compare jamon to jamon. From sasc0041 at stud.hs-kl.de Thu Jan 28 09:35:32 2016 From: sasc0041 at stud.hs-kl.de (Sandra Schreiner) Date: Thu, 28 Jan 2016 08:35:32 +0000 Subject: AW: Key generation with GPGME and GnuPG hangs at gpgme_op_genkey In-Reply-To: <56A924B6.1080408@sixdemonbag.org> References: <56A74DE2.7060003@sixdemonbag.org> <87twm06vnu.fsf@alice.fifthhorseman.net> <56A89691.4070700@sixdemonbag.org> <56A8D76E.3070306@sixdemonbag.org> , <56A924B6.1080408@sixdemonbag.org> Message-ID: >Don't give up! >So far we've cleared two major problems: the first was GnuPG taking ~15 >minutes to generate a certificate, and the second was GPGME not working >with your callback. Two major problems solved in two days. Imagine >what we can get solved by the end of the week. >Programming is hard, but you're not stupid, and you're in a place where >you can get help. Stick with it. Things will be okay. Thank you for this encouraging words. In fact I got solved another problem. It seems that the reason GnuPG was asking for the dummy password, was that this user was set as a signer in my context (as default). Now I use gpgme_signers_clear(mContext); before I encrypt/sign my string. The request for the dummy password disappeared. The only problem remaining is that the application still ignores my own password callback and uses the GnuPG default: gpgme_set_passphrase_cb(mContext, passphrase_cb, nullptr); I replaced my callback with your code: gpgme_error_t passphrase_cb(void *hook, const char *uid_hint, const char *passphrase_info, int prev_was_bad, int fd){ std::string passphrase { "" }; size_t written { 0 }; std::cout << "Enter your passphrase: "; std::getline(std::cin, passphrase); if (passphrase.empty()) return GPG_ERR_CANCELED; while (written < passphrase.size()) { ssize_t bytesWritten = gpgme_io_write(fd, &passphrase[0] + written, passphrase.size() - written); if (bytesWritten == 0) break; written += bytesWritten; } gpgme_io_write(fd, "\n", 1); return GPG_ERR_NO_ERROR; } From rjh at sixdemonbag.org Thu Jan 28 09:45:00 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 28 Jan 2016 03:45:00 -0500 Subject: AW: Key generation with GPGME and GnuPG hangs at gpgme_op_genkey In-Reply-To: References: <56A74DE2.7060003@sixdemonbag.org> <87twm06vnu.fsf@alice.fifthhorseman.net> <56A89691.4070700@sixdemonbag.org> <56A8D76E.3070306@sixdemonbag.org> <56A924B6.1080408@sixdemonbag.org> Message-ID: <56A9D50C.4010308@sixdemonbag.org> > Thank you for this encouraging words. In fact I got solved another problem. Woot! > The only problem remaining is that the application still ignores my > own password callback and uses the GnuPG default: This is actually expected behavior. See: https://bugs.gnupg.org/gnupg/issue767 >From Werner: "gpg2 can't use [custom passphrase handlers] as [using gpg-]agent is a hard requirement. The only reason for keeping the passphrase callback is for symmetric encryption." Since you're not using symmetric encryption -- you're generating a certificate -- your callback never gets called. From sasc0041 at stud.hs-kl.de Thu Jan 28 10:20:32 2016 From: sasc0041 at stud.hs-kl.de (Sandra Schreiner) Date: Thu, 28 Jan 2016 09:20:32 +0000 Subject: AW: AW: Key generation with GPGME and GnuPG hangs at gpgme_op_genkey In-Reply-To: <56A9D50C.4010308@sixdemonbag.org> References: <56A74DE2.7060003@sixdemonbag.org> <87twm06vnu.fsf@alice.fifthhorseman.net> <56A89691.4070700@sixdemonbag.org> <56A8D76E.3070306@sixdemonbag.org> <56A924B6.1080408@sixdemonbag.org> , <56A9D50C.4010308@sixdemonbag.org> Message-ID: >From Werner: "gpg2 can't use [custom passphrase handlers] as [using >gpg-]agent is a hard requirement. The only reason for keeping the >passphrase callback is for symmetric encryption." I guess I'm in real trouble now. The reason for this is a bit complex. My encprytion class is part of a framework, which shall be used on different plattforms. Therefore my own 'GPGME wrapper' (and the framework as a whole) should be available in C++ and Java. Before I started with my implementation I found this https://github.com/smartrevolution/gnupg-for-java wrapper of GPGME for Java (so I thought it should be generally possible to use GnuPG/GPGME in Java). But we decided to not use the existing wrapper, because it is old, (seems) unmaintained and we would like to have simpler interfaces and one solution for both, the C++ and Java world. Means: we just want to provide the simple and small interface in C++ and wrap this with JNI for Java. So the problem boils down to this question: What would happen if my class would be called by an android application? Would the pinentry provided by GnuPG work in this case? From rjh at sixdemonbag.org Thu Jan 28 10:32:03 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 28 Jan 2016 04:32:03 -0500 Subject: AW: Key generation with GPGME and GnuPG hangs at gpgme_op_genkey In-Reply-To: References: <56A74DE2.7060003@sixdemonbag.org> <87twm06vnu.fsf@alice.fifthhorseman.net> <56A89691.4070700@sixdemonbag.org> <56A8D76E.3070306@sixdemonbag.org> <56A924B6.1080408@sixdemonbag.org> <56A9D50C.4010308@sixdemonbag.org> Message-ID: <56A9E013.5050904@sixdemonbag.org> > I guess I'm in real trouble now. Maybe less than you think! > But we decided to not use the existing wrapper, because it is old, > (seems) unmaintained and we would like to have simpler interfaces and > one solution for both, the C++ and Java world. Means: we just want to > provide the simple and small interface in C++ and wrap this with JNI > for Java. Already been done for you. The guys at the Guardian Project maintain the official Java-GPGME bindings, *and* they're in production use on Android. https://github.com/guardianproject/gnupg-for-java There was some talk on this list a few months ago about getting some important patches in there, but looking over the Git log they seem to have not yet been applied. Antony Prince was the guy updating Guardian Project's code. See the thread at: http://www.gossamer-threads.com/lists/gnupg/users/73146 According to Antony, you can grab his updates from: ftp://blazrsoft.com/gnupg-for-java/ It wasn't responding for me just now, though. Antony, are you still maintaining this? From rjh at sixdemonbag.org Thu Jan 28 10:34:09 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 28 Jan 2016 04:34:09 -0500 Subject: AW: Key generation with GPGME and GnuPG hangs at gpgme_op_genkey In-Reply-To: <56A9E013.5050904@sixdemonbag.org> References: <56A74DE2.7060003@sixdemonbag.org> <87twm06vnu.fsf@alice.fifthhorseman.net> <56A89691.4070700@sixdemonbag.org> <56A8D76E.3070306@sixdemonbag.org> <56A924B6.1080408@sixdemonbag.org> <56A9D50C.4010308@sixdemonbag.org> <56A9E013.5050904@sixdemonbag.org> Message-ID: <56A9E091.6020103@sixdemonbag.org> > According to Antony, you can grab his updates from: > > ftp://blazrsoft.com/gnupg-for-java/ > > It wasn't responding for me just now, though. His webserver, though, is still going strong. Try: https://www.blazrsoft.com/gnupg-for-java/ From sasc0041 at stud.hs-kl.de Thu Jan 28 10:53:35 2016 From: sasc0041 at stud.hs-kl.de (Sandra Schreiner) Date: Thu, 28 Jan 2016 09:53:35 +0000 Subject: AW: Key generation with GPGME and GnuPG hangs at gpgme_op_genkey In-Reply-To: <56A9E013.5050904@sixdemonbag.org> References: <56A74DE2.7060003@sixdemonbag.org> <87twm06vnu.fsf@alice.fifthhorseman.net> <56A89691.4070700@sixdemonbag.org> <56A8D76E.3070306@sixdemonbag.org> <56A924B6.1080408@sixdemonbag.org> <56A9D50C.4010308@sixdemonbag.org> , <56A9E013.5050904@sixdemonbag.org> Message-ID: >> But we decided to not use the existing wrapper, because it is old, >> (seems) unmaintained and we would like to have simpler interfaces and >> one solution for both, the C++ and Java world. Means: we just want to >> provide the simple and small interface in C++ and wrap this with JNI >> for Java. >Already been done for you. The guys at the Guardian Project maintain >the official Java-GPGME bindings, *and* they're in production use on >Android. This will sadly not solve my problem. The GPGME interface is not the interface we would like to use for our purposes, because not all of the GPGME features should be available in our framework (intentionally). Therefore I would have to write (actually I already wrote, beside the callback problem) a C++ wrapper for GPGME. And I would have to write another wrapper for the Java wrapper, for the same reason. The combination of this would lead to maintaining at least two wrappers: the one for Java and the one for C++. Moreover the license is GPL and we would need LGPG. Maybe this point could be solved with separate license negotiations. But for now I guess I'm back to my question: What would happen if I would rely on pinentry in android? From rjh at sixdemonbag.org Thu Jan 28 11:54:59 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 28 Jan 2016 05:54:59 -0500 Subject: AW: Key generation with GPGME and GnuPG hangs at gpgme_op_genkey In-Reply-To: References: <56A74DE2.7060003@sixdemonbag.org> <87twm06vnu.fsf@alice.fifthhorseman.net> <56A89691.4070700@sixdemonbag.org> <56A8D76E.3070306@sixdemonbag.org> <56A924B6.1080408@sixdemonbag.org> <56A9D50C.4010308@sixdemonbag.org> <56A9E013.5050904@sixdemonbag.org> Message-ID: <56A9F383.2000604@sixdemonbag.org> > Moreover the license is GPL and we would need LGPG. Maybe this point > could be solved with separate license negotiations. The GnuPG developers have historically been unwilling to provide GPGME under any terms except the GPL. If you need an LGPLed GPGME, you're out of luck. If you can't/won't use GPLed code, we insist you not use GPGME. If you can, we're happy to continue helping you address your problems with it. From stebe at mailbox.org Thu Jan 28 13:46:39 2016 From: stebe at mailbox.org (stebe at mailbox.org) Date: Thu, 28 Jan 2016 13:46:39 +0100 (CET) Subject: Problems with 4096 keys on 2.1 card In-Reply-To: <56A8D235.5000409@andrewg.com> References: <3e0f6297c30e7e766a420b859a14279a.squirrel@10.99.199.22> <56A6C68B.3050400@fsij.org> <2b9a0ff157abb7087340c60db3873602.squirrel@10.99.199.22> <56A806C0.9010102@fsij.org> <56A8D235.5000409@andrewg.com> Message-ID: <570779784.25674.de08ed73-f9ab-4718-b848-5569387fe7fe.open-xchange@office.mailbox.org> Hi, > Andrew Gallagher hat am 27. Januar 2016 um 15:20 > geschrieben: > > > On 26/01/16 23:52, NIIBE Yutaka wrote: > > > > It had been difficult to configure GNOME keyring (to stop the feature > > of gpg-agent) properly. Here is some info: > > > > http://www.gniibe.org/memo/notebook/gnome3-gpg-settings.html > > I fixed it by disabling gnome-keyring at system level. The following > works under Jessie: > > echo "X-GNOME-Autostart-enabled=false" >> > /etc/xdg/autostart/gnome-keyring-ssh.desktop > echo "X-GNOME-Autostart-enabled=false" >> > /etc/xdg/autostart/gnome-keyring-gpg.desktop > > NB this will affect all users. > I used (for a debian system, system-wide basis) the following command which I found in the wiki. $ sudo dpkg-divert --local --rename --divert /etc/xdg/autostart/gnome-keyring-gpg.desktop-disable --add /etc/xdg/autostart/gnome-keyring-gpg.desktop If you later decide to reenable it, then you can use: $ sudo dpkg-divert --rename --remove /etc/xdg/autostart/gnome-keyring-gpg.desktop http://wiki.gnupg.org/GnomeKeyring Cheers, Stebe From stebe at mailbox.org Thu Jan 28 14:15:03 2016 From: stebe at mailbox.org (stebe at mailbox.org) Date: Thu, 28 Jan 2016 14:15:03 +0100 (CET) Subject: BAD signatures for GnuPG Stable In-Reply-To: <56A9A344.1040606@gmail.com> References: <56A6F905.9060309@gmail.com> <87h9i0vgi6.fsf@vigenere.g10code.de> <56A84B44.1020604@gmail.com> <4b3eea0371f84248ab0e514092e2fd2d@t1l1exchmbs-01.fchn.com> <56A9A344.1040606@gmail.com> Message-ID: <399373840.25836.de08ed73-f9ab-4718-b848-5569387fe7fe.open-xchange@office.mailbox.org> Hi, > Aaron Tovo hat am 28. Januar 2016 um 06:12 > geschrieben: > I re-downloaded sig file and it still fails the gpg --verify test. > > $ gpg --verify libgpg-error-1.21.tar.bz2.sig gpg: Signature made Sat 12 > Dec 2015 06:03:30 AM CST using RSA key ID 4F25E3B6 > gpg: BAD signature from "Werner Koch (dist sig)" > > Could this be some kind of man-in-the-middle attack? I don't recall > having seen a signature fail like this before. > If you are really interested in further invesigating it, it seems that this might be useful for you. I haven't checked it yet, though. (1) https://github.com/Whonix/gpg-bash-lib Quote from (1) Why Writing bash scripts that do file verification using gpg that really is secure and passes a comprehensive threat model, that covers indefinite freeze, rollback, endless data attacks, etc. is hard. gpg-bash-lib's goal is to provide a bash library that we can collaboratively develop, audit and abstract the hard work into reuseable functions. Checking gpg exit codes only is insufficient. Quote Werner Koch (gnupg lead developer): "there is no clear distinction between the codes and for proper error reporting you are advised to use the --status-fd messages." What does it do Abstracts file verification into common functions. Allows detecting of stale files, i.e. detection downgrade or indefinite freeze attacks by implementing a valid-until like mechanism. Internally parses gpg's --status-file output. It is signal friendly. Detects endless data attacks, aborts and reports this. Detects indefinite freeze and rollback (downgrade) attacks and reports this. Can help with verification of names of files, that are otherwise not covered by default when using gpg. Provide diagnostic output (variables) that contain information if the local clock is sane by comparing signature creation date with local clock. [...] Introduction It is assumed, that your script downloaded a data file as well as a signature file. A separate folder containing the keys that are supposed to be used for gpg verification, such as for example /usr/share/program-name/signing-keys.d is required as a prerequisite. You can then use this library to do the gpg verification for you. Cheers, Stebe From samir at samirnassar.com Thu Jan 28 15:32:02 2016 From: samir at samirnassar.com (Samir Nassar) Date: Thu, 28 Jan 2016 15:32:02 +0100 Subject: What's the contextual definition of the term?... signature In-Reply-To: <5ioac6a21g.fsf@fencepost.gnu.org> References: <5ioac6a21g.fsf@fencepost.gnu.org> Message-ID: <6860093.Kzhflg9CZN@lathe> On Wednesday 27 January 2016 21:08:43 Don Saklad wrote: > What's the contextual definition of the term?... signature > as this term is used for GNUpg A signature, also known as a "John Hancock": https://commons.wikimedia.org/wiki/File:JohnHancocksSignature.svg -- Samir Nassar samir at samirnassar.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From aarontovo at gmail.com Thu Jan 28 16:31:31 2016 From: aarontovo at gmail.com (Aaron Tovo) Date: Thu, 28 Jan 2016 09:31:31 -0600 Subject: BAD signatures for GnuPG Stable In-Reply-To: <399373840.25836.de08ed73-f9ab-4718-b848-5569387fe7fe.open-xchange@office.mailbox.org> References: <56A6F905.9060309@gmail.com> <87h9i0vgi6.fsf@vigenere.g10code.de> <56A84B44.1020604@gmail.com> <4b3eea0371f84248ab0e514092e2fd2d@t1l1exchmbs-01.fchn.com> <56A9A344.1040606@gmail.com> <399373840.25836.de08ed73-f9ab-4718-b848-5569387fe7fe.open-xchange@office.mailbox.org> Message-ID: <56AA3453.6040607@gmail.com> Thanks for the info. Today I re-downloaded the .bz2 and .sig. And the verification worked (see output below). I did file diffs between the new and the previous downloads with 'diff' and they are identical. So I tried verify on the previous download and it worked this time. Very confusing. I've also downloaded the rest of the packages for building GnuPG 2.0.29 and verification succeeded on all of them. $ gpg --verify libgpg-error-1.21.tar.bz2.sig libgpg-error-1.21.tar.bz2 gpg: Signature made Sat 12 Dec 2015 06:03:30 AM CST using RSA key ID 4F25E3B6 gpg: Good signature from "Werner Koch (dist sig)" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 On 01/28/2016 07:15 AM, stebe at mailbox.org wrote: > Hi, > >> Aaron Tovo hat am 28. Januar 2016 um 06:12 >> geschrieben: > >> I re-downloaded sig file and it still fails the gpg --verify test. >> >> $ gpg --verify libgpg-error-1.21.tar.bz2.sig gpg: Signature made Sat 12 >> Dec 2015 06:03:30 AM CST using RSA key ID 4F25E3B6 >> gpg: BAD signature from "Werner Koch (dist sig)" >> >> Could this be some kind of man-in-the-middle attack? I don't recall >> having seen a signature fail like this before. >> > If you are really interested in further invesigating it, it seems that > this might be useful for you. I haven't checked it yet, though. > > (1) https://github.com/Whonix/gpg-bash-lib > > Quote from (1) > > Why > > Writing bash scripts that do file verification using gpg that really is > secure and passes a comprehensive threat model, that covers indefinite > freeze, rollback, endless data attacks, etc. is hard. > > gpg-bash-lib's goal is to provide a bash library that we can > collaboratively develop, audit and abstract the hard work into reuseable > functions. > > Checking gpg exit codes only is insufficient. Quote Werner Koch (gnupg > lead developer): > > "there is no clear distinction between the codes and for proper error > reporting you are advised to use the --status-fd messages." > > > What does it do > > Abstracts file verification into common functions. > Allows detecting of stale files, i.e. detection downgrade or > indefinite freeze attacks by implementing a valid-until like mechanism. > Internally parses gpg's --status-file output. > It is signal friendly. > Detects endless data attacks, aborts and reports this. > Detects indefinite freeze and rollback (downgrade) attacks and reports > this. > Can help with verification of names of files, that are otherwise not > covered by default when using gpg. > Provide diagnostic output (variables) that contain information if the > local clock is sane by comparing signature creation date with local clock. > > [...] > > Introduction > > It is assumed, that your script downloaded a data file as well as a > signature file. A separate folder containing the keys that are supposed to > be used for gpg verification, such as for example > /usr/share/program-name/signing-keys.d is required as a prerequisite. You > can then use this library to do the gpg verification for you. > > Cheers, > > Stebe From peter at digitalbrains.com Thu Jan 28 17:00:20 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 28 Jan 2016 17:00:20 +0100 Subject: BAD signatures for GnuPG Stable In-Reply-To: <56AA3453.6040607@gmail.com> References: <56A6F905.9060309@gmail.com> <87h9i0vgi6.fsf@vigenere.g10code.de> <56A84B44.1020604@gmail.com> <4b3eea0371f84248ab0e514092e2fd2d@t1l1exchmbs-01.fchn.com> <56A9A344.1040606@gmail.com> <399373840.25836.de08ed73-f9ab-4718-b848-5569387fe7fe.open-xchange@office.mailbox.org> <56AA3453.6040607@gmail.com> Message-ID: <1d7ea751bb0a85ed15e1dbead3e9118e@butters.digitalbrains.com> On 2016-01-28 16:31, Aaron Tovo wrote: > I did file diffs between the new and the previous > downloads with 'diff' and they are identical. So I tried verify on > the > previous download and it worked this time. Very confusing. My guess is that sharp-eyed Damien Goutte-Gattat was correct and you were accidentally verifying your first, corrupt download instead of your new one the previous time. I'm glad that you've finally got a hold of the correct file :). 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 aarontovo at gmail.com Thu Jan 28 17:27:21 2016 From: aarontovo at gmail.com (Aaron Tovo) Date: Thu, 28 Jan 2016 10:27:21 -0600 Subject: BAD signatures for GnuPG Stable In-Reply-To: <1d7ea751bb0a85ed15e1dbead3e9118e@butters.digitalbrains.com> References: <56A6F905.9060309@gmail.com> <87h9i0vgi6.fsf@vigenere.g10code.de> <56A84B44.1020604@gmail.com> <4b3eea0371f84248ab0e514092e2fd2d@t1l1exchmbs-01.fchn.com> <56A9A344.1040606@gmail.com> <399373840.25836.de08ed73-f9ab-4718-b848-5569387fe7fe.open-xchange@office.mailbox.org> <56AA3453.6040607@gmail.com> <1d7ea751bb0a85ed15e1dbead3e9118e@butters.digitalbrains.com> Message-ID: <56AA4169.9090402@gmail.com> Probably. Although I did get a failure when using both parameters, but it was a different error message. $ gpg --verify libgpg-error-1.21.tar.bz2.sig libgpg-error-1.21\(1\).tar.bz2 gpg: can't open `libgpg-error-1.21.tar.bz2.sig' gpg: verify signatures failed: file open error But I was also renaming files and trying a lot of different things and I may well have made a mistake in all of that. Anyway thanks for your help people. I'm on my way. :) Aaron On 01/28/2016 10:00 AM, Peter Lebbing wrote: > On 2016-01-28 16:31, Aaron Tovo wrote: >> I did file diffs between the new and the previous >> downloads with 'diff' and they are identical. So I tried verify on the >> previous download and it worked this time. Very confusing. > > My guess is that sharp-eyed Damien Goutte-Gattat was correct and you > were accidentally verifying your first, corrupt download instead of > your new one the previous time. > > I'm glad that you've finally got a hold of the correct file :). > > Peter. > From wk at gnupg.org Thu Jan 28 18:13:13 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 28 Jan 2016 18:13:13 +0100 Subject: AW: Key generation with GPGME and GnuPG hangs at gpgme_op_genkey In-Reply-To: <56A9F383.2000604@sixdemonbag.org> (Robert J. Hansen's message of "Thu, 28 Jan 2016 05:54:59 -0500") References: <56A74DE2.7060003@sixdemonbag.org> <87twm06vnu.fsf@alice.fifthhorseman.net> <56A89691.4070700@sixdemonbag.org> <56A8D76E.3070306@sixdemonbag.org> <56A924B6.1080408@sixdemonbag.org> <56A9D50C.4010308@sixdemonbag.org> <56A9E013.5050904@sixdemonbag.org> <56A9F383.2000604@sixdemonbag.org> Message-ID: <87io2doceu.fsf@vigenere.g10code.de> On Thu, 28 Jan 2016 11:54, rjh at sixdemonbag.org said: > The GnuPG developers have historically been unwilling to provide GPGME > under any terms except the GPL. If you need an LGPLed GPGME, you're out > of luck. That is right for GnuPG but not for GPGME. From gpgme/AUTHORS: License (software): LGPLv2.1+ License (manual+tools): GPLv3+ and from a decade old release note: Noteworthy changes in version 1.0.2 (2004-12-28) ------------------------------------------------ * Changed the license of the library to the GNU Lesser General Public License (LGPL), version 2.1 or later. BTW: A C++ language binding for GPGME is available from KDE. IIRC, this has no Qt or KDE dependencies. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 bytes Desc: not available URL: From wk at gnupg.org Thu Jan 28 18:15:35 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 28 Jan 2016 18:15:35 +0100 Subject: Problems with 4096 keys on 2.1 card In-Reply-To: (Jorgen Ottosson's message of "Wed, 27 Jan 2016 23:39:03 +0100") References: <3e0f6297c30e7e766a420b859a14279a.squirrel@10.99.199.22> <56A6C68B.3050400@fsij.org> <2b9a0ff157abb7087340c60db3873602.squirrel@10.99.199.22> <8760yftl7d.fsf@vigenere.g10code.de> Message-ID: <87egd1ocaw.fsf@vigenere.g10code.de> On Wed, 27 Jan 2016 23:39, list.gnupg-users at acme.nu said: > $ gpg-connect-agent -v > gpg-connect-agent: connection to agent established >> SCD GETINFO version > ERR 103 unknown command You are not running the GnuPG gpg-agent. Very likely the gnome-keyring-daemon has hijacked the socket gpg uses to talk to gpg-agent. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From fa-ml at ariis.it Thu Jan 28 17:13:18 2016 From: fa-ml at ariis.it (Francesco Ariis) Date: Thu, 28 Jan 2016 17:13:18 +0100 Subject: What's the contextual definition of the term?... signature In-Reply-To: <5ioac6a21g.fsf@fencepost.gnu.org> References: <5ioac6a21g.fsf@fencepost.gnu.org> Message-ID: <20160128161318.GA2610@casa.casa> On Wed, Jan 27, 2016 at 09:08:43PM -0500, Don Saklad wrote: > What's the contextual definition of the term?... signature > as this term is used for GNUpg Since you have only received (not so) funny answers: a signature, in PGP, serves more or less the same purpose of a handwritten one. Most of the time it will mean "I am the author of this (email|document| article)" but not always -- as with handwritten one it could be used within a contract, etc. If you have the public key of person A, you can verify with PGP his signature, so you will be sure the document you received has not been tampered with. From antony at blazrsoft.com Thu Jan 28 19:06:05 2016 From: antony at blazrsoft.com (Antony Prince) Date: Thu, 28 Jan 2016 13:06:05 -0500 Subject: AW: Key generation with GPGME and GnuPG hangs at gpgme_op_genkey In-Reply-To: <56A9E013.5050904@sixdemonbag.org> References: <56A74DE2.7060003@sixdemonbag.org> <87twm06vnu.fsf@alice.fifthhorseman.net> <56A89691.4070700@sixdemonbag.org> <56A8D76E.3070306@sixdemonbag.org> <56A924B6.1080408@sixdemonbag.org> <56A9D50C.4010308@sixdemonbag.org> <56A9E013.5050904@sixdemonbag.org> Message-ID: <56AA588D.8060206@blazrsoft.com> On 1/28/2016 4:32 AM, Robert J. Hansen wrote: ... > > Antony Prince was the guy updating Guardian Project's code. See the > thread at: > > http://www.gossamer-threads.com/lists/gnupg/users/73146 > > According to Antony, you can grab his updates from: > > ftp://blazrsoft.com/gnupg-for-java/ > > It wasn't responding for me just now, though. Antony, are you still > maintaining this? > I switched hosting providers a month or two ago and those files may have slipped through the cracks. If anyone is interested in the pre-compiled files, I can set it up again. The code was pretty much exactly the same as that from guardian project except I made a few modifications to the build process so it could be built by the travis continuous integration system. If you are familiar with Java and Maven, it would probably be best to build it natively using Maven on your host system. I tested the binaries on a few systems (all Ubuntu) and it seemed to work as expected, but I'm not 100% sure if there are any bindings created and if there are, that they are system independent. If you need a hand with the maven build process, I'll be happy to help. -- Antony Prince -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 884 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Thu Jan 28 20:15:27 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 28 Jan 2016 14:15:27 -0500 Subject: AW: Key generation with GPGME and GnuPG hangs at gpgme_op_genkey In-Reply-To: <87io2doceu.fsf@vigenere.g10code.de> References: <56A74DE2.7060003@sixdemonbag.org> <87twm06vnu.fsf@alice.fifthhorseman.net> <56A89691.4070700@sixdemonbag.org> <56A8D76E.3070306@sixdemonbag.org> <56A924B6.1080408@sixdemonbag.org> <56A9D50C.4010308@sixdemonbag.org> <56A9E013.5050904@sixdemonbag.org> <56A9F383.2000604@sixdemonbag.org> <87io2doceu.fsf@vigenere.g10code.de> Message-ID: <56AA68CF.2090804@sixdemonbag.org> > That is right for GnuPG but not for GPGME. From gpgme/AUTHORS: Really? I thought GPGME had a dependency on libgpg-error, and the COPYING file for that is clearly GPLv2. From kloecker at kde.org Thu Jan 28 20:52:14 2016 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Thu, 28 Jan 2016 20:52:14 +0100 Subject: BAD signatures for GnuPG Stable In-Reply-To: <56AA3453.6040607@gmail.com> References: <56A6F905.9060309@gmail.com> <399373840.25836.de08ed73-f9ab-4718-b848-5569387fe7fe.open-xchange@office.mailbox.org> <56AA3453.6040607@gmail.com> Message-ID: <12433235.m7ILdLy8o0@thufir> On Thursday 28 January 2016 09:31:31 Aaron Tovo wrote: > Thanks for the info. > > Today I re-downloaded the .bz2 and .sig. And the verification worked > (see output below). I did file diffs between the new and the previous > downloads with 'diff' and they are identical. So I tried verify on the > previous download and it worked this time. Very confusing. I had a similarly confusing incident with some FLAC files intermittently being logged as corrupted by vlc. It turned out that I had bad RAM that lead to subtle differences in the files if they happened to be put onto the bad RAM by the kernel's file cache. Long story short, I suggest that you check your RAM. 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 wk at gnupg.org Thu Jan 28 21:08:12 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 28 Jan 2016 21:08:12 +0100 Subject: AW: Key generation with GPGME and GnuPG hangs at gpgme_op_genkey In-Reply-To: <56AA68CF.2090804@sixdemonbag.org> (Robert J. Hansen's message of "Thu, 28 Jan 2016 14:15:27 -0500") References: <56A74DE2.7060003@sixdemonbag.org> <87twm06vnu.fsf@alice.fifthhorseman.net> <56A89691.4070700@sixdemonbag.org> <56A8D76E.3070306@sixdemonbag.org> <56A924B6.1080408@sixdemonbag.org> <56A9D50C.4010308@sixdemonbag.org> <56A9E013.5050904@sixdemonbag.org> <56A9F383.2000604@sixdemonbag.org> <87io2doceu.fsf@vigenere.g10code.de> <56AA68CF.2090804@sixdemonbag.org> Message-ID: <8760ydo4b7.fsf@vigenere.g10code.de> On Thu, 28 Jan 2016 20:15, rjh at sixdemonbag.org said: > Really? I thought GPGME had a dependency on libgpg-error, and the > COPYING file for that is clearly GPLv2. That is just a file. COPYING describes the licence used for the manual and the tools. COPYING.LIB describes the license for the library itself (LGPLv2.1+). AUTHORS and gpg-error.h also show that it is LGPLv2.1+. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 bytes Desc: not available URL: From sbutler at fchn.com Thu Jan 28 21:16:53 2016 From: sbutler at fchn.com (Steve Butler) Date: Thu, 28 Jan 2016 20:16:53 +0000 Subject: BAD signatures for GnuPG Stable In-Reply-To: <12433235.m7ILdLy8o0@thufir> References: <56A6F905.9060309@gmail.com> <399373840.25836.de08ed73-f9ab-4718-b848-5569387fe7fe.open-xchange@office.mailbox.org> <56AA3453.6040607@gmail.com> <12433235.m7ILdLy8o0@thufir> Message-ID: <5b839797487c49088ca1957223132ea3@t1l1exchmbs-01.fchn.com> Did you say this was on a VM? We've had corrupted files with 'cp' from one file system to another on a VM box if it decided to do a vmotion while the copy was in progress. Just remember -- "To err is human, but to really foul things up you need a computer."(Paul Ehrlich) -----Original Message----- From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Ingo Kl?cker Sent: Thursday, January 28, 2016 11:52 AM To: gnupg-users at gnupg.org Subject: Re: BAD signatures for GnuPG Stable On Thursday 28 January 2016 09:31:31 Aaron Tovo wrote: > Thanks for the info. > > Today I re-downloaded the .bz2 and .sig. And the verification worked > (see output below). I did file diffs between the new and the previous > downloads with 'diff' and they are identical. So I tried verify on the > previous download and it worked this time. Very confusing. I had a similarly confusing incident with some FLAC files intermittently being logged as corrupted by vlc. It turned out that I had bad RAM that lead to subtle differences in the files if they happened to be put onto the bad RAM by the kernel's file cache. Long story short, I suggest that you check your RAM. Regards, Ingo -- CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. From aarcane at aarcane.org Fri Jan 29 02:38:03 2016 From: aarcane at aarcane.org (Schlacta, Christ) Date: Thu, 28 Jan 2016 17:38:03 -0800 Subject: What's the contextual definition of the term?... signature In-Reply-To: References: <5ioac6a21g.fsf@fencepost.gnu.org> Message-ID: I sent this a while ago in case anybody else wants to read it, but accidentally only to Don. On Jan 28, 2016 7:42 AM, "Schlacta, Christ" wrote: > Unofficially, but functionality and contextually correct.. A cryptographic > signature is a cryptographically strong hash of a message that has been > encrypted from an agent's private key to its public key such that anybody > with the public key can verify the message, yet nobody except the agent > with the private key could have generated said signature. > The function is both to verify that the sender specified in the message is > the one who sent it, and that the message is exactly and only the message > the sender sent. > On Jan 27, 2016 7:01 PM, "Don Saklad" wrote: > >> What's the contextual definition of the term?... signature >> as this term is used for GNUpg >> >> _______________________________________________ >> 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 bre at pagekite.net Fri Jan 29 19:32:09 2016 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Fri, 29 Jan 2016 18:32:09 -0000 Subject: User experience of --hidden-recipient encryption Message-ID: <20160129182353-2641-48887-mailpile@advancedsearch-virginmedia-com> Hello GnuPG-users! I am (still) working on Mailpile, and it was brought to my attention that if I send encrypted mail with folks in the BCC line, the fact that they got a copy is leaked unless: a) I use --hidden-recipient b) I send them their own separate copy of the mail, encrypted only to them I am trying to chose between these options (see issue https://github.com/mailpile/Mailpile/issues/1561 ). Using --hidden-recipient is more efficient and easier to implement, but I wonder how this is handled on the receiving end? If the user only has one public/private key pair, I assume the experience isn't too bad, GnuPG will just make a guess. But if the user has multiple keys, do they have to enter the passphrase for each in succession, as gpg tries to guess how to decrypt? How does this work in practice? Is --hidden-recipient a decent user experience for the recipient? Also, if I go with a), does that leak the fact that there were hidden recipients? Does it leak how many? Thanks, - Bjarni -------------- next part -------------- A non-text attachment was scrubbed... Name: Encryption key for Bjarni Runar Einarsson.asc Type: application/pgp-keys Size: 24204 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP Digital Signature URL: From mlisten at hammernoch.net Fri Jan 29 23:25:53 2016 From: mlisten at hammernoch.net (=?UTF-8?B?THVkd2lnIEjDvGdlbHNjaMOkZmVy?=) Date: Fri, 29 Jan 2016 23:25:53 +0100 Subject: User experience of --hidden-recipient encryption In-Reply-To: <20160129182353-2641-48887-mailpile@advancedsearch-virginmedia-com> References: <20160129182353-2641-48887-mailpile@advancedsearch-virginmedia-com> Message-ID: <56ABE6F1.3080406@hammernoch.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 29.01.16 19:32, Bjarni Runar Einarsson wrote: > (...) Using --hidden-recipient is more efficient and easier to > implement, but I wonder how this is handled on the receiving end? > If the user only has one public/private key pair, I assume the > experience isn't too bad, GnuPG will just make a guess. But if the > user has multiple keys, do they have to enter the passphrase for > each in succession, as gpg tries to guess how to decrypt? Yes, and it's a PITA if you have multiple secret keys. Ludwig -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWq+ahAAoJEDrb+m0Aoeb+Bn4QANHAbKnl5TkWzHTg1exq2uWe JPWAvo441fKUIjVzGyksIWH9aRKkVKOefmlktbaJViuw/Yu0REO7VyWXypF5hWxS CEpnnzljkUwPe5+bRqWvKXsv+CS6nynGU86FCRBtAD4lhECtmt6/X8RhhQ1YwZpj F5ssjD1BiiX6dt2+29ORxu7Fqzm2o9fjh3R3FM0xDpEVhrF7yJUEZ3JcCUqN7lh/ Q73aeSC1nMi8VOFt5tm0YK/UBHQRR154eJXuNNeSmFqJ6onOzgZNZXjAtLT2Oc/5 mVsFOH1mgFZJsmsQZNuPJQmnofPNQ0/PXg31LG4MJYwk5rY3/ixTzpQJqIQ2kVc9 eeTYOPhfdbg1mYHdVY96n4ZvMMhjISMV9KbeSNkTG1obgfwyJpj3HGljtUoToPcd 6thoopRxh3f5gI/arY6CR4tvPoxz5Vwt2vX6u5T794H5xQ655QyAC1osVOmpCe/U R0QlLHLuV+TjFQ6JUhcBaG3zA/CoapwDJX+zqLQlRnwFJ5JYqJczWdaGzNXwEQ3e or7WETZwjCMMJlCt310sfaobasv0jycRv6kPEkogRzsAdr4yy1hhvGTWxW4yBhDb bSc7z3XyHTizP0VJTTm87nRQeqcCsv4SBBxGYymqJ1VpvxE+ylad96VKubA+v20a Lm6q5vFe8GCwCc/4iYBd =nuF8 -----END PGP SIGNATURE----- From sasc0041 at stud.hs-kl.de Sat Jan 30 10:13:42 2016 From: sasc0041 at stud.hs-kl.de (Sandra Schreiner) Date: Sat, 30 Jan 2016 09:13:42 +0000 Subject: Default configuration of GnuPG preferred chiphers and hashfunctions Message-ID: Hello again, I somehow can't get GPGME to work with a custom configuration directory for GnuPG. Every time I set a path any key generation fails with a GPGME_ERR_GENERAL afterwards. There is nothing special about how I set the path: gpgme_engine_info_t info; gpgme_error_t error; const char* dir = "/home/myuser/crypttest"; // Initializes gpgme gpgme_check_version(NULL); // Initialize the locale environment. setlocale(LC_ALL, ""); gpgme_set_locale(NULL, LC_CTYPE, setlocale(LC_CTYPE, NULL)); #ifdef LC_MESSAGES gpgme_set_locale(NULL, LC_MESSAGES, setlocale(LC_MESSAGES, NULL)); #endif //also tried this, but this didn't work either: // error = gpgme_set_engine_info(GPGME_PROTOCOL_OpenPGP, NULL, // CONFIG_DIR); if(error) return false; error = gpgme_new(&mContext); if(error) return false; // Check OpenPGP error = gpgme_engine_check_version(GPGME_PROTOCOL_OpenPGP); if(error) return false; // load engine info error = gpgme_get_engine_info(&info); if(error) return false; while(info && info->protocol != gpgme_get_protocol(mContext)) { info = info->next; } // set path to config file error = gpgme_ctx_set_engine_info(mContext, GPGME_PROTOCOL_OpenPGP, NULL, CONFIG_DIR); if(error) return false; If I remove the directory in my init function and use a nullptr (for default), the same key generation succeeds. I don't know why this happens. I have read and write access to this directory and tried various other directories (also including the closing / at the end), but without luck. Moreover I searched for information about the default (preferreed) order of GnuPG for ciphers and hashfunctions. But didn't found something. There doesn't seem to be any gpg.conf file on my PC. Neither on my windows system in %APPDATA%\gnupg or my Debian system (both have GnuPG installed). How can I figure this out? Im using gpg2 2.0.26 and GPGME 1.5.1 in 64 bit Debian VM on Windows 7 64 bit Host System. Many thanks in advance, Sandra From rjh at sixdemonbag.org Sat Jan 30 11:27:48 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 30 Jan 2016 05:27:48 -0500 Subject: Default configuration of GnuPG preferred chiphers and hashfunctions In-Reply-To: References: Message-ID: <56AC9024.60206@sixdemonbag.org> > I somehow can't get GPGME to work with a custom configuration > directory for GnuPG. Every time I set a path any key generation fails > with a GPGME_ERR_GENERAL afterwards. Let's tackle this. > const char* dir = "/home/myuser/crypttest"; So far so good. > // error = gpgme_set_engine_info(GPGME_PROTOCOL_OpenPGP, NULL, > // CONFIG_DIR); > > error = gpgme_ctx_set_engine_info(mContext, GPGME_PROTOCOL_OpenPGP, > NULL, CONFIG_DIR); Shouldn't CONFIG_DIR be dir? I'm guessing you have CONFIG_DIR defined somewhere else in your project and it's sending you off-course. If you've already tried gpgme_set_engine_info(GPGME_PROTOCOL_OpenPGP, nullptr, dir) though, ignore me. :) Also, a C++ tip: never use NULL. NULL is defined to be 0. If you need the numeric value zero, use 0; if you need a pointer to null, use nullptr. Wikibooks has a good article on this: https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/nullptr > Moreover I searched for information about the default (preferred) > order of GnuPG for ciphers and hashfunctions. But didn't found > something. There doesn't seem to be any gpg.conf file on my PC. You don't need a gpg.conf file, but if you want one, check the GnuPG FAQ. There's a sample gpg.conf file in there that sets default cipher preferences. The lines you'll want to change/modify are "personal-*-preferences". From peter at digitalbrains.com Sat Jan 30 13:36:45 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 30 Jan 2016 13:36:45 +0100 Subject: User experience of --hidden-recipient encryption In-Reply-To: <20160129182353-2641-48887-mailpile@advancedsearch-virginmedia-com> References: <20160129182353-2641-48887-mailpile@advancedsearch-virginmedia-com> Message-ID: <56ACAE5D.2050701@digitalbrains.com> On 29/01/16 19:32, Bjarni Runar Einarsson wrote: > If the user only has one public/private key pair, I assume the > experience isn't too bad, GnuPG will just make a guess. But if > the user has multiple keys, do they have to enter the passphrase > for each in succession, as gpg tries to guess how to decrypt? AFAIK, yes. > How does this work in practice? Is --hidden-recipient a decent > user experience for the recipient? I think separate copies for BCC recipients is a much better user experience. Yes, you have to send more copies, but in many environments, that isn't relevant at all. Only when you pay per kilobyte on a mobile connection or when you have large attachments would this actually incur any significant penalty on the sender side, I think. Also, some mail servers actually identify and aggregate identical e-mails or attachments of their users. I suppose if you're in a corporate environment with a lot of internal mail with large encrypted attachments and hidden recipients, you would need more storage on your mail server because each hidden recipient gets a different mail. This is just something that occured to me, it doesn't seem to outweigh the advantages of separate copies. > Also, if I go with a), does that leak the fact that there were > hidden recipients? Does it leak how many? I'd say yes and yes. Every recipient has their own Public Key Encrypted Session Key (PKESK) packet with the (shared) session key encrypted to their key. The only difference between a regular recipient and a hidden one is that the regular ones identify which key the packet is meant for, whereas each hidden recipient has a packet without that identification. So the number of PKESK packets without identification is equal to the number of hidden recipients. It leaks that there were and how many there were, just like you can identify all non-hidden recipients by the remaining PKESK packets. 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 andrey.od.utkin at gmail.com Sun Jan 31 13:20:26 2016 From: andrey.od.utkin at gmail.com (Andrey Utkin) Date: Sun, 31 Jan 2016 14:20:26 +0200 Subject: User experience of --hidden-recipient encryption In-Reply-To: <56ACAE5D.2050701@digitalbrains.com> References: <20160129182353-2641-48887-mailpile@advancedsearch-virginmedia-com> <56ACAE5D.2050701@digitalbrains.com> Message-ID: <56ADFC0A.70401@gmail.com> On 30.01.2016 14:36, Peter Lebbing wrote: > On 29/01/16 19:32, Bjarni Runar Einarsson wrote: >> Also, if I go with a), does that leak the fact that there were >> hidden recipients? Does it leak how many? > > I'd say yes and yes. Every recipient has their own Public Key Encrypted > Session Key (PKESK) packet with the (shared) session key encrypted to > their key. The only difference between a regular recipient and a hidden > one is that the regular ones identify which key the packet is meant for, > whereas each hidden recipient has a packet without that identification. > So the number of PKESK packets without identification is equal to the > number of hidden recipients. It leaks that there were and how many there > were, just like you can identify all non-hidden recipients by the > remaining PKESK packets. Leakage of exact number of hidden recipients can be mitigated by adding random number of pseudo-recipients (e.g. generate some more keys on your localhost and add them to recipients). -------------- 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 Sun Jan 31 14:03:08 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 31 Jan 2016 14:03:08 +0100 Subject: User experience of --hidden-recipient encryption In-Reply-To: <56ADFC0A.70401@gmail.com> References: <20160129182353-2641-48887-mailpile@advancedsearch-virginmedia-com> <56ACAE5D.2050701@digitalbrains.com> <56ADFC0A.70401@gmail.com> Message-ID: <56AE060C.7060302@digitalbrains.com> On 31/01/16 13:20, Andrey Utkin wrote: > Leakage of exact number of hidden recipients can be mitigated by > adding random number of pseudo-recipients There is a lot of literature on masking the length of packets with random padding. It's not as straightforward as it seems. I think this has anologues, and should not generally be considered a good idea. But in general, the kind of statistics that go into this kind of research is beyond me, at least without a serious refresher course. So I don't think I'm qualified to actually say much about it, other than that I've heard that it's not generally considered a good idea. > (e.g. generate some more keys on your localhost and add them to > recipients). Is it possible to differentiate between MPI's[1] that are the result of encryption proper and random noise?[2] I think you can get away with simple random data. And if not, it seems more economical to just add a few packets encrypted to one of the public keys used. Each time you generate a PKESK, it will come out differently, even for the same public key. The PKCS#1 EME-PKCS1-v1_5 encoding makes use of random padding. So you could simply include the same public key multiple times as hidden recipients. I don't see any problem with that, but if there is, you could include PKESK packets with intentionally malformed data such that the decrypting application will reject it as "okay, must have used the wrong key for this packet", even though it was actually the correct key. I don't know if the architecture of GnuPG would allow for such a procedure (intentional malformation), and more importantly, I don't think this is something that should be done anyway. I was just going with the hypothetical situation that we need dummy PKESK packets, and observing that dummy public keys seems a bit heavyweight for that purpose. My 2 rather hyptothetical cents, Peter. [1] Multiple Precision Integers, the base encoding blocks of public key cryptography for at least many common cryptosystems. [2] Some situations are impossible: in RSA, a ciphertext greater than the modulus is obviously impossible, or at least, an invalid encoding. But! Since this is a hidden recipient, we don't know what the modulus is since we don't know what the recipient key is. So we can't identify a too great ciphertext MPI! -- 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 stebe at mailbox.org Sun Jan 31 16:07:56 2016 From: stebe at mailbox.org (stebe at mailbox.org) Date: Sun, 31 Jan 2016 16:07:56 +0100 (CET) Subject: GnuPG and the debian-archive-keyring Message-ID: <1438937703.3486.d0e3fe43-f143-47ca-803d-bf3856d0c20a.open-xchange@office.mailbox.org> Hi, recently, I refreshed some keys of my GnuPG public keyring, did a check and learned that 1) the RSA key 46925553 Debian Archive Automatic Signing Key (7.0/wheezy) has been revoked [output translated into English in square brackets]. gpg2 --edit-key 0x46925553 pub 4096R/46925553 erzeugt[created]: 2012-04-27 verf?llt[expires]: 2020-04-25 Aufruf[call/invocation]: SC Vertrauen[trust]: unbekannt[unknown] G?ltigkeit[validity]:unbekannt[unknown] Der folgende Schl?ssel wurde am 2014-03-17 von RSA Schl?ssel 46925553 Debian Archive Automatic Signing Key (7.0/wheezy) widerrufen [The following key has been revoked by RSA key 46925553 Debian Archive Automatic Signing Key (7.0/wheezy) on 2014-03-17] sub 4096R/ADD6B7E2 erzeugt: 2012-04-27 widerrufen: 2014-03-17 Aufruf: E [ unbek.] (1). Debian Archive Automatic Signing Key (7.0/wheezy) gpg> fpr pub 4096R/46925553 2012-04-27 Debian Archive Automatic Signing Key (7.0/wheezy) Haupt-Fingerabdruck [Key Fingerprint] = A1BD 8E9D 78F7 FE5C 3E65 D8AF 8B48 AD62 4692 5553 2) Moreover, I learned that the RSA key 2B90D010 Debian Archive Automatic Signing Key (8/jessie) may (may?) have been revoked by, well, I am not sure by which key, as gpg's output is as follows: gpg2 --edit-key 0x2B90D010 Dieser Schl?ssel k?nnte durch RSA mit Schl?ssel CA1CF964 [?] widerrufen worden sein [This key may have been revoked by RSA key CA1CF964 [?]] Dieser Schl?ssel k?nnte durch RSA mit Schl?ssel B12525C4 [?] widerrufen worden sein Dieser Schl?ssel k?nnte durch RSA mit Schl?ssel 15B0FD82 [?] widerrufen worden sein pub 4096R/2B90D010 erzeugt: 2014-11-21 verf?llt: 2022-11-19 Aufruf: SC Vertrauen: unbekannt G?ltigkeit: unbekannt [ unbek.] (1). Debian Archive Automatic Signing Key (8/jessie) gpg> fpr pub 4096R/2B90D010 2014-11-21 Debian Archive Automatic Signing Key (8/jessie) Haupt-Fingerabdruck [Key Fingerprint] = 126C 0D24 BD8A 2942 CC7D F8AC 7638 D044 2B90 D010 As to 1) the expiration date seems to be quite a while ago, but what struck me is the fact that there seems to be no way of getting the new key. I guess, there has to be a new one, as wheezy still is among the living. 3) So I checked apt-key (list) and the keyrings listed in there, namely /usr/share/keyrings/debian-archive-removed-keys.gpg Nothing. Hmm, I thought it was supposed to be listed there automatically as a consequence of some archive keyring update performed in the past. 4) I read the apt-key manpage. Unfortunately, the "net-update" option that might have resolved the issue is not available in Debian but only in Ubuntu. I did an "update" but none of the keys has changed. gpg: Schl?ssel 46925553: "Debian Archive Automatic Signing Key (7.0/wheezy) " nicht ge?ndert [unchanged] gpg: Schl?ssel 2B90D010: "Debian Archive Automatic Signing Key (8/jessie) " nicht ge?ndert ...some more keys... 5) I checked if apt indicated the availbility of a new debian-archive-keyring version, but no, 2014.3~deb7u1 not marked as updatable. I have to remove the revoked key from apt-key, fine, but what else can I do for getting the new one? And will the removal affect my oldstable system in terms of security/secure updates? Have I disregarded something important? As to 2) What kind of ambiguous output is "may" and "?" I hold gpg to be a program that would not be vague, and maybe it isn't, and it's just me who does not understand. But what on earth might be the reason for giving an output like that? What does it mean? How can I check further if it actually has been revoked? Thanks in advance for any helpful input. And forgive me if I can't see the wood for the trees! Stebe From peter at digitalbrains.com Sun Jan 31 19:13:38 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 31 Jan 2016 19:13:38 +0100 Subject: GnuPG and the debian-archive-keyring In-Reply-To: <1438937703.3486.d0e3fe43-f143-47ca-803d-bf3856d0c20a.open-xchange@office.mailbox.org> References: <1438937703.3486.d0e3fe43-f143-47ca-803d-bf3856d0c20a.open-xchange@office.mailbox.org> Message-ID: <56AE4ED2.3090301@digitalbrains.com> On 31/01/16 16:07, stebe at mailbox.org wrote: > Hi, > > recently, I refreshed some keys of my GnuPG public keyring, did a check > and learned that > > 1) the RSA key 46925553 Debian Archive Automatic Signing Key (7.0/wheezy) > has been revoked [output translated into English in > square brackets]. I see this more often. This seems like a suboptimal way to communicate on an English list. Presuming you have the environment variable LANG=de_DE.UTF-8 set, you could invoke gpg2 as follows: $ LANG=C.UTF-8 gpg2 --edit-key 0x46925553 And it will communicate with you in the standard C locale, which will have English language. My l10n-foo is not up to snuff, so I might have details wrong. The funny thing is, if you specify nonsense it will fall back to the C locale, AFAIK, so I might actually be specifying nonsense, but I think I'm doing it right. It might be that LANG=C.UTF-8 is a dumb way to say LANG=C . If you want to override any more complex locale settings, you could do: $ LC_ALL=C.UTF-8 gpg2 ... or perhaps $ LC_ALL=C gpg2 ... But to get back to your remark: I think you interpreted it wrong. Primary key 46925553 revoked an encryption subkey ADD6B7E2. "Der folgende Schl?ssel"! And then comes ADD6B7E2. I don't know if there is an option to look at revocation reasons... which seems a rather big lack in my knowledge, how did this come about? Anyway, apart from my frustrations, you can actually look at it: > $ gpg2 --export 0x46925553|gpg2 --list-packets > # off=0 ctb=99 tag=6 hlen=3 plen=525 > :public key packet: > version 4, algo 1, created 1335553717, expires 0 > pkey[0]: [4096 bits] > pkey[1]: [17 bits] > keyid: 8B48AD6246925553 > [...] > # off=11947 ctb=b9 tag=14 hlen=3 plen=525 > :public sub key packet: > version 4, algo 1, created 1335553717, expires 0 > pkey[0]: [4096 bits] > pkey[1]: [17 bits] > keyid: 85215E51ADD6B7E2 > [...] > # off=13027 ctb=89 tag=2 hlen=3 plen=630 > :signature packet: algo 1, keyid 8B48AD6246925553 > version 4, created 1395098327, md5len 0, sigclass 0x28 > digest algo 8, begin of digest 5c 81 > hashed subpkt 2 len 4 (sig created 2014-03-17) > hashed subpkt 29 len 88 (revocation reason 0x03 (This key is used for signing only. The encryption subkey was never intended to be used.)) > subpkt 16 len 8 (issuer key ID 8B48AD6246925553) > data: [4096 bits] So it was a simple mistake: they added an encryption subkey. To keep debian-archive-keyring clean, they don't include it there, but keyservers are like elephants and never forget. > 2) Moreover, I learned that the RSA key 2B90D010 Debian Archive Automatic > Signing Key (8/jessie) may (may?) have been revoked > by, well, I am not sure by which key, as gpg's output is as follows: > > gpg2 --edit-key 0x2B90D010 > > Dieser Schl?ssel k?nnte durch RSA mit Schl?ssel CA1CF964 [?] widerrufen > worden sein > [This key may have been revoked by RSA key CA1CF964 [?]] > Dieser Schl?ssel k?nnte durch RSA mit Schl?ssel B12525C4 [?] widerrufen > worden sein > Dieser Schl?ssel k?nnte durch RSA mit Schl?ssel 15B0FD82 [?] widerrufen > worden sein I suppose you don't have those keys. Neither did I, and that was the message I got. I thought that this would have been due to not having those keys. After all, how could you validate a revocation without the key that made that revocation signature? But even with those keys, and even with them made fully valid by signatures on those keys, it will still say this: > $ gpg2 --recv-keys CA1CF964 B12525C4 15B0FD82 > [...] > $ gpg2 --edit-key 0x2B90D010 > gpg (GnuPG) 2.1.11; Copyright (C) 2016 Free Software Foundation, Inc. > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > > > This key may be revoked by RSA key CA1CF964 Ansgar Burchardt > This key may be revoked by RSA key B12525C4 Joerg Jaspert > This key may be revoked by RSA key 15B0FD82 Mark Hymers I think this is simply the message GnuPG gives for keys with designated revokers. I don't know why it is saying that, somebody else will need to answer that question. Note that it says "may be revoked", which seems a different verb inflection than "k?nnte widerrufen worden sein", which to me indeed sounds like "may have been revoked". Is this a translation error and should it have been "kann widerrufen werden" or something like that? I have to admit my grasp of German is mostly passive: I can read it slowly, I can follow it if people articulate well, but actively producing German is mainly good for laughs. > What kind of ambiguous output is "may" and "?" I hold gpg to be a program > that would not be vague, and maybe it isn't, and it's just me who does not > understand. But what on earth might be the reason for giving an output > like that? What does it mean? How can I check further if it actually has > been revoked? I'd like to know that as well! 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 wk at gnupg.org Sun Jan 31 19:13:51 2016 From: wk at gnupg.org (Werner Koch) Date: Sun, 31 Jan 2016 19:13:51 +0100 Subject: User experience of --hidden-recipient encryption In-Reply-To: <20160129182353-2641-48887-mailpile@advancedsearch-virginmedia-com> (Bjarni Runar Einarsson's message of "Fri, 29 Jan 2016 18:32:09 -0000") References: <20160129182353-2641-48887-mailpile@advancedsearch-virginmedia-com> Message-ID: <87bn81k468.fsf@vigenere.g10code.de> On Fri, 29 Jan 2016 19:32, bre at pagekite.net said: > a) I use --hidden-recipient Never. You leak the information that there is a BCC, so it is only half-blind. > b) I send them their own separate copy of the mail, encrypted only to them That is how all proper MUAs do it. > How does this work in practice? Is --hidden-recipient a decent > user experience for the recipient? No, because you need to do trial decryption only to realize that the sender forgot to encrypt to you ;-). Trial decryption may even mean to swap your cards. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Sun Jan 31 19:24:00 2016 From: wk at gnupg.org (Werner Koch) Date: Sun, 31 Jan 2016 19:24:00 +0100 Subject: GnuPG and the debian-archive-keyring In-Reply-To: <1438937703.3486.d0e3fe43-f143-47ca-803d-bf3856d0c20a.open-xchange@office.mailbox.org> (stebe@mailbox.org's message of "Sun, 31 Jan 2016 16:07:56 +0100 (CET)") References: <1438937703.3486.d0e3fe43-f143-47ca-803d-bf3856d0c20a.open-xchange@office.mailbox.org> Message-ID: <87zivlip4v.fsf@vigenere.g10code.de> On Sun, 31 Jan 2016 16:07, stebe at mailbox.org said: > 1) the RSA key 46925553 Debian Archive Automatic Signing Key (7.0/wheezy) > has been revoked [output translated into English in > square brackets]. > > gpg2 --edit-key 0x46925553 Run it this way to get the original english strings: LANG=C gpg2 --edit-key 0x46925553 this much easier for us to read and helps us to find the corresponding line in the source. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Sun Jan 31 19:20:15 2016 From: wk at gnupg.org (Werner Koch) Date: Sun, 31 Jan 2016 19:20:15 +0100 Subject: Default configuration of GnuPG preferred chiphers and hashfunctions In-Reply-To: (Sandra Schreiner's message of "Sat, 30 Jan 2016 09:13:42 +0000") References: Message-ID: <874mdtk3vk.fsf@vigenere.g10code.de> On Sat, 30 Jan 2016 10:13, sasc0041 at stud.hs-kl.de said: > error = gpgme_ctx_set_engine_info(mContext, GPGME_PROTOCOL_OpenPGP, NULL, > CONFIG_DIR); > if(error) > return false; You should print the error here: err = gpgme_ctx_set_engine_info(mContext, GPGME_PROTOCOL_OpenPGP, NULL, CONFIG_DIR); if (err) { fprintf (stderr, "set_engine_info(%s) failed: %s <%s>\n", CONFIG_DIR, gpg_strerror (err), gpg_strsource (err)); return false; } You should better not use the symbol "error" because that is a glibc function and you _may_ run in conflicts. If you can't find the problem set the GPGME_DEBUG envvar to trace the operation. Shalom-Salam, Werner From andrewg at andrewg.com Sun Jan 31 18:40:32 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sun, 31 Jan 2016 17:40:32 +0000 Subject: GnuPG and the debian-archive-keyring In-Reply-To: <1438937703.3486.d0e3fe43-f143-47ca-803d-bf3856d0c20a.open-xchange@office.mailbox.org> References: <1438937703.3486.d0e3fe43-f143-47ca-803d-bf3856d0c20a.open-xchange@office.mailbox.org> Message-ID: <07E2B236-D325-4C69-BC30-7F5FC165B13D@andrewg.com> On 31 Jan 2016, at 15:07, stebe at mailbox.org wrote: > > gpg2 --edit-key 0x2B90D010 > > Dieser Schl?ssel k?nnte durch RSA mit Schl?ssel CA1CF964 [?] widerrufen > worden sein > [This key may have been revoked by RSA key CA1CF964 [?]] > Dieser Schl?ssel k?nnte durch RSA mit Schl?ssel B12525C4 [?] widerrufen > worden sein > Dieser Schl?ssel k?nnte durch RSA mit Schl?ssel 15B0FD82 [?] widerrufen > worden sein > pub 4096R/2B90D010 erzeugt: 2014-11-21 verf?llt: 2022-11-19 Aufruf: SC Do you have the revoking keys in your keyring? It sounds as if there's a revocation sig attached to the public key but gpg has no way of determining its validity. (Not at the computer right now so can't check myself) A From bre at pagekite.net Sun Jan 31 20:32:36 2016 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Sun, 31 Jan 2016 19:32:36 -0000 Subject: User experience of --hidden-recipient encryption In-Reply-To: <87bn81k468.fsf@vigenere.g10code.de> References: <87bn81k468.fsf@vigenere.g10code.de> Message-ID: <20160131193139-2641-15741-mailpile@advancedsearch-virginmedia-com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks for the replies everyone. I think it's pretty clear what I need to do! All the best, - Bjarni - -- PageKite.net lets your personal computer be part of the web. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWrmFUAAoJEI4ANxYAz5SRUakH/iwSlfqUnTU7FPyF1JJtG3qi T8HoeUhpX+rMmykteUbN/O3FfeXOIEa663Kah7l0wOk1YHUShFfOtsQr9031DFhb lURDGrCWz38KnF8TUU4FgzHtBRA/kDZCVC/CRWyr3ZWF8SexPJ4/3dW/i8LNS+xR xc1z9ejTWR01NYpAKaHfp7IRS2njqWa8qjovobH2qSfA6czsz+LLTAysp6QShu0p gMb7hvQO9xOpmdhKr/uRK39Q1f/OeLnyI1P52p4YN1pAwLUrhvyW+/0e39wODJTT tT1OjQ6R27MvbfVsS4K9dyQrOoStY1JFuIAla4hRNSQpiVC+04cAem6ooAyYO5g= =kAUn -----END PGP SIGNATURE----- From stebe at mailbox.org Sun Jan 31 23:55:06 2016 From: stebe at mailbox.org (stebe at mailbox.org) Date: Sun, 31 Jan 2016 23:55:06 +0100 (CET) Subject: GnuPG and the debian-archive-keyring In-Reply-To: <56AE4ED2.3090301@digitalbrains.com> References: <1438937703.3486.d0e3fe43-f143-47ca-803d-bf3856d0c20a.open-xchange@office.mailbox.org> <56AE4ED2.3090301@digitalbrains.com> Message-ID: <1383651561.598.4b7bd281-beed-4891-8bbe-24a25352520c.open-xchange@office.mailbox.org> Hi, > Peter Lebbing hat am 31. Januar 2016 um 19:13 > geschrieben: > On 31/01/16 16:07, stebe at mailbox.org wrote: >> Hi, >> >> recently, I refreshed some keys of my GnuPG public keyring, did a check >> and learned that >> >> 1) the RSA key 46925553 Debian Archive Automatic Signing Key >> (7.0/wheezy) >> has been revoked [output translated into English >> in >> square brackets]. > I see this more often. This seems like a suboptimal way to communicate > on an > English list. Well, maybe you're right. I didn't think of changing it. [...] > If you want to override any more complex locale settings, you could do: > > $ LC_ALL=C.UTF-8 gpg2 ... > > or perhaps > > $ LC_ALL=C gpg2 ... > I have a system pretty soundly localized, but those two commands worked, thanks. Simply putting LANG=C didn't work. > But to get back to your remark: > > I think you interpreted it wrong. Primary key 46925553 revoked an > encryption > subkey ADD6B7E2. "Der folgende Schl?ssel"! And then comes ADD6B7E2. > Indeed. I got it wrong. See the message in reply to Werner. > I don't know if there is an option to look at revocation reasons... > which seems > a rather big lack in my knowledge, how did this come about? Anyway, > apart from > my frustrations, you can actually look at it: > $ gpg2 --export 0x46925553|gpg2 --list-packets > # off=0 ctb=99 tag=6 hlen=3 plen=525 [...] > So it was a simple mistake: they added an encryption subkey. To keep > debian-archive-keyring clean, they don't include it there, but > keyservers are > like elephants and never forget. OK, thanks, you have opened my eyes. :-) I didn't know this particular command pipe. My apologies to all Debian people. >> 2) Moreover, I learned that the RSA key 2B90D010 Debian Archive >> Automatic >> Signing Key (8/jessie) may (may?) have been >> revoked >> by, well, I am not sure by which key, as gpg's output is as follows: >> >> gpg2 --edit-key 0x2B90D010 >> >> Dieser Schl?ssel k?nnte durch RSA mit Schl?ssel CA1CF964 [?] >> widerrufen >> worden sein >> [This key may have been revoked by RSA key CA1CF964 [?]] >> Dieser Schl?ssel k?nnte durch RSA mit Schl?ssel B12525C4 [?] >> widerrufen >> worden sein >> Dieser Schl?ssel k?nnte durch RSA mit Schl?ssel 15B0FD82 [?] >> widerrufen >> worden sein > I suppose you don't have those keys. Neither did I, and that was the > message I > got. I thought that this would have been due to not having those keys. > After > all, how could you validate a revocation without the key that made that > revocation signature? But even with those keys, and even with them made > fully > valid by signatures on those keys, it will still say this: > [...] In my case, the English output is as follows. LC_ALL=C gpg2 --edit-key 0x2B90D010 [...] This key may be revoked by RSA key CA1CF964 [?] This key may be revoked by RSA key B12525C4 [?] This key may be revoked by RSA key 15B0FD82 [?] pub 4096R/2B90D010 created: 2014-11-21 expires: 2022-11-19 usage: SC trust: unknown validity: unknown [ unknown] (1). Debian Archive Automatic Signing Key (8/jessie) Now I understand. The German translation is misleading and should be improved. I'll file a bug report. [...] > > Note that it says "may be revoked", which seems a different verb > inflection than > "k?nnte widerrufen worden sein", which to me indeed sounds like "may > have been > revoked". Is this a translation error and should it have been "kann > widerrufen > werden" or something like that? I have to admit my grasp of German is > mostly > passive: I can read it slowly, I can follow it if people articulate > well, but > actively producing German is mainly good for laughs. You're right with your supposition. The German wording should positively be changed. It makes people think that the action of revoking may have already been carried out, whereas the English informs of the keys' ability/capacity to revoke the key. Thanks a lot. Stebe From stebe at mailbox.org Sun Jan 31 23:58:53 2016 From: stebe at mailbox.org (stebe at mailbox.org) Date: Sun, 31 Jan 2016 23:58:53 +0100 (CET) Subject: GnuPG and the debian-archive-keyring In-Reply-To: <87zivlip4v.fsf@vigenere.g10code.de> References: <1438937703.3486.d0e3fe43-f143-47ca-803d-bf3856d0c20a.open-xchange@office.mailbox.org> <87zivlip4v.fsf@vigenere.g10code.de> Message-ID: <43529358.618.4b7bd281-beed-4891-8bbe-24a25352520c.open-xchange@office.mailbox.org> Hi, > Werner Koch hat am 31. Januar 2016 um 19:24 geschrieben: > > > On Sun, 31 Jan 2016 16:07, stebe at mailbox.org said: > Run it this way to get the original english strings: > > LANG=C gpg2 --edit-key 0x46925553 > > this much easier for us to read and helps us to find the corresponding > line in the source. Thanks, I had to invoke $ LC_ALL=C gpg2 --edit-key 0x46925553 gpg (GnuPG) 2.0.19; Copyright (C) 2012 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. pub 4096R/46925553 created: 2012-04-27 expires: 2020-04-25 usage: SC trust: unknown validity: unknown The following key was revoked on 2014-03-17 by RSA key 46925553 Debian Archive Automatic Signing Key (7.0/wheezy) sub 4096R/ADD6B7E2 created: 2012-04-27 revoked: 2014-03-17 usage: E [ unknown] (1). Debian Archive Automatic Signing Key (7.0/wheezy) to switch gpg's output to English. Everything all right here, though. I thought it might refer to the key 0x46925553 being revoked by 0x46925553 (Debian Archive Automatic Signing Key, mentioned in the last line, which in fact is the uid) but I didn't pay attention to the fact that it actually refers to the enryption subkey. Gnupg-users and developers, Debian people, I beg your pardon. Stebe > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. >