From wk at gnupg.org Wed Jul 1 15:19:19 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 01 Jul 2015 15:19:19 +0200 Subject: [Announce] GnuPG 2.1.6 released Message-ID: <87h9poggmg.fsf@vigenere.g10code.de> Hello! The GnuPG Project is pleased to announce the availability of a new release of GnuPG modern: Version 2.1.6. 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.6 =================================== * agent: New option --verify for the PASSWD command. * gpgsm: Add command option "offline" as an alternative to --disable-dirmngr. * gpg: Do not prompt multiple times for a password in pinentry loopback mode. * Allow the use of debug category names with --debug. * Using gpg-agent and gpg/gpgsm with different locales will now show the correct translations in Pinentry. * gpg: Improve speed of --list-sigs and --check-sigs. * gpg: Make --list-options show-sig-subpackets work again. * gpg: Fix an export problem for old keyrings with PGP-2 keys. * scd: Support PIN-pads on more readers. * dirmngr: Properly cleanup zombie LDAP helper processes and avoid hangs on dirmngr shutdown. * Various other bug fixes. 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 https://gnupg.org/download/ or read on: GnuPG 2.1.6 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. On ftp.gnupg.org you find these files: ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.6.tar.bz2 (4802k) ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.6.tar.bz2.sig This is the GnuPG source code compressed using BZIP2 and its OpenPGP signature. ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.6_20150701.exe (2577k) ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.6_20150701.exe.sig This is an installer for Windows without graphical frontends except for a basic Pinentry tool. Please de-install an installed Gpg4win version before trying this installer. Note that on Window TLS access to keyservers is not yet available. The sources used to build the installer can be found in the same directory with an ".tar.xz" suffix. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.1.6.tar.bz2 you would use this command: gpg --verify gnupg-2.1.6.tar.bz2.sig gnupg-2.1.6.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.6.tar.bz2, you would run the command like this: sha1sum gnupg-2.1.6.tar.bz2 and check that the output matches the next line: 9e8157b3386da04760657ce3117fc4dc570c57c5 gnupg-2.1.6.tar.bz2 a8cd2e7ab48abb94c126051df902e3380faf117e gnupg-w32-2.1.6_20150701.exe 1d3e70504f993d1297f04564dfda222f8b68a96f gnupg-w32-2.1.6_20150701.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 files 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 using 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 (2075 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 https://gnupg.org/blob/. 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 may need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. 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, and answering questions on the mailing lists. Maintenance and development of GnuPG is possible due to many individual and corporate donations; for a list of non-anonymous donors see . For the GnuPG hackers, Werner p.s. This is a 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 wk at gnupg.org Wed Jul 1 17:22:06 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 01 Jul 2015 17:22:06 +0200 Subject: [Announce] Pinentry 0.9.5 released In-Reply-To: <87h9poggmg.fsf@vigenere.g10code.de> (Werner Koch's message of "Wed, 01 Jul 2015 15:19:19 +0200") References: <87h9poggmg.fsf@vigenere.g10code.de> Message-ID: <876163hpi9.fsf@vigenere.g10code.de> Hi, Pinentry 0.9.5 is now available at ftp://ftp.gnupg.org/gcrypt/pinentry/pinentry-0.9.5.tar.bz2 ftp://ftp.gnupg.org/gcrypt/pinentry/pinentry-0.9.5.tar.bz2.sig Noteworthy changes in version 0.9.5 (2015-07-01) ------------------------------------------------ * Replaced the internal Assuan and gpg-error code by the standard libassuan and libgpg-error libraries. * Add a new Emacs pinentry and use as fallback for GUI programs. * gnome3: The use-password-manager checkbox does now work. * Gtk: Improved fallback to curses feature. * curses: Recognize DEL as backspace. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From freebooter2015 at gmail.com Thu Jul 2 01:27:23 2015 From: freebooter2015 at gmail.com (Rex Kneisley) Date: Wed, 01 Jul 2015 23:27:23 +0000 Subject: [Announce] Pinentry 0.9.5 released In-Reply-To: <876163hpi9.fsf@vigenere.g10code.de> References: <87h9poggmg.fsf@vigenere.g10code.de> <876163hpi9.fsf@vigenere.g10code.de> Message-ID: <5594775B.4080707@gmail.com> Hello Group, I have been experimenting with installing GnuPG from scratch and also by using the Debian packages. I am currently running Debian "Stretch" with experimantal added to get me GnuPG 2.1.4: deb http://ftp.us.debian.org/debian/ stretch main contrib non-free deb-src http://ftp.us.debian.org/debian/ stretch main contrib non-free # experimental sources in order to get latest vertion of GnuPG deb http://ftp.debian.org/debian experimental main Now that we have a new version of Pinentry, I would like to try installing from scratch since the Debian package is currently only at version 0.9.4-2. I noticed when I tried to install the Debian package, (sudo apt-get install pinentry) it tells me there are several variations: Package pinentry is a virtual package provided by: pinentry-tty 0.9.4-2 pinentry-qt4 0.9.4-2 pinentry-gtk2 0.9.4-2 pinentry-gnome3 0.9.4-2 pinentry-curses 0.9.4-2 mew-beta-bin 7.0.50~6.7~rc1+0.20150513-1 mew-bin 1:6.6-3 You should explicitly select one to install. So I used "sudo apt-get install pinentry*" in order to get them all. Was this correct? Does the available tar-ball have all of these too? (pinentry-0.9.5.tar.bz2) Now I want to install pinentry-0.9.5. In the past I downloaded all of the tar-balls (GnuPG, Libgpg-error, Libgcrypt, etc) to a folder in my home directory which I named "Software" I then unpacked them, cd'ed in to each directory and then ran "./configure, make, make install) I'm older and wiser now. Should I unpack the Pinentry-0.9.5.tar.bz2 in to the /usr/local folder and then perform the ./configure,make,make install steps? How would I put the libraries in /usr/local/lib and the headers in /usr/local/include? Do they go there automatically when I run the installation? (naive assumption) Rex (Sorry if this question is more Debian related than GnuPG related, but it is the application I'm trying to install) Werner Koch: > Hi, > > Pinentry 0.9.5 is now available at > > ftp://ftp.gnupg.org/gcrypt/pinentry/pinentry-0.9.5.tar.bz2 > ftp://ftp.gnupg.org/gcrypt/pinentry/pinentry-0.9.5.tar.bz2.sig > > > Noteworthy changes in version 0.9.5 (2015-07-01) > ------------------------------------------------ > > * Replaced the internal Assuan and gpg-error code by the standard > libassuan and libgpg-error libraries. > > * Add a new Emacs pinentry and use as fallback for GUI programs. > > * gnome3: The use-password-manager checkbox does now work. > > * Gtk: Improved fallback to curses feature. > > * curses: Recognize DEL as backspace. > > > > Salam-Shalom, > > Werner > > From manan.navin.mehta at accenture.com Wed Jul 1 08:01:08 2015 From: manan.navin.mehta at accenture.com (manan.navin.mehta at accenture.com) Date: Wed, 1 Jul 2015 06:01:08 +0000 Subject: Facing issue while installing GnuPG 2.0.27 on AIX 7.1 References: <0b421b1066e8482491ea4a06308d61b2@CO2PR42MB076.048d.mgd.msft.net> <87eglqftc3.fsf@vigenere.g10code.de> Message-ID: <6eb3a6f1b6914a0eae5190a9c2d89b0b@CO2PR42MB076.048d.mgd.msft.net> Hi Werner/GnuPG Team, Greetings..!! Need your expert advice/suggestions..!! After upgrading the Compiler and having all the required Lib files, it seems that GnuPG has been installed, PFB excerpt from the log which we got after triggering below command: Also, PFA "config.log" which automatically gets generated and "GnuPG_log" which has logs copied from screen after running below command. Request you to look into it and check whether GnuPG has been installed correctly or not and kindly also let us know if any post steps are required.. Command used: ./configure; make; make install GnuPG v2.0.27 has been configured as follows: Revision: 8d47e6e (36167) Platform: AIX (powerpc-ibm-aix7.1.2.0) OpenPGP: yes S/MIME: yes Agent: yes Smartcard: yes (without internal CCID driver) Gpgtar: no Protect tool: (default) Default agent: (default) Default pinentry: (default) Default scdaemon: (default) Default dirmngr: (default) Warning: Mismatches between the target platform and the to be used libraries have been detected for: libgpg-error libgcrypt Please check above for more warning messages. make all-recursive Making all in m4 Target "all" is up to date. Thanks a lot in advance :) [cid:image001.png at 01D0B3ED.F0BCCAF0] From: Navin Mehta, Manan Sent: Friday, June 05, 2015 3:16 PM To: 'Werner Koch' Cc: gnupg-users at gnupg.org; gnupg-devel at gnupg.org; DiEnno, Michael F.; Dawane, Shailendra S.; Sharma, Pramod; Zingade, Swati; Karmakar, Sanjiv; Kothari, Jayesh Subject: RE: Facing issue while installing GnuPG 2.0.27 on AIX 7.1 Hi Werner, Thanks for your reply. Sure, we will check with our Unix team for the availability of the C compiler and get it installed. Request you to address one more query: ? As you have mentioned in the trail mail that "You need to have a compiler and all related tools (the toolchain) to build software" , can you please give more details on "toolchain" ? What all other tools will be required (other than installing C compiler) for successful installation of GnuPG software. Thanks again :) Thanks, Manan N Mehta Accenture | SAP BASIS Admin Email: manan.navin.mehta at accenture.com -----Original Message----- From: Werner Koch [mailto:wk at gnupg.org] Sent: Friday, June 05, 2015 2:03 PM To: Navin Mehta, Manan Cc: gnupg-users at gnupg.org; gnupg-devel at gnupg.org; DiEnno, Michael F.; Dawane, Shailendra S.; Sharma, Pramod; Zingade, Swati; Karmakar, Sanjiv Subject: Re: Facing issue while installing GnuPG 2.0.27 on AIX 7.1 On Thu, 4 Jun 2015 09:04, manan.navin.mehta at accenture.com said: > Below are the OS level details: > > [cid:image006.png at 01D09EBE.3BD6EBA0] Sorry, I can't view the images as they are only available in the HTML rendered version. Please always transcript con5tents from screenshots so that it is possible to search for the content. Anyway, the attached config.log has all the details of your system. > But still we are facing Error as C compiler cannot create executables The configure run and the config.log show > configure:3875: checking whether the C compiler works > configure:3897: c99 -g conftest.c -lposix >&5 > ./configure[3899]: c99: not found Thus you don't have a compiler installed. You need to have a compiler and all related tools (the toolchain) to build software. > If you have 24X7 support help line number then kindly share the > details. This is a public mailing list. If you need commercial support please see http://gnupg.org/service.html . Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ________________________________ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. ______________________________________________________________________________________ www.accenture.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 2970 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: application/octet-stream Size: 262047 bytes Desc: config.log URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: GnuPG_log.txt URL: From manan.navin.mehta at accenture.com Wed Jul 1 09:17:15 2015 From: manan.navin.mehta at accenture.com (manan.navin.mehta at accenture.com) Date: Wed, 1 Jul 2015 07:17:15 +0000 Subject: Facing issue while installing GnuPG 2.0.27 on AIX 7.1 References: <0b421b1066e8482491ea4a06308d61b2@CO2PR42MB076.048d.mgd.msft.net> <87eglqftc3.fsf@vigenere.g10code.de> Message-ID: Additional details on the trail mail....kindly look into the same. It errors out even when creating a key : Note - anything that calls gpg-agent gets dumped ( you may want to mention this in your email to support) sdlux09:#> ./GnuPG/gnupg-2.0.27/g10/gpg2 --gen-key gpg (GnuPG) 2.0.27; 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. Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) Your selection? 1 RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) 1024 Requested keysize is 1024 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) 1 Key expires at Thu Jul 2 06:43:39 UCT 2015 Is this correct? (y/N) y GnuPG needs to construct a user ID to identify your key. Real name: Jayesh Email address: jayesh.kothari at accenture.com Comment: Test You selected this USER-ID: "Jayesh (Test) >" Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O You need a Passphrase to protect your secret key. ( didn't let met enter anything) gpg: signal 11 caught ... exiting Segmentation fault [cid:image001.png at 01D0B3FC.0A9A9DE0] From: Navin Mehta, Manan Sent: Wednesday, July 01, 2015 11:31 AM To: 'Werner Koch'; 'gnupg-users at gnupg.org'; 'gnupg-devel at gnupg.org' Cc: DiEnno, Michael F.; Dawane, Shailendra S.; Sharma, Pramod; Zingade, Swati; Karmakar, Sanjiv; Kothari, Jayesh Subject: RE: Facing issue while installing GnuPG 2.0.27 on AIX 7.1 Hi Werner/GnuPG Team, Greetings..!! Need your expert advice/suggestions..!! After upgrading the Compiler and having all the required Lib files, it seems that GnuPG has been installed, PFB excerpt from the log which we got after triggering below command: Also, PFA "config.log" which automatically gets generated and "GnuPG_log" which has logs copied from screen after running below command. Request you to look into it and check whether GnuPG has been installed correctly or not and kindly also let us know if any post steps are required.. Command used: ./configure; make; make install GnuPG v2.0.27 has been configured as follows: Revision: 8d47e6e (36167) Platform: AIX (powerpc-ibm-aix7.1.2.0) OpenPGP: yes S/MIME: yes Agent: yes Smartcard: yes (without internal CCID driver) Gpgtar: no Protect tool: (default) Default agent: (default) Default pinentry: (default) Default scdaemon: (default) Default dirmngr: (default) Warning: Mismatches between the target platform and the to be used libraries have been detected for: libgpg-error libgcrypt Please check above for more warning messages. make all-recursive Making all in m4 Target "all" is up to date. Thanks a lot in advance :) [cid:image001.png at 01D0B3FC.0A9A9DE0] From: Navin Mehta, Manan Sent: Friday, June 05, 2015 3:16 PM To: 'Werner Koch' Cc: gnupg-users at gnupg.org; gnupg-devel at gnupg.org; DiEnno, Michael F.; Dawane, Shailendra S.; Sharma, Pramod; Zingade, Swati; Karmakar, Sanjiv; Kothari, Jayesh Subject: RE: Facing issue while installing GnuPG 2.0.27 on AIX 7.1 Hi Werner, Thanks for your reply. Sure, we will check with our Unix team for the availability of the C compiler and get it installed. Request you to address one more query: ? As you have mentioned in the trail mail that "You need to have a compiler and all related tools (the toolchain) to build software" , can you please give more details on "toolchain" ? What all other tools will be required (other than installing C compiler) for successful installation of GnuPG software. Thanks again :) Thanks, Manan N Mehta Accenture | SAP BASIS Admin Email: manan.navin.mehta at accenture.com -----Original Message----- From: Werner Koch [mailto:wk at gnupg.org] Sent: Friday, June 05, 2015 2:03 PM To: Navin Mehta, Manan Cc: gnupg-users at gnupg.org; gnupg-devel at gnupg.org; DiEnno, Michael F.; Dawane, Shailendra S.; Sharma, Pramod; Zingade, Swati; Karmakar, Sanjiv Subject: Re: Facing issue while installing GnuPG 2.0.27 on AIX 7.1 On Thu, 4 Jun 2015 09:04, manan.navin.mehta at accenture.com said: > Below are the OS level details: > > [cid:image006.png at 01D09EBE.3BD6EBA0] Sorry, I can't view the images as they are only available in the HTML rendered version. Please always transcript con5tents from screenshots so that it is possible to search for the content. Anyway, the attached config.log has all the details of your system. > But still we are facing Error as C compiler cannot create executables The configure run and the config.log show > configure:3875: checking whether the C compiler works > configure:3897: c99 -g conftest.c -lposix >&5 > ./configure[3899]: c99: not found Thus you don't have a compiler installed. You need to have a compiler and all related tools (the toolchain) to build software. > If you have 24X7 support help line number then kindly share the > details. This is a public mailing list. If you need commercial support please see http://gnupg.org/service.html . Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ________________________________ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. ______________________________________________________________________________________ www.accenture.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 2970 bytes Desc: image001.png URL: From folkert at vanheusden.com Wed Jul 1 21:22:50 2015 From: folkert at vanheusden.com (folkert) Date: Wed, 1 Jul 2015 21:22:50 +0200 Subject: [Announce] GnuPG 2.1.6 released In-Reply-To: <87h9poggmg.fsf@vigenere.g10code.de> References: <87h9poggmg.fsf@vigenere.g10code.de> Message-ID: <20150701192250.GZ9362@belle.intranet.vanheusden.com> Hi, At least with gpg2 2.1.4-1 and gpgme 1.5.5-2 the passphrase callback does not work. When enabled I get the "secret key unusable" error, and without the callback (enter passphrase via agent) it works fine. If I remember correctly you stated that you need gpg2 v2.1 or better for that to work: https://lists.gnupg.org/pipermail/gnupg-devel/2015-May/029872.html On Wed, Jul 01, 2015 at 03:19:19PM +0200, Werner Koch wrote: > Hello! > > The GnuPG Project is pleased to announce the availability of a new > release of GnuPG modern: Version 2.1.6. > > 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.6 > =================================== > > * agent: New option --verify for the PASSWD command. > > * gpgsm: Add command option "offline" as an alternative to > --disable-dirmngr. > > * gpg: Do not prompt multiple times for a password in pinentry > loopback mode. > > * Allow the use of debug category names with --debug. > > * Using gpg-agent and gpg/gpgsm with different locales will now show > the correct translations in Pinentry. > > * gpg: Improve speed of --list-sigs and --check-sigs. > > * gpg: Make --list-options show-sig-subpackets work again. > > * gpg: Fix an export problem for old keyrings with PGP-2 keys. > > * scd: Support PIN-pads on more readers. > > * dirmngr: Properly cleanup zombie LDAP helper processes and avoid > hangs on dirmngr shutdown. > > * Various other bug fixes. > > > 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 https://gnupg.org/download/ or > read on: > > GnuPG 2.1.6 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. > > On ftp.gnupg.org you find these files: > > ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.6.tar.bz2 (4802k) > ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.6.tar.bz2.sig > > This is the GnuPG source code compressed using BZIP2 and its OpenPGP > signature. > > ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.6_20150701.exe (2577k) > ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.6_20150701.exe.sig > > This is an installer for Windows without graphical frontends except for > a basic Pinentry tool. Please de-install an installed Gpg4win version > before trying this installer. Note that on Window TLS access to > keyservers is not yet available. The sources used to build the > installer can be found in the same directory with an ".tar.xz" suffix. > > > Checking the Integrity > ====================== > > In order to check that the version of GnuPG which you are going to > install is an original and unmodified one, you can do it in one of > the following ways: > > * If you already have a version of GnuPG installed, you can simply > verify the supplied signature. For example to verify the signature > of the file gnupg-2.1.6.tar.bz2 you would use this command: > > gpg --verify gnupg-2.1.6.tar.bz2.sig gnupg-2.1.6.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.6.tar.bz2, you would run the command like this: > > sha1sum gnupg-2.1.6.tar.bz2 > > and check that the output matches the next line: > > 9e8157b3386da04760657ce3117fc4dc570c57c5 gnupg-2.1.6.tar.bz2 > a8cd2e7ab48abb94c126051df902e3380faf117e gnupg-w32-2.1.6_20150701.exe > 1d3e70504f993d1297f04564dfda222f8b68a96f gnupg-w32-2.1.6_20150701.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 files 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 using 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 (2075 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 https://gnupg.org/blob/. > > > 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 may need a certain feature for your > project, please do not hesitate to bring it to the gnupg-devel mailing > list for discussion. > > > 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, and answering questions on the mailing > lists. Maintenance and development of GnuPG is possible due to many > individual and corporate donations; for a list of non-anonymous donors > see . > > > For the GnuPG hackers, > > Werner > > > p.s. > This is a 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. > _______________________________________________ > Gnupg-announce mailing list > Gnupg-announce at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-announce > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel Folkert van Heusden -- To MultiTail einai ena polymorfiko ergaleio gia ta logfiles kai tin eksodo twn entolwn. Prosferei: filtrarisma, xrwmatismo, sygxwneysi, diaforetikes provoles. http://www.vanheusden.com/multitail/ ---------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com From tankred at whiteout.io Thu Jul 2 15:48:16 2015 From: tankred at whiteout.io (Tankred Hase) Date: Thu, 2 Jul 2015 15:48:16 +0200 Subject: Secure Private Key Synchronization (RFC) Message-ID: Hi, I'm Tankred from Whiteout (https://whiteout.io). Me, Werner and other PGP projects discussed a secure way to synchronize a user's private key between devices during the OpenPGP summit in April (https://www.gnupg.org/blog/20150426-openpgp-summit.html). The goal was to formalize and hopefully standardize a very simple protocol that allows interoperability between mail user agents. We've already gotten feedback from other vendors using OpenPGP.js such as Mailvelope and 1&1, and we would also like to hear what the GPG community has to say about it. Here is our current proposal: https://github.com/whiteout-io/mail-html5/wiki/Secure-OpenPGP-Key-Pair-Synchronization-via-IMAP Thanks for any feedback! Kind regards, Tankred -- Whiteout Networks GmbH c/o Werk1 Grafinger Str. 6 D-81671 M?nchen Gesch?ftsf?hrer: Oliver Gajek RG M?nchen HRB 204479 From dkg at fifthhorseman.net Thu Jul 2 18:40:13 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 02 Jul 2015 12:40:13 -0400 Subject: [Announce] Pinentry 0.9.5 released In-Reply-To: <5594775B.4080707@gmail.com> References: <87h9poggmg.fsf@vigenere.g10code.de> <876163hpi9.fsf@vigenere.g10code.de> <5594775B.4080707@gmail.com> Message-ID: <87k2uio6mq.fsf@alice.fifthhorseman.net> On Wed 2015-07-01 19:27:23 -0400, Rex Kneisley wrote: > I have been experimenting with installing GnuPG from scratch and also by > using the Debian packages. is the purpose of these experiments to build skills with software compilation or other system management? > Now I want to install pinentry-0.9.5. one approach is to wait a couple days for one of us to get around to packaging it for debian :) > In the past I downloaded all of the tar-balls (GnuPG, Libgpg-error, > Libgcrypt, etc) to a folder in my home directory which I named > "Software" I then unpacked them, cd'ed in to each directory and then ran > "./configure, make, make install) > > I'm older and wiser now. Should I unpack the Pinentry-0.9.5.tar.bz2 in > to the /usr/local folder and then perform the ./configure,make,make > install steps? there should be no reason to do the build in /usr/local explictly. > How would I put the libraries in /usr/local/lib and the headers in > /usr/local/include? Do they go there automatically when I run the > installation? (naive assumption) by default, pinentry doesn't install any shared libraries or development headers at all. --dkg From diafygi at gmail.com Thu Jul 2 18:59:30 2015 From: diafygi at gmail.com (Daniel Roesler) Date: Thu, 2 Jul 2015 09:59:30 -0700 Subject: Secure Private Key Synchronization (RFC) In-Reply-To: References: Message-ID: Will the proposal require support private subkey stubs generated from gpg --export-secret-subkeys? Daniel On Thu, Jul 2, 2015 at 6:48 AM, Tankred Hase wrote: > Hi, > > I'm Tankred from Whiteout (https://whiteout.io). Me, Werner and other > PGP projects discussed a secure way to synchronize a user's private > key between devices during the OpenPGP summit in April > (https://www.gnupg.org/blog/20150426-openpgp-summit.html). The goal > was to formalize and hopefully standardize a very simple protocol that > allows interoperability between mail user agents. > > We've already gotten feedback from other vendors using OpenPGP.js such > as Mailvelope and 1&1, and we would also like to hear what the GPG > community has to say about it. Here is our current proposal: > > https://github.com/whiteout-io/mail-html5/wiki/Secure-OpenPGP-Key-Pair-Synchronization-via-IMAP > > Thanks for any feedback! > > Kind regards, > Tankred > > -- > Whiteout Networks GmbH c/o Werk1 > Grafinger Str. 6 > D-81671 M?nchen > Gesch?ftsf?hrer: Oliver Gajek > RG M?nchen HRB 204479 > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From aarcane at aarcane.org Thu Jul 2 22:06:03 2015 From: aarcane at aarcane.org (Schlacta, Christ) Date: Thu, 2 Jul 2015 13:06:03 -0700 Subject: gpa and gpgex in gpg 2.1.x releases for windows. Message-ID: As a gpg user, I've been using the gpg 2.1.x releases for a while. as of 2.1.1, gpg for windows included gpa and gpgex. I used them. newer releases didn't remove these features, but didn't upgrade or include them either. Now it's difficult if not impossible to install gpa and gpgex with gnupg 2.1.x series. Can we get these nearly essential features added back into the 2.1.x releases going forward please? If not, can we have them made into an add-on package so that downloading them is easy? Even if they're not fully or properly supported, the existing functionality like clipboard, and basic key use are quite important for day to day use of gpg on windows. Not everybody uses a dedicated e-mail client, or cares to install one. From bernhard at intevation.de Fri Jul 3 11:01:59 2015 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 3 Jul 2015 11:01:59 +0200 Subject: Question about FAQ maintenance Message-ID: <201507031102.00756.bernhard@intevation.de> Hi Robert, again thanks for maintaining the GnuPG FAQ, I believe it is really important to have good quality source for frequently needed answers! Some suggestions: https://gnupg.org/faq/gnupg-faq.html says | When was this FAQ last checked for accuracy? | October 2012. Is this still true? My suggestion would to add some date indication so that readers can assume which version of the FAQ they are looking at. (Background: I've seen some posts on the lists for new FAQ entries from 2014 and also I found a potential source code at https://github.com/rjhansen/gpgfaq/blob/master/gpgfaq.xml with the last commit in 2013 .. this confused me. ;) ) My suggestion is also to state how someone can best help with the FAQ (or potentially where the master source lives. I know that we probably should not adversise the proprietary services of github, I would welcome to have the source elsewhere. But it is more important to see the latest revision before reporting something.) Best, Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From tankred at whiteout.io Fri Jul 3 12:44:38 2015 From: tankred at whiteout.io (Tankred Hase) Date: Fri, 3 Jul 2015 12:44:38 +0200 Subject: Secure Private Key Synchronization (RFC) In-Reply-To: References: Message-ID: 2015-07-02 18:59 GMT+02:00 Daniel Roesler : > Will the proposal require support private subkey stubs generated from > gpg --export-secret-subkeys? That's a good question and the spec is indeed not specific enough here. If I'm not mistaken Mailvelope only includes the primary key packets in their current implementation. But it makes sense to include subkey packets as well. Something to be clarified in the spec. Tankred > On Thu, Jul 2, 2015 at 6:48 AM, Tankred Hase wrote: >> Hi, >> >> I'm Tankred from Whiteout (https://whiteout.io). Me, Werner and other >> PGP projects discussed a secure way to synchronize a user's private >> key between devices during the OpenPGP summit in April >> (https://www.gnupg.org/blog/20150426-openpgp-summit.html). The goal >> was to formalize and hopefully standardize a very simple protocol that >> allows interoperability between mail user agents. >> >> We've already gotten feedback from other vendors using OpenPGP.js such >> as Mailvelope and 1&1, and we would also like to hear what the GPG >> community has to say about it. Here is our current proposal: >> >> https://github.com/whiteout-io/mail-html5/wiki/Secure-OpenPGP-Key-Pair-Synchronization-via-IMAP >> >> Thanks for any feedback! >> >> Kind regards, >> Tankred >> >> -- >> Whiteout Networks GmbH c/o Werk1 >> Grafinger Str. 6 >> D-81671 M?nchen >> Gesch?ftsf?hrer: Oliver Gajek >> RG M?nchen HRB 204479 >> >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users -- Whiteout Networks GmbH c/o Werk1 Grafinger Str. 6 D-81671 M?nchen Gesch?ftsf?hrer: Oliver Gajek RG M?nchen HRB 204479 From wk at gnupg.org Fri Jul 3 17:52:27 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 03 Jul 2015 17:52:27 +0200 Subject: Question about FAQ maintenance In-Reply-To: <201507031102.00756.bernhard@intevation.de> (Bernhard Reiter's message of "Fri, 3 Jul 2015 11:01:59 +0200") References: <201507031102.00756.bernhard@intevation.de> Message-ID: <873815p7b8.fsf@vigenere.g10code.de> On Fri, 3 Jul 2015 11:01, bernhard at intevation.de said: > Is this still true? My suggestion would to add some date indication > so that readers can assume which version of the FAQ they are looking at. There is just one offical version and that is at https://gnupg.org - Documentation - FAQs, or: https://gnupg.org/documentation/faqs.html The page has a prominent link to the source code. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From diafygi at gmail.com Fri Jul 3 20:05:43 2015 From: diafygi at gmail.com (Daniel Roesler) Date: Fri, 3 Jul 2015 11:05:43 -0700 Subject: Secure Private Key Synchronization (RFC) In-Reply-To: <03544057-7F7F-4802-86F5-B19C3E2F10C4@pine.nl> References: <03544057-7F7F-4802-86F5-B19C3E2F10C4@pine.nl> Message-ID: On Fri, Jul 3, 2015 at 7:08 AM, Arjan Wekking wrote: > Now, if you were only to generete these message-id?s for private key pairs, I assume it would probably never be an issue. But if you were to add public keys as well, then using fingerprints instead of (long) key ID?s would perhaps be better. > SKS keyservers accept lookups for both short and long key ids, fingerprints, and word searches on user ids[1]. Perhaps the Message-ID should be the fingerprint + user ids (i.e. "0xf75be... Daniel Roesler "), so that a client can easily index/search their mailbox for the keys they want to use (I might have multiple private keys for work and personal). It might be a bit of an issue with UTF-8 user ids, though. Can a Message-ID be UTF-8? Also, it looks like OpenPGP.js doesn't support gpg --export-secret-subkeys files yet[2]. Daniel [1]: https://bitbucket.org/skskeyserver/sks-keyserver/src/1a1b0b48e642449527e2ddafb761352f339a2636/dbserver.ml?at=default#cl-202 [2]: https://github.com/openpgpjs/openpgpjs/issues/251 From arjan.wekking at pine.nl Fri Jul 3 16:08:39 2015 From: arjan.wekking at pine.nl (Arjan Wekking) Date: Fri, 3 Jul 2015 16:08:39 +0200 Subject: Secure Private Key Synchronization (RFC) In-Reply-To: References: Message-ID: <03544057-7F7F-4802-86F5-B19C3E2F10C4@pine.nl> Hello Tankred. Interesting proposal. > On 03 Jul 2015, at 12:44, Tankred Hase wrote: > > That's a good question and the spec is indeed not specific enough > here. If I'm not mistaken Mailvelope only includes the primary key > packets in their current implementation. But it makes sense to include > subkey packets as well. Something to be clarified in the spec. So, if I understand this correctly, this would still only cover private keys c.q. key pairs? But what about the public keys of your contacts, and their uids and signatures? If it would allow you to store these as well, perhaps with the same [KEY ID]@[HOSTNAME] message-id scheme but using different MIME types, it could also function as a simple ?shared key ring?? Also, wouldn?t it be better to use [FINGERPRINT] instead of [KEY ID] in the message-id, assuming that the latter is actually a long key ID and not the fingerprint already? Although it is probably still unlikely for quite a while, collisions on long key IDs are technically possible and will only become more likely. RFC 4880 section 3.3 also recommends not relying on the uniqueness of key IDs: > Implementations SHOULD NOT assume that Key IDs are unique. Now, if you were only to generete these message-id?s for private key pairs, I assume it would probably never be an issue. But if you were to add public keys as well, then using fingerprints instead of (long) key ID?s would perhaps be better. -Arjan From viktordick86 at gmail.com Sat Jul 4 11:24:19 2015 From: viktordick86 at gmail.com (Viktor Dick) Date: Sat, 4 Jul 2015 11:24:19 +0200 Subject: Merging private subkeys into other key Message-ID: <5597A643.7040200@gmail.com> Hi, there has already been a discussion on this two years ago, see https://lists.gnupg.org/pipermail/gnupg-users/2013-September/047567.html I have been following the intstructions on https://wiki.debian.org/Subkeys for some time now, with my master key only residing on my backup disk and several machines having only the subkeys. But now I somehow have the problem that only an older version of the master key is still there, so I have one keyring with the master secret key but without the most recent subkeys and another with the most recent subkeys but without the master key. Does anyone have an idea how to merge them? Using --import results in ### gpg: Total number processed: 2 gpg: unchanged: 1 gpg: secret keys read: 2 ### I also tried ### $ gpg --homedir /mnt/backup/.gnupg --expert --edit-key gpg> addkey Please select what kind of key you want: .... (13) Existing key Your selection? 13 Enter the keygrip: No key with this keygrip ### I am not sure what the keygrip is, but I guess it is only valid within the same keyring or something? Any help is greatly appreciated. In a month or so I need to create new subkeys and I would rather not lose my current subkeys. Regards, Viktor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From juanmi.3000 at gmail.com Sat Jul 4 14:03:31 2015 From: juanmi.3000 at gmail.com (=?UTF-8?Q?Juan_Miguel_Navarro_Mart=c3=adnez?=) Date: Sat, 4 Jul 2015 14:03:31 +0200 Subject: Merging private subkeys into other key In-Reply-To: <5597A643.7040200@gmail.com> References: <5597A643.7040200@gmail.com> Message-ID: <5597CB93.7010103@gmail.com> I could do it myself by importing the keys in GPG 2.1, then exporting them. -- Juan Miguel Navarro Mart?nez GPG Keyfingerprint: 5A91 90D4 CF27 9D52 D62A BC58 88E2 947F 9BC6 B3CF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From viktordick86 at gmail.com Sat Jul 4 16:34:32 2015 From: viktordick86 at gmail.com (Viktor Dick) Date: Sat, 4 Jul 2015 16:34:32 +0200 Subject: Merging private subkeys into other key In-Reply-To: <5597CB93.7010103@gmail.com> References: <5597A643.7040200@gmail.com> <5597CB93.7010103@gmail.com> Message-ID: <5597EEF8.7030300@gmail.com> On 04.07.2015 14:03, Juan Miguel Navarro Mart?nez wrote: > I could do it myself by importing the keys in GPG 2.1, then exporting > them. Hi, thanks for the quick reply, but I am using GPG 2.1.5 and 'gpg --import sec.key' does not seem to work if there are already other subkeys of the same key present. I guess the patch mentioned in the link in my earlier post has never been accepted into the source code. In principle I also found this problematic on earlier occasions, namely even if I the key on my backup partition was up-to-date and I added a new subkey there, it was somehow non-intuitive to get the keyrings on my PC and laptop up-to-date. It seems it is necessary to delete the complete key from them first and then re-import them. Or is there a better way? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From juanmi.3000 at gmail.com Sat Jul 4 17:38:09 2015 From: juanmi.3000 at gmail.com (=?UTF-8?Q?Juan_Miguel_Navarro_Mart=c3=adnez?=) Date: Sat, 4 Jul 2015 17:38:09 +0200 Subject: Merging private subkeys into other key In-Reply-To: <5597EEF8.7030300@gmail.com> References: <5597A643.7040200@gmail.com> <5597CB93.7010103@gmail.com> <5597EEF8.7030300@gmail.com> Message-ID: <5597FDE1.9020306@gmail.com> El 04/07/2015 a las 16:34, Viktor Dick escribi?: > Hi,> [...] > It seems it is necessary to delete the> complete key from them first and then re-import them. Or is there a> better way? > For now, that's the only way I know of how to merge them, which is what I did and I think you said, get the master key and the different subkeys in different files (ex. masterkey.gpg, encryption_subkey.gpg, windows_subkey.gpg, linux_subkey.gpg, android_subkey.gpg...), create a temp folder or delete the secret keys from the current keyring. Then import them back, do whatever changes I need and export the whole thing after that so I can easily import the whole thing back for new changes. And, of course, either remove the non-needed subkeys from the keyring (as in delete the Windows and Android secret parts from the Linux keyring) or shred the temporary keyring depending on what method I used. If someone else knows another easy way that can help you (and I guess me as well though it's not too much of an annoyance for me as I may do that rarely) -- Juan Miguel Navarro Mart?nez GPG Keyfingerprint: 5A91 90D4 CF27 9D52 D62A BC58 88E2 947F 9BC6 B3CF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From viktordick86 at gmail.com Sat Jul 4 18:18:53 2015 From: viktordick86 at gmail.com (Viktor Dick) Date: Sat, 4 Jul 2015 18:18:53 +0200 Subject: Merging private subkeys into other key In-Reply-To: <5597FDE1.9020306@gmail.com> References: <5597A643.7040200@gmail.com> <5597CB93.7010103@gmail.com> <5597EEF8.7030300@gmail.com> <5597FDE1.9020306@gmail.com> Message-ID: <5598076D.7010705@gmail.com> OK, it seems that the actual problem was that --export-secret-subkeys does not work if I leave the passphrase empty. Since my hard disks are encrypted, I usually do not have passphrases for my secret keys and since GnuPG 2.0 this created some problems. When I exported them with a passphrase and imported them, giving that passphrase, they are correctly merged into the existing key. Afterwards the passphrase can be deleted again. I now also understand why gnupg is always asking multiple times for a (new) passphrase when exporting or changing the passphrase - it seems to have a different passphrase for each subkey. Of course this is not very helpful if the dialog does not specify which key is about to be changed. I guess I should file a bug report for this, if I create a new subkey every year it will take quite a while to export the complete key if I have to type a passphrase for each of them in a few years... Thanks, Viktor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From bernhard at intevation.de Mon Jul 6 12:43:48 2015 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 6 Jul 2015 12:43:48 +0200 Subject: gpa and gpgex in gpg 2.1.x releases for windows. In-Reply-To: References: Message-ID: <201507061243.49332.bernhard@intevation.de> Hi, On Thursday 02 July 2015 at 22:06:03, Schlacta, Christ wrote: > As a gpg user, I've been using the gpg 2.1.x releases for a while. ?as > of 2.1.1, gpg for windows included gpa and gpgex. ?I used them. ?newer > releases didn't remove these features, but didn't upgrade or include > them either. ?Now it's difficult if not impossible to install gpa and > gpgex with gnupg 2.1.x series. ?Can we get these nearly essential > features added back into the 2.1.x releases going forward please? right now the product Gpg4win 2.2.4 offers GPA and GpgEX, so you should be able to install it from there. Check out http://gpg4win.de/community.html to get more assisstance. Gpg4win does not package GnuPG 2.1.x yet, because GnuPG 2.1.x is "modern", more recent and moving a lot faster. From the users' point of view, some features are a bit more experimental right now. Once we've put in the effort and GnuPG 2.1.x matures even more, Gpg4win will come with GnuPG 2.1.x (or 2.2.x). Does that answer your question? Best, Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From steve at sawczyn.com Mon Jul 6 16:11:19 2015 From: steve at sawczyn.com (Steven M. Sawczyn) Date: Mon, 6 Jul 2015 09:11:19 -0500 Subject: Question about GpgOL Message-ID: <010101d0b7f5$a1956f20$e4c04d60$@Sawczyn.com> Hi, I?m trying to use the GpgOL plugin and am running into a hopefully solvable issue. Essentially, I want to be able to send and sign Email, but when I do this, the signature is always opaque. While I think I understand the reason for using opaque, this essentially results in the message being duplicated. Is there a way to change this behavior, so that my messages are clear signed, or so that the signature is attached to the message? Thanks for any help, Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From scriptkiddie at wp.pl Tue Jul 7 15:40:35 2015 From: scriptkiddie at wp.pl (Marek Szuba) Date: Tue, 07 Jul 2015 15:40:35 +0200 Subject: gpg-2.1.6 scdaemon: cannot disable OpenPGP application Message-ID: <559BD6D3.90704@wp.pl> Hello, I have run into problems trying to get GnuPG (version 2.1.6, running under Linux/amd64) to talk to my SmartCard-HSM. The card has been working perfectly so far, ditto the reader (indeed, I can see in the logs that the latter is seen by scdaemon). Judging from the fact the string sd-hsm does appear inside the scdaemon binary, this application should - as expected - be supported. Okay, here goes: $ gpg --card-status [the reader gets detected and its LED blinks once] scdaemon[2513] can't select application 'openpgp': Not supported gpg: OpenPGP card not available: Not supported Makes sense, this is not an OpenPGP card so no wonder the application cannot be selected. I've killed the running instance of scdaemon and in order to prevent it from getting stuck on this in the future, added disable-application openpgp to ~/.gnupg/scdaemon.conf. The problem is, I still get exactly the same error with that line in the config... Messing with debug levels hasn't revealed anything enlightening, merely confirming that scdaemon happily keeps on trying to use the supposedly-disabled application. Running gpg as root has not helped either. I would very much appreciate any help you could offer me with solving this problem. Should you require any more information, please let me know! Yours sincerely, -- MS From rjh at sixdemonbag.org Tue Jul 7 19:18:25 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 07 Jul 2015 13:18:25 -0400 Subject: Question about FAQ maintenance In-Reply-To: <873815p7b8.fsf@vigenere.g10code.de> References: <201507031102.00756.bernhard@intevation.de> <873815p7b8.fsf@vigenere.g10code.de> Message-ID: <559C09E1.4020102@sixdemonbag.org> First, the good news: yes, I did receive your emails about the FAQ. Second, the bad news: I'm on vacation and won't be responding to them for another couple of days. I haven't vanished, I'm just on holiday. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Wed Jul 8 10:02:00 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 08 Jul 2015 17:02:00 +0900 Subject: gpg-2.1.6 scdaemon: cannot disable OpenPGP application In-Reply-To: <559BD6D3.90704@wp.pl> References: <559BD6D3.90704@wp.pl> Message-ID: <559CD8F8.5000702@fsij.org> Hello, Thank you for your report. I maintain scdaemon of GnuPG. On 07/07/2015 10:40 PM, Marek Szuba wrote: > I have run into problems trying to get GnuPG (version 2.1.6, running > under Linux/amd64) to talk to my SmartCard-HSM. The card has been > working perfectly so far, ditto the reader (indeed, I can see in the > logs that the latter is seen by scdaemon). Judging from the fact the > string sd-hsm does appear inside the scdaemon binary, this application > should - as expected - be supported. Okay, here goes: Since I don't have any experience with SmartCard-HSM, could you please let me know how it worked and what version of GnuPG? > $ gpg --card-status > [the reader gets detected and its LED blinks once] > scdaemon[2513] can't select application 'openpgp': Not supported > gpg: OpenPGP card not available: Not supported > > Makes sense, this is not an OpenPGP card so no wonder the application > cannot be selected. I've killed the running instance of scdaemon and in > order to prevent it from getting stuck on this in the future, added > > disable-application openpgp > > to ~/.gnupg/scdaemon.conf. > > The problem is, I still get exactly the same error with that line in the > config... Messing with debug levels hasn't revealed anything > enlightening, merely confirming that scdaemon happily keeps on trying to > use the supposedly-disabled application. Running gpg as root has not > helped either. > > I would very much appreciate any help you could offer me with solving > this problem. Should you require any more information, please let me know! It is gpg frontend which submits request "SCD SERIALNO openpgp" (with specific apptype=openpgp) to gpg-agent and gpg-agent relays it to scdaemon. The code is there since 2009. The setting of 'disable-application openpgp' is only valid when the command doesn't come with apptype. IIUC, there was the error message, too. It might be the stderr was not to directed TTY in other versions, perhaps. Are there any problems for the functionality? -- From gniibe at fsij.org Wed Jul 8 10:10:22 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 08 Jul 2015 17:10:22 +0900 Subject: gpg-agent and putty/ssh agent bug In-Reply-To: <5592F711.8020608@kset.org> References: <55907BAA.6040802@kset.org> <87twtpjrr1.fsf@vigenere.g10code.de> <5592F711.8020608@kset.org> Message-ID: <559CDAEE.5090601@fsij.org> On 07/01/2015 05:07 AM, Marko Bo?ikovi? wrote: > Here we go... [...] > 2015-06-30 20:28:26 gpg-agent[8912] DBG: chan_0000016C <- ERR 100663404 Card error > 2015-06-30 20:28:26 gpg-agent[8912] no authentication key for ssh on card: Card error It seems that your private keys are on smartcard. And it seems that card reader is not available. If you are using smartcard and card reader, please let me know specific product name for the reader. -- From bozho at kset.org Wed Jul 8 10:51:47 2015 From: bozho at kset.org (=?UTF-8?B?TWFya28gQm/Fvmlrb3ZpxIc=?=) Date: Wed, 08 Jul 2015 09:51:47 +0100 Subject: gpg-agent and putty/ssh agent bug In-Reply-To: <559CDAEE.5090601@fsij.org> References: <55907BAA.6040802@kset.org> <87twtpjrr1.fsf@vigenere.g10code.de> <5592F711.8020608@kset.org> <559CDAEE.5090601@fsij.org> Message-ID: <559CE4A3.3060900@kset.org> On 08/07/2015 09:10, NIIBE Yutaka wrote: > On 07/01/2015 05:07 AM, Marko Bo?ikovi? wrote: >> Here we go... > [...] >> 2015-06-30 20:28:26 gpg-agent[8912] DBG: chan_0000016C <- ERR 100663404 Card error >> 2015-06-30 20:28:26 gpg-agent[8912] no authentication key for ssh on card: Card error > > It seems that your private keys are on smartcard. And it seems that > card reader is not available. > > If you are using smartcard and card reader, please let me know > specific product name for the reader. > Hi, I'm not using a smartcard (yet :) Maybe gpg-agent thinks I am using a smartcard on the first try and then just gives up when it doesn't find one? The second and all subsequent tries work fine until I restart gpg-agent. -- Marko From scriptkiddie at wp.pl Wed Jul 8 11:29:48 2015 From: scriptkiddie at wp.pl (Marek Szuba) Date: Wed, 08 Jul 2015 11:29:48 +0200 Subject: gpg-2.1.6 scdaemon: cannot disable OpenPGP application In-Reply-To: <559CD8F8.5000702@fsij.org> References: <559BD6D3.90704@wp.pl> <559CD8F8.5000702@fsij.org> Message-ID: <559CED8C.2080704@wp.pl> On 2015-07-08 10:02, NIIBE Yutaka wrote: > Since I don't have any experience with SmartCard-HSM, could you please > let me know how it worked and what version of GnuPG? Should have made this more clear, sorry. This is the first time I tried using this card with GnuPG, what I meant is that it had been working perfectly with other applications (via PKCS#11, PKCS#15 and dedicated SmartCard-HSM tools). > It is gpg frontend which submits request "SCD SERIALNO openpgp" (with > specific apptype=openpgp) to gpg-agent and gpg-agent relays it to > scdaemon. The code is there since 2009. I see. In other words, even though scdaemon does support this type of card now gpg itself (I've just tried gpgsm, I've got no X.509 certificates on that card but at least no errors appear) still requires an OpenPGP SmartCard? Cheers, -- MS From rjh at sixdemonbag.org Wed Jul 8 17:45:55 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 08 Jul 2015 11:45:55 -0400 Subject: Question about FAQ maintenance In-Reply-To: <201507031102.00756.bernhard@intevation.de> References: <201507031102.00756.bernhard@intevation.de> Message-ID: <559D45B3.7040700@sixdemonbag.org> > Is this still true? My suggestion would to add some date indication > so that readers can assume which version of the FAQ they are looking > at. I have a small update to the FAQ that's ready to be pushed, but I'm held back slightly by my lack of comfort with org-mode (the format used for the FAQ). The FAQ hasn't changed in a few years. Probably 95% of the text is still correct. However, there are some changes that need to be made (e.g., we now give a cautious recommendation for PGP/MIME, and the defaults have changed slightly, etc.). > (Background: I've seen some posts on the lists for new FAQ entries > from 2014 and also I found a potential source code at > https://github.com/rjhansen/gpgfaq/blob/master/gpgfaq.xml with the > last commit in 2013 .. this confused me. ;) ) The GitHub repo should probably be closed: it's been completely superseded by the main GnuPG repo. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From magist3r at gmail.com Thu Jul 9 00:04:52 2015 From: magist3r at gmail.com (Sergei Lopatin) Date: Wed, 08 Jul 2015 22:04:52 +0000 Subject: gpgsm can't decrypt smime encrypted mails from 1 contact Message-ID: Hi all! Please take a look at this bugreport https://bugs.gnupg.org/gnupg/issue2033 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gniibe at fsij.org Thu Jul 9 01:59:00 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 09 Jul 2015 08:59:00 +0900 Subject: gpg-agent and putty/ssh agent bug In-Reply-To: <559CE4A3.3060900@kset.org> References: <55907BAA.6040802@kset.org> <87twtpjrr1.fsf@vigenere.g10code.de> <5592F711.8020608@kset.org> <559CDAEE.5090601@fsij.org> <559CE4A3.3060900@kset.org> Message-ID: <559DB944.2060907@fsij.org> Sorry, my understanding of private key retrieval was wrong. On 07/08/2015 05:51 PM, Marko Bo?ikovi? wrote: > Maybe gpg-agent thinks I am using a smartcard on the first try and then just > gives up when it doesn't find one? You're right. For SSH authentication, the function card_key_available is always called before searching other entries (of keys on files) if not disabled by "disable-scdaemon". Source: gnupg/agent/command-ssh.c. -- From gniibe at fsij.org Thu Jul 9 06:56:46 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 09 Jul 2015 13:56:46 +0900 Subject: gpg-2.1.6 scdaemon: cannot disable OpenPGP application In-Reply-To: <559CED8C.2080704@wp.pl> References: <559BD6D3.90704@wp.pl> <559CD8F8.5000702@fsij.org> <559CED8C.2080704@wp.pl> Message-ID: <559DFF0E.1060208@fsij.org> Hello, Currently, in the source code of GnuPG, we have support of following: DINSIG (DIN V 66291-1) German Geldkarte OpenPGP card pkcs#15 card SmartCard-HSM Telesec NKS card Pardon my ignorance about smartcard other than OpenPGPcard compatible. The driver for SmartCard-HSM is recently added. Others looks quite old. On 07/08/2015 06:29 PM, Marek Szuba wrote: > This is the first time I tried using this card with GnuPG, what I > meant is that it had been working perfectly with other applications > (via PKCS#11, PKCS#15 and dedicated SmartCard-HSM tools). I see your situation. > In other words, even though scdaemon does support this type of card > now gpg itself (I've just tried gpgsm, I've got no X.509 > certificates on that card but at least no errors appear) still > requires an OpenPGP SmartCard? I'm not sure, but it would be possible for SmartCard-HSM to be tested very lightly, and it was not well tested as a whole GnuPG suite. I mean, it would not be tested with gpg frontend together. Perhaps, it was only tested with gpgsm. If so, I think that the situation is somehow frustrated for users of SmartCard-HSM who expect OpenPGP functionality. I've examined the code of SmartCard-HSM driver. There are most functionalities. However, the method of 'do_readkey' (of retrieving public key information from card) is missing. If it will be supported, we will be able to use SmartCard-HSM for OpenPGP. I need some help for this direction of development. Well, for the first step, please help me. I think that $ gpg-connect-agent learn "SCD SERIALNO" /bye ... works somehow with SmartCard-HSM. Could you please confirm? -- From bozho at kset.org Thu Jul 9 10:46:39 2015 From: bozho at kset.org (=?UTF-8?B?TWFya28gQm/Fvmlrb3ZpxIc=?=) Date: Thu, 09 Jul 2015 09:46:39 +0100 Subject: gpg-agent and putty/ssh agent bug In-Reply-To: <559DB944.2060907@fsij.org> References: <55907BAA.6040802@kset.org> <87twtpjrr1.fsf@vigenere.g10code.de> <5592F711.8020608@kset.org> <559CDAEE.5090601@fsij.org> <559CE4A3.3060900@kset.org> <559DB944.2060907@fsij.org> Message-ID: <559E34EF.5060801@kset.org> On 09/07/2015 00:59, NIIBE Yutaka wrote: > Sorry, my understanding of private key retrieval was wrong. > > On 07/08/2015 05:51 PM, Marko Bo?ikovi? wrote: >> Maybe gpg-agent thinks I am using a smartcard on the first try and then just >> gives up when it doesn't find one? > > You're right. For SSH authentication, the function card_key_available > is always called before searching other entries (of keys on files) if > not disabled by "disable-scdaemon". Source: gnupg/agent/command-ssh.c. With that in mind, I disabled scdaemon in gpg-agent settings and restarted it (killed the scdaemon as well), but I still get the same behaviour. -- Marko From bernhard at intevation.de Thu Jul 9 14:45:36 2015 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 9 Jul 2015 14:45:36 +0200 Subject: Question about FAQ maintenance In-Reply-To: <559D45B3.7040700@sixdemonbag.org> References: <201507031102.00756.bernhard@intevation.de> <559D45B3.7040700@sixdemonbag.org> Message-ID: <201507091445.37781.bernhard@intevation.de> On Wednesday 08 July 2015 at 17:45:55, Robert J. Hansen wrote: > I have a small update to the FAQ that's ready to be pushed, but I'm held > back slightly by my lack of comfort with org-mode (the format used for > the FAQ). Cool, please push it. (And think about adding a version information.) > The FAQ hasn't changed in a few years. Probably 95% of the text is > still correct. However, there are some changes that need to be made > (e.g., we now give a cautious recommendation for PGP/MIME, and the > defaults have changed slightly, etc.). I think it is important that we as the GnuPG Initiative keep the FAQ current and have a place to point towards to. The workflow I have gathered from the document is: Send email to you. :) Is this the workflow, you're intending? > The GitHub repo should probably be closed: it's been completely > superseded by the main GnuPG repo. Good point, or it should be replaced by a pointer to the main repo then. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From scriptkiddie at wp.pl Thu Jul 9 15:48:29 2015 From: scriptkiddie at wp.pl (Marek Szuba) Date: Thu, 09 Jul 2015 15:48:29 +0200 Subject: gpg-2.1.6 scdaemon: cannot disable OpenPGP application In-Reply-To: <559DFF0E.1060208@fsij.org> References: <559BD6D3.90704@wp.pl> <559CD8F8.5000702@fsij.org> <559CED8C.2080704@wp.pl> <559DFF0E.1060208@fsij.org> Message-ID: <559E7BAD.1040204@wp.pl> On 2015-07-09 06:56, NIIBE Yutaka wrote: > I'm not sure, but it would be possible for SmartCard-HSM to be tested > very lightly, and it was not well tested as a whole GnuPG suite. I > mean, it would not be tested with gpg frontend together. Perhaps, it > was only tested with gpgsm. > > If so, I think that the situation is somehow frustrated for users of > SmartCard-HSM who expect OpenPGP functionality. Indeed. To be precise, the SmartCard-HSM Web site states clearly GnuPG only supports this card as key store for X.509 certificates and private keys so there should be no false expectations regarding OpenPGP support - but given we are talking about a powerful, highly versatile and apparently increasingly popular SmartCard here it would in the long run be a waste not to let it be used in this mode. One problem is that as you pointed out in your previous post, the Assuan command which explicitly demands cards accessed by gpg to support the openpgp application is hard-coded in the sources and has been there for quite a few years. Hopefully relaxing this restriction will not prove to be too much of a paradigm shift. > I've examined the code of SmartCard-HSM driver. There are most > functionalities. However, the method of 'do_readkey' (of retrieving > public key information from card) is missing. If it will be > supported, we will be able to use SmartCard-HSM for OpenPGP. > > I need some help for this direction of development. It is excellent news that there shouldn't be too much left to implement! I will be very happy to provide any help I can. Shall we continue off the mailing list? -- MS From ndk.clanbo at gmail.com Sat Jul 11 08:24:45 2015 From: ndk.clanbo at gmail.com (NdK) Date: Sat, 11 Jul 2015 08:24:45 +0200 Subject: gpg-2.1.6 scdaemon: cannot disable OpenPGP application In-Reply-To: <559DFF0E.1060208@fsij.org> References: <559BD6D3.90704@wp.pl> <559CD8F8.5000702@fsij.org> <559CED8C.2080704@wp.pl> <559DFF0E.1060208@fsij.org> Message-ID: <55A0B6AD.7020900@gmail.com> Il 09/07/2015 06:56, NIIBE Yutaka ha scritto: > Currently, in the source code of GnuPG, we have support of following: > DINSIG (DIN V 66291-1) > German Geldkarte > OpenPGP card > pkcs#15 card > SmartCard-HSM > Telesec NKS card So I could use any pkcs#15-formatted card to keep GnuPG keys? I searched a bit but saw no docs on what needs to be done... BYtE, Diego From gniibe at fsij.org Sat Jul 11 10:59:18 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Sat, 11 Jul 2015 17:59:18 +0900 Subject: gpg-2.1.6 scdaemon: cannot disable OpenPGP application In-Reply-To: <55A0B6AD.7020900@gmail.com> References: <559BD6D3.90704@wp.pl> <559CD8F8.5000702@fsij.org> <559CED8C.2080704@wp.pl> <559DFF0E.1060208@fsij.org> <55A0B6AD.7020900@gmail.com> Message-ID: <55A0DAE6.7070008@fsij.org> On 07/11/2015 03:24 PM, NdK wrote: > Il 09/07/2015 06:56, NIIBE Yutaka ha scritto: > >> Currently, in the source code of GnuPG, we have support of following: >> DINSIG (DIN V 66291-1) >> German Geldkarte >> OpenPGP card >> pkcs#15 card >> SmartCard-HSM >> Telesec NKS card > So I could use any pkcs#15-formatted card to keep GnuPG keys? > I searched a bit but saw no docs on what needs to be done... It seems that the support of those cards (other than OpenPGP card) are intended to be used with gpgsm (for X.509). I don't think pkcs#15 driver worked for OpenPGP since it doesn't have READKEY method to access its public key. -- From dieamme at googlemail.com Sun Jul 12 20:46:32 2015 From: dieamme at googlemail.com (thomas) Date: Sun, 12 Jul 2015 20:46:32 +0200 Subject: {gnupg 2.1.6} Howto change s2k cipher from AES -> AES256? Message-ID: <20150712204632.4e715e85@TTM-i5.homenet> Hi, I'm trying with gnupg version 2.1.6. Based on the changelog: Is there a way to change the encryption-cipher for the secret Keys in "private-keys-v1.d" ? I tried it with: gpg2 --openpgp --s2k-cipher-algo AES256 --s2k-digest-algo SHA512 \ --s2k-mode 3 --s2k-count 65000000 --edit-key Key-id gpg> passwd --> change passphrase --> save But this didn't work for me. With the default config the secret keys are encrypted and stored with AES128 and SHA1. How to change it? -- Thank you and best regards, thomas From aheinecke at intevation.de Tue Jul 14 19:37:37 2015 From: aheinecke at intevation.de (Andre Heinecke) Date: Tue, 14 Jul 2015 19:37:37 +0200 Subject: operating on remote files (Windows) using a UNC In-Reply-To: References: Message-ID: <1733725.IIzL2vjk3K@esus> Hi, Sorry for the late reply, gpg4win-users-en would probably have been a better place for this question. On Tuesday, June 30, 2015 09:57:55 PM Charles Spitzer wrote: > Whenever I attempt to operate upon a remote file using a UNC, it doesn't > seem to find the file. > > C:\Users\cspitzer>gpg --decrypt "\\remote.machine.com\data\Vendor File > Transfers\Archive\Input.2015-06-15.045720.csv.pgp" gpg: can't open > `\\\\remote.machine.com\\data \\Vendor File Transfers > \\Archive\\Input.2015-06-15.045720.csv.pgp': No such file or directory gpg: > decrypt_message failed: No such file or directory I stumbled upon this also once. You need to use forward slashes instead of backslashes for gnupg to work with UNC paths e.g.: gpg2 --decrypt //remote.machine/encrypted.gpg Works. -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From punksgt at gmail.com Wed Jul 15 17:13:24 2015 From: punksgt at gmail.com (punksgt) Date: Wed, 15 Jul 2015 09:13:24 -0600 Subject: GNUPG / GPG / S3 / Duplicity gpg: no default secret key: secret key not available Message-ID: <55A67894.7090809@gmail.com> I using S3 / duplicity back up script , save my files. It has been working just fine, until I added a second gpg key. Then all hell broke loose. I tried to deal with two keys, then I delete the second key. Then I remove / purged gpg altogether and started with a fresh start. I created a new key and this is the response I get. |GPGError: GPG Failed, see log below: ===== Begin GnuPG log ===== gpg: no default secret key: secret key not available gpg: [stdin]: sign+encrypt failed: secret key not available ===== End GnuPG log ===== | Here is my back up script (but I dont think that is the problem) |> #!/bin/bash > > # Make GPG explicitly aware of our private key, > # since we'll be running this via cron as root > > > HOME="/" SOURCE="/" TARGET=s3+http://xxxx/xxxxx/ > LOGFILE=/home/bege/.duplicity/desktop.log export HOME=$HOME export > SOURCE=$SOURCE export TARGET=$TARGET export LOGFILE=$LOGFILE > > # Load our credentials source "/home/bege/Desktop/.credentials.conf" > > export PASSPHRASE export AWS_ACCESS_KEY_ID export > AWS_SECRET_ACCESS_KEY > > GPG_KEY='7E4B6B9B' > > duplicity \ > --verbosity notice \ > --s3-use-new-style \ > --volsize=1000 \ > --encrypt-key="$GPG_KEY" \ > --sign-key="$GPG_KEY" \ > --full-if-older-than 7D \ > --asynchronous-upload \ > --log-file "/home/bege/.duplicity/log.log" \ > --include=/home/bege/Desktop/charts \ > --exclude=/** \ > --progress \ > $SOURCE \ > $TARGET > $LOGFILE > > > > unset PASSPHRASE unset AWS_ACCESS_KEY_ID unset AWS_SECRET_ACCESS_KEY | Here is the details of my keys: |/home/bege/.gnupg/pubring.gpg ----------------------------- pub 2048R/7E4B6B9B 2015-07-15 uid Chad H /home/bege/.gnupg/secring.gpg ----------------------------- sec 2048R/7E4B6B9B 2015-07-15 uid Chad H | I have also modified the conf file to make this key the default one. I have spent far to much time on this but I'm obessed for some lame reason, I'm at my wits end, thanks in advance. http://askubuntu.com/questions/648541/gnupg-gpg-s3-duplicity-gpg-no-default-secret-key-secret-key-not-availabl -------------- next part -------------- An HTML attachment was scrubbed... URL: From gniibe at fsij.org Thu Jul 16 02:09:15 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 16 Jul 2015 09:09:15 +0900 Subject: GNUPG / GPG / S3 / Duplicity gpg: no default secret key: secret key not available In-Reply-To: <55A67894.7090809@gmail.com> References: <55A67894.7090809@gmail.com> Message-ID: <55A6F62B.5030600@fsij.org> On 07/16/2015 12:13 AM, punksgt wrote: > Here is the details of my keys: > > |/home/bege/.gnupg/pubring.gpg > ----------------------------- > pub 2048R/7E4B6B9B 2015-07-15 > uid Chad H > > /home/bege/.gnupg/secring.gpg > ----------------------------- > sec 2048R/7E4B6B9B 2015-07-15 > uid Chad H It seems that your key is only primary key (which is for signing other key and for signing data). For encryption, you also need a subkey for encryption (or primary key should have a flag for encryption). You can add a subkey for encryption by 'gpg --edit 7E4B6B9B' or you can create new key with primary key and subkey for encryption. Default is "RSA and RSA", which means RSA primary key and RSA encryption key. -- From dsfvdfbfdb at mail.com Wed Jul 15 23:25:12 2015 From: dsfvdfbfdb at mail.com (sdvfds sdvsdv) Date: Wed, 15 Jul 2015 23:25:12 +0200 Subject: OpenPGP smartcard Message-ID: An HTML attachment was scrubbed... URL: From gniibe at fsij.org Fri Jul 17 07:07:37 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 17 Jul 2015 14:07:37 +0900 Subject: OpenPGP smartcard In-Reply-To: References: Message-ID: <55A88D99.7060008@fsij.org> Hello, On 07/16/2015 06:25 AM, sdvfds sdvsdv wrote: > I have been trying to find technical specifications for the g10 openpgp > smartcard without much success so far. Perhaps someone on this list will be > able to answer my questions? I answer what I know of. The specifications and sample code are available from: http://www.g10code.com/p-card.html > What is the vendor and model for the crypto chip? See the page above. > Is Javacard and/or GlobalPlatform installed? I don't think so. > The g10code webpage states that ?software on this card is not > available as free software due to NDAs?. So, you have visited the page already. Please read the page carefully. If you needed, please download the documentation and read it. > Is there any way to verify that the software has not been tampered? I'd like to ask you, how do you verify for your smartcard(s), in general? > Is card firmware writable after it leaves manufacturing/personalization facility? I don't think the firmware is writable by a user of OpenPGPcard. > Is PKCS#15 supported? If you are speaking of OpenPGPcard, I don't think so. > Are there any ?master keys? stored on the card (OS signing keys, applet keys, > etc) which end user is unable to alter or reset? I don't know. > OpenPGP card specification v2.1 states ?Private keys and passwords > cannot be read from the card with any command or function.? What > steps have been taken to comply with this? Umm... you already read it, and still post questions... Sorry, I don't understand this question of yours. Perhaps, you read the specification in different way. I think that the specification just explains there is no command or function defined in the specification to read out secret data. There is no guarantee for non-existence of backdoor or vulnerability, by the specification itself. I understand that secret data should not be read out from smartcard. It would be good to ask smartcard manufacturer, too. -- From gniibe at fsij.org Fri Jul 17 07:48:00 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 17 Jul 2015 14:48:00 +0900 Subject: GNUPG / GPG / S3 / Duplicity gpg: no default secret key: secret key not available In-Reply-To: <55A8886E.8090901@gmail.com> References: <55A67894.7090809@gmail.com> <55A6F62B.5030600@fsij.org> <55A8886E.8090901@gmail.com> Message-ID: <55A89710.9070805@fsij.org> On 07/17/2015 01:45 PM, punksgt wrote: > Still getting this error. > > GPGError: GPG Failed, see log below: > ===== Begin GnuPG log ===== > gpg: no default secret key: secret key not available > gpg: [stdin]: sign+encrypt failed: secret key not available > ===== End GnuPG log ===== I re-read your original post again, and found that you redefine the environment variable "HOME" in the script, which is the cause of the trouble. Please add two lines in your script: =================================== GNUPGHOME=/home/bege/.gnupg export GNUPGHOME =================================== Then, please try with new script. By setting GNUPGHOME, gpg command will access that directory. (Please note that secret subkey for encryption is also needed.) -- From punksgt at gmail.com Fri Jul 17 06:45:34 2015 From: punksgt at gmail.com (punksgt) Date: Thu, 16 Jul 2015 22:45:34 -0600 Subject: GNUPG / GPG / S3 / Duplicity gpg: no default secret key: secret key not available In-Reply-To: <55A6F62B.5030600@fsij.org> References: <55A67894.7090809@gmail.com> <55A6F62B.5030600@fsij.org> Message-ID: <55A8886E.8090901@gmail.com> Okay, not to be a complete noob. So I created a new key and selected "RSA and RSA" Still getting this error. GPGError: GPG Failed, see log below: ===== Begin GnuPG log ===== gpg: no default secret key: secret key not available gpg: [stdin]: sign+encrypt failed: secret key not available ===== End GnuPG log ===== Here is the out put of my edit function: bege at BlueSky:~/Desktop$ gpg --edit D9CF0329 gpg (GnuPG) 1.4.18; Copyright (C) 2014 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. pub 2048R/D9CF0329 created: 2015-07-17 expires: never usage: SC trust: ultimate validity: ultimate sub 2048R/545996A5 created: 2015-07-17 expires: never usage: E [ultimate] (1). Chad H gpg> On 07/15/2015 06:09 PM, NIIBE Yutaka wrote: > On 07/16/2015 12:13 AM, punksgt wrote: >> Here is the details of my keys: >> >> |/home/bege/.gnupg/pubring.gpg >> ----------------------------- >> pub 2048R/7E4B6B9B 2015-07-15 >> uid Chad H >> >> /home/bege/.gnupg/secring.gpg >> ----------------------------- >> sec 2048R/7E4B6B9B 2015-07-15 >> uid Chad H > It seems that your key is only primary key (which is for signing other > key and for signing data). For encryption, you also need a subkey for > encryption (or primary key should have a flag for encryption). > > You can add a subkey for encryption by 'gpg --edit 7E4B6B9B' or you > can create new key with primary key and subkey for encryption. > Default is "RSA and RSA", which means RSA primary key and RSA > encryption key. From mailing-lists at asatiifm.net Fri Jul 17 20:04:45 2015 From: mailing-lists at asatiifm.net (=?UTF-8?B?VmlsbGUgTcOkw6R0dMOk?=) Date: Fri, 17 Jul 2015 21:04:45 +0300 Subject: speedo build of 2.1.6 failing on OS X Message-ID: <55A943BD.2010000@asatiifm.net> I'm getting a failure at speedo.mk build for 2.1.6 on OS X 10.10.4 Yosemite. I'm using a forced brewed GCC 5.2, that is: $make -f build-aux/speedo.mk native INSTALL_PREFIX=/usr/local/gnupg CC=/usr/local/bin/gcc-5 CXX=/usr/local/bin/g++-5 It's failing at gpg-agent. Just the short snippet below. I just built 2.1.5 with the same setup and previous builds have also built ok. Is anyone else seeing this? Making all in agent CCLD gpg-agent CCLD gpg-protect-tool CCLD gpg-preset-passphrase Undefined symbols for architecture x86_64: "_gettext", referenced from: _ssh_handler_add_identity in gpg_agent-command-ssh.o _agent_Lunderscore in gpg_agent-call-pinentry.o _setup_qualitybar in gpg_agent-call-pinentry.o _agent_delete_key in gpg_agent-findkey.o _check_passphrase_constraints in gpg_agent-genkey.o _agent_ask_new_passphrase in gpg_agent-genkey.o _agent_genkey in gpg_agent-genkey.o ... ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status make[4]: *** [gpg-agent] Error 1 make[4]: *** Waiting for unfinished jobs.... make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 make[1]: *** [/Users/vmaatta/src/gnupg-2.1.6/PLAY/stamps/stamp-gnupg-02-make] Error 2 make: *** [native] Error 2 -- Ville -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: OpenPGP digital signature URL: From punksgt at gmail.com Fri Jul 17 21:54:47 2015 From: punksgt at gmail.com (punksgt) Date: Fri, 17 Jul 2015 13:54:47 -0600 Subject: GNUPG / GPG / S3 / Duplicity gpg: no default secret key: secret key not available In-Reply-To: <55A89710.9070805@fsij.org> References: <55A67894.7090809@gmail.com> <55A6F62B.5030600@fsij.org> <55A8886E.8090901@gmail.com> <55A89710.9070805@fsij.org> Message-ID: <55A95D87.7080900@gmail.com> Awesome! you are genius, thanks for your assistance! On 07/16/2015 11:48 PM, NIIBE Yutaka wrote: > On 07/17/2015 01:45 PM, punksgt wrote: >> Still getting this error. >> >> GPGError: GPG Failed, see log below: >> ===== Begin GnuPG log ===== >> gpg: no default secret key: secret key not available >> gpg: [stdin]: sign+encrypt failed: secret key not available >> ===== End GnuPG log ===== > I re-read your original post again, and found that you redefine the > environment variable "HOME" in the script, which is the cause of the > trouble. > > Please add two lines in your script: > =================================== > GNUPGHOME=/home/bege/.gnupg > export GNUPGHOME > =================================== > > Then, please try with new script. By setting GNUPGHOME, gpg command > will access that directory. > > (Please note that secret subkey for encryption is also needed.) From pneukom at gmail.com Fri Jul 17 21:48:10 2015 From: pneukom at gmail.com (Philip Neukom) Date: Fri, 17 Jul 2015 15:48:10 -0400 Subject: Problems with key available in v1.4.19 but not v2.1.5 Message-ID: <55A95BFA.4090102@gmail.com> Hello all. I'm having some problems with my key that was created a long time ago (1994) but updated with new emails over the years. I am stuck after searching for an answer so thought I'd ask for some guidance from the list. I have reviewed the Docs, Mini Guide and HowTos. I apologize in advance for the rather lengthy email but I figured I had to put as much info so you may see what I've tried. I moved my keys pubring.gpg, secring.pgp and trustdb.gpg to a new Mac over the past week. I downloaded and installed MacGPG for the GUI. I only installed the GPG Keychain, GPG Services and MacGPG. When I opened the GPG Keychain, all the keys were on the screen for a brief moment and then the list shrunk and many keys disappeared in addition to my personal public and secret keys. ??? So panic set in and I restored my pubring and secring from backup and deleted the install of MacGPG. I thought maybe there was a problem with MacGPG so best to go back to command line Gnupg. I installed 2.1.5 from source and found none of my keys in the pubring and secring. What??? So I downloaded and installed 1.4.19, restored the pubring and secring from backup again and found my public and secret keys are now listed. This time I generated a revoke just in case and to test the install. 1.4.19 works fine. Now I re-ran 2.1.5 and tried to find my keys. Again they've gone missing. [# gpg2 --list-keys] None of my keys (pub and sec) are available in 2.1.5. Re-running [gpg --list-keys] with 1.4.19 and my keys are still there. Why would v1.4.19 show my pub and sec keys but v2.1.5 wouldn't? I presume this is something very basic but I'm stumped. I thought v1.x and v2.x keys were interoperable?? Thanks in advance for any guidance, Philip. PS I'm on digest mode so would appreciate if you could cc me directly on any reply. Thanks. From juanmi.3000 at gmail.com Sat Jul 18 01:09:40 2015 From: juanmi.3000 at gmail.com (=?UTF-8?Q?Juan_Miguel_Navarro_Mart=c3=adnez?=) Date: Sat, 18 Jul 2015 01:09:40 +0200 Subject: Problems with key available in v1.4.19 but not v2.1.5 In-Reply-To: <55A95BFA.4090102@gmail.com> References: <55A95BFA.4090102@gmail.com> Message-ID: <55A98B34.6080600@gmail.com> Pre-2.1: Public keys are in pubring.gpg and secret keys are in secring.gpg Post-2.1: Public keys are in pubring.kbx and secret keys are in the directory private-keys-v1.d[1]. Normally they should transition the Pre-2.1 keyrings to 2.1.X the first time you use it or at least use pubring.gpg. But if you wanna force-transition the public keyring, as shown in the information about GnuPG2.1[2], you should do this commands: $ cd ~/.gnupg $ gpg --export-ownertrust >otrust.lst $ mv pubring.gpg publickeys $ gpg2 --import-options import-local-sigs --import publickeys $ gpg2 --import-ownertrust otrust.lst $ mv publickeys pubring.gpg Second one exports the trust database, then renames pubring.gpg to publickeys, next two ones import the trust database to GnuPG 2.1 and the public keys from the rename GnuPG pre-2.1 keyring. Last command renames it back to pubring.gpg so that it can be used by GnuPG 1.x and 2.0.x versions. As for the secret keyring, I don't know but I suppose you can always do: $ gpg --export-secret-keys | gpg2 --import As you have 1.4.19 and 2.1.5, `gpg` would be used for GnuPG 1.4.19 and `gpg2` for GnuPG 2.1.5. After you have done that, any change in either GnuPG pre-2.1 or post-2.1 keyrings won't be update into the other. [1]: https://www.gnupg.org/faq/whats-new-in-2.1.html#nosecring [2]: https://www.gnupg.org/faq/whats-new-in-2.1.html#keybox On 2015/07/17 at 21:48, Philip Neukom wrote: > Hello all. > > I'm having some problems with my key that was created a long time ago > (1994) but updated with new emails over the years. > > I am stuck after searching for an answer so thought I'd ask for some > guidance from the list. I have reviewed the Docs, Mini Guide and HowTos. > > I apologize in advance for the rather lengthy email but I figured I > had to put as much info so you may see what I've tried. > > I moved my keys pubring.gpg, secring.pgp and trustdb.gpg to a new Mac > over the past week. > > I downloaded and installed MacGPG for the GUI. I only installed the GPG > Keychain, GPG Services and MacGPG. > > When I opened the GPG Keychain, all the keys were on the screen for a > brief moment and then the list shrunk and many keys disappeared in > addition to my personal public and secret keys. ??? > > So panic set in and I restored my pubring and secring from backup and > deleted the install of MacGPG. I thought maybe there was a problem > with MacGPG so best to go back to command line Gnupg. > > I installed 2.1.5 from source and found none of my keys in the > pubring and secring. What??? > > So I downloaded and installed 1.4.19, restored the pubring and secring > from backup again and found my public and secret keys are now listed. > This time I generated a revoke just in case and to test the install. > 1.4.19 works fine. > > Now I re-ran 2.1.5 and tried to find my keys. Again they've gone > missing. [# gpg2 --list-keys] None of my keys (pub and sec) are > available in 2.1.5. > > Re-running [gpg --list-keys] with 1.4.19 and my keys are still there. > > Why would v1.4.19 show my pub and sec keys but v2.1.5 wouldn't? I > presume this is something very basic but I'm stumped. I thought v1.x > and v2.x keys were interoperable?? > > Thanks in advance for any guidance, > Philip. > > PS I'm on digest mode so would appreciate if you could cc me directly on > any reply. Thanks. > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- Juan Miguel Navarro Mart?nez GPG Keyfingerprint: 5A91 90D4 CF27 9D52 D62A BC58 88E2 947F 9BC6 B3CF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From juanmi.3000 at gmail.com Sat Jul 18 01:19:53 2015 From: juanmi.3000 at gmail.com (=?UTF-8?Q?Juan_Miguel_Navarro_Mart=c3=adnez?=) Date: Sat, 18 Jul 2015 01:19:53 +0200 Subject: Problems with key available in v1.4.19 but not v2.1.5 In-Reply-To: <55A95BFA.4090102@gmail.com> References: <55A95BFA.4090102@gmail.com> Message-ID: <55A98D99.3050208@gmail.com> PS: Of course, on the commands in the other email, cd ~/.gnupg implies that gnupg directory is in your home. If it is in another place, you'll have to use that path for the `cd` command instead. On 2015/07/17 at 21:48, Philip Neukom wrote: > Hello all. > > I'm having some problems with my key that was created a long time ago > (1994) but updated with new emails over the years. > > I am stuck after searching for an answer so thought I'd ask for some > guidance from the list. I have reviewed the Docs, Mini Guide and HowTos. > > I apologize in advance for the rather lengthy email but I figured I > had to put as much info so you may see what I've tried. > > I moved my keys pubring.gpg, secring.pgp and trustdb.gpg to a new Mac > over the past week. > > I downloaded and installed MacGPG for the GUI. I only installed the GPG > Keychain, GPG Services and MacGPG. > > When I opened the GPG Keychain, all the keys were on the screen for a > brief moment and then the list shrunk and many keys disappeared in > addition to my personal public and secret keys. ??? > > So panic set in and I restored my pubring and secring from backup and > deleted the install of MacGPG. I thought maybe there was a problem > with MacGPG so best to go back to command line Gnupg. > > I installed 2.1.5 from source and found none of my keys in the > pubring and secring. What??? > > So I downloaded and installed 1.4.19, restored the pubring and secring > from backup again and found my public and secret keys are now listed. > This time I generated a revoke just in case and to test the install. > 1.4.19 works fine. > > Now I re-ran 2.1.5 and tried to find my keys. Again they've gone > missing. [# gpg2 --list-keys] None of my keys (pub and sec) are > available in 2.1.5. > > Re-running [gpg --list-keys] with 1.4.19 and my keys are still there. > > Why would v1.4.19 show my pub and sec keys but v2.1.5 wouldn't? I > presume this is something very basic but I'm stumped. I thought v1.x > and v2.x keys were interoperable?? > > Thanks in advance for any guidance, > Philip. > > PS I'm on digest mode so would appreciate if you could cc me directly on > any reply. Thanks. > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- Juan Miguel Navarro Mart?nez GPG Keyfingerprint: 5A91 90D4 CF27 9D52 D62A BC58 88E2 947F 9BC6 B3CF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From johanw at vulcan.xs4all.nl Sat Jul 18 00:26:50 2015 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Sat, 18 Jul 2015 00:26:50 +0200 Subject: Problems with key available in v1.4.19 but not v2.1.5 In-Reply-To: <55A95BFA.4090102@gmail.com> References: <55A95BFA.4090102@gmail.com> Message-ID: <55A9812A.9060904@vulcan.xs4all.nl> On 17-07-2015 21:48, Philip Neukom wrote: > I'm having some problems with my key that was created a long time ago > (1994) but updated with new emails over the years. Then it's a v2 key, and unfortunately GnuPG dropped support for v2 keys. But fortunately you can install a copy of GnuPG 1.4.x alongside 2.1 to use that key. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From rjh at sixdemonbag.org Sat Jul 18 01:36:01 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 17 Jul 2015 19:36:01 -0400 Subject: Problems with key available in v1.4.19 but not v2.1.5 In-Reply-To: <55A95BFA.4090102@gmail.com> References: <55A95BFA.4090102@gmail.com> Message-ID: <55A99161.4010200@sixdemonbag.org> > I'm having some problems with my key that was created a long time > ago (1994) but updated with new emails over the years. You're using a key generated with PGP 2, which conforms to RFC1991. This is an *old* *old* standard, and has been pretty much completely replaced by RFC4880. Older versions of GnuPG supported RFC1991. Current versions of GnuPG have much less in the way of support for RFC1991. I'd suggest generating a new certificate -- after 20 years you're due for one. :) > Why would v1.4.19 show my pub and sec keys but v2.1.5 wouldn't? I > presume this is something very basic but I'm stumped. I thought > v1.x and v2.x keys were interoperable?? RFC4880 keys are interoperable between versions. RFC1991 keys *aren't*. RFC1991 has an unfortunate dependency on the MD5 hash algorithm, and MD5 is pretty much completely broken for cryptographic purposes. Since MD5 is broken, current versions of GnuPG refuse to process MD5 data... which means RFC1991 support is severely curtailed. From gniibe at fsij.org Sat Jul 18 06:38:54 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Sat, 18 Jul 2015 13:38:54 +0900 Subject: speedo build of 2.1.6 failing on OS X In-Reply-To: <55A943BD.2010000@asatiifm.net> References: <55A943BD.2010000@asatiifm.net> Message-ID: <55A9D85E.1000602@fsij.org> On 07/18/2015 03:04 AM, Ville M??tt? wrote: > $make -f build-aux/speedo.mk native INSTALL_PREFIX=/usr/local/gnupg > CC=/usr/local/bin/gcc-5 CXX=/usr/local/bin/g++-5 [...] > Undefined symbols for architecture x86_64: > "_gettext", referenced from: I think that it is related to NLS (Natural Language support). Please see the issue: Non-NLS build broken in 2.1.6 https://bugs.gnupg.org/gnupg/issue2032 It is fixed in master branch. -- From mailing-lists at asatiifm.net Sat Jul 18 11:21:30 2015 From: mailing-lists at asatiifm.net (=?UTF-8?B?VmlsbGUgTcOkw6R0dMOk?=) Date: Sat, 18 Jul 2015 12:21:30 +0300 Subject: speedo build of 2.1.6 failing on OS X In-Reply-To: <55A9D85E.1000602@fsij.org> References: <55A943BD.2010000@asatiifm.net> <55A9D85E.1000602@fsij.org> Message-ID: <55AA1A9A.3010104@asatiifm.net> On 18.07.15 07:38, NIIBE Yutaka wrote: > On 07/18/2015 03:04 AM, Ville M??tt? wrote: >> $make -f build-aux/speedo.mk native INSTALL_PREFIX=/usr/local/gnupg >> CC=/usr/local/bin/gcc-5 CXX=/usr/local/bin/g++-5 > [...] >> Undefined symbols for architecture x86_64: >> "_gettext", referenced from: > > I think that it is related to NLS (Natural Language support). > > Please see the issue: > Non-NLS build broken in 2.1.6 > https://bugs.gnupg.org/gnupg/issue2032 > > It is fixed in master branch. > That was it. Thanks. -- Ville -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: OpenPGP digital signature URL: From pneukom at gmail.com Sat Jul 18 16:11:15 2015 From: pneukom at gmail.com (Philip Neukom) Date: Sat, 18 Jul 2015 10:11:15 -0400 Subject: Problems with key available in v1.4.19 but not v2.1.5 In-Reply-To: <55A99161.4010200@sixdemonbag.org> References: <55A95BFA.4090102@gmail.com> <55A99161.4010200@sixdemonbag.org> Message-ID: <55AA5E83.2000909@gmail.com> On 17.07.2015 19:36, Robert J. Hansen wrote: > > I'd suggest generating a new certificate -- after 20 years you're due > for one. :) > Thank you, Robert. I'll revoke the old one and create a new. I'll need to do some reading of the docs but just curious if there is there a way to move the trust rating from the old cert to the newly created one other than ask those who signed to resign? Thanks again, Philip. From pneukom at gmail.com Sat Jul 18 16:21:19 2015 From: pneukom at gmail.com (Philip Neukom) Date: Sat, 18 Jul 2015 10:21:19 -0400 Subject: [slightly off topic] e-courier.ca Message-ID: <55AA60DF.4070508@gmail.com> Hello all. Over the past couple of days I've read a discussion in my association about a "secure" email service located in Canada. I put "secure" in quotes as they talk about a "proprietary" encryption algorithm. As soon as I read "proprietary", I have to roll my eyes as I don't necessarily trust encryption if it isn't open for everyone to verify. Has anyone here tried, verified or used this service? Is this similar to what has been discussed as a potential use or service by GnuPG? The service isn't seamless but perhaps would make sense as an offering by GnuPG/Werner? Cheers! Philip. From pneukom at gmail.com Sat Jul 18 16:24:32 2015 From: pneukom at gmail.com (Philip Neukom) Date: Sat, 18 Jul 2015 10:24:32 -0400 Subject: Problems with key available in v1.4.19 but not v2.1.5 Message-ID: <55AA61A0.1020308@gmail.com> Thank you, Juan. I didn't see your helpful comments until I read the digest this morning. I appreciate everyone's help. Philip. From mlisten at hammernoch.net Sat Jul 18 17:13:02 2015 From: mlisten at hammernoch.net (=?UTF-8?B?THVkd2lnIEjDvGdlbHNjaMOkZmVy?=) Date: Sat, 18 Jul 2015 17:13:02 +0200 Subject: Problems with key available in v1.4.19 but not v2.1.5 In-Reply-To: <55AA5E83.2000909@gmail.com> References: <55A95BFA.4090102@gmail.com> <55A99161.4010200@sixdemonbag.org> <55AA5E83.2000909@gmail.com> Message-ID: <55AA6CFE.3090007@hammernoch.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 18.07.15 16:11, Philip Neukom wrote: > On 17.07.2015 19:36, Robert J. Hansen wrote: >> >> I'd suggest generating a new certificate -- after 20 years you're >> due for one. :) >> > > Thank you, Robert. I'll revoke the old one and create a new. > > I'll need to do some reading of the docs but just curious if there > is there a way to move the trust rating from the old cert to the > newly created one other than ask those who signed to resign? You can sign the new cert with your old one, but I'm not sure if that trust chain holds if you revoke your old cert. Also, more and more people will not be able to hold your old cert in their keyring when they migrate to use gpg2 modern (2.1.x). Ludwig -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJVqmz8AAoJEDrb+m0Aoeb+uBYP/00BK6CZ7sjZ8wb/K5EuntRw 50xeM1QD5a9n4CiPmOCtOF7ty4SVK36FBygNutGOQYiY6nzf5x8mlfgaHO0kdFrR +O2KcHBGlTTYpZF5u797cNAu8UVSBqsrUxAJcn/02kpvmNay+/TikOFI7EMRH9D1 gwEkqzt6hVrsT7dYNYugnY5A8zRu1Qdhixm7dWdaAaCUvqoJqtnCpnRZvasZToTF ka5NuzabVI1/gM2jPBFA3a/C41WlGlea5SnZKhYxVgNdn7DXBes0rQx0IYurumdo Hw+1qhXmWzaJIOW+/ojhklvpexsh75t44Rtjj8yCxR6HR+78JjJAqCGlUf77yGT4 dw/FE+RvwpQFvrjm2/erpqt4qRSlbYsYYGn1y6EkS4jQKmpvkBjHOuf3vIwEYe9a fGqJ8LJVo24JzLKJs+xsBLYDHNb2cunK/EV66IPiN+1YAB/9Hz/PybxT7mxKLT+/ MViYpHle9/bCwXxPLKB6qa4MqSsS4GniCsaxZ95/7ZAUNhITSGPfdkU575mXWGmt 4LRmRo/oXXCdlkYJR1U25FLA8KnfcRYOyqfA716kvCpcwvR/sbtd40aXsddsAp1N Y+MRhhklYs5PlgE7ho4FsvuXNtZi2bo7thCV7dE/1MmRP22XVkdF6qZ492okvIuP PnlJ1PkcoW1AcqoI6uj5 =ImLA -----END PGP SIGNATURE----- From johannes at zarl.at Sat Jul 18 15:57:09 2015 From: johannes at zarl.at (Johannes Zarl-Zierl) Date: Sat, 18 Jul 2015 15:57:09 +0200 Subject: High resource usage when verifying a signature Message-ID: <1458194.WOyrjbICn1@mani> Hi, I've noticed that sometimes gpg2 will take around 1-2 minutes on my desktop PC attempting to verify an email signature. At first, I thought that maybe the increasing prevalence of really big keys would increase the computational complexity, or that the keyserver communication is taking so long, but this does not seem the case. I'm pretty sure this happens on different kinds of keys, but today I noticed it on a 1024 bit DSA key. Looking into top revealed that my email program had spawned a gpg2 process that was using 100% of a single CPU core: gpg2 --enable-special-filenames --batch --no-sk-comments --status-fd 22 --no- tty --charset utf8 --enable-progress-filter --display :0 --verify -- -&23 -&25 Opening the same email a second time happens more or less instantaneously (as far as I know, kmail does not cache the verification). Is this behaviour to be expected? Is this some computation that happens only the first time a new key is encountered? Cheers, Johannes From farhanible at gmail.com Sat Jul 18 18:58:07 2015 From: farhanible at gmail.com (F Rafi) Date: Sat, 18 Jul 2015 12:58:07 -0400 Subject: Optimal setup for corporate keys Message-ID: We exchange sensitive files with multiple corporate partners and would like to set our keys up so that a single private key compromise does not require generating new keys for all partners. 1) Should we generate separate pub / priv key pairs for all partners? 2) Generate a single pub / priv key for signing and multiple sub-keys for encryption? Thanks, Farhan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Sun Jul 19 01:42:34 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 19 Jul 2015 01:42:34 +0200 Subject: High resource usage when verifying a signature In-Reply-To: <1458194.WOyrjbICn1@mani> References: <1458194.WOyrjbICn1@mani> Message-ID: <87io9hnic5.fsf@alice.fifthhorseman.net> Hi Johannes-- On Sat 2015-07-18 15:57:09 +0200, Johannes Zarl-Zierl wrote: > I've noticed that sometimes gpg2 will take around 1-2 minutes on my desktop PC > attempting to verify an email signature. what version of gpg2 are you using? > At first, I thought that maybe the increasing prevalence of really big keys > would increase the computational complexity, or that the keyserver > communication is taking so long, but this does not seem the case. > I'm pretty sure this happens on different kinds of keys, but today I noticed > it on a 1024 bit DSA key. Looking into top revealed that my email program had > spawned a gpg2 process that was using 100% of a single CPU core: > > gpg2 --enable-special-filenames --batch --no-sk-comments --status-fd 22 --no- > tty --charset utf8 --enable-progress-filter --display :0 --verify -- -&23 -&25 > > Opening the same email a second time happens more or less instantaneously (as > far as I know, kmail does not cache the verification). > > Is this behaviour to be expected? Is this some computation that happens only > the first time a new key is encountered? I suspect what's taking a long time is an update to the trustdb. one workaround is to put no-auto-check-trustdb in ~/.gnupg/gpg.conf, and then have a nightly cronjob that runs "gpg2 --check-trustdb". --dkg From greg at turnstep.com Sat Jul 18 23:37:27 2015 From: greg at turnstep.com (Greg Sabino Mullane) Date: Sat, 18 Jul 2015 21:37:27 -0000 Subject: Optimal setup for corporate keys In-Reply-To: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > We exchange sensitive files with multiple corporate partners and would like > to set our keys up so that a single private key compromise does not require > generating new keys for all partners. > > 1) Should we generate separate pub / priv key pairs for all partners? Yes. It's best to keep everyone as separated as possible. - -- Greg Sabino Mullane greg at turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201507181736 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAlWqxs8ACgkQvJuQZxSWSsiOMgCgtd92BO8wTnevEiM2uCG5Ncrq 5cYAnjFztvCJEo39V7YWYYro+wQW7YsD =rc23 -----END PGP SIGNATURE----- From farhanible at gmail.com Sun Jul 19 03:59:53 2015 From: farhanible at gmail.com (F Rafi) Date: Sat, 18 Jul 2015 21:59:53 -0400 Subject: Optimal setup for corporate keys In-Reply-To: References: Message-ID: Thanks. Does it make sense to use a key-server? The public key will only be use by a single partner organization. We were thinking about exchanging it over e-mail. Farhan On Sat, Jul 18, 2015 at 5:37 PM, Greg Sabino Mullane wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > > > We exchange sensitive files with multiple corporate partners and would > like > > to set our keys up so that a single private key compromise does not > require > > generating new keys for all partners. > > > > 1) Should we generate separate pub / priv key pairs for all partners? > > Yes. It's best to keep everyone as separated as possible. > > - -- > Greg Sabino Mullane greg at turnstep.com > End Point Corporation http://www.endpoint.com/ > PGP Key: 0x14964AC8 201507181736 > http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 > -----BEGIN PGP SIGNATURE----- > > iEYEAREDAAYFAlWqxs8ACgkQvJuQZxSWSsiOMgCgtd92BO8wTnevEiM2uCG5Ncrq > 5cYAnjFztvCJEo39V7YWYYro+wQW7YsD > =rc23 > -----END PGP SIGNATURE----- > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From htd+ml at fritha.org Sun Jul 19 15:19:52 2015 From: htd+ml at fritha.org (Heinz Diehl) Date: Sun, 19 Jul 2015 15:19:52 +0200 Subject: Optimal setup for corporate keys In-Reply-To: References: Message-ID: <20150719131952.GA5049@fritha.org> On 19.07.2015, F Rafi wrote: > Does it make sense to use a key-server? You just answered yourself: > The public key will only be use by a single partner organization. > We were thinking about exchanging it over e-mail. So no need to upload it to a keyserver. From johannes at zarl.at Sun Jul 19 16:32:51 2015 From: johannes at zarl.at (Johannes Zarl-Zierl) Date: Sun, 19 Jul 2015 16:32:51 +0200 Subject: High resource usage when verifying a signature In-Reply-To: <87io9hnic5.fsf@alice.fifthhorseman.net> References: <1458194.WOyrjbICn1@mani> <87io9hnic5.fsf@alice.fifthhorseman.net> Message-ID: <1783120.6V1BzailzI@mani> On Sunday 19 July 2015 01:42:34 Daniel Kahn Gillmor wrote: > I suspect what's taking a long time is an update to the trustdb. one > workaround is to put no-auto-check-trustdb in ~/.gnupg/gpg.conf, and > then have a nightly cronjob that runs "gpg2 --check-trustdb". ...and sure enough "gpg2 --check-trustdb" takes around a minute, the same duration as the arbitrary lockups in kmail. Thanks again, this is very probably the cause! Cheers, Johannes From flapflap at riseup.net Sun Jul 19 19:01:37 2015 From: flapflap at riseup.net (flapflap) Date: Sun, 19 Jul 2015 17:01:37 +0000 Subject: Optimal setup for corporate keys In-Reply-To: References: Message-ID: <55ABD7F1.8010408@riseup.net> Greg Sabino Mullane: > > >> We exchange sensitive files with multiple corporate partners and would like >> to set our keys up so that a single private key compromise does not require >> generating new keys for all partners. > >> 1) Should we generate separate pub / priv key pairs for all partners? > > Yes. It's best to keep everyone as separated as possible. Probably, it is a non-issue in this specific case (you already know the files you send to your partners), but in general one (here: your partners) should not use secret keys generated by others because they are not /secret/ to oneself anymore. Simply let your partners generate their pub/sec key pairs and then exchange them. From mailing-lists at asatiifm.net Sun Jul 19 19:52:01 2015 From: mailing-lists at asatiifm.net (=?UTF-8?B?VmlsbGUgTcOkw6R0dMOk?=) Date: Sun, 19 Jul 2015 20:52:01 +0300 Subject: [slightly off topic] e-courier.ca In-Reply-To: <55AA60DF.4070508@gmail.com> References: <55AA60DF.4070508@gmail.com> Message-ID: <55ABE3C1.9070002@asatiifm.net> On 18.07.15 17:21, Philip Neukom wrote: > I put "secure" in quotes as they talk about a "proprietary" encryption > algorithm. As soon as I read "proprietary", I have to roll my eyes as I > don't necessarily trust encryption if it isn't open for everyone to verify. Pretty much. > Is this similar to what has been discussed as a potential use or service > by GnuPG? The service isn't seamless but perhaps would make sense as an > offering by GnuPG/Werner? No. There is a standard called OpenPGP already and this service is not relevant in any way. See the how it works page[1]. They can't and don't change how email, i.e. SMTP works. They just send the receiver a link to their web service and both their client and recipient use a browser to do their "emailing". The world is full of services like that. GnuPG and other OpenPGP compliant software sign and / or encrypt the /contents of email/. [1]: http://e-courier.ca/howitworks.html -- Ville -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: OpenPGP digital signature URL: From misscrissylynn at gmail.com Sun Jul 19 19:22:27 2015 From: misscrissylynn at gmail.com (Crissy Lynn) Date: Sun, 19 Jul 2015 13:22:27 -0400 Subject: High resource usage when verifying a signature In-Reply-To: <1783120.6V1BzailzI@mani> References: <1458194.WOyrjbICn1@mani> <87io9hnic5.fsf@alice.fifthhorseman.net> <1783120.6V1BzailzI@mani> Message-ID: <7397FC21-98E6-45A7-9A5B-27E16EFA4845@gmail.com> Please remove me from this mailing list. > On Jul 19, 2015, at 10:32 AM, Johannes Zarl-Zierl wrote: > >> On Sunday 19 July 2015 01:42:34 Daniel Kahn Gillmor wrote: >> I suspect what's taking a long time is an update to the trustdb. one >> workaround is to put no-auto-check-trustdb in ~/.gnupg/gpg.conf, and >> then have a nightly cronjob that runs "gpg2 --check-trustdb". > > ...and sure enough "gpg2 --check-trustdb" takes around a minute, the same > duration as the arbitrary lockups in kmail. > > Thanks again, this is very probably the cause! > > Cheers, > Johannes > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From mailing-lists at asatiifm.net Sun Jul 19 20:27:53 2015 From: mailing-lists at asatiifm.net (=?UTF-8?B?VmlsbGUgTcOkw6R0dMOk?=) Date: Sun, 19 Jul 2015 21:27:53 +0300 Subject: High resource usage when verifying a signature In-Reply-To: <7397FC21-98E6-45A7-9A5B-27E16EFA4845@gmail.com> References: <1458194.WOyrjbICn1@mani> <87io9hnic5.fsf@alice.fifthhorseman.net> <1783120.6V1BzailzI@mani> <7397FC21-98E6-45A7-9A5B-27E16EFA4845@gmail.com> Message-ID: <55ABEC29.4040208@asatiifm.net> On 19.07.15 20:22, Crissy Lynn wrote: > Please remove me from this mailing list. Please follow the link at the bottom of each list email and follow instructions. -- Ville -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Sun Jul 19 20:28:52 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 19 Jul 2015 14:28:52 -0400 Subject: High resource usage when verifying a signature In-Reply-To: <7397FC21-98E6-45A7-9A5B-27E16EFA4845@gmail.com> References: <1458194.WOyrjbICn1@mani> <87io9hnic5.fsf@alice.fifthhorseman.net> <1783120.6V1BzailzI@mani> <7397FC21-98E6-45A7-9A5B-27E16EFA4845@gmail.com> Message-ID: <55ABEC64.9080205@sixdemonbag.org> > Please remove me from this mailing list. If you visit the website listed at the bottom of each email, you'll be able to unsubscribe yourself. > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users Otherwise, you'll have to wait until a list moderator gets back. From farhanible at gmail.com Mon Jul 20 02:44:44 2015 From: farhanible at gmail.com (F Rafi) Date: Sun, 19 Jul 2015 20:44:44 -0400 Subject: Optimal setup for corporate keys In-Reply-To: <55ABD7F1.8010408@riseup.net> References: <55ABD7F1.8010408@riseup.net> Message-ID: The partners will generate their own keys so we can send them files. We're generating separate pub/priv keys for each partner to receive files from them. My question was that if we should generate separate pub/priv keys or generate subkeys under a single signing key. Looks like the consensus is that we should use entirely separate pub/priv keys. We will have decryption processes on multiple servers. So if one server happens to get compromised, I want to avoid the disruption of reaching out to 40 partners to exchange keys again. We would only reach out to the affected partners with new keys. Thanks for the input everyone! Farhan On Sun, Jul 19, 2015 at 1:01 PM, flapflap wrote: > Greg Sabino Mullane: > > > > > >> We exchange sensitive files with multiple corporate partners and would > like > >> to set our keys up so that a single private key compromise does not > require > >> generating new keys for all partners. > > > >> 1) Should we generate separate pub / priv key pairs for all partners? > > > > Yes. It's best to keep everyone as separated as possible. > > Probably, it is a non-issue in this specific case (you already know the > files you send to your partners), but in general one (here: your > partners) should not use secret keys generated by others because they > are not /secret/ to oneself anymore. > > Simply let your partners generate their pub/sec key pairs and then > exchange them. > > _______________________________________________ > 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 ndk.clanbo at gmail.com Mon Jul 20 09:12:08 2015 From: ndk.clanbo at gmail.com (NdK) Date: Mon, 20 Jul 2015 09:12:08 +0200 Subject: Optimal setup for corporate keys In-Reply-To: References: <55ABD7F1.8010408@riseup.net> Message-ID: <55AC9F48.5070702@gmail.com> Il 20/07/2015 02:44, F Rafi ha scritto: > We will have decryption processes on multiple servers. So if one server > happens to get compromised, I want to avoid the disruption of reaching > out to 40 partners to exchange keys again. We would only reach out to > the affected partners with new keys. If possible, I'd go for the HSM route (openpgp card or FST-01). This way, if a server gets compromised remotely, the attacker can not get a copy of the key (but he'll be able to use it as long as his activity on the server is not detected!). If the attacker obtains physical access to the server, you're toasted anyway. Just my .02 ... BYtE, Diego From stefaniak at gmail.com Mon Jul 20 09:37:44 2015 From: stefaniak at gmail.com (Filip Stefaniak) Date: Mon, 20 Jul 2015 09:37:44 +0200 Subject: [xkcd] Public key Message-ID: <55ACA548.2050500@gmail.com> https://xkcd.com/1553/ :) -- Filip Stefaniak Uptime: 13072 dni 8 godzin W lod?wce ma 9.6stC, na dzia?ce w sadku 18.8stC From bozho at kset.org Mon Jul 20 10:49:18 2015 From: bozho at kset.org (=?UTF-8?B?TWFya28gQm/Fvmlrb3ZpxIc=?=) Date: Mon, 20 Jul 2015 09:49:18 +0100 Subject: Optimal setup for corporate keys In-Reply-To: References: Message-ID: <55ACB60E.9030209@kset.org> On 18/07/2015 17:58, F Rafi wrote: > > We exchange sensitive files with multiple corporate partners and would like to > set our keys up so that a single private key compromise does not require > generating new keys for all partners. > > 1) Should we generate separate pub / priv key pairs for all partners? > 2) Generate a single pub / priv key for signing and multiple sub-keys for > encryption? > To add one more thing: if you wish to add comments to your partner keys in order to distinguish them easily, take a look at notations before generating keys as notations are the only way to add 'comments' to your subkeys and you have to specify them when generating a key (at least I haven't found a way to add them afterwards) -- Marko From bozho at kset.org Mon Jul 20 10:49:18 2015 From: bozho at kset.org (=?UTF-8?B?TWFya28gQm/Fvmlrb3ZpxIc=?=) Date: Mon, 20 Jul 2015 09:49:18 +0100 Subject: Optimal setup for corporate keys In-Reply-To: References: Message-ID: <55ACB60E.70808@kset.org> On 18/07/2015 17:58, F Rafi wrote: > > We exchange sensitive files with multiple corporate partners and would like to > set our keys up so that a single private key compromise does not require > generating new keys for all partners. > > 1) Should we generate separate pub / priv key pairs for all partners? > 2) Generate a single pub / priv key for signing and multiple sub-keys for > encryption? > To add one more thing: if you wish to add comments to your partner keys in order to distinguish them easily, take a look at notations before generating keys as notations are the only way to add 'comments' to your subkeys and you have to specify them when generating a key (at least I haven't found a way to add them afterwards) -- Marko From wk at gnupg.org Mon Jul 20 17:31:09 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 20 Jul 2015 17:31:09 +0200 Subject: {gnupg 2.1.6} Howto change s2k cipher from AES -> AES256? In-Reply-To: <20150712204632.4e715e85@TTM-i5.homenet> (thomas's message of "Sun, 12 Jul 2015 20:46:32 +0200") References: <20150712204632.4e715e85@TTM-i5.homenet> Message-ID: <87380ilubm.fsf@vigenere.g10code.de> On Sun, 12 Jul 2015 20:46, dieamme at googlemail.com said: > Is there a way to change the encryption-cipher for the > secret Keys in "private-keys-v1.d" ? No. There is decryption support for AES256 and we may eventually enable AES256 for encryption. Right now that is not possible because it would break too many old installations. > gpg2 --openpgp --s2k-cipher-algo AES256 --s2k-digest-algo SHA512 \ > --s2k-mode 3 --s2k-count 65000000 --edit-key Key-id With GnuPG 2.1 the s2k options are only used for --symmetric encryption. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Jul 20 17:40:45 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 20 Jul 2015 17:40:45 +0200 Subject: gpg-2.1.6 scdaemon: cannot disable OpenPGP application In-Reply-To: <55A0DAE6.7070008@fsij.org> (NIIBE Yutaka's message of "Sat, 11 Jul 2015 17:59:18 +0900") References: <559BD6D3.90704@wp.pl> <559CD8F8.5000702@fsij.org> <559CED8C.2080704@wp.pl> <559DFF0E.1060208@fsij.org> <55A0B6AD.7020900@gmail.com> <55A0DAE6.7070008@fsij.org> Message-ID: <87y4iakfb6.fsf@vigenere.g10code.de> On Sat, 11 Jul 2015 10:59, gniibe at fsij.org said: > It seems that the support of those cards (other than OpenPGP card) are > intended to be used with gpgsm (for X.509). Right. Or for SSH. For example the Belgian EID card (a pkcs#15 card) can be used for SSH. > I don't think pkcs#15 driver worked for OpenPGP since it doesn't have > READKEY method to access its public key. Actually we did the OpenPGP smardcard specification with the goal to habe one and only one smardcard application for GPG. This simplifies the code and makes it possible to test cards from other vendors. Thus if a smardcard vendors wants to support OpenPGP via GPG they need to implement the OpenPGP card specification in addition to what they already provide with their card. This can be implemented as a different view on the card's data objects and functions and would need only minimal extra code. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Jul 20 17:53:30 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 20 Jul 2015 17:53:30 +0200 Subject: gpa and gpgex in gpg 2.1.x releases for windows. In-Reply-To: (Christ Schlacta's message of "Thu, 2 Jul 2015 13:06:03 -0700") References: Message-ID: <87twsykepx.fsf@vigenere.g10code.de> On Thu, 2 Jul 2015 22:06, aarcane at aarcane.org said: > As a gpg user, I've been using the gpg 2.1.x releases for a while. as > of 2.1.1, gpg for windows included gpa and gpgex. I used them. newer > releases didn't remove these features, but didn't upgrade or include Due to a lot of changes in the GTK+ GUI toolkit each Windows installer release of 2.1 was pretty troublesome and took a lot of time. Thus I decided to drop it entirely so that we are able to a Windows release of the GnuPG core within a few hour and be confident not to introduce severe regressions. It would have been possible to keep GpgEx in the installer but without GPA or Kleopatra GpgEX is of not much use, thus it has also been dropped. The idea is to have one installer for GnuPG and crypto library code and another installers for the GUI parts. The main problem with this is that we do not have a suitable packaging system on Windows and unfortunately attempts to agree on a free software for windows packaging system have all failed. And before you ask: no, MSI does not work for us. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rjh at sixdemonbag.org Mon Jul 20 18:32:50 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 20 Jul 2015 12:32:50 -0400 Subject: gpa and gpgex in gpg 2.1.x releases for windows. In-Reply-To: <87twsykepx.fsf@vigenere.g10code.de> References: <87twsykepx.fsf@vigenere.g10code.de> Message-ID: <55AD22B2.9000508@sixdemonbag.org> > system have all failed. And before you ask: no, MSI does not work > for us. MS has committed to opening up C# and placing it entirely under a libre license, and Mono is beginning to incorporate some of MS's libre code in order to improve Mono's ability to run .NET apps. (Mono doesn't support WPF, WCF, and some other important .NET technologies.) Once Mono is able to host/run WiX, which is also libre, then there'll be a fully libre ecosystem for creating MSIs. If your objection to MSI is on purely libre grounds, this may change things. If your objection is that it's an awful packaging standard, well... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Mon Jul 20 19:01:15 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 20 Jul 2015 13:01:15 -0400 Subject: Peculiar behavior of --list-secret-keys Message-ID: <55AD295B.7040300@sixdemonbag.org> My newly-generated secret key is demonstrating some "first it's there, then it's not" behavior. Behold, it's there: [rjh at localhost ~]$ gpg --list-secret-key b44427c7 sec 3072R/1DCBDC01B44427C7 2015-07-16 uid Robert J. Hansen uid Robert J. Hansen ssb 3072R/DC0F82625FA6AADE 2015-07-16 Behold, it's not: [rjh at localhost ~]$ gpg2 --list-secret-keys /home/rjh/.gnupg/pubring.kbx ---------------------------- sec rsa2048/B700F482FEAF8109 2005-02-22 [revoked: 2009-03-17] uid [ revoked] Robert J. Hansen uid [ revoked] Robert J. Hansen sec dsa2048/23806BE5D6B98E10 2008-07-30 uid [ unknown] Robert J. Hansen uid [ unknown] Robert J. Hansen uid [ unknown] Robert J. Hansen uid [ unknown] Robert J. Hansen uid [ unknown] [jpeg image of size 14285] ssb elg2048/B8A6B74C001892C2 2008-07-30 ssb rsa2048/446A446F810DB5D0 2013-03-14 Also, GnuPG seems to have lost track of the fact that D6B98E10 is an ultimately-trusted key. From rjh at sixdemonbag.org Mon Jul 20 19:02:46 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 20 Jul 2015 13:02:46 -0400 Subject: Peculiar behavior of --list-secret-keys In-Reply-To: <55AD295B.7040300@sixdemonbag.org> References: <55AD295B.7040300@sixdemonbag.org> Message-ID: <55AD29B6.8060005@sixdemonbag.org> Also, why is it trying to read secret keys from my public keybox? See below. > [rjh at localhost ~]$ gpg2 --list-secret-keys > /home/rjh/.gnupg/pubring.kbx From rjh at sixdemonbag.org Mon Jul 20 19:33:55 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 20 Jul 2015 13:33:55 -0400 Subject: Really weird behavior with fresh install Message-ID: <55AD3103.808@sixdemonbag.org> So, in the interests of further checking this out, I figured I'd start from a fresh slate: [rjh at localhost ~]$ rm -rf .gnupg [rjh at localhost ~]$ gpg gpg: directory `/home/rjh/.gnupg' created gpg: new configuration file `/home/rjh/.gnupg/gpg.conf' created gpg: WARNING: options in `/home/rjh/.gnupg/gpg.conf' are not ... gpg: keyring `/home/rjh/.gnupg/secring.gpg' created gpg: keyring `/home/rjh/.gnupg/pubring.gpg' created gpg: Go ahead and type your message ... ^C gpg: Interrupt caught ... exiting I verified the directory was clean: [rjh at localhost ~]$ ls -l .gnupg/ total 12 -rw-------. 1 rjh rjh 9188 Jul 20 13:18 gpg.conf -rw-------. 1 rjh rjh 0 Jul 20 13:18 pubring.gpg -rw-------. 1 rjh rjh 0 Jul 20 13:18 secring.gpg Let's verify gpg-agent is gone: [rjh at localhost ~]$ killall gpg-agent gpg-agent: no process found [rjh at localhost ~]$ ps ax|grep gpg 45613 pts/0 S+ 0:00 grep --color=auto gpg Then, when Enigmail tried to get a key list, this happened: enigmail> /usr/bin/gpg2 --charset utf-8 --display-charset utf-8 --batch --no-tty --status-fd 2 --fixed-list-mode --with-colons --list-keys gpg: error reading key: Invalid user ID Let's verify there are no user IDs, so ergo there can't be an error related to an invalid key ID: [rjh at localhost ~]$ ls -l .gnupg/ total 16 -rw-------. 1 rjh rjh 9188 Jul 20 13:25 gpg.conf -rw-------. 1 rjh rjh 0 Jul 20 13:25 pubring.gpg -rw-------. 1 rjh rjh 0 Jul 20 13:25 secring.gpg -rw-------. 1 rjh rjh 40 Jul 20 13:30 trustdb.gpg And finally, let's run Enigmail's same command line: [rjh at localhost ~]$ /usr/bin/gpg2 --charset utf-8 --display-charset utf-8 --batch --no-tty --status-fd 2 --fixed-list-mode --with-colons --list-keys tru::1:1437413421:0:3:1:5 ... No error. This is very, very weird. Does anyone have any thoughts? From juanmi.3000 at gmail.com Mon Jul 20 20:23:39 2015 From: juanmi.3000 at gmail.com (=?UTF-8?Q?Juan_Miguel_Navarro_Mart=c3=adnez?=) Date: Mon, 20 Jul 2015 20:23:39 +0200 Subject: Peculiar behavior of --list-secret-keys In-Reply-To: <55AD29B6.8060005@sixdemonbag.org> References: <55AD295B.7040300@sixdemonbag.org> <55AD29B6.8060005@sixdemonbag.org> Message-ID: <55AD3CAB.9050708@gmail.com> You are using GnuPG 1.x and GnuPG 2.1.x, they use different keyring locations for storing public and secret keys. The only time when GnuPG 2.1.x uses "pubring.gpg" instead of "pubring.kbx" is when it detects public keys on pubring.gpg before installing it. So now you have GnuPG 1.x using pubring.gpg and secring.gpg and GnuPG 2.1.x using pubring.kbx and private-keys-v1.d folder. Every keys you import or make in GnuPG 1.x won't appear in GnuPG 2.1.x and vice versa, you'll have to use --import and --export on both versions to sync the keyrings. As to way GnuPG 2.1.x is looking at pubring.kbx, I don't know. I suppose you made a secret key with GnuPG 2.1? On 2015/07/20 at 19:02, Robert J. Hansen wrote: > Also, why is it trying to read secret keys from my public keybox? See > below. > >> [rjh at localhost ~]$ gpg2 --list-secret-keys >> /home/rjh/.gnupg/pubring.kbx > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- Juan Miguel Navarro Mart?nez GPG Keyfingerprint: 5A91 90D4 CF27 9D52 D62A BC58 88E2 947F 9BC6 B3CF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Mon Jul 20 20:24:44 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 20 Jul 2015 20:24:44 +0200 Subject: gpa and gpgex in gpg 2.1.x releases for windows. In-Reply-To: <55AD22B2.9000508@sixdemonbag.org> (Robert J. Hansen's message of "Mon, 20 Jul 2015 12:32:50 -0400") References: <87twsykepx.fsf@vigenere.g10code.de> <55AD22B2.9000508@sixdemonbag.org> Message-ID: <877fpuk7pv.fsf@vigenere.g10code.de> On Mon, 20 Jul 2015 18:32, rjh at sixdemonbag.org said: > If your objection to MSI is on purely libre grounds, this may change > things. If your objection is that it's an awful packaging standard, well... Neither of them. MSI is a very good packaging system but to make good use of it you need to use it in a fine-grained manner and not just with huge packages. For example the current 2.1.x installer would need to be split up in maybe a dozen separate MSI files much like it is done in Linux distributions. The main work will then be to maintain the dependencies. We can easily do that for most parts of GnuPG but there are external packages which should be shared with other applications (think: zlib) and this raises the question who will be responsible for this. Windows\Debian, or Windows\Fedora, or Windows\Gentoo, etc .... Without that we won't have a package management system but several of them and don't get rid of all the ugly hacks and annoyances. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From juanmi.3000 at gmail.com Mon Jul 20 20:31:18 2015 From: juanmi.3000 at gmail.com (=?UTF-8?Q?Juan_Miguel_Navarro_Mart=c3=adnez?=) Date: Mon, 20 Jul 2015 20:31:18 +0200 Subject: High resource usage when verifying a signature In-Reply-To: <7397FC21-98E6-45A7-9A5B-27E16EFA4845@gmail.com> References: <1458194.WOyrjbICn1@mani> <87io9hnic5.fsf@alice.fifthhorseman.net> <1783120.6V1BzailzI@mani> <7397FC21-98E6-45A7-9A5B-27E16EFA4845@gmail.com> Message-ID: <55AD3E76.4040605@gmail.com> Send a mail to gnupg-users-request at gnupg.org with "unsubscribe " in the subject or body. On 2015/07/19 at 19:22, Crissy Lynn wrote: > Please remove me from this mailing list. > -- Juan Miguel Navarro Mart?nez GPG Keyfingerprint: 5A91 90D4 CF27 9D52 D62A BC58 88E2 947F 9BC6 B3CF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Mon Jul 20 20:32:00 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 20 Jul 2015 14:32:00 -0400 Subject: Peculiar behavior of --list-secret-keys In-Reply-To: <55AD3CAB.9050708@gmail.com> References: <55AD295B.7040300@sixdemonbag.org> <55AD29B6.8060005@sixdemonbag.org> <55AD3CAB.9050708@gmail.com> Message-ID: <55AD3EA0.1080202@sixdemonbag.org> > You are using GnuPG 1.x and GnuPG 2.1.x, they use different keyring > locations for storing public and secret keys. Yeah, that was my bad; I forgot Fedora ships with both 2.1 and 1.4. However, weirdness persists. From wk at gnupg.org Mon Jul 20 20:37:00 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 20 Jul 2015 20:37:00 +0200 Subject: Peculiar behavior of --list-secret-keys In-Reply-To: <55AD295B.7040300@sixdemonbag.org> (Robert J. Hansen's message of "Mon, 20 Jul 2015 13:01:15 -0400") References: <55AD295B.7040300@sixdemonbag.org> Message-ID: <87380ik75f.fsf@vigenere.g10code.de> On Mon, 20 Jul 2015 19:01, rjh at sixdemonbag.org said: > [rjh at localhost ~]$ gpg --list-secret-key b44427c7 > sec 3072R/1DCBDC01B44427C7 2015-07-16 > uid Robert J. Hansen You created it with gpg 1.x or 2.0 and thus they are stored in pubring.gpg . > [rjh at localhost ~]$ gpg2 --list-secret-keys > /home/rjh/.gnupg/pubring.kbx and here you are using 2.1 which uses pubring.kbx. As soon as there is a single OpenPGP key in pubring.kbx (maybe due to gpg2.1 --import) gpg2.1 will use pubring.kbx and ignore an existing pubring.gpg. Note that the presence of a pubring.kbx is not sufficient to let gpg2.1 use it becuase a file with that name has always been used by gpgsm. To check whether an OpenPGP key is in a pubring.kbx run $ kbxutil ~/.gnupg/pubring.kbx | head BEGIN-RECORD: 0 Length: 32 Type: Header Version: 1 Flags: 0002 (openpgp) [...] and check that the openpgp flag is there (very recent file(1) versions should also be able to tell you this). > Also, GnuPG seems to have lost track of the fact that D6B98E10 is an > ultimately-trusted key. This is a separate issue; iirc we have/had this in the tracker. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Jul 20 20:38:10 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 20 Jul 2015 20:38:10 +0200 Subject: Peculiar behavior of --list-secret-keys In-Reply-To: <55AD29B6.8060005@sixdemonbag.org> (Robert J. Hansen's message of "Mon, 20 Jul 2015 13:02:46 -0400") References: <55AD295B.7040300@sixdemonbag.org> <55AD29B6.8060005@sixdemonbag.org> Message-ID: <87y4iaisj1.fsf@vigenere.g10code.de> On Mon, 20 Jul 2015 19:02, rjh at sixdemonbag.org said: > Also, why is it trying to read secret keys from my public keybox? See > below. > >> [rjh at localhost ~]$ gpg2 --list-secret-keys >> /home/rjh/.gnupg/pubring.kbx --list-secret-key is actually --list-keys with a filter to check whether the agent has a corresponding secret key. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Jul 20 20:47:07 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 20 Jul 2015 20:47:07 +0200 Subject: Really weird behavior with fresh install In-Reply-To: <55AD3103.808@sixdemonbag.org> (Robert J. Hansen's message of "Mon, 20 Jul 2015 13:33:55 -0400") References: <55AD3103.808@sixdemonbag.org> Message-ID: <87twsyis44.fsf@vigenere.g10code.de> On Mon, 20 Jul 2015 19:33, rjh at sixdemonbag.org said: > So, in the interests of further checking this out, I figured I'd start > from a fresh slate: gpg --version ? gpg2 --version ? > [rjh at localhost ~]$ killall gpg-agent > gpg-agent: no process found [Better use /pkill/ than /killall/ so that the next time you sit at a Solaris console you won't be responsible for halting the box] > Then, when Enigmail tried to get a key list, this happened: > > enigmail> /usr/bin/gpg2 --charset utf-8 --display-charset utf-8 > --batch --no-tty --status-fd 2 --fixed-list-mode > --with-colons --list-keys > gpg: error reading key: Invalid user ID I think we recently fixed that. The wrong error messages is due to the missing trustdb.gpg. > [rjh at localhost ~]$ ls -l .gnupg/ > total 16 > -rw-------. 1 rjh rjh 9188 Jul 20 13:25 gpg.conf > -rw-------. 1 rjh rjh 0 Jul 20 13:25 pubring.gpg > -rw-------. 1 rjh rjh 0 Jul 20 13:25 secring.gpg > -rw-------. 1 rjh rjh 40 Jul 20 13:30 trustdb.gpg which fortunately has been created now and thus > And finally, let's run Enigmail's same command line: works. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dan+mozilla at pasteur.fr Tue Jul 21 10:29:42 2015 From: dan+mozilla at pasteur.fr (daniel Azuelos) Date: Tue, 21 Jul 2015 10:29:42 +0200 Subject: [Enigmail] Really weird behavior with fresh install In-Reply-To: <55AD3103.808@sixdemonbag.org> References: <55AD3103.808@sixdemonbag.org> Message-ID: <20150721082942.GA70098@pasteur.fr> Robert J. Hansen ?crivait (wrote) : [...] | And finally, let's run Enigmail's same command line: | | [rjh at localhost ~]$ /usr/bin/gpg2 --charset utf-8 | --display-charset utf-8 --batch --no-tty | --status-fd 2 --fixed-list-mode --with-colons | --list-keys | tru::1:1437413421:0:3:1:5 [...] echo $? just after /usr/bin/gpg2 may help. -- This E-mail is safe : it isn't using HTML. Use of HTML - within E-mail - is the main contributing factor of the worldwide phishing attacks outburst. -------- daniel Azuelos R.S.S.I. - C.I.S.O. - Institut Pasteur From jankow at datenkollektiv.net Tue Jul 21 11:59:39 2015 From: jankow at datenkollektiv.net (Jan Kowalsky) Date: Tue, 21 Jul 2015 11:59:39 +0200 Subject: reencrypt emails with another user id Message-ID: <55AE180B.80306@datenkollektiv.net> Hi all, maybe a little bit o.t. but I'm looking for the possibility to reencrypt messages inside an imap folder. My situation: I have some emails encrypted with an uid stored on imap and I wan't to reencrypt them with another UID. (The reason: It's encrypted with a uid which resides only on a card - and I wan't to save the mails for secure access in the future if the card get lost). Anybody has an Idea? I looked around and found this tool so far: http://chrislee.dhs.org/projects/imapcrypt.html which is only for encrypting - not for decrypting and reencrypting. Thanks in advance and kind regards Jan From bob.henson at galen.org.uk Tue Jul 21 17:12:26 2015 From: bob.henson at galen.org.uk (Bob Henson) Date: Tue, 21 Jul 2015 16:12:26 +0100 Subject: GnuPG 2.1 Message-ID: <55AE615A.40207@galen.org.uk> I'm not sure whether I should be asking in here or in the Enigmail group, so I'm trying here first - please refer me to the other group if it is more appropriate. I've just changed over to GnuPG 2.1.x and have been trying out an ECC key too. By and large, it all seems to work well (signatures verify, and encryption/unencryption works fine too) , but whilst sending test messages back and forth to myself using new and old keys for signing and encryption I noticed a couple of odd things, and it would be useful to know if they are related to GnuPG 2.1.x, or Enigmail (or even the ECC key - although that isn't likely). I'm using PGP/MIME for all messages. The first problem is trivial - if I send an HTML message, the signature verifies correctly, but the body of the message vanishes without trace - nothing at all shows up when trying to read the received message. There's an easy answer, I know - don't use HTML. I'm quite happy to do that, but I'm old and I forget :-( The second is a bit of a problem and will look odd if it happens when I send mail to others. Signing a message with either my old key or the new ECC key, and sending it to myself encrypted to both keys results in no problems with the signature or decryption, and the message appears OK. Above, and as part of, the message text, appear two of the message headers:- Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable This would look a bit odd to another recipient - albeit they don't prevent the rest of the message from being read. Why am I asking in here - well it didn't happen with the same versions of Thunderbird/Enigmail and GnuPG 2.0.x . That doesn't mean it isn't an Enigmail thing, of course, and I'm hoping you'll be able to tell me which it is. Please feel free to laugh out loud if I'm missing something stupidly obvious - I did tell you I was old :-) Regards, Bob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 538 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Tue Jul 21 19:31:09 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 21 Jul 2015 13:31:09 -0400 Subject: GnuPG 2.1 In-Reply-To: <55AE615A.40207@galen.org.uk> References: <55AE615A.40207@galen.org.uk> Message-ID: <55AE81DD.7020406@sixdemonbag.org> > Please feel free to laugh out loud if I'm missing something stupidly > obvious - I did tell you I was old :-) Nonsense: good questions deserve good answers. :) > I'm not sure whether I should be asking in here or in the Enigmail > group, so I'm trying here first - please refer me to the other group > if it is more appropriate. It's a little of both, actually. You may want to ask again on Enigmail, although you'll likely get a lot of the same answers from a lot of the same people (myself included). > I've just changed over to GnuPG 2.1.x and have been trying out an > ECC key too. Right now, I wouldn't recommend ECC for production use. We're still getting the kinks worked out of it, and it isn't beyond the realm of possibility to think we might see significant changes by GnuPG 2.2. That said, if your purpose is edification and education, go for it! :) > The first problem is trivial - if I send an HTML message, the > signature verifies correctly, but the body of the message vanishes > without trace - nothing at all shows up when trying to read the > received message. There's an easy answer, I know - don't use HTML. The easy answer is also the wrong one. This appears to be a serious usability bug, and we very much want to fix those! Could you please do the following? 1. Write a short message in HTML. (Just "Hello, world!" will do.) 2. Send it to me, *off-list*. 3. Write the exact same short message in a new email. 4. Sign it using PGP/MIME and send it to me *off-list*. I'll take a look at it. If I can't see the problem, I'll kick it over to Patrick and Nicolai for some in-depth debugging. > Above, and as part of, the message text, appear two of the message > headers:- This is a known issue. Enigmail expects GnuPG to behave in a certain way, and since 2.1 GnuPG acts just slightly different than what we expect. Getting this fixed is on our to-do list. :) From tejas.chaudhari at cedge.in Tue Jul 21 11:25:52 2015 From: tejas.chaudhari at cedge.in (Tejas) Date: Tue, 21 Jul 2015 14:55:52 +0530 Subject: gen--key not working for non root users Message-ID: <031001d0c397$3d1c7ea0$b7557be0$@chaudhari@cedge.in> Hi , Gnupg not able to generate keys for non-root user . $ gpg2 --version gpg (GnuPG) 2.0.22 libgcrypt 1.6.3 Copyright (C) 2013 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, RSA, RSA, ELG, DSA, ECC, ? Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 You need a Passphrase to protect your secret key. Warning: using insecure memory! Afetr this the passphrase prompt doesnt prompt me for password ?? It acually just keeps on running forever like ; ----------------------------------------------------? ? Enter passphrase ? ? ? ? ? ? Passphrase *************************************___ ? ? ? ? For root user its absolsutely fine . Thanks & Regards, Tejas Chaudhari Assistant Consultant C-Edge Technologies Ltd 9th Floor,A Wing Lodha i-Think Techno Campus Pokharan Road No.2 Off. Eastern Express Highway Thane (West) - 400 607 Mobile : 9870282371 Mail to :tejas.chaudhari at cedge.in Website: www.cedge.in This communication (including any accompanying documents / attachments) is intended only for the use of the addressee(s) and contains information that is PRIVILEGED AND CONFIDENTIAL. If you are not the intended recipient, you are notified that any dissemination and/or copying of this e-mail is Strictly prohibited and you are requested to delete this e-mail immediately. Communicating through e-mail is not secure and capable of interception & delays. Any one communicating with C-Edge Technologies Limited by e-mail accepts the risks involved and their consequences. While this e-mail has been checked for all known viruses, the addressee should also scan for viruses and notify the originator.If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you for your co-operation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vedaal at nym.hush.com Tue Jul 21 23:36:45 2015 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Tue, 21 Jul 2015 17:36:45 -0400 Subject: [openpgp] Unuploadable Keys In-Reply-To: <87615dkygj.fsf@alice.fifthhorseman.net> References: <87a8uxlcvz.wl-neal@walfield.org> <87615dkygj.fsf@alice.fifthhorseman.net> Message-ID: <20150721213645.979D941F12@smtp.hushmail.com> On 7/21/2015 at 5:11 PM, "Daniel Kahn Gillmor" wrote: >> Concretely, it should be possible to mark a key as not >exportable to a >> keyserver or to provide a list of key servers (perhaps described >using >> regular expressions as per Section 8 of RFC 4880) to which it >may be >> exported. >> >> This could be implemented as a new signature subpacket. ..... > >However, this arrangement (or your signature subpacket proposal) >has a >set of problems that make it far from ideal protection, especially >in >the face of potentially adversarial users: > > 0) Any existing key (one with a self-sig that does *not* have this > feature set) can't add this feature in a reliable way -- a new > self-sig can just be stripped out of the certificate and the > remaining certificate (with the previous self-sig) will be >back to > being "exportable". > > 1) The keyservers would need to respect the value and decline to >accept > or propagate such keys. SKS currently doesn't even respect the > non-exportable flag for non-self-sigs > (https://bitbucket.org/skskeyserver/sks-keyserver/pull- >request/20), > let alone verify the cryptographic validity of signatures. ===== There could be a workaround, where the key is uploaded to the keyservers, but functionally unusable except to individuals whom the key-creator wants to use it: [1] Encrypt part of the public key symmetrically, the same way that the private key is symmetrically encrypted. [2] Send the passphrase to whomever you want to send the public key, encrypted to their public key. [3] Upload the key to keyservers. It will be usable only by those whom you choose to give the passphrase. (* Unless* you misjudged someone to whom you sent the passphrase, and he turns maliciously on you, and uploads the decrypted form .... ) If such a key-type were implemented, would it need a change in 4880, other than a notice to allow it? vedaal From dkg at fifthhorseman.net Wed Jul 22 11:46:44 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 22 Jul 2015 11:46:44 +0200 Subject: [openpgp] Unuploadable Keys In-Reply-To: <20150721213645.979D941F12@smtp.hushmail.com> References: <87a8uxlcvz.wl-neal@walfield.org> <87615dkygj.fsf@alice.fifthhorseman.net> <20150721213645.979D941F12@smtp.hushmail.com> Message-ID: <87615cjzi3.fsf@alice.fifthhorseman.net> On Tue 2015-07-21 23:36:45 +0200, vedaal at nym.hush.com wrote: > There could be a workaround, where the key is uploaded to the keyservers, > but functionally unusable except to individuals whom the key-creator wants to use it: > > [1] Encrypt part of the public key symmetrically, the same way that the private key is symmetrically encrypted. > > [2] Send the passphrase to whomever you want to send the public key, encrypted to their public key. > > [3] Upload the key to keyservers. It will be usable only by those whom you choose to give the passphrase. > > (* Unless* you misjudged someone to whom you sent the passphrase, and he turns maliciously on you, and uploads the decrypted form .... ) > > If such a key-type were implemented, would it need a change in 4880, other than a notice to allow it? if we were to have a cryptographically-validating keyserver, there's no way that the certificate could be verified. I'm not clear what the use case for this is. people who "want their public key to be not-public" probably actually care more about: * avoiding publication of their User ID, and * avoiding publication of a persistent identifier that can link communications together both of these things would probably fail if the key (even obscured) was published to the public key servers. I don't see how this proposal solves the identified concern (though it's possible that i'm misunderstanding the identified concern). --dkg From flapflap at riseup.net Wed Jul 22 16:36:22 2015 From: flapflap at riseup.net (flapflap) Date: Wed, 22 Jul 2015 14:36:22 +0000 Subject: no valid user IDs after changing key expiration time Message-ID: <55AFAA66.9080508@riseup.net> Hi list, I have a key for some years which did not have an expiration time. Now, I finally want to change this and changed the expiration time (via --edit-key then expire, save). To test if everything is now working as it should, I exported the keys (--export, --export-secret-keys), deleted the key from my keyring (--delete-secret-keys, --delete-keys). Afterwards, I imported my public key and the output is fine. But when I import the secret key gpg says: gpg: key $MYKEY: secret key imported gpg: key $MYKEY: no valid user IDs gpg: this may be caused by a missing self-signature gpg: Total number processed: 1 gpg: w/o user IDs: 1 gpg: secret keys read: 1 gpg: secret keys imported: 1 So, it says "no valid user IDs". However, --list-keys and --list-secret-keys both show my UIDs. Should I be worried by the warning or is this normal behaviour? (GnuPG version is 2.0.25 and libgcrypt is 1.5.0) Thanks in advance, ~flapflap From wk at gnupg.org Wed Jul 22 16:48:15 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 22 Jul 2015 16:48:15 +0200 Subject: GnuPG 2.1 In-Reply-To: <55AE81DD.7020406@sixdemonbag.org> (Robert J. Hansen's message of "Tue, 21 Jul 2015 13:31:09 -0400") References: <55AE615A.40207@galen.org.uk> <55AE81DD.7020406@sixdemonbag.org> Message-ID: <871tg0dz9s.fsf@vigenere.g10code.de> On Tue, 21 Jul 2015 19:31, rjh at sixdemonbag.org said: > Right now, I wouldn't recommend ECC for production use. We're still > getting the kinks worked out of it, and it isn't beyond the realm of > possibility to think we might see significant changes by GnuPG 2.2. Nope, you won't see changes here - at least not for the standard NIST or Brainpool curves. The problem with ECC is that the software supporting ECC is not not yet widely deployed and thus people either can't verify your messages or not send you encrypted messages. This is also the reason why ECC requires the --expert option. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mlisten at hammernoch.net Wed Jul 22 16:49:40 2015 From: mlisten at hammernoch.net (=?UTF-8?B?THVkd2lnIEjDvGdlbHNjaMOkZmVy?=) Date: Wed, 22 Jul 2015 16:49:40 +0200 Subject: no valid user IDs after changing key expiration time In-Reply-To: <55AFAA66.9080508@riseup.net> References: <55AFAA66.9080508@riseup.net> Message-ID: <55AFAD84.4070306@hammernoch.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 22.07.15 16:36, flapflap wrote: > Should I be worried by the warning or is this normal behaviour? You should set ultimate ownertrust on your own key after (re-)importing. Then it will become valid again. Ludwig -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJVr62DAAoJEDrb+m0Aoeb+SEgP/1PwV9FXKBD+J6tWPcmJFWXl dQU5swWU4TsZgqPRdfspalexjDWUlntO5a+TQzVuF6eCLSuu7XaqMCMQ02cmgUXM SkOAWi+IKJhqDbWJhfX/7XiN5EpQOu7fcIXujNBGaPPbr4k3cga2/DTghhlcQx8F Lqo/fvttrWGSaeJYjv82KFx65Oauf6wyjaalxygr2IMRtUV17g9zmZJr/Xgo8Rbu NPx9a+GnnpgNyT6N0fAPE6PjGQKX/T/dk5nLF4k6wwQEHmRKVNdOyqrkARAOtH8S 4h9cie8YqPOB1UfrXhQENX2xnkMfu/VRm67Of12Gx6ACrO/VMY83zK+vbmF+DMxb OddRLi/aK4CeZGgr7mn0/eYShOx8B47o3eUKhbJUPhXOz2iARSRB6uAKbz2wqjo1 PUgZyR86lNpeKYOscFMSiF+/aqT5fZgBEhdoLfK/zi2VYR1Jlpgf2Ps3E8kJwlS/ uqb4xzSkjNJqlQOW8nkE3GTK3I695s2uxG0IkDfj9ekM9n+yDV5gnXP9WDJY6nc6 SD96abtNeZVCEcry0m/LWnRUnE9dqm3t7sMxAodMJVbd68/SRpkcSwadoKKpzpfp F3uPJKj26HBZtsJzcoZYNKqinJDYm7rw8h8n9HXXFKc9W2kFK4QJmdSoxp0VmxnN 6HlI9gD9sEcfkT8Ds+Fq =XoBt -----END PGP SIGNATURE----- From flapflap at riseup.net Wed Jul 22 19:05:04 2015 From: flapflap at riseup.net (flapflap) Date: Wed, 22 Jul 2015 17:05:04 +0000 Subject: no valid user IDs after changing key expiration time In-Reply-To: <55AFAD84.4070306@hammernoch.net> References: <55AFAA66.9080508@riseup.net> <55AFAD84.4070306@hammernoch.net> Message-ID: <55AFCD40.3070006@riseup.net> Ludwig H?gelsch?fer: > On 22.07.15 16:36, flapflap wrote: > >> Should I be worried by the warning or is this normal behaviour? > > You should set ultimate ownertrust on your own key after > (re-)importing. Then it will become valid again. My key still looked/looks valid, even without changing the ownertrust (in that case its ownertrust is just shown as unknown). All UIDs are present. What seems strange to me is that I do not see the warning message when I import the previous version of my key (exported about a year ago). The warning only appears when I change the expiration time of that key, export it, delete it, and then re-import it (including secret key). ~flapflap From 2014-667rhzu3dc-lists-groups at riseup.net Thu Jul 23 00:23:30 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Wed, 22 Jul 2015 23:23:30 +0100 Subject: [openpgp] Unuploadable Keys In-Reply-To: <20150721213645.979D941F12@smtp.hushmail.com> References: <87a8uxlcvz.wl-neal@walfield.org> <87615dkygj.fsf@alice.fifthhorseman.net> <20150721213645.979D941F12@smtp.hushmail.com> Message-ID: <145285802.20150722232330@my_localhost> Hi On Tuesday 21 July 2015 at 10:36:45 PM, in , vedaal at nym.hush.com wrote: > (* Unless* you misjudged someone to whom you sent the > passphrase, and he turns maliciously on you, and > uploads the decrypted form .... It could easily be accidental rather than malicious. -- Best regards MFPA Coffee doesn't need a menu, it needs a cup. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 841 bytes Desc: not available URL: From 2014-667rhzu3dc-lists-groups at riseup.net Thu Jul 23 01:15:13 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Thu, 23 Jul 2015 00:15:13 +0100 Subject: GnuPG 2.1 In-Reply-To: <871tg0dz9s.fsf@vigenere.g10code.de> References: <55AE615A.40207@galen.org.uk> <55AE81DD.7020406@sixdemonbag.org> <871tg0dz9s.fsf@vigenere.g10code.de> Message-ID: <1889314552.20150723001513@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Wednesday 22 July 2015 at 3:48:15 PM, in , Werner Koch wrote: > Nope, you won't see changes here - at least not for the > standard NIST or Brainpool curves. Is the format for encryption keys using Curve 25519 finalised/implemented yet? - -- Best regards MFPA Ballerinas are always on their toes. We need taller ballerinas! -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJVsCQMXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXw4TwH/1otuYBgAPZtKAKWv3hoJgXe ItJvVGR3V747X20PK0FY8ZYPv4sFP/txgCjdd5fydlmmo/jnpuONlwSTyhpzoBHu 5nRd75v9+7UEgPdck31jmRqxoS5wdubz92YtD1HCDP8//5iUM9avyDD4oUJZZf7U 1HdGXEID4w7TeziIIqy/C3Mvka99qKaaPelkrAzvxgxP9xDJJoKhDXZDunX7cB45 eR8yDFDqezAchNc4TYe88sbxVF470Kcv2K2qNJwzdrTVz5bX8JFX4yDpICeN8gXP ZnW5cBQgxRsQC48pykr3HvxsQOdhGgBwqF7kJuSPrW+Tk76mwzyjnlirfCMR8RyI vgQBFgoAZgUCVbAkEl8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45AvqAQCefexf2zbT+6iUir9WolI6rDgn 4gOZPQD4xgc1KKbuWQD9Eo7zEsbjfpRqPV3eUt8E/Pbvq9i9KH3d57BSDEnw8gE= =bQVB -----END PGP SIGNATURE----- From bozho at kset.org Thu Jul 23 16:30:27 2015 From: bozho at kset.org (=?UTF-8?B?TWFya28gQm/Fvmlrb3ZpxIc=?=) Date: Thu, 23 Jul 2015 15:30:27 +0100 Subject: gpg 2.1.6 toggle doesn't Message-ID: <55B0FA83.20506@kset.org> Hi all, I've just noticed that the 'toggle' command in gpg 2.1.5/6 on Windows doesn't switch key display. It still seems to switch the keys, since I moved my authentication private key to a smartcard successfully. Thank you, -- Marko From jimmy.thrasibule at gmail.com Thu Jul 23 17:14:11 2015 From: jimmy.thrasibule at gmail.com (Jimmy Thrasibule) Date: Thu, 23 Jul 2015 17:14:11 +0200 Subject: Pinentry fails with gpg-agent and SSH Message-ID: Hello, I'm running Fedora 22. I'm trying to setup GnuPG to have my SSH connections authenticated using my PGP authentication subkey that is located on my Yubikey Neo. I have a systemd unit starting the gpg-agent as following: /usr/bin/gpg-agent --homedir=%h/.gnupg --daemon --use-standard-socket And I have enabled SSH support in the configuration: enable-ssh-support pinentry-program /usr/bin/pinentry-gtk Other parts of the setup include adding the [keygrip][1] of my key to the ~/.gnupg/sshcontrol file, adding my [public key][2] to the remote host and declaring the [environment variables][3]. Globally looking at the various logs the setup wants to work, I can see that SSH is finding the key but actually failing to sign with it. If I look at the logs from gpg-agent, I can see that it is failing to launch the pinentry program and therefore, no requesting for the PIN code: 2015-07-22 23:23:28 gpg-agent[6758] DBG: error calling pinentry: Ioctl() inappropriate for a device 2015-07-22 23:23:28 gpg-agent[6758] DBG: chan_8 -> BYE 2015-07-22 23:23:28 gpg-agent[6758] DBG: chan_7 -> CAN 2015-07-22 23:23:28 gpg-agent[6758] DBG: chan_7 <- ERR 100663573 The IPC call was canceled 2015-07-22 23:23:28 gpg-agent[6758] smartcard signing failed: Ioctl() inappropriate for a device 2015-07-22 23:23:28 gpg-agent[6758] ssh sign request failed: Ioctl() inappropriate for a device What we see here is that when used in combination with SSH, some ioctl call is failing while calling pinentry. However if I run the following: $ echo "Test" | gpg2 -s The PIN window is popping up and it's all working fine. Can you help me understand what's going on with this setup and SSH? [1]: https://lists.gnupg.org/pipermail/gnupg-users/2012-July/045059.html [2]: https://lists.gnupg.org/pipermail/gnupg-users/2012-July/045115.html [3]: https://www.gnupg.org/documentation/manuals/gnupg/Agent-Examples.html#Agent-Examples From carterdh7978 at bellsouth.net Thu Jul 23 17:04:16 2015 From: carterdh7978 at bellsouth.net (David Carter) Date: Thu, 23 Jul 2015 15:04:16 +0000 (UTC) Subject: Gnupg Decryption Question Message-ID: <1054550372.1104729.1437663856096.JavaMail.yahoo@mail.yahoo.com> Hello, We currently use Gnupg 1.4.10 as part of our interactions with an online mailbox system. We are able to successfully encrypt our data files but we haven't been able to find the combination of options that will let us decrypt files that we receive - so we've used a different product for that purpose.? Our desire is to use only one product to perform both encryption and decryption. This is a sample of how we would call gpg to encrypt a text file prior to transmission: gpg -c -o DataFile.gpg --batch --compress-algo 1 --cipher-algo cast5 --passphrase KeyValue DataFile.txt The files that we receive share the same KeyValue, so we would appreciate some guidance on undoing what was done above. Thanks very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carterdh7978 at bellsouth.net Thu Jul 23 16:47:22 2015 From: carterdh7978 at bellsouth.net (David Carter) Date: Thu, 23 Jul 2015 14:47:22 +0000 (UTC) Subject: Gnupg Decryption Question Message-ID: <1460890466.1051201.1437662842135.JavaMail.yahoo@mail.yahoo.com> Hello, We currently use Gnupg 1.4.10 as part of our interactions with an online mailbox system. We are able to successfully encrypt our data files but we haven't been able to find the combination of options that will let us decrypt files that we receive - so we've used a different product for that purpose.? Our desire is to use only one product to perform both encryption and decryption. This is a sample of how we would call gpg to encrypt a text file prior to transmission: gpg -c -o DataFile.gpg --batch --compress-algo 1 --cipher-algo cast5 --passphrase KeyValue DataFile.txt The files that we receive share the same KeyValue, so we would appreciate some guidance on undoing what was done above. Thanks very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbutler at fchn.com Thu Jul 23 19:11:03 2015 From: sbutler at fchn.com (Steve Butler) Date: Thu, 23 Jul 2015 17:11:03 +0000 Subject: Gnupg Decryption Question In-Reply-To: <1460890466.1051201.1437662842135.JavaMail.yahoo@mail.yahoo.com> References: <1460890466.1051201.1437662842135.JavaMail.yahoo@mail.yahoo.com> Message-ID: <7c41661cc5d54404bcaa549e678def7a@t1l1exchmbs-01.fchn.com> This is a snippet of the script I use to decrypt any file coming to me that has my private key (or my companies private key) $DFLT gpg_pass2 \ | gpg --homedir $homedir --quiet --passphrase-fd 0 --no-tty --skip-verify \ --no-permission-warning --no-mdc-warning --batch \ --output "$oname" --decrypt "$x" > /dev/null 2>&1 The DFLT gpg_pass2 script manages to obtain the pass phrase for the private key and pipe it to gpg via stdin The statement right after the above does check to see if the status ($?) is 0. From: Gnupg-users [mailto:gnupg-users-bounces+sbutler=fchn.com at gnupg.org] On Behalf Of David Carter Sent: Thursday, July 23, 2015 7:47 AM To: gnupg-users at gnupg.org Subject: Gnupg Decryption Question Hello, We currently use Gnupg 1.4.10 as part of our interactions with an online mailbox system. We are able to successfully encrypt our data files but we haven't been able to find the combination of options that will let us decrypt files that we receive - so we've used a different product for that purpose. Our desire is to use only one product to perform both encryption and decryption. This is a sample of how we would call gpg to encrypt a text file prior to transmission: gpg -c -o DataFile.gpg --batch --compress-algo 1 --cipher-algo cast5 --passphrase KeyValue DataFile.txt The files that we receive share the same KeyValue, so we would appreciate some guidance on undoing what was done above. Thanks very much. -- 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jupelluri at riseup.net Thu Jul 23 20:54:41 2015 From: jupelluri at riseup.net (A.T. Leibson) Date: Thu, 23 Jul 2015 14:54:41 -0400 Subject: Archaic PGP usage Message-ID: <55B13871.1000902@riseup.net> I know this list doesn't deal with PGP, but since no else does either any more, it seems like the best place to start. I'm very interested in the history of cryptographic implementations. I recently noticed that John Young of Cryptome uses PGP 2.6.1, which struck me as odd. He's an old-timer, so I figured he just hasn't upgraded in the last decade. Then I noticed that Theo De Raadt of OpenBSD links to a 2.6.3ia key from 1997 from openbsd.org/security.html. Again, I thought the key was just another old relic. Finally, this morning I noticed that OpenBSD still has 2.6.3 and 5.0i in its packages. Do people (other than John Young) still use PGP? Why would someone want to do that? -Adam From farhanible at gmail.com Thu Jul 23 21:35:09 2015 From: farhanible at gmail.com (F Rafi) Date: Thu, 23 Jul 2015 15:35:09 -0400 Subject: Python GPG libraries Message-ID: Does anyone use a GPG library to embed file encryption processes within python code? Which libraries do you use? Any recommendations? We looked at the ones below which are basically wrappers for the GnuPG library. http://pythonhosted.org/gnupg/ https://pythonhosted.org/python-gnupg/index.html https://python-gnupg.readthedocs.org/ Thanks, Farhan -------------- next part -------------- An HTML attachment was scrubbed... URL: From diafygi at gmail.com Thu Jul 23 22:47:57 2015 From: diafygi at gmail.com (Daniel Roesler) Date: Thu, 23 Jul 2015 13:47:57 -0700 Subject: Python GPG libraries In-Reply-To: References: Message-ID: There appears to be two main forks of the wrapper. I'm not sure on what the differences are, but they appear to be pretty well maintained. I'd recommend using one of these wrappers. https://bitbucket.org/vinay.sajip/python-gnupg (what runs https://pythonhosted.org/python-gnupg/) https://github.com/isislovecruft/python-gnupg (what runs https://python-gnupg.readthedocs.org/) I also have a super-duper experimental and completely unfinished and unsafe OpenPGP parser[1] that I use to learn the format and to dump the sks-keyserver pool to json[2]. Daniel [1]: https://github.com/diafygi/openpgp-python [2]: https://research.daylightpirates.org/sks-dumps/latest/json/ On Thu, Jul 23, 2015 at 12:35 PM, F Rafi wrote: > Does anyone use a GPG library to embed file encryption processes within > python code? Which libraries do you use? Any recommendations? > > We looked at the ones below which are basically wrappers for the GnuPG > library. > > http://pythonhosted.org/gnupg/ > https://pythonhosted.org/python-gnupg/index.html > https://python-gnupg.readthedocs.org/ > > Thanks, > Farhan > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From rjh at sixdemonbag.org Thu Jul 23 23:13:49 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 23 Jul 2015 17:13:49 -0400 Subject: Archaic PGP usage In-Reply-To: <55B13871.1000902@riseup.net> References: <55B13871.1000902@riseup.net> Message-ID: <55B1590D.9030200@sixdemonbag.org> > I know this list doesn't deal with PGP, but since no else does either > any more, it seems like the best place to start. Old versions of PGP were at least FOSS-friendly, if not FOSS themselves, so it's probably safe to discuss it here. :) > Do people (other than John Young) still use PGP? Why would someone want > to do that? You'd have to ask them. There are some reasons to keep using ancient versions of PGP, but why these specific people keep using ancient PGP is really a question for them and not this list. That said: 1. PGP 2.6 is *small*. The original PGP specification (RFC1991) is a small fraction of the size of the modern OpenPGP specification (RFC4880). When it comes to trustworthy code, small is beautiful. 2. PGP 2.6 is extremely well-audited. GnuPG and Symantec's PGP are both moving targets, but PGP 2.6 really hasn't changed in about 20 years. That gives a lot of confidence that its major bugs have been discovered. 3. PGP 2.6 is "good enough crypto". Modern OpenPGP adds a ton more capabilities, but for many users PGP 2.6 offers them just enough to do what they need. The small-is-beautiful camp tends to have a lot of overlap with the good-enough-crypto camp. ... All this being said, do I recommend PGP 2.6? Absolutely not: its dependency on MD5 alone should disqualify it. But that doesn't mean I don't understand some of the motivations of the people who keep using it. From nobody at dizum.com Fri Jul 24 03:33:34 2015 From: nobody at dizum.com (Nomen Nescio) Date: Fri, 24 Jul 2015 03:33:34 +0200 (CEST) Subject: Gnupg Decryption Question Message-ID: <8f84ad65d4627fc03d04cb7218c4aac2@dizum.com> David Carter wrote: > We currently use Gnupg 1.4.10 > > This is a sample of how we would call > gpg to encrypt a text file prior to transmission: > > gpg -c -o DataFile.gpg --batch --compress-algo 1 --cipher-algocast5 --passphrase KeyValue DataFile.txt > > The files that we receive share the same KeyValue, > so we would appreciate some guidance on undoing > what was done above. > gpg --batch --decrypt --output DataFile.txt --passphrase KeyValue DataFile.gpg From wk at gnupg.org Fri Jul 24 13:20:27 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 24 Jul 2015 13:20:27 +0200 Subject: Archaic PGP usage In-Reply-To: <55B1590D.9030200@sixdemonbag.org> (Robert J. Hansen's message of "Thu, 23 Jul 2015 17:13:49 -0400") References: <55B13871.1000902@riseup.net> <55B1590D.9030200@sixdemonbag.org> Message-ID: <871tfxby4k.fsf@vigenere.g10code.de> On Thu, 23 Jul 2015 23:13, rjh at sixdemonbag.org said: > 1. PGP 2.6 is *small*. The original PGP specification (RFC1991) is a > small fraction of the size of the modern OpenPGP specification > (RFC4880). When it comes to trustworthy code, small is beautiful. FWIW, RFC-1991 is not a complete specification of PGP-2. You can't implement a compatible version based on this info. You also need to look into the PGP-2 documentation and finally you need to be able to send questions to another person who can provide an answer based on the PGP-2 source code (which is public but due copyright reasons one better does not do it by oneself). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Jul 24 13:23:51 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 24 Jul 2015 13:23:51 +0200 Subject: Gnupg Decryption Question In-Reply-To: <7c41661cc5d54404bcaa549e678def7a@t1l1exchmbs-01.fchn.com> (Steve Butler's message of "Thu, 23 Jul 2015 17:11:03 +0000") References: <1460890466.1051201.1437662842135.JavaMail.yahoo@mail.yahoo.com> <7c41661cc5d54404bcaa549e678def7a@t1l1exchmbs-01.fchn.com> Message-ID: <87wpxpajeg.fsf@vigenere.g10code.de> On Thu, 23 Jul 2015 19:11, sbutler at fchn.com said: > This is a snippet of the script I use to decrypt any file coming to me that has my private key (or my companies private key) > > $DFLT gpg_pass2 \ > | gpg --homedir $homedir --quiet --passphrase-fd 0 --no-tty --skip-verify \ > --no-permission-warning --no-mdc-warning --batch \ > --output "$oname" --decrypt "$x" > /dev/null 2>&1 If you receive arbitrary data you may want to add --max-output SUITABLELARGENUMBEROFBYTES to avoid a DoS using special crafted compression data. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From sbutler at fchn.com Fri Jul 24 16:02:29 2015 From: sbutler at fchn.com (Steve Butler) Date: Fri, 24 Jul 2015 14:02:29 +0000 Subject: Gnupg Decryption Question In-Reply-To: <87wpxpajeg.fsf@vigenere.g10code.de> References: <1460890466.1051201.1437662842135.JavaMail.yahoo@mail.yahoo.com> <7c41661cc5d54404bcaa549e678def7a@t1l1exchmbs-01.fchn.com> <87wpxpajeg.fsf@vigenere.g10code.de> Message-ID: -----Original Message----- From: Werner Koch [mailto:wk at gnupg.org] Sent: Friday, July 24, 2015 4:24 AM On Thu, 23 Jul 2015 19:11, sbutler at fchn.com said: > This is a snippet of the script I use to decrypt any file coming to me that has my private key (or my companies private key) > > $DFLT gpg_pass2 \ > | gpg --homedir $homedir --quiet --passphrase-fd 0 --no-tty --skip-verify \ > --no-permission-warning --no-mdc-warning --batch \ > --output "$oname" --decrypt "$x" > /dev/null 2>&1 If you receive arbitrary data you may want to add --max-output SUITABLELARGENUMBEROFBYTES to avoid a DoS using special crafted compression data. Shalom-Salam, Werner ======================= I'll look into that. We do IP filtering on the firewall so we do know who is getting to our SFTP box (on Aug 3 we will shut down port 21 and standard FTP). All who send data to us must sign a business agreement (HIPAA rules). One such does send us encrypted files that approach 25 GB in size -- yikes!! Thankfully that is once a month. -- 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 vedaal at nym.hush.com Fri Jul 24 17:49:54 2015 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Fri, 24 Jul 2015 11:49:54 -0400 Subject: Archaic PGP usage In-Reply-To: <55B13871.1000902@riseup.net> Message-ID: <20150724154954.3FC5041F0B@smtp.hushmail.com> On 7/23/2015 at 2:58 PM, "A.T. Leibson" wrote: >Do people (other than John Young) still use PGP? Why would someone >want to do that? ===== The only possible reasons I can think of are: [1] Remailer use, Original remailers used PGP 2.x and even though some use GnuPG, others are reluctant to change anything. [2] Large File Transfers PGP 2.x can be used as a uuencode, and automatically split a signed and encrypted armored file into 100 smaller files ready to be emailed and reconstitued by the receiver. The default for file splitting, is 720 armored lines, but have done it for much more, and successfully sent a 1 gb Truecrypt container and reconstituted it. If you are thinking of looking at PGP 2.x, I would recommend Disastry's version, as it is not limited to MD5 and IDA but can use any HASH and any encryption algorithm except for Camelia. http://www.spywarewarrior.com/uiuc/disastry/263multi.htm (btw, If anyone knows how to install this on 64 bit Ubuntu 14.04 please let me know. It wouldn't compile on Ubuntu 12.x, but was able to install the linux executable PGP on a 32 bit system, but can't on 14.x 64 bit.) TIA vedaal From 2014-667rhzu3dc-lists-groups at riseup.net Sat Jul 25 14:26:37 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sat, 25 Jul 2015 13:26:37 +0100 Subject: gpg 2.1.6 toggle doesn't In-Reply-To: <55B0FA83.20506@kset.org> References: <55B0FA83.20506@kset.org> Message-ID: <253829032.20150725132637@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Thursday 23 July 2015 at 3:30:27 PM, in , Marko Bo?ikovic wrote: > Hi all, > I've just noticed that the 'toggle' command in gpg > 2.1.5/6 on Windows doesn't switch key display. It still > seems to switch the keys, since I moved my > authentication private key to a smartcard successfully. Yes, it does not toggle the display in GnuPG 2.1.x. If you "toggle" nothing seems to happen. But if you then, for example, try to "adduid" you are told you need to "toggle" first. In , Werner says the [toggle] command should be removed because it does not make much sense anymore. - -- Best regards MFPA ETHERNET(n): device used to catch the Ether bunny -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJVs4CSXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXws7EH/jophXym9lrZYfZMchdJJwN2 GiUInFAafFnBITaiJ0TrqA8lqtRALNajPKN6DddTPb/+DVlC+a8gwi86e4aadFRp hF0xuacYqB8EVBcSlGI1W6Q9Ropp0wkQ+konEqlMwO8i+LOwWyHvmoh9NKidychE RrsioAEr017hETLBPJLxUu1VS+OCfetHvoXp0AD2QhgNK8hH1eB1tamBlkqDK79N JkvtBH8QHNqXOlzdmBdm83W6jC45bMNzynf/sF8a9Q3EQSK3ONFkySLHh2vW6rMv ssjx2yDUNhN5UNPAC8UMCpsP9QV4dBMw8vEdHZdkaxJFGbib6fFEcu1JvYSUrieI vgQBFgoAZgUCVbOAmF8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45NSXAP9S/Tp39NLaO0OV3JE7dabgSYea ZpnzXvTr90IsY08a2QD/bDLmBZem8bkw6pNAm+54e5+uOE/pIdI8GihPcmx56w0= =yD0L -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Sat Jul 25 14:36:41 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sat, 25 Jul 2015 13:36:41 +0100 Subject: Archaic PGP usage In-Reply-To: <20150724154954.3FC5041F0B@smtp.hushmail.com> References: <55B13871.1000902@riseup.net> <20150724154954.3FC5041F0B@smtp.hushmail.com> Message-ID: <7410318850.20150725133641@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Friday 24 July 2015 at 4:49:54 PM, in , vedaal at nym.hush.com wrote: > [2] Large File Transfers PGP 2.x can be used as a > uuencode, and automatically split a signed and > encrypted armored file into 100 smaller files ready to > be emailed and reconstitued by the receiver. > The default for file splitting, is 720 armored lines, > but have done it for much more, and successfully sent a > 1 gb Truecrypt container and reconstituted it. That sounds like a useful feature. But if doing such things often, it may be worth looking at Mike Ingle's Confidant Mail , which has been tested with attachment files of over 4GB. - -- Best regards MFPA Experience is the name everyone gives to their mistakes -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJVs4LaXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwGnoH/ivoLok0kKTygsm5lXXPrZyp M2XYH61sgKDMeYXOSTf5y7dKPxoLSyEUwzC0+VoGyxjZoVw0fyJJ47SzIqID3TL1 xHZkCm8mAf1ylcBDiYI9cw5XATsE9Zv//vU3vhqNPsvgADj4hlDnGByYCAyKJhEX aghaMc+ROpItx0tOTh/lBJJilItxHKKO5+B6Z2EVf4RmKmWmsYrKLwgh3O+ea2ya NKKBOXz9+lCJxd1SRKKUIPnJSVuqHx3i7b3+BFyn5Ju0ZqV1dzlQLJguWgTGRP5B HxDihG4ZWwlewXQ54HaKxkJTeeF7d5tSYXxU6r5PHRFwsk4lz/vdxX82Zk8SD8GI vQQBFgoAZgUCVbOC2l8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45NuyAQDukt7SUH2zUMxwY69MK7XuRkQV bTffr0+SYYKyAKp6wgD43An11/DtOZo3g+2XDuCR4IlMVX/7T15+6FGgQdrUDg== =Fk1Q -----END PGP SIGNATURE----- From muelli at cryptobitch.de Fri Jul 24 14:06:50 2015 From: muelli at cryptobitch.de (Tobias Mueller) Date: Fri, 24 Jul 2015 14:06:50 +0200 Subject: Python GPG libraries In-Reply-To: References: Message-ID: <20150724120650.GL3665@cryptobitch.de> Hi. On Thu, Jul 23, 2015 at 03:35:09PM -0400, F Rafi wrote: > Does anyone use a GPG library to embed file encryption processes within > python code? Which libraries do you use? Any recommendations? As far as I understand, the GPGME-based pygpgme is the embraced library: https://launchpad.net/pygpgme The others don't use gpgme but call gpg themselves. There have been many discussions on this list and elsewhere discussing the ability to use gnupg as a library from Python. >From what I understand, they all have their issues. The python-gnupg ones are easier to use, but lack features like signing keys. pygpgme does not seem to be actively maintained and lacks support for, e.g. exporting secret keys (or public keys in a --export-minimal) fashion. Cheers, Tobi From 2014-667rhzu3dc-lists-groups at riseup.net Sun Jul 26 09:55:11 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sun, 26 Jul 2015 08:55:11 +0100 Subject: Python GPG libraries In-Reply-To: <20150724120650.GL3665@cryptobitch.de> References: <20150724120650.GL3665@cryptobitch.de> Message-ID: <993169522.20150726085511@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Friday 24 July 2015 at 1:06:50 PM, in , Tobias Mueller wrote: > Hi. > On Thu, Jul 23, 2015 at 03:35:09PM -0400, F Rafi wrote: >> Does anyone use a GPG library to embed file encryption processes within >> python code? Which libraries do you use? Any recommendations? > As far as I understand, the GPGME-based pygpgme is the > embraced library: https://launchpad.net/pygpgme Ben McGinnes has been working on GPyGME, a python wrapper and API which will be included in a future release of GPGME. (This link was down just now but the search engine I used to search for "GPyGME" showed me a cached version via their proxy.) - -- Best regards MFPA Was time invented by an Irishman named O'Clock? -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJVtJJzXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwlWcIAL8QqiEwW3wQ+vJd/BK1KwRy +TnrtTH2TKk+2CiHzI5SD2tJjmEFdPvAhKOjknSZrS25JJ3Gmp8tkxNxzvi3uqRb R6DSV1+ZFU2KugfM0DUmEkh9P9/UDTs+qdpHvIYDvZhPXXGp2b/fVVX7h6fsPnSZ Q1+QjcIx/iUoz2VbqG1uV6E6LntL/+F2dI8K9eyjNhuhYSeKcD4Y1xAoOucN4sL2 owdlPeDkeq/yQuEHGVKduoW52zoURbAJ2U8v2kERptv3GTglPChLBWGlQNU5sf/Z 5hmigHGjg0saHw37cXVEA2t4hkq+GrLymGt8PxexoLGEIzMVRYy6W/E6Hg1JPPaI vgQBFgoAZgUCVbSSel8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45KEsAP4uIeVRSo29sM45SUN1C3UStR5z PnPp/bR4V8zxvfpXIgEA/VLWFAVU2IQFcBlBcRJQnu/qjvheh0RExQA1czYgiAk= =uS3d -----END PGP SIGNATURE----- From jimmy.thrasibule at gmail.com Sun Jul 26 10:58:49 2015 From: jimmy.thrasibule at gmail.com (Jimmy Thrasibule) Date: Sun, 26 Jul 2015 10:58:49 +0200 Subject: Pinentry fails with gpg-agent and SSH In-Reply-To: References: Message-ID: Hi, I've found the answer on the [GPG Website][1] itself. The agent was failing to find on which screen to display the Pinentry window. I just had to put the following in my .*shrc file: echo "UPDATESTARTUPTTY" | gpg-connect-agent > /dev/null 2&>1 [1]: https://www.gnupg.org/documentation/manuals/gnupg/Common-Problems.html __ Jimmy From bozho at kset.org Mon Jul 27 10:48:11 2015 From: bozho at kset.org (=?UTF-8?B?TWFya28gQm/Fvmlrb3ZpxIc=?=) Date: Mon, 27 Jul 2015 09:48:11 +0100 Subject: gpg 2.1.6 toggle doesn't In-Reply-To: <253829032.20150725132637@my_localhost> References: <55B0FA83.20506@kset.org> <253829032.20150725132637@my_localhost> Message-ID: <55B5F04B.109@kset.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 25/07/2015 13:26, MFPA wrote: > Hi > > > On Thursday 23 July 2015 at 3:30:27 PM, in , > Marko Bo?ikovic wrote: > > >> Hi all, > >> I've just noticed that the 'toggle' command in gpg 2.1.5/6 on Windows >> doesn't switch key display. It still seems to switch the keys, since I >> moved my authentication private key to a smartcard successfully. > > Yes, it does not toggle the display in GnuPG 2.1.x. If you "toggle" > nothing seems to happen. But if you then, for example, try to "adduid" > you are told you need to "toggle" first. > > In , Werner says the [toggle] > command should be removed because it does not make much sense anymore. Ok, but why doesn't it make much sense anymore? Is there another way to get private key info while in --edit-key mode? (e.g. key location, like the bug submitter mentions) - -- Marko -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJVtfBEAAoJEE8XQV0qn4Bv6fIIAIF35b38atadrKRuQ3Rralo7 g3Z3YklS9nn7/WF8j3Hp4SMzX/bvNwNxqgk+IOMH9Lrk9J4mZ7d06RF7n8sF5KZO /fpo3EEuKyKPo6Uo9QD4X58HfjRwdGjCtWgrh415Mi8jNczU9txLdl5Lt0spsG8Z /CIzd/JDSSrzyOl/ZnkFKHrXy85yCbY6jjx290NnULOlMOKZaRef+JLyj52fYbva cNwAWS09jkM/ZxxDaSqEdWDVe8PzgALfvpvJpT2W1i+tnI7aZFvmoUVvWcIIGLM8 PHz1flJi3/PBlzCNwIlMphMsn0zm9ZkmO4v2E9kwfprZSg3jnUE0zWB3XwxfxeU= =rBjh -----END PGP SIGNATURE----- From kristian.fiskerstrand at sumptuouscapital.com Mon Jul 27 11:03:50 2015 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Mon, 27 Jul 2015 11:03:50 +0200 Subject: gpg 2.1.6 toggle doesn't In-Reply-To: <55B5F04B.109@kset.org> References: <55B0FA83.20506@kset.org> <253829032.20150725132637@my_localhost> <55B5F04B.109@kset.org> Message-ID: <55B5F3F6.90700@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 07/27/2015 10:48 AM, Marko Bo?ikovi? wrote: > On 25/07/2015 13:26, MFPA wrote: >> Hi .. > Ok, but why doesn't it make much sense anymore? Is there another > way to get private key info while in --edit-key mode? (e.g. key > location, like the bug submitter mentions) > 1.4 and 2.0 have separate keyrings for public keys (pubring.gpg) and private keys (secring.gpg). In 2.1 everything is handled in agent and keys stored in platform agnostic format on per-key basis based on keygrip. I.e. there is no more toggling between keyrings. - -- - ---------------------------- Kristian Fiskerstrand Blog: http://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 - ---------------------------- "History doesn't repeat itself, but it does rhyme." (Mark Twain) -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJVtfPyAAoJECULev7WN52F2vcH/A2yB6w0XG6XjHw0+YBMna1y A5FcA4c2W9CcQX/U2S8jhpAKP9e0yA4Z2dELKIyZoQhOEy5P9MHMKyQPC7z/dSP5 TW8G0/0gU1DyVTO+QtL4UvfSySjJXL8sXiEtq33aOIwdlhqB6+ev9Q8H3JHOqnLj d/TmC8YeYGs2eKCnhQT9UEvuTzCzWSAbuiFFOOplCqvMraLHchECxrB7MxDsy9AV 1Jk/pACiaaiPDmJASufwL+WmLN96EJqEX5UM475Da3CsKmxuS+OV7pHUI0TDxvnM /edCHHMr1jq3KqqsFWAoo79rQc1RZnXX7A0TryT8BgEy7VX8gfaTWEagcDP83vk= =6DnW -----END PGP SIGNATURE----- From nico at enigmail.net Mon Jul 27 07:55:03 2015 From: nico at enigmail.net (nico at enigmail.net) Date: Mon, 27 Jul 2015 07:55:03 +0200 Subject: Proposal of OpenPGP Email Validation Message-ID: <55B5C7B7.4090907@enigmail.net> Hi all, in March we discussed here "German ct magazine postulates death of pgp encryption" and Patrick Brunschwig proposed a way to validate email addresses I also had in mind: > http://lists.gnupg.org/pipermail/gnupg-users/2015-March/052882.html In the past months I tried to come up with a concrete proposal. I discussed it already with some people and this is what I/we propose so far. The proposal is not perfect and not completely worked out but IMO it is ready for a broader discussion and review. Thus, I am happy for any feedback (details and general remarks) both here and directly as email to me. If the concept is possible and useful the goal is to have a first validating keyserver proxy (see the document for details what this is) at the end of this year. We have some guy willing to implement it as part of a Bachelor thesis. Best regards Nico -- Nicolai M. Josuttis www.josuttis.de mailto:nico at enigmail.net PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5 -- Nicolai M. Josuttis www.josuttis.de mailto:nico at enigmail.net PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5 -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP-Email-Validation-20150726.pdf Type: application/pdf Size: 283243 bytes Desc: not available URL: From kristian.fiskerstrand at sumptuouscapital.com Mon Jul 27 11:14:41 2015 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Mon, 27 Jul 2015 11:14:41 +0200 Subject: gpg 2.1.6 toggle doesn't In-Reply-To: <55B5F3F6.90700@sumptuouscapital.com> References: <55B0FA83.20506@kset.org> <253829032.20150725132637@my_localhost> <55B5F04B.109@kset.org> <55B5F3F6.90700@sumptuouscapital.com> Message-ID: <55B5F681.1070002@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 07/27/2015 11:03 AM, Kristian Fiskerstrand wrote: > On 07/27/2015 10:48 AM, Marko Bo?ikovi? wrote: >> On 25/07/2015 13:26, MFPA wrote: >>> Hi > > > .. > >> Ok, but why doesn't it make much sense anymore? Is there another >> way to get private key info while in --edit-key mode? (e.g. key >> location, like the bug submitter mentions) > > > 1.4 and 2.0 have separate keyrings for public keys (pubring.gpg) > and private keys (secring.gpg). In 2.1 everything is handled in > agent and keys stored in platform agnostic format on per-key basis > based on keygrip. I.e. there is no more toggling between keyrings. > > Was a bit quick there, so to clarify that a bit, all secret-key operations are handled in the agent, and based on keygrip calculated in the single-store public keyring. - -- - ---------------------------- Kristian Fiskerstrand Blog: http://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 - ---------------------------- Aquila non capit muscas The eagle does not hunt flies -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJVtfZ6AAoJECULev7WN52F/ucH/0TiasUsLalQsJsgjTuSG3Ee ZBX90BOZOoxGvitIuLqY61+78Bwz0nSZe91Ar+UTPxZM+PnJIkL/tFwobJ5r6Oci fopEU8OZzWxSafLlPEr4CZkzy9lOqfra+jFyYnNXPVsbR/hQhFyi5bfnRA1gy0Jg NEEhUbWVHBt/V4ee79pVJMd9X5mRDDnknuQPLEvr8TdAYf+nK0AUKl0vHAF9JzCq bMIywD0RzzdVALucuWknu/qJIqS4VEA3ON1Y3Ipx52+PSqAo4LkHY9BDUmQuRUd5 GV6024G3e5Laj4PVz8eulKlMUIGInJX9CvJxDxggFWSZpnTpT+XlOdtWnVO1fr0= =ZaSY -----END PGP SIGNATURE----- From bozho at kset.org Mon Jul 27 12:46:09 2015 From: bozho at kset.org (=?UTF-8?B?TWFya28gQm/Fvmlrb3ZpxIc=?=) Date: Mon, 27 Jul 2015 11:46:09 +0100 Subject: gpg 2.1.6 toggle doesn't In-Reply-To: <55B5F681.1070002@sumptuouscapital.com> References: <55B0FA83.20506@kset.org> <253829032.20150725132637@my_localhost> <55B5F04B.109@kset.org> <55B5F3F6.90700@sumptuouscapital.com> <55B5F681.1070002@sumptuouscapital.com> Message-ID: <55B60BF1.3040900@kset.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 27/07/2015 10:14, Kristian Fiskerstrand wrote: > On 07/27/2015 11:03 AM, Kristian Fiskerstrand wrote: >> On 07/27/2015 10:48 AM, Marko Bo?ikovi? wrote: >>> On 25/07/2015 13:26, MFPA wrote: >>>> Hi > > >> .. > >>> Ok, but why doesn't it make much sense anymore? Is there another way >>> to get private key info while in --edit-key mode? (e.g. key location, >>> like the bug submitter mentions) > > >> 1.4 and 2.0 have separate keyrings for public keys (pubring.gpg) and >> private keys (secring.gpg). In 2.1 everything is handled in agent and >> keys stored in platform agnostic format on per-key basis based on >> keygrip. I.e. there is no more toggling between keyrings. > > > > Was a bit quick there, so to clarify that a bit, all secret-key > operations are handled in the agent, and based on keygrip calculated in > the single-store public keyring. I know that, and I'm using 2.1 exclusively... Still, it would be nice to be able to see the state of private keys (e.g. primary key not present in the keyring, private keys are on the card, etc) while editing keys. It seems that the only way to see private key info is running gpg(2) -K (or am I missing something?) - -- Marko -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJVtgvqAAoJEE8XQV0qn4Bv4dEIAKSOxfmrbgXZHK+0lzYMgSeB 5Mm3MWHBKx7mq6ffMm/MBsCoxjjLGf/boTTrG0t0DYjhKw0svZjEAkYegSYI5wqG nt53+RtUTIbhcoSn1Fca+zoR5ppzTHMu+cKA1r2E6H/UgBovTcu+dpCa6he0Lqef VQIf5ESJUi53Av9Wphjozt/RE2MSueijMG067fRyy8pfrw63nPvoo0u3toxxO0r1 mzwLKdVeM+3O1mhtJOzBrB4YWPoFT6kzvjHLGyxiMlcjTPQMCfW0jH5h6j65FFa9 m+f+s7f0x7FbXWpQAl/IjIfgpiL5mHCh0jAWvZWQxCS6dbe0lR7CB58PIgmBAE0= =rgVw -----END PGP SIGNATURE----- From neal at walfield.org Mon Jul 27 14:15:57 2015 From: neal at walfield.org (Neal H. Walfield) Date: Mon, 27 Jul 2015 14:15:57 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <55B5C7B7.4090907@enigmail.net> References: <55B5C7B7.4090907@enigmail.net> Message-ID: <874mkpokxu.wl-neal@walfield.org> Hi, I guess you mean this: The idea I have in mind is roughly as follows: if you upload a key to a keyserver, the keyserver would send an encrypted email to every UID in the key. Each encrypted mail contains a unique link to confirm the email address. Once all email addresses are confirmed, the key is validated and the keyserver will allow access to it just like with any regular keyserver. This approach is not going to stop a nation state. A nation state can intercept the mail, decrypt it and follow the link. For the same reason, it is not going to stop a user's ISP. Given Microsoft's et al.'s willingness to cooperate with the NSA, these are not very good starting conditions. The approach also has another problem: which key servers are going to do this? There are 100s of key servers. I'm not going to reply to mails from each one, sorry. This also seems like a nice way to spam someone. Generate a key, upload it to a key server and they have a bunch of mails from the key server. Based on this, I suspect that it won't take long for the key servers to be blacklisted? Have you considered these issues? Do you have any thoughts about how to avoid these problems or do you think they are not real problems? Regarding the design: personally, I wouldn't have the user follow a link that includes a swiss number, but have the user reply to the mail, include the swiss number and sign it. I'd also consider having the key servers publish the validations. If you chain the validations (include the hash of the previous validation in the current validation) you can detect if the key servers serve a fake key to a specific user. Neal From 2014-667rhzu3dc-lists-groups at riseup.net Mon Jul 27 15:16:49 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Mon, 27 Jul 2015 14:16:49 +0100 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <55B5C7B7.4090907@enigmail.net> References: <55B5C7B7.4090907@enigmail.net> Message-ID: <653170829.20150727141649@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Monday 27 July 2015 at 6:55:03 AM, in , nico at enigmail.net wrote: > Thus, I am happy for any feedback (details and general > remarks) both here and directly as email to me. Comments in no particular order, just as they occurred to me when looking through your paper:- If a key is validated by the proxy, then subsequently uploaded again with a new UID, does the new UID get a validation expiry date that matches the rest of the key? Or does it get a standard 12-month validation period, but still get re-validated the next time one of the other UIDs needs it, so that all UIDs' validation expiry dates are brought back into sync? And what if the upload with an extra UID hits a different validation server? If a third party has uploaded my key, or if the validation server is automatically validating existing keys in response to certain events, the validation emails are unsolicited by me. Most people will not click a link in such an email. If a third party who can intercept my emails has generated a key containing my email address in a UID, all bets are off. If an email provider provides public keys for their customers, presumably those keys are unsuitable for mail encryption because the provider may have access to the private key. The configuration changes for email clients that you mention, things like which keyserver to use and which keys to trust, need to be set in GnuPG.conf (or maybe some form of GnuPG wrapper or plugin) so that they are used by an email client that simply calls GnuPG and therefore honours GnuPG's own settings. Same for trust models; maybe you should consider suggesting a modified trust model for GnuPG that includes options for handling validation signatures. Blacklists should not be used *anywhere* as they are a form of censorship and can be used for DOS attacks. In your proposal for listing validation signatures in GnuPG: "?!? after sig signals successful validation" - why is this needed? Surely the mere presence of a validation signature signals successful validation. Why would the notation value be base64 encoded? What is the rationale for preventing users from reading the notation values in a key listing? Notation version numbers. Rather than using different notation names such as validation-v2 at enigmail.net, I would think it better to keep the notation name standard and put the version number at the start of the value string. - -- Best regards MFPA Of course it's a good idea - it's mine! -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJVti9OXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwomYIAKOZABvgm+ThrS8fEVBss0ZC YGum47Mu1j72FAAVZWw2q/w34sOOpZmBU4SdqFYVtvy+g3+KpdBviybU3pZCjUx9 220pOHjLzyWOA1Kg4yl3N9NDRRzN70IvTf3S1jEwiJAedr4dH1Wq25SlS8vICj6r JYohh9Cp4fEBXQTA7IJVvHUE6AbVRfeN4HqyaDCfLN3Om0m37fws2J9p6w9u7CnI Pkuku+BwMMzJX2bqJo4rEQ9f777FGpyicAfj0xVEZuwfa5zZ6Uc5sWaxc9RXyjw7 zKHpwllefD3xhV7SavEjea5cmU2GpNuPDHwYB2tzMq3PR/zZxMdK8qF2tgTqpDmI vgQBFgoAZgUCVbYvU18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45HYGAQCMDqnx5p5GssdlNRjamhGLZ722 jSiKwhEuScsRNcg2dAEA5QtVWIzazuuC8KJB9kERVyXCnoWUu9QD7Rlatzh6wAU= =0XZS -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Mon Jul 27 15:31:56 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Mon, 27 Jul 2015 14:31:56 +0100 Subject: gpg 2.1.6 toggle doesn't In-Reply-To: <55B60BF1.3040900@kset.org> References: <55B0FA83.20506@kset.org> <253829032.20150725132637@my_localhost> <55B5F04B.109@kset.org> <55B5F3F6.90700@sumptuouscapital.com> <55B5F681.1070002@sumptuouscapital.com> <55B60BF1.3040900@kset.org> Message-ID: <822164877.20150727143156@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Monday 27 July 2015 at 11:46:09 AM, in , Marko Bo?ikovic wrote: > I know that, and I'm using 2.1 exclusively... Still, it > would be nice to be able to see the state of private > keys (e.g. primary key not present in the keyring, > private keys are on the card, etc) while editing keys. > It seems that the only way to see private key info is > running gpg(2) -K (or am I missing something?) When I run gpg -K, or gpg --list-secret-keys, the listing for each key starts with the location of pubring.kbx and not the location of private-keys-v1.d. - -- Best regards MFPA When it comes to humility, I'm the greatest. -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJVtjLMXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXw1ngIALjT1LY1U8g1sMIlRN409dn/ c4AKgkByMKjUKd3uL+fYRn6akpBNgO7JDz7PmRN48CtddhSgnTGqGMOEq44fldy+ XK22HMgP8tXMyZ/JK3VH12TndDY4EbcXlfQt3/NkqussQo0t8ZYETLZ6waAIOrhQ 0/0OgQ+jY4SYHsYrd9+1qkIdGioEXJKUjgpncDw23YlvtvxqJXw8qgnAa6tM/JYV N0vVTjdmqjiLWcE2scoWdhzdVkFsfP5ZUZplGYRS1qmsGfnqw1gdQei6IdC8Ix2p OzBoVqglFaVWhsyIZUeYKYspH/z4uZXNDs9HQV9jAMbvIzJqPR/gf6f1aBmGXeiI vgQBFgoAZgUCVbYyzV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45IfJAQDr1dvBpa8gkBAj+7wso3UoFAv4 tCe7nvS5djPAwuTN4AEA9OeeoQcRqN1aJkD8QjwzqyD69dclfPQPVsI+sYw8bAo= =QJbV -----END PGP SIGNATURE----- From mls at dabpunkt.eu Mon Jul 27 14:33:42 2015 From: mls at dabpunkt.eu (Daniel Baur) Date: Mon, 27 Jul 2015 14:33:42 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <874mkpokxu.wl-neal@walfield.org> References: <55B5C7B7.4090907@enigmail.net> <874mkpokxu.wl-neal@walfield.org> Message-ID: <55B62526.9000906@dabpunkt.eu> Hello, Am 27.07.2015 um 14:15 schrieb Neal H. Walfield: > This approach is not going to stop a nation state. A nation state can > intercept the mail, decrypt it and follow the link. > > For the same reason, it is not going to stop a user's ISP. Given > Microsoft's et al.'s willingness to cooperate with the NSA, these are > not very good starting conditions. As far as I understand, the email is encrypted with the public key of the owner ? so as long as we think that GPG is safe, Nico?s verification-emails should be also safe. What could be a problem: The state or the ISP could create a key-pair of its own and upload it, intercept the mail and verify it. Sincerely, DaB. From bozho at kset.org Mon Jul 27 16:06:53 2015 From: bozho at kset.org (=?UTF-8?B?TWFya28gQm/Fvmlrb3ZpxIc=?=) Date: Mon, 27 Jul 2015 15:06:53 +0100 Subject: gpg 2.1.6 toggle doesn't In-Reply-To: <822164877.20150727143156@my_localhost> References: <55B0FA83.20506@kset.org> <253829032.20150725132637@my_localhost> <55B5F04B.109@kset.org> <55B5F3F6.90700@sumptuouscapital.com> <55B5F681.1070002@sumptuouscapital.com> <55B60BF1.3040900@kset.org> <822164877.20150727143156@my_localhost> Message-ID: <55B63AFD.4030702@kset.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 27/07/2015 14:31, MFPA wrote: > Hi > > > On Monday 27 July 2015 at 11:46:09 AM, in > , Marko Bo?ikovic wrote: > > >> I know that, and I'm using 2.1 exclusively... Still, it would be nice >> to be able to see the state of private keys (e.g. primary key not >> present in the keyring, private keys are on the card, etc) while >> editing keys. It seems that the only way to see private key info is >> running gpg(2) -K (or am I missing something?) > > When I run gpg -K, or gpg --list-secret-keys, the listing for each key > starts with the location of pubring.kbx and not the location of > private-keys-v1.d. > Hi, I'm not sure we're talking about the same thing... When I run gpg -K (2.1), I get a listing of my private keys' info from my pubring.kbx. In the listing, there are indicators for missing/deleted private keys (sec#) and private key "placeholders" (not sure if that's the term) for keys that are stored on the card (ssb>). This is what the output looks like (notice # and >'s) sec# rsa4096/AAAAAAAA 2015-05-11 [expires: 2018-05-10] uid [ultimate] uid [ultimate] ... ssb> rsa2048/XXXXXXXX 2015-05-11 [expires: 2016-05-10] ssb> rsa2048/YYYYYYYY 2015-05-11 [expires: 2016-05-10] ssb> rsa2048/ZZZZZZZZ 2015-05-11 [expires: 2016-05-10] Previously, using toggle, you could see that info while running gpg --edit-key Cheers, - -- Marko -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJVtjr4AAoJEE8XQV0qn4BvSGEH/25G8HLCdrVmXgs9YRXfpWqp Y62qTVfj/4YSpm0MHcQAn07f0GUoJparduX2Lh/hAd92ujb6Slg73AJWewza1oqd m59J4+KWN22oFOBqaqBTK1eYXmSLSj9U9DwDXVxAvancGodME2krwsyLHgHUTeVU yDaqoe+GK+eaX+K7v4yJ99rK8yUC26CGCcjj5Ygy0dAYIpYLNVS+8ATfaCgxlLx2 /0/DiaGog4cKWol3pJm2881RFyyE9JhgepzW+4cXuKBx0lDSJxt5DUg67VK2yJpX XVmM1IrkKMXZkxoBQDulRrRh73YwJ5pY124sad9bzz714uAWKhiEBa+Z+YUf6mk= =k8ug -----END PGP SIGNATURE----- From wk at gnupg.org Mon Jul 27 17:23:28 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 27 Jul 2015 17:23:28 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <55B5C7B7.4090907@enigmail.net> (nico@enigmail.net's message of "Mon, 27 Jul 2015 07:55:03 +0200") References: <55B5C7B7.4090907@enigmail.net> Message-ID: <87h9op7hfz.fsf@vigenere.g10code.de> On Mon, 27 Jul 2015 07:55, nico at enigmail.net said: > Thus, I am happy for any feedback > (details and general remarks) Plain text would be appreciated. I accidentally accepted that 280k PDF but sending such files to 2600 subscribes should be the exception. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From kloecker at kde.org Mon Jul 27 16:31:15 2015 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Mon, 27 Jul 2015 16:31:15 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <55B5C7B7.4090907@enigmail.net> References: <55B5C7B7.4090907@enigmail.net> Message-ID: <1567894.c4elsytu3Z@collossus.ingo-kloecker.de> On Monday 27 July 2015 07:55:03 nico at enigmail.net wrote: > Hi all, > > in March we discussed here > "German ct magazine postulates death of pgp encryption" > and Patrick Brunschwig proposed a way to validate email addresses > > I also had in mind: > > http://lists.gnupg.org/pipermail/gnupg-users/2015-March/052882.html > > In the past months I tried to come up with a concrete proposal. > I discussed it already with some people and > this is what I/we propose so far. > The proposal is not perfect and not completely worked out > but IMO it is ready for a broader discussion and review. This whole concept of a whitelist of "trusted validation servers" included in the email clients sounds a lot like the CA certificate bundles included in browsers and/or OSes. Who is going to maintain this whitelist? The email client developers? The OS manufactures? Who is going to certify "trusted validation servers", i.e. who is going to tell benign validation servers apart from malignant validation servers? Your proposal seems to repeat a lot of the (failed) concepts of the centralized CA approach. For this reason I think the approach is doomed to fail the same way the centralized CA approach has failed (even if everybody seems to ignore its failure). I'd rather put my bets on a DANE-based approach like https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Mon Jul 27 18:10:12 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 27 Jul 2015 18:10:12 +0200 Subject: Archaic PGP usage In-Reply-To: <20150724154954.3FC5041F0B@smtp.hushmail.com> (vedaal@nym.hush.com's message of "Fri, 24 Jul 2015 11:49:54 -0400") References: <20150724154954.3FC5041F0B@smtp.hushmail.com> Message-ID: <8738097fa3.fsf@vigenere.g10code.de> On Fri, 24 Jul 2015 17:49, vedaal at nym.hush.com said: > PGP 2.x can be used as a uuencode, and automatically split a signed > and encrypted armored file into 100 smaller files ready to be emailed > and reconstitued by the receiver. OpenPGP also defines such an armor option but it is not implemented by GnuPG because: - It is better to use the standard MIME feature for splitting messages. - Mail has replaced BBSs and we have other constraints now than the small maximum message size of 30 years ago. - Remailers need to employ their own system to send data in fixed size charges and can't use the PGP format. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From patrick at enigmail.net Mon Jul 27 17:51:56 2015 From: patrick at enigmail.net (Patrick Brunschwig) Date: Mon, 27 Jul 2015 17:51:56 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <874mkpokxu.wl-neal__30091.3890744143$1437999461$gmane$org@walfield.org> References: <55B5C7B7.4090907@enigmail.net> <874mkpokxu.wl-neal__30091.3890744143$1437999461$gmane$org@walfield.org> Message-ID: <55B6539C.6040302@enigmail.net> On 27.07.15 14:15, Neal H. Walfield wrote: > Hi, > > I guess you mean this: > > The idea I have in mind is roughly as follows: if you upload a key to > a keyserver, the keyserver would send an encrypted email to every UID > in the key. Each encrypted mail contains a unique link to confirm the > email address. Once all email addresses are confirmed, the key is > validated and the keyserver will allow access to it just like with any > regular keyserver. > > This approach is not going to stop a nation state. A nation state can > intercept the mail, decrypt it and follow the link. If the email can be decrypted, then any email can be decrypted, which would turn OpenPGP useless. > For the same reason, it is not going to stop a user's ISP. Given > Microsoft's et al.'s willingness to cooperate with the NSA, these are > not very good starting conditions. If (and only if) the user stores his private key on his computer, and the connection to the validating key server is HTTPS with PFS, I don't really agree. In any case, the target users are not the Edward Snowdens of this world, but the 99% of people who just want to communicate easily with each other and don't want to be bothered too much with key complicated key lookup/verification scenarios. > The approach also has another problem: which key servers are going to > do this? There are 100s of key servers. I'm not going to reply to > mails from each one, sorry. The idea is that these servers are separate from the keyserver network. That is, a relatively small set of servers that would only do validation of email addresses. Validated keys would then be uploaded to normal key servers. > This also seems like a nice way to spam someone. Generate a key, > upload it to a key server and they have a bunch of mails from the key > server. Based on this, I suspect that it won't take long for the key > servers to be blacklisted? True, but this only serves the purpose of spamming someone without any further action. You cannot send specific text to those who get spammed, that's thus not very interesting. But in general, that's certainly something to consider (such as only accepting one key at a time and only accepting N keys per hour from some IP address). > Have you considered these issues? Do you have any thoughts about how > to avoid these problems or do you think they are not real problems? > > > Regarding the design: personally, I wouldn't have the user follow a > link that includes a swiss number, but have the user reply to the > mail, include the swiss number and sign it. That's a good idea indeed. > I'd also consider having the key servers publish the validations. If > you chain the validations (include the hash of the previous validation > in the current validation) you can detect if the key servers serve a > fake key to a specific user. Sounds like a good idea. -Patrick From nico at enigmail.net Mon Jul 27 19:21:10 2015 From: nico at enigmail.net (nico at enigmail.net) Date: Mon, 27 Jul 2015 19:21:10 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <874mkpokxu.wl-neal@walfield.org> References: <55B5C7B7.4090907@enigmail.net> <874mkpokxu.wl-neal@walfield.org> Message-ID: <55B66886.9070503@enigmail.net> Thanks, Neal for the feedback. I will try to answer. Am 27.07.2015 um 14:15 schrieb Neal H. Walfield: > Hi, > > I guess you mean this: > > The idea I have in mind is roughly as follows: if you upload a key to > a keyserver, the keyserver would send an encrypted email to every UID > in the key. Each encrypted mail contains a unique link to confirm the > email address. Once all email addresses are confirmed, the key is > validated and the keyserver will allow access to it just like with any > regular keyserver. > Hmm, not quite right, there are two major points where I think there is some misunderstanding: First, I DON'T propose to use key servers here. In agreement with Kristian Fiskerstrand we propose to give other servers the task. As written, these "validation servers" should ideally operate as key server proxies, though, passing all requests to keyservers and responses back to email clients, while in addition doing/triggering email validations. But for ordinary keyservers validations servers "only" provide validation signatures as any other email client can do. Second, because the signatures sign UIDs (not keys), each UID is individually signed. A validation server could wait to upload the key to a key server until the FIRST email address is signed. But in principle, uploading a key or a new UID for the key is different from triggering its validation (and as a result uploading the corresponding validation signature to the UID(s)). > This approach is not going to stop a nation state. A nation state can > intercept the mail, decrypt it and follow the link. > Sorry, don't know what a nation state is. > For the same reason, it is not going to stop a user's ISP. Given > Microsoft's et al.'s willingness to cooperate with the NSA, these are > not very good starting conditions. > Although, Daniel answered, I didn't quite get the problem here and would be happy if you prefer to explain the problem a bit in detail (yes, sorry, I am not an expert). > The approach also has another problem: which key servers are going to > do this? There are 100s of key servers. I'm not going to reply to > mails from each one, sorry. > Hmm, I though I discussed that but may be my wording was bad. Indeed, there should only by one validation request per email address each year. For this, we'd trust multiple validation signatures. But yes, as I wrote, we have to maintain white- and/or black lists then (in email clients or where ever). And yes, THIS can be(come) a problem. > This also seems like a nice way to spam someone. Generate a key, > upload it to a key server and they have a bunch of mails from the key > server. Based on this, I suspect that it won't take long for the key > servers to be blacklisted? > We though about that, but right I didn't write anything about it. We might follow the following rule: - Once validated, no re-validations can be triggered within the 12 months the signature is valid (may be unless the owner of the key itself troggers the re-validation) - But yes, then we have the problem of others uploading faked keys (the problem we want to solve). First: May be it's fine that people get informed that faked keys are uploaded. At least I personally would like to know that. Then: I could trigger my own validation and as written in the first bullet disable any other validations unless triggered by me. Thus, once there is a successful validation this is no loner a problem. > Have you considered these issues? Do you have any thoughts about how > to avoid these problems or do you think they are not real problems? > At least a part of them, I hope. But I would not be surprised having overlooked some stuff. You are the experts. I only want to solve the problem. And indeed , the question, how to avoid to many validation requests while at the same time having multiple validation servers is something I am pretty unsure about details. I am happy for any help here. > Regarding the design: personally, I wouldn't have the user follow a > link that includes a swiss number, but have the user reply to the > mail, include the swiss number and sign it. > OK, that's of course also possible. Any reason why this is something you prefer? > I'd also consider having the key servers publish the validations. If > you chain the validations (include the hash of the previous validation > in the current validation) you can detect if the key servers serve a > fake key to a specific user. > OK, interesting idea. Thanks a lot Nico > Neal > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > -- Nicolai M. Josuttis www.josuttis.de mailto:nico at enigmail.net PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5 From wk at gnupg.org Mon Jul 27 19:46:03 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 27 Jul 2015 19:46:03 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <874mkpokxu.wl-neal@walfield.org> (Neal H. Walfield's message of "Mon, 27 Jul 2015 14:15:57 +0200") References: <55B5C7B7.4090907@enigmail.net> <874mkpokxu.wl-neal@walfield.org> Message-ID: <87si895w9w.fsf@vigenere.g10code.de> On Mon, 27 Jul 2015 14:15, neal at walfield.org said: > The approach also has another problem: which key servers are going to > do this? There are 100s of key servers. I'm not going to reply to > mails from each one, sorry. As Nico described, PGP used a very simlar system to validate keys and expire them based on the date of the last validation. However, that system worked with because they control the central server and the server did not sync with the other keyserver automatically. The validation signature you find on some the keys are due to faulty manual syncing (download from pgp.com upload to pgp.net). A solid approach for central crypto server. > I'd also consider having the key servers publish the validations. If > you chain the validations (include the hash of the previous validation You can't do that due to the decentralized approach with no requirement for the user to always upload to the same keyserver. Thus a server may miss validation signatures not yet received from other servers. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nico at enigmail.net Mon Jul 27 19:55:24 2015 From: nico at enigmail.net (nico at enigmail.net) Date: Mon, 27 Jul 2015 19:55:24 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <653170829.20150727141649@my_localhost> References: <55B5C7B7.4090907@enigmail.net> <653170829.20150727141649@my_localhost> Message-ID: <55B6708C.9090007@enigmail.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi MFPA, Thanks a lot for your feedback. Am 27.07.2015 um 15:16 schrieb MFPA: > Hi > > > On Monday 27 July 2015 at 6:55:03 AM, in > , nico at enigmail.net wrote: > > > >> Thus, I am happy for any feedback (details and general >> remarks) both here and directly as email to me. > > > Comments in no particular order, just as they occurred to me when > looking through your paper:- > > > > If a key is validated by the proxy, then subsequently uploaded again > with a new UID, does the new UID get a validation expiry date that > matches the rest of the key? Or does it get a standard 12-month > validation period, but still get re-validated the next time one of the > other UIDs needs it, so that all UIDs' validation expiry dates are > brought back into sync? And what if the upload with an extra UID hits > a different validation server? > Hmm, I didn't think about that in detail. But I would assume that because each validation validates a specific email address, a validation once each year is enough. I see no problem with both attempts: - - If the goal is to keep validations in sync, key owners might have to confirm emails added over the year earlier, which shouldn't be too bad. - - If the goal is to reduce validation requests, I see no problem to have different expiration dates. I think, because each email should be validated from time to time anyway (and this is an isolated process), each validation should give the 12 month period for the specific email when it is validated. Or do you see any problems? > If a third party has uploaded my key, or if the validation server is > automatically validating existing keys in response to certain events, > the validation emails are unsolicited by me. Most people will not > click a link in such an email. > OK, I agree (unless this feature is widely accepted ;-) ). So may be, for the beginning, validations can only be triggered when keys are uploaded (not when they are downloaded). > If a third party who can intercept my emails has generated a key > containing my email address in a UID, all bets are off. > This whole approach is NOT to make a perfect prove that the email is correct. It only says that the email did one day work for a validation of any kind, which is more than what we have now. That is, such a validation does not give full trust, it would only give slightly more trust over emails that do not have the validation. But that might be enough to solve the faked key issue. This is BTW no different than for any other validation email in common systems. They also don't give more guarantee. Thus this solution does NOT solve the problem of interception of emails. But it helps to detect them (if this happens the ct guys know that the problem is a lot worse than they thought) and helps in case this is the result of internet trolls. > If an email provider provides public keys for their customers, > presumably those keys are unsuitable for mail encryption because the > provider may have access to the private key. > It depends on whether and how far you trust the provider. Reality looks different (see startmail, posteo, riseup, and many company email servers). I don't claim to solve any problem in that area. User/clients might have to decide whether to trust a validation notation given by posteo, riseup, google, ... > The configuration changes for email clients that you mention, things > like which keyserver to use and which keys to trust, need to be set in > GnuPG.conf (or maybe some form of GnuPG wrapper or plugin) so that > they are used by an email client that simply calls GnuPG and therefore > honours GnuPG's own settings. Same for trust models; maybe you should > consider suggesting a modified trust model for GnuPG that includes > options for handling validation signatures. > THAT's a bigger step, but if Gnu wants to support it (which would mean that they think that this approach is fine), I am happy if this happens. For the moment I try to minimize additional requirements to be able to support this approach pretty fast (for people who want it). And I really try to got at least some solution for this problem, which I consider to be one show stopper to establish email encryption. > Blacklists should not be used *anywhere* as they are a form of > censorship and can be used for DOS attacks. > OK, don't we even have some blacklists in key servers? ;-) But I agree, that's something we have to discuss or find out in detail. > In your proposal for listing validation signatures in GnuPG: > "?!? after sig signals successful validation" - why is this needed? > Surely the mere presence of a validation signature signals successful > validation. > Hmm, Wener recommended to use --check-sigs rather than --list.sigs which then results in printing the '!'. Isn't it necessary in your opinion? > Why would the notation value be base64 encoded? What is the rationale > for preventing users from reading the notation values in a key > listing? > Hmm, it was a recommendation by Kristina Fiskerstrand: "the value should be base64 encoded to avoid some issues" @Kristian: Can you elaborate on that? > Notation version numbers. Rather than using different notation names > such as validation-v2 at enigmail.net, I would think it better to keep > the notation name standard and put the version number at the start of > the value string. > > Thanks Nico - -- Nicolai M. Josuttis www.josuttis.de mailto:nico at enigmail.net PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBCgAGBQJVtnCJAAoJEBwWpwr5LSj18ucQALZO/MAyIISvrJ9jpq0IoEv8 BkjSKcTdmkN3UT1mO5qTpDO/CtG0fumCMXruWLd3oMhPnxl9wItjt5ckEBUn45ow 4J0TcR5KvDEn+X6H0xa0SHGfz7p2kpjuaqLSTK8T1/12P3/ok1wk+z8gNJVcf/9o DzYiXNSfchH8ezfQ24a0tXwotcpjMIi3ravZ4St5ppX/DnsajBiSzOOi7YbT/kT7 l9kDmTDTFlQWn/5YtaLVmsK9SSNm1hXPdEZY+Sg2dsOi7aDqrPW5IvU1daBxZQCG w+xItKigSrLJF3cunx1k3nqwXIk0NceyW5JKR+qohZbx49eWLSXXlpbgg0A75kzx ZDBUPC1cZ8QTdVlm/4GAV2UgkmjyqvO60uV9gSw3Gbtc6jolEsSpfX7lvK3vH6ms oMopBCp4udsbBHEhqFeGAq4CyKQwnGSPiN7XK9O6YSVwcs2kX4WaqzG+/m//eIzy leCX99mar34BEx63s9uhgGYyJU6GAZVB0zy56hk5H0UQPUupomNqhgGwpzZulRg4 F51LpOoo7vkfyiS+TKCSQ3DdtBHmEGMGI5AVQB5yByfx1K2ai/Qd5xNfh9ajMjnZ +IiU05cxEy90+HvLLAwsh8E3vqvtsdYJn0pJwkEBptcGIAFVPIX1cJI1xJf1Z1dp DooS5ZJ+JOGXWZ7EUDd0 =Xfrv -----END PGP SIGNATURE----- From kristian.fiskerstrand at sumptuouscapital.com Mon Jul 27 19:54:14 2015 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Mon, 27 Jul 2015 19:54:14 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <87si895w9w.fsf@vigenere.g10code.de> References: <55B5C7B7.4090907@enigmail.net> <874mkpokxu.wl-neal@walfield.org> <87si895w9w.fsf@vigenere.g10code.de> Message-ID: <55B67046.5040400@sumptuouscapital.com> On 07/27/2015 07:46 PM, Werner Koch wrote: > On Mon, 27 Jul 2015 14:15, neal at walfield.org said: > > > You can't do that due to the decentralized approach with no > requirement for the user to always upload to the same keyserver. > Thus a server may miss validation signatures not yet received from > other servers. The way I read this proposal isn't about keyservers per se, but the individual validation servers publishing a chained list (like a blockchain) of its validations. There is merit to that proposal for auditing purposes, although I'm not entirely sure how it'd work in practice unless the blockchain itself was decentralized (it can't function securely if completely local to validation server). iirc this is what Google is doing with its approach as well[0]. References: [0] http://www.certificate-transparency.org/ -- ---------------------------- Kristian Fiskerstrand Blog: http://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 ---------------------------- "Knowing is not enough; we must apply. Willing is not enough; we must do." (Johann Wolfgang von Goethe) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Mon Jul 27 20:00:08 2015 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Mon, 27 Jul 2015 20:00:08 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <55B6708C.9090007@enigmail.net> References: <55B5C7B7.4090907@enigmail.net> <653170829.20150727141649@my_localhost> <55B6708C.9090007@enigmail.net> Message-ID: <55B671A8.7020109@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 07/27/2015 07:55 PM, nico at enigmail.net wrote: > Hi MFPA, Thanks a lot for your feedback. .. > >> Why would the notation value be base64 encoded? What is the >> rationale for preventing users from reading the notation values >> in a key listing? > > Hmm, it was a recommendation by Kristina Fiskerstrand: "the value > should be base64 encoded to avoid some issues" @Kristian: Can you > elaborate on that? It makes the information more compact and will make hkp vindex lists look cleaner. Presuming this information contains data objects in json format it will be interpreted by a parser, and raw data from keyservers anyways shouldn't be trusted directly before validating the signature (including its subpackets/notations) since no crypto has been performed at that point. - -- - ---------------------------- Kristian Fiskerstrand Blog: http://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 - ---------------------------- "Knowing is not enough; we must apply. Willing is not enough; we must do ." (Johann Wolfgang von Goethe) -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJVtnGkAAoJECULev7WN52FyFAIAKgXWzCuH8/k96sw+Bgw4Y5O fuAzTVTFk4D4UO9F0T1YIinfWNiDXV37sOGdGdgR5BGNGSyeXNU3R0GgyeM4NTaT K8UGnY2xwpY2wndi8rKpLVj5uoLofCrvhnrqJ1juuNHOXy0xuQarYwB5/5TWYfgT rBBMeIrEUgBita8Eh+7/0H4AkmRioTJIcHZDNqySqA5UF9ai6skcvVIoyh/zAmtH 230shQfx4XG4wJpWTRE7W0oCyEMBl38Pdno0c2GfJ7rHszpnk3DnOViyf9JHFzvI rjWP0DTP7CCsJ3N0YomphnDGxtpZyKJw3R8znk1CU3Q8quZ/R1dlkvF8alwGfxI= =XKeM -----END PGP SIGNATURE----- From nico at enigmail.net Mon Jul 27 20:19:07 2015 From: nico at enigmail.net (nico at enigmail.net) Date: Mon, 27 Jul 2015 20:19:07 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <1567894.c4elsytu3Z@collossus.ingo-kloecker.de> References: <55B5C7B7.4090907@enigmail.net> <1567894.c4elsytu3Z@collossus.ingo-kloecker.de> Message-ID: <55B6761B.5010609@enigmail.net> Hi Ingo, thanks a lot for the feedback. Am 27.07.2015 um 16:31 schrieb Ingo Kl?cker: > On Monday 27 July 2015 07:55:03 nico at enigmail.net wrote: >> Hi all, >> >> in March we discussed here >> "German ct magazine postulates death of pgp encryption" >> and Patrick Brunschwig proposed a way to validate email addresses >> >> I also had in mind: >>> http://lists.gnupg.org/pipermail/gnupg-users/2015-March/052882.html >> >> In the past months I tried to come up with a concrete proposal. >> I discussed it already with some people and >> this is what I/we propose so far. >> The proposal is not perfect and not completely worked out >> but IMO it is ready for a broader discussion and review. > > This whole concept of a whitelist of "trusted validation servers" included in > the email clients sounds a lot like the CA certificate bundles included in > browsers and/or OSes. Who is going to maintain this whitelist? The email > client developers? The OS manufactures? Who is going to certify "trusted > validation servers", i.e. who is going to tell benign validation servers apart > from malignant validation servers? > I agree that this is a key issue/problem of the approach. And indeed, I suggest to initially or by default give some trust to some signatures. Note that I propose different things, though: 1) A standard format for such validations. This simply would help to be able to deal with any validation approach. 2) A way to establish such validations by using a validating key server proxy. 3) A whitelist. I am happy to only have 1) and 2) and to teach people to trust e.g. specific servers (and to mistrust others). I only want to have a way to manage email validations (a common technique where everybody wonders why this is not supported). This is the best I could come up with after discussing this with several people. And so far it would be a lot more than we have now. It it might fix a problem which otherwise is a show stopper. If this is not appropriate, what do YOU propose instead for email validation? So many processes in this world are today based on email validation. Do you think that in general email validation is not the right approach or do you propose something different? > Your proposal seems to repeat a lot of the (failed) concepts of the > centralized CA approach. For this reason I think the approach is doomed to > fail the same way the centralized CA approach has failed (even if everybody > seems to ignore its failure). > I TRIED to avoid some of them: - avoiding to many signatures - providing no central solution It's the best I could come up with. I don't see any other form but may be you know better. Tell me! > I'd rather put my bets on a DANE-based approach like > https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ > I am happy with ANY solution here. I don't know all the details about DANE, but as far as I know it is promising but well not established yet. If we don#t need my proposal, great! But if establishing DANE will take more time or if there are some flaws with it), I would like to have this solution because IMO it would help. But I might be wrong. Thanks and all the best Nico BTW, the name sounds German and I am happy to discuss this whole issue with you in person. > > Regards, > Ingo -- Nicolai M. Josuttis www.josuttis.de mailto:nico at enigmail.net PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5 From neal at walfield.org Mon Jul 27 21:08:43 2015 From: neal at walfield.org (Neal H. Walfield) Date: Mon, 27 Jul 2015 21:08:43 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <55B66886.9070503@enigmail.net> References: <55B5C7B7.4090907@enigmail.net> <874mkpokxu.wl-neal@walfield.org> <55B66886.9070503@enigmail.net> Message-ID: <871tfto1tw.wl-neal@walfield.org> Hi Nico, At Mon, 27 Jul 2015 19:21:10 +0200, nico at enigmail.net wrote: > > Thanks, Neal for the feedback. > I will try to answer. > > Am 27.07.2015 um 14:15 schrieb Neal H. Walfield: > > Hi, > > > > I guess you mean this: > > > > The idea I have in mind is roughly as follows: if you upload a key to > > a keyserver, the keyserver would send an encrypted email to every UID > > in the key. Each encrypted mail contains a unique link to confirm the > > email address. Once all email addresses are confirmed, the key is > > validated and the keyserver will allow access to it just like with any > > regular keyserver. > > > Hmm, not quite right, there are two major points where I think > there is some misunderstanding: If this is not right please point me to the proposal. The above is just a quote from the single source in your original email. After I read that I will respond to your other questions / comments. :) Neal From juanmi.3000 at gmail.com Mon Jul 27 21:22:08 2015 From: juanmi.3000 at gmail.com (=?UTF-8?Q?Juan_Miguel_Navarro_Mart=c3=adnez?=) Date: Mon, 27 Jul 2015 21:22:08 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <871tfto1tw.wl-neal@walfield.org> References: <55B5C7B7.4090907@enigmail.net> <874mkpokxu.wl-neal@walfield.org> <55B66886.9070503@enigmail.net> <871tfto1tw.wl-neal@walfield.org> Message-ID: <55B684E0.2020807@gmail.com> On 2015/07/27 at 21:08, Neal H. Walfield wrote: > If this is not right please point me to the proposal. The above is > just a quote from the single source in your original email. After I > read that I will respond to your other questions / comments. > > :) Neal > It's attached in the OP named "OpenPGP-Email-Validation-20150726.pdf" -- Juan Miguel Navarro Mart?nez GPG Keyfingerprint: 5A91 90D4 CF27 9D52 D62A BC58 88E2 947F 9BC6 B3CF From mlisten at hammernoch.net Mon Jul 27 21:05:26 2015 From: mlisten at hammernoch.net (=?UTF-8?B?THVkd2lnIEjDvGdlbHNjaMOkZmVy?=) Date: Mon, 27 Jul 2015 21:05:26 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <1567894.c4elsytu3Z@collossus.ingo-kloecker.de> References: <55B5C7B7.4090907@enigmail.net> <1567894.c4elsytu3Z@collossus.ingo-kloecker.de> Message-ID: <55B680F6.40701@hammernoch.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Ingo, On 27.07.15 16:31, Ingo Kl?cker wrote: > This whole concept of a whitelist of "trusted validation servers" > included in the email clients sounds a lot like the CA certificate > bundles included in browsers and/or OSes. Who is going to maintain > this whitelist? Whilelists: The OpenPGP-aware clients. There aren't so many of them, so that's manageable. > The email client developers? The OS manufactures? Who is going to > certify "trusted validation servers", i.e. who is going to tell > benign validation servers apart from malignant validation servers? There is a community providing keyservers (such as pool.sks-keyservers.net). My impression is that this network is well maintained and has worked reliably the last years. Why should there not be a similar community approach for setting up a (smaller) network of validating key server proxies. > I'd rather put my bets on a DANE-based approach like > https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ DANE requires write access to DNS. I don't see that the average OpenPGP user has facilities and knowledge to achieve setting up the required DNS records. If you can't convince the big mail providers (e.g. Google, GMX here in Germany, ...) to provide a reasonable interface for their users, I'm afraid that this will not be a success, Ludwig -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJVtoDzAAoJEDrb+m0Aoeb+/NcP/ioUVK5tlkZ7bXlkiKKtaB1f 7EpTqpkg2gIY0ev6xhAWwLoDsACLX/iCmVu+OHgJbRFYo/e5m6FHzxpWEMMxgsON Dn7yuuHtxDxWQmX3LzPzG3GU3x2ynKuR7V5iyj4p1fbVYmijaIraOpbPaM5wKjP+ 2m5+QZjAHrHzFIrj4LadiaJmCn5HVfGcttqxc3I8u/oQl3uXoB1XTIa+Xf5lt2vG 7FUchBZCWSZVzShLk2PYU9ZYHK1/oMYFBS0qMgYtZeGnuCMUUbKFsPjfaqEAq/I9 95dxk9GSssxdANGFjyT9Q1fMdrJOdi/rAENCzHHQ+Tmj6Aa2cn46DNxjiqEjA77V YPvlLm9Sjec/UvpaJ3aYVhu+uHl7FwEsNe+ZA1W/y9HmdISCrmorpHi3SOCGJIWR PbGmRthYjDPQ7wK0naQ5my5prum586Cs9dloHMFuW/1jd7K2rC8GkOhR2KDpsHr3 L1sGovfBtahy3uVOOvqILZzX61qen9ACd/7XJBXOYurytgzXFzz8FtRehdwf31Of 3VnprnXPIWwOQ6Xj0lcilw3Ff3t8T2PgJqLftBxF+64bqtlP63XzFMNWo87a0nbo WfG13WHLdBEmWo2TiAA8EHFWCCW+HlGVclo+5mR/NBgFKlZhF4kAhgcaTwLvP6ke TnJfQ7Ba8btK1vP/5nfq =L7BF -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Mon Jul 27 23:31:45 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 27 Jul 2015 17:31:45 -0400 Subject: Next Big Future on quantum computation Message-ID: <55B6A341.20701@sixdemonbag.org> Some people have been all abuzz over this article lately: http://nextbigfuture.com/2015/07/currently-quantum-computers-might-be.html Rather than go through it point by point I'm just going to talk about the author's closing paragraph, which one would expect to have been pretty closely checked prior to publication. "Getting 1.4 million times speedup over a single CPU is possible now with a Google data center. In ten to 15 years it could be inside one rack of future conventional computers. If that rack of computers could not solve your NP-hard problem you could use it for many other revenue generating and useful applications." The first "wait, what did you just say?" was his assertion that it's possible to get a 1.4 millionfold speedup over a single CPU with the money it would take to build a Google data center. If it was possible, don't you think Google, Microsoft, Apple, and Facebook would *already be building them*? Entrepreneurs who can afford to do this are overwhelmingly choosing not to do this. When the people who should be doing it aren't, think hard and think twice. His next claim is just ... it makes no sense to me. "If that rack of [quantum] computers could not solve your NP-hard problem..." Point blank: quantum computers cannot solve NP-Hard problems. Period, end of sentence. NP-Hard is where the ridiculously difficult problems live. If you had a computer that could break NP-Hard problems, you could literally crack one-time pads, predict the future, solve the Halting Problem, reverse entropy, and essentially become a god. Okay, so maybe the author had a goof. Maybe he meant NP-Complete. That's better, right? If that rack of computers couldn't solve your NP-Complete problem you could use it for many other revenue generating and useful applications. Except that, by definition, if you're unable to solve *one* NP-Complete problem, you're unable to solve *any* NP-Complete problem. It's an all-or-nothing deal. You can either solve everything in NP-Complete, or nothing. No in-betweens. So reading his sentence as "couldn't solve your NP-Complete problem" doesn't improve it. Can't solve one, can't solve any. Let's scale it back some more. Maybe he meant "If that rack of computers couldn't solve your NP problem you could...". Okay. Now we're getting kind of close to reality, except that NP is a *big* class of algorithms -- this is like asking someone to find your lost dog and saying you're pretty sure you left him in Australia. It's too vague to really be meaningful. NP is like that, but its Outback is bigger. Take it back a step further: "If that rack of computers could not solve your BQP problem you could..." BQP is the set of all algorithms that can be efficiently solved with a quantum computer. If that rack of computers can't solve a BQP problem, then maybe you should consider whether you've been defrauded. So that sentence there -- * Can't be true for NP-Hard: you're not a god. * Is nonsense for NP-Complete: if you can't solve one, you can't solve any. * Isn't particularly well-defined for NP. * Is trivially true for BQP. ... I'm a thesis shy of a Ph.D. in computer science and I've got absolutely no idea what the author meant by what he said in that paragraph. None. Zero. It sounds nice but I'm at a loss to explain what it means. I'm not an expert on rocketry, so I won't comment on those parts of the essay. But the computer science parts of the essay are all like this: they're superficially glib but they're just plain *bad*. Also, check out the author's bio/resume: http://lifeboat.com/ex/bios.brian.l.wang From josef at netpage.dk Mon Jul 27 21:09:19 2015 From: josef at netpage.dk (Josef Schneider) Date: Mon, 27 Jul 2015 21:09:19 +0200 Subject: One Key, multiple Smartcards not working anymore Message-ID: <55B681DF.5040107@netpage.dk> Hello, I have a problem with my Key. I have a 4096bit RSA key since 2012 and it is stored on a OpenPGP smartcard. Recently I added three new 2048bit subkeys, because I bought a Yubikey NEO device and want to use PGP on my phone/tablet with Android and NFC. This worked as expected. I created the new subkeys on my PC, saved a backup and then moved them to the card. PGP showed me correctly that the first three keys are on card 1 and the second three are on card 2. If the wrong card was inserted, it asked me to insert the correct one. I then wanted to create one key backup with all six private keys to print using PaperBack and store in a safe place. I was able to merge all the private keys with gpgsplit and moving/renaming files and created that backup. After that, I deleted the whole key, got my public key from the keyservers and tried to use it with the card (after gpg2 --card-status). Here is now my problem: GPG adds the key stub for the smartcard keys only for the first card! If I delete the key, import, use card-status, then I can usse the three keys from that smartcard. If I insert the second smartcard and do a card-status, nothing changes! If I import the full key with all private keys, I can then replace the keys on the card and move all keys to smartcards. Then I get a key working with both smartcards again. But of course I don't want to touch the key backup. It's printed on paper and stored in a safe location for a reason. Am I doing something wrong, or is that a bug? Here are some gpg outputs: At the moment, I have it here on my notebook working with the 4096bit keys: sec> 4096R/9BE45ED0 2012-12-10 [verf?llt: 2017-04-13] Kartenseriennr. = 0005 XXXXXXXX uid Josef Schneider uid Josef Schneider ssb> 4096R/B641DD11 2012-12-10 ssb> 4096R/CA02F8EA 2012-12-10 ssb# 2048R/988E7DDD 2015-07-07 ssb# 2048R/03E021FE 2015-07-07 ssb# 2048R/8B406748 2015-07-07 I insert the other card and do a card-status: C:\Users\Josef Schneider>gpg --card-status Application ID ...: DXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Version ..........: 2.0 Manufacturer .....: Yubico Serial number ....: XXXXXXXX Name of cardholder: Josef Schneider Language prefs ...: de Sex ..............: m?nnlich URL of public key : https://j0s.at/gpg.asc Login data .......: [nicht gesetzt] Signature PIN ....: zwingend Key attributes ...: 2048R 2048R 2048R Max. PIN lengths .: 127 127 127 PIN retry counter : 3 3 3 Signature counter : 39 Signature key ....: 50FD 3663 AB67 A8FD 64BD C208 1272 58BE 988E 7DDD created ....: 2015-07-07 11:34:08 Encryption key....: 88FA 7314 795F 5F19 F258 3B70 E18B C1D9 03E0 21FE created ....: 2015-07-07 11:38:08 Authentication key: E0E5 13F9 AA97 8C8E 1BF5 27FB B6BF D0F7 8B40 6748 created ....: 2015-07-07 20:15:08 General key info..: pub 2048R/988E7DDD 2015-07-07 Josef Schneider sec> 4096R/9BE45ED0 erzeugt: 2012-12-10 verf?llt: 2017-04-13 Kartennummer:0005 XXXXXXXX ssb> 4096R/B641DD11 erzeugt: 2012-12-10 verf?llt: niemals Kartennummer:0005 XXXXXXXX ssb> 4096R/CA02F8EA erzeugt: 2012-12-10 verf?llt: niemals Kartennummer:0005 XXXXXXXX ssb# 2048R/988E7DDD erzeugt: 2015-07-07 verf?llt: 2017-07-06 ssb# 2048R/03E021FE erzeugt: 2015-07-07 verf?llt: 2017-07-06 ssb# 2048R/8B406748 erzeugt: 2015-07-07 verf?llt: 2017-10-24 I can't use this key. After deleting it and import https://j0s.at/gpg.asc : C:\Users\Josef Schneider>gpg --card-status Application ID ...: DXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Version ..........: 2.0 Manufacturer .....: Yubico Serial number ....: XXXXXXXX Name of cardholder: Josef Schneider Language prefs ...: de Sex ..............: m?nnlich URL of public key : https://j0s.at/gpg.asc Login data .......: [nicht gesetzt] Signature PIN ....: zwingend Key attributes ...: 2048R 2048R 2048R Max. PIN lengths .: 127 127 127 PIN retry counter : 3 3 3 Signature counter : 40 Signature key ....: 50FD 3663 AB67 A8FD 64BD C208 1272 58BE 988E 7DDD created ....: 2015-07-07 11:34:08 Encryption key....: 88FA 7314 795F 5F19 F258 3B70 E18B C1D9 03E0 21FE created ....: 2015-07-07 11:38:08 Authentication key: E0E5 13F9 AA97 8C8E 1BF5 27FB B6BF D0F7 8B40 6748 created ....: 2015-07-07 20:15:08 General key info..: pub 2048R/988E7DDD 2015-07-07 Josef Schneider sec# 4096R/9BE45ED0 erzeugt: 2012-12-10 verf?llt: 2017-04-13 ssb# 4096R/B641DD11 erzeugt: 2012-12-10 verf?llt: niemals ssb# 4096R/CA02F8EA erzeugt: 2012-12-10 verf?llt: niemals ssb> 2048R/988E7DDD erzeugt: 2015-07-07 verf?llt: 2017-07-06 Kartennummer:0006 XXXXXXXX ssb> 2048R/03E021FE erzeugt: 2015-07-07 verf?llt: 2017-07-06 Kartennummer:0006 XXXXXXXX ssb> 2048R/8B406748 erzeugt: 2015-07-07 verf?llt: 2017-10-24 Kartennummer:0006 XXXXXXXX I can use the 2048bit keys, but not the 4096 After inserting the first card again: C:\Users\Josef Schneider>gpg --card-status Application ID ...: DXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Version ..........: 2.0 Manufacturer .....: ZeitControl Serial number ....: XXXXXXXX Name of cardholder: Schneider Josef Language prefs ...: de Sex ..............: m?nnlich URL of public key : https://netpage.dk/gpg.asc Login data .......: - Signature PIN ....: zwingend Key attributes ...: 4096R 4096R 4096R Max. PIN lengths .: 32 32 32 PIN retry counter : 3 0 3 Signature counter : 250 Signature key ....: CA77 342B 856C 9D5B B0B6 C23C 3140 E873 9BE4 5ED0 created ....: 2012-12-10 00:01:57 Encryption key....: DE61 0EF1 5124 2A64 400B 9968 4CBB 978B B641 DD11 created ....: 2012-12-10 00:01:57 Authentication key: 3E9E 5480 F676 B9D6 6632 49A2 E1D8 2ECC CA02 F8EA created ....: 2012-12-10 00:03:06 General key info..: pub 4096R/9BE45ED0 2012-12-10 Josef Schneider sec# 4096R/9BE45ED0 erzeugt: 2012-12-10 verf?llt: 2017-04-13 ssb# 4096R/B641DD11 erzeugt: 2012-12-10 verf?llt: niemals ssb# 4096R/CA02F8EA erzeugt: 2012-12-10 verf?llt: niemals ssb> 2048R/988E7DDD erzeugt: 2015-07-07 verf?llt: 2017-07-06 Kartennummer:0006 XXXXXXXX ssb> 2048R/03E021FE erzeugt: 2015-07-07 verf?llt: 2017-07-06 Kartennummer:0006 XXXXXXXX ssb> 2048R/8B406748 erzeugt: 2015-07-07 verf?llt: 2017-10-24 Kartennummer:0006 XXXXXXXX Still can't use the 4096bit keys. If I want to use the 2048bit keys, GPG asks me correctly to inert the other card and then it works. All with gpg (GnuPG) 2.0.28 (Gpg4win 2.2.5) I hope someone can help me figure that out. Best regards, Josef -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Tue Jul 28 00:01:26 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 27 Jul 2015 18:01:26 -0400 Subject: Next Big Future on quantum computation In-Reply-To: <55B6A341.20701@sixdemonbag.org> References: <55B6A341.20701@sixdemonbag.org> Message-ID: <55B6AA36.3040009@sixdemonbag.org> > Point blank: quantum computers cannot solve NP-Hard problems. Period, > end of sentence. NP-Hard is where the ridiculously difficult problems > live. For those who like pedantry: NP-Hard is the name given to any problem that is as hard, or harder, than any problem in NP. The Traveling Salesman Problem is NP, and is known to be as hard as any problem in NP, therefore it's NP-Hard. But it's also the *easiest* NP-Hard. Because remember, NP-Hard is anything as hard *or harder* than anything in NP. Playing a perfect game of Go isn't in NP, ergo playing a perfect game of Go is NP-Hard. NP-Hard is a collective term that covers a truly staggering amount of terrain, going from the "easy" problems like traveling salesman all the way up to the "are you kidding me?" like reversing entropy. Few computer scientists like talking about NP-Hard. It's simply too big of a space. And if anyone seriously talks about a general technique that works on NP-Hard problems, they get laughed at. Lots. Because there isn't one, and we've formally proven there isn't one. This was the proof that made Alan Turing famous. From 2014-667rhzu3dc-lists-groups at riseup.net Tue Jul 28 00:56:50 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Mon, 27 Jul 2015 23:56:50 +0100 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <55B62526.9000906@dabpunkt.eu> References: <55B5C7B7.4090907@enigmail.net> <874mkpokxu.wl-neal@walfield.org> <55B62526.9000906@dabpunkt.eu> Message-ID: <1808038406.20150727235650@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Monday 27 July 2015 at 1:33:42 PM, in , Daniel Baur wrote: > What could be a problem: The state or the ISP could > create a key-pair of its own and upload it, intercept > the mail and verify it. That certainly would be a problem. I've no idea how likely. - -- Best regards MFPA None are so fond of secrets as those who do not mean to keep them -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJVtrc7XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwFO0H/AlkbVUjVPqi46W3sSaQjxR6 LmQrNbaUzHDdwWWNgBfUCciejRzkwgFUtxCwuMogzsGbObdBVtMsBk8XCkGYoG1O 5mPLyiKP1Mz5mburJZsphrrmwSsH3gjy7Fspa7GnmGkZk3EwdE8AHLEoazViTfQu ELU0vtJMapqvccafMYLTFnzwm+eaJivtiLlPhL+kBX5opgK4BfB73uw1M3VW9OHl XP1nKgEO7v8WUVIDkdnyP6fYILdSWAjqdYeQvaIjl8XkJntcnVR2LVZ5fTRNSnbW imo+ihOskkjMT0Y5GEsgK8KtcG6MYaq1jb+ffbeZtoIy8f40hjF1890FgfEBPYWI vgQBFgoAZgUCVba3Q18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45CjfAQCwdabfoGT+SvHNxpQirKYVNF8+ j2lNxxAPC/QYCY+dAwEA7s2QOoHqmgyghBc//is7xFDt3Q0wAyUhE0cuYCKbAg4= =qn4S -----END PGP SIGNATURE----- From neal at walfield.org Tue Jul 28 01:28:10 2015 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 28 Jul 2015 01:28:10 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <55B6539C.6040302@enigmail.net> References: <55B5C7B7.4090907@enigmail.net> <874mkpokxu.wl-neal__30091.3890744143$1437999461$gmane$org@walfield.org> <55B6539C.6040302@enigmail.net> Message-ID: <87zj2hmb91.wl-neal@walfield.org> At Mon, 27 Jul 2015 17:51:56 +0200, Patrick Brunschwig wrote: > > On 27.07.15 14:15, Neal H. Walfield wrote: > > Hi, > > > > I guess you mean this: > > > > The idea I have in mind is roughly as follows: if you upload a key to > > a keyserver, the keyserver would send an encrypted email to every UID > > in the key. Each encrypted mail contains a unique link to confirm the > > email address. Once all email addresses are confirmed, the key is > > validated and the keyserver will allow access to it just like with any > > regular keyserver. > > > > This approach is not going to stop a nation state. A nation state can > > intercept the mail, decrypt it and follow the link. > > If the email can be decrypted, then any email can be decrypted, which > would turn OpenPGP useless. Sorry. This was definately unclear. What I meant is: a nation state can create a "fake" key, upload it to the key server and intercept the mail encrypted to the fake key thereby validating the fake key. > In any case, the target users are not the Edward Snowdens of this world, > but the 99% of people who just want to communicate easily with each > other and don't want to be bothered too much with key complicated key > lookup/verification scenarios. This is a worthy goal :). :) Neal From neal at walfield.org Tue Jul 28 09:22:23 2015 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 28 Jul 2015 09:22:23 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <55B5C7B7.4090907@enigmail.net> References: <55B5C7B7.4090907@enigmail.net> Message-ID: <87y4i0n3v4.wl-neal@walfield.org> Hi, Did you consider user a proof-of-work scheme? For instance, the user does a 1 week PoW, signs the result and attackes it to the key. These would be refreshed about once a year. This eliminates the verification servers and the problems associated with them (namely, people need to trust them and there can't be too many of them). It also increases usability: there are no emails. This can be done completely by, say, gpg-agent in the background. gpg (or the email clients) don't need to know about special verification keys / signatures. They just check the proof of work and sort the returned keys appropriately. Neal From wk at gnupg.org Tue Jul 28 09:44:37 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 28 Jul 2015 09:44:37 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <55B67046.5040400@sumptuouscapital.com> (Kristian Fiskerstrand's message of "Mon, 27 Jul 2015 19:54:14 +0200") References: <55B5C7B7.4090907@enigmail.net> <874mkpokxu.wl-neal@walfield.org> <87si895w9w.fsf@vigenere.g10code.de> <55B67046.5040400@sumptuouscapital.com> Message-ID: <87h9oo680q.fsf@vigenere.g10code.de> On Mon, 27 Jul 2015 19:54, kristian.fiskerstrand at sumptuouscapital.com said: > The way I read this proposal isn't about keyservers per se, but the > individual validation servers publishing a chained list (like a Right. I assume that these validation servers still work like the the regualr keyservers and sync between them. The question about the implementaion language of SKS indated to me that the validation servers are based on that protocol and would thus also use the Gossip protocol. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Jul 28 15:34:29 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 28 Jul 2015 15:34:29 +0200 Subject: gpg 2.1.6 toggle doesn't In-Reply-To: <55B60BF1.3040900@kset.org> ("Marko =?utf-8?B?Qm/Fvmlrb3Zp?= =?utf-8?B?xIciJ3M=?= message of "Mon, 27 Jul 2015 11:46:09 +0100") References: <55B0FA83.20506@kset.org> <253829032.20150725132637@my_localhost> <55B5F04B.109@kset.org> <55B5F3F6.90700@sumptuouscapital.com> <55B5F681.1070002@sumptuouscapital.com> <55B60BF1.3040900@kset.org> Message-ID: <87pp3c4d96.fsf@vigenere.g10code.de> On Mon, 27 Jul 2015 12:46, bozho at kset.org said: > I know that, and I'm using 2.1 exclusively... Still, it would be nice to be > able to see the state of private keys (e.g. primary key not present in the > keyring, private keys are on the card, etc) while editing keys. It seems Right, that makes sense. As of now you only see "Secret key is available" if any secret key is availabale but you won't see any indication which subkey also has a secret key. What about using pub/sec or sub/ssb depending on whether a secret key is available? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bozho at kset.org Tue Jul 28 15:58:04 2015 From: bozho at kset.org (=?UTF-8?B?TWFya28gQm/Fvmlrb3ZpxIc=?=) Date: Tue, 28 Jul 2015 14:58:04 +0100 Subject: gpg 2.1.6 toggle doesn't In-Reply-To: <87pp3c4d96.fsf@vigenere.g10code.de> References: <55B0FA83.20506@kset.org> <253829032.20150725132637@my_localhost> <55B5F04B.109@kset.org> <55B5F3F6.90700@sumptuouscapital.com> <55B5F681.1070002@sumptuouscapital.com> <55B60BF1.3040900@kset.org> <87pp3c4d96.fsf@vigenere.g10code.de> Message-ID: <55B78A6C.1090009@kset.org> On 28/07/2015 14:34, Werner Koch wrote: > On Mon, 27 Jul 2015 12:46, bozho at kset.org said: > >> I know that, and I'm using 2.1 exclusively... Still, it would be nice to be >> able to see the state of private keys (e.g. primary key not present in the >> keyring, private keys are on the card, etc) while editing keys. It seems > > Right, that makes sense. As of now you only see "Secret key is > available" if any secret key is availabale but you won't see any > indication which subkey also has a secret key. > > What about using pub/sec or sub/ssb depending on whether a secret key > is available? > Yes, that would be good. When we're talking about private keys "not being there", is there a difference between a private key that has been deleted from your own keypair and a private key that's never been there (i.e. you only have someone else's public key)? Also, the indicator that the private key is present on the card (> in the gpg -K output) would be useful in gpg --edit-key output. Thank you, -- Marko From kloecker at kde.org Tue Jul 28 16:46:54 2015 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Tue, 28 Jul 2015 16:46:54 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <55B680F6.40701@hammernoch.net> References: <55B5C7B7.4090907@enigmail.net> <1567894.c4elsytu3Z@collossus.ingo-kloecker.de> <55B680F6.40701@hammernoch.net> Message-ID: <1865150.UFN610AODu@collossus.ingo-kloecker.de> On Monday 27 July 2015 21:05:26 Ludwig H?gelsch?fer wrote: > Hi Ingo, > > On 27.07.15 16:31, Ingo Kl?cker wrote: > > This whole concept of a whitelist of "trusted validation servers" > > included in the email clients sounds a lot like the CA certificate > > bundles included in browsers and/or OSes. Who is going to maintain > > this whitelist? > > Whilelists: The OpenPGP-aware clients. There aren't so many of them, > so that's manageable. Speaking for KMail how can I be sure that somebody who claims that his validation server can be trusted can actually be trusted and should therefore be added to the whitelist? KDE avoids this problem for the CA certificate bundle by relying on the certificate bundles provided by the Linux distributors or by Mozilla. > > The email client developers? The OS manufactures? Who is going to > > certify "trusted validation servers", i.e. who is going to tell > > benign validation servers apart from malignant validation servers? > > There is a community providing keyservers (such as > pool.sks-keyservers.net). My impression is that this network is well > maintained and has worked reliably the last years. > > Why should there not be a similar community approach for setting up a > (smaller) network of validating key server proxies. Well, the keyservers do not make any claims with regard to the authenticity or the integrity of the keys. Those checks are left to the clients. I do not have to trust any of the keyservers. The validating key server proxies claim validity of the UIDs (to a certain degree). I can see myself marking such a proxy as trusted by adding it to my gnupg.conf (or to KMail's configuration). But I cannot see myself adding such a proxy to the whitelist that's shipped with KMail. Another problem I see with whitelist management is revocation in case the validation key of a validating proxy is compromised. Again, for the CA certificate bundles that's handled by the distributors and not by individual application developers. > > I'd rather put my bets on a DANE-based approach like > > https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ > > DANE requires write access to DNS. I don't see that the average > OpenPGP user has facilities and knowledge to achieve setting up the > required DNS records. If you can't convince the big mail providers > (e.g. Google, GMX here in Germany, ...) to provide a reasonable > interface for their users, I'm afraid that this will not be a success, I'm confident that the smaller mail providers who focus on security would be willing to add such an interface. Frankly, I do not care that much for the big mail providers. People who really value privacy should use mail providers that value privacy. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From kloecker at kde.org Tue Jul 28 16:56:08 2015 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Tue, 28 Jul 2015 16:56:08 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <55B6761B.5010609@enigmail.net> References: <55B5C7B7.4090907@enigmail.net> <1567894.c4elsytu3Z@collossus.ingo-kloecker.de> <55B6761B.5010609@enigmail.net> Message-ID: <3241286.FAChBxhklG@collossus.ingo-kloecker.de> On Monday 27 July 2015 20:19:07 nico at enigmail.net wrote: > Am 27.07.2015 um 16:31 schrieb Ingo Kl?cker: > > This whole concept of a whitelist of "trusted validation servers" included > > in the email clients sounds a lot like the CA certificate bundles > > included in browsers and/or OSes. Who is going to maintain this > > whitelist? The email client developers? The OS manufactures? Who is going > > to certify "trusted validation servers", i.e. who is going to tell benign > > validation servers apart from malignant validation servers? > > I agree that this is a key issue/problem of the approach. > And indeed, I suggest to initially or by default give some trust > to some signatures. > > Note that I propose different things, though: > 1) A standard format for such validations. > This simply would help to be able to deal with any > validation approach. > 2) A way to establish such validations > by using a validating key server proxy. > 3) A whitelist. > > I am happy to only have 1) and 2) and to teach people > to trust e.g. specific servers (and to mistrust others). > > I only want to have a way to manage email validations > (a common technique where everybody wonders why this > is not supported). > This is the best I could come up with after discussing this > with several people. > And so far it would be a lot more than we have now. > It it might fix a problem which otherwise is a show stopper. > > If this is not appropriate, what do YOU propose instead > for email validation? > So many processes in this world are today based on email validation. > Do you think that in general email validation is not the right approach > or do you propose something different? I'm not against your proposal per se. In fact, I'm probably one of the few people who actually think that the email validation done by PGP.com has some value. Consequently, I am also seeing the value in your proposal. I'm just having reservations with regard to the whitelists. See my reply to Ludwig's reply. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From kloecker at kde.org Tue Jul 28 17:06:28 2015 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Tue, 28 Jul 2015 17:06:28 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <87y4i0n3v4.wl-neal@walfield.org> References: <55B5C7B7.4090907@enigmail.net> <87y4i0n3v4.wl-neal@walfield.org> Message-ID: <1517713.Bk1xnoONrS@collossus.ingo-kloecker.de> On Tuesday 28 July 2015 09:22:23 Neal H. Walfield wrote: > Hi, > > Did you consider user a proof-of-work scheme? For instance, the user > does a 1 week PoW, signs the result and attackes it to the key. These > would be refreshed about once a year. Which problem do you propose to address with such a scheme? I can see the zombie key issue being addressed by this, but this issue can as easily be addressed by 1-year-key-expiration (where the PoW consists of extending the expiration date). I don't see how a PoW scheme addresses the fake key issue. Someone who is motivated enough to create a fake key will most likely also be motivated enough to add a PoW (at least, for the first year). Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From patrick at enigmail.net Tue Jul 28 18:05:42 2015 From: patrick at enigmail.net (Patrick Brunschwig) Date: Tue, 28 Jul 2015 18:05:42 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <1865150.UFN610AODu__44049.5751020082$1438094932$gmane$org@collossus.ingo-kloecker.de> References: <55B5C7B7.4090907@enigmail.net> <1567894.c4elsytu3Z@collossus.ingo-kloecker.de> <55B680F6.40701@hammernoch.net> <1865150.UFN610AODu__44049.5751020082$1438094932$gmane$org@collossus.ingo-kloecker.de> Message-ID: <55B7A856.6070805@enigmail.net> On 28.07.15 16:46, Ingo Kl?cker wrote: > On Monday 27 July 2015 21:05:26 Ludwig H?gelsch?fer wrote: >> Hi Ingo, >> >> On 27.07.15 16:31, Ingo Kl?cker wrote: >>> This whole concept of a whitelist of "trusted validation servers" >>> included in the email clients sounds a lot like the CA certificate >>> bundles included in browsers and/or OSes. Who is going to maintain >>> this whitelist? >> >> Whilelists: The OpenPGP-aware clients. There aren't so many of them, >> so that's manageable. > > Speaking for KMail how can I be sure that somebody who claims that his > validation server can be trusted can actually be trusted and should therefore > be added to the whitelist? KDE avoids this problem for the CA certificate > bundle by relying on the certificate bundles provided by the Linux > distributors or by Mozilla. Let's face it: KDE doesn't /avoid/ this problem. It just shifts the problem to someone else -- the Linux distributors or Mozilla ;) -Patrick From hn000246 at gmail.com Tue Jul 28 17:33:30 2015 From: hn000246 at gmail.com (Programador IBMi) Date: Tue, 28 Jul 2015 09:33:30 -0600 Subject: Setting Up a User with Private Digital Keys (Error Msg) Message-ID: Hello Guys, Greetings from Honduras, It's my first time using gng from the AS400 (IBMi) but when I'm trying to setting up a user with private key, I'm getting an error: Command: gpg --gen-key Error: gpg: cannot open `/dev/tty': No such device or address Could you help me to solve this issue? Best Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Tue Jul 28 18:27:49 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 28 Jul 2015 18:27:49 +0200 Subject: gpg 2.1.6 toggle doesn't In-Reply-To: <55B78A6C.1090009@kset.org> ("Marko =?utf-8?B?Qm/Fvmlrb3Zp?= =?utf-8?B?xIciJ3M=?= message of "Tue, 28 Jul 2015 14:58:04 +0100") References: <55B0FA83.20506@kset.org> <253829032.20150725132637@my_localhost> <55B5F04B.109@kset.org> <55B5F3F6.90700@sumptuouscapital.com> <55B5F681.1070002@sumptuouscapital.com> <55B60BF1.3040900@kset.org> <87pp3c4d96.fsf@vigenere.g10code.de> <55B78A6C.1090009@kset.org> Message-ID: <87k2tk458a.fsf@vigenere.g10code.de> On Tue, 28 Jul 2015 15:58, bozho at kset.org said: > When we're talking about private keys "not being there", is there a difference > between a private key that has been deleted from your own keypair and a > private key that's never been there (i.e. you only have someone else's public You can't know. The presence of the secret key data file in private-keys-v1.d is the only indicator whether there is a secret key. ("secret key" and "private key" are equivalent in OpenPGP parlance) > Also, the indicator that the private key is present on the card (> in the gpg > -K output) would be useful in gpg --edit-key output. Right. I'll check whether this can be done easily. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From 2014-667rhzu3dc-lists-groups at riseup.net Tue Jul 28 19:26:07 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Tue, 28 Jul 2015 18:26:07 +0100 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <55B6708C.9090007@enigmail.net> References: <55B5C7B7.4090907@enigmail.net> <653170829.20150727141649@my_localhost> <55B6708C.9090007@enigmail.net> Message-ID: <83911986.20150728182607@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Monday 27 July 2015 at 6:55:24 PM, in , nico at enigmail.net wrote: > If the > goal is to keep validations in sync, key owners might > have to confirm emails added over the year earlier, > which shouldn't be too bad. - - If the goal is to > reduce validation requests, I see no problem to have > different expiration dates. I think, because each email > should be validated from time to time anyway (and this > is an isolated process), each validation should give > the 12 month period for the specific email when it is > validated. Or do you see any problems? I just think if I was to receive revalidation requests all at the same time I would be less likely to overlook those for little-used email addresses I do not often check. It also keeps it neat. > This whole approach is NOT to make a perfect prove that > the email is correct. Nothing is perfect. Even meeting up and verifying government-issued ID documents can be defeated by good quality fake documents. > It only says that the email did > one day work for a validation of any kind, which is > more than what we have now. We have the Web of Trust to demonstrate that. But those are generally one-off signatures on a key, and may be quite a few years old. Some email providers recycle addresses, so an address Bob used a few months or years ago could now be under Alice's, or even Mallory's, control. As far as I see it, your scheme adds two things: periodic revalidation, and an easy way to get a signature on your key without having to meet anybody. > That is, such a validation > does not give full trust, it would only give slightly > more trust over emails that do not have the validation. Indeed. I think an annual revalidation period strikes a reasonable balance, although maybe there are email services that recycle addresses more quickly than that. > But that might be enough to solve the faked key issue. Are there really many "faked" keys, rather than keys that are no longer used, forgotten passphrase, lost private key, etc.? > this solution does NOT solve the > problem of interception of emails. But it helps to > detect them How does this help to detect interception of emails? > It depends on whether and how far you trust the > provider. Reality looks different (see startmail, > posteo, riseup, and many company email servers). I > don't claim to solve any problem in that area. > User/clients might have to decide whether to trust a > validation notation given by posteo, riseup, google, > ... Company email servers, I would expect companies as a matter of course to have a means to decrypt their employees' emails. I'm shocked to read [0] that Riseup once had a webmail option that stored the user's public and private keys. Riseup now tells [1] users who want to use encrypted email to utilize an email client to send and receive email, while keeping their private key stored safely on their local machine. [0] [1] Startmail sounds like a similar concept to Hushmail, which was compromised by a court order obtained through a mutual assistance treaty. It is not clear to me why Startmail would not be expected to suffer the same fate. Posteo looks interesting. But their overview says end-to-end encryption is done by the user in addition to Posteo's own security measures, so the user would have to generate and store their own keys. And Google make a living out of exploiting data mined from users' emails and search activities. Why would anybody trust them? >> In your proposal for listing validation signatures in >> GnuPG: "?!? after sig signals successful validation" - >> why is this needed? Surely the mere presence of a >> validation signature signals successful validation. > Hmm, Wener recommended to use --check-sigs rather than > --list.sigs which then results in printing the '!'. > Isn't it necessary in your opinion? Fair enough. The mere presence of a validation signature from the validation server indicates successful validation of the email address in the UID. The "!" after "sig" in the output of --check-sigs indicates the signature has been checked and found to be "good" or "valid". - -- Best regards MFPA A woman's mind is cleaner than a man's: She changes it more often. -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJVt7tCXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwT+gIALbLkCzYZ8UV65RDYkMEZhZx kos01iteGKPiOZDOkvNanXEiM2UWO848kDS4SLb/bl/k3Wwob4SatIUwSH5g5LYi VSVl3UF1KeoycEg96HvIpxddRpK8EdhrOe7QMCYQh9UfPwpjbjda2iO+v3bnNXS3 GQJNNfKs9ra4cWiouqV26c52q3uKtiSTnjrs31nXeiCpEP9LN6GjjDQuj+j3bfQq yYs3sLjvTPR6izg9YrXqD0rsWaEAjb0QblVb32a4X1lmmWApKZGL/o5h+qodPbXy ntjKaUftxjC80bB9tmYkiQeCyA4Cx3J7Ah8qN/HOMg3emc7M+su93akvgft7zwCI vgQBFgoAZgUCVbe7SF8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45EktAQChF8LMjoJ+Bo1lU4Rgx6thm+V2 fJmlWB0C8wbJin0IaAD/UcDLbZIJrrgRhSC1Jo1a8NGxijHKWfc5ydIXC7kGowc= =8z3J -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Tue Jul 28 19:57:29 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Tue, 28 Jul 2015 18:57:29 +0100 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <55B671A8.7020109@sumptuouscapital.com> References: <55B5C7B7.4090907@enigmail.net> <653170829.20150727141649@my_localhost> <55B6708C.9090007@enigmail.net> <55B671A8.7020109@sumptuouscapital.com> Message-ID: <567350910.20150728185729@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Monday 27 July 2015 at 7:00:08 PM, in , Kristian Fiskerstrand wrote: > It makes the information more compact and will make hkp > vindex lists look cleaner. I thought Base64 encodes 3 bytes into 4, so has a 33% overhead. > Presuming this information > contains data objects in json format it will be > interpreted by a parser, Couldn't human-readable data with a suitable field delimiter (such as generated by GnuPG's "--with-colons" option) be interpreted by a parser? > and raw data from keyservers > anyways shouldn't be trusted directly before validating > the signature (including its subpackets/notations) > since no crypto has been performed at that point. Is that a good enough reason to deny the user the opportunity to read the signature notation value data in a "--list-sigs" output? What about in a "--check-sigs" output? The "!" would indicate the validation signature signature could be trusted, but the Base64 encoding would obscure the detail about how the email address was verified. - -- Best regards MFPA Wait. You think I'm right? -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJVt8KTXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwvLsH/2QWBfAQ4HyJTtToMhIscl94 72ehjR/ackAyg4ojqbbN7/PDL4BBH7b5EjLIUcsVTwXUGxSw4Z1XBEAXR7oz70Uo WJdyrQVc6CtYLnepzTH2atRSuwd3fv4BpYfbUZ+R4ogVqOtctZznFz2acCXj2HUH Mqq8rUWiJzzCBTBHrprM5Hir8T9gwB/i0qjzOxta7NsMU4r8HcIgUTsxGuQWTjvX mY1NNAXo/S5hjcf8dzHvO9jDSbbt9AtEfA/K3qoIDDJBvY9w5U3dj5i0lpelValM iGC5rg9QJSXT755Rz2Mbs0lK/eYGRQXdJVn3e5vZn7fczOcdCdOMEPSzDTpY6vaI vgQBFgoAZgUCVbfCmF8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45KWNAQD0RFU+Dg3l9npiN3QLXDxKtTnT RJtvh2TagoxVi4AyHgEAvLnRqoss9FL3AkdPCFsfgRCwID44+X5Tr/mG43Jecgs= =0igL -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Tue Jul 28 20:22:29 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Tue, 28 Jul 2015 19:22:29 +0100 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <87y4i0n3v4.wl-neal@walfield.org> References: <55B5C7B7.4090907@enigmail.net> <87y4i0n3v4.wl-neal@walfield.org> Message-ID: <1305965287.20150728192229@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Tuesday 28 July 2015 at 8:22:23 AM, in , Neal H. Walfield wrote: > Did you consider user a proof-of-work scheme? For > instance, the user does a 1 week PoW, signs the result > and attackes it to the key. These would be refreshed > about once a year. Would this one-week PoW pause when the user shuts down and continue when they boot it up? There are plenty of email users who do not leave their computer running all the time. > This eliminates the verification servers and the > problems associated with them (namely, people need to > trust them and there can't be too many of them). It also eliminates any attempt to to establish a link between the key and the email address in the UID. > gpg (or the email clients) don't need to know about > special verification keys / signatures. They just > check the proof of work and sort the returned keys > appropriately. Instead of one special signature notation type, we have another that will be much larger? - -- Best regards MFPA Censor: a man who knows more than he thinks you ought to. -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJVt8hrXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwdtMIAJ4a4kL/C5dskGgWJqh16q6J 0FBX9GNSzuu3UZr7NVzBo3Lf5Ed7uxdKdb9FEjTsUEOG/awy87KYYMKaj9wT2UtY o9ObVXJ68W/JH9dT9v+07Serco88uVbRAh3wbMe10HIJfxVw3AG1FvejdkVfEU9Z rwmnr0OgRvDTXXFF8P9LwHwCyvbCe/lsACeisqCDyTosQMlwWYEvLgY66VKumlRQ HtTss2jy6lqSinFWEvOiNM20310zL5BjJGGzve9sAgB3Bn3zlp6Gb0x9FXK02Qh4 /aJosyeHEqNssRHMRveWefzXzjlLVGI/O4JSQ4zOJxsQrxE6Hrr/G6QM5ONLl/iI vgQBFgoAZgUCVbfIcF8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45F7XAPwMjqC88bZ7Ij+Gsu6QQZPZ54ph Mlg8RLj4MuQRN8A6xgEAwJ447hyipEnIRvkVIJKZJo3p1FcYQ1oxn4YNYfUUPgk= =lk5K -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Tue Jul 28 20:46:18 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Tue, 28 Jul 2015 19:46:18 +0100 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <1865150.UFN610AODu@collossus.ingo-kloecker.de> References: <55B5C7B7.4090907@enigmail.net> <1567894.c4elsytu3Z@collossus.ingo-kloecker.de> <55B680F6.40701@hammernoch.net> <1865150.UFN610AODu@collossus.ingo-kloecker.de> Message-ID: <1957409686.20150728194618@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Tuesday 28 July 2015 at 3:46:54 PM, in , Ingo Kl?cker wrote: > I'm confident that the smaller mail providers who focus > on security would be willing to add such an interface. > Frankly, I do not care that much for the big mail > providers. Unless at least some of the major email providers were to provide a means for these DNS entries to be added, any DNS-based approach has very limited potential. > People who really value privacy should use > mail providers that value privacy. A person cannot usually dictate which mail provider is used by the people with whom they exchange messages. - -- Best regards MFPA It is not necessary to have enemies if you go out of your way to make friends hate you. -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJVt84EXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXww1AH/iaZry3CPY/8YfDSjWYedmdm QQwJFZCjc4V9PyiCL+yBwRvKElsCtTCrwTPY2f+GxgASXCOLObzdnCdgFQrT9dbi 3BGuOz2yCrJ/5jCx8sSCEXa1qLvfQoARw6rufgYb9gxiDnikQ82eOhfptbAf4TMQ tyHU9ITodCS61rzw5e2DaKJWrQWEXS4+sGOO7XJw4u0y0R8EuR2EHoSI1BnDEHZG 2AQlvGQJY8XaPlSoLRBZqqIxmJ7OJXjMmFod0FGb+VxRanhAxY/I+F2TVTqxdkVg UWlWk/Dd4xiMSnsiLL2A8+WnNgdEREaoDv6NR94JMfMOMXXwLl1nERNCf/5knWSI vgQBFgoAZgUCVbfOCV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45Ft+AP0YJw0U+xtnCLEZ889FGYrhO3aY TE6ljuYBfSUaLgix8AEA+VOgf6UnRzUKF8L+85qvo6x5BNnN4mTI4KQKHE8DHgQ= =ci51 -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Tue Jul 28 21:13:35 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Tue, 28 Jul 2015 20:13:35 +0100 Subject: gpg 2.1.6 toggle doesn't In-Reply-To: <55B63AFD.4030702@kset.org> References: <55B0FA83.20506@kset.org> <253829032.20150725132637@my_localhost> <55B5F04B.109@kset.org> <55B5F3F6.90700@sumptuouscapital.com> <55B5F681.1070002@sumptuouscapital.com> <55B60BF1.3040900@kset.org> <822164877.20150727143156@my_localhost> <55B63AFD.4030702@kset.org> Message-ID: <1459889112.20150728201335@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Monday 27 July 2015 at 3:06:53 PM, in , Marko Bo?ikovic wrote: > On 27/07/2015 14:31, MFPA wrote: >> When I run gpg -K, or gpg --list-secret-keys, the >> listing for each key starts with the location of >> pubring.kbx and not the location of >> private-keys-v1.d. > Hi, > I'm not sure we're talking about the same thing... I think we are but I am not understanding something correctly. > When I run gpg -K (2.1), I get a listing of my private > keys' info from my pubring.kbx. I thought the private keys were in private-keys-v1.d, not in pubring.kbx. > In the listing, there > are indicators for missing/deleted private keys (sec#) > and private key "placeholders" (not sure if that's the > term) for keys that are stored on the card (ssb>). I get the "#" for revoked, missing or deleted private keys, buy I don't have any cards so don't see ">" in my listing. > This is what the output looks like (notice # and >'s) > sec# rsa4096/AAAAAAAA 2015-05-11 [expires: 2018-05-10] > uid [ultimate] > uid [ultimate] > ... >ssb> rsa2048/XXXXXXXX 2015-05-11 [expires: 2016-05-10] >ssb> rsa2048/YYYYYYYY 2015-05-11 [expires: 2016-05-10] >ssb> rsa2048/ZZZZZZZZ 2015-05-11 [expires: 2016-05-10] I get something like:- Keyring: C:/PATH/TO/pubring.kbx - ----------------------------------------------------------------------------------- sec rsa2048/0xAAAAAAAAAAAAAAAA 2014-11-09 Key fingerprint = AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA Keygrip = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA uid [ultimate] ssb rsa2048/0xXXXXXXXXXXXXXXXX 2014-11-09 Keygrip = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ssb# nistp256/0xYYYYYYYYYYYYYYYY 2014-11-09 nistp256 [revoked: 2015-01-16] Keygrip = YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY My point was that when I list the public keys, the listing for each key starts with "Keyring: C:/PATH/TO/pubring.kbx". When listing the private keys, I would expect to instead be given the path to private-keys-v1.d. > Previously, using toggle, you could see that info while > running gpg --edit-key Yes, indeed. But not any more. - -- Best regards MFPA Dreams come true on this side of the Rainbow too! -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJVt9RqXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwekQIAJxyJcgdOA/24sUF9Vd52jND 1cDLJhVwr1Py7my2C0HF8cYyOGFcVsyBsiozcrzijf6rbLuLAr2P6lj/a+nWgIjf KIe+FWE7A2HtMe4tblvfDZAOYRhdsrlDrP5vgxfy9T/Ak6GDWrKnsUtZSPzgdm+c /u67ZsQjSYY8uaic/lhO7y4eVjNqc1ykeBEtvb5Inv8KINGh+l9nUUelGJIz7ufv Kf1V6jrfRCrzGdx0lqUFYZQrUN1AahEK4hXp5SXcn656waUII3bi+S6OEJOWQxu/ U1JGY06IsH/+N1tbXxBBBIMT7GeS/sfYogyVBAyNU9TqRUU6dUyb6dgbW4dLD8WI vgQBFgoAZgUCVbfUc18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45MciAQCr6aQenSx7l4cTed9uXH8+fx8z nF+wBxQSm0tyTqSrRwD+I4eY7tcukQZS4zaMFVY36Q9/Z4xZj8GD/oxWQWC1mwc= =ehOP -----END PGP SIGNATURE----- From nico at enigmail.net Tue Jul 28 21:17:28 2015 From: nico at enigmail.net (nico at enigmail.net) Date: Tue, 28 Jul 2015 21:17:28 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <83911986.20150728182607@my_localhost> References: <55B5C7B7.4090907@enigmail.net> <653170829.20150727141649@my_localhost> <55B6708C.9090007@enigmail.net> <83911986.20150728182607@my_localhost> Message-ID: <55B7D548.4020104@enigmail.net> Hi, thanks again for the great feedback. Am 28.07.2015 um 19:26 schrieb MFPA: > > Hi > > On Monday 27 July 2015 at 6:55:24 PM, in > , nico at enigmail.net wrote: > >> If the >> goal is to keep validations in sync, key owners might >> have to confirm emails added over the year earlier, >> which shouldn't be too bad. - - If the goal is to >> reduce validation requests, I see no problem to have >> different expiration dates. I think, because each email >> should be validated from time to time anyway (and this >> is an isolated process), each validation should give >> the 12 month period for the specific email when it is >> validated. Or do you see any problems? > > I just think if I was to receive revalidation requests all at the same > time I would be less likely to overlook those for little-used email > addresses I do not often check. It also keeps it neat. > OK, I will add this as an argument. Does anybody disagree? >> It only says that the email did >> one day work for a validation of any kind, which is >> more than what we have now. > > We have the Web of Trust to demonstrate that. But those are generally > one-off signatures on a key, and may be quite a few years old. Some > email providers recycle addresses, so an address Bob used a few months > or years ago could now be under Alice's, or even Mallory's, control. > > As far as I see it, your scheme adds two things: periodic > revalidation, and an easy way to get a signature on your key without > having to meet anybody. > Yep, sounds good to me. May be an additional value is the goal to establish some "common" validation signatures, which would allow to use/trust these signatures by default. Thus, we also introduce an easy way to benefit from a validation (signature). >> That is, such a validation >> does not give full trust, it would only give slightly >> more trust over emails that do not have the validation. > > Indeed. I think an annual revalidation period strikes a reasonable > balance, although maybe there are email services that recycle > addresses more quickly than that. > Finding the right balance is probably something we have to find out over time. I would start very very conservatively, just not to annoy people. >> But that might be enough to solve the faked key issue. > > Are there really many "faked" keys, rather than keys that are no > longer used, forgotten passphrase, lost private key, etc.? > AFAIK, there are not THAT many faked keys, but the problem exists especially for key parties of our internet world (a famous German magazine, at least one GPG tool, ...). The problem is that the German magazine takes this as a show stopper (both personally and publicly). I really want to have them back on our road for more encryption with OpenPGP. And the "publicity" we get from not validating email addresses is really a big problem (especially as fixing that problems sounds so easy and obvious). Thus, without fixing this, IMO the whole OpenPGP movement has a reputation problem. >> this solution does NOT solve the >> problem of interception of emails. But it helps to >> detect them > > How does this help to detect interception of emails? > Today, people with faked keys simply get unreadable emails, but don't know whether there were trolls or spies at work. After validating their own key, only one of two things can happen: a) The faked key problem is solved, because people now know, which of the available keys to prefer (provided people trust the validation signature) b) The faked key problem still exists, because a validation signature to the faked key was also added. In this case we know that something more severe happened: - either the confirmation email was intercepted - or the validation server was corrupted That is, either the problem is solved or we know that the problem is more severe than just a work of trolls only uploading a faked key for fun. >> It depends on whether and how far you trust the >> provider. Reality looks different (see startmail, >> posteo, riseup, and many company email servers). I >> don't claim to solve any problem in that area. >> User/clients might have to decide whether to trust a >> validation notation given by posteo, riseup, google, >> ... > > Company email servers, I would expect companies as a matter of course > to have a means to decrypt their employees' emails. > > I'm shocked to read [0] that Riseup once had a webmail option that > stored the user's public and private keys. Riseup now tells [1] users > who want to use encrypted email to utilize an email client to send and > receive email, while keeping their private key stored safely on their > local machine. > > [0] > [1] > > Startmail sounds like a similar concept to Hushmail, which was > compromised by a court order obtained through a mutual assistance > treaty. It is not clear to me why Startmail would not be expected to > suffer the same fate. > > Posteo looks interesting. But their overview says end-to-end > encryption is done by the user in addition to Posteo's own security > measures, so the user would have to generate and store their own keys. > > And Google make a living out of exploiting data mined from users' > emails and search activities. Why would anybody trust them? > Interesting, but this is a different issue. The question you raise is: (How far) Can we trust the email provider/server regarding the handling of private keys. Here in this proposal, IMO, we have a slightly different problem, which makes corruption less likely. The reason is: If an email provider/server "G" gives the private key to the NSA we don't know about it, because that's a private deal between G and NSA. Thus, this breakage of privacy is hard to detect and therefore not a big risk for G to do. But if G claims that an email address was validated although it was not, they express this as a public signature visible to the whole world. If they do that, people can/will find out and blame G. But that's something G clearly wants to avoid (they need trust by their customers). Thus, they have much more interest not to signal validation of a faked key because any violation here is easy to detect. Best Nico -- Nicolai M. Josuttis www.josuttis.de mailto:nico at enigmail.net PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5 From mlisten at hammernoch.net Tue Jul 28 22:06:03 2015 From: mlisten at hammernoch.net (=?UTF-8?B?THVkd2lnIEjDvGdlbHNjaMOkZmVy?=) Date: Tue, 28 Jul 2015 22:06:03 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <1865150.UFN610AODu@collossus.ingo-kloecker.de> References: <55B5C7B7.4090907@enigmail.net> <1567894.c4elsytu3Z@collossus.ingo-kloecker.de> <55B680F6.40701@hammernoch.net> <1865150.UFN610AODu@collossus.ingo-kloecker.de> Message-ID: <55B7E0AB.9020601@hammernoch.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 28.07.15 16:46, Ingo Kl?cker wrote: > On Monday 27 July 2015 21:05:26 Ludwig H?gelsch?fer wrote: >> Hi Ingo, >> >> On 27.07.15 16:31, Ingo Kl?cker wrote: (...) >> Why should there not be a similar community approach for setting >> up a (smaller) network of validating key server proxies. > > Well, the keyservers do not make any claims with regard to the > authenticity or the integrity of the keys. Those checks are left to > the clients. I do not have to trust any of the keyservers. > > The validating key server proxies claim validity of the UIDs (to a > certain degree). I can see myself marking such a proxy as trusted > by adding it to my gnupg.conf (or to KMail's configuration). But I > cannot see myself adding such a proxy to the whitelist that's > shipped with KMail. > > Another problem I see with whitelist management is revocation in > case the validation key of a validating proxy is compromised. > Again, for the CA certificate bundles that's handled by the > distributors and not by individual application developers. Let's concentrate on this one, I think this is the real tough task: establishing a trust chain from the validating servers to the client. There's one root certificate, signing the individual proxy certificates. Each individual proxy has a certificate it is using for creating the validating signatures. Each client only needs to have the root certificate builtin. If it encounters a validation proxy's certificate, it will download it. If a proxy certificate is known compromised, the signature from the root certificate is revoked. If the root certificate is compromised (and revoked), the scheme will require new client versions with a new root certificate builtin. The client itself must refresh the root certificate and all downloaded proxy certificates regularly. This all requires a very small group of maintainers for the root certificate (2 or 3 people), issueing and revoking signatures for proxy certificates. The client authors will need to have a trust chain to at least one root certificate maintainer. This is also true for the proxy maintainers . This is my view of the problem :-) Ludwig -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJVt+CmAAoJEDrb+m0Aoeb+MZsP/RhiweEwRqQhG1q6yyrFLdYJ +tBUUYOlKWdI3xoDCX2g0dUu+4hl9VcbvLpOJSunDgbPNT7HHaZSKmV8Mo+3iE2o J9v9jGdmK3UJxBRNZhR2+z0vN2Qm9OWN2a17rd7EDmwAjr6GZ6zqw1XMTjd3JSz9 yDGaCgMQhLfcw0qesTD4rKEWNf95KQBpFdWcJypcEPBJtad676SNwHLBAnktAhJ+ Oo942tT9982s2ijnPfGGw5CS8K+J2T2kS/ucMPWFwK4m6/NngLip20ET+S2DcBcG f09RHHwvPUc1/j6QDb1HfDdlu9vqUp/h9MZ6EEBPPCCDwTtl0RSXnd6jveEJtzrs X5DSZRMruDrjNw4OJ0NQytN1s+FeyZn1I/vQYEREgJgGdzGmW1UpcqbzVhMOOFHz dgP5RbIrgQC2MbgZDjARlFK8SknJxO0D6B9RYqaYE4bCr6/x4+9vZ9XAJZw8wYlt 25gP1S7oLC8g3vsVNXfkXeaRRC7V6PPKPWxqcodBtg0uQh49H8i7G53W/OMpu/aZ QJJn8Z2JqKbye/0IRByYcCEcnd2dviHRA++eWQswdJpb6kyJv7LraHgV3z0lhZkI Qj9roCPGuqIsHGuQLoL+leOp6xUkWbgdT1dWNnIkCzWnRB3wl5pJ9R6eIKGcWlmO jZqhgSJBm5V7OXV51bdr =0UhR -----END PGP SIGNATURE----- From neal at walfield.org Wed Jul 29 00:46:10 2015 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 29 Jul 2015 00:46:10 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <1305965287.20150728192229@my_localhost> References: <55B5C7B7.4090907@enigmail.net> <87y4i0n3v4.wl-neal@walfield.org> <1305965287.20150728192229@my_localhost> Message-ID: <87vbd3nbnx.wl-neal@walfield.org> At Tue, 28 Jul 2015 19:22:29 +0100, MFPA wrote: > On Tuesday 28 July 2015 at 8:22:23 AM, in > , Neal H. Walfield wrote: > > > Did you consider user a proof-of-work scheme? For > > instance, the user does a 1 week PoW, signs the result > > and attackes it to the key. These would be refreshed > > about once a year. > > Would this one-week PoW pause when the user shuts down and continue > when they boot it up? There are plenty of email users who do not leave > their computer running all the time. Of course. A simple proof of work scheme is to find a hash that starts with X zeros. This requires 2^X steps. In our case, the prefix of the text would be the primary public key. > > This eliminates the verification servers and the > > problems associated with them (namely, people need to > > trust them and there can't be too many of them). > > It also eliminates any attempt to to establish a link between the key > and the email address in the UID. I'm not so sure. Recall that we are not attempting to protect against attacks by nation states. As such, performing a week of computation each year is going to be too much to maintain for those who upload fake keys. Moreover, this will automatically purge old keys (or at least rank them very low in search results). In other words, only people who actually use a given key will bother performing the work. > > gpg (or the email clients) don't need to know about > > special verification keys / signatures. They just > > check the proof of work and sort the returned keys > > appropriately. > > Instead of one special signature notation type, we have another that > will be much larger? What do you mean? A PoW is just a few dozen bytes large... Neal From 2014-667rhzu3dc-lists-groups at riseup.net Wed Jul 29 02:03:53 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Wed, 29 Jul 2015 01:03:53 +0100 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <87vbd3nbnx.wl-neal@walfield.org> References: <55B5C7B7.4090907@enigmail.net> <87y4i0n3v4.wl-neal@walfield.org> <1305965287.20150728192229@my_localhost> <87vbd3nbnx.wl-neal@walfield.org> Message-ID: <1587154033.20150729010353@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Tuesday 28 July 2015 at 11:46:10 PM, in , Neal H. Walfield wrote: > At Tue, 28 Jul 2015 19:22:29 +0100, MFPA wrote: >> It also eliminates any attempt to to establish a link >> between the key and the email address in the UID. > I'm not so sure. Recall that we are not attempting to > protect against attacks by nation states. As such, > performing a week of computation each year is going to > be too much to maintain for those who upload fake keys. And too much for people with multiple email addresses. > Moreover, this will automatically purge old keys (or at > least rank them very low in search results). In other > words, only people who actually use a given key will > bother performing the work. If the search results were returned in order of PoW date, newest first, that would be great. Are they currently sorted at all, or simply returned in the order in which they are found? This still seems less rigorous to me than having to receive an email sent to that address and decrypt it with that key. I guess it's a case of swings and roundabouts. - -- Best regards MFPA There is no snooze button for a cat that wants breakfast -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJVuBh1XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXw31EH/2pRMlByL/KlNaIWBL7HYmUV thLGzhoiTjMCM3aWpGEsRtCXGiUbykPl16dL8A7siSHH6kSIklOpYUviRSp09M6o GhRRGQcqQ/1xWcQRdb64q6QHHCCQSHDWUk1o1uiGG0BUmKf7lhB25LifCVCLNZ4L 1tYAZJdylNrwTAYRZlZqesirhJi0f9r40dmMR87wye4eInQBLkqeB++BmAqM6V00 KzdmRf7acR9pD3Hz0lyHkFGRqm3PY5lIRqad3XhsQ7Ln5BQyVNrsnN//7/lUXFPD NKQmWXlF+MKl3t7s5BSkt0yLtJCujrzh6AdUZoyYjITCuF7TiS0G4076LxW3POWI vgQBFgoAZgUCVbgYe18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45G4sAP9whBfAE5Vg0aO3J9u1vIxTOJr0 d6PmgM2WntglbHyLGQEA00g7R8WvHgZIuaYrqZm/ndRW8C7RZNguQvyDFbxa4Qc= =ogbj -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Wed Jul 29 02:10:08 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Wed, 29 Jul 2015 01:10:08 +0100 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <55B7E0AB.9020601@hammernoch.net> References: <55B5C7B7.4090907@enigmail.net> <1567894.c4elsytu3Z@collossus.ingo-kloecker.de> <55B680F6.40701@hammernoch.net> <1865150.UFN610AODu@collossus.ingo-kloecker.de> <55B7E0AB.9020601@hammernoch.net> Message-ID: <954175434.20150729011008@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Tuesday 28 July 2015 at 9:06:03 PM, in , Ludwig H?gelsch?fer wrote: > Let's concentrate on this one, I think this is the real > tough task: establishing a trust chain from the > validating servers to the client. > There's one root certificate, signing the individual > proxy certificates. Sounds a lot like the discredited "trusted CA" system, used for TLS and S/MIME? - -- Best regards MFPA A woman's mind is cleaner than a man's: She changes it more often. -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJVuBnhXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwposH/15Ka7DXO5nFHdiCvIA9HQLi majWzM4taIWwNpKNrFYHDEBl2WuYrPzIeqI+hZQEdgHWKmGUeDUyRp+iOzRG9O0c 4ZtpY0DNdoeMH2MiZbstfgtrRTblI7jw1K5x0hhFA9m2y3HnAWpy/s9NMeMy8NBh /dTE5Qdad1cvmfHvkBobvlh4USuaeLs2JksZyGKN3blXR2u4y0Lbv4D9qVt0n87J S8LXfntcV2azmOKTV8b1vvpu5gG0BwRLQ31xBLB9yRl4Ooqnyprdpx9h7FfM8gHM FGiQ95zQ2xQw9/HPKAApq64H1+Ds0FvN51eh+C0ey0vJFxR1Y7qC4OWdh6ENxSGI vgQBFgoAZgUCVbgZ4V8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45JcCAQCI9iT1YcoTxx+iC2GWv6wBtlwv cBcGakM8/EgYQu7LzgD/Upx5INuwxkkJEvZFdurXAJLjOfPXeza95OgFcgbOFAk= =qOTP -----END PGP SIGNATURE----- From gniibe at fsij.org Wed Jul 29 02:25:01 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 29 Jul 2015 09:25:01 +0900 Subject: One Key, multiple Smartcards not working anymore In-Reply-To: <55B681DF.5040107@netpage.dk> References: <55B681DF.5040107@netpage.dk> Message-ID: <55B81D5D.7040206@fsij.org> Hello, Thank you for the report describing complicated issue. Your detailed description helps me understand the situation. On 07/28/2015 04:09 AM, Josef Schneider wrote: > I have a problem with my Key. I have a 4096bit RSA key since 2012 and it > is stored on a OpenPGP smartcard. > Recently I added three new 2048bit subkeys, because I bought a Yubikey > NEO device and want to use PGP on my phone/tablet with Android and NFC. > This worked as expected. I created the new subkeys on my PC, saved a > backup and then moved them to the card. > PGP showed me correctly that the first three keys are on card 1 and the > second three are on card 2. If the wrong card was inserted, it asked me > to insert the correct one. > > I then wanted to create one key backup with all six private keys to > print using PaperBack and store in a safe place. I was able to merge all > the private keys with gpgsplit and moving/renaming files and created > that backup. > > After that, I deleted the whole key, got my public key from the > keyservers and tried to use it with the card (after gpg2 --card-status). > Here is now my problem: > GPG adds the key stub for the smartcard keys only for the first card! If > I delete the key, import, use card-status, then I can usse the three > keys from that smartcard. If I insert the second smartcard and do a > card-status, nothing changes! > > If I import the full key with all private keys, I can then replace the > keys on the card and move all keys to smartcards. Then I get a key > working with both smartcards again. But of course I don't want to touch > the key backup. It's printed on paper and stored in a safe location for > a reason. > > Am I doing something wrong, or is that a bug? [...] > All with gpg (GnuPG) 2.0.28 (Gpg4win 2.2.5) This is a bug in 2.0. (I think it works well (or better) on 2.1.) In gnupg/g10/card-utilc, we have a function card_status, which corresponds --card-status option. It goes to the block of line 590, when there is no secret keys available but public key is available (let's call THE CONDITION). In this specific case, the function auto_create_card_key_stub will be called to create the stub. In your case, secret key stub is not available but public key is available. The calculation of THE CONDITION is somehow wrong for subkeys sharing primary key when the subkey is not available but another subkey is available. This is because of the lookup is basically based on primary key. I'm going to look in detail, and I will fix. -- From 2014-667rhzu3dc-lists-groups at riseup.net Wed Jul 29 02:48:54 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Wed, 29 Jul 2015 01:48:54 +0100 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <55B7D548.4020104@enigmail.net> References: <55B5C7B7.4090907@enigmail.net> <653170829.20150727141649@my_localhost> <55B6708C.9090007@enigmail.net> <83911986.20150728182607@my_localhost> <55B7D548.4020104@enigmail.net> Message-ID: <19610726502.20150729014854@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Tuesday 28 July 2015 at 8:17:28 PM, in , nico at enigmail.net wrote: > AFAIK, there are not THAT many faked keys, but the > problem exists especially for key parties of our > internet world (a famous German magazine, at least one > GPG tool, ...). The problem is that the German magazine > takes this as a show stopper (both personally and > publicly). I really want to have them back on our road > for more encryption with OpenPGP. And the "publicity" > we get from not validating email addresses is really a > big problem (especially as fixing that problems sounds > so easy and obvious). Thus, without fixing this, IMO > the whole OpenPGP movement has a reputation problem. I understand what you are saying. I cannot help but think they are making a mountain out of a molehill by characterising this minor irritation as a "show stopper". Putting something in place to counteract the issue is one approach. Would it not be an equally-valid approach to educate them as to why it is a non-issue, which they could then disseminate through their magazine? > Today, people with faked keys simply get unreadable > emails, but don't know whether there were trolls or > spies at work. They can, however, search on keyservers for the key to which the message was encrypted. Or ask the sender where they got it and to forward a copy for inspection. > After validating their own key, only one > of two things can happen: [snipped] > either the > problem is solved or we know that the problem is more > severe than just a work of trolls only uploading a > faked key for fun. Fair enough. > But if G claims that an email address was validated > although it was not, they express this as a public > signature visible to the whole world. If they do that, > people can/will find out and blame G. But that's > something G clearly wants to avoid (they need trust by > their customers). Thus, they have much more interest > not to signal validation of a faked key because any > violation here is easy to detect. The provider could claim the user's password must have been compromised and that was how the validation occurred without the user's knowledge. They could even make the user jump through password reset and security question hoops the next time they log in. Anyway, after ten minutes public attention will switch to something else. - -- Best regards MFPA Adults are obsolete children. -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJVuCMBXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwxpYH/jjZIF0ue4m1F8WJSdNt3fcG WGrdQT5rpOG8hUUcCPA36NTeKA9zWrREgFgZX2lRIPOwCTzaHzlw3SRNc42yOS2/ ayviJbN714zrl0tT6zhYlb3T4lQo0mX8S8G4EkzUECt9DPYZOsv6YPxv+WcNMDGa YwAsEvXQHD4uXe2bmvO2zIjNsehYBnISPKv4dr9XHMjxOVUTSPmmBsRkYnrVP6mN MEXf9VQJUtybnrWUlhE3WqAX1zBdTMwfm1PlpWNUTMPTtluoW7qabEI5kGMuPRsj AygSJvUqUzs5wlg2jVhvUfAK4eeNBnua+U0duvIsfP4xeeYWN1r1uzjC7m+y6xyI vgQBFgoAZgUCVbgjB18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45J18AQCVilysc7qVQt09cSq0/nxPAq+j Y4OGfgsiB1itI5jVFgEA95f3usAyVwOh3xKv4KJpXZqBjHxKD/B18U+TDmTitwU= =dOC/ -----END PGP SIGNATURE----- From fmv1992 at gmail.com Wed Jul 29 04:53:47 2015 From: fmv1992 at gmail.com (fmv1992 at gmail.com) Date: Tue, 28 Jul 2015 23:53:47 -0300 Subject: Is there a way to comment a key locally? Message-ID: <55B8403B.8050207@gmail.com> Is there a way to comment a key locally? Examples: Let's say I met a guy and we exchanged keys. After 10 years I decide to send him an encrypted email. How would I remember the guy - key link? I'm thinking of adding an alias like 'red haired funny tall guy from XYZ meeting' Other scenario: I downloaded and verified a file on the internet. For some reasons I decide to trust that his key belong to this developer. I will not be using his key for some time. So again when I decide to download again that software how can I remember that GOOD SIGNAURE from abc at def is from the same developer? -- Felipe Martins Vieira Public PGP key: http://pgp.surfnet.nl Key Fingerprint: 9640 F192 63DA D637 6750 AC08 7BCA 19BB 0E69 E45D From gniibe at fsij.org Wed Jul 29 06:02:58 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 29 Jul 2015 13:02:58 +0900 Subject: One Key, multiple Smartcards not working anymore In-Reply-To: <55B681DF.5040107@netpage.dk> References: <55B681DF.5040107@netpage.dk> Message-ID: <55B85072.3020301@fsij.org> Hello, I forgot to address some way to recover. On 07/28/2015 04:09 AM, Josef Schneider wrote: > I insert the other card and do a card-status: [...] > General key info..: pub 2048R/988E7DDD 2015-07-07 Josef Schneider > > sec> 4096R/9BE45ED0 erzeugt: 2012-12-10 verf?llt: 2017-04-13 > Kartennummer:0005 XXXXXXXX > ssb> 4096R/B641DD11 erzeugt: 2012-12-10 verf?llt: niemals > Kartennummer:0005 XXXXXXXX > ssb> 4096R/CA02F8EA erzeugt: 2012-12-10 verf?llt: niemals > Kartennummer:0005 XXXXXXXX > ssb# 2048R/988E7DDD erzeugt: 2015-07-07 verf?llt: 2017-07-06 > ssb# 2048R/03E021FE erzeugt: 2015-07-07 verf?llt: 2017-07-06 > ssb# 2048R/8B406748 erzeugt: 2015-07-07 verf?llt: 2017-10-24 In this situation, you have a stub for RSA 4096-bit keys. 4096R/9BE45ED0 -> Kartennummer:0005 XXXXXXXX 4096R/B641DD11 -> Kartennummer:0005 XXXXXXXX 4096R/CA02F8EA -> Kartennummer:0005 XXXXXXXX With GnuPG 2.0, you can export stub (it's not possible for GnuPG 2.1). $ gpg -a -o 9BE45ED0-stub.asc --export-secret-keys 9BE45ED0 $ gpg -a -o B641DD11-stub.asc --export-secret-subkeys B641DD11 $ gpg -a -o CA02F8EA-stub.asc --export-secret-subkeys CA02F8EA Then, > General key info..: pub 2048R/988E7DDD 2015-07-07 Josef Schneider > > sec# 4096R/9BE45ED0 erzeugt: 2012-12-10 verf?llt: 2017-04-13 > ssb# 4096R/B641DD11 erzeugt: 2012-12-10 verf?llt: niemals > ssb# 4096R/CA02F8EA erzeugt: 2012-12-10 verf?llt: niemals > ssb> 2048R/988E7DDD erzeugt: 2015-07-07 verf?llt: 2017-07-06 > Kartennummer:0006 XXXXXXXX > ssb> 2048R/03E021FE erzeugt: 2015-07-07 verf?llt: 2017-07-06 > Kartennummer:0006 XXXXXXXX > ssb> 2048R/8B406748 erzeugt: 2015-07-07 verf?llt: 2017-10-24 > Kartennummer:0006 XXXXXXXX When you have this configuration ('#' means no secret key), import *-stub.asc by gpg --import. -- From nico at enigmail.net Wed Jul 29 07:42:34 2015 From: nico at enigmail.net (nico at enigmail.net) Date: Wed, 29 Jul 2015 07:42:34 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <1076303842.20150729023047@my_localhost> References: <55B5C7B7.4090907@enigmail.net> <874mkpokxu.wl-neal@walfield.org> <1076303842.20150729023047@my_localhost> Message-ID: <55B867CA.9090501@enigmail.net> Am 29.07.2015 um 03:30 schrieb MFPA: > > Hi > > > On Monday 27 July 2015 at 1:15:57 PM, in > , Neal H. Walfield wrote: > > >> Regarding the design: personally, I wouldn't have the >> user follow a link that includes a swiss number, but >> have the user reply to the mail, include the swiss >> number and sign it. > > > Why not simplify the workflow:- > > 1. key reaches validation server. > > 2. for each UID containing an email address, validation server creates > a copy of the key stripped of all other UIDs. > > 3. validation server signs that copy of the key. > > 4. validation server pastes the signed key into an email, encrypts the > email to that key, and sends it to the email address in the UID. > > 5. user receives each email, decrypts it, and updates their local copy of > their key. > > 6. user uploads key now bearing the validation server's signatures to > a keyserver. > > Interesting. What comes into my mind is the following: - This requires special email clients. The benefit of the proposed workflow is that any existing client can use it just by switching its keyserver to the validating keyserver proxy. IMO, that's a huge drawback, because any solution that requires email client updates is a lot harder to establish. - How to deal with existing keys? Well probably the same (upload a key for the first time and uploading it for updates would run the saem workflow), right? > There is still the same level of assurance that the email address and > private key are controlled by the same entity. Advantages are:- > > a. Nobody is asked to click links or reply to emails. > Hmm, isn't step 5 is kind of that? In any case some confirmation email handling is required. If this is done by the email client silently, this also can be done by the email client in my proposal. But again this requires supporting clients. > b. The validation server does not need to manage a "stack" of keys > awaiting feedback from the validation emails. > indeed, that's an argument > c. Changes to the user's key are uploaded to the keyserver by the > user, not by the validation server. > Is this a real benefit? Thanks Nico -- Nicolai M. Josuttis www.josuttis.de mailto:nico at enigmail.net PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5 From nico at enigmail.net Wed Jul 29 08:28:26 2015 From: nico at enigmail.net (nico at enigmail.net) Date: Wed, 29 Jul 2015 08:28:26 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <55B867CA.9090501@enigmail.net> References: <55B5C7B7.4090907@enigmail.net> <874mkpokxu.wl-neal@walfield.org> <1076303842.20150729023047@my_localhost> <55B867CA.9090501@enigmail.net> Message-ID: <55B8728A.4060602@enigmail.net> >> b. The validation server does not need to manage a "stack" of keys >> awaiting feedback from the validation emails. >> > indeed, that's an argument > Hmm, but IMO we anyway need a state in validation servers to deal with different spam schemes (i.e. avoiding that any request to a v-server sends an email). -- Nicolai M. Josuttis www.josuttis.de mailto:nico at enigmail.net PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5 From wk at gnupg.org Wed Jul 29 09:57:02 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 29 Jul 2015 09:57:02 +0200 Subject: gpg 2.1.6 toggle doesn't In-Reply-To: <87k2tk458a.fsf@vigenere.g10code.de> (Werner Koch's message of "Tue, 28 Jul 2015 18:27:49 +0200") References: <55B0FA83.20506@kset.org> <253829032.20150725132637@my_localhost> <55B5F04B.109@kset.org> <55B5F3F6.90700@sumptuouscapital.com> <55B5F681.1070002@sumptuouscapital.com> <55B60BF1.3040900@kset.org> <87pp3c4d96.fsf@vigenere.g10code.de> <55B78A6C.1090009@kset.org> <87k2tk458a.fsf@vigenere.g10code.de> Message-ID: <87egjr4cs1.fsf@vigenere.g10code.de> On Tue, 28 Jul 2015 18:27, wk at gnupg.org said: > Right. I'll check whether this can be done easily. Okay, with commit 8b2b988 it does now look this way: sec rsa1024/53B620D01CE0C630 created: 2006-01-01 expired: 2011-06-30 usage: SC card-no: 0001 00000347 trust: unknown validity: expired [ expired] (1). Werner Koch (dist sig) (That is the old distribution signing key). The toggle comment is more or less a NOP now but does a "list" as before. You will see "sec" or "sbb" is the corresponding secret key is available or a card with that secret key has been used. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Jul 29 10:00:27 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 29 Jul 2015 10:00:27 +0200 Subject: gpg 2.1.6 toggle doesn't In-Reply-To: <1459889112.20150728201335@my_localhost> (MFPA's message of "Tue, 28 Jul 2015 20:13:35 +0100") References: <55B0FA83.20506@kset.org> <253829032.20150725132637@my_localhost> <55B5F04B.109@kset.org> <55B5F3F6.90700@sumptuouscapital.com> <55B5F681.1070002@sumptuouscapital.com> <55B60BF1.3040900@kset.org> <822164877.20150727143156@my_localhost> <55B63AFD.4030702@kset.org> <1459889112.20150728201335@my_localhost> Message-ID: <87a8uf4cmc.fsf@vigenere.g10code.de> On Tue, 28 Jul 2015 21:13, 2014-667rhzu3dc-lists-groups at riseup.net said: > My point was that when I list the public keys, the listing for each > key starts with "Keyring: C:/PATH/TO/pubring.kbx". When listing the > private keys, I would expect to instead be given the path to > private-keys-v1.d. Since 2.1 listing a private keys simply mean listing all keys with the private part available. private-keys-v1.d is a property of gpg-agent and may actually be on a different machine. To see which file below private-keys-v1.d has the private key parts, you can use gpg -K --with-keygrip Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From antoine.michard at chezgeek.fr Wed Jul 29 10:10:05 2015 From: antoine.michard at chezgeek.fr (Antoine Michard) Date: Wed, 29 Jul 2015 10:10:05 +0200 Subject: Use Private DOs Message-ID: <55B88A5D.5010606@chezgeek.fr> Hi all, I've discover recently the Private DO field in my OpenPGP Smart Card V2.1. First, I try it on my Windows System and Gpg4Win 2.2.5 but I did't see anything. Yesterday, on my Debian system I finally saw it ( Private DO #1 & #2). Now, I've got a big TEST in my field and I didn't find how to delete it. With a blank fied, I've got an error from GPG, and I didn't find an article about Private DOs on Internet. Just one in French but not how to delete field or how to show field #3 & #4 I've read some info in OpenPGP Card 2.1 documentation but not how to use it with GPG. I think is a function not well documented. Can you explain me how is it work ?? Thx -- 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 wk at gnupg.org Wed Jul 29 10:08:39 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 29 Jul 2015 10:08:39 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <567350910.20150728185729@my_localhost> (MFPA's message of "Tue, 28 Jul 2015 18:57:29 +0100") References: <55B5C7B7.4090907@enigmail.net> <653170829.20150727141649@my_localhost> <55B6708C.9090007@enigmail.net> <55B671A8.7020109@sumptuouscapital.com> <567350910.20150728185729@my_localhost> Message-ID: <8761534c8o.fsf@vigenere.g10code.de> On Tue, 28 Jul 2015 19:57, 2014-667rhzu3dc-lists-groups at riseup.net said: > Couldn't human-readable data with a suitable field delimiter (such as > generated by GnuPG's "--with-colons" option) be interpreted by a > parser? OpenPGP allows to indicate whether a notation data item is human readable. Notation data generated by gpg are always flagged as human readable and there has up to now be no request to add a feature to add binary notation data - but it would be possible to do that. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Jul 29 10:16:30 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 29 Jul 2015 10:16:30 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <1957409686.20150728194618@my_localhost> (MFPA's message of "Tue, 28 Jul 2015 19:46:18 +0100") References: <55B5C7B7.4090907@enigmail.net> <1567894.c4elsytu3Z@collossus.ingo-kloecker.de> <55B680F6.40701@hammernoch.net> <1865150.UFN610AODu@collossus.ingo-kloecker.de> <1957409686.20150728194618@my_localhost> Message-ID: <871tfr4bvl.fsf@vigenere.g10code.de> On Tue, 28 Jul 2015 20:46, 2014-667rhzu3dc-lists-groups at riseup.net said: > Unless at least some of the major email providers were to provide a > means for these DNS entries to be added, any DNS-based approach has > very limited potential. Right, but is the only solid way of doing it. The provider already have the infrastructure to maintain the mail account and thus the costs of adding a new data field a marginal. Of course one could setup a service to do this for example by appending foo.gnupg.net to the mail address before the lookup. However this introduces a lot of costs (user help desk), annoyance (the user need to register with that service), and centralization. > A person cannot usually dictate which mail provider is used by the > people with whom they exchange messages. Iff enough people are interested in confidential mail communication competition will force all providers to add this. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bozho at kset.org Wed Jul 29 10:46:24 2015 From: bozho at kset.org (=?UTF-8?B?TWFya28gQm/Fvmlrb3ZpxIc=?=) Date: Wed, 29 Jul 2015 09:46:24 +0100 Subject: gpg 2.1.6 toggle doesn't In-Reply-To: <87egjr4cs1.fsf@vigenere.g10code.de> References: <55B0FA83.20506@kset.org> <253829032.20150725132637@my_localhost> <55B5F04B.109@kset.org> <55B5F3F6.90700@sumptuouscapital.com> <55B5F681.1070002@sumptuouscapital.com> <55B60BF1.3040900@kset.org> <87pp3c4d96.fsf@vigenere.g10code.de> <55B78A6C.1090009@kset.org> <87k2tk458a.fsf@vigenere.g10code.de> <87egjr4cs1.fsf@vigenere.g10code.de> Message-ID: <55B892E0.7020108@kset.org> On 29/07/2015 08:57, Werner Koch wrote: > On Tue, 28 Jul 2015 18:27, wk at gnupg.org said: > >> Right. I'll check whether this can be done easily. > > Okay, with commit 8b2b988 it does now look this way: > > sec rsa1024/53B620D01CE0C630 > created: 2006-01-01 expired: 2011-06-30 usage: SC > card-no: 0001 00000347 > trust: unknown validity: expired > [ expired] (1). Werner Koch (dist sig) > > (That is the old distribution signing key). The toggle comment is more > or less a NOP now but does a "list" as before. You will see "sec" or > "sbb" is the corresponding secret key is available or a card with that > secret key has been used. Brilliant! Thank you very much! -- Marko From kloecker at kde.org Wed Jul 29 12:05:13 2015 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Wed, 29 Jul 2015 12:05:13 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <55B867CA.9090501@enigmail.net> References: <55B5C7B7.4090907@enigmail.net> <1076303842.20150729023047@my_localhost> <55B867CA.9090501@enigmail.net> Message-ID: <1713361.R4RmYyGI3m@collossus.ingo-kloecker.de> On Wednesday 29 July 2015 07:42:34 nico at enigmail.net wrote: > Am 29.07.2015 um 03:30 schrieb MFPA: > > Why not simplify the workflow:- > > > > 1. key reaches validation server. > > > > 2. for each UID containing an email address, validation server creates > > a copy of the key stripped of all other UIDs. > > > > 3. validation server signs that copy of the key. > > > > 4. validation server pastes the signed key into an email, encrypts the > > email to that key, and sends it to the email address in the UID. > > > > 5. user receives each email, decrypts it, and updates their local copy of > > their key. > > > > 6. user uploads key now bearing the validation server's signatures to > > a keyserver. > > > > There is still the same level of assurance that the email address and > > private key are controlled by the same entity. Advantages are:- > > c. Changes to the user's key are uploaded to the keyserver by the > > user, not by the validation server. > > Is this a real benefit? A possible benefit would be that the user can choose not to upload the validation signatures to the keyservers. With a minor change in step 1 (the key owner uploads his key to the validation server without uploading it to a keyserver) the UID validation would even work for keys which its owner does not want to upload to a public keyserver. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From kloecker at kde.org Wed Jul 29 12:38:46 2015 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Wed, 29 Jul 2015 12:38:46 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <19610726502.20150729014854@my_localhost> References: <55B5C7B7.4090907@enigmail.net> <55B7D548.4020104@enigmail.net> <19610726502.20150729014854@my_localhost> Message-ID: <12203261.aOCGBWf565@collossus.ingo-kloecker.de> On Wednesday 29 July 2015 01:48:54 MFPA wrote: > On Tuesday 28 July 2015 at 8:17:28 PM, in > , nico at enigmail.net wrote: > > AFAIK, there are not THAT many faked keys, but the > > problem exists especially for key parties of our > > internet world (a famous German magazine, at least one > > GPG tool, ...). The problem is that the German magazine > > takes this as a show stopper (both personally and > > publicly). I really want to have them back on our road > > for more encryption with OpenPGP. And the "publicity" > > we get from not validating email addresses is really a > > big problem (especially as fixing that problems sounds > > so easy and obvious). Thus, without fixing this, IMO > > the whole OpenPGP movement has a reputation problem. > > I understand what you are saying. I cannot help but think they are > making a mountain out of a molehill by characterising this minor > irritation as a "show stopper". Yes, he (not they!), the author of the article is doing exactly this. > Putting something in place to > counteract the issue is one approach. Would it not be an equally-valid > approach to educate them as to why it is a non-issue, which they could > then disseminate through their magazine? I think that the author of the article knows that it's mostly a non-issue. He still decided to write the article "Forged PGP Keys in the Wild" [1] and even an accompanying editorial titled "Let PGP Die!" [2]. I guess he simply got pissed because he received so many messages that were undecryptable with his real key. Luckily, there are also more sensible authors working for this magazine who write good articles about OpenPGP. I personally chose to ignore the stupid editorial. IMHO it does not deserve more attention than any other rant written by a random troll. OTOH, the article actually isn't that bad. It points out the issue with the missing validation of email addresses in UIDs making a bit of a fuss about it, but IIRC it also explains how to avoid falling into the trap of using a fake key. Regards, Ingo [1] http://www.heise.de/artikel-archiv/ct/2015/06/160_Die-Schluessel-Falle (German; needs to be bought) [2] https://www.heise.de/artikel-archiv/ct/2015/06/3_Editorial (German; free) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From 2014-667rhzu3dc-lists-groups at riseup.net Wed Jul 29 13:05:50 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Wed, 29 Jul 2015 12:05:50 +0100 Subject: Is there a way to comment a key locally? In-Reply-To: <55B8403B.8050207@gmail.com> References: <55B8403B.8050207@gmail.com> Message-ID: <867147768.20150729120550@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Wednesday 29 July 2015 at 3:53:47 AM, in , fmv1992 at gmail.com wrote: > Is there a way to comment a key locally? I think the closest currently available is a non-exportable signature with brief comment in a signature notation. - -- Best regards MFPA Two rights do not make a wrong. They make an airplane. -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJVuLOUXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwqHMIAIwtPbemT+hyeJhoUe+ap2P9 YNroRAFptjxinnhtiSDc8T8PaGc24latkQNT782Shl03i18EeBtU6q7RVebQp75W h8PWPPrSHqndagHTtqrYQDLSLf73aWx5S601xobt4kE6KcES4P3LDR/+qxfO8tSX hRWrVVofRE3fkixTz2s19CxtNqf1axkrGmjx9ZnIxblAIS6EM0GgD+mkscrktiq+ 1pe+hjuvR1Itoq+2Du49vvewrNfEc+1AzeL5UMwl7Cph6QGOP7oBMxX7FrEiO6Lg 428FtzxwEWbqpWj0rRJvERjop9rY+erj8dLlepRXWW+fwO0MJNIhQi1bok6ImVeI vgQBFgoAZgUCVbizlF8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45OWSAQD8JAdzdLxYs4V4Ugx9/NEA2R2T sUu1LPtKd4cwgWbiSgEA3i8bw3hwvM8iNg5oXGpIkHiwj10bU78ZtFXKHS+kbAc= =bZmx -----END PGP SIGNATURE----- From nico at enigmail.net Wed Jul 29 13:07:20 2015 From: nico at enigmail.net (nico at enigmail.net) Date: Wed, 29 Jul 2015 13:07:20 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <12203261.aOCGBWf565@collossus.ingo-kloecker.de> References: <55B5C7B7.4090907@enigmail.net> <55B7D548.4020104@enigmail.net> <19610726502.20150729014854@my_localhost> <12203261.aOCGBWf565@collossus.ingo-kloecker.de> Message-ID: <55B8B3E8.9080702@enigmail.net> Hmmm, first i talked to him/them a couple of times personally (there are multiple editors at that magazine) about the issue in detail and tried to convince them following the WoT without success. Note that they just behave as ordinary users, having not much time to deal with the problems of OpenPGP. They get hundreds of emails per day and each email they can't read is a significant problem because the 2 seconds they have for reading emails turn out to become minutes. There should simply be no overhead in using OpenPGP in the ordinary case for the ordinary user. And I agree with that. Usability is key for a broad acceptance. I don't want to have the same problem. And other tools also don't want to have it anymore (e.g. the GPGTools.org guys have the same problem). I see no reason NOT to solve this problem, but I see many reasons to solve it. Just saying "deal with it" simply means that we place unneccesary burden on OpenPGP users. IMO, that's a really bad approach. Am 29.07.2015 um 12:38 schrieb Ingo Kl?cker: > On Wednesday 29 July 2015 01:48:54 MFPA wrote: >> On Tuesday 28 July 2015 at 8:17:28 PM, in >> , nico at enigmail.net wrote: >>> AFAIK, there are not THAT many faked keys, but the >>> problem exists especially for key parties of our >>> internet world (a famous German magazine, at least one >>> GPG tool, ...). The problem is that the German magazine >>> takes this as a show stopper (both personally and >>> publicly). I really want to have them back on our road >>> for more encryption with OpenPGP. And the "publicity" >>> we get from not validating email addresses is really a >>> big problem (especially as fixing that problems sounds >>> so easy and obvious). Thus, without fixing this, IMO >>> the whole OpenPGP movement has a reputation problem. >> >> I understand what you are saying. I cannot help but think they are >> making a mountain out of a molehill by characterising this minor >> irritation as a "show stopper". > > Yes, he (not they!), the author of the article is doing exactly this. > > >> Putting something in place to >> counteract the issue is one approach. Would it not be an equally-valid >> approach to educate them as to why it is a non-issue, which they could >> then disseminate through their magazine? > > I think that the author of the article knows that it's mostly a non-issue. He > still decided to write the article "Forged PGP Keys in the Wild" [1] and even > an accompanying editorial titled "Let PGP Die!" [2]. I guess he simply got > pissed because he received so many messages that were undecryptable with his > real key. > > Luckily, there are also more sensible authors working for this magazine who > write good articles about OpenPGP. > > I personally chose to ignore the stupid editorial. IMHO it does not deserve > more attention than any other rant written by a random troll. OTOH, the > article actually isn't that bad. It points out the issue with the missing > validation of email addresses in UIDs making a bit of a fuss about it, but > IIRC it also explains how to avoid falling into the trap of using a fake key. > > > Regards, > Ingo > > > [1] http://www.heise.de/artikel-archiv/ct/2015/06/160_Die-Schluessel-Falle > (German; needs to be bought) > [2] https://www.heise.de/artikel-archiv/ct/2015/06/3_Editorial (German; free) > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- Nicolai M. Josuttis www.josuttis.de mailto:nico at enigmail.net PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5 From kristian.fiskerstrand at sumptuouscapital.com Wed Jul 29 13:14:56 2015 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 29 Jul 2015 13:14:56 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <55B8B3E8.9080702@enigmail.net> References: <55B5C7B7.4090907@enigmail.net> <55B7D548.4020104@enigmail.net> <19610726502.20150729014854@my_localhost> <12203261.aOCGBWf565@collossus.ingo-kloecker.de> <55B8B3E8.9080702@enigmail.net> Message-ID: <55B8B5B0.7060506@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 07/29/2015 01:07 PM, nico at enigmail.net wrote: > Hmmm, > There should simply be no overhead in using OpenPGP in the ordinary > case for the ordinary user. > Any secure system needs proper operational security surrounding it, that require user awareness. So if security/privacy is a priority, there needs to be an overhead (it might even serve a purpose as it reminds the user about the the proper procedures to follow). Quick example; They can use OpenPGP all they want, doesn't help one bit if the private keys are stored on the computer, running a 10 year old version of Operating System XY with so many trojan horses working on copying the private key data that they are fighting over the resources on the computer. To paraphrase Schneier, security isn't a product it is a process. - -- - ---------------------------- Kristian Fiskerstrand Blog: http://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 - ---------------------------- "Action is the foundational key to all success" (Pablo Picasso) -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJVuLWrAAoJECULev7WN52FabcH/3NYi5yWdKNZgAmee/gFy6cB GNVYn1xxK/JI6X0/rJ58OfCbAvzxmDzpM6/FCZJ61uPFFi3UCchqkupaHKdOfkqj qVsPtavL3jeq4h/2ZXxajHiGFATGZyyO2GMQtB+TzXLwbFijErxrpE9vswBri+HH rrNRtxZM1rE7LpI0frGCS99wbcv8en0BVG6zafkKq2hA9JNDSzjnxCkqqNcRXDZL wWhCrdzobdaoxE+TPN8v7IXLdgPeLa4J9MwvT15RiS4lE07bmFuYgmtSWBWJGZQo ph8mBlii1myCedVe4oTzO5Uu2U3lO7fKi91dXz2/8GGU07TqEWTZLd7TLt6wCGA= =loYp -----END PGP SIGNATURE----- From dgouttegattat at incenp.org Wed Jul 29 13:34:00 2015 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Wed, 29 Jul 2015 13:34:00 +0200 Subject: Use Private DOs In-Reply-To: <55B88A5D.5010606@chezgeek.fr> References: <55B88A5D.5010606@chezgeek.fr> Message-ID: <55B8BA28.8050505@incenp.org> On 07/29/2015 10:10 AM, Antoine Michard wrote: > how to delete field or how to show field #3 & #4 Private DOs #3 and #4 are only readable once the User and Admin PIN, respectively, have been verified. So to show the contents of Private DO #3 : $ gpg --card-edit gpg/card> verify [enter your User PIN when prompted] gpg/card> list And to show the contents of Private DO #4 : $ gpg --card-edit gpg/card> admin verify [enter your Admin PIN when prompted] gpg/card> list As for the deleting the contents of one of those fields, I don't think you can specify an empty value (gpg's card editor won't let you do that anyway, as you have seen). What you *can* do is replacing the contents by any non-significant value, such as "none", "0", or even a non-breakable space character (a normal space character won't do, because it will be trimmed by gpg). 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 neal at walfield.org Wed Jul 29 14:07:21 2015 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 29 Jul 2015 14:07:21 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <1587154033.20150729010353@my_localhost> References: <55B5C7B7.4090907@enigmail.net> <87y4i0n3v4.wl-neal@walfield.org> <1305965287.20150728192229@my_localhost> <87vbd3nbnx.wl-neal@walfield.org> <1587154033.20150729010353@my_localhost> Message-ID: <87twsnmakm.wl-neal@walfield.org> At Wed, 29 Jul 2015 01:03:53 +0100, MFPA wrote: > On Tuesday 28 July 2015 at 11:46:10 PM, in > , Neal H. Walfield wrote: > > At Tue, 28 Jul 2015 19:22:29 +0100, MFPA wrote: > >> It also eliminates any attempt to to establish a link > >> between the key and the email address in the UID. > > > I'm not so sure. Recall that we are not attempting to > > protect against attacks by nation states. As such, > > performing a week of computation each year is going to > > be too much to maintain for those who upload fake keys. > > And too much for people with multiple email addresses. It doesn't have to be per-email address. It is sufficient to attach it to the primary key. > This still seems less rigorous to me than having to receive an email > sent to that address and decrypt it with that key. I guess it's a case > of swings and roundabouts. Well, I don't like the CA model and that's what Nico is basically proposing (with less rigorous checks). Another huge disadvantage is that user's have to actively participate by replying to emails / visiting a link. Using PoW, no human intervention is required and there is no central authority. PoW relies on the assumption that conducting an attack is too expensive to do / maintain. :) Neal From neal at walfield.org Wed Jul 29 14:09:54 2015 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 29 Jul 2015 14:09:54 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <1076303842.20150729023047@my_localhost> References: <55B5C7B7.4090907@enigmail.net> <874mkpokxu.wl-neal@walfield.org> <1076303842.20150729023047@my_localhost> Message-ID: <87lhdzmagd.wl-neal@walfield.org> At Wed, 29 Jul 2015 02:30:47 +0100, MFPA wrote: > On Monday 27 July 2015 at 1:15:57 PM, in > , Neal H. Walfield wrote: > > > > Regarding the design: personally, I wouldn't have the > > user follow a link that includes a swiss number, but > > have the user reply to the mail, include the swiss > > number and sign it. > > > Why not simplify the workflow:- > > 1. key reaches validation server. > > 2. for each UID containing an email address, validation server creates > a copy of the key stripped of all other UIDs. > > 3. validation server signs that copy of the key. > > 4. validation server pastes the signed key into an email, encrypts the > email to that key, and sends it to the email address in the UID. > > 5. user receives each email, decrypts it, and updates their local copy of > their key. > > 6. user uploads key now bearing the validation server's signatures to > a keyserver. > > > There is still the same level of assurance that the email address and > private key are controlled by the same entity. Advantages are:- > > a. Nobody is asked to click links or reply to emails. > > b. The validation server does not need to manage a "stack" of keys > awaiting feedback from the validation emails. > > c. Changes to the user's key are uploaded to the keyserver by the > user, not by the validation server. Personally, I think c is the killer in this plan: people aren't going to bother to upload it (assuming they even get that far)! Neal From 2014-667rhzu3dc-lists-groups at riseup.net Wed Jul 29 14:25:31 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Wed, 29 Jul 2015 13:25:31 +0100 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <55B867CA.9090501@enigmail.net> References: <55B5C7B7.4090907@enigmail.net> <874mkpokxu.wl-neal@walfield.org> <1076303842.20150729023047@my_localhost> <55B867CA.9090501@enigmail.net> Message-ID: <937045624.20150729132531@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Wednesday 29 July 2015 at 6:42:34 AM, in , nico at enigmail.net wrote: > Interesting. What comes into my mind is the following: > - This requires special email clients. How would this require a special email client? OpenPGP-aware email clients I have used have a simple way to save a key from a message to the keyring by clicking a button or selecting a menu option. And if the user's email client is not OpenPGP-aware, or they use webmail, there is always copy and paste. > The benefit of > the proposed workflow is that any existing client can > use it just by switching its keyserver to the > validating keyserver proxy. I only suggested simplification of the workflow for actually validating/signing the keys. The user can still just switch their keyserver of choice to the validating proxy. > How to > deal with existing keys? Well probably the same > (upload a key for the first time and uploading it > for updates would run the saem workflow), right? Yes. And for automatic re-validations, before my step 1 (key reaches validation server) the proxy server would consult its list of which keys it signed when and fetch them for revalidation. >> There is still the same level of assurance that the >> email address and private key are controlled by the >> same entity. Advantages are:- >> a. Nobody is asked to click links or reply to emails. > Hmm, isn't step 5 is kind of that? No. Step 5 is that the user receives an encrypted email to each relevant email address containing a copy of their key with the additional signature on just that UID, much as they might receive from other attendees at a keysigning. If they wish, the user saves the updated key to their keyring. And, again if they wish, the user uploads their updated key to a keyserver. > In any case some > confirmation email handling is required. For each UID, the copy of the key containing a validation signature over only that UID would be sent in an encrypted email to the email address in that UID. Receipt of the email containing the signed key confirms the ability to receive messages sent to that email address. And decryption of that email confirms access to the private key. What else do you need to confirm? >> c. Changes to the user's key are uploaded to the >> keyserver by the user, not by the validation >> server. > Is this a real benefit? It's the user's key. Denying them the choice by uploading your changes directly to keyservers is pretty arrogant. Maybe you could have the validating proxy upload the changes itself in the event the the key you are validating does not have the keyserver no-modify flag set? - -- Best regards MFPA Think for yourself. Otherwise you have to believe what other people tell you. -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJVuMZGXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXweqgH/Aq5kO8qt0dJLy0J7W73I8k2 TXjCir9yvYvlqIliJpoYRbV5TC4N/k0xI6d+kx/J825V81xjpi6wgtLHXpF3tii4 rGdEniBgzJmoZvSNVVUhbzgy/Nd7RdMAL/ZF0PVfGsG0fg0MRSonikG1AUVxk9S8 JOXNfq5suDhx3hIA0W5qL0ecWSWRfbwFmUXcO9C59oTd90Do1Noz7LAAizzeNOgT ZeM7wuGlOicqqRGVKppxJ64LlRlkRc/WHkbZlubDw3iR4d3iqwAMam+/tI1vDvDg 9YHu7M91FHqPPIKFd8cCVbcFBdnBctucYVvC07KnCKOeqPBmCE+EnHoxwRm22reI vgQBFgoAZgUCVbjGcF8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45J7bAP0dlJftV38bRaG70yc2g0ZMOUCv hMpVCeNAbfYKXoQmwwEA/TzLo6o28HFJ3pjaQ/ZGr8x0sR4RzBsMJ9JwUWw+4AE= =5N4q -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Wed Jul 29 14:41:42 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Wed, 29 Jul 2015 13:41:42 +0100 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <1713361.R4RmYyGI3m@collossus.ingo-kloecker.de> References: <55B5C7B7.4090907@enigmail.net> <1076303842.20150729023047@my_localhost> <55B867CA.9090501@enigmail.net> <1713361.R4RmYyGI3m@collossus.ingo-kloecker.de> Message-ID: <1907782805.20150729134142@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Wednesday 29 July 2015 at 11:05:13 AM, in , Ingo Kl?cker wrote: > A possible benefit would be that the user can choose > not to upload the validation signatures to the > keyservers. With a minor change in step 1 (the key > owner uploads his key to the validation server without > uploading it to a keyserver) the UID validation would > even work for keys which its owner does not want to > upload to a public keyserver. That would be good: mail clients that applied a rule to only use validated keys would otherwise deny service when emailing somebody who is trying to keep their key off the keyservers. - -- Best regards MFPA If at first you don't succeed, destroy all evidence that you tried. -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJVuMoGXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwMtoH/iPmxI7H2eaewn8kqa5fzmTE X/zvQ2HpSwEuh7EU6o18pTZungVVpHQ03vMYAWtvGhUNw771IJT8t1KGGMBDavlg sMFTmYDn4vuJIGwr0n3hxyHfEjY81qe4TM9cQ41DxRCDcRT+pd0vkpiKrQdcEizc DDdZB8PtM+UQnIfQIg7Av8OSC/JaDKqZlxgctqiHyGx1fvMPhFNwWQblgnr3Oxnc CEBd2/vdFaVSpHTxnVuhbfFXNc0oRNdf7o894vvchpNMcjSmxXYXxmlugxdSK4v5 2az5KAMdZ8GKR4K0FsnIXxiEoJ/E2Slu7TTcmqAiRxYxAAFzmrLSZ7BvT1tphxiI vgQBFgoAZgUCVbjKKV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45J0PAP9UraHwesfTkIc0jUqOVuJpqfBD MdnlNiMthNBz4NXwOQEA6YyB96i/U+YpEMPogOtKfR1ohBg7/nh00ZjMSpi27QE= =I0b9 -----END PGP SIGNATURE----- From kristian.fiskerstrand at sumptuouscapital.com Wed Jul 29 14:47:35 2015 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 29 Jul 2015 14:47:35 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <1907782805.20150729134142@my_localhost> References: <55B5C7B7.4090907@enigmail.net> <1076303842.20150729023047@my_localhost> <55B867CA.9090501@enigmail.net> <1713361.R4RmYyGI3m@collossus.ingo-kloecker.de> <1907782805.20150729134142@my_localhost> Message-ID: <55B8CB67.105@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 07/29/2015 02:41 PM, MFPA wrote: > Hi > > > On Wednesday 29 July 2015 at 11:05:13 AM, in > , Ingo Kl?cker > wrote: > > >> A possible benefit would be that the user can choose not to >> upload the validation signatures to the keyservers. With a minor >> change in step 1 (the key owner uploads his key to the validation >> server without uploading it to a keyserver) the UID validation >> would even work for keys which its owner does not want to upload >> to a public keyserver. > > That would be good: mail clients that applied a rule to only use > validated keys would otherwise deny service when emailing somebody > who is trying to keep their key off the keyservers. Are they really the target group for this proposal? Keep in mind this would be in addition to the regular WoT model, so there is no DoS based on that, per se (obviously you should never encrypt data to a key that isn't verified on some level, even if just a heuristic analysis based on public data and a local non-exportable signature). If the key isn't on keyserver it defeats some of the purpose of this being an easy to use for senders (while still providing _some_ level of security). - -- - ---------------------------- Kristian Fiskerstrand Blog: http://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 - ---------------------------- "A committee is a group that keeps minutes and loses hours." (Milton Berle) -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJVuMtjAAoJECULev7WN52F0C8H/1LMy2GnsLr6WRAcPj9jMAvS IwpL+oe5cTdTtpdIcs7s5PhRXwQsbmGdlVaPllsbFn4mAOJ2x7eD7fe/hIHkIPGX +ocZk6h9GlgK6wadNp5mbJ9egxYVVnV84+64S07GAx6IQ9NpOOa+BEa4VDL0UcI/ uLx1LO/9Fkj/gg5IM9YrM3ToLhcotMfen/wQE5dAQ5Zcb2BcDWAGw9mCTzs+a4LY 06w0Q5cRuQDUTcrmrGs5Y23BIRjtijPqEvamWhGynokeR1dmG1axbBAWgRzZAsQl XPoDYLaldAXqPPqLUoNN/IBtJ+7c8MUVlkYTccIzTkYnsqFfGZimEo1mx1DmiNQ= =0Gtq -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Wed Jul 29 15:05:49 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Wed, 29 Jul 2015 14:05:49 +0100 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <87lhdzmagd.wl-neal@walfield.org> References: <55B5C7B7.4090907@enigmail.net> <874mkpokxu.wl-neal@walfield.org> <1076303842.20150729023047@my_localhost> <87lhdzmagd.wl-neal@walfield.org> Message-ID: <225902045.20150729140549@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Wednesday 29 July 2015 at 1:09:54 PM, in , Neal H. Walfield wrote: > Personally, I think c is the killer in this plan: > people aren't going to bother to upload it (assuming > they even get that far)! They have gone to the effort of sending it to the validation server to obtain the validation signature. It is up to them whether they publish it to a server, publicise it in some other way, send it to their contacts directly, or just do nothing. - -- Best regards MFPA Volvo, Video, Velcro. (I came, I saw, I stuck around.) -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJVuM+0XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwO04H/1FPkm+NLuMKhSSPW3hWfGQj FCYNxrbPcV+NICLD9pnvU4sQBYK14sJ2n6gSzgQZA58x+IiV9tI/xtCDIPMiR9L9 AAfk+Ru2zbfABGALH5E/9Wem8bIc47hCQNfTjp2R3qemCev2IZ2/FhxVA6qGtLS5 OKh3sM2QmrYtSIpElsMnaYYcGmFsIEzBZo89DBksWJlwQkljGsXHzFAN2zOQc8Lo N7sBIxujPOXZFgt3y9RZQjS3WhDWSsV3QLEcCn1q7N7lKVcLGn9HtP2P4iRk6S1J ZKK9wbY6VN2btNx/4taa4xBgjAwCJC+j/XizMXWHR1E05GwWHGQSl52b8tcNb/iI vgQBFgoAZgUCVbjPwV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45C1VAP931XFbBRTuo5uUqo8vEqh02VNJ XnNNsXgTLkpkYgPNcAD/eFS0Rh9qzWF+Nb8GQEgeKITsjmvF+eHbnyuPQXqPDgQ= =C5qa -----END PGP SIGNATURE----- From kloecker at kde.org Wed Jul 29 15:14:07 2015 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Wed, 29 Jul 2015 15:14:07 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <87lhdzmagd.wl-neal@walfield.org> References: <55B5C7B7.4090907@enigmail.net> <1076303842.20150729023047@my_localhost> <87lhdzmagd.wl-neal@walfield.org> Message-ID: <5368668.NjoS34tb11@collossus.ingo-kloecker.de> On Wednesday 29 July 2015 14:09:54 Neal H. Walfield wrote: > At Wed, 29 Jul 2015 02:30:47 +0100, > > MFPA wrote: > > On Monday 27 July 2015 at 1:15:57 PM, in > > > > , Neal H. Walfield wrote: > > > Regarding the design: personally, I wouldn't have the > > > user follow a link that includes a swiss number, but > > > have the user reply to the mail, include the swiss > > > number and sign it. > > > > Why not simplify the workflow:- > > > > 1. key reaches validation server. > > > > 2. for each UID containing an email address, validation server creates > > > > a copy of the key stripped of all other UIDs. > > > > 3. validation server signs that copy of the key. > > > > 4. validation server pastes the signed key into an email, encrypts the > > > > email to that key, and sends it to the email address in the UID. > > > > 5. user receives each email, decrypts it, and updates their local copy of > > > > their key. > > > > 6. user uploads key now bearing the validation server's signatures to > > > > a keyserver. > > > > There is still the same level of assurance that the email address and > > private key are controlled by the same entity. Advantages are:- > > > > a. Nobody is asked to click links or reply to emails. > > > > b. The validation server does not need to manage a "stack" of keys > > > > awaiting feedback from the validation emails. > > > > c. Changes to the user's key are uploaded to the keyserver by the > > > > user, not by the validation server. > > Personally, I think c is the killer in this plan: people aren't going > to bother to upload it (assuming they even get that far)! If you replace "validation server" with "keysigning party participant" then you get one of the ways participants of keysigning parties get their signatures to the key owners. So, it's already done and people do upload their signed keys. I don't see why people should behave differently for validation servers. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From neal at walfield.org Wed Jul 29 15:16:55 2015 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 29 Jul 2015 15:16:55 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <225902045.20150729140549@my_localhost> References: <55B5C7B7.4090907@enigmail.net> <874mkpokxu.wl-neal@walfield.org> <1076303842.20150729023047@my_localhost> <87lhdzmagd.wl-neal@walfield.org> <225902045.20150729140549@my_localhost> Message-ID: <87k2tjm7co.wl-neal@walfield.org> At Wed, 29 Jul 2015 14:05:49 +0100, MFPA wrote: > On Wednesday 29 July 2015 at 1:09:54 PM, in > , Neal H. Walfield wrote: > > > > Personally, I think c is the killer in this plan: > > people aren't going to bother to upload it (assuming > > they even get that far)! > > They have gone to the effort of sending it to the validation server > to obtain the validation signature. It is up to them whether they > publish it to a server, publicise it in some other way, send > it to their contacts directly, or just do nothing. I suspect that >95% of users won't bother. This would defeat the entire scheme, which requires widespread buy in to be successful. Neal From neal at walfield.org Wed Jul 29 15:22:52 2015 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 29 Jul 2015 15:22:52 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <5368668.NjoS34tb11@collossus.ingo-kloecker.de> References: <55B5C7B7.4090907@enigmail.net> <1076303842.20150729023047@my_localhost> <87lhdzmagd.wl-neal@walfield.org> <5368668.NjoS34tb11@collossus.ingo-kloecker.de> Message-ID: <87io93m72r.wl-neal@walfield.org> At Wed, 29 Jul 2015 15:14:07 +0200, Ingo Kl?cker wrote: > If you replace "validation server" with "keysigning party participant" then > you get one of the ways participants of keysigning parties get their > signatures to the key owners. So, it's already done and people do upload their > signed keys. I don't see why people should behave differently for validation > servers. Key signing parties are a surprisingly good example that demonstrate my point. Key signing parties are a bizarre geek ritual. Most people don't do it. And, I think, most people won't use the validation servers. Neal From kloecker at kde.org Wed Jul 29 15:33:04 2015 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Wed, 29 Jul 2015 15:33:04 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <55B8B3E8.9080702@enigmail.net> References: <55B5C7B7.4090907@enigmail.net> <12203261.aOCGBWf565@collossus.ingo-kloecker.de> <55B8B3E8.9080702@enigmail.net> Message-ID: <12294450.FTEalgxVN0@collossus.ingo-kloecker.de> [Please do not CC me. I am subscribed.] On Wednesday 29 July 2015 13:07:20 nico at enigmail.net wrote: > I see no reason NOT to solve this problem, > but I see many reasons to solve it. > > Just saying "deal with it" simply means that > we place unneccesary burden on OpenPGP users. > IMO, that's a really bad approach. Sure. All I'm saying is that introducing a second centralized CA PKI does not strike me as a good solution. Actually, I think this is more of an educational or a social problem than it is a technical problem. The problem you have to solve is that people blindly trust the UIDs. You cannot counter people's ignorance about how OpenPGP and the WoT works with technical means. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From 2014-667rhzu3dc-lists-groups at riseup.net Wed Jul 29 15:41:07 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Wed, 29 Jul 2015 14:41:07 +0100 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <87twsnmakm.wl-neal@walfield.org> References: <55B5C7B7.4090907@enigmail.net> <87y4i0n3v4.wl-neal@walfield.org> <1305965287.20150728192229@my_localhost> <87vbd3nbnx.wl-neal@walfield.org> <1587154033.20150729010353@my_localhost> <87twsnmakm.wl-neal@walfield.org> Message-ID: <562982140.20150729144107@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Wednesday 29 July 2015 at 1:07:21 PM, in , Neal H. Walfield wrote: > It doesn't have to be per-email address. It is > sufficient to attach it to the primary key. Fair enough if it is just to signify the key is in current usage. But I think it does have to be per-email address if the point is to address the same issue as Nico's scheme. The key announcements in Mike Ingle's Confidant Mail include a Proof of Work, and I think they are done every few days. If you stop using the key, it stops being announced and over time disappears from the DHT. But the keys there do not have multiple addresses. (They don't really even *need* an address, the fingerprint will suffice.) > Well, I don't like the CA model and that's what Nico is > basically proposing (with less rigorous checks). > Another huge disadvantage is that user's have to > actively participate by replying to emails / visiting a > link. Yes, PoW has none of that. If you went for a per-UID PoW and a common validation signature notation with Nico's scheme ("type": "ProofOfWork" instead of "enc-email"), the schemes could operate together as compatible alternatives. - -- Best regards MFPA Working hard. Please interrupt at once. -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJVuNf/XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwcdAIAJ5TDVjiz2DdRDW9Iq8k9B2q cBlSqWRrje2thrwhWHM4GsN4rJsst3aBGOpaZLLWwo0KK9BP88B68ahej38+OHb1 l+OU55OVlmQ87/Op5vsmKlr9yuXM/uYrYJO1mCOzr4KGoq2eptfcIBH7ZakcZDQq GVZHN8AZRPfa1Gm5l90IqRMrkSkY/D9boWhjKhIAlHWdRLV92V8TdGex1Mg7bTOD BboAnUkWi0uYbHy8ISrYxTOrM+wou0TV7eOdTrTrVtkV9cth+hai/XARNvdmfBrj BJZKvLByGd1Hp+bUUYDz95U/oCcRieZEoLOEDlhqbWzMLiomUUUKretDz3scz++I vgQBFgoAZgUCVbjYBl8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45AJZAP9104lD12MmcWKsxQug4R86eekA VQMFRSAMAK6dsyElhwD7B2IyijCYyv8SZqZrMXiinXKU8RBh+ZPfhP4F1tBIhwc= =wVtr -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Wed Jul 29 15:42:38 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Wed, 29 Jul 2015 14:42:38 +0100 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <55B8B3E8.9080702@enigmail.net> References: <55B5C7B7.4090907@enigmail.net> <55B7D548.4020104@enigmail.net> <19610726502.20150729014854@my_localhost> <12203261.aOCGBWf565@collossus.ingo-kloecker.de> <55B8B3E8.9080702@enigmail.net> Message-ID: <1802578865.20150729144238@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Wednesday 29 July 2015 at 12:07:20 PM, in , nico at enigmail.net wrote: > They get hundreds of emails per day and each email they > can't read is a significant problem because the 2 > seconds they have for reading emails turn out to become > minutes. I would expect each time they got "no secret key" they would spend a couple of seconds to fire back an email of boilerplate text saying they couldn't decrypt and containing the correct key. > There should simply be no overhead in using > OpenPGP in the ordinary case for the ordinary user. Any security measure has overhead. It takes longer to open a door if you have to unlock it first, and then there's the overhead of having to look after a key or remember an access code. (-: > I see no reason NOT to solve this problem, but I see > many reasons to solve it. I was just questioning whether it is really a problem. If it is, and the effort to solve it is less than the effort to just deal with it, then it should be solved. - -- Best regards MFPA Experience is the name everyone gives to their mistakes -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJVuNhPXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwJPMH/iFT5dzzuD7elMJXPnDEzvQY QSmbFnB9iKtw4FdM0Hi/Hk1VlY0iSzzxipIEAZD2Tx9L8gKwv/PJTNm5hFk5ajrq ObGl3h5c/z+ZdXWm0sBVbKYOv641wyNpK6TtecCPtHU88OeApyFrAq39xc3GqvHD MCm5GSDluT9mw5/0EaNsOgqCaMsUbhcdpQbic39tvXsEsWm57LyqJ2PuxsvFheo8 N2txlfpJV22nIiSzMtvNKYc67utyGsihcwXK0hg3p11bIKZWKoDCzlMNNAhofZER HNefknmxJaXrqNYvwXp10dGNDl1kQXVZWRy6pJvJgqErXEgIoItBCMiay3mMVmuI vgQBFgoAZgUCVbjYT18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45ErmAQCH0BlkGuDeV6mSKThVPkc1Q6EL QuK5956kri9B5/LJDgD/QJV28U42WN0Q8hK/g+p5Pao0pAXPm8b+Fu79/qAThwU= =KJDo -----END PGP SIGNATURE----- From wk at gnupg.org Wed Jul 29 15:43:34 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 29 Jul 2015 15:43:34 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <12203261.aOCGBWf565@collossus.ingo-kloecker.de> ("Ingo =?utf-8?Q?Kl=C3=B6cker=22's?= message of "Wed, 29 Jul 2015 12:38:46 +0200") References: <55B5C7B7.4090907@enigmail.net> <55B7D548.4020104@enigmail.net> <19610726502.20150729014854@my_localhost> <12203261.aOCGBWf565@collossus.ingo-kloecker.de> Message-ID: <871tfr2i61.fsf@vigenere.g10code.de> On Wed, 29 Jul 2015 12:38, kloecker at kde.org said: > I personally chose to ignore the stupid editorial. IMHO it does not deserve > more attention than any other rant written by a random troll. OTOH, the The publication came to a surprise to me given that we had a mail Q+A in the week before to explain what keyservers are and what they are not. I later heard rumors that he was working on that article for a year. I spent some time to rebute it (in German): http://rem.eifzilla.de/archives/2015/02/24/re-die-schlssel-falle Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From 2014-667rhzu3dc-lists-groups at riseup.net Wed Jul 29 16:02:37 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Wed, 29 Jul 2015 15:02:37 +0100 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <55B8CB67.105@sumptuouscapital.com> References: <55B5C7B7.4090907@enigmail.net> <1076303842.20150729023047@my_localhost> <55B867CA.9090501@enigmail.net> <1713361.R4RmYyGI3m@collossus.ingo-kloecker.de> <1907782805.20150729134142@my_localhost> <55B8CB67.105@sumptuouscapital.com> Message-ID: <559799852.20150729150237@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Wednesday 29 July 2015 at 1:47:35 PM, in , Kristian Fiskerstrand wrote: > On 07/29/2015 02:41 PM, MFPA wrote: >> That would be good: mail clients that applied a rule >> to only use validated keys would otherwise deny >> service when emailing somebody who is trying to keep >> their key off the keyservers. > Are they really the target group for this proposal? The target group for an email address validation certificate on my key would be people who wanted to email me. - -- Best regards MFPA Humility is no substitute for a good personality. -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJVuNz9XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwTTkH/joN2TCMNlj/JrXyZnaHelQH Hr2Of7WCADGMhkWNbcRmR7IjJXGvsZurSPtTVQL2i6LLvLnrPd+3Xr8eOyyIynLX WTX05ecxGl5RLcSlZsO6ocCRySFBSb0RNlkdoDloWex8slpe1ShVfg4zprn5/XeE SmBxuyQ2QDvPvplVuQrJ5oemB1U4mLhJWvlZLDqW1QJSr2ASCmu5nFNcjYlbvGKV 2LPvL0uga4HbNwCB45yFkpVADdQm7QSW5ndqgg3rfZmVe621I+r40L+kjjB6ACQP X+kQhQ0MSVW8OKZfel+Yu5pRSKtzYDcKVS3NU71sKxqbofgRzRbMv90ZW/+s/AGI vgQBFgoAZgUCVbjdAl8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45GdwAQCNcHKFzUus0OvHZKoIA+JGIUhT D85F88TRBFViq2VYigEA77mLohKUDTNLLOIFxGYq/FxAmqpZbEwoJeiFRvwdlQo= =HtQo -----END PGP SIGNATURE----- From kristian.fiskerstrand at sumptuouscapital.com Wed Jul 29 16:13:06 2015 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 29 Jul 2015 16:13:06 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <559799852.20150729150237@my_localhost> References: <55B5C7B7.4090907@enigmail.net> <1076303842.20150729023047@my_localhost> <55B867CA.9090501@enigmail.net> <1713361.R4RmYyGI3m@collossus.ingo-kloecker.de> <1907782805.20150729134142@my_localhost> <55B8CB67.105@sumptuouscapital.com> <559799852.20150729150237@my_localhost> Message-ID: [Sent from my HTC, as it is not a secured device there are no cryptographic keys on this device, meaning this message is sent without an OpenPGP signature. In general you should *not* rely on any information sent over such an unsecure channel, if you find any information controversial or un-expected send a response and request a signed confirmation] On Jul 29, 2015 4:02 PM, "MFPA" <2014-667rhzu3dc-lists-groups at riseup.net> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi > > > On Wednesday 29 July 2015 at 1:47:35 PM, in > , Kristian Fiskerstrand wrote: > > > > On 07/29/2015 02:41 PM, MFPA wrote: > >> That would be good: mail clients that applied a rule > >> to only use validated keys would otherwise deny > >> service when emailing somebody who is trying to keep > >> their key off the keyservers. > > > Are they really the target group for this proposal? > > The target group for an email address validation certificate on my key > would be people who wanted to email me. You are still in control of that given that you can (i) opt not to click the validation link, so other users defer back to WoT, same as today (ii) elect not to give any ownertrust to the CA -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick at enigmail.net Wed Jul 29 17:49:10 2015 From: patrick at enigmail.net (Patrick Brunschwig) Date: Wed, 29 Jul 2015 17:49:10 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <87twsnmakm.wl-neal__28203.1449526132$1438171737$gmane$org@walfield.org> References: <55B5C7B7.4090907@enigmail.net> <87y4i0n3v4.wl-neal@walfield.org> <1305965287.20150728192229@my_localhost> <87vbd3nbnx.wl-neal@walfield.org> <1587154033.20150729010353@my_localhost> <87twsnmakm.wl-neal__28203.1449526132$1438171737$gmane$org@walfield.org> Message-ID: <55B8F5F6.9080106@enigmail.net> On 29.07.15 14:07, Neal H. Walfield wrote: > At Wed, 29 Jul 2015 01:03:53 +0100, > MFPA wrote: >> On Tuesday 28 July 2015 at 11:46:10 PM, in >> , Neal H. Walfield wrote: >>> At Tue, 28 Jul 2015 19:22:29 +0100, MFPA wrote: >>>> It also eliminates any attempt to to establish a link >>>> between the key and the email address in the UID. >> >>> I'm not so sure. Recall that we are not attempting to >>> protect against attacks by nation states. As such, >>> performing a week of computation each year is going to >>> be too much to maintain for those who upload fake keys. >> >> And too much for people with multiple email addresses. > > It doesn't have to be per-email address. It is sufficient to attach > it to the primary key. This allows me to have patrick at enigmail.net verified OK. Then I add a new UID mallory at evil.com and delete patrick at enigmail.net from the key. And then I upload my key to the keyservers network, and I'll end up where we are now. >> This still seems less rigorous to me than having to receive an email >> sent to that address and decrypt it with that key. I guess it's a case >> of swings and roundabouts. > > Well, I don't like the CA model and that's what Nico is basically > proposing (with less rigorous checks). Another huge disadvantage is > that user's have to actively participate by replying to emails / > visiting a link. > > Using PoW, no human intervention is required and there is no central > authority. PoW relies on the assumption that conducting an attack is > too expensive to do / maintain. The whole point of this exercise is to verify that the key and the email address(es) belong _together_. I don't see how PoW could do this, or I didn't understand it well enough. -Patrick From nico at enigmail.net Wed Jul 29 18:24:08 2015 From: nico at enigmail.net (nico at enigmail.net) Date: Wed, 29 Jul 2015 18:24:08 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <562982140.20150729144107@my_localhost> References: <55B5C7B7.4090907@enigmail.net> <87y4i0n3v4.wl-neal@walfield.org> <1305965287.20150728192229@my_localhost> <87vbd3nbnx.wl-neal@walfield.org> <1587154033.20150729010353@my_localhost> <87twsnmakm.wl-neal@walfield.org> <562982140.20150729144107@my_localhost> Message-ID: <55B8FE28.4060600@enigmail.net> Am 29.07.2015 um 15:41 schrieb MFPA: >> Well, I don't like the CA model and that's what Nico is >> basically proposing (with less rigorous checks). >> Another huge disadvantage is that user's have to >> actively participate by replying to emails / visiting a >> link. > > Yes, PoW has none of that. > > If you went for a per-UID PoW and a common validation signature > notation with Nico's scheme ("type": "ProofOfWork" instead of > "enc-email"), the schemes could operate together as compatible > alternatives. I am happy to propose other way of validation. Unfortunately I didn't understand the PoW approach yet. So, could somebody explain in a bit more detail how a PoW approach works? In my scenario a user only has to do 2 easy and understandable things: a) change the keyserver configuration: I.e. replace a keyserver by a validating keyserver proxy b) From time to time process an email asking for email confirmation by clicking the appropriate link IMO, that's easy, that's something people are used to do (when they register to other services), that's rare enough to get accepted.. And it works with each existing email client (where I can configure the keyserver). So, how does the PoW approach works in practice? How does this validate an email? What has the user to do? Does it work for each existing email client? IMO anything more complicated makes acceptance more problematic. E.g. using two servers (asking for validation at another server than the keyserver) is IMO for most people simply a show stopper. Even replying with a signed email IMO instead of clicking a link sounds more complicated to me. IMO, we should avoid any step that makes the scenario more complex than necessary (without a significant win). But as written, I didn't understand the PoW scenario yet. may be the effective interaction (based on the UIs of existing email clients) is not worse. Sorry that I am not an expert in this area. Nico -- Nicolai M. Josuttis www.josuttis.de mailto:nico at enigmail.net PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5 From dkg at fifthhorseman.net Wed Jul 29 18:34:52 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 29 Jul 2015 12:34:52 -0400 Subject: Is there a way to comment a key locally? In-Reply-To: <867147768.20150729120550@my_localhost> References: <55B8403B.8050207@gmail.com> <867147768.20150729120550@my_localhost> Message-ID: <871tfqhqhf.fsf@alice.fifthhorseman.net> On Wed 2015-07-29 07:05:50 -0400, MFPA wrote: > On Wednesday 29 July 2015 at 3:53:47 AM, in , fmv1992 at gmail.com wrote: > >> Is there a way to comment a key locally? > > I think the closest currently available is a non-exportable signature > with brief comment in a signature notation. That's exactly what i do with a small (fairly clumsy) script "lcert": -------- #!/bin/bash read -e -p 'lsig reason: ' reason gpg2 --lsign --cert-notation "lsigreason at notations.openpgp.fifthhorseman.net=${reason}" "$1" -------- the main issue is when the cert i'm making such a notation on has multiple user IDs and then gpg falls back to prompting whether i want to sign all uids or not -- if i say "no", then i have to select the relevant uids, and then type "lsign" and "save" in the gpg subshell. note that this has the side effect of marking every lsigned key+user id as valid (since i'm certifying it with my own key). If that's not what you want, you can also just keep a separate text file (or addressbook or whatever data storage you're most comfortable with) with your own notes about the person/key in question. --dkg From 2014-667rhzu3dc-lists-groups at riseup.net Thu Jul 30 01:06:26 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Thu, 30 Jul 2015 00:06:26 +0100 Subject: Is there a way to comment a key locally? In-Reply-To: <871tfqhqhf.fsf@alice.fifthhorseman.net> References: <55B8403B.8050207@gmail.com> <867147768.20150729120550@my_localhost> <871tfqhqhf.fsf@alice.fifthhorseman.net> Message-ID: <15731105.20150730000626@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Wednesday 29 July 2015 at 5:34:52 PM, in , Daniel Kahn Gillmor wrote: > note that this has the side effect of marking every > lsigned key+user id as valid (since i'm certifying it > with my own key). Would it work to keep a special key with downgraded ownertrust for making these local signatures, so that they didn't validate the keys? - -- Best regards MFPA During an eruption - move away from the volcano - not towards it -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJVuV1IXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwffMH/i7BmUyQ8RPi2TCwtOJ7OBht tSTjCGBbioT5I9akZO34s7p38f9wb8QgoJe58RlNEpSaAJ6kz/bClM9KeiqA6IVT oqs80wn60UjL9ZP3D60fhn/oMJQ+ZUIaDHLGkZhsgYRak+nlEGlUBBMx+XHsxI76 b/NG2IvkJmphz34m++Z8IYY8PEhyjgSRcWKxou+qJmFrZ6PYWH9tOWH+d/xM4kyi rc3IZYIVakPrM5mOCZrkjeIksbbgxAgCy6KUbNuY6ivfHAyvWUdTq/IzJJgNiaOD Xr4++N9xnZRY0GQcMSe6GWarI28CPfMkqJzx+C8Fo5cOtSF+FV4VCC10jw19mXyI vgQBFgoAZgUCVbldTl8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45L78AQCOY47wuYJoOtoXh1bfiLJxSii8 Pxo7YFLRyF4eToZWDwD/VMVW4yq96v2QGtzlc3TguWEE+5+ujENFYGPnHIINuA4= =mR/3 -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Thu Jul 30 03:02:17 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 29 Jul 2015 21:02:17 -0400 Subject: Is there a way to comment a key locally? In-Reply-To: <15731105.20150730000626@my_localhost> References: <55B8403B.8050207@gmail.com> <867147768.20150729120550@my_localhost> <871tfqhqhf.fsf@alice.fifthhorseman.net> <15731105.20150730000626@my_localhost> Message-ID: <87h9ome9uu.fsf@alice.fifthhorseman.net> On Wed 2015-07-29 19:06:26 -0400, MFPA wrote: > On Wednesday 29 July 2015 at 5:34:52 PM, in , Daniel Kahn Gillmor wrote: > >> note that this has the side effect of marking every lsigned key+user >> id as valid (since i'm certifying it with my own key). > > Would it work to keep a special key with downgraded ownertrust for > making these local signatures, so that they didn't validate the keys? Sure, that would work. But if you're going to do that, why not just keep the info in your associated addressbook or other handy database/textfile? the GnuPG keyring isn't the most efficient data store for arbitrary data. --dkg From viktordick86 at gmail.com Thu Jul 30 08:04:28 2015 From: viktordick86 at gmail.com (Viktor Dick) Date: Thu, 30 Jul 2015 08:04:28 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <55B8FE28.4060600@enigmail.net> References: <55B5C7B7.4090907@enigmail.net> <87y4i0n3v4.wl-neal@walfield.org> <1305965287.20150728192229@my_localhost> <87vbd3nbnx.wl-neal@walfield.org> <1587154033.20150729010353@my_localhost> <87twsnmakm.wl-neal@walfield.org> <562982140.20150729144107@my_localhost> <55B8FE28.4060600@enigmail.net> Message-ID: <55B9BE6C.1050900@gmail.com> On 2015-07-29 18:24, nico at enigmail.net wrote: > So, could somebody explain in a bit more detail how a PoW approach works? > As far as I understand it, for any key that you have - regardless whether you have access to the mail address in the uid - you can add some signature where anyone with the public key can quickly check that the person that posesses the private key has spent a specific amount of computing power (p.e., 1 week with an average PC) to create this signature. It is hard to create the signature (impossible without the private key, a lot of computing power with it) but easy to check. Essentially, you create the possibility to make a key 'premium' by spending this time and hope that trolls who flood the keyservers with fake keys will be deterred by the costs. Anyone who does not have any problem with trolls can of course still upload a non-premium key. I myself find the idea not so appealling. I would not like it if after creating a key my machine had high CPU load for a couple of weeks. And I doubt that many trolls will be deterred by it - the number of fake keys per time interval will go down, but since they are anyhow going out of their way to create problems for others without any gain for themselves, I think a significant portion will still do it even if it costs more. I rather like the idea of servers that offer to sign your key (or rather a specific UID) and send it to your email, encrypted to you. For the user this just means that if he has the problem of trolls using his address he has to send his key to such a server or upload it in a webinterface, then receive the mail, decrypt it and import the contained signatures to his key, and optionally upload his new key to a keyserver - with enigmail, for example, everything done within a few clicks. Anyone who looks for a key to a specific mail address on a keyserver will probably, when faced with multiple results, take the one that has most signatures (and isn't expired) - especially if some of the signatures are from email-verification-sounding hostnames. Therefore, there is no necessity to create a whitelist of servers (but it can be done, if a user decides to trust signatures of a specific server) and it is still decentralized - anyone can set up such a verification server. Of course with a lot of effort, a troll could still try to create a complete fake network and cross-sign different keys. But here the amount of work to be done for a troll is much bigger than that for a genuine user, so hopefully it will not be a problem. It would also be possible to check for known services if the signature is actually theirs (by checking the key with that on the homepage or something like that), but of course it should have been possible to do that with the original recipient already... These signatures should expire after a year or so, so keys where the owner no longer has acces to the private key will loose these signatures after a while. I myself have two older keys from early experiments (where I did not specify an expiry date) uploaded to the keyserver network, but I guess anyone who looks me up will take my current key, because it has much more subkeys (which I now change every year) and also some signatures. Now that I think about it - if I search for the original author of the c't article (ju at ct.de), who complained about getting mails that were encrypted to some fake key, I would assume that the keys 38EA4970 and E1374764 are both genuine, because they both have not only selfsigs. BTW, they are both signed by different keys with the UID 'pgpCA at ct.heise.de', so they already have a similar service in place - of course I had to do a websearch to find if these keys are genuine, which should probably be easier. I guess ideally the UID would contain a weblink to a page that has the fingerprint and describes the service shortly. Regards, Viktor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From kloecker at kde.org Thu Jul 30 10:17:44 2015 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Thu, 30 Jul 2015 10:17:44 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <55B9BE6C.1050900@gmail.com> References: <55B5C7B7.4090907@enigmail.net> <55B8FE28.4060600@enigmail.net> <55B9BE6C.1050900@gmail.com> Message-ID: <2314525.4tys9XtptD@collossus.ingo-kloecker.de> On Thursday 30 July 2015 08:04:28 Viktor Dick wrote: > Now that I think about it - if I search for the original author of the > c't article (ju at ct.de), who complained about getting mails that were > encrypted to some fake key, I would assume that the keys 38EA4970 and > E1374764 are both genuine, because they both have not only selfsigs. > BTW, they are both signed by different keys with the UID > 'pgpCA at ct.heise.de', so they already have a similar service in place - > of course I had to do a websearch to find if these keys are genuine, > which should probably be easier. I guess ideally the UID would contain a > weblink to a page that has the fingerprint and describes the service > shortly. I'm sorry to tell you that you have fallen into the trap. There is only one genuine pgpCA at ct.heise.de key the fingerprint of which is printed in each issue of the c't magazine. The other one is a fake. And the fact that the fake key with the author's email address is signed by different keys only means that a lot of people have signed this fake key without following the proper procedure of key validation (or that the trolls created even more fake keys to sign the author's fake key to make it look more credible). Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From viktordick86 at gmail.com Thu Jul 30 10:27:37 2015 From: viktordick86 at gmail.com (Viktor Dick) Date: Thu, 30 Jul 2015 10:27:37 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <2314525.4tys9XtptD@collossus.ingo-kloecker.de> References: <55B5C7B7.4090907@enigmail.net> <55B8FE28.4060600@enigmail.net> <55B9BE6C.1050900@gmail.com> <2314525.4tys9XtptD@collossus.ingo-kloecker.de> Message-ID: <55B9DFF9.6080507@gmail.com> On 2015-07-30 10:17, Ingo Kl?cker wrote: > I'm sorry to tell you that you have fallen into the trap. There is only one > genuine pgpCA at ct.heise.de key the fingerprint of which is printed in each > issue of the c't magazine. The other one is a fake. And the fact that the fake > key with the author's email address is signed by different keys only means > that a lot of people have signed this fake key without following the proper > procedure of key validation (or that the trolls created even more fake keys to > sign the author's fake key to make it look more credible). > Not according to http://www.heise.de/security/dienste/PGP-Schluessel-der-c-t-CA-473386.html where three different keys are listed (two DSS and one RSA). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From 2014-667rhzu3dc-lists-groups at riseup.net Thu Jul 30 12:23:20 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Thu, 30 Jul 2015 11:23:20 +0100 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <55B9DFF9.6080507@gmail.com> References: <55B5C7B7.4090907@enigmail.net> <55B8FE28.4060600@enigmail.net> <55B9BE6C.1050900@gmail.com> <2314525.4tys9XtptD@collossus.ingo-kloecker.de> <55B9DFF9.6080507@gmail.com> Message-ID: <501361285.20150730112320@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Thursday 30 July 2015 at 9:27:37 AM, in , Viktor Dick wrote: > On 2015-07-30 10:17, Ingo Kl?cker wrote: >> I'm sorry to tell you that you have fallen into the trap. There is only one >> genuine pgpCA at ct.heise.de key the fingerprint of which is printed in each >> issue of the c't magazine. The other one is a fake. And the fact that the fake >> key with the author's email address is signed by different keys only means >> that a lot of people have signed this fake key without following the proper >> procedure of key validation (or that the trolls created even more fake keys to >> sign the author's fake key to make it look more credible). > Not according to > http://www.heise.de/security/dienste/PGP-Schluessel-der-c-t-CA-473386.html > where three different keys are listed (two DSS and one > RSA). I concur that the keys 38EA4970 and E1374764 both look likely to be genuine. One has signatures from B3B2A12C, the other from DAFFB000. The link above lists as "ct magazine CERTIFICATE " keys B3B2A12C and DAFFB000, as well as a third key BB1D9F6D. As for the other non-revoked keys I found by searching for "schmidt juergen heise de":- all four are signed by a "ct magazine CERTIFICATE " key F6ADD6C2 that is not listed on the magazine's page. all four are also signed by a "ct magazine CERTIFICATE " key FB4DFDC6. one of the four has a UID claiming itself to be another "ct magazine CERTIFICATE " as well as being Juergen Schmidt's key. Also all four have the same creation date. I guess anybody being fooled didn't look at the page linked above, or they would have used key 2C26A309 "ct magazine pgpCA CommunicationKey 2015 " when contacting the magazine. (-; - -- Best regards MFPA This message represents the official view of the voices in my head. -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJVufsoXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwC2oIALQTnp8zRuDfNM/crs07szAG lrmNBhB63fSnr2CfHbpSUHXjoVIgn6sKRGz7oUEyhvmTUDPc4QS+aa7khV5jE094 kQn4nh7oWSNDfTEMSZJjA1DQlrN9QMO0A1Pq77Y1LoRCnaMSBtMgifOqp1vX6nfE ejhqpwMiLF4Db7fdn4gTBK1o3FGXKP55kC5i2QMnwF9KiXz0gtkgdQ+7pgM4MdRT ow9pynZHoEy9sfIKRkF5g5uk1ch5O2mFFvFeCfTph1d6MK06phQaT9v0VQgOz8ms 0BtsUApmUShYO+BPKVlKVFDsfnMPGrcsOqjxcCz+Ikv2GOOdgdnEl1Rbs2+N0ICI vgQBFgoAZgUCVbn7Ll8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45MHfAQDVto8gZk48618e2MxXA8ZITDH4 bTaPakeawetZLjew+QD/QZSjuDd/l7s76NXGhrj14fXb9Z9B+/ibDuPelWfSnws= =cN7q -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Thu Jul 30 12:38:34 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Thu, 30 Jul 2015 11:38:34 +0100 Subject: Is there a way to comment a key locally? In-Reply-To: <87h9ome9uu.fsf@alice.fifthhorseman.net> References: <55B8403B.8050207@gmail.com> <867147768.20150729120550@my_localhost> <871tfqhqhf.fsf@alice.fifthhorseman.net> <15731105.20150730000626@my_localhost> <87h9ome9uu.fsf@alice.fifthhorseman.net> Message-ID: <247308962.20150730113834@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Thursday 30 July 2015 at 2:02:17 AM, in , Daniel Kahn Gillmor wrote: > Sure, that would work. But if you're going to do that, > why not just keep the info in your associated > addressbook or other handy database/textfile? the > GnuPG keyring isn't the most efficient data store for > arbitrary data. Fair enough. But keeping it in the keyring is neat, and I'm sure I read somewhere that the .kbx format is more flexible than the old keyring format and stores meta-information about the keys. Local comments seem to me to be a reasonable type of metadata to want to store. They could usefully double as a locally-assigned "UID" or handle for the key, saying "red haired funny tall guy from XYZ meeting" or including an email address that is not in the key's actual UIDs. - -- Best regards MFPA Virtual workspace, Virtual Office, Virtual Job -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJVuf60XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwHe8H/1ftfbGoJv1YIemfgkgOwEQa tXgMRfllYEy3O/WLo4zuVJ3MDKrl6synmfZ+ti6g4F11og71B63FKQLkSp1cdg5U 9FB0w0E7QiPua2TexeW1YusGlODQu9UzFZFEJm9YPSKCA9AAQwVWmd5lDAv9H/UG wNbNRHwBb0TShX1lbjJe6gcrEnLijVPj0O14sQ1TQ//BcZSfnySxe1vJV4AibY7m rNbPHKbJgeCF2J5Ac0pRAdjm3Oq9JYgRNOnEWmqhRdSVVzcDNk+W8G7D8Ch2Q7zb L1BmtbXIo3oFqsqychm40n9n8Na4f8LkyRhefw7i6VCYy6f4Yx+dd4Qnib44AAyI vgQBFgoAZgUCVbn+wF8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45O1+AP9kuwuMwevNsKNmP/7ENiko5jrH 18OfJc41pSwahJ8zrgD9GBuB5KsTL36Sdr9VZjkvU/Og/k7ZHRf2rLJTzFiWeQs= =Vow0 -----END PGP SIGNATURE----- From wk at gnupg.org Thu Jul 30 12:43:07 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 30 Jul 2015 12:43:07 +0200 Subject: Is there a way to comment a key locally? In-Reply-To: <871tfqhqhf.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 29 Jul 2015 12:34:52 -0400") References: <55B8403B.8050207@gmail.com> <867147768.20150729120550@my_localhost> <871tfqhqhf.fsf@alice.fifthhorseman.net> Message-ID: <874mkm0vus.fsf@vigenere.g10code.de> On Wed, 29 Jul 2015 18:34, dkg at fifthhorseman.net said: > note that this has the side effect of marking every lsigned key+user id > as valid (since i'm certifying it with my own key). It would be possible to add a notation in the unhashed area so that it can be added to the self-signature(s). We would of course not export such a notation. Another option is to add a comment to the metadata which we store in a keybox. An even better way will be to allow for a comment in the TOFU database we will eventually implement. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Jul 30 13:04:29 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 30 Jul 2015 13:04:29 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <55B8F5F6.9080106@enigmail.net> (Patrick Brunschwig's message of "Wed, 29 Jul 2015 17:49:10 +0200") References: <55B5C7B7.4090907@enigmail.net> <87y4i0n3v4.wl-neal@walfield.org> <1305965287.20150728192229@my_localhost> <87vbd3nbnx.wl-neal@walfield.org> <1587154033.20150729010353@my_localhost> <87twsnmakm.wl-neal__28203.1449526132$1438171737$gmane$org@walfield.org> <55B8F5F6.9080106@enigmail.net> Message-ID: <87zj2dzz2a.fsf@vigenere.g10code.de> On Wed, 29 Jul 2015 17:49, patrick at enigmail.net said: > The whole point of this exercise is to verify that the key and the email > address(es) belong _together_. I don't see how PoW could do this, or I > didn't understand it well enough. The idea with a regular PoW is that an attacker (well, script kiddie) would look for a lower hanfing fruit than to create a faked key. The PoW is expensive and thus the expectaion is that it would at best only done for the first interval but not a second time My points against PoW are: - PoW is not green computing so it should only be done in rare cases. - Users with low end devices are discriminated. - With all that surplus Bitcoin mining rig we would soon see a lot of faked keys just for the fun of it - or as a service. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From 2014-667rhzu3dc-lists-groups at riseup.net Thu Jul 30 14:21:21 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Thu, 30 Jul 2015 13:21:21 +0100 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <55B9BE6C.1050900@gmail.com> References: <55B5C7B7.4090907@enigmail.net> <87y4i0n3v4.wl-neal@walfield.org> <1305965287.20150728192229@my_localhost> <87vbd3nbnx.wl-neal@walfield.org> <1587154033.20150729010353@my_localhost> <87twsnmakm.wl-neal@walfield.org> <562982140.20150729144107@my_localhost> <55B8FE28.4060600@enigmail.net> <55B9BE6C.1050900@gmail.com> Message-ID: <773524780.20150730132121@my_localhost> Hi On Thursday 30 July 2015 at 7:04:28 AM, in , Viktor Dick wrote: > On 2015-07-29 18:24, nico at enigmail.net wrote: >> So, could somebody explain in a bit more detail how a PoW approach works? > As far as I understand it, for any key that you have - > regardless whether you have access to the mail address > in the uid - you can add some signature where anyone > with the public key can quickly check that the person > that posesses the private key has spent a specific > amount of computing power (p.e., 1 week with an average > PC) to create this signature. It is hard to create the > signature (impossible without the private key, a lot of > computing power with it) but easy to check. That's my understanding, too. > Essentially, you create the possibility to make a key > 'premium' by spending this time and hope that trolls > who flood the keyservers with fake keys will be > deterred by the costs. You can hope so, but is it reasonable to expect? > Anyone who does not have any > problem with trolls can of course still upload a > non-premium key. And anybody who doesn't trust Proof of Work as a validation could trust only encrypted-mail validations. It would be simple, as PoW validation signatures would be self-certs whereas enc-mail validation certs would come from a validation server's key. > I myself find the idea not so appealling. I would not > like it if after creating a key my machine had high CPU > load for a couple of weeks. And I doubt that many > trolls will be deterred by it - the number of fake keys > per time interval will go down, but since they are > anyhow going out of their way to create problems for > others without any gain for themselves, I think a > significant portion will still do it even if it costs > more. I think a week of computing for the PoW is excessive. But if the troll's CPU time is on a botnet, they won't care about the cost or about slowing down their machine for a week. > I rather like the idea of servers that offer to sign > your key (or rather a specific UID) and send it to your > email, encrypted to you. For the user this just means > that if he has the problem of trolls using his address > he has to send his key to such a server or upload it in > a webinterface, then receive the mail, decrypt it and > import the contained signatures to his key, and > optionally upload his new key to a keyserver - with > enigmail, for example, everything done within a few > clicks. I prefer this method rather than clicking a link in an email. But people are used to that scenario from website registrations, as long as the email arrives within a couple of minutes of them registering on the website. > Anyone who looks for a key to a specific mail > address on a keyserver will probably, when faced with > multiple results, take the one that has most signatures > (and isn't expired) - especially if some of the > signatures are from email-verification-sounding > hostnames. Surely, all signatures from keys that you do not already trust are just ambient noise. > Therefore, there is no necessity to create a > whitelist of servers (but it can be done, if a user > decides to trust signatures of a specific server) and > it is still decentralized - anyone can set up such a > verification server. If it can be done without Big Brother creating a whitelist, it should be. > Of course with a lot of effort, a > troll could still try to create a complete fake network > and cross-sign different keys. But here the amount of > work to be done for a troll is much bigger than that > for a genuine user, so hopefully it will not be a > problem. I imagine it would not be much of a problem for a troll to automate most of the work. But unless they compromise some keys from genuine validators, it's all in vain if people bother to check signatures. Hold on, the magazine writer's problem is that people encrypt his emails to the wrong key because they do not bother to check signatures. -- Best regards MFPA A closed mouth gathers no foot From nico at enigmail.net Thu Jul 30 14:43:35 2015 From: nico at enigmail.net (nico at enigmail.net) Date: Thu, 30 Jul 2015 14:43:35 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <501361285.20150730112320@my_localhost> References: <55B5C7B7.4090907@enigmail.net> <55B8FE28.4060600@enigmail.net> <55B9BE6C.1050900@gmail.com> <2314525.4tys9XtptD@collossus.ingo-kloecker.de> <55B9DFF9.6080507@gmail.com> <501361285.20150730112320@my_localhost> Message-ID: <55BA1BF7.4090408@enigmail.net> Indeed, as written in the proposal key 8B5A ABB1 A033 21CE C2FF C35F 3BA0 E844 EDEB DFE9 > https://hkps.pool.sks-keyservers.net/pks/lookup?op=vindex&search=0x3BA0E844EDEBDFE9 is a faked key which is signed by a faked CA. THAT's exactly the problem I want to fix! And note that for ordinary users it is not that easy to find out Yes, people could in this case double check with the web site of the magazine. But they simply don't do that (including me and a couple of other people here in this forum!). As a result J?rgen aganin and again gets emails with the wrong key. And I dind't get an answer from J?rgen ... And ... I want to avoid this unnessecary burdon. BTW, as another example, several keys of team at gpgtools.org are faked (search for these keys and the the interesting result). Am 30.07.2015 um 12:23 schrieb MFPA: > Hi > > > On Thursday 30 July 2015 at 9:27:37 AM, in > , Viktor Dick wrote: > > >> On 2015-07-30 10:17, Ingo Kl?cker wrote: >>> I'm sorry to tell you that you have fallen into the trap. There is only one >>> genuine pgpCA at ct.heise.de key the fingerprint of which is printed in each >>> issue of the c't magazine. The other one is a fake. And the fact that the fake >>> key with the author's email address is signed by different keys only means >>> that a lot of people have signed this fake key without following the proper >>> procedure of key validation (or that the trolls created even more fake keys to >>> sign the author's fake key to make it look more credible). > >> Not according to >> http://www.heise.de/security/dienste/PGP-Schluessel-der-c-t-CA-473386.html >> where three different keys are listed (two DSS and one >> RSA). > > > I concur that the keys 38EA4970 and E1374764 both look likely to be > genuine. One has signatures from B3B2A12C, the other from DAFFB000. > The link above lists as "ct magazine CERTIFICATE " > keys B3B2A12C and DAFFB000, as well as a third key BB1D9F6D. > > > As for the other non-revoked keys I found by searching for "schmidt > juergen heise de":- > > all four are signed by a "ct magazine CERTIFICATE > " key F6ADD6C2 that is not listed on the > magazine's page. > > all four are also signed by a "ct magazine CERTIFICATE magazine CERTIFICATE>" key FB4DFDC6. > > one of the four has a UID claiming itself to be another "ct > magazine CERTIFICATE " as well as being > Juergen Schmidt's key. > > Also all four have the same creation date. > > I guess anybody being fooled didn't look at the page linked above, or > they would have used key 2C26A309 "ct magazine pgpCA CommunicationKey > 2015 " when contacting the magazine. (-; > > > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- Nicolai M. Josuttis www.josuttis.de mailto:nico at enigmail.net PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5 From josef at netpage.dk Thu Jul 30 14:45:29 2015 From: josef at netpage.dk (Josef Schneider) Date: Thu, 30 Jul 2015 14:45:29 +0200 Subject: One Key, multiple Smartcards not working anymore In-Reply-To: <55B85072.3020301@fsij.org> References: <55B681DF.5040107@netpage.dk> <55B85072.3020301@fsij.org> Message-ID: <55BA1C69.7080106@netpage.dk> Hello, Thank you for the fast reply and the solution. I can confirm, that this works. Also I switched to GPG 2.1 on my notebook (also Windows) and the bug doesn't exist in that version. Best regards, Josef On 29.07.2015, 06:02 NIIBE Yutaka wrote: > Hello, > > I forgot to address some way to recover. > > On 07/28/2015 04:09 AM, Josef Schneider wrote: >> I insert the other card and do a card-status: > [...] >> General key info..: pub 2048R/988E7DDD 2015-07-07 Josef Schneider >> >> sec> 4096R/9BE45ED0 erzeugt: 2012-12-10 verf?llt: 2017-04-13 >> Kartennummer:0005 XXXXXXXX >> ssb> 4096R/B641DD11 erzeugt: 2012-12-10 verf?llt: niemals >> Kartennummer:0005 XXXXXXXX >> ssb> 4096R/CA02F8EA erzeugt: 2012-12-10 verf?llt: niemals >> Kartennummer:0005 XXXXXXXX >> ssb# 2048R/988E7DDD erzeugt: 2015-07-07 verf?llt: 2017-07-06 >> ssb# 2048R/03E021FE erzeugt: 2015-07-07 verf?llt: 2017-07-06 >> ssb# 2048R/8B406748 erzeugt: 2015-07-07 verf?llt: 2017-10-24 > In this situation, you have a stub for RSA 4096-bit keys. > > 4096R/9BE45ED0 -> Kartennummer:0005 XXXXXXXX > 4096R/B641DD11 -> Kartennummer:0005 XXXXXXXX > 4096R/CA02F8EA -> Kartennummer:0005 XXXXXXXX > > With GnuPG 2.0, you can export stub (it's not possible for GnuPG 2.1). > > $ gpg -a -o 9BE45ED0-stub.asc --export-secret-keys 9BE45ED0 > $ gpg -a -o B641DD11-stub.asc --export-secret-subkeys B641DD11 > $ gpg -a -o CA02F8EA-stub.asc --export-secret-subkeys CA02F8EA > > Then, > >> General key info..: pub 2048R/988E7DDD 2015-07-07 Josef Schneider >> >> sec# 4096R/9BE45ED0 erzeugt: 2012-12-10 verf?llt: 2017-04-13 >> ssb# 4096R/B641DD11 erzeugt: 2012-12-10 verf?llt: niemals >> ssb# 4096R/CA02F8EA erzeugt: 2012-12-10 verf?llt: niemals >> ssb> 2048R/988E7DDD erzeugt: 2015-07-07 verf?llt: 2017-07-06 >> Kartennummer:0006 XXXXXXXX >> ssb> 2048R/03E021FE erzeugt: 2015-07-07 verf?llt: 2017-07-06 >> Kartennummer:0006 XXXXXXXX >> ssb> 2048R/8B406748 erzeugt: 2015-07-07 verf?llt: 2017-10-24 >> Kartennummer:0006 XXXXXXXX > When you have this configuration ('#' means no secret key), > import *-stub.asc by gpg --import. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 603 bytes Desc: OpenPGP digital signature URL: From 2014-667rhzu3dc-lists-groups at riseup.net Thu Jul 30 16:39:38 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Thu, 30 Jul 2015 15:39:38 +0100 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <55BA1BF7.4090408@enigmail.net> References: <55B5C7B7.4090907@enigmail.net> <55B8FE28.4060600@enigmail.net> <55B9BE6C.1050900@gmail.com> <2314525.4tys9XtptD@collossus.ingo-kloecker.de> <55B9DFF9.6080507@gmail.com> <501361285.20150730112320@my_localhost> <55BA1BF7.4090408@enigmail.net> Message-ID: <16510404070.20150730153938@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thursday 30 July 2015 at 1:43:35 PM, in , nico at enigmail.net wrote: > BTW, as another example, several keys of > team at gpgtools.org are faked (search for these keys and > the the interesting result). Sorry, I don't see a result that leaps out at me as interesting. Are you willing to elaborate? - -- Best regards MFPA Teamwork is essential - it allows you to blame someone else -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJVujcxXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwooMH/0C6TwqvvV4x7JoCk2ovnO7i SlGcm9LdRESIRbk0WNqfaBkINP/pimVRhmLAgvmt8aBmBD5mk19QZqyUwHR5JJP4 z4Q3OkfXFcXr6KWqgHgAkXxghFtnp8MJj/5TLQ4ICO5bPee4yN6L2NElPIrN1M6a PA17OZdCpTVuQXOU84b4XyvFkADNM5xJLX22lNYkm/NX2YMbJ89IlntfjBksCP8I xh9xUjQaNsOnXHv16iNLskrWmdGeCG3gvGq0QX53bLc/ExHMhy7p7GOHt0TT+Guh qpCbQdlyil7FGsUTl/5hawkFA4Xy5SOaieIQFkURV2V/H07DiUb4U1LI36XaT2+I vgQBFgoAZgUCVbo3Nl8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45ISoAQDffuI/eHQ4N6RnAfAI0WR9m/YO xLD1KPSvkv30D+ZflgEAzVSctYlMpt2xk6HozQGCeaKEG+H0JEgNswYH5yx0xAU= =O+Gs -----END PGP SIGNATURE----- From viktordick86 at gmail.com Thu Jul 30 17:12:35 2015 From: viktordick86 at gmail.com (Viktor Dick) Date: Thu, 30 Jul 2015 17:12:35 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <16510404070.20150730153938@my_localhost> References: <55B5C7B7.4090907@enigmail.net> <55B8FE28.4060600@enigmail.net> <55B9BE6C.1050900@gmail.com> <2314525.4tys9XtptD@collossus.ingo-kloecker.de> <55B9DFF9.6080507@gmail.com> <501361285.20150730112320@my_localhost> <55BA1BF7.4090408@enigmail.net> <16510404070.20150730153938@my_localhost> Message-ID: <55BA3EE3.7000608@gmail.com> On 2015-07-30 16:39, MFPA wrote: > On Thursday 30 July 2015 at 1:43:35 PM, in > , nico at enigmail.net wrote >> BTW, as another example, several keys of >> team at gpgtools.org are faked (search for these keys and >> the the interesting result). > > Sorry, I don't see a result that leaps out at me as interesting. Are > you willing to elaborate? I'd say if one searches on a keyserver, it is pretty clear which key is real. I'm a bit worried because when I search with Enigmail it does not show the signatures, so from there they all seem equally valid. Regards, Viktor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Thu Jul 30 17:32:47 2015 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Thu, 30 Jul 2015 17:32:47 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <55BA3EE3.7000608@gmail.com> References: <55B5C7B7.4090907@enigmail.net> <55B8FE28.4060600@enigmail.net> <55B9BE6C.1050900@gmail.com> <2314525.4tys9XtptD@collossus.ingo-kloecker.de> <55B9DFF9.6080507@gmail.com> <501361285.20150730112320@my_localhost> <55BA1BF7.4090408@enigmail.net> <16510404070.20150730153938@my_localhost> <55BA3EE3.7000608@gmail.com> Message-ID: <55BA439F.4030208@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 07/30/2015 05:12 PM, Viktor Dick wrote: > On 2015-07-30 16:39, MFPA wrote: >> On Thursday 30 July 2015 at 1:43:35 PM, in >> , nico at enigmail.net wrote >>> BTW, as another example, several keys of team at gpgtools.org are >>> faked (search for these keys and the the interesting result). >> >> Sorry, I don't see a result that leaps out at me as interesting. >> Are you willing to elaborate? > > I'd say if one searches on a keyserver, it is pretty clear which > key is real. I'm a bit worried because when I search with Enigmail > it does not show the signatures, so from there they all seem > equally valid. Instinctively this sounds flawed, the point is there is no way without downloading the key and verifying the validation path through other existing known good keys. If you rely solely on the number of signatures that can easily be constructed, either through generating new keys or due to the keyservers not doing any cryptographic verification that the signatures themselves are correct. ... and that is intended behavior ... - -- - ---------------------------- Kristian Fiskerstrand Blog: http://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 - ---------------------------- Nil satis nisi optimum Nothing but the best is good enough -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJVukObAAoJECULev7WN52FowoH/RPkEUy5LiIXqqKZaNPvLno1 7KB4vTCSVQwj/RHfCUYCCF5mqZ5mkLA6czdKOCslaZP6YqjrgPhzDxJ65mzZ2enG Xv8neTWgnjVbotkQ0tauNqlw7mcTSLG8FwxXpuyrAilAKmOEeV1/JN2pHZBp/0u2 2LPfcc2QNMaXwKK5Ri5vpOTieFlmeLEj/lt+HCF3AikilIKv8L7grG+jADTda5kw VlQ3Sn+NbUUMrRMUjMwtwgN58jtM8uGtflsveouFsQEs9eH5bPbw/nj1ZVtAyjeS hcs2KyMqHj5JAhKpySkhgvqID7gr3LxOSB1xCkgvAz3LHhQu39OD6iOGFT4fLBc= =yklt -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Fri Jul 31 01:11:35 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Fri, 31 Jul 2015 00:11:35 +0100 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <55BA3EE3.7000608@gmail.com> References: <55B5C7B7.4090907@enigmail.net> <55B8FE28.4060600@enigmail.net> <55B9BE6C.1050900@gmail.com> <2314525.4tys9XtptD@collossus.ingo-kloecker.de> <55B9DFF9.6080507@gmail.com> <501361285.20150730112320@my_localhost> <55BA1BF7.4090408@enigmail.net> <16510404070.20150730153938@my_localhost> <55BA3EE3.7000608@gmail.com> Message-ID: <957598505.20150731001135@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thursday 30 July 2015 at 4:12:35 PM, in , Viktor Dick wrote: > On 2015-07-30 16:39, MFPA wrote: >> On Thursday 30 July 2015 at 1:43:35 PM, in >> , nico at enigmail.net wrote >>> BTW, as another example, several keys of >>> team at gpgtools.org are faked (search for these keys and >>> the the interesting result). >> Sorry, I don't see a result that leaps out at me as >> interesting. Are you willing to elaborate? > I'd say if one searches on a keyserver, it is pretty > clear which key is real. Only if you download the key from the GPGTools website and find the key-id first. (If the GPGTools team shows their key ID or Fingerprint on their website, I failed to find it.) My output from searching a keyserver for "gpgtools.org":- - ----------------------------------------------------------------------- C:\TDM-GCC-32>gpg --search-keys team at gpgtools.org gpg: using character set 'utf-8' gpg: data source: http://kronecker.scientia.net:11371 (1) GPGTools Team 2048 bit RSA key 0xDE13CCD892EFC169, created: 2013-09-13, exp ires: 2017-09-13 (2) GPGTools Team 2048 bit RSA key 0x93F6E721F7D75F75, created: 2013-09-13, exp ires: 2017-09-13 (3) GPGTools Team 2048 bit RSA key 0x07F7603CC8F5BBF1, created: 2013-09-13, exp ires: 2017-09-13 (4) *Key invalid; use 76D78F0500D026C4 GPG Tools Team 2048 bit RSA key 0x929D128A9EA002BA, created: 2013-09-13, exp ires: 2017-09-13 (5) George Nigg 2048 bit RSA key 0xD0863D5E46FA0F9F, created: 2013-07-12, exp ires: 2017-07-12 (6) GPGTools Team GPGMail Project Team (Official OpenPGP Key) - ----------------------------------------------------------------------- Number 6 has more UIDs but nothing in the search listing tells me any key is clearly the one I want. When verifying a software download, the search would be the other way around. I would be checking a signature, so GnuPG would search the server for the key-id that made the signature, the signature would be good or bad, and the key would be the one their website says it should be or it wouldn't. (OK, there would quite probably be certifications vouching for the key as well, in case the site was hacked and now said a different key.) > I'm a bit worried because when > I search with Enigmail it does not show the signatures, > so from there they all seem equally valid. I do not use Enigmail, so couldn't comment. However, what would be different if one of the keys found happened to carry one of your proposed? - -- Best regards MFPA What's another word for synonym? -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJVuq8rXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwL1cH/3MxcfTEKp+Dlnj3pf//5dr4 sywvMnkv/7k7X0wEPApQVmlVH+6y0kFgOBK366oAKh32mq2muftcRIhOe/eH5pCJ PQvpjhmuqu7TvmIT9YlnnEcuWPMhK8iT8q1WqAwNJdFxv2WhzN6V+g/QcilDE4cD TQ6VyIvNp9Z6Nrrb9bl7DF8eh4jxiRtvyoT+JfL9l3qt3umqcuy/eTyt5YLOg03T V3jSherLB4eSyRFwxbOvccd9o9yZK8rVezD6Oul+dOUQbgBeuPrLfRG2E1sjLE2S fKj9NsZTmMOc3D2uSfwGNWb9vQtKnnvMosGX6PGvp9ESgvj5REXEJ4vCcwZUFxKI vgQBFgoAZgUCVbqvPF8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45HRoAQCWIaBpOmDy7AruEsbWaJZUrt3I tCsfiO9kXYa5lBh4CgEA+xSPOnYEEaWXIqlouKAbKEt1JqqJ+k5ut5j68DbkBAo= =qAVG -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Fri Jul 31 01:26:49 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Fri, 31 Jul 2015 00:26:49 +0100 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <957598505.20150731001135@my_localhost> References: <55B5C7B7.4090907@enigmail.net> <55B8FE28.4060600@enigmail.net> <55B9BE6C.1050900@gmail.com> <2314525.4tys9XtptD@collossus.ingo-kloecker.de> <55B9DFF9.6080507@gmail.com> <501361285.20150730112320@my_localhost> <55BA1BF7.4090408@enigmail.net> <16510404070.20150730153938@my_localhost> <55BA3EE3.7000608@gmail.com> <957598505.20150731001135@my_localhost> Message-ID: <11340095.20150731002649@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Friday 31 July 2015 at 12:11:35 AM, in , MFPA wrote: > However, what would be different if one of the keys > found happened to carry one of your proposed? Sorry, that should have been:- What would be different if one of the keys found in the search happened to carry one of the proposed email address validation signatures? - -- Best regards MFPA No matter what a man's past may have been, his future is spotless. -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJVurK6XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwbCcH/1sWY/2Gah5tOrppI71SYMZ4 pTXghWR5ahYDZuKyMJHpSJ6Vy+QKEYrdEqGhCXgHa4npBmkal3OlUlwSaktO9WJO ubJzP5QP3vwvd2c8hbHA49/oKbTRoNcPQRNfTkteQU1gLvwiklTYbeu6uhaNy7oc okvTHQvJ47Vzb9t+Vt2Wj3vOA5qnwJtDIw9PnBqxKRYqNyJ+BzhTvsVxlgyifp8Q Y/2M8Jko8L0TN+BbCNTYi9MRXDmc3nCfWyn/0T9g4RQCciyNVc5eDuDi1KM/kzm6 oK9wpfxwtwuZ7B8dhrZS4AWSRZ/6Vv2lFpUU45FfvKNQU3e9VtG0bIykp4pUH02I vgQBFgoAZgUCVbqyy18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45H74AP9YIHPPdKMxRWMDSg8WWFSwCsv1 ThEwttSwRmcVZ4mFJQD+M9OBBkk31ksmUMxZRyk0GZsga5p8E9nguH+hJ9hDqA8= =U6Vd -----END PGP SIGNATURE----- From viktordick86 at gmail.com Fri Jul 31 07:43:29 2015 From: viktordick86 at gmail.com (Viktor Dick) Date: Fri, 31 Jul 2015 07:43:29 +0200 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <957598505.20150731001135@my_localhost> References: <55B5C7B7.4090907@enigmail.net> <55B8FE28.4060600@enigmail.net> <55B9BE6C.1050900@gmail.com> <2314525.4tys9XtptD@collossus.ingo-kloecker.de> <55B9DFF9.6080507@gmail.com> <501361285.20150730112320@my_localhost> <55BA1BF7.4090408@enigmail.net> <16510404070.20150730153938@my_localhost> <55BA3EE3.7000608@gmail.com> <957598505.20150731001135@my_localhost> Message-ID: <55BB0B01.4020907@gmail.com> On 31.07.2015 01:11, MFPA wrote: > Only if you download the key from the GPGTools website and find the > key-id first. (If the GPGTools team shows their key ID or Fingerprint on their website, I failed to find it.) On the front page they have 'to verify the signature, please download and import our ' right below the download button. There is no fingerprint, but the whole key is there. But I was talking about the fact that of the six results, one has hundreds of signatures. Sure, in the web of trust concept this doesn't mean anything unless there is a (short) trust chain from me to one of these, but in practice this still significantly rises the chance that it is the correct key (and it is, I checked with the one on their homepage). > My output from searching a keyserver for "gpgtools.org":- 'gpg --search-keys' does not seem to give a list of signatures (which explains why enigmail also doesn't), I was searching using a web interface. I guess this is because it is assumed that signatures do not mean anything without a trust chain. But if I had to bet money on one of the keys, I would still take the one with hundreds of signatures. > However, what would be different if one of the keys found happened to > carry one of your proposed email address validation signatures? If I could quickly check (or rather, my client could do that automatically) that the signature is also found on their web page, I can assume that either the web page is fake (which is unlikely for something known like ccc.de), it has been hacked (unlikely for a random troll) or someone intercepted either my HTTP request or the original verification e-mail (possible with a secret service, unlikely with a troll). Therefore, it will raise my estimated probability that the owner of the key also has access to the mailbox, which will pretty surely now be much higher than for any fake key. The advantage with respect to the proof of work concept is that the procedure is asymmetric: it costs much more to troll than to verify a genuine key. Best regards, Viktor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From listofactor at mail.ru Fri Jul 31 09:15:23 2015 From: listofactor at mail.ru (listo factor) Date: Fri, 31 Jul 2015 07:15:23 +0000 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <55B5C7B7.4090907@enigmail.net> References: <55B5C7B7.4090907@enigmail.net> Message-ID: <55BB208B.6090807@mail.ru> The problem with most "e-mail reform" proposals (this one included) is that they don't address what is the primary problem of essential users of the encrypted communication: that to their attackers the knowledge of who communicates with whom is of greater value than the content of the message. Without solving that primary problem, the motivation for the adoption of any new scheme is either low or non-existent. Listo Factor From 2014-667rhzu3dc-lists-groups at riseup.net Fri Jul 31 12:31:56 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Fri, 31 Jul 2015 11:31:56 +0100 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <55BB208B.6090807@mail.ru> References: <55B5C7B7.4090907@enigmail.net> <55BB208B.6090807@mail.ru> Message-ID: <1867196814.20150731113156@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Friday 31 July 2015 at 8:15:23 AM, in , listo factor wrote: > The problem with most "e-mail reform" proposals (this > one included) is that they don't address what is the > primary problem of essential users of the encrypted > communication: that to their attackers the knowledge of > who communicates with whom is of greater value than the > content of the message. Taken in the round for general surveillance purposes, yes. But for a relatively small number of messages, it's the content that is more valuable. For example, if Bob emails Alice his credit card details (or commercial secrets). > Without solving that primary > problem, the motivation for the adoption of any new > scheme is either low or non-existent. One scheme that does address the metadata issue is Confidant Mail . - -- Best regards MFPA Editing is a rewording activity -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJVu06gXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwCBEIALXYGEGvGxGs8xYLq1LDekON FNqOeZzhUGzdfxP4Os8isSQ5X3g53Ffz1rG5RnoQpob1bbn8FqogonWp5IMcogdL TRyBuAftzVlUybMweqavaeQZ8QuegUnnKZ0FolqVYMHyDL2q1TMT9djln6nbltfD xq1jGOZFTKolaaxTbyJG3N6B93Jd8ETrWjRqkPIaMvkmtiMFFJ/tTWfxwqm54nPz s2vTYbA8+wSAK20UOzA0lajoETQAhuqTgFezq+kbbqvDf4XfbptauUyTmJptdyp4 sfaSy3qJMa3QVp12ewGhtLRm/rDM/QLdZQf73bNxIJqtXobQxPBT0Y6R6NTfyCGI vgQBFgoAZgUCVbtPFV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45NywAP4qRDGwXwazn3s6rEnVmvpiHyoY dRh2UVMrHCxkmUOIdQEAuOFcDGCa/7jRxwdXdgZKBTOzz2x9JdK9xLcvMFR9tQ4= =vbCb -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Fri Jul 31 13:13:34 2015 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Fri, 31 Jul 2015 12:13:34 +0100 Subject: Proposal of OpenPGP Email Validation In-Reply-To: <55BB0B01.4020907@gmail.com> References: <55B5C7B7.4090907@enigmail.net> <55B8FE28.4060600@enigmail.net> <55B9BE6C.1050900@gmail.com> <2314525.4tys9XtptD@collossus.ingo-kloecker.de> <55B9DFF9.6080507@gmail.com> <501361285.20150730112320@my_localhost> <55BA1BF7.4090408@enigmail.net> <16510404070.20150730153938@my_localhost> <55BA3EE3.7000608@gmail.com> <957598505.20150731001135@my_localhost> <55BB0B01.4020907@gmail.com> Message-ID: <256354833.20150731121334@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Friday 31 July 2015 at 6:43:29 AM, in , Viktor Dick wrote: > On 31.07.2015 01:11, MFPA wrote: >> Only if you download the key from the GPGTools website and find the >> key-id first. (If the GPGTools team shows their key ID or Fingerprint > on their website, I failed to find it.) > On the front page they have 'to verify the signature, please download > and import our ' right below the download button. There is > no fingerprint, but the whole key is there. > But I was talking about the fact that of the six results, one has > hundreds of signatures. OK, you can go to a keyserver's web interface and see there are lots of signatures there. But you cannot see that when searching the keyserver using GnuPG, quite rightly since any signature you have not (yet) been able to check and establish you trust it is just background noise. > Sure, in the web of trust concept this doesn't > mean anything unless there is a (short) trust chain from me to one of > these, but in practice this still significantly rises the chance that it > is the correct key Anybody of that opinion could be easily fooled by creating a few dozen "fake" keys and signing one with the rest. >> My output from searching a keyserver for >> "gpgtools.org":- > 'gpg --search-keys' does not seem to give a list of signatures (which > explains why enigmail also doesn't), I was searching using a web > interface. I guess this is because it is assumed that signatures do not > mean anything without a trust chain. It's a fact, not just an assumption. > But if I had to bet money on one of > the keys, I would still take the one with hundreds of signatures. How much would you pay for somebody to create a few dozen "fake" keys and sign one with the rest? >> However, what would be different if one of the keys >> found happened to carry one of your proposed email >> address validation signatures? > If I could quickly check (or rather, my client could do that > automatically) that the signature is also found on their web page, I can > assume that either the web page is fake (which is unlikely for something > known like ccc.de), it has been hacked (unlikely for a random troll) or > someone intercepted either my HTTP request or the original verification > e-mail (possible with a secret service, unlikely with a troll). > Therefore, it will raise my estimated probability that the owner of the > key also has access to the mailbox, which will pretty surely now be much > higher than for any fake key. I guess your mail client would have to automatically check what is at a URL given in a (self-)certification. Is that not an attack vector in itself? And wouldn't you have to download all the keys offered and check the signatures in order to find the URLs to follow (or, indeed, the email validation certificate notations)? > The advantage with respect to the proof of work concept is that the > procedure is asymmetric: it costs much more to troll than to verify a > genuine key. Could the troll not reduce the cost by using something optimised for the task, like a Bitcoin mining box as Werner mentioned? Or farm the cost out by using a botnet to perform the PoWs? - -- Best regards MFPA Hard work never killed anyone, but why take a risk? -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJVu1hkXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwlwwIAJPFsAlAKmCQKqHTPzjFP0aW qHVl9B7JMUPm3A5l2TXDWz3Ie64+E3P+0IoGXqMc19at4xdz6gJhm6rcEJVUkmvX hD4q81+ie9gw4BRAIqUMlqx6pHFvDun+YpR9hnsRhyugseVJp60zjz0Su0ehb1Mm Yn/Q4vDH/jmydGpRfJKjEE2Hqw98OJcee3PlJGo9gF/R3bdP9ZI8+9nz0XT1Tx0o d7ZT4pII0DJ5DejnHsX4yR71RawaYNGYIuY7leP9P6B8fQg1JPIuh6VvUY/ycDGb gaPxc7Nal5U7UywUTaK8OCGz0Lav7A23RnRKvAjOz2gaMUeE/KzhIYJUZZvSGBaI vgQBFgoAZgUCVbtYaV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45P5cAQCsXJP6dCn171lXW4OV47HNPyhR fOG3KSxF3fTa7/1r8QEA6zn1yhpdDc+fZCWPLvkPOByW/sXY0ukJJr3lGt/maw4= =KiYV -----END PGP SIGNATURE----- From hw42 at ipsumj.de Fri Jul 31 19:10:47 2015 From: hw42 at ipsumj.de (HW42) Date: Fri, 31 Jul 2015 19:10:47 +0200 Subject: unattended key deletion GnuPG 2.1 Message-ID: <55BBAC17.8040605@ipsumj.de> Hi, I try to delete a public and it's secret key via gpgme. The problem is that it always pops a pinentry confirmation dialog. Since I want do the action unattended this is a problem. By looking at the gpg-agent code it seems that there is currently no way to do this. But maybe I missed something. There are two possibly workarounds I have think of 1) use a fake pinentry which always says yes. 2) delete the key in private-keys-v1.d but those are obviously crude hacks. Thank you. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: