From peter at digitalbrains.com Sun May 1 10:55:52 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 1 May 2016 10:55:52 +0200 Subject: making a Debian Live CD for managing GnuPG master key and smartcards In-Reply-To: <57211F9B.5050209@pocock.pro> References: <571F1E62.30203@pocock.pro> <5720C11B.2000909@digitalbrains.com> <57211F9B.5050209@pocock.pro> Message-ID: <5725C498.5050807@digitalbrains.com> On 27/04/16 22:22, Daniel Pocock wrote: > Can anybody point me to an example of using pinentry with either of > those? Or will it just work on the basic black and white console? There are textmode pinentries that "grab" a console and use that to query the user. The default GUI pinentries have a curses fallback. With GnuPG 2.1, for me it's as easy as unsetting DISPLAY to have it prompt with curses for my smartcard PIN. $ DISPLAY= gpg2 -d test.gpg You can explicitly configure a textmode pinentry in $GNUPGHOME/gpg-agent.conf: pinentry-program pinentry-curses or perhaps pinentry-program pinentry-tty for a real bare bones one. These pinentries are in the identically named Debian packages; you do need to explicitly install them (pinentry-curses is already listed on the wiki). I haven't tried them with whiptail and such, but if they corrupt something during the interaction, that might be a bug in the pinentry. I haven't looked at the code to see how they save and restore the old contents. Do they switch to the alternate screen buffer? Then as long as whiptail doesn't do that, I think they should co-exist. pinentry-tty most likely does screw up the screen. You really can't blame it though, it's a bit simple :). > paperkey is already listed in the wiki and printing is mentioned, it > should have been in the workflow too, now it is added there. Ah, I missed it. What about a good OCR-friendly font to print with? And related to that, you could consider scanner support and OCR software, but perhaps it is too much work for too little gain, as the paper backup is for emergencies only (and can also be typed out). Maybe something for a future version. > Some people actually want shorter expiry, every 1 - 3 months, although I > am not advocating that so far. Please realize that this burden is not just on the owner of the key, but also on others. The correspondents of the key owner will need to refresh their copy of the key as often as it expires. In fact, I suspect this might be the reason to advocate for shorter expiry times: it forces your correspondents to check if there is anything new, including newly created subkeys. It limits the amount of time people can encrypt to an old key that was retired, perhaps even compromised. However, this also means they need internet connectivity when they want to encrypt something. If they are working while commuting, on a laptop without an internet connection, they will simply find they cannot encrypt because the key has expired. I think this is a great disadvantage, and the person who chooses short expiry times puts this burden on their correspondents rather than just on themselves. There's another aspect: the size of the key on the keyservers. Keyservers are append-only. Every time a RSA-4096 key expiry is extended, this appends about 600 bytes to the key, and on the order of 300 bytes for a RSA-2048 key. For the key you propose on the wiki, this is 900 bytes for a subkey expiry (three 2048 subkeys) and 600 bytes for every primare key expiry (one 4096 key). > Did this have all the necessary things (GnuPG 2.x, paperkey, smartcard > support) in the image? Good point, I forgot: it most likely did not have paperkey :). The others: yes, I think it contained them back then, and it does now (I checked the list of installed packages, I didn't boot one up to check). HTH, Peter. PS: Could you please trim your quotes when replying? I found it a bit difficult to pick your words from my own endless ramblings while composing this reply... (while composing a reply in Icedove, it's a lot more difficult to see the quote-level, it's all the same color). -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Sun May 1 11:22:53 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 1 May 2016 11:22:53 +0200 Subject: making a Debian Live CD for managing GnuPG master key and smartcards In-Reply-To: <5725C498.5050807@digitalbrains.com> References: <571F1E62.30203@pocock.pro> <5720C11B.2000909@digitalbrains.com> <57211F9B.5050209@pocock.pro> <5725C498.5050807@digitalbrains.com> Message-ID: <5725CAED.6000402@digitalbrains.com> On 01/05/16 10:55, Peter Lebbing wrote: > The correspondents of the key owner will need to refresh their copy of > the key as often as it expires. I expect some people would be worried about the amount of metadata this leaks with short expiry times. If you are in the position to sample refreshes, it gives a nice view of how many people regularly use the key, based on the number of refreshes of the key. When people don't use things like Tor to hide their key refreshes, they also leak the information that they personally are using the key. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From dashohoxha at gmail.com Sun May 1 13:57:09 2016 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Sun, 1 May 2016 13:57:09 +0200 Subject: making a Debian Live CD for managing GnuPG master key and smartcards In-Reply-To: <5722F350.80708@gmail.com> References: <571F1E62.30203@pocock.pro> <571F4E02.1080100@pocock.pro> <571F5D18.30901@pocock.pro> <5722F350.80708@gmail.com> Message-ID: On Fri, Apr 29, 2016 at 7:38 AM, Paul R. Ramer wrote: > On 04/26/2016 05:24 AM, Dashamir Hoxha wrote: > > It doesn't seem reasonable to me. > > Honestly, what is with this, "It doesn't seem reasonable to me," line? > This is the second post in the thread where you have said this. If you > want people to react positively to the needs of your project, you might > choose not to say things like, "I don't want to...," and, "It doesn't > seem reasonable to me." > > You already know that there seems to be a consensus that your project is > not a solution to any problem. [1] You effectively ask for help, and yet > when someone tells you how you can make a Debian package, which is an > issue on your development website [2], you say that you don't want to do > it because it "doesn't seem reasonable." > > You can't have it both ways. You are either engaging, communicative, > reasonable, and compromising, or you are not. But don't expect anyone > to help you when reject their ideas out of turn. > > You asked for help on smartcards recently because you don't have any > readers or cards. I am not sure whether your project is useful or not, > but I had considered giving you some assistance since I have multiple > readers and cards. I might help you out when I had some free time just > because you asked for it, I thought. But your inflexible, and sometimes > irreverent, attitude has soured my intention. > This message about me is a bit off topic, in my opinion. So, I don't find it reasonable to reply here. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joerg at schmitz-linneweber.de Mon May 2 17:13:16 2016 From: joerg at schmitz-linneweber.de (=?UTF-8?Q?J=C3=B6rg_Schmitz-Linneweber?=) Date: Mon, 02 May 2016 17:13:16 +0200 Subject: gpg and smartcard on ubuntu 16.04 In-Reply-To: <1461790938.5458.19.camel@gmail.com> References: <1461790938.5458.19.camel@gmail.com> Message-ID: Hi! Am 2016-04-27 23:02, schrieb Richard Ulrich: > I didn't read this list for a while, so forgive me if this was > discussed before. > > For many years I have used gpg and gpg-agent with ssh support with an > OpenPGP smartcard.? > On every ubuntu upgrade I had to fiddle a little bit to have gpg-agent > act for ssh auth. No big deal usually. > > But this time, after the usual fiddling, I have it working nicely for > ssh and evolution. But now it's the direct usage of gpg on the command > line that is giving me a hard time. This aspect always worked out of > the box so far. A colleague had the same problems (at the same day... :) and after some time we found that in the process of the update to 16.04, Ubuntu/apt-get decided to de-install the package "scdaemon"! So as the scdaemon is mandatory for gnupg card usage and ssh auth access, he re-installed it and afterwards he was back to business. But keep in mind: He had a working ssh/gpg/smart card setup *before* starting the update to 16.04 and this setup was also not quite intuitive either. :-) Salut, Joerg -- gpg/pgp key # 0xd7fa4512 fingerprint 4e89 6967 9cb2 f548 a806 7e8b fcf4 2053 d7fa 4512 From Hauke_Westemeier at web.de Sun May 1 21:54:06 2016 From: Hauke_Westemeier at web.de (Hauke Westemeier) Date: Sun, 1 May 2016 21:54:06 +0200 Subject: Default Settings of honor-keyserver-url ? Message-ID: <71d9b9ec-5b2f-8a25-43a1-d55fe0892aaf@web.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm using GnuPG 2.0.30 (installed for Windows 8.1 by Gpg4win 2.3.1). If I run gpg2 --no-options --keyserver keys.gnupg.net --refresh-keys I get "gpg: fordere Schl?ssel F0D6B1E0 von ldap-Server keyserver.pgp.com an" which translates to something like "gpg: request key F0D6B1E0 from ldap-Server keyserver.pgp.com" All other keys are updated from keyserver.pgp.com as requested but for key F0D6B1E0 its preferred key server ldap://keyserver.pgp.com is used. I can use gpg2 --no-options --keyserver keys.gnupg.net --keyserver-options no-honor-keyserver-url --refresh-keys to only use keys.gnupg.net but from the manual https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuration-Options.html > honor-keyserver-url When using --refresh-keys, if the key in > question has a preferred keyserver URL, then use that preferred > keyserver to refresh the key from. In addition, if > auto-key-retrieve is set, and the signature being verified has a > preferred keyserver URL, then use that preferred keyserver to > fetch the key from. Note that this option introduces a "web bug": > The creator of the key can see when the keys is refreshed. Thus > this option is not enabled by default. I thought that honor-keyserver-url is disabled by default (for very good reasons) and I'm therefore surprised that I have to specify no-honor-keyserver-url explicitly. Can somebody comment on this issue? Just two more short questions by me: - - Is there a way (for me or you) to fix the encoding of the gpg output (the German Umlaute are not properly displayed, for example in "Schl?ssel", "unver?ndert"...)? - - Already in 2014 was reported http://wald.intevation.org/tracker/?func=detail&atid=126&aid=6528&group_id=11 that the --workdir option is not working in gnupg 2.0 and it still doesn't work in gnupg 2.0.30. Is there a chance that it will work in coming 2.0.X versions or do I have to switch to 2.1 (I was told that it is working there)? Of course I can set the GNUPGHOME system variable but I found having an command line option more convenient. It took me quite some time to find out that there was a problem after I updated from gnupg 1.4, at least an error/warning should be provided so that others don't run into the same pitfall. Kind regards, Hauke -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlcmXtwACgkQjz8jfoq989daMgCfdloQf2i6gtyM//sqxQPHPZxB 8loAn0oRWxTPsdwCjtHwgigfMO9YvGfu =d7/G -----END PGP SIGNATURE----- From luis.marsano at gmail.com Mon May 2 04:21:37 2016 From: luis.marsano at gmail.com (Luis Marsano) Date: Sun, 1 May 2016 22:21:37 -0400 Subject: How to add ssh key to gpg-agent in Windows 10? Message-ID: I'm using GnuPG 2.1.11 from the *Simple installer for GnuPG modern* Windows binary release on https://www.gnupg.org/download/index.html After muddling about a great deal, I found gpg-agent can be enabled as an ssh-agent for PuTTY by - adding enable-putty-support to *gpg-agent.conf* - gpg --expert --edit-key key-id and adding a subkey with authentication flag - gpg --list-secret-keys --with-keygrip --with-colons key-id | sed -ne '/:a:/,/^grp/ {/^grp/p;}' | cut -d: -f10 >>~/.gnupg/sshcontrol to get keygrip and add it to *sshcontrol* - gpg --export-ssh-key key-id | ssh user at host 'cat - >>.ssh/authorized_keys' - reloading gpg-agent Is there a simpler way to add the keygrip to *sshcontrol*? The above enables us to use gpg-created keys for ssh sessions. The manual https://www.gnupg.org/documentation/manuals/gnupg/Agent-Options.html#index-enable_002dputty_002dsupport-62 also discusses using *ssh-add* to add ssh keys to gpg-agent. PuTTY, however, doesn't include *ssh-add* and cygwin/msys2 *ssh-add* doesn't seem compatible with native gpg-agent. How do we add ssh keys to gpg-agent in Windows? -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel at pocock.pro Tue May 3 14:04:21 2016 From: daniel at pocock.pro (Daniel Pocock) Date: Tue, 3 May 2016 14:04:21 +0200 Subject: Reiner SCT cyberJack Secoder 2 / PIN pad support? Message-ID: <572893C5.2070003@pocock.pro> I've got this device with a built-in PIN pad: Reiner SCT cyberJack Secoder 2 / PIN pad support? $ lsusb -v ... idVendor 0x0c4b Reiner SCT Kartensysteme GmbH idProduct 0x0400 ... $ opensc-tool -l # Detected readers (pcsc) Nr. Card Features Name 0 No PIN pad REINER SCT cyberJack ecom_a (7555830073) 00 00 When I try to use it, I am always prompted for the PIN on my PC I found some support for Reiner SCT and Cyberjack with different product ID in ccid-driver.c: $ egrep 'REINER|CYBER' scd/ccid-driver.c VENDOR_REINER = 0x0c4b, #define CYBERJACK_GO 0x0504 although CYBERJACK_GO doesn't appear to be used anywhere else in there. I've also got a reader from another manufacturer, it also has a PIN pad and that other reader works fine using the exact same sequence of commands, e.g. gpg2 --card-edit admin lang en I'm using gnupg2 packages on Debian jessie, version 2.0.26-6 I came across this blog: https://blogs.fsfe.org/jzarl/2013/08/20/card-reader-reinersct-cyberjack-pinpad/ and it suggests that there are some older Reiner SCT readers that will never be supported because they use pcscd and don't support CCID I looked at scd.log and it appears that CCID is not supported for this reader: 2016-05-03 13:46:47 scdaemon[20977] DBG: ccid-driver: failed to open `/dev/cmx0': No such file or directory 2016-05-03 13:46:47 scdaemon[20977] DBG: ccid-driver: failed to open `/dev/cmx1': No such file or directory 2016-05-03 13:46:47 scdaemon[20977] DBG: ccid-driver: no CCID reader with number 0 Does this mean this reader will definitely never work with GnuPG? Is it possible the reader will work with OpenSC or something else on Linux? Can anybody comment on any of the readers that people should buy if they want a PIN pad? Could GnuPG provide an easier way for people to diagnose whether their reader is supported without having to check logs? From daniel at pocock.pro Tue May 3 15:04:15 2016 From: daniel at pocock.pro (Daniel Pocock) Date: Tue, 3 May 2016 15:04:15 +0200 Subject: managing OpenPGP cards in batch mode? Message-ID: <5728A1CF.6090807@pocock.pro> I tried this with GnuPG 2.0.26 on Debian: $ gpg2 --card-edit --batch gpg: can't do this in batch mode Is this supported in newer versions or can it be done with GPGME? In particular, I would like the user to be able to do things like: - set PINs - set language - set name - set URL From dashohoxha at gmail.com Tue May 3 15:55:10 2016 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Tue, 3 May 2016 15:55:10 +0200 Subject: managing OpenPGP cards in batch mode? In-Reply-To: <5728A1CF.6090807@pocock.pro> References: <5728A1CF.6090807@pocock.pro> Message-ID: On Tue, May 3, 2016 at 3:04 PM, Daniel Pocock wrote: > > I tried this with GnuPG 2.0.26 on Debian: > > $ gpg2 --card-edit --batch > gpg: can't do this in batch mode > You can try something like this: - https://github.com/nyarly/simplekey/blob/master/commands/trust#L46-L50 or like this: - https://github.com/dashohoxha/egpg/blob/master/src/cmd/key/renew.sh#L40-L47 -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel at pocock.pro Tue May 3 20:20:14 2016 From: daniel at pocock.pro (Daniel Pocock) Date: Tue, 3 May 2016 20:20:14 +0200 Subject: managing OpenPGP cards in batch mode? In-Reply-To: References: <5728A1CF.6090807@pocock.pro> Message-ID: <5728EBDE.1020608@pocock.pro> On 03/05/16 15:55, Dashamir Hoxha wrote: > On Tue, May 3, 2016 at 3:04 PM, Daniel Pocock > wrote: > > I tried this with GnuPG 2.0.26 on Debian: > > $ gpg2 --card-edit --batch > gpg: can't do this in batch mode > > > You can try something like this: > - https://github.com/nyarly/simplekey/blob/master/commands/trust#L46-L50 > or like this: > - https://github.com/dashohoxha/egpg/blob/master/src/cmd/key/renew.sh#L40-L47 Thanks for this feedback This is a list of all the things that I need to batch/manage from the whiptail UI: gen-key (and get back the key ID) adduid - GnuPG 2.1 has --quick-adduid adding more subkeys (addkey) "--gen-key --batch" only creates one subkey gen-revoke card-edit (for setting PIN, etc) keytocard The method you propose appears to be dependent on a particular GnuPG version / menu strings. As it will be on a Live CD we could live with that temporarily because it will be immutable and users won't mix and match the script with different GnuPG versions. In the long term it would be nice to do all those things through batch mode or an API though. Regards, Daniel From dashohoxha at gmail.com Tue May 3 22:31:24 2016 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Tue, 3 May 2016 22:31:24 +0200 Subject: managing OpenPGP cards in batch mode? In-Reply-To: <5728EBDE.1020608@pocock.pro> References: <5728A1CF.6090807@pocock.pro> <5728EBDE.1020608@pocock.pro> Message-ID: On Tue, May 3, 2016 at 8:20 PM, Daniel Pocock wrote: > > > On 03/05/16 15:55, Dashamir Hoxha wrote: > > On Tue, May 3, 2016 at 3:04 PM, Daniel Pocock > > wrote: > > > > I tried this with GnuPG 2.0.26 on Debian: > > > > $ gpg2 --card-edit --batch > > gpg: can't do this in batch mode > > > > > > You can try something like this: > > - > https://github.com/nyarly/simplekey/blob/master/commands/trust#L46-L50 > > or like this: > > - > https://github.com/dashohoxha/egpg/blob/master/src/cmd/key/renew.sh#L40-L47 > > Thanks for this feedback > > This is a list of all the things that I need to batch/manage from the > whiptail UI: > > gen-key (and get back the key ID) > > adduid > - GnuPG 2.1 has --quick-adduid > > adding more subkeys (addkey) > "--gen-key --batch" only creates one subkey > > gen-revoke > > card-edit (for setting PIN, etc) > > keytocard > I will keep an eye on your project and see how you manage to solve these. Is it on GitHub (so that I can watch you)? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Wed May 4 08:13:13 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 04 May 2016 08:13:13 +0200 Subject: managing OpenPGP cards in batch mode? In-Reply-To: <5728EBDE.1020608@pocock.pro> (Daniel Pocock's message of "Tue, 3 May 2016 20:20:14 +0200") References: <5728A1CF.6090807@pocock.pro> <5728EBDE.1020608@pocock.pro> Message-ID: <878tzq1hc6.fsf@wheatstone.g10code.de> On Tue, 3 May 2016 20:20, daniel at pocock.pro said: > gen-key (and get back the key ID) There is also --quick-gen-key: $ gpg -v --status-fd 2 --batch --quick-gen-key test-20160504.2 at example.org [GNUPG:] PINENTRY_LAUNCHED 9804 [GNUPG:] PINENTRY_LAUNCHED 9806 gpg: writing self signature gpg: RSA/SHA256 signature from: "43A68746 [?]" gpg: writing key binding signature gpg: RSA/SHA256 signature from: "43A68746 [?]" gpg: writing public key to '/home/wk/b/gnupg/tmp3/pubring.kbx' gpg: using PGP trust model gpg: key 43A68746 marked as ultimately trusted gpg: writing to '[...]/openpgp-revocs.d/5AF79828EB76B2709378639CEE[...] gpg: RSA/SHA256 signature from: "43A68746 test-20160504.2 at example.org" gpg: revocation certificate stored as '[...]/openpgp-revocs.d/5AF7[...] [GNUPG:] KEY_CREATED B 5AF79828EB76B2709378639CEEBFB26F43A68746 Instead of the key ID you should use the fingerprint as shows in the KEY_CREATED status line. > adding more subkeys (addkey) > "--gen-key --batch" only creates one subkey A --quick-addkey has been discussed but has not yet been implemented. > gen-revoke Well, 2.1 creates a revocation certifciate with the key. > card-edit (for setting PIN, etc) You need to use --status-fd and --command-fd to automate this. Or you bypass gpg and use gpg-connect-agent to access the card directly. Using --debug 1024 and a log file in scdaemon.confshows you what the gpg commands do. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From SK at flowserve.com Wed May 4 08:53:55 2016 From: SK at flowserve.com (K, Saravanakumar) Date: Wed, 4 May 2016 06:53:55 +0000 Subject: How to Encrypt & Sign a file? Message-ID: Hi all, Am to trying to encrypt & sign a file without using the terminal from SAP using the following command. --no-tty --recipient --encrypt --sign --default-key /SAP /input/PPID.TXT The above command resulted with the following error gpg: no default secret key: No secret key gpg: [stdin]: sign+encrypt failed: No secret key External program terminated with exit code 2 Requesting you to guide me where to set the default secret key. I would appreciate if you could guide me with the step by step procedure. Many thanks in advance. Kind regards, K. Saravanakumar Programmer/Analyst SAP COE APAC Flowserve Corporation office: 044 46238363 mobile: +91 9962522880 email: sk at flowserve.com Flowserve India Controls Private Limited 7th Floor, AMBIT IT Park, 32-A&B, Industrial Estate, Ambattur, CHENNAI 600 058, India NOTICE: The information contained in this e-mail, and attachment(s) thereto, is confidential and may contain attorney - client privileged communications. If you are not the intended recipient,you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately and delete the e-mail from your computer system without retaining any copies. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnxx at posteo.net Wed May 4 10:18:04 2016 From: jnxx at posteo.net (Johannes Nix) Date: Wed, 4 May 2016 09:18:04 +0100 Subject: [tool / utility] check-trustpaths, a command-line tool for retrieving and checking chains of signatures in the web of trust Message-ID: <20160504091804.74f1212c@mangold.snakenest.scot> I wrote a small tool for automatically retrieving and checking trust paths between two PGP keys. This was motivated by me experiencing difficulty when verifying signed Linux distribution images or downloads for web software using GnuPG. The PGP Pathfinder Service provided by Henk P. Penning allows to do that manually. However, to strongly verify a key, one needs to download and locally check each key in the resulting trust path, which is somewhat time-consuming, and probably to much of a hassle for normal people. What I wanted was a utility to do that check in an automated way. Therefore, I wrote a little Python program which does that, and documentation how to use it, it is here: https://github.com/jnxx/check-trustpaths I'd be happy to hear whether it is working for you and where it can be improved. The utility tries to cover a number of edge cases and security aspects - querying several key servers at once, requiring 64-bit key IDs by default, sanitizing responses from the pgp pathfinder service, handling potential 32-bit collisions of key IDs (such as for Peter Palfrader's key, which is a signing key for the Debian image key) and warning about them. Also, I have a question. The tool assumes by default that key ID collisions are possible, for 32-bit key IDs as well as for 64-bit key IDs. Therefore, the documentation suggests to use the fingerprint of the target key to identify this key. If more than one key is found for an ID, it tries to resolve the ambiguity by matching the signature with the ID of the preceding key in the chain. The long IDs of the signing keys are retrieved using gpg --check-sigs --with-colons. However, this command only returns a 64-bit key ID for the signing key, not its fingerprint. My questions are, is the above reasonably secure? Assuming that it is better the use the fingerprint of the signing key, how can I retrieve it? Johannes From peter at digitalbrains.com Wed May 4 11:37:32 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 4 May 2016 11:37:32 +0200 Subject: managing OpenPGP cards in batch mode? In-Reply-To: References: <5728A1CF.6090807@pocock.pro> <5728EBDE.1020608@pocock.pro> Message-ID: <5729C2DC.9000807@digitalbrains.com> On 03/05/16 22:31, Dashamir Hoxha wrote: > Is it on GitHub (so that I can watch you)? >From [1]: the project is in Git, but not on GitHub. You can browse the repository on the web at [2], and you can clone it to your local hard disk with: git clone https://anonscm.debian.org/git/collab-maint/make-pgp-clean-room.git HTH, Peter. [1] https://wiki.debian.org/OpenPGP/CleanRoomLiveEnvironment [2] https://anonscm.debian.org/cgit/collab-maint/make-pgp-clean-room.git/ -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Wed May 4 11:40:07 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 4 May 2016 11:40:07 +0200 Subject: managing OpenPGP cards in batch mode? In-Reply-To: <878tzq1hc6.fsf@wheatstone.g10code.de> References: <5728A1CF.6090807@pocock.pro> <5728EBDE.1020608@pocock.pro> <878tzq1hc6.fsf@wheatstone.g10code.de> Message-ID: <5729C377.7000807@digitalbrains.com> On 04/05/16 08:13, Werner Koch wrote: > There is also --quick-gen-key: > > [...] > > Well, 2.1 creates a revocation certifciate with the key. Werner, would you recommend they use 2.1 or 2.0 for the Debian Live CD? Cheers, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From wk at gnupg.org Wed May 4 11:55:11 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 04 May 2016 11:55:11 +0200 Subject: managing OpenPGP cards in batch mode? In-Reply-To: <5729C377.7000807@digitalbrains.com> (Peter Lebbing's message of "Wed, 4 May 2016 11:40:07 +0200") References: <5728A1CF.6090807@pocock.pro> <5728EBDE.1020608@pocock.pro> <878tzq1hc6.fsf@wheatstone.g10code.de> <5729C377.7000807@digitalbrains.com> Message-ID: <87shxyywow.fsf@wheatstone.g10code.de> On Wed, 4 May 2016 11:40, peter at digitalbrains.com said: > Werner, would you recommend they use 2.1 or 2.0 for the Debian Live CD? 2.1 of course Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dashohoxha at gmail.com Wed May 4 12:16:47 2016 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Wed, 4 May 2016 12:16:47 +0200 Subject: managing OpenPGP cards in batch mode? In-Reply-To: <5729C2DC.9000807@digitalbrains.com> References: <5728A1CF.6090807@pocock.pro> <5728EBDE.1020608@pocock.pro> <5729C2DC.9000807@digitalbrains.com> Message-ID: On Wed, May 4, 2016 at 11:37 AM, Peter Lebbing wrote: > On 03/05/16 22:31, Dashamir Hoxha wrote: > > Is it on GitHub (so that I can watch you)? > > From [1]: the project is in Git, but not on GitHub. GitHub provides issue/project management features on top of Git. For example it will notify me when new issues are created, when pull requests are merged, when new releases are made, etc. Git is great, GitHub is greater. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel at pocock.pro Wed May 4 12:22:44 2016 From: daniel at pocock.pro (Daniel Pocock) Date: Wed, 4 May 2016 12:22:44 +0200 Subject: managing OpenPGP cards in batch mode? In-Reply-To: <87shxyywow.fsf@wheatstone.g10code.de> References: <5728A1CF.6090807@pocock.pro> <5728EBDE.1020608@pocock.pro> <878tzq1hc6.fsf@wheatstone.g10code.de> <5729C377.7000807@digitalbrains.com> <87shxyywow.fsf@wheatstone.g10code.de> Message-ID: <5729CD74.7040004@pocock.pro> On 04/05/16 11:55, Werner Koch wrote: > On Wed, 4 May 2016 11:40, peter at digitalbrains.com said: > >> Werner, would you recommend they use 2.1 or 2.0 for the Debian Live CD? > > 2.1 of course > I already raised the topic of using 2.1, there is some feedback about it in the bug tracker, especially about the file format issues: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822974 Given the Live CD is a clean room, isolated, will the file format compatibility issues will be relevant? People with interact with other systems by copying keys to be signed onto a flash drive and copy the signed keys back into the other system later. The other system they use may be running 1.4.x or 2.0.x Regards, Daniel From gniibe at fsij.org Wed May 4 13:37:55 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 04 May 2016 20:37:55 +0900 Subject: Reiner SCT cyberJack Secoder 2 / PIN pad support? In-Reply-To: <572893C5.2070003@pocock.pro> References: <572893C5.2070003@pocock.pro> Message-ID: <5729DF13.9040502@fsij.org> On 05/03/2016 09:04 PM, Daniel Pocock wrote: > I've got this device with a built-in PIN pad: > > Reiner SCT cyberJack Secoder 2 / PIN pad support? > > > $ lsusb -v > ... > idVendor 0x0c4b Reiner SCT Kartensysteme GmbH > idProduct 0x0400 If I understand correctly, this device is not CCID (the USB standard for smartcard reader) compatible. It seems that it is supported by another library to PC/SC. https://tracker.debian.org/pkg/pcsc-cyberjack Thus, scd/ccid-driver.c is irrelevant for this device. All that GnuPG could do is through PC/SC. I maintain this list: https://wiki.debian.org/GnuPG/CCID_Driver For pinpad input support, please see here: https://wiki.gnupg.org/CardReader/PinpadInput -- From peter at digitalbrains.com Wed May 4 14:07:04 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 4 May 2016 14:07:04 +0200 Subject: managing OpenPGP cards in batch mode? In-Reply-To: <5729CD74.7040004@pocock.pro> References: <5728A1CF.6090807@pocock.pro> <5728EBDE.1020608@pocock.pro> <878tzq1hc6.fsf@wheatstone.g10code.de> <5729C377.7000807@digitalbrains.com> <87shxyywow.fsf@wheatstone.g10code.de> <5729CD74.7040004@pocock.pro> Message-ID: <5729E5E8.5070407@digitalbrains.com> On 04/05/16 12:22, Daniel Pocock wrote: > Given the Live CD is a clean room, isolated, will the file format > compatibility issues will be relevant? To the best of my knowledge, this would indeed not pose a problem at all. Note that exporting a private key with 2.1 prompts the user to enter the passphrase for the key. This is different from how earlier versions did it. The reason is a technical one: the local storage is in a different format than the export, and hence the passphrase is needed to decrypt the local storage, convert the format and then re-encrypt the export. As far as I can see, it doesn't matter whether the passphrase is already cached or not: I am always prompted for export. > People with interact with other systems by copying keys to be signed onto a > flash drive and copy the signed keys back into the other system later. The > other system they use may be running 1.4.x or 2.0.x I agree. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Wed May 4 14:34:07 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 4 May 2016 14:34:07 +0200 Subject: (OT) development infrastructure In-Reply-To: References: <5728A1CF.6090807@pocock.pro> <5728EBDE.1020608@pocock.pro> <5729C2DC.9000807@digitalbrains.com> Message-ID: <5729EC3F.1010900@digitalbrains.com> On 04/05/16 12:16, Dashamir Hoxha wrote: > GitHub provides issue/project management features on top of Git. > For example it will notify me when new issues are created, when > pull requests are merged, when new releases are made, etc. Debian has its own infrastructure for that. In fact, the Git repository for the Live CD is hosted by the Debian infrastructure. Incidentally, GitHub is not as free (as in freedom) as some would like it to be, so it makes sense Debian, with its DFSG, is using its own infrastructure for it. (I'm just putting it in perspective, I'm not trying to provoke a discussion on freedom) HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From wk at gnupg.org Wed May 4 15:38:49 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 04 May 2016 15:38:49 +0200 Subject: managing OpenPGP cards in batch mode? In-Reply-To: (Dashamir Hoxha's message of "Wed, 4 May 2016 12:16:47 +0200") References: <5728A1CF.6090807@pocock.pro> <5728EBDE.1020608@pocock.pro> <5729C2DC.9000807@digitalbrains.com> Message-ID: <87r3dix7rq.fsf@wheatstone.g10code.de> On Wed, 4 May 2016 12:16, dashohoxha at gmail.com said: > Git is great, GitHub is greater. I would appreciate if you do not advertise proprietary services here. Those who really want such a centralized service may eant to check out gitlab.com, which seems to repect user freedom better. See also https://lwn.net/Articles/685199/ Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernhard at intevation.de Wed May 4 15:42:52 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 4 May 2016 15:42:52 +0200 Subject: Webpage and mailinglists overview Message-ID: <201605041542.56856.bernhard@intevation.de> Hi Webmaster, just noticed that the information about our community mailinglist is a bit inconsistent. http://lists.gnupg.org/ does not list a number of relevant mailinglists like gnupg-de and gnupg-commits. I suggest to scratch the http://lists.gnupg.org/ page and redirect it to https://gnupg.org/documentation/mailing-lists.html Note that http://lists.gnupg.org/mailman/listinfo/ still has some lists which probably never ran anything like Neues at least there is nothing in the archives. How about scratching these? Shouldn't also be considered to discontinue some mailinglists that have almost no relevant traffic for many years? Gnupg-br looks like a candidat for this, probably others. Some archive links are broken from the listinfo pages, e.g. https://lists.gnupg.org/mailman/listinfo/gnupg-es https://lists.gnupg.org/mailman/listinfo/gnupg-doc and some others. Should I better open issue in the tracker? Best, Bernhard -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 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: 473 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Wed May 4 16:26:10 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 4 May 2016 16:26:10 +0200 Subject: [tool / utility] check-trustpaths, a command-line tool for retrieving and checking chains of signatures in the web of trust In-Reply-To: <20160504091804.74f1212c@mangold.snakenest.scot> References: <20160504091804.74f1212c@mangold.snakenest.scot> Message-ID: <201605041626.14819.bernhard@intevation.de> Hi Johannes, Am Mittwoch, 4. Mai 2016 10:18:04 schrieb Johannes Nix: > https://github.com/jnxx/check-trustpaths > > I'd be happy to hear whether it is working for you > and where it can be improved. I like the idea, I'll probably try it once I have a need for the use case. Maybe you can add a link to your tool to wiki.gnupg.org? First thing I've noticed is that it does not use the recommended gnupg api based on gpgme. Did you consider pyme or pygpgme? (See https://wiki.gnupg.org/APIs ) For a new application (which is not a module) I would directly go to python3 and gpg2 only in order to easy future maintenance. Best, Bernhard -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 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: 473 bytes Desc: This is a digitally signed message part. URL: From gnupg at soondae.co.uk Wed May 4 16:38:18 2016 From: gnupg at soondae.co.uk (keith) Date: Wed, 04 May 2016 15:38:18 +0100 Subject: UK Investigatory Powers Bill Message-ID: <1462372698.2764.40.camel@keith> Feel free to ignore me. As you may know the UK Government is attempting to update or otherwise consolidate its legislation in respect of access to Communications and Other Data for the purposes of law enforcement. In part that is what raised my interest in encryption and caused me to join this list. I am not really any further forward but the interest remains... I should mention that I am not a Diplomat or Advocate but rather a thick keyboard slapper. I've been following, listening to, The Public Bill Committee Debates with some degree of disappointment given the odds are stacked by the present Government majority and the apparent lack of technical knowledge of those involved in developing this legislation. I am just listening to, http://dl.parliamentlive.tv/ukp/vod/_download/552432b2-0a7d-4dae-a58d-a528a62b7a89_01_64.mp3?dln=20160503_investigatory_powers_bill_committee My apologies for not being able to give an exact time stamp but somewhere about 2 hours in they start discussing encryption and the capability of requesting its removal. I'm not going to try and decipher what is going on here or the thoughts or interpretations of those concerned other than suggest that things appear to fall to pieces or at least there is a veil of uncertainty. Again... feel free to ignore me but it strikes me, and it should be unsurprising, that you lot know what you are talking about given you built GPG and as such I wonder if you might wish to make a direct comment to the committee yourselves. I realise that is a big ask because the underlying information is extensive and spread out across numerous resources. Other problem is the consultation, or this stage of it, closes tomorrow... http://services.parliament.uk/bills/2015-16/investigatorypowers/committees/houseofcommonspublicbillcommitteeontheinvestigatorypowersbill201516.html "Latest news The Public Bill Committee on the Investigatory Powers Bill has now concluded its work, and has reported the Bill to the House with amendments. Once a Public Bill Committee has completed its work it is no longer able to receive written evidence." It appears it is now 'closed'... Next stop[?] 'House of Lords'.. http://services.parliament.uk/bills/2015-16/investigatorypowers.html Otherwise Kier Starmer, Labour, and Joanna Cherry, Scottish National Party, were the committee members who worked hardest to scrutinise and attempt to amend the bill at this particular stage. keir.starmer.mp at parliament.uk joanna.cherry.mp at parliament.uk I could be wrong but given the Government majority my impression is that they were not overly successful. However you might wish to ask them for advice and gather your thoughts in order to present your concerns, should you have any, and voice them. This UK legislation will have impact elsewhere. Regards Keith From wk at gnupg.org Wed May 4 17:15:51 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 04 May 2016 17:15:51 +0200 Subject: [Announce] GnuPG 2.1.12 released Message-ID: <87eg9hyhug.fsf@wheatstone.g10code.de> Hello! The GnuPG team is pleased to announce the availability of a new release of GnuPG modern: Version 2.1.12. See below for new features and bug fixes. The GNU Privacy Guard (GnuPG) is a complete and free implementation of the OpenPGP standard which is commonly abbreviated as PGP. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries making use of GnuPG are available. Since version 2 GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Three different branches of GnuPG are actively maintained: - GnuPG "modern" (2.1) is the latest development with a lot of new features. This announcement is about this branch. - GnuPG "stable" (2.0) is the current stable version for general use. This is what most users are still 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.12 ==================================== * gpg: New --edit-key sub-command "change-usage" for testing purposes. * gpg: Out of order key-signatures are now systematically detected and fixed by --edit-key. * gpg: Improved detection of non-armored messages. * gpg: Removed the extra prompt needed to create Curve25519 keys. * gpg: Improved user ID selection for --quick-sign-key. * gpg: Use the root CAs provided by the system with --fetch-key. * gpg: Add support for the experimental Web Key Directory key location service. * gpg: Improve formatting of Tofu messages and emit new Tofu specific status lines. * gpgsm: Add option --pinentry-mode to support a loopback pinentry. * gpgsm: A new pubring.kbx is now created with the header blob so that gpg can detect that the keybox format needs to be used. * agent: Add read support for the new private key protection format openpgp-s2k-ocb-aes. * agent: Add read support for the new extended private key format. * agent: Default to --allow-loopback-pinentry and add option --no-allow-loopback-pinentry. * scd: Changed to use the new libusb 1.0 API for the internal CCID driver. * dirmngr: The dirmngr-client does now auto-detect the PEM format. * g13: Add experimental support for dm-crypt. * w32: Tofu support is now available with the Speedo build method. * w32: Removed the need for libiconv.dll. * The man pages for gpg and gpgv are now installed under the correct name (gpg2 or gpg - depending on a configure option). * Lots of internal cleanups and 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 or read on: GnuPG 2.1.12 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.12.tar.bz2 (5381k) ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.12.tar.bz2.sig or here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.12.tar.bz2 (5381k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.12.tar.bz2.sig An installer for Windows without any graphical frontend except for a basic Pinentry tool is available here: ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.12_20160504.exe (3477k) ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.12_20160504.exe.sig or here https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.12_20160504.exe (3477k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.12_20160504.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. This Windows installer comes with Tofu support, translations, and support for Tor and the Tor browser. It is still missing HKPS support, though. 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.12.tar.bz2 you would use this command: gpg --verify gnupg-2.1.12.tar.bz2.sig gnupg-2.1.12.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.12.tar.bz2, you run the command like this: sha1sum gnupg-2.1.12.tar.bz2 and check that the output matches the next line: 3b01a35ac04277ea31cc01b4ac4e230e54b5480c gnupg-2.1.12.tar.bz2 0195d8b551e35b958f5efb4b678c3a178ba1ecb7 gnupg-w32-2.1.12_20160504.exe 2bad63245431a67fb4f076ec2b95f24b1ea1da0f gnupg-w32-2.1.12_20160504.tar.xz Release Signing Keys ==================== To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: 2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31] Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 Werner Koch (Release Signing Key) You may retrieve these keys from a keyserver using this command gpg --keyserver hkp://keys.gnupg.net --recv-keys \ 249B39D24F25E3B6 04376F3EE0856959 \ 2071B08A33BD3F06 8A861B1C7EFD60D9 The keys are also available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese, Czech, French, German, Japanese, Russian, and Ukrainian being almost completely translated (2166 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 our postings at . Support ======== Please consult the archive of the gnupg-users mailing list before reporting a bug . We suggest to send bug reports for a new release to this list in favor of filing a bug at . For commercial support requests we keep a list of known service companies at: https://gnupg.org/service.html If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Maintenance and development of GnuPG is mostly financed by donations. As of today we employ 3 full-time developers, one part-timer, and one contractor. They all work on GnuPG and closely related software like Libgcrypt and GPA. Please consider to donate via: https://gnupg.org/donate/ Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, answering questions on the mailing lists, and donating money. For the GnuPG hackers, Werner p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users'at'gnupg.org mailing list. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From steve-gnupg at gbnet.net Wed May 4 17:30:49 2016 From: steve-gnupg at gbnet.net (Steve Karmeinsky) Date: Wed, 4 May 2016 16:30:49 +0100 Subject: UK Investigatory Powers Bill In-Reply-To: <1462372698.2764.40.camel@keith> References: <1462372698.2764.40.camel@keith> Message-ID: <20160504153049.GE8584@davin.gbnet.net> On Wed, May 04, 2016 at 03:38:18PM +0100, keith wrote: > This UK legislation will have impact elsewhere. Currently encryption isn't banned, however say you encrypt an email and send it to someone and the 'authorities' want to read it, they can then force you to hand over the keys and if you refuse, you go to jail until you do ... There are other major issues like equipment interference and bulk interception to name a few. Steve -- NetTek Ltd UK mob +44 7775 755503 UK +44 20 3432 3735 / US +1 (650) 423 1390 / Fax +44 20 7483 2455 social id stevekennedyuk Euro Tech News Blog http://eurotechnews.blogspot.com From gnupg at soondae.co.uk Wed May 4 19:04:55 2016 From: gnupg at soondae.co.uk (keith) Date: Wed, 04 May 2016 18:04:55 +0100 Subject: UK Investigatory Powers Bill In-Reply-To: <20160504153049.GE8584@davin.gbnet.net> References: <1462372698.2764.40.camel@keith> <20160504153049.GE8584@davin.gbnet.net> Message-ID: <1462381495.2764.63.camel@keith> .. I should really sort out which e-mails I have a clue about.. On Wed, 2016-05-04 at 16:30 +0100, Steve Karmeinsky wrote: > On Wed, May 04, 2016 at 03:38:18PM +0100, keith wrote: > > > This UK legislation will have impact elsewhere. > > Currently encryption isn't banned, however say you encrypt an email and > send it to someone and the 'authorities' want to read it, they can then > force you to hand over the keys and if you refuse, you go to jail until > you do ... > > There are other major issues like equipment interference and bulk > interception to name a few. > > Steve > Thanks.. Having listened further, I was just going through it when I posted my original message.. and gone to Hansard, http://www.publications.parliament.uk/pa/cm201516/cmpublic/InvestigatoryPowers/160503/am/PBC_Investigatory%20Powers%2015th%20sit%20(am)%203.5.16.pdf ..There should be a linkable online version somewhere but my skills are broken.. >From Page 14 of 20, [651|652] "Joanna Cherry: I am sorry to interrupt the Solicitor General?s flow, but I sense he is coming to the end of his argument. Will he clarify something? Am I right in understanding that there is nothing in the clause to prevent someone who is intent on evading surveillance from using open-source encryption software that is personally generated by the user? That would mean they could encrypt files and email communications themselves, independent of any provider, and therefore remain untouched by this legislation. The Solicitor General: That question is about the definition of the provider. I am sure we will be able to provide some clarity on that before I draw my remarks to a conclusion. I am grateful to the hon. and learned Lady for raising that point. - - The hon. and learned Lady made the powerful point that the clause does not relate to personally applied encryption. However, measures in part 3 of RIPA 2000 provide for where law enforcement agencies can require an individual to remove encryption that he or she has applied themselves. We know that the Bill generally does not cover all the agencies? powers. This is perhaps a welcome opportunity to remind ourselves of the existing provisions in part 3, so I am grateful to her." Then as you suggest they are relying on or appear to be relying upon RIPA 2000 whereby the person who applied the original encryption can be 'forced' to hand over their keys. Being me I still would not trust them to not be seeking ways or means to back door encryption. It's got something to do with their lips moving :-) I also note your point about equipment interference and bulk interception. You can add ICRs and indeed the rest of the bill to the list of concerns. Personally I almost realise that some of this may be needed and/or indeed necessary but I am concerned that the direction and level of intrusion might be misplaced. Regards Keith From dashohoxha at gmail.com Wed May 4 21:12:04 2016 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Wed, 4 May 2016 21:12:04 +0200 Subject: managing OpenPGP cards in batch mode? In-Reply-To: <87r3dix7rq.fsf@wheatstone.g10code.de> References: <5728A1CF.6090807@pocock.pro> <5728EBDE.1020608@pocock.pro> <5729C2DC.9000807@digitalbrains.com> <87r3dix7rq.fsf@wheatstone.g10code.de> Message-ID: On Wed, May 4, 2016 at 3:38 PM, Werner Koch wrote: > On Wed, 4 May 2016 12:16, dashohoxha at gmail.com said: > > > Git is great, GitHub is greater. > > I would appreciate if you do not advertise proprietary services here. > I do not advertise, I expess my opinion. Do you think that I am affiliated somehow with GitHub? Yes, I can obey you. However, "e pur si muove", it still is great, the truth cannot be hidden. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dashohoxha at gmail.com Wed May 4 21:13:05 2016 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Wed, 4 May 2016 21:13:05 +0200 Subject: managing OpenPGP cards in batch mode? In-Reply-To: References: <5728A1CF.6090807@pocock.pro> <5728EBDE.1020608@pocock.pro> <5729C2DC.9000807@digitalbrains.com> <87r3dix7rq.fsf@wheatstone.g10code.de> Message-ID: On Wed, May 4, 2016 at 9:12 PM, Dashamir Hoxha wrote: > On Wed, May 4, 2016 at 3:38 PM, Werner Koch wrote: > >> On Wed, 4 May 2016 12:16, dashohoxha at gmail.com said: >> >> > Git is great, GitHub is greater. >> >> I would appreciate if you do not advertise proprietary services here. >> > > I do not advertise, I expess my opinion. > Do you think that I am affiliated somehow with GitHub? > Yes, I can obey you. > However, "e pur si muove", it still is great, the truth cannot be hidden. > Peace. (Sorry, I forgot to greet.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From timog24 at mailbox.org Wed May 4 20:22:59 2016 From: timog24 at mailbox.org (Timo) Date: Wed, 4 May 2016 20:22:59 +0200 Subject: Hundreds of RSA keys factored Message-ID: <572A3E03.5050004@mailbox.org> There is this scary project listing several hundreds factored pgp/rsa keys: http://trilema.com/2016/the-phuctoring/ Quote: "This find exposes significant vulnerabilities in the OpSec practices of each and every organisation or institution mentioned. The Pirate Party, German users, something calling itself "The PGP Corporation", the FSF and Apple particularly badly hit. Phuctor will continue as a free, open and public service in the indefinite future. Feel free to verify your future keys against the ever-growing database. Special thanks to Mr. D. J. Bernstein for refinements to the algorithm that allowed us to reduce the required workload considerably.ii" In theory the software generating the keys should check the generated primes using algorithms like the Miller-Rabin-Test, which would return with near perfect security whether the number is prime or not. On the site I noticed that many of the keys that use nonprime numbers are generated by gnupg. Given that there are only a few million pgp keys on the public keyservers and the likelihood of the Rabin-Miller-Test failing is way lower than this result shown by the mentioned site, should it not be assumed that there is something wrong with the implementation? Maybe someone can put the pieces together for me to understand how this is possible. -------------- 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 May 4 22:23:05 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 04 May 2016 22:23:05 +0200 Subject: off-topic/adverstising posts (was: managing OpenPGP cards in batch mode?) In-Reply-To: (Dashamir Hoxha's message of "Wed, 4 May 2016 21:12:04 +0200") References: <5728A1CF.6090807@pocock.pro> <5728EBDE.1020608@pocock.pro> <5729C2DC.9000807@digitalbrains.com> <87r3dix7rq.fsf@wheatstone.g10code.de> Message-ID: <8737pxvahi.fsf_-_@wheatstone.g10code.de> On Wed, 4 May 2016 21:12, dashohoxha at gmail.com said: > However, "e pur si muove", it still is great, the truth cannot be hidden. I asked you not to do this on this list. There are enough other ways to express OT opinions; look fur such opportunities. Please do us all a favor and stick to the netiquette. There is no need for to reply to this mail. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From richard.hoechenberger at gmail.com Wed May 4 21:54:17 2016 From: richard.hoechenberger at gmail.com (=?UTF-8?Q?Richard_H=C3=B6chenberger?=) Date: Wed, 4 May 2016 21:54:17 +0200 Subject: managing OpenPGP cards in batch mode? In-Reply-To: References: <5728A1CF.6090807@pocock.pro> <5728EBDE.1020608@pocock.pro> <5729C2DC.9000807@digitalbrains.com> <87r3dix7rq.fsf@wheatstone.g10code.de> Message-ID: On Wed, May 4, 2016 at 9:12 PM, Dashamir Hoxha wrote: > I do not advertise, I expess my opinion. Please keep you it to yourself, then. Your provocative, passive-aggressive communication style is outrageous and disrespectful. From rjh at sixdemonbag.org Thu May 5 00:09:07 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 4 May 2016 18:09:07 -0400 Subject: Hundreds of RSA keys factored In-Reply-To: <572A3E03.5050004@mailbox.org> References: <572A3E03.5050004@mailbox.org> Message-ID: > There is this scary project listing several hundreds factored pgp/rsa > keys: http://trilema.com/2016/the-phuctoring/ Not scary. Not all that interesting, either. It's also been discussed on this list before. This group claims to have access to my secret key. I posted a 256-bit random sequence and asked them to sign it with my key. Daniel Kahn Gillmor realized I'd made an oversight: it could be my encryption key they'd broken. He posted an encrypted message and suggested they reveal the random string contained therein. We have not heard back from them. See, e.g.: https://lists.gnupg.org/pipermail/gnupg-users/2015-May/053632.html Until such time as they're able to verify that yes, they can forge signatures or decrypt traffic, I think we should be suspicious of their claims. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Thu May 5 00:14:01 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 4 May 2016 18:14:01 -0400 Subject: managing OpenPGP cards in batch mode? In-Reply-To: References: <5728A1CF.6090807@pocock.pro> <5728EBDE.1020608@pocock.pro> <5729C2DC.9000807@digitalbrains.com> <87r3dix7rq.fsf@wheatstone.g10code.de> Message-ID: <4dc839d7-98c0-f65b-7550-ec8c96c7be9d@sixdemonbag.org> > I do not advertise, I expess my opinion. Dashamir, this list has very few rules. I'm grateful for that, really. One of the few rules that must be obeyed, though, is "we will not advocate non-libre software or products here". If you want to host your project on GitHub, go for it! Nobody will condemn you for it. But describing GitHub as a superior product, *without constructive criticism as to how to improve libre products*, is against the rules. "GitHub is so much better than the libre alternatives because it supports two-factor authentication via Yubikey" is okay. You're talking about how a proprietary product is better, but you're also showing how libre products can be improved. "GitHub is better" is not okay. You're just talking about how a proprietary product is better. From 2014-667rhzu3dc-lists-groups at riseup.net Thu May 5 00:15:47 2016 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Wed, 4 May 2016 23:15:47 +0100 Subject: UK Investigatory Powers Bill In-Reply-To: <1462381495.2764.63.camel@keith> References: <1462372698.2764.40.camel@keith> <20160504153049.GE8584@davin.gbnet.net> <1462381495.2764.63.camel@keith> Message-ID: <118570216.20160504231547@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Wednesday 4 May 2016 at 6:04:55 PM, in , keith wrote: > Personally I almost realise that > some of this may be > needed and/or indeed necessary By contrast, I am 100% certain that none of it is needed. If "the authorities" think they need access to some specific group or individual's communications, they can employ plain old-fashioned deception to have undercover agents worm their way in and get themselves trusted and included in the encryption list. - -- Best regards MFPA Editing is a rewording activity -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJXKnSUXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXw1scH/17gSYP8Lp4tt+JyBDEPFv+B 9oMEjIYgWy33fL5tuIpOZVvwLrkBIbwmUv7NmcHjudIZkusp+iCcuE0o9rk/k7nm 0PYEZOgWUSsh1FCbcYJvh3CRqYVsj9UdRnQv0SjSEzWiyntV1Kt4PpXCziPO9hEt zyBDEJaNhfTWKAyrnf4IL2BQfmBCSHuEQ2Z5d4W//zpWz2nQvecCZhJoTJJqzzYN azVZY6LnTh3kIEWGWIX102h7ysomserDVBa5d6UkcCZpU7mGi8clekXTfT0SkT3x sCzd7aDtUvkLnE0sYv06SXx1nwNYvch6PqjHl1iOiGMGjK2iw7iyo7cLzIEMIFKI vgQBFgoAZgUCVyp0lF8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45PPkAQD+3bWvLVUwitqeR3Z1ffGglzcW GeojR/Gh5ZM3ybiy+QEAr/SR/pa4QCQP+G94NkDeJk86gBowwhgGntlHld4VcQ0= =J0rX -----END PGP SIGNATURE----- From steve-gnupg at gbnet.net Thu May 5 01:48:22 2016 From: steve-gnupg at gbnet.net (Steve Karmeinsky) Date: Thu, 5 May 2016 00:48:22 +0100 Subject: UK Investigatory Powers Bill In-Reply-To: <118570216.20160504231547@riseup.net> References: <1462372698.2764.40.camel@keith> <20160504153049.GE8584@davin.gbnet.net> <1462381495.2764.63.camel@keith> <118570216.20160504231547@riseup.net> Message-ID: <20160504234822.GA26696@davin.gbnet.net> On Wed, May 04, 2016 at 11:15:47PM +0100, MFPA wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > On Wednesday 4 May 2016 at 6:04:55 PM, in > , keith wrote: > > Personally I almost realise that > > some of this may be > > needed and/or indeed necessary > By contrast, I am 100% certain that none of it is needed. If "the > authorities" think they need access to some specific group or > individual's communications, they can employ plain old-fashioned > deception to have undercover agents worm their way in and get > themselves trusted and included in the encryption list. Unfortunately it doesn't matter if it's needed, it's becoming law (well it's already law under RIP, but DRIP 'expires' this year, so now enshrined under IP Act). It's a blanked law to ensure what's being done already is now legalised. Steve -- NetTek Ltd UK mob +44 7775 755503 UK +44 20 3432 3735 / US +1 (650) 423 1390 / Fax +44 20 7483 2455 social id stevekennedyuk Euro Tech News Blog http://eurotechnews.blogspot.com From caro at nymph.paranoici.org Thu May 5 00:55:34 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Wed, 4 May 2016 22:55:34 +0000 (UTC) Subject: 'No pinentry' error (--pinentry-mode loopback with --delete-secret-and-public-key) Message-ID: <20160504225534.2DFAC101222B@remailer.paranoici.org> Hello! I need help with GnuPG 2.1.12 migrating an encryption tool from 1.4.20. I'm trying to run the --delete-secret-and-public-key command with the passphrase entered through stdin, which doesn't get activated ('delete key failed: No pinentry'). With --export-secret-keys I was successful this way (also added below). Or can I use --passphrase somehow? TIA Caro --delete-secret-and-public-key: | Microsoft Windows [Version 6.1.7600] | Copyright (c) 2009 Microsoft Corporation. All rights reserved. | | d:\gpg>gpg.exe --pinentry-mode loopback --homedir "d:\gpgdat" --debug-level 10 --no-auto-key-locate --lock-once --no-default-keyring --keyring "d:\gpgdat\pubring.kbx" --delete-secret-and-public-key "66C040ADBE2C5728022F81DCCE09E0556C2C8CE0" | gpg (GnuPG) 2.1.12; Copyright (C) 2016 Free Software Foundation, Inc. | This is free software: you are free to change and redistribute it. | There is NO WARRANTY, to the extent permitted by law. | | gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust cardio ipc clock lookup extprog | gpg: DBG: [not enabled in the source] start | gpg: DBG: [not enabled in the source] keydb_new | gpg: DBG: [not enabled in the source] keydb_search enter | gpg: DBG: keydb_search: 1 search descriptions: | gpg: DBG: keydb_search 0: FPR20: '66C0 40AD BE2C 5728 022F 81DC CE09 E055 6C2C 8CE0' | gpg: DBG: keydb_search: searching keybox (resource 0 of 1) | gpg: DBG: keydb_search: searched keybox (resource 0 of 1) => Success | gpg: DBG: [not enabled in the source] keydb_search leave (found) | gpg: DBG: [not enabled in the source] keydb_get_keybock enter | gpg: DBG: parse_packet(iob=1): type=6 length=269 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.12/g10/keydb.c.1172) | gpg: DBG: parse_packet(iob=1): type=13 length=27 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.12/g10/keydb.c.1172) | gpg: DBG: parse_packet(iob=1): type=2 length=311 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.12/g10/keydb.c.1172) | gpg: DBG: parse_packet(iob=1): type=14 length=269 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.12/g10/keydb.c.1172) | gpg: DBG: parse_packet(iob=1): type=2 length=287 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.12/g10/keydb.c.1172) | gpg: DBG: iobuf-1.0: underflow: buffer size: 1177; still buffered: 0 => space for 1177 bytes | gpg: DBG: [not enabled in the source] keydb_get_keyblock leave | gpg: DBG: [not enabled in the source] keydb_new | gpg: DBG: [not enabled in the source] keydb_search enter | gpg: DBG: keydb_search: 1 search descriptions: | gpg: DBG: keydb_search 0: LONG_KID: 'CE09E0556C2C8CE0' | gpg: DBG: keydb: kid_not_found_p (ce09e0556c2c8ce0) => indeterminate | gpg: DBG: keydb_search: searching keybox (resource 0 of 1) | gpg: DBG: keydb_search: searched keybox (resource 0 of 1) => Success | gpg: DBG: [not enabled in the source] keydb_search leave (found) | gpg: DBG: [not enabled in the source] keydb_get_keybock enter | gpg: DBG: parse_packet(iob=2): type=6 length=269 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.12/g10/keydb.c.1172) | gpg: DBG: parse_packet(iob=2): type=13 length=27 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.12/g10/keydb.c.1172) | gpg: DBG: parse_packet(iob=2): type=2 length=311 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.12/g10/keydb.c.1172) | gpg: DBG: parse_packet(iob=2): type=14 length=269 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.12/g10/keydb.c.1172) | gpg: DBG: parse_packet(iob=2): type=2 length=287 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.12/g10/keydb.c.1172) | gpg: DBG: iobuf-2.0: underflow: buffer size: 1177; still buffered: 0 => space for 1177 bytes | gpg: DBG: iobuf-2.0: close '?' | gpg: DBG: [not enabled in the source] keydb_get_keyblock leave | gpg: DBG: chan_0x000000b4 <- OK Pleased to meet you | gpg: DBG: connection to agent established | gpg: DBG: chan_0x000000b4 -> RESET | gpg: DBG: chan_0x000000b4 <- OK | gpg: DBG: chan_0x000000b4 -> GETINFO version | gpg: DBG: chan_0x000000b4 <- D 2.1.12 | gpg: DBG: chan_0x000000b4 <- OK | gpg: DBG: chan_0x000000b4 -> OPTION allow-pinentry-notify | gpg: DBG: chan_0x000000b4 <- OK | gpg: DBG: chan_0x000000b4 -> OPTION agent-awareness=2.1.0 | gpg: DBG: chan_0x000000b4 <- OK | gpg: DBG: chan_0x000000b4 -> OPTION pinentry-mode=loopback | gpg: DBG: chan_0x000000b4 <- OK | gpg: DBG: chan_0x000000b4 -> AGENT_ID | gpg: DBG: chan_0x000000b4 <- ERR 67109139 Unknown IPC command | gpg: DBG: get_keygrip for public key | gpg: DBG: keygrip= BC 31 F5 AE D9 89 EC CF 8C 4B BE 97 88 F8 5C 7F 97 4B 5C 43 | gpg: DBG: chan_0x000000b4 -> HAVEKEY BC31F5AED989ECCF8C4BBE9788F85C7F974B5C43 | gpg: DBG: chan_0x000000b4 <- OK | gpg: DBG: free_packet() type=6 | gpg: DBG: free_packet() type=13 | gpg: DBG: free_packet() type=2 | gpg: DBG: free_packet() type=14 | gpg: DBG: free_packet() type=2 | gpg: DBG: free_packet() type=6 | gpg: DBG: free_packet() type=13 | gpg: DBG: free_packet() type=2 | gpg: DBG: free_packet() type=14 | gpg: DBG: free_packet() type=2 | gpg: DBG: [not enabled in the source] keydb_new | gpg: DBG: [not enabled in the source] keydb_search enter | gpg: DBG: keydb_search: 1 search descriptions: | gpg: DBG: keydb_search 0: FPR20: '66C0 40AD BE2C 5728 022F 81DC CE09 E055 6C2C 8CE0' | gpg: DBG: keydb_search: searching keybox (resource 0 of 1) | gpg: DBG: keydb_search: searched keybox (resource 0 of 1) => Success | gpg: DBG: [not enabled in the source] keydb_search leave (found) | gpg: DBG: [not enabled in the source] keydb_get_keybock enter | gpg: DBG: parse_packet(iob=3): type=6 length=269 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.12/g10/keydb.c.1172) | gpg: DBG: parse_packet(iob=3): type=13 length=27 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.12/g10/keydb.c.1172) | gpg: DBG: parse_packet(iob=3): type=2 length=311 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.12/g10/keydb.c.1172) | gpg: DBG: parse_packet(iob=3): type=14 length=269 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.12/g10/keydb.c.1172) | gpg: DBG: parse_packet(iob=3): type=2 length=287 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.12/g10/keydb.c.1172) | gpg: DBG: iobuf-3.0: underflow: buffer size: 1177; still buffered: 0 => space for 1177 bytes | gpg: DBG: [not enabled in the source] keydb_get_keyblock leave | gpg: DBG: [not enabled in the source] keydb_new | gpg: DBG: [not enabled in the source] keydb_search enter | gpg: DBG: keydb_search: 1 search descriptions: | gpg: DBG: keydb_search 0: LONG_KID: 'CE09E0556C2C8CE0' | gpg: DBG: keydb: kid_not_found_p (ce09e0556c2c8ce0) => indeterminate | gpg: DBG: keydb_search: searching keybox (resource 0 of 1) | gpg: DBG: keydb_search: searched keybox (resource 0 of 1) => Success | gpg: DBG: [not enabled in the source] keydb_search leave (found) | gpg: DBG: [not enabled in the source] keydb_get_keybock enter | gpg: DBG: parse_packet(iob=4): type=6 length=269 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.12/g10/keydb.c.1172) | gpg: DBG: parse_packet(iob=4): type=13 length=27 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.12/g10/keydb.c.1172) | gpg: DBG: parse_packet(iob=4): type=2 length=311 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.12/g10/keydb.c.1172) | gpg: DBG: parse_packet(iob=4): type=14 length=269 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.12/g10/keydb.c.1172) | gpg: DBG: parse_packet(iob=4): type=2 length=287 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.12/g10/keydb.c.1172) | gpg: DBG: iobuf-4.0: underflow: buffer size: 1177; still buffered: 0 => space for 1177 bytes | gpg: DBG: iobuf-4.0: close '?' | gpg: DBG: [not enabled in the source] keydb_get_keyblock leave | gpg: DBG: get_keygrip for public key | gpg: DBG: keygrip= BC 31 F5 AE D9 89 EC CF 8C 4B BE 97 88 F8 5C 7F 97 4B 5C 43 | gpg: DBG: chan_0x000000b4 -> HAVEKEY BC31F5AED989ECCF8C4BBE9788F85C7F974B5C43 | gpg: DBG: chan_0x000000b4 <- OK | gpg: DBG: free_packet() type=6 | gpg: DBG: free_packet() type=13 | gpg: DBG: free_packet() type=2 | gpg: DBG: free_packet() type=14 | gpg: DBG: free_packet() type=2 | gpg: DBG: [not enabled in the source] keydb_new | gpg: DBG: [not enabled in the source] keydb_search enter | gpg: DBG: keydb_search: 1 search descriptions: | gpg: DBG: keydb_search 0: LONG_KID: 'CE09E0556C2C8CE0' | gpg: DBG: keydb: kid_not_found_p (ce09e0556c2c8ce0) => indeterminate | gpg: DBG: keydb_search: searching keybox (resource 0 of 1) | gpg: DBG: keydb_search: searched keybox (resource 0 of 1) => Success | gpg: DBG: [not enabled in the source] keydb_search leave (found) | gpg: DBG: [not enabled in the source] keydb_get_keybock enter | gpg: DBG: parse_packet(iob=5): type=6 length=269 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.12/g10/keydb.c.1172) | gpg: DBG: parse_packet(iob=5): type=13 length=27 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.12/g10/keydb.c.1172) | gpg: DBG: parse_packet(iob=5): type=2 length=311 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.12/g10/keydb.c.1172) | gpg: DBG: parse_packet(iob=5): type=14 length=269 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.12/g10/keydb.c.1172) | gpg: DBG: parse_packet(iob=5): type=2 length=287 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.12/g10/keydb.c.1172) | gpg: DBG: iobuf-5.0: underflow: buffer size: 1177; still buffered: 0 => space for 1177 bytes | gpg: DBG: iobuf-5.0: close '?' | gpg: DBG: [not enabled in the source] keydb_get_keyblock leave | gpg: DBG: rsa_verify data:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffff003031300d060960864801650304020105000420fa \ | gpg: DBG: 995b39967a266737fe2f3ea5706e8ca9cf74ca41421cbb41585d7924528ccf | gpg: DBG: rsa_verify sig:+a30bee84b033191164b9044390fda761aa07304dbffda51818dcc58c1d35fee0 \ | gpg: DBG: 49b572d4270e5170a88e4fb679d5d92db20d73ad6d4a2506175dd589a6ed823c \ | gpg: DBG: 19289ba2a53b37d36858f5862cffbc03d6b008a1458325501317c5fca0da002b \ | gpg: DBG: 32d33218dcca0e28c3daa099ad9d77a5180cab24f308167b56b08bc09739e27d \ | gpg: DBG: 7a230effa20a15c00a7cf539c5e284a1f2c20e3317bd1769b70e4c879ce96273 \ | gpg: DBG: acc5bc11964da8b0838000430a8cc5c31fdaf67affddec57b7e78ea9d3687b19 \ | gpg: DBG: 973a38cbdd5f999277edbc7fbe7778381344d709414985a555a2917793ad2bd5 \ | gpg: DBG: 6ae9ceb6a978ca5c4013d247461848ae01e57cf992f829718c09d0bc23aef9b5 | gpg: DBG: rsa_verify n:+d0fc6758502a00410f146475aa5476606cca8171dff82f51ba200da910070d19 \ | gpg: DBG: ba3d75234921d91d28b7185ae2ef5fdd8784478062fed301e7169c57e30640fd \ | gpg: DBG: bbf5135f41054692ae53caf4e3c43bf9b8742e09c79e8708fcc7d81eb80f1bc4 \ | gpg: DBG: 2fdb6a5c0873ef6056af23bfc812842511a5e20d2679c1a928ebca6253ac709e \ | gpg: DBG: 64dd024cd4c6aab536f8bdf04f3aaf88f5bca930d98ace0404b6968c9862fd32 \ | gpg: DBG: 77354da998886a145c062dfda7716c24cc2984e74fba3a54f352f2f27358b152 \ | gpg: DBG: dc4b5f3c385ad5daa0584fcd3973cc3261c30c20d880a4337725642bbf4958f8 \ | gpg: DBG: 0955d75ad7f4945bc5ecae441dfe07733adf818da4869ba01c839c3a4efd6cad | gpg: DBG: rsa_verify e:+010001 | gpg: DBG: rsa_verify cmp:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffff003031300d060960864801650304020105000420fa \ | gpg: DBG: 995b39967a266737fe2f3ea5706e8ca9cf74ca41421cbb41585d7924528ccf | gpg: DBG: rsa_verify => Good | gpg: DBG: rsa_verify data:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffff003031300d06096086480165030402010500042056 \ | gpg: DBG: 97370d0d16d80c17131cc965d8ceb95561ce1b054ec511335c0b728ffe7a9e | gpg: DBG: rsa_verify sig:+8478589cf4af50735cae5079c6b5eacc0a5dabf7512822da44dc93734cc37b3d \ | gpg: DBG: 60b14b66518222036ff08fc02695b3a2d5a5de062128846d9196a67a2e60f3be \ | gpg: DBG: 9963602588db10a9f93e4afedef106d7347e86a8bd9893ed1dbab018987d49dd \ | gpg: DBG: 099fdcffaa6c327f105c9ee85062c152cdcb11acb42eba159cb91ff0a976fd1a \ | gpg: DBG: 46e723f8cfe4a5d4ddc7146e66901070a59c1eecfb7425822990743c4a7267cf \ | gpg: DBG: 4da0b47914901dcc0b258a43193850f56727a96320d9c9f1844499a4957fe6ad \ | gpg: DBG: 7169f48ded5db477136bb5dc0c3b6f0307721dfb4776ef8fe25e48560deaf827 \ | gpg: DBG: 4c045eb55cddfc57b6d2d075280409a07be9fc5db309a564eaca1f99f2648bf0 | gpg: DBG: rsa_verify n:+d0fc6758502a00410f146475aa5476606cca8171dff82f51ba200da910070d19 \ | gpg: DBG: ba3d75234921d91d28b7185ae2ef5fdd8784478062fed301e7169c57e30640fd \ | gpg: DBG: bbf5135f41054692ae53caf4e3c43bf9b8742e09c79e8708fcc7d81eb80f1bc4 \ | gpg: DBG: 2fdb6a5c0873ef6056af23bfc812842511a5e20d2679c1a928ebca6253ac709e \ | gpg: DBG: 64dd024cd4c6aab536f8bdf04f3aaf88f5bca930d98ace0404b6968c9862fd32 \ | gpg: DBG: 77354da998886a145c062dfda7716c24cc2984e74fba3a54f352f2f27358b152 \ | gpg: DBG: dc4b5f3c385ad5daa0584fcd3973cc3261c30c20d880a4337725642bbf4958f8 \ | gpg: DBG: 0955d75ad7f4945bc5ecae441dfe07733adf818da4869ba01c839c3a4efd6cad | gpg: DBG: rsa_verify e:+010001 | gpg: DBG: rsa_verify cmp:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffff003031300d06096086480165030402010500042056 \ | gpg: DBG: 97370d0d16d80c17131cc965d8ceb95561ce1b054ec511335c0b728ffe7a9e | gpg: DBG: rsa_verify => Good | gpg: DBG: finish_lookup: checking key 6C2C8CE0 (one)(req_usage=0) | gpg: DBG: using key 6C2C8CE0 | gpg: DBG: free_packet() type=6 | gpg: DBG: free_packet() type=13 | gpg: DBG: free_packet() type=2 | gpg: DBG: free_packet() type=14 | gpg: DBG: free_packet() type=2 | | sec rsa2048/6C2C8CE0 2016-04-23 John Doe | | Delete this key from the keyring? (y/N) y | This is a secret key! - really delete? (y/N) y | gpg: DBG: get_keygrip for public key | gpg: DBG: keygrip= BC 31 F5 AE D9 89 EC CF 8C 4B BE 97 88 F8 5C 7F 97 4B 5C 43 | gpg: DBG: chan_0x000000b4 -> HAVEKEY BC31F5AED989ECCF8C4BBE9788F85C7F974B5C43 | gpg: DBG: chan_0x000000b4 <- OK | gpg: DBG: get_keygrip for public key | gpg: DBG: keygrip= BC 31 F5 AE D9 89 EC CF 8C 4B BE 97 88 F8 5C 7F 97 4B 5C 43 | gpg: DBG: chan_0x000000b4 -> SETKEYDESC Do+you+really+want+to+permanently+delete+the+OpenPGP+secret+key:%0A%22John+Doe+%22%0A2048-bit+RSA+key,+ID+6C2C8CE0,%0Acreated+2016-04-23.%0A? | gpg: DBG: chan_0x000000b4 <- OK | gpg: DBG: chan_0x000000b4 -> DELETE_KEY BC31F5AED989ECCF8C4BBE9788F85C7F974B5C43 | gpg: DBG: chan_0x000000b4 <- ERR 67108949 No pinentry | gpg: deleting secret key failed: No pinentry | gpg: DBG: get_keygrip for public key | gpg: DBG: keygrip= E6 3C 96 35 C5 29 5C 76 3E 99 C4 CF 6B 87 CF 9D 2C 7F 07 17 | gpg: DBG: chan_0x000000b4 -> HAVEKEY E63C9635C5295C763E99C4CF6B87CF9D2C7F0717 | gpg: DBG: chan_0x000000b4 <- OK | gpg: DBG: get_keygrip for public key | gpg: DBG: keygrip= E6 3C 96 35 C5 29 5C 76 3E 99 C4 CF 6B 87 CF 9D 2C 7F 07 17 | gpg: DBG: chan_0x000000b4 -> SETKEYDESC Do+you+really+want+to+permanently+delete+the+OpenPGP+secret+subkey+key:%0A%22John+Doe+%22%0A2048-bit+RSA+key,+ID+174B70A0,%0Acreated+2016-04-23+(main+key+ID+6C2C8CE0).%0A? | gpg: DBG: chan_0x000000b4 <- OK | gpg: DBG: chan_0x000000b4 -> DELETE_KEY E63C9635C5295C763E99C4CF6B87CF9D2C7F0717 | gpg: DBG: chan_0x000000b4 <- ERR 67108949 No pinentry | gpg: deleting secret subkey failed: No pinentry | gpg: DBG: free_packet() type=6 | gpg: DBG: free_packet() type=13 | gpg: DBG: free_packet() type=2 | gpg: DBG: free_packet() type=14 | gpg: DBG: free_packet() type=2 | gpg: 66C040ADBE2C5728022F81DCCE09E0556C2C8CE0: delete key failed: No pinentry | gpg: DBG: [not enabled in the source] stop | gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 | outmix=0 getlvl1=0/0 getlvl2=0/0 | gpg: secmem usage: 0/32768 bytes in 0 blocks | | d:\gpg> --export-secret-keys: | d:\gpg>gpg.exe --pinentry-mode loopback --homedir "d:\gpgdat" --debug-level 10 --no-auto-key-locate --lock-once --no-default-keyring --keyring "d:\gpgdat\pubring.kbx" --armor --export-secret-keys "6C2C8CE0" | gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust cardio ipc clock lookup extprog | gpg: DBG: [not enabled in the source] start | gpg: DBG: iobuf-1.0: open '[stdout]' desc=file_filter(fd) fd=7 | gpg: DBG: iobuf-1.0: ioctl 'file_filter(fd)' no_cache=1 | gpg: DBG: armor-filter: control: 5 | gpg: DBG: iobuf-1.1: push 'armor_filter' | gpg: DBG: armor-filter: control: 5 | gpg: DBG: iobuf chain: 1.1 'armor_filter' filter_eof=0 start=0 len=0 | gpg: DBG: iobuf chain: 1.0 'file_filter(fd)' filter_eof=0 start=0 len=0 | gpg: DBG: armor-filter: control: 1 | gpg: DBG: [not enabled in the source] keydb_new | gpg: DBG: chan_0x000000ac <- OK Pleased to meet you | gpg: DBG: connection to agent established | gpg: DBG: chan_0x000000ac -> RESET | gpg: DBG: chan_0x000000ac <- OK | gpg: DBG: chan_0x000000ac -> GETINFO version | gpg: DBG: chan_0x000000ac <- D 2.1.12 | gpg: DBG: chan_0x000000ac <- OK | gpg: DBG: chan_0x000000ac -> OPTION allow-pinentry-notify | gpg: DBG: chan_0x000000ac <- OK | gpg: DBG: chan_0x000000ac -> OPTION agent-awareness=2.1.0 | gpg: DBG: chan_0x000000ac <- OK | gpg: DBG: chan_0x000000ac -> OPTION pinentry-mode=loopback | gpg: DBG: chan_0x000000ac <- OK | gpg: DBG: chan_0x000000ac -> AGENT_ID | gpg: DBG: chan_0x000000ac <- ERR 67109139 Unknown IPC command | gpg: DBG: chan_0x000000ac -> KEYWRAP_KEY --export | gpg: DBG: chan_0x000000ac <- D -?pj+r,(+rfJ+??? | gpg: DBG: chan_0x000000ac <- OK | gpg: DBG: [not enabled in the source] keydb_search enter | gpg: DBG: keydb_search: 1 search descriptions: | gpg: DBG: keydb_search 0: SHORT_KID: '6C2C8CE0' | gpg: DBG: keydb_search: searching keybox (resource 0 of 1) | gpg: DBG: keydb_search: searched keybox (resource 0 of 1) => Success | gpg: DBG: [not enabled in the source] keydb_search leave (found) | gpg: DBG: [not enabled in the source] keydb_get_keybock enter | gpg: DBG: parse_packet(iob=2): type=6 length=269 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.12/g10/keydb.c.1172) | gpg: DBG: parse_packet(iob=2): type=13 length=27 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.12/g10/keydb.c.1172) | gpg: DBG: parse_packet(iob=2): type=2 length=311 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.12/g10/keydb.c.1172) | gpg: DBG: parse_packet(iob=2): type=14 length=269 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.12/g10/keydb.c.1172) | gpg: DBG: parse_packet(iob=2): type=2 length=287 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.12/g10/keydb.c.1172) | gpg: DBG: iobuf-2.0: underflow: buffer size: 1177; still buffered: 0 => space for 1177 bytes | gpg: DBG: iobuf-2.0: close '?' | gpg: DBG: [not enabled in the source] keydb_get_keyblock leave | gpg: DBG: get_keygrip for public key | gpg: DBG: keygrip= BC 31 F5 AE D9 89 EC CF 8C 4B BE 97 88 F8 5C 7F 97 4B 5C 43 | gpg: DBG: get_keygrip for public key | gpg: DBG: keygrip= E6 3C 96 35 C5 29 5C 76 3E 99 C4 CF 6B 87 CF 9D 2C 7F 07 17 | gpg: DBG: chan_0x000000ac -> HAVEKEY BC31F5AED989ECCF8C4BBE9788F85C7F974B5C43 E63C9635C5295C763E99C4CF6B87CF9D2C7F0717 | gpg: DBG: chan_0x000000ac <- OK | gpg: DBG: get_keygrip for public key | gpg: DBG: keygrip= BC 31 F5 AE D9 89 EC CF 8C 4B BE 97 88 F8 5C 7F 97 4B 5C 43 | gpg: DBG: chan_0x000000ac -> KEYINFO BC31F5AED989ECCF8C4BBE9788F85C7F974B5C43 | gpg: DBG: chan_0x000000ac <- S KEYINFO BC31F5AED989ECCF8C4BBE9788F85C7F974B5C43 D - - - P - - - | gpg: DBG: chan_0x000000ac <- OK | gpg: DBG: [not enabled in the source] keydb_new | gpg: DBG: [not enabled in the source] keydb_search enter | gpg: DBG: keydb_search: 1 search descriptions: | gpg: DBG: keydb_search 0: LONG_KID: 'CE09E0556C2C8CE0' | gpg: DBG: keydb: kid_not_found_p (ce09e0556c2c8ce0) => indeterminate | gpg: DBG: keydb_search: searching keybox (resource 0 of 1) | gpg: DBG: keydb_search: searched keybox (resource 0 of 1) => Success | gpg: DBG: [not enabled in the source] keydb_search leave (found) | gpg: DBG: [not enabled in the source] keydb_get_keybock enter | gpg: DBG: parse_packet(iob=3): type=6 length=269 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.12/g10/keydb.c.1172) | gpg: DBG: parse_packet(iob=3): type=13 length=27 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.12/g10/keydb.c.1172) | gpg: DBG: parse_packet(iob=3): type=2 length=311 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.12/g10/keydb.c.1172) | gpg: DBG: parse_packet(iob=3): type=14 length=269 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.12/g10/keydb.c.1172) | gpg: DBG: parse_packet(iob=3): type=2 length=287 (parse./home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.12/g10/keydb.c.1172) | gpg: DBG: iobuf-3.0: underflow: buffer size: 1177; still buffered: 0 => space for 1177 bytes | gpg: DBG: iobuf-3.0: close '?' | gpg: DBG: [not enabled in the source] keydb_get_keyblock leave | gpg: DBG: rsa_verify data:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffff003031300d060960864801650304020105000420fa \ | gpg: DBG: 995b39967a266737fe2f3ea5706e8ca9cf74ca41421cbb41585d7924528ccf | gpg: DBG: rsa_verify sig:+a30bee84b033191164b9044390fda761aa07304dbffda51818dcc58c1d35fee0 \ | gpg: DBG: 49b572d4270e5170a88e4fb679d5d92db20d73ad6d4a2506175dd589a6ed823c \ | gpg: DBG: 19289ba2a53b37d36858f5862cffbc03d6b008a1458325501317c5fca0da002b \ | gpg: DBG: 32d33218dcca0e28c3daa099ad9d77a5180cab24f308167b56b08bc09739e27d \ | gpg: DBG: 7a230effa20a15c00a7cf539c5e284a1f2c20e3317bd1769b70e4c879ce96273 \ | gpg: DBG: acc5bc11964da8b0838000430a8cc5c31fdaf67affddec57b7e78ea9d3687b19 \ | gpg: DBG: 973a38cbdd5f999277edbc7fbe7778381344d709414985a555a2917793ad2bd5 \ | gpg: DBG: 6ae9ceb6a978ca5c4013d247461848ae01e57cf992f829718c09d0bc23aef9b5 | gpg: DBG: rsa_verify n:+d0fc6758502a00410f146475aa5476606cca8171dff82f51ba200da910070d19 \ | gpg: DBG: ba3d75234921d91d28b7185ae2ef5fdd8784478062fed301e7169c57e30640fd \ | gpg: DBG: bbf5135f41054692ae53caf4e3c43bf9b8742e09c79e8708fcc7d81eb80f1bc4 \ | gpg: DBG: 2fdb6a5c0873ef6056af23bfc812842511a5e20d2679c1a928ebca6253ac709e \ | gpg: DBG: 64dd024cd4c6aab536f8bdf04f3aaf88f5bca930d98ace0404b6968c9862fd32 \ | gpg: DBG: 77354da998886a145c062dfda7716c24cc2984e74fba3a54f352f2f27358b152 \ | gpg: DBG: dc4b5f3c385ad5daa0584fcd3973cc3261c30c20d880a4337725642bbf4958f8 \ | gpg: DBG: 0955d75ad7f4945bc5ecae441dfe07733adf818da4869ba01c839c3a4efd6cad | gpg: DBG: rsa_verify e:+010001 | gpg: DBG: rsa_verify cmp:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffff003031300d060960864801650304020105000420fa \ | gpg: DBG: 995b39967a266737fe2f3ea5706e8ca9cf74ca41421cbb41585d7924528ccf | gpg: DBG: rsa_verify => Good | gpg: DBG: rsa_verify data:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffff003031300d06096086480165030402010500042056 \ | gpg: DBG: 97370d0d16d80c17131cc965d8ceb95561ce1b054ec511335c0b728ffe7a9e | gpg: DBG: rsa_verify sig:+8478589cf4af50735cae5079c6b5eacc0a5dabf7512822da44dc93734cc37b3d \ | gpg: DBG: 60b14b66518222036ff08fc02695b3a2d5a5de062128846d9196a67a2e60f3be \ | gpg: DBG: 9963602588db10a9f93e4afedef106d7347e86a8bd9893ed1dbab018987d49dd \ | gpg: DBG: 099fdcffaa6c327f105c9ee85062c152cdcb11acb42eba159cb91ff0a976fd1a \ | gpg: DBG: 46e723f8cfe4a5d4ddc7146e66901070a59c1eecfb7425822990743c4a7267cf \ | gpg: DBG: 4da0b47914901dcc0b258a43193850f56727a96320d9c9f1844499a4957fe6ad \ | gpg: DBG: 7169f48ded5db477136bb5dc0c3b6f0307721dfb4776ef8fe25e48560deaf827 \ | gpg: DBG: 4c045eb55cddfc57b6d2d075280409a07be9fc5db309a564eaca1f99f2648bf0 | gpg: DBG: rsa_verify n:+d0fc6758502a00410f146475aa5476606cca8171dff82f51ba200da910070d19 \ | gpg: DBG: ba3d75234921d91d28b7185ae2ef5fdd8784478062fed301e7169c57e30640fd \ | gpg: DBG: bbf5135f41054692ae53caf4e3c43bf9b8742e09c79e8708fcc7d81eb80f1bc4 \ | gpg: DBG: 2fdb6a5c0873ef6056af23bfc812842511a5e20d2679c1a928ebca6253ac709e \ | gpg: DBG: 64dd024cd4c6aab536f8bdf04f3aaf88f5bca930d98ace0404b6968c9862fd32 \ | gpg: DBG: 77354da998886a145c062dfda7716c24cc2984e74fba3a54f352f2f27358b152 \ | gpg: DBG: dc4b5f3c385ad5daa0584fcd3973cc3261c30c20d880a4337725642bbf4958f8 \ | gpg: DBG: 0955d75ad7f4945bc5ecae441dfe07733adf818da4869ba01c839c3a4efd6cad | gpg: DBG: rsa_verify e:+010001 | gpg: DBG: rsa_verify cmp:+01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \ | gpg: DBG: ffffffffffffffffffffff003031300d06096086480165030402010500042056 \ | gpg: DBG: 97370d0d16d80c17131cc965d8ceb95561ce1b054ec511335c0b728ffe7a9e | gpg: DBG: rsa_verify => Good | gpg: DBG: finish_lookup: checking key 6C2C8CE0 (one)(req_usage=0) | gpg: DBG: using key 6C2C8CE0 | gpg: DBG: free_packet() type=6 | gpg: DBG: free_packet() type=13 | gpg: DBG: free_packet() type=2 | gpg: DBG: free_packet() type=14 | gpg: DBG: free_packet() type=2 | gpg: DBG: chan_0x000000ac -> SETKEYDESC Please+enter+the+passphrase+to+export+the+OpenPGP+secret+key:%0A%22John+Doe+%22%0A2048-bit+RSA+key,+ID+6C2C8CE0,%0Acreated+2016-04-23.%0A | gpg: DBG: chan_0x000000ac <- OK | gpg: DBG: chan_0x000000ac -> EXPORT_KEY --openpgp BC31F5AED989ECCF8C4BBE9788F85C7F974B5C43 | gpg: DBG: chan_0x000000ac <- S INQUIRE_MAXLEN 255 | gpg: DBG: chan_0x000000ac <- INQUIRE PASSPHRASE | gpg: DBG: chan_0x000000ac -> D 1234567890 | gpg: DBG: chan_0x000000ac -> END | gpg: DBG: chan_0x000000ac <- S CACHE_NONCE C4D49BE839A4834EA4B28AF1 | gpg: DBG: chan_000000AC <- [ 44 20 6a ac 84 5b 14 25 32 35 50 f1 45 06 8d 6e ...(982 byte(s) skipped) ] | gpg: DBG: chan_000000AC <- [ 44 20 ad 93 41 11 a7 7d eb 61 a7 d7 d9 21 18 b6 ...(102 byte(s) skipped) ] | gpg: DBG: chan_0x000000ac <- OK | gpg: DBG: build_packet() type=6 | gpg: DBG: iobuf-4.0: close '?' | gpg: DBG: build_packet() type=13 | gpg: DBG: build_packet() type=2 | gpg: DBG: iobuf-5.0: close '?' | gpg: DBG: get_keygrip for public key | gpg: DBG: keygrip= E6 3C 96 35 C5 29 5C 76 3E 99 C4 CF 6B 87 CF 9D 2C 7F 07 17 | gpg: DBG: chan_0x000000ac -> KEYINFO E63C9635C5295C763E99C4CF6B87CF9D2C7F0717 | gpg: DBG: chan_0x000000ac <- S KEYINFO E63C9635C5295C763E99C4CF6B87CF9D2C7F0717 D - - - P - - - | gpg: DBG: chan_0x000000ac <- OK | gpg: DBG: chan_0x000000ac -> SETKEYDESC Please+enter+the+passphrase+to+export+the+OpenPGP+secret+subkey:%0A%22John+Doe+%22%0A2048-bit+RSA+key,+ID+174B70A0,%0Acreated+2016-04-23+(main+key+ID+6C2C8CE0).%0A | gpg: DBG: chan_0x000000ac <- OK | gpg: DBG: chan_0x000000ac -> EXPORT_KEY --openpgp --cache-nonce=C4D49BE839A4834EA4B28AF1 E63C9635C5295C763E99C4CF6B87CF9D2C7F0717 | gpg: DBG: chan_0x000000ac <- S CACHE_NONCE C4D49BE839A4834EA4B28AF1 | gpg: DBG: chan_000000AC <- [ 44 20 17 51 e1 e8 a4 10 f9 d2 16 c0 70 d8 f9 cf ...(982 byte(s) skipped) ] | gpg: DBG: chan_000000AC <- [ 44 20 4f 85 ed be 90 14 7c ad 3b c9 1e 8f a8 b3 ...(112 byte(s) skipped) ] | gpg: DBG: chan_0x000000ac <- OK | gpg: DBG: build_packet() type=14 | gpg: DBG: iobuf-6.0: close '?' | gpg: DBG: build_packet() type=2 | gpg: DBG: iobuf-7.0: close '?' | gpg: DBG: [not enabled in the source] keydb_search enter | gpg: DBG: keydb_search: 1 search descriptions: | gpg: DBG: keydb_search 0: SHORT_KID: '6C2C8CE0' | gpg: DBG: keydb_search: searching keybox (resource 0 of 1) | gpg: DBG: keydb_search: searched keybox (resource 0 of 1) => EOF | gpg: DBG: [not enabled in the source] keydb_search leave (not found) | gpg: DBG: free_packet() type=6 | gpg: DBG: free_packet() type=13 | gpg: DBG: free_packet() type=2 | gpg: DBG: free_packet() type=14 | gpg: DBG: free_packet() type=2 | gpg: DBG: armor-filter: control: 4 | gpg: DBG: armor-filter: control: 5 | gpg: DBG: iobuf-1.1: close 'armor_filter' | gpg: DBG: armor-filter: control: 2 | -----BEGIN PGP PRIVATE KEY BLOCK----- | Version: GnuPG v2 | | lQPGBFcbOOoBCADQ/GdYUCoAQQ8UZHWqVHZgbMqBcd/4L1G6IA2pEAcNGbo9dSNJ | IdkdKLcYWuLvX92HhEeAYv7TAecWnFfjBkD9u/UTX0EFRpKuU8r048Q7+bh0LgnH | nocI/MfYHrgPG8Qv22pcCHPvYFavI7/IEoQlEaXiDSZ5wako68piU6xwnmTdAkzU | xqq1Nvi98E86r4j1vKkw2YrOBAS2loyYYv0ydzVNqZiIahRcBi39p3FsJMwphOdP | ujpU81Ly8nNYsVLcS188OFrV2qBYT805c8wyYcMMINiApDN3JWQrv0lY+AlV11rX | 9JRbxeyuRB3+B3M634GNpIaboByDnDpO/WytABEBAAH+BwMCv6PyCdTEdFm2snBn | tg0OE/0M4N7bervDxgQrYUoCpfAaY18D+gDNNYkZ3+/rSLPQ/SdIKOSE690wd0KF | pcOHCreUoWFrIJNIJQpka5hOofZ5P9lIXayeh76wkM0bsPn20VLn3bwqL/r3esvP | 4HxS4Xr9eMymHXaSPK1zYn0YodDwuZKb33/cXs0yGWI+4ldmMOyeo/UYiMHvVvWd | ZfZh2ZEiI49T9ktwAAeOWNZvYiw0WljPD8e/WNEvvsklwIUbmMa+Bm4Rnjx8ZBEo | knUQQ0ImFoq3yk2Pox26OBuFN2HgLm/YvP25K+Pn0kTEgIFCm7UZCykYs03KsYSw | F0TrmxxnZMpKJwo1i7fRW54s2YJenSgnTutCOx8zyg+hNmizbrx3NqEtoMUTPa3a | OhwF2Sd31MIVc2qVVMHNC2rXoR+RFLkG0a+rYFmSAJurLCwkwqAjH2iwDr7ZnNuN | 3rUdlb6p9FK/w1MlGDBw6jaNZ5Nnj+nSH8Nh4llQDuOJXjgkeHSJcFNs+N/dVWZ4 | lGVGWfSHuH/3RMO9Hht4vs1UuWRZjCiY2hsvl/lF2gx9qM52P+0qd5zHB1RNkexD | U3kp2mmQ9EIaBDAPBt9QqVXbx9KLBYDo6u3IZ1ZNVJOgPTKDwj0wJpImEl2xQLxY | wRldQ2ODKGfzhFiWpKYm5SiSh49S59QJLK8f135FhOIgVG1SdFJh+wP6vEsMtFOl | 1Uko1OJA8qKvK4OQRMMpBzio3QHB05WNvxtwntkUaNGo8JxvL+9i4V6iOjdQY5I+ | k3o7JWO2f70SuNxErcs8MKtxkl0Lf6BW12jMBjimK/f9JS9ROkb999OCERLFD3/o | 91STwOLDGi/d7S0g3KjEXBt+pFJieV714Ors2A7v3/xgUUd96wwqebRW6i92q3rU | fZkzJyHl9ELCtBtKb2huIERvZSA8ZG9lakBleGFtcGxlLmNvbT6JATcEEwEIACEF | AlcbOOoCGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQzgngVWwsjOD6mQgA | owvuhLAzGRFkuQRDkP2nYaoHME2//aUYGNzFjB01/uBJtXLUJw5RcKiOT7Z51dkt | sg1zrW1KJQYXXdWJpu2CPBkom6KlOzfTaFj1hiz/vAPWsAihRYMlUBMXxfyg2gAr | MtMyGNzKDijD2qCZrZ13pRgMqyTzCBZ7VrCLwJc54n16Iw7/ogoVwAp89TnF4oSh | 8sIOMxe9F2m3DkyHnOlic6zFvBGWTaiwg4AAQwqMxcMf2vZ6/93sV7fnjqnTaHsZ | lzo4y91fmZJ37bx/vnd4OBNE1wlBSYWlVaKRd5OtK9Vq6c62qXjKXEAT0kdGGEiu | AeV8+ZL4KXGMCdC8I675tZ0DxgRXGzjqAQgAq/kvNEjpU5QyeTJ78RGTdc64BBaR | EH3U217+hzEFFPjC98IDrG9Rh26u/eYgveoKiqUqW8WgTAe1CWVrS7m7oPl73AqW | kLZWuz3/iFy2rcaK2cshHvTSWmVXoj1oKVbcM+kLR39ySusCFL8AjUcp2gvT9cFK | P1R7skl9HfdQgyRS/cUl9t1jy7MEdpj70xpf8bM5VSm1Nk/4bLWe778hub7rxaA0 | 9tRybG4a1mfO5gANYbe9Hfhq+qOKSFFWEkZCl434+Zf8gTG/FKk1kUZ9hrTXcVy6 | Tm3/fL8lB5wnnerPmYUg114tA1X07d7Kk8T15OMAcnpXzDxFSfLgoFBaIQARAQAB | /gcDApEAFN9HunY+tnYnYu+coxe0ni1JP7Id4t26hds0v94cPjT1URooD90OF+mV | AHLU2VWFC/XCi05QJ787OGDFACBU+qOJPYIhc0ZglE+etERa6XmexU7YOcL7FDY3 | gRDrtbqjCuija+oa1yE3K+T1n0o4b+24ppwitW5UBoRWhykTJCese4dU3PfUOEJO | IsNwobS1PUhOT4oDksiAgVCZ5T83IMJp55iSx9FpGNG12p+pHVHnv/OFW5aC+GI1 | tTlPbHFhD5GRbNyM0Mbn7CjAyI/aFNmG4CTN+1pnrSJQJ/8rcUfoHVKk6CSQuJFs | 76O0ZwCY6vWVLCfq0doXOdQiHUEG3ASwgn7pWq/nHqV6tRzkMT4I9KW8t7sYKXZ1 | qOJqb0eEst3vcEx1qbVZUzugHd5jb7EIGCIKLhyvpntUmZTD2MbjhkFelsDIoJzL | nhxR5Cr7nmCBZRBy7c2/zVelwruG4wGT5S2CvlrcdzxTDkJXS/mIs9h3sfJNo9zr | hp3xiDENIl1nrS/KPqNqtvxY8CukxFyq/wV12B4FCVrxia3kYVdKWqlxBrzEZkhI | Sy//OITpWE/1Gq5VASsVDInED418dZWfUf1K9jG3icr7fGGBpEUgs2/agK4viHt7 | szpbB6HjyYRBYPgjDGwLOBuVy2X4ZZ2AU7tUpJjlRxCSyL+ydG91DPKkSIt/psVq | FchXVXl86bYa29fe5mr0nxpNJpbVXPkEppQK5Dyhr+3tc34xKoVwHa7haSbYGPpX | QQDJUBIcf9xsi74prB/gUFOSmVCkqIhqgNCl3/+ZbaOTsZPN47DOP0jZcfwJQ8/E | 8OLVx+FD83oJQPolK+VS5kfoG1a1z4rTs3YBzL2W1blogxkrQhdBJZMEE+7Up3qb | ZNK+f5eQVrViW7xcuSHyg3PIp0SRSI23MokBHwQYAQgACQUCVxs46gIbDAAKCRDO | CeBVbCyM4FaXCACEeFic9K9Qc1yuUHnGterMCl2r91EoItpE3JNzTMN7PWCxS2ZR | giIDb/CPwCaVs6LVpd4GISiEbZGWpnouYPO+mWNgJYjbEKn5Pkr+3vEG1zR+hqi9 | mJPtHbqwGJh9Sd0Jn9z/qmwyfxBcnuhQYsFSzcsRrLQuuhWcuR/wqXb9GkbnI/jP | 5KXU3ccUbmaQEHClnB7s+3QlgimQdDxKcmfPTaC0eRSQHcwLJYpDGThQ9WcnqWMg | 2cnxhESZpJV/5q1xafSN7V20dxNrtdwMO28DB3Id+0d274/iXkhWDer4J0wEXrVc | 3fxXttLQdSgECaB76fxdswmlZOrKH5nyZIvw | =1JtY | -----END PGP PRIVATE KEY BLOCK----- | gpg: DBG: iobuf-1.0: close 'file_filter(fd)' | gpg: DBG: [not enabled in the source] stop | gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 | outmix=0 getlvl1=0/0 getlvl2=0/0 | gpg: secmem usage: 0/32768 bytes in 0 blocks | | d:\gpg> From rjh at sixdemonbag.org Thu May 5 02:09:42 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 4 May 2016 20:09:42 -0400 Subject: Attempted extortion of Enigmail In-Reply-To: <20160504223930.2AECA103437@mail2.openmailbox.org> References: <20160504223930.2AECA103437@mail2.openmailbox.org> Message-ID: <6ce01567-12f6-9df0-d230-e87396151aa4@sixdemonbag.org> I just received this at my Enigmail address. I'm posting this publicly because I side with Rudyard Kipling, who wrote: "And that is called paying the Dane-geld; But we've proved it again and again, That if once you have paid him the Dane-geld You never get rid of the Dane!" There's a 99% chance this threat is empty. If a miracle happens and these people are actually capable of making good on their threat, the Enigmail web site/mailing lists may see some disruption -- but even if so, we'll be back afterwards. Don't fear. :) -------- Forwarded Message -------- Subject: DDOS ATTACK Date: Wed, 04 May 2016 18:39:26 -0400 From: Armada Collective To: rob at enigmail.net FORWARD THIS MAIL TO WHOEVER IS IMPORTANT IN YOUR COMPANY AND CAN MAKE DECISION! We are Armada Collective. http://lmgtfy.com/?q=Armada+Collective Your network will be DDoS-ed starting 12:00 UTC on 08 May 2016 if you don't pay protection fee - 10 Bitcoins @ [omitted] If you don't pay by 12:00 UTC on 08 May 2016, attack will start, yours service going down permanently price to stop will increase to 20 BTC and will go up 10 BTC for every day of attack. This is not a joke. Our attacks are extremely powerful - sometimes over 1 Tbps per second. And we pass CloudFlare and others remote protections! So, no cheap protection will help. Prevent it all with just 10 BTC @ [omitted] Do not reply, we will not read. Pay and we will know its you. AND YOU WILL NEVER AGAIN HEAR FROM US! Bitcoin is anonymous, nobody will ever know you cooperated. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: OpenPGP digital signature URL: From pete at heypete.com Thu May 5 01:17:34 2016 From: pete at heypete.com (Pete Stephenson) Date: Thu, 5 May 2016 01:17:34 +0200 Subject: managing OpenPGP cards in batch mode? In-Reply-To: <4dc839d7-98c0-f65b-7550-ec8c96c7be9d@sixdemonbag.org> References: <5728A1CF.6090807@pocock.pro> <5728EBDE.1020608@pocock.pro> <5729C2DC.9000807@digitalbrains.com> <87r3dix7rq.fsf@wheatstone.g10code.de> <4dc839d7-98c0-f65b-7550-ec8c96c7be9d@sixdemonbag.org> Message-ID: On Thu, May 5, 2016 at 12:14 AM, Robert J. Hansen wrote: > Dashamir, this list has very few rules. I'm grateful for that, really. > One of the few rules that must be obeyed, though, is "we will not > advocate non-libre software or products here". Out of curiosity, where are these rules defined? The list information page doesn't make any mention of such a rule. Certainly, there are basic rules of netiquette that should ideally be universally known and followed (don't send spam, don't flame people, etc.), but "don't advocate non-libre software or products" isn't one of them. I understand wanting to keep discussions related to GnuPG and related subjects, so advocating or discussing third-party services may be considered off-topic, but you seem to be referring to a more specific rule. Cheers! -Pete -- Pete Stephenson From jhs at berklix.com Thu May 5 02:23:59 2016 From: jhs at berklix.com (Julian H. Stacey) Date: Thu, 05 May 2016 02:23:59 +0200 Subject: UK Investigatory Powers Bill In-Reply-To: Your message "Wed, 04 May 2016 18:04:55 +0100." <1462381495.2764.63.camel@keith> Message-ID: <201605050024.u450NxmO017034@fire.js.berklix.net> > > > This UK legislation will have impact elsewhere. Too many wind mills, too little time ;-) - The world has excess ignorant "Regulate Crypto" politicians & & civil servants paid to push laws. - National cryptography vendors, systems houses, banks etc may have more commercial interest to fund lobbying against local ignorant politicians. - International source groups have few people per country, None paid to waste time begging to educate ignorant politicians within their deadlines & foreign procedures. - Only laws that may motivate most global source developers will be those of countries of passport, residence, mail list server & source repository. Leaving 190 countries each will ignore. Inefficient to try to explain tech. to politicians ? Quicker to tell them: They will cripple & expose their country: International groups will ignore their laws, & continue development. Only their country's nationals will be crippled, out competed by rest of world's industries, banks, even industrial spies, international crackers, terrorists on net, & local criminals will All have better encryption than their local law restricted citizens. Even the USA failed to enforce Clipper or restrict international encryption: Dept of Commerce chased a crypt cat out of the bag for a decade, & failed. (USA munitions law, Crypt.c, freebsd.org, South African source repository.) Best spend time protecting source projects, - Insufficient resources to fight a globe of ignorant politicians, so best structure projects so no few countries can cripple development. - eg mirrors in several countries & regions, with backups, so if server master has legal or net trouble, or a regional geographic incident, people can switch to another server in another country & region. - Individuals could also quietly offer logins to developers in other countries (so if one day a developers' country implements a law restricting export of code, next edit is done via ssh & vi in your country not theirs, so no file ever needs to be exported (aka USA munitions law). Cheers, Julian -- Julian Stacey, BSD Linux Unix Sys Eng Consultant Munich http://berklix.eu/jhs/ Mail plain text, No quoted-printable, HTML, base64, MS.doc. Prefix old lines '> ' Reply below old, like play script. Break lines by 80. Brexit: Meeting +UK blocks votes of Brits in EU http://www.berklix.eu/brexit/ From rjh at sixdemonbag.org Thu May 5 02:32:53 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 4 May 2016 20:32:53 -0400 Subject: Attempted extortion of Enigmail In-Reply-To: <6ce01567-12f6-9df0-d230-e87396151aa4@sixdemonbag.org> References: <20160504223930.2AECA103437@mail2.openmailbox.org> <6ce01567-12f6-9df0-d230-e87396151aa4@sixdemonbag.org> Message-ID: <5ce2cf18-7cf8-ae95-7d2a-6133edec8037@sixdemonbag.org> Paul Applegate was kind enough to point me at: https://blog.cloudflare.com/empty-ddos-threats-meet-the-armada-collective/ TL;DR version: there's no evidence these people can back up their threat with action, but they've still been making a ton of money from their victims. There are a lot of people who have paid out. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: OpenPGP digital signature URL: From dashohoxha at gmail.com Thu May 5 07:41:34 2016 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Thu, 5 May 2016 07:41:34 +0200 Subject: managing OpenPGP cards in batch mode? In-Reply-To: References: <5728A1CF.6090807@pocock.pro> <5728EBDE.1020608@pocock.pro> <5729C2DC.9000807@digitalbrains.com> <87r3dix7rq.fsf@wheatstone.g10code.de> <4dc839d7-98c0-f65b-7550-ec8c96c7be9d@sixdemonbag.org> Message-ID: On Thu, May 5, 2016 at 1:17 AM, Pete Stephenson wrote: > On Thu, May 5, 2016 at 12:14 AM, Robert J. Hansen > wrote: > > Dashamir, this list has very few rules. I'm grateful for that, really. > > One of the few rules that must be obeyed, though, is "we will not > > advocate non-libre software or products here". > > Out of curiosity, where are these rules defined? > > The list information page > doesn't make > any mention of such a rule. > > Certainly, there are basic rules of netiquette that should ideally be > universally known and followed (don't send spam, don't flame people, > etc.), but "don't advocate non-libre software or products" isn't one > of them. I understand wanting to keep discussions related to GnuPG and > related subjects, so advocating or discussing third-party services may > be considered off-topic, but you seem to be referring to a more > specific rule. > I agree with Pete (and Werner). This list is about help and discussion related to GnuPG. Everything else is off-topic (including this message). Thanks Pete. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Thu May 5 08:11:51 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 5 May 2016 02:11:51 -0400 Subject: managing OpenPGP cards in batch mode? In-Reply-To: References: <5728A1CF.6090807@pocock.pro> <5728EBDE.1020608@pocock.pro> <5729C2DC.9000807@digitalbrains.com> <87r3dix7rq.fsf@wheatstone.g10code.de> <4dc839d7-98c0-f65b-7550-ec8c96c7be9d@sixdemonbag.org> Message-ID: <23cb7ee3-5dcf-044b-2602-2380f0edbae5@sixdemonbag.org> > Out of curiosity, where are these rules defined? The Free Software Foundation requires them for all FSF-sponsored mailing lists. Thou Shalt Not Advocate Proprietary Software. I wish I had a link but I don't -- I was told about this Thou Shalt Not Advocate Proprietary Software rule by a member of FSF, it wasn't something I saw on a webpage. I disagree with the FSF's rules, but so long as I'm on an FSF list I abide by them. From jnxx at posteo.net Thu May 5 10:28:09 2016 From: jnxx at posteo.net (Johannes Nix) Date: Thu, 5 May 2016 09:28:09 +0100 Subject: [tool / utility] check-trustpaths, a command-line tool for retrieving and checking chains of signatures in the web of trust In-Reply-To: <201605041626.14819.bernhard@intevation.de> References: <20160504091804.74f1212c@mangold.snakenest.scot> <201605041626.14819.bernhard@intevation.de> Message-ID: <20160505092809.00f7f3d1@mangold.snakenest.scot> Hello Bernhard, > I like the idea, I'll probably try it once I have a need for > the use case. Maybe you can add a link to your tool to > wiki.gnupg.org? Sure, if that's OK for a still somewhat experimental stage. > Did you consider pyme or > pygpgme? (See https://wiki.gnupg.org/APIs ) I did search for current gnupg Python bindings and thought that there ought to be a in-process solution, but have to confess that until three days ago, I wasn't even aware that both exist. > For a new application (which is not a module) I would directly > go to python3 and gpg2 only in order to easy future > maintenance. I started out with python2 because, having used it mainly for scientific computing, I am still more comfortable doing experimental stuff with it. But I agree for the long term and libraries being available, python3 is better. Johannes -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From Mrityunjay_Kumar03 at infosys.com Thu May 5 06:39:30 2016 From: Mrityunjay_Kumar03 at infosys.com (Mrityunjay Kumar03) Date: Thu, 5 May 2016 04:39:30 +0000 Subject: GNUPG Issues. Message-ID: <06927470d34f44739fdd2393091b1a8e@PUNITPMBX33.ad.infosys.com> Hi Team, On my application server GPG 1.2.1 is being used. Recently the keys expired on the server. We had to extend the expiry key which we did to 4 years. As the interfacing server also uses the same keys but different expiry dates, hence we only changed the expiry keys. Even after changing expiry key and setting the trust to ultimate we are having following error. gpg: : skipped: unusable public key gpg: : sign+encrypt failed: unusable public key Could anyone please help. Server version being used is Solaris 8. Regards, Mrityunjay Kumar ECSADMC - Telstra AUTOCAT & INOSS Support Mob. - +91 - 9561112969/9552551145 Desk - +91 - 2033712049 [cid:image001.png at 01D09701.F30FE110] [Infosys 20th year_Email Signature A-01] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 2080 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 12764 bytes Desc: image002.jpg URL: From gnupg at soondae.co.uk Thu May 5 12:33:34 2016 From: gnupg at soondae.co.uk (keith) Date: Thu, 05 May 2016 11:33:34 +0100 Subject: UK Investigatory Powers Bill In-Reply-To: <20160504234822.GA26696@davin.gbnet.net> References: <1462372698.2764.40.camel@keith> <20160504153049.GE8584@davin.gbnet.net> <1462381495.2764.63.camel@keith> <118570216.20160504231547@riseup.net> <20160504234822.GA26696@davin.gbnet.net> Message-ID: <1462444414.2792.12.camel@keith> On Thu, 2016-05-05 at 00:48 +0100, Steve Karmeinsky wrote: > On Wed, May 04, 2016 at 11:15:47PM +0100, MFPA wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > On Wednesday 4 May 2016 at 6:04:55 PM, in > > , keith wrote: > > > Personally I almost realise that > > > some of this may be > > > needed and/or indeed necessary > > By contrast, I am 100% certain that none of it is needed. If "the > > authorities" think they need access to some specific group or > > individual's communications, they can employ plain old-fashioned > > deception to have undercover agents worm their way in and get > > themselves trusted and included in the encryption list. > > Unfortunately it doesn't matter if it's needed, it's becoming law (well > it's already law under RIP, but DRIP 'expires' this year, so now > enshrined under IP Act). > > It's a blanked law to ensure what's being done already is now legalised. > > Steve > Ah well... As you suggest they are looking to legalise past actions and extend their capabilities in the future. http://services.parliament.uk/bills/2015-16/investigatorypowers/stages.html Resistance as they say is futile. The Public Bill Committee was 'loaded' in favour of the Government with any and all Opposition amendments being voted down. Basically it has gone through this stage without anything being changed. I do not see much hope for anything happening in The House of Lords or any time later so we are left with the ECtHR, Davis and Williams. I guess I look forward to receiving a 'Technical Capability Notice' in respect of my Raspberry PI e-mail server. Otherwise welcome to Full On Hard Core DPI across the whole of the UK that is going to affect all internal traffic and anything transiting the borders.... Not that you could trust them, or others, anyway but it might be time to set up BGP to steer all traffic away from DataStrip One. :-( Keith From andrewg at andrewg.com Thu May 5 13:01:45 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 5 May 2016 12:01:45 +0100 Subject: Hundreds of RSA keys factored In-Reply-To: References: <572A3E03.5050004@mailbox.org> Message-ID: <572B2819.5060303@andrewg.com> On 04/05/16 23:09, Robert J. Hansen wrote: >> There is this scary project listing several hundreds factored pgp/rsa >> keys: http://trilema.com/2016/the-phuctoring/ > > Not scary. Not all that interesting, either. Hanno B?ck has a fairly comprehensive response here: http://www.openwall.com/lists/oss-security/2016/05/05/7 tl;dr: they're mangled, useless copies of real pubkeys, and mangled keys will almost always be non-prime. A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From steve-gnupg at gbnet.net Thu May 5 13:53:41 2016 From: steve-gnupg at gbnet.net (Steve Karmeinsky) Date: Thu, 5 May 2016 12:53:41 +0100 Subject: UK Investigatory Powers Bill In-Reply-To: <1462444414.2792.12.camel@keith> References: <1462372698.2764.40.camel@keith> <20160504153049.GE8584@davin.gbnet.net> <1462381495.2764.63.camel@keith> <118570216.20160504231547@riseup.net> <20160504234822.GA26696@davin.gbnet.net> <1462444414.2792.12.camel@keith> Message-ID: <20160505115341.GB5440@davin.gbnet.net> On Thu, May 05, 2016 at 11:33:34AM +0100, keith wrote: > Otherwise welcome to Full On Hard Core DPI across the whole of the UK > that is going to affect all internal traffic and anything transiting the > borders.... Not that you could trust them, or others, anyway but it > might be time to set up BGP to steer all traffic away from DataStrip > One. Have a look on Google Streetview around Bude (in Cornwall), what was C&W land all their cables there (very pretty little cove, with a concrete hut at the top). 'Oddly' there's a GCHQ 'listening' station right next door and allegedly they don't even need to tap the cables, they're just given a splice. (Again allegedly) they have the capability to store 30 days worth of traffic while they do any analysis of stuff and can then move any interesting data elsewhere for further analysis. Already doing bulk intercept, now just legitimising it ... Steve -- NetTek Ltd UK mob +44 7775 755503 UK +44 20 3432 3735 / US +1 (650) 423 1390 / Fax +44 20 7483 2455 social id stevekennedyuk Euro Tech News Blog http://eurotechnews.blogspot.com From timog24 at mailbox.org Thu May 5 14:45:07 2016 From: timog24 at mailbox.org (Timo) Date: Thu, 5 May 2016 14:45:07 +0200 Subject: Hundreds of RSA keys factored In-Reply-To: <572B2819.5060303@andrewg.com> References: <572A3E03.5050004@mailbox.org> <572B2819.5060303@andrewg.com> Message-ID: <572B4053.2070007@mailbox.org> Thank you, that is pretty much what I wanted to know. The fact that the project hasn't responded by proving that they have the secret key of anyone demanding prove isn't really reassuring, although it might be the only thing to be sure. What had me worried most is the number of keys with nonprime values, as this is handled by the implementation. On 05/05/2016 01:01 PM, Andrew Gallagher wrote: > On 04/05/16 23:09, Robert J. Hansen wrote: >>> There is this scary project listing several hundreds factored pgp/rsa >>> keys: http://trilema.com/2016/the-phuctoring/ >> >> Not scary. Not all that interesting, either. > > Hanno B?ck has a fairly comprehensive response here: > > http://www.openwall.com/lists/oss-security/2016/05/05/7 > > tl;dr: they're mangled, useless copies of real pubkeys, and mangled keys > will almost always be non-prime. > > A > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From daniel at pocock.pro Thu May 5 16:02:01 2016 From: daniel at pocock.pro (Daniel Pocock) Date: Thu, 5 May 2016 16:02:01 +0200 Subject: managing OpenPGP cards in batch mode? In-Reply-To: <23cb7ee3-5dcf-044b-2602-2380f0edbae5@sixdemonbag.org> References: <5728A1CF.6090807@pocock.pro> <5728EBDE.1020608@pocock.pro> <5729C2DC.9000807@digitalbrains.com> <87r3dix7rq.fsf@wheatstone.g10code.de> <4dc839d7-98c0-f65b-7550-ec8c96c7be9d@sixdemonbag.org> <23cb7ee3-5dcf-044b-2602-2380f0edbae5@sixdemonbag.org> Message-ID: <572B5259.8010505@pocock.pro> On 05/05/16 08:11, Robert J. Hansen wrote: >> Out of curiosity, where are these rules defined? > > The Free Software Foundation requires them for all FSF-sponsored mailing > lists. Thou Shalt Not Advocate Proprietary Software. I wish I had a > link but I don't -- I was told about this Thou Shalt Not Advocate > Proprietary Software rule by a member of FSF, it wasn't something I saw > on a webpage. > > I disagree with the FSF's rules, but so long as I'm on an FSF list I > abide by them. > Oddly enough, making rules like that is technically restricting people's freedom to communicate. Restricting freedom to promote freedom is a dangerous game. There will always be people who are new to the community and don't appreciate the issues with Github (if you'll excuse the pun), I'm sure we can help explain in a friendly way without needing to resort to rules like these. If the same person repeatedly insists that Github is better than Gitlab, for example, that would be spamming. From wk at gnupg.org Thu May 5 17:17:15 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 05 May 2016 17:17:15 +0200 Subject: managing OpenPGP cards in batch mode? In-Reply-To: <23cb7ee3-5dcf-044b-2602-2380f0edbae5@sixdemonbag.org> (Robert J. Hansen's message of "Thu, 5 May 2016 02:11:51 -0400") References: <5728A1CF.6090807@pocock.pro> <5728EBDE.1020608@pocock.pro> <5729C2DC.9000807@digitalbrains.com> <87r3dix7rq.fsf@wheatstone.g10code.de> <4dc839d7-98c0-f65b-7550-ec8c96c7be9d@sixdemonbag.org> <23cb7ee3-5dcf-044b-2602-2380f0edbae5@sixdemonbag.org> Message-ID: <87twicttz8.fsf@wheatstone.g10code.de> On Thu, 5 May 2016 08:11, rjh at sixdemonbag.org said: > The Free Software Foundation requires them for all FSF-sponsored mailing > lists. Thou Shalt Not Advocate Proprietary Software. I wish I had a Well, this is not an FSF sponsored list. I never received any money or other resources from the FSF. Maybe others, but I doubnt that. The only exception may be that they paid me a flight and 3 nights in a shared hotel room in Tokyo in '99 - I gave a talk at their fund raising event. > link but I don't -- I was told about this Thou Shalt Not Advocate > Proprietary Software rule by a member of FSF, it wasn't something I saw I think this is a good rule in general because I started GnuPG as a replacement for its proprietary counterpart. I am not as strict as the Boston folks; so it is okay to speak about PGP etc. as long as it does not feel like advertising. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From peter at digitalbrains.com Thu May 5 17:52:26 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 5 May 2016 17:52:26 +0200 Subject: (OT) FSF involvement (was: managing OpenPGP cards in batch mode?) In-Reply-To: <87twicttz8.fsf@wheatstone.g10code.de> References: <5728A1CF.6090807@pocock.pro> <5728EBDE.1020608@pocock.pro> <5729C2DC.9000807@digitalbrains.com> <87r3dix7rq.fsf@wheatstone.g10code.de> <4dc839d7-98c0-f65b-7550-ec8c96c7be9d@sixdemonbag.org> <23cb7ee3-5dcf-044b-2602-2380f0edbae5@sixdemonbag.org> <87twicttz8.fsf@wheatstone.g10code.de> Message-ID: <572B6C3A.7030401@digitalbrains.com> On 05/05/16 17:17, Werner Koch wrote: > Well, this is not an FSF sponsored list. I never received any money or > other resources from the FSF. gnu.org lists GnuPG as a "GNU package", a part of the GNU Project. I kinda assumed that that would imply some form of involvement of the FSF in GnuPG... be that infrastructure or other support or whatnot... Also, similarly, I thought the mailing list infrastructure was shared with GnuTLS and that GnuTLS was a part of the GNU Project up till 2012? Or is the shared infra perhaps from after the split between GnuTLS and the FSF? Cheers, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From mike at confidantmail.org Thu May 5 22:59:10 2016 From: mike at confidantmail.org (Mike Ingle) Date: Thu, 05 May 2016 13:59:10 -0700 Subject: Batch key creation curve25519 not working in version 2.1.12 Windows Message-ID: <572BB41E.90503@confidantmail.org> GPG version 2.1.12 added support for Curve25519 sign and encrypt. I am trying to support such keys in Confidant Mail. Installed from gnupg-w32-2.1.12_20160504.exe If I create a key manually I get: GOOD pub ed25519/C850D9A5 2016-05-05 [SC] uid [ultimate] test 3 sub cv25519/22967908 2016-05-05 [E] which works, as the roles are properly assigned to the main and sub key. If I create one in batch mode I get: BAD pub ed25519/3CC6C1EC 2016-05-05 [SCA] uid [ultimate] t 3 sub cv25519/154B8241 2016-05-05 [] which cannot do anything because the roles are assigned wrong. The batch creation string I am using was initially: Key-Type: ecdsa Name-Real: t 4 Subkey-Curve: Curve25519 Subkey-Type: ecdh Name-Email: t at 4 Key-Curve: Ed25519 Key-Length: 255 %commit I also tried manually setting the roles, with no effect: Key-Type: ecdsa Name-Real: t 6 Subkey-Curve: Curve25519 Subkey-Usage: encrypt Subkey-Type: ecdh Name-Email: t at 6 Key-Curve: Ed25519 Key-Usage: sign Key-Length: 255 %commit This looks like a code problem. Any suggestions? Confidant Mail is a non-SMTP secure email system which supports large file attachments. https://www.confidantmail.org/ From daniel at hillsdalecorp.com Fri May 6 04:20:53 2016 From: daniel at hillsdalecorp.com (Daniel H. Werner) Date: Thu, 5 May 2016 19:20:53 -0700 Subject: Help needed - again Message-ID: It appears that I made a mess of my new install. I am on a Mac, running OS 10.11.4. I had been using PGP ( v9.7.1?) on a previous older Mac but, of course, that will not work on OS X. I downloaded the suite and did the install on my laptop (I did not want to try it on the desktop machine until I was sure I could do everything right). The Keychain was moved from my old machine to the new one. After the new install, I opened the GPG Keychain andI saw that I had a sec/pub key set dated 3 months ago. I assume I mistakenly created that set when I was trying earlier to install GPG. After getting some help from some of you, it appeared that the install was good. I could send an encrypted and signed message to myself and receive it. Feeling smug and on top of the world, I then sent my public key, dated in 2003, to a colleague with a request that he respond. He did and ? I cannot decrypt his message. I get a prompt telling me that my secret key is missing. I still have the previous/original secret and public keys. When I tried to Import them, I get a prompt telling me: "It seems that you're trying to import some non PGP related data that can't be processed." I do not know what to do now. Should I Uninstall everything, cancel/revoke all the keys and start over from scratch? Thank you everyone in advance, for your help. Daniel _______________________________ Daniel H. Werner, President Hillsdale Corporation 9 Oregon Yacht Club Portland, OR 97202 USA www.hillsdalecorp.com Cell: (503) 709-0950 Confidentiality Notice: The information contained in this e-mail is confidential and for the intended recipient(s) alone. It may contain privileged and confidential information and is covered by Non-Disclosure Agreements. If you are not an intended recipient, you must not copy, distribute or take any action in reliance on it. If you have received this e-mail in error, please notify us immediately. Thank You. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: HSDL_Logo_H.smjpg.jpg Type: image/jpeg Size: 8411 bytes Desc: not available URL: From wk at gnupg.org Fri May 6 08:12:09 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 06 May 2016 08:12:09 +0200 Subject: (OT) FSF involvement In-Reply-To: <572B6C3A.7030401@digitalbrains.com> (Peter Lebbing's message of "Thu, 5 May 2016 17:52:26 +0200") References: <5728A1CF.6090807@pocock.pro> <5728EBDE.1020608@pocock.pro> <5729C2DC.9000807@digitalbrains.com> <87r3dix7rq.fsf@wheatstone.g10code.de> <4dc839d7-98c0-f65b-7550-ec8c96c7be9d@sixdemonbag.org> <23cb7ee3-5dcf-044b-2602-2380f0edbae5@sixdemonbag.org> <87twicttz8.fsf@wheatstone.g10code.de> <572B6C3A.7030401@digitalbrains.com> Message-ID: <87eg9fu346.fsf@wheatstone.g10code.de> On Thu, 5 May 2016 17:52, peter at digitalbrains.com said: > kinda assumed that that would imply some form of involvement of the FSF > in GnuPG... be that infrastructure or other support or whatnot... The reason for not sharing mailing lists and web sites of GnuPG with other GNU projects is due to the (former) US export restrictions. > Or is the shared infra perhaps from after the split between GnuTLS and > the FSF? Right. Nikos asked whether gnupg can host the gnutls stuff after he got upset with the FSF. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From Alexander.Strobel at giepa.de Fri May 6 09:24:09 2016 From: Alexander.Strobel at giepa.de (Alexander Strobel) Date: Fri, 6 May 2016 09:24:09 +0200 Subject: Batch key creation curve25519 not working in version 2.1.12 Windows In-Reply-To: <572BB41E.90503@confidantmail.org> References: <572BB41E.90503@confidantmail.org> Message-ID: <572C4699.5030308@giepa.de> Am 05.05.2016 um 22:59 schrieb Mike Ingle: > If I create a key manually I get: > GOOD > pub ed25519/C850D9A5 2016-05-05 [SC] > uid [ultimate] test 3 > sub cv25519/22967908 2016-05-05 [E] > which works, as the roles are properly assigned to the main and sub key. > > If I create one in batch mode I get: > BAD > pub ed25519/3CC6C1EC 2016-05-05 [SCA] > uid [ultimate] t 3 > sub cv25519/154B8241 2016-05-05 [] > which cannot do anything because the roles are assigned wrong. Same here but with GPG 2.1.11 already. Using Brainpool curve it works as expected. Best regards Alex Strobel www.gpg4o.com From gniibe at fsij.org Fri May 6 10:58:06 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 6 May 2016 17:58:06 +0900 Subject: Batch key creation curve25519 not working in version 2.1.12 Windows In-Reply-To: <572BB41E.90503@confidantmail.org> References: <572BB41E.90503@confidantmail.org> Message-ID: <572C5C9E.6090709@fsij.org> On 05/06/2016 05:59 AM, Mike Ingle wrote: > Key-Type: ecdsa > Name-Real: t 6 > Subkey-Curve: Curve25519 > Subkey-Usage: encrypt > Subkey-Type: ecdh > Name-Email: t at 6 > Key-Curve: Ed25519 > Key-Usage: sign > Key-Length: 255 > %commit I got success with this: ---------------------------- Key-Type: eddsa Key-Curve: Ed25519 Key-Usage: sign Name-Real: Chuji Kunisada Name-Email: chuji at gniibe.org Subkey-Type: ecdh Subkey-Curve: Curve25519 Subkey-Usage: encrypt Expire-Date: 0 Passphrase: abcdef %commit %echo done ---------------------------- $ gpg2 --list-key chuji pub ed25519/3265921F 2016-05-06 [SC] uid [ultimate] Chuji Kunisada sub cv25519/7CB539CD 2016-05-06 [E] The Key-Type should be eddsa (not ecdsa). -- From wk at gnupg.org Fri May 6 11:29:51 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 06 May 2016 11:29:51 +0200 Subject: Batch key creation curve25519 not working in version 2.1.12 Windows In-Reply-To: <572C5C9E.6090709@fsij.org> (NIIBE Yutaka's message of "Fri, 6 May 2016 17:58:06 +0900") References: <572BB41E.90503@confidantmail.org> <572C5C9E.6090709@fsij.org> Message-ID: <8737pvsfe8.fsf@wheatstone.g10code.de> On Fri, 6 May 2016 10:58, gniibe at fsij.org said: > I got success with this: > ---------------------------- > Key-Type: eddsa To make this more clear: This is e*d*dsa and not e*c*dsa. The names are very similar but they are different algorithms. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From flapflap at riseup.net Fri May 6 15:22:52 2016 From: flapflap at riseup.net (flapflap) Date: Fri, 6 May 2016 13:22:52 +0000 Subject: (OT) FSF involvement In-Reply-To: <572B6C3A.7030401@digitalbrains.com> References: <5728A1CF.6090807@pocock.pro> <5728EBDE.1020608@pocock.pro> <5729C2DC.9000807@digitalbrains.com> <87r3dix7rq.fsf@wheatstone.g10code.de> <4dc839d7-98c0-f65b-7550-ec8c96c7be9d@sixdemonbag.org> <23cb7ee3-5dcf-044b-2602-2380f0edbae5@sixdemonbag.org> <87twicttz8.fsf@wheatstone.g10code.de> <572B6C3A.7030401@digitalbrains.com> Message-ID: <572C9AAC.1050608@riseup.net> Peter Lebbing: > On 05/05/16 17:17, Werner Koch wrote: >> Well, this is not an FSF sponsored list. I never received any money or >> other resources from the FSF. > > gnu.org lists GnuPG as a "GNU package", a part of the GNU Project. I > kinda assumed that that would imply some form of involvement of the FSF > in GnuPG... be that infrastructure or other support or whatnot... I might be wrong, but I thought that the "Thou Shalt Not Advocate Proprietary Software" rule is because of the rules for GNU Projects -- not because of the FSF. They are two different organisations for different purposes. Previously, I believed to have read these rules in the "Information for Maintainers of GNU Software" [0] but could not find it any more. ~flapflap [0] https://www.gnu.org/prep/maintain/maintain.html From flapflap at riseup.net Fri May 6 15:57:21 2016 From: flapflap at riseup.net (flapflap) Date: Fri, 6 May 2016 13:57:21 +0000 Subject: (OT) FSF involvement In-Reply-To: <572C9AAC.1050608@riseup.net> References: <5728A1CF.6090807@pocock.pro> <5728EBDE.1020608@pocock.pro> <5729C2DC.9000807@digitalbrains.com> <87r3dix7rq.fsf@wheatstone.g10code.de> <4dc839d7-98c0-f65b-7550-ec8c96c7be9d@sixdemonbag.org> <23cb7ee3-5dcf-044b-2602-2380f0edbae5@sixdemonbag.org> <87twicttz8.fsf@wheatstone.g10code.de> <572B6C3A.7030401@digitalbrains.com> <572C9AAC.1050608@riseup.net> Message-ID: <572CA2C1.9050907@riseup.net> flapflap: > Peter Lebbing: >> On 05/05/16 17:17, Werner Koch wrote: >>> Well, this is not an FSF sponsored list. I never received any money or >>> other resources from the FSF. >> >> gnu.org lists GnuPG as a "GNU package", a part of the GNU Project. I >> kinda assumed that that would imply some form of involvement of the FSF >> in GnuPG... be that infrastructure or other support or whatnot... > > I might be wrong, but I thought that the "Thou Shalt Not Advocate > Proprietary Software" rule is because of the rules for GNU Projects -- > not because of the FSF. They are two different organisations for > different purposes. > Previously, I believed to have read these rules in the "Information for > Maintainers of GNU Software" [0] but could not find it any more. I found it, finally, in the guidelines for becoming/submitting a GNU package [0]: "A GNU program should not recommend use of any non-free program, and it should not refer the user to any non-free documentation for free software." and "Since a GNU program is released under the auspices of GNU, it should not say anything that contradicts the GNU Project's views." IMHO, these are valid positions for a GNU Project. Non-free software is unjust, and thus, should not be recommended (including advertisement) -- unless a much higher good (e.g., life and limb after a catastrophe) than software freedom is in danger. As others have said earlier in this thread, it's fine to discuss non-free software by the above rules, but advertisement is not discussion. ~flapflap [0] https://www.gnu.org/help/evaluation.html From peter at digitalbrains.com Fri May 6 16:01:54 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 6 May 2016 16:01:54 +0200 Subject: (OT) FSF involvement In-Reply-To: <572C9AAC.1050608@riseup.net> References: <5728A1CF.6090807@pocock.pro> <5728EBDE.1020608@pocock.pro> <5729C2DC.9000807@digitalbrains.com> <87r3dix7rq.fsf@wheatstone.g10code.de> <4dc839d7-98c0-f65b-7550-ec8c96c7be9d@sixdemonbag.org> <23cb7ee3-5dcf-044b-2602-2380f0edbae5@sixdemonbag.org> <87twicttz8.fsf@wheatstone.g10code.de> <572B6C3A.7030401@digitalbrains.com> <572C9AAC.1050608@riseup.net> Message-ID: <572CA3D2.1030300@digitalbrains.com> On 06/05/16 15:22, flapflap wrote: > Previously, I believed to have read these rules in the "Information for > Maintainers of GNU Software" [0] but could not find it any more. Perhaps chapter 13: [1] > A GNU package should not recommend use of any non-free program, nor should > it require a non-free program (such as a non-free compiler or IDE) to build. Furtheron it says: > Please don?t host discussions about your package in a service that requires > nonfree software. For instance, Google+ "communities" require running a > nonfree JavaScript program to post a message, so they can?t be used in the > Free World. Google Groups has the same problem. To host discussions there > would be excluding people who live by free software principles. > > Of course, you can?t order people not to use such services to talk with each > other. What you can do is not legitimize them, and use your influence to lead > people away from them. For instance, where you say where to have discussions > related to the program, don?t list such a place. You could consider promoting non-free services on the mailing list a form of "legitimiz[ing] them" and the fact that it is not allowed here "us[ing] your influence to lead people away from them". Still, the way Werner phrased it: > I think this is a good rule in general because I started GnuPG as a > replacement for its proprietary counterpart. I am not as strict as the > Boston folks; so it is okay to speak about PGP etc. as long as it does > not feel like advertising. Combined with the earlier part of that mail, it doesn't sound to me like he is doing this to conform to some rule from the FSF or the GNU Project. Anyway, thanks for pointing us to a written source of the "FSF does not want this" rule I had never seen written down before! Cheers, Peter. PS: I converted the curly quotes from the gnu.org quote to straight quotes since we're talking about netiquette and some don't like non-ASCII ;-). [1] https://www.gnu.org/prep/maintain/maintain.html#Ethical-and-Philosophical-Consideration -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From youcanlinux at gmail.com Fri May 6 16:12:39 2016 From: youcanlinux at gmail.com (Daniel Villarreal) Date: Fri, 6 May 2016 10:12:39 -0400 Subject: (OT) FSF involvement In-Reply-To: <572CA2C1.9050907@riseup.net> References: <5728A1CF.6090807@pocock.pro> <5728EBDE.1020608@pocock.pro> <5729C2DC.9000807@digitalbrains.com> <87r3dix7rq.fsf@wheatstone.g10code.de> <4dc839d7-98c0-f65b-7550-ec8c96c7be9d@sixdemonbag.org> <23cb7ee3-5dcf-044b-2602-2380f0edbae5@sixdemonbag.org> <87twicttz8.fsf@wheatstone.g10code.de> <572B6C3A.7030401@digitalbrains.com> <572C9AAC.1050608@riseup.net> <572CA2C1.9050907@riseup.net> Message-ID: <8eaa2ae9-094d-df3c-79e9-51aabdf5bdbb@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 05/06/2016 09:57 AM, flapflap wrote: > flapflap: >> Peter Lebbing: >>> On 05/05/16 17:17, Werner Koch wrote: >>>> Well, this is not an FSF sponsored list. I never received >>>> any money or other resources from the FSF. >>> >>> gnu.org lists GnuPG as a "GNU package", a part of the GNU >>> Project. I kinda assumed that that would imply some form of >>> involvement of the FSF in GnuPG... be that infrastructure or >>> other support or whatnot... >> >> I might be wrong, but I thought that the "Thou Shalt Not >> Advocate Proprietary Software" rule is because of the rules for >> GNU Projects -- not because of the FSF. They are two different >> organisations for different purposes. Previously, I believed to >> have read these rules in the "Information for Maintainers of GNU >> Software" [0] but could not find it any more. > > I found it, finally, in the guidelines for becoming/submitting a > GNU package [0]: > > "A GNU program should not recommend use of any non-free program, > and it should not refer the user to any non-free documentation for > free software." > > and > > "Since a GNU program is released under the auspices of GNU, it > should not say anything that contradicts the GNU Project's views." > > IMHO, these are valid positions for a GNU Project. Non-free > software is unjust, and thus, should not be recommended (including > advertisement) -- unless a much higher good (e.g., life and limb > after a catastrophe) than software freedom is in danger. > > As others have said earlier in this thread, it's fine to discuss > non-free software by the above rules, but advertisement is not > discussion. > > ~flapflap > > [0] https://www.gnu.org/help/evaluation.html hey flapflap, I think you're onto something. I think people who care about open-source/libre software should carefully consider how they mention proprietary and/or non-free/non-libre software. I feel people can discuss almost anything if handled in a thoughtful, respectful manner. Maybe GNU people would consider touching on this topic at https://www.gnu.org/philosophy/words-to-avoid.html or some such page? At the same time, I wouldn't want a "Chilling effect" [1] [1] Dr.Ian Goldberg Battling Internet censorship and surveillance Privacy Enhancing Technologies for the Internet Cryptography, Security, and Privacy (CrySP) Research Group University Research Talk 18 February 2016 http://livestream.com/itmsstudio/events/4783392 University of Waterloo https://uwaterloo.ca/ - -- Daniel Villarreal http://www.youcanlinux.org youcanlinux at gmail.com PGP key 2F6E 0DC3 85E2 5EC0 DA03 3F5B F251 8938 A83E 7B49 https://pgp.mit.edu/pks/lookup?op=get&search=0xF2518938A83E7B49 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXLKZOAAoJEPJRiTioPntJ1RsH/1iYry6NPGyBNTtsR6lAa+cP TBFjEXjyL0rEaE/lAxyQUXTTOUK5IIdp32/AVgCxXgSq/+LLD2w5O5v1LauONOia O9oYgL5ik450ivP4xNzcwI7aHV5Azw9VoeAG2eLiwh6SG313rE2ubiIVz3dHmK5V PIALkjw+60hb8u4XvasUT6RzCrzssd2mkhXd2lJNsnUq276CefSe/pfXrG7YJIPg PgTWpE9gzZ+beUwb6SaAlrukzt5lmlrfaod/SkglOqg0+L07Gb3okPaLw8J34O4O nqzK5pWS4dxKoyGRerYEggdQqeESZvkliaOZvlJIJM2esV3+qD2JYoyWRzHWGck= =Sml3 -----END PGP SIGNATURE----- From dashohoxha at gmail.com Fri May 6 18:41:00 2016 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Fri, 6 May 2016 18:41:00 +0200 Subject: Speading up key generation Message-ID: Hi, We all know that generating new keys currently takes a lot of time, especially on headless environments. There are several suggestions on the internet about how to improve this, but most of them are criticized for making the security weaker (by lowering the quality of randomness that they generate). One of the suggestions is to use haveged[1]. I havn't seen any criticizm about it yet. Is it really safe? If yes, why it is not used by default in gpg? Because it indeed improves the time of key generation greatly. Peace, Dashamir P.s. I have started to play with the latest version of GnuPG (2.1) in Ubuntu-16.04, and I see lots of improvements compared to gnupg-2.0 Some of these improvements make obsolete some of the things that I have tried to fix with egpg, and this is great, because I don't want egpg to be a bloated bunch of scripts and tricks, I'd like it to be as lean as possible. [1]: http://www.issihosts.com/haveged/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Fri May 6 20:00:41 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 06 May 2016 20:00:41 +0200 Subject: (OT) FSF involvement In-Reply-To: <8eaa2ae9-094d-df3c-79e9-51aabdf5bdbb@gmail.com> (Daniel Villarreal's message of "Fri, 6 May 2016 10:12:39 -0400") References: <5728A1CF.6090807@pocock.pro> <5728EBDE.1020608@pocock.pro> <5729C2DC.9000807@digitalbrains.com> <87r3dix7rq.fsf@wheatstone.g10code.de> <4dc839d7-98c0-f65b-7550-ec8c96c7be9d@sixdemonbag.org> <23cb7ee3-5dcf-044b-2602-2380f0edbae5@sixdemonbag.org> <87twicttz8.fsf@wheatstone.g10code.de> <572B6C3A.7030401@digitalbrains.com> <572C9AAC.1050608@riseup.net> <572CA2C1.9050907@riseup.net> <8eaa2ae9-094d-df3c-79e9-51aabdf5bdbb@gmail.com> Message-ID: <87r3dfnk1i.fsf@wheatstone.g10code.de> On Fri, 6 May 2016 16:12, youcanlinux at gmail.com said: > proprietary and/or non-free/non-libre software. I feel people can > discuss almost anything if handled in a thoughtful, respectful manner. Take care ... Nobody expects the Free Software police! SCNR, Werner p.s Not my quote; I can't remember its origin, though. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mike at confidantmail.org Fri May 6 20:41:28 2016 From: mike at confidantmail.org (Mike Ingle) Date: Fri, 06 May 2016 11:41:28 -0700 Subject: Batch key creation curve25519 not working in version 2.1.12 Windows In-Reply-To: <572C5C9E.6090709@fsij.org> References: <572BB41E.90503@confidantmail.org> <572C5C9E.6090709@fsij.org> Message-ID: <572CE558.107@confidantmail.org> I tried my inputs with eddsa instead of ecdsa and it worked. Not sure if there is still a bug to report? Thank you for the workaround. On 5/6/2016 1:58 AM, NIIBE Yutaka wrote: > On 05/06/2016 05:59 AM, Mike Ingle wrote: > >> Key-Type: ecdsa >> Name-Real: t 6 >> Subkey-Curve: Curve25519 >> Subkey-Usage: encrypt >> Subkey-Type: ecdh >> Name-Email: t at 6 >> Key-Curve: Ed25519 >> Key-Usage: sign >> Key-Length: 255 >> %commit >> > > I got success with this: > ---------------------------- > Key-Type: eddsa > Key-Curve: Ed25519 > Key-Usage: sign > Name-Real: Chuji Kunisada > Name-Email: chuji at gniibe.org > Subkey-Type: ecdh > Subkey-Curve: Curve25519 > Subkey-Usage: encrypt > Expire-Date: 0 > Passphrase: abcdef > %commit > %echo done > ---------------------------- > > $ gpg2 --list-key chuji > pub ed25519/3265921F 2016-05-06 [SC] > uid [ultimate] Chuji Kunisada > sub cv25519/7CB539CD 2016-05-06 [E] > > > The Key-Type should be eddsa (not ecdsa). > From avi.wiki at gmail.com Fri May 6 20:31:38 2016 From: avi.wiki at gmail.com (Avi) Date: Fri, 6 May 2016 14:31:38 -0400 Subject: (OT) FSF involvement In-Reply-To: <87r3dfnk1i.fsf@wheatstone.g10code.de> References: <5728A1CF.6090807@pocock.pro> <5728EBDE.1020608@pocock.pro> <5729C2DC.9000807@digitalbrains.com> <87r3dix7rq.fsf@wheatstone.g10code.de> <4dc839d7-98c0-f65b-7550-ec8c96c7be9d@sixdemonbag.org> <23cb7ee3-5dcf-044b-2602-2380f0edbae5@sixdemonbag.org> <87twicttz8.fsf@wheatstone.g10code.de> <572B6C3A.7030401@digitalbrains.com> <572C9AAC.1050608@riseup.net> <572CA2C1.9050907@riseup.net> <8eaa2ae9-094d-df3c-79e9-51aabdf5bdbb@gmail.com> <87r3dfnk1i.fsf@wheatstone.g10code.de> Message-ID: On Friday, May 6, 2016, Werner Koch wrote: > > > Not my quote; I can't remember its origin, though. > Takeoff of Monty Python & Spanish Inquisition, perhaps? Avi -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Fri May 6 23:13:30 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 6 May 2016 17:13:30 -0400 Subject: GNUPG Issues. In-Reply-To: <06927470d34f44739fdd2393091b1a8e@PUNITPMBX33.ad.infosys.com> References: <06927470d34f44739fdd2393091b1a8e@PUNITPMBX33.ad.infosys.com> Message-ID: > Could anyone please help. Probably not. You're using a version of GnuPG that's 14 years old with many known bugs. Please upgrade to at least GnuPG 1.4. If the problem persists, we can probably help track down what's happening -- but our ability to help with GnuPG 1.2.1 is pretty minimal. From daniel at hillsdalecorp.com Sat May 7 01:59:32 2016 From: daniel at hillsdalecorp.com (Daniel H. Werner) Date: Fri, 6 May 2016 16:59:32 -0700 Subject: Help needed - again Message-ID: I sent the following message several days ago and am not sure it actually went. I am, therefore, sending it again. Thanks. It appears that I made a mess of my new install. I am on a Mac, running OS 10.11.4. I had been using PGP ( v9.7.1?) on a previous older Mac but, of course, that will not work on OS X. I downloaded the suite and did the install on my laptop (I did not want to try it on the desktop machine until I was sure I could do everything right). The Keychain was moved from my old machine to the new one. After the new install, I opened the GPG Keychain andI saw that I had a sec/pub key set dated 3 months ago. I assume I mistakenly created that set when I was trying earlier to install GPG. After getting some help from some of you, it appeared that the install was good. I could send an encrypted and signed message to myself and receive it. Feeling smug and on top of the world, I then sent my public key, dated in 2003, to a colleague with a request that he respond. He did and ? I cannot decrypt his message. I get a prompt telling me that my secret key is missing. I still have the previous/original secret and public keys. When I tried to Import them, I get a prompt telling me: "It seems that you're trying to import some non PGP related data that can't be processed." I do not know what to do now. Should I Uninstall everything, cancel/revoke all the keys and start over from scratch? Thank you everyone in advance, for your help. Daniel _______________________________ Daniel H. Werner, President Hillsdale Corporation 9 Oregon Yacht Club Portland, OR 97202 USA www.hillsdalecorp.com Cell: (503) 709-0950 Confidentiality Notice: The information contained in this e-mail is confidential and for the intended recipient(s) alone. It may contain privileged and confidential information and is covered by Non-Disclosure Agreements. If you are not an intended recipient, you must not copy, distribute or take any action in reliance on it. If you have received this e-mail in error, please notify us immediately. Thank You. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: HSDL_Logo_H.smjpg.jpg Type: image/jpeg Size: 8411 bytes Desc: not available URL: From gniibe at fsij.org Sat May 7 04:12:39 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Sat, 7 May 2016 11:12:39 +0900 Subject: Batch key creation curve25519 not working in version 2.1.12 Windows In-Reply-To: <572CE558.107@confidantmail.org> References: <572BB41E.90503@confidantmail.org> <572C5C9E.6090709@fsij.org> <572CE558.107@confidantmail.org> Message-ID: <572D4F17.1060603@fsij.org> On 05/07/2016 03:41 AM, Mike Ingle wrote: > I tried my inputs with eddsa instead of ecdsa and it worked. Not sure if > there is still a bug to report? > Thank you for the workaround. No, it's not a workaround. It is the correct way to specify the algorithm. Well, my description in the previous mail had been bad. Let me explanation in detail. In the (forthcoming) OpenPGP standard, we will have a specification for new key with EdDSA, which has its own algorithm number (= 22). New algorithm number is required because it's a different thing. Not only the curve is different, but also the algorithm is different. On the other hand, Curve25519 ECDH encryption is considered as an extension of existing algorighm of ECDH with the specific curve. Theoretically speaking, we could consider ECDSA with the curve of Ed25519. If people really wanted to use it, I'd say, it would be a bug of GnuPG. The priority of fixing this (as a bug) is not that high, though. -- From caro at nymph.paranoici.org Sat May 7 12:59:14 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Sat, 7 May 2016 10:59:14 +0000 (UTC) Subject: 'No pinentry' error (--pinentry-mode loopback with --delete-secret-and-public-key) References: <20160504225534.2DFAC101222B@remailer.paranoici.org> Message-ID: <20160507105914.45E761031C14@remailer.paranoici.org> Hello, on Wed, 4 May 2016 22:55:34 +0000 (UTC), I wrote: >I need help with GnuPG 2.1.12 migrating an encryption tool from 1.4.20. > >I'm trying to run the --delete-secret-and-public-key command with the >passphrase entered through stdin, which doesn't get activated ('delete >key failed: No pinentry'). With --export-secret-keys I was successful >this way (also added below). Or can I use --passphrase somehow? Nobody here with an idea how to solve my problem, to tell me whether a GnuPG bug prevents success or if it's worth to keep on trying? I once thought '--pinentry-mode loopback' is kinda compatibility mode to simplify transition from 1.4 and allow embedded usage. I'm stuck. Caro From dashohoxha at gmail.com Sat May 7 14:18:39 2016 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Sat, 7 May 2016 14:18:39 +0200 Subject: 'No pinentry' error (--pinentry-mode loopback with --delete-secret-and-public-key) In-Reply-To: <20160507105914.45E761031C14@remailer.paranoici.org> References: <20160504225534.2DFAC101222B@remailer.paranoici.org> <20160507105914.45E761031C14@remailer.paranoici.org> Message-ID: On Sat, May 7, 2016 at 12:59 PM, Carola Grunwald wrote: > Hello, > > on Wed, 4 May 2016 22:55:34 +0000 (UTC), I wrote: > > >I need help with GnuPG 2.1.12 migrating an encryption tool from 1.4.20. > > > >I'm trying to run the --delete-secret-and-public-key command with the > >passphrase entered through stdin, which doesn't get activated ('delete > >key failed: No pinentry'). With --export-secret-keys I was successful > >this way (also added below). Or can I use --passphrase somehow? > Have you tried: `gpg --batch --delete-secret-and-public-keys "fingerprint"` ? This works for me and it does not ask for a passphrase. Take care, Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad at fineby.me.uk Sat May 7 12:51:01 2016 From: brad at fineby.me.uk (Brad Rogers) Date: Sat, 7 May 2016 11:51:01 +0100 Subject: Help needed - again In-Reply-To: References: Message-ID: <20160507115101.19d555d1@abydos.stargate.org.uk> On Fri, 6 May 2016 16:59:32 -0700 Daniel H. Werner wrote: Hello Daniel, >I sent the following message several days ago and am not sure it Less than 24 hrs, according to time stamps. The list archives would show that the first copy was received. -- Regards _ / ) "The blindingly obvious is / _)rad never immediately apparent" You only see me for the clothes that I wear Public Image - Public Image Ltd -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From daniel at hillsdalecorp.com Sat May 7 17:20:25 2016 From: daniel at hillsdalecorp.com (Daniel Werner) Date: Sat, 7 May 2016 08:20:25 -0700 Subject: Help needed - again In-Reply-To: <20160507115101.19d555d1@abydos.stargate.org.uk> References: <20160507115101.19d555d1@abydos.stargate.org.uk> Message-ID: Thanks. I hope someone can tell me what I might be doing wrong. > On May 7, 2016, at 3:51 AM, Brad Rogers wrote: > > On Fri, 6 May 2016 16:59:32 -0700 > Daniel H. Werner wrote: > > Hello Daniel, > >> I sent the following message several days ago and am not sure it > > Less than 24 hrs, according to time stamps. The list archives would show > that the first copy was received. > > -- > Regards _ > / ) "The blindingly obvious is > / _)rad never immediately apparent" > You only see me for the clothes that I wear > Public Image - Public Image Ltd > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users ***************************** Daniel H. Werner Hillsdale Corporation 9 Oregon Yacht Club Portland, Oregon 97202 USA Cell: +1-503-709-0950 www.hillsdalecorp.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From caro at nymph.paranoici.org Sat May 7 17:32:13 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Sat, 7 May 2016 15:32:13 +0000 (UTC) Subject: 'No pinentry' error (--pinentry-mode loopback with --delete-secret-and-public-key) References: <20160504225534.2DFAC101222B@remailer.paranoici.org> <20160507105914.45E761031C14@remailer.paranoici.org> Message-ID: <20160507153213.30F5F1031C18@remailer.paranoici.org> Hello Dashamir, on Sat, 7 May 2016 14:18:39 +0200, you wrote: >On Sat, May 7, 2016 at 12:59 PM, Carola Grunwald >wrote: > >> Hello, >> >> on Wed, 4 May 2016 22:55:34 +0000 (UTC), I wrote: >> >> >I need help with GnuPG 2.1.12 migrating an encryption tool from 1.4.20. >> > >> >I'm trying to run the --delete-secret-and-public-key command with the >> >passphrase entered through stdin, which doesn't get activated ('delete >> >key failed: No pinentry'). With --export-secret-keys I was successful >> >this way (also added below). Or can I use --passphrase somehow? >> > >Have you tried: `gpg --batch --delete-secret-and-public-keys "fingerprint"` >? >This works for me and it does not ask for a passphrase. > >Take care, >Dashamir Thanks for your reply. You're right, there's no passphrase request with | d:\gpg>gpg.exe --batch --homedir "d:\gpgdat" --no-auto-key-locate --no-default-keyring --keyring "d:\gpgdat\pubring.kbx" --delete-secret-and-public-key "66C040ADBE2C5728022F81DCCE09E0556C2C8CE0" But that way a 'Pinentry' window opens, which I have to avoid: | Pinentry | | Do you really want to permanently delete the | OpenPGP secret key: | "John Doe " | 2048-bit RSA key, ID 6C2C8CE0, | created 2016-04-23. | ? | | [ Delete key ] [ No ] followed by | Pinentry | | Do you really want to permanently delete the | OpenPGP secret subkey key: | "John Doe " | 2048-bit RSA key, ID 174B70A0, | created 2016-04-23 (main key ID 6C2C8CE0). | ? | | [ Delete key ] [ No ] Kind regards Caro From rick at openfortress.nl Sat May 7 12:20:28 2016 From: rick at openfortress.nl (Rick van Rein) Date: Sat, 07 May 2016 12:20:28 +0200 Subject: Speading up key generation In-Reply-To: References: Message-ID: <572DC16C.5050100@openfortress.nl> Hi Dashamir, Thanks for pointing to HAVEG(E), it was a new approach to me. > One of the suggestions is to use haveged[1]. I don't think you meant to suggest this HAVEGE implementation [1] -- which is a PRNG based on the entrope of HAVEG -- but wanted to point out a HAVEG implementation instead, right? [1] http://www.issihosts.com/haveged/ > I havn't seen any criticizm > about it yet. Is it really safe? Then let me be the first ;-) There is no really solid basis for the entropy measured; it is suggestively shown (which the authors say in their ACM paper [2]) on statistical tests which are known to not provide certainty about the randomness of the sequence. [2] http://www.irisa.fr/caps/projects/hipsor/publi.php The guessed #bits per interrupt is rather high (8-64 kB) but this would depend heavily on CPU architecture. This means that there is no reliable manner of having a portable implementation of HAVEG. I also have my doubts if they actually collect this much information -- as they are only looking at the CPU counter as a summary of the complex internal CPU state. Different states will inevitably merge into similar measurements, and there's probably a probabilistic distribution for measurements -- which the statistical tests might even show if they had been tailored to the chunk size of these measurements, and when the measurements hadn't been shuffled in a PRNG-ish style. The paper could (and therefore should) have taken away this concern, IMHO. Finally, I'm afraid that this algorithm might have solid fixpoints, namely when an interrupt flushes all the state of the CPU. I do like the idea of harvesting CPU-internal data, but do not feel free of worries about this implementation style. There should be a more accurate model of its entropy before I'd trust it. But once it has this, the principle might expand to include much more probably switches, such as through multiple processes or threading. > If yes, why it is not used by default in > gpg? As far as I'm concerned: (1) because key generation is a rare event and good entropy is worth waiting for in these special circumstances, and (2) because this may not work as reliably as possible on a system that is booting in a reliable manner, especially from a relatively simple CPU (perhaps MIPS or ARM). > Because it indeed improves the time of key generation greatly. > IMHO, this time is much less important than properly generating the keys that you are (often) going to rely on for years. If you want a speedup, you might look into key generation/signing algorithms, such as ECDSA. They need less randomness and should (in theory) be faster to generate keys from. I'm curious if anyone has different opinions on this! Cheers, -Rick From dougb at dougbarton.email Sun May 8 05:55:53 2016 From: dougb at dougbarton.email (Doug Barton) Date: Sat, 7 May 2016 20:55:53 -0700 Subject: Evangelzation discussion :Was [Re: making a Debian Live CD for managing GnuPG master key and smartcards] In-Reply-To: References: <571F1E62.30203@pocock.pro> <571F51DA.8060809@digitalbrains.com> <67a964a0-28b3-92f4-e8eb-ab2b4e0c45da@broadcom.com> <571FD4D9.90706@sixdemonbag.org> Message-ID: <572EB8C9.1030002@dougbarton.email> On 04/26/2016 02:40 PM, Bob (Robert) Cavanaugh wrote: > New thread for this topic... For what it's worth, you didn't actually do that. What you did was to change the subject line of your reply. For those of us who use mail readers that actually thread, your message still appears under the original thread. From dougb at dougbarton.email Sun May 8 06:11:22 2016 From: dougb at dougbarton.email (Doug Barton) Date: Sat, 7 May 2016 21:11:22 -0700 Subject: making a Debian Live CD for managing GnuPG master key and smartcards In-Reply-To: <571F6F2D.7080507@sixdemonbag.org> References: <571F1E62.30203@pocock.pro> <571F51DA.8060809@digitalbrains.com> <571F648C.5090504@digitalbrains.com> <571F6F2D.7080507@sixdemonbag.org> Message-ID: <572EBC6A.8030205@dougbarton.email> On 04/26/2016 06:37 AM, Robert J. Hansen wrote: > I've looked over your egpg code. My bloodless technical evaluation is > simple: "it is nowhere near ready for production environments." And I > think if you read over the other technical criticisms you've received, > you'll see this is pretty much a consensus opinion. +1 on all counts. FWIW, Doug From rjh at sixdemonbag.org Sun May 8 06:53:42 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 8 May 2016 00:53:42 -0400 Subject: Help needed - again In-Reply-To: References: Message-ID: > I am, therefore, sending it again. I've been hoping someone else would tackle this, since I'm not particularly well-versed in PGP for OS X. I do run GnuPG on OS X, though, so maybe I can be of some assistance. I'm going to be posing a lot of questions here, but they're all rhetorical -- they're meant to illuminate some of the open questions, not things to respond to right away. At the end of this message I'll repeat these questions, and give steps that you can follow which will help reach answers. > I am on a Mac, running OS 10.11.4. My laptop's 10.11 as well, so my experience should be applicable to yours. > I had been using PGP ( v9.7.1?) on a previous older Mac but, of course, > that will not work on OS X. Symantec sells a 10.x version which worked with OS X -- at least, a previous version of OS X (I haven't checked past 10.8). If GnuPG fails to work out for you, you may want to consider that. I don't advocate it as a first option, though: let's see if we can resolve your problem. :) > I downloaded the suite and did the install on my laptop (I did not want Which suite? Several different groups package GnuPG for OS X. * Macports * Homebrew * Fink * GPGTools * GPGOSX Without knowing precisely what package you installed, my advice here will have to be general. > The Keychain was moved from my old machine to the new one. PGP stores its public and secret keys in two files called "pubring.pkr" and "secring.skr". These are not stored on the Apple Keychain. Did you migrate the pubring.pkr and secring.skr files, or did you migrate the Apple Keychain? > I assume I mistakenly created that set when I was > trying earlier to install GPG. Do you recognize the certificate ID associated with this set? > After getting some help from some of you, it appeared that the install > was good. I could send an encrypted and signed message to myself and > receive it. Which certificate did you use to encrypt to yourself? The one you found which you believe was mistakenly created, or your certificate from 2003? > He did and ? I cannot decrypt his message. How do you know that he used your certificate to encrypt the message? Oftentimes, when we can't decrypt traffic sent to us, it's because the person sending us email used the wrong certificate. > I still have the previous/original secret and public keys. When I tried > to Import them, I get a prompt telling me: How are you trying to import them? And are you importing two files named "pubring.pkr" and "secring.skr", or something else? > I do not know what to do now. Should I Uninstall everything, > cancel/revoke all the keys and start over from scratch? It's hard to say right now. Let's try to get a firm handle on exactly what's going on before we take any drastic steps. :) * Which GnuPG suite did you install? This one should be fairly straightforward. If you don't remember offhand, look through your browser history. :) * Did you migrate an Apple Keychain, or a pubring.pkr/secring.skr file set? Open a Terminal window (Applications/Utilities/Terminal.app). At the prompt, which I'm going to assume is "$" (although it probably won't be), type: $ find ~ -name "*ring.?kr" When you respond to this email, include the output of this command, please. (You should, of course, first check to make sure you're not revealing any confidential information. This command is perfectly safe, but you shouldn't take my word for it.) * Is the certificate ID of the mystery certificate the same as that of your normal certificate? If you don't know your normal certificate's ID, then just answer "I don't know". It's okay. :) * Which certificate did you use to encrypt to yourself? Take the email that you could read and save it (in encrypted form) to your Desktop as "my_message.eml". From Terminal.app, run this: $ gpg -vvvv $HOME/Desktop/my_message.eml You'll get a ton of output. Copy-and-paste it into your response (after checking to make sure there's nothing confidential in there). * Which certificate did he use to encrypt his message to you? Take the email that you couldn't read and save it to your Desktop as "his_message.eml". From Terminal.app, run this: $ gpg -vvvv $HOME/Desktop/his_message.eml Copy-and-paste that into your response. ... Do all this, and we should be much better able to help you figure this thing out. :) From dashohoxha at gmail.com Sun May 8 08:10:47 2016 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Sun, 8 May 2016 08:10:47 +0200 Subject: OT egpg evaluation Message-ID: Starting an other topic. On Sun, May 8, 2016 at 6:11 AM, Doug Barton wrote: > On 04/26/2016 06:37 AM, Robert J. Hansen wrote: > >> I've looked over your egpg code. My bloodless technical evaluation is >> simple: "it is nowhere near ready for production environments." And I >> think if you read over the other technical criticisms you've received, >> you'll see this is pretty much a consensus opinion. >> > > +1 on all counts. > Thanks. Your opinion counts. There are two branches of egpg: gnupg-2.0 and gnupg-2.1 corresponding to the stable and modern versions of GnuPG. Are you sure you used the right branch for testing? Did you find any bugs? Or missing features? Or wrong features? Or is it totally a worthless idea. Well, the branch egpg/gnupg-2.1 is still in development and I agree with you on all counts. But the branch egpg/gnupg-2.0 is tested and documented and bug free (up to my knowledge). Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From dashohoxha at gmail.com Sun May 8 08:20:29 2016 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Sun, 8 May 2016 08:20:29 +0200 Subject: How to silence gpg Message-ID: > >* gpg: checking the trustdb *> >* gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model*> > It comes from gpg. I just pushed a fix for 2.1 toseilence it with --quiet. I still get that output even when using --quiet But maybe it is because I still have 2.1.11 (ubuntu 16.04) Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Sun May 8 09:56:56 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 8 May 2016 03:56:56 -0400 Subject: OT egpg evaluation In-Reply-To: References: Message-ID: > Or is it totally a worthless idea. I think this code, in its current form, is genuinely dangerous, and should not be recommended to anyone. > Are you sure you used the right branch for testing? I didn't test it. What I saw while reading your code gave me such the heebie-jeebies I *won't* test it -- that's how big some of the bugs are. Let's start with the very first function I inspected. I chose this function because it's short, simple, and hard to screw up: ===== gpg_send_keys() { is_true $SHARE || return gnupghome_setup gpg --keyserver "$KEYSERVER" --send-keys "$@" gnupghome_reset } ===== Okay, so to know if we can send keys successfully we have to know how gnupghome_setup works. Let's look at that (in auxiliary.sh). The first few lines are: ===== gnupghome_setup() { # ... workdir_make # ... } ===== So now we need to know if workdir_make (in platform.sh) can fail. I found workdir_make in platform.sh. Let's look at that one. ===== workdir_make() { [[ -z "$WORKDIR" ]] || return # ... trap workdir_clear INT TERM EXIT } ===== Whereupon my brow began to arch and I began to get a bad, bad feeling. You test if WORKDIR is set, but what if the user has already set WORKDIR for something else? What if the user has specified "export WORKDIR=/path/to/my/doctoral/thesis" in their startup file? This is not auspicious, but it might be understandable. Does the manpage warn the user about this? Searching through the manpage, there is no mention of WORKDIR. Moving on: the trap line means that when the script receives INT, TERM, or EXIT, workdir_clear gets called. So let's look at that. ===== workdir_clear() { [[ -n "$WORKDIR" ]] || return [[ -d "$WORKDIR" ]] && find "$WORKDIR" -type f -exec shred {} + [[ -d "$WORKDIR" ]] && rm -rf "$WORKDIR" unset WORKDIR } ===== And at that point I decided that I *will not* test this code. If WORKDIR is set in the user's environment before they start egpg, egpg will shred and rm -rf $WORKDIR. This could have terrifying consequences for my doctoral thesis, and even worse if someone has WORKDIR set to something like /. I found a potentially *system-destroying bug* in literally the *very first function I inspected*. I've been very circumspect in my criticisms until now, Dashamir, because I really want to encourage people to hack on things. But it took me under seven minutes to discover a bug that will destroy a user's hard drive, and that is not the sort of thing which inspires trust in your code. Now do you understand why so many people here are getting upset about you recommending this package for inclusion in live Debian images, recommending it to new users, etc.? From dashohoxha at gmail.com Sun May 8 10:16:23 2016 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Sun, 8 May 2016 10:16:23 +0200 Subject: OT egpg evaluation In-Reply-To: References: Message-ID: On Sun, May 8, 2016 at 9:56 AM, Robert J. Hansen wrote: > > I found a potentially *system-destroying bug* in literally the *very > first function I inspected*. I've been very circumspect in my > criticisms until now, Dashamir, because I really want to encourage > people to hack on things. But it took me under seven minutes to > discover a bug that will destroy a user's hard drive, and that is not > the sort of thing which inspires trust in your code. > You are absolutely right about it. Now that you point it out I see that it is wrong. Do you think that renaming "WORKDIR" to "EGPG_TMP_WORKDIR" would fix it? Well, you can say that there may be other bugs too. Let's fix them as well. I am not ashamed about this bug because I don't claim that I am an expert for everything. But I beleive that togather we can do a better job. Thanks, Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Sun May 8 10:48:27 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 8 May 2016 04:48:27 -0400 Subject: OT egpg evaluation In-Reply-To: References: Message-ID: <68b5b486-01fb-067f-5a4a-771eb13704d7@sixdemonbag.org> > Do you think that renaming "WORKDIR" to "EGPG_TMP_WORKDIR" would fix it? I have tried very hard to be polite in my criticisms, but you seem to be under the unreasonable belief that politeness means I am amenable to working with you on it. I do not want to be involved with this in any way, except as someone who has spoken out clearly about its flaws and your inability to write good code. I believe that anyone who gets involved in this is taking terrible chances with their reputation. And this is the last I will say on the matter. From dashohoxha at gmail.com Sun May 8 11:03:13 2016 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Sun, 8 May 2016 11:03:13 +0200 Subject: OT egpg evaluation In-Reply-To: <68b5b486-01fb-067f-5a4a-771eb13704d7@sixdemonbag.org> References: <68b5b486-01fb-067f-5a4a-771eb13704d7@sixdemonbag.org> Message-ID: On Sun, May 8, 2016 at 10:48 AM, Robert J. Hansen wrote: > > Do you think that renaming "WORKDIR" to "EGPG_TMP_WORKDIR" would fix it? > > I have tried very hard to be polite in my criticisms, but you seem to be > under the unreasonable belief that politeness means I am amenable to > working with you on it. > You (singular) are making the wrong assumption that by "you" and "togather" I mean only you as a person. I actually mean whoever wants to help, the community. (It is not your fault that English is flowed, I know.) I do not want to be involved with this in any way, except as someone who > has spoken out clearly about its flaws and your inability to write good > code. > I accept the second (my inability to write good code). I do not accept the first, you have not spoken clear enough. You have only shown one bug. Please show all the bugs that you are aware of. I would appreciate it (and all of us I think). I believe that anyone who gets involved in this is taking terrible > chances with their reputation. > OK, let's hope that somebody with no reputation and nothing to lose will have the kindness to be helpful. And this is the last I will say on the matter. > I appreciate it nonetheless. It was helpful. Peace, Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From dashohoxha at gmail.com Sun May 8 11:04:25 2016 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Sun, 8 May 2016 11:04:25 +0200 Subject: OT egpg evaluation In-Reply-To: <68b5b486-01fb-067f-5a4a-771eb13704d7@sixdemonbag.org> References: <68b5b486-01fb-067f-5a4a-771eb13704d7@sixdemonbag.org> Message-ID: > > Do you think that renaming "WORKDIR" to "EGPG_TMP_WORKDIR" would fix it? > I think that this is a better fix: https://github.com/dashohoxha/egpg/commit/ff331e1db8f28a9521c2603f84fde1c9412702bd -------------- next part -------------- An HTML attachment was scrubbed... URL: From flapflap at riseup.net Sun May 8 14:09:14 2016 From: flapflap at riseup.net (flapflap) Date: Sun, 8 May 2016 12:09:14 +0000 Subject: OT egpg evaluation In-Reply-To: References: Message-ID: <572F2C6A.1060300@riseup.net> Robert J. Hansen: > And at that point I decided that I *will not* test this code. If > WORKDIR is set in the user's environment before they start egpg, egpg > will shred and rm -rf $WORKDIR. This could have terrifying consequences > for my doctoral thesis, and even worse if someone has WORKDIR set to > something like /. > > I found a potentially *system-destroying bug* in literally the *very > first function I inspected*. I've been very circumspect in my > criticisms until now, Dashamir, because I really want to encourage > people to hack on things. But it took me under seven minutes to > discover a bug that will destroy a user's hard drive, and that is not > the sort of thing which inspires trust in your code. > > Now do you understand why so many people here are getting upset about > you recommending this package for inclusion in live Debian images, > recommending it to new users, etc.? Another thing I've seen by skimming through the sources are problems with input sanitisation: if the input (e.g., file name) starts with "-" or "--" it's interpreted as commands (for that reason, most unix tools accept a "--" argument to interpret all following args as input/file names, not as commands). I wasn't able to find a working shellcode injection though, but I also didn't look at it with much care. I really don't think that bash is the right language here... From peter at digitalbrains.com Sun May 8 14:30:45 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 8 May 2016 14:30:45 +0200 Subject: OT egpg evaluation In-Reply-To: <572F2C6A.1060300@riseup.net> References: <572F2C6A.1060300@riseup.net> Message-ID: <572F3175.20901@digitalbrains.com> On 08/05/16 14:09, flapflap wrote: > (for that reason, most unix tools > accept a "--" argument to interpret all following args as input/file > names, not as commands) This includes gpg2. The complexity of the gpg2 command line means some things require a good ordering of options and commands, while often unix tools will accept any ordering. But the convention that "--" means everything that follows is input is also observed by gpg2, at least in my quick check. The following two are decidedly different: $ gpg2 -o test.gpg -r de500b3e -e -s $ gpg2 -o test.gpg -r de500b3e -e -- -s The second uses the file named -s and doesn't sign. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From dashohoxha at gmail.com Sun May 8 14:54:56 2016 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Sun, 8 May 2016 14:54:56 +0200 Subject: OT egpg evaluation In-Reply-To: <572F2C6A.1060300@riseup.net> References: <572F2C6A.1060300@riseup.net> Message-ID: On Sun, May 8, 2016 at 2:09 PM, flapflap wrote: > > I really don't think that bash is the right language here... But if you want to automate some tasks on the command line, bash seems to be the perfect choice. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrewg at andrewg.com Sun May 8 22:39:48 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sun, 8 May 2016 21:39:48 +0100 Subject: OT egpg evaluation In-Reply-To: References: <572F2C6A.1060300@riseup.net> Message-ID: On 8 May 2016, at 13:54, Dashamir Hoxha wrote: > >> On Sun, May 8, 2016 at 2:09 PM, flapflap wrote: >> I really don't think that bash is the right language here... > > But if you want to automate some tasks on the command line, bash seems to be the perfect choice. By hand, yes. If you are constructing the algorithm yourself and have a reasonable expectation of the file names etc and are confident you won't hit any edge cases. If you're knocking something together for a particular purpose and don't mind picking up the pieces when it doesn't work exactly as you expected. But when you expect other people to use your code on machines you've never heard of and in contexts that you never anticipated, it's a whole order of magnitude more complicated. In particular, if your language of choice doesn't support an execve() equivalent (e.g. perl's open(,,,)), you're pretty much screwed before you start. Andrew Gallagher -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott at smemsh.net Mon May 9 01:14:09 2016 From: scott at smemsh.net (Scott Mcdermott) Date: Sun, 8 May 2016 16:14:09 -0700 Subject: how to configure default sign key for particular user? Message-ID: <20160508231409.GA24983@smemsh.net> I have multiple keys for the same userid. When using: gpg --sign --user email at address.foo gpg-2.1.11 is always choosing the wrong one. The 'default-key' setting is ignored (as documented) due to presence of '--user'. Does this mean there is no way to tell gpg to automatically sign with a particular key, unless I specify the actual keyid instead of the email? How can I configure the default signing key to use *for a given userid/address* (not just in unspecified case)? Otherwise, any application [which knows only username/email] has to be know also the specific keyid to override gpg's default selection (which I'm guessing is the first key in the keyring); this seems wrong, it should be configurable in gpg, just like it's configurable if no userid is given (i.e. default-key). (aside: the default key selected for a userid should probably be the later key anyways, I would think, under the assumption that one always want to use the newer key, not the oldest one.) -- Scott From 2014-667rhzu3dc-lists-groups at riseup.net Mon May 9 02:44:19 2016 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Mon, 9 May 2016 01:44:19 +0100 Subject: how to configure default sign key for particular user? In-Reply-To: <20160508231409.GA24983@smemsh.net> References: <20160508231409.GA24983@smemsh.net> Message-ID: <1829694350.20160509014419@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Monday 9 May 2016 at 12:14:09 AM, in , Scott Mcdermott wrote: > (aside: the default key selected for a userid should > probably be > the later key anyways, I would think, under the > assumption that > one always want to use the newer key, not the oldest > one.) That would enable a "denial of service" attack: I publish a key containing your email address in a UID, people encrypt to my newer key instead of your older key. - -- Best regards MFPA The second mouse gets the cheese -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJXL91kXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwwMsH/2QGOr1ZzEoPPnAPRtYMpmBT 13j04mdzM1NeXZdYu5DbAiHEN53RkweXzvc/hVMW/mqL4QNnCZM3EUAKBt7dGbEE LjIUm2t+63UPMWXiR86ymqAdpXARtYkgiiyR1QfwFrGYoBuTAD2lnlxnTgRTW3DB 04uerMOewvVFOwlzdhnOLupC0yVnm17Bfvq87DUREwIji30toQJW54nReWRkcLKl AQvldNVW61baBCUi7DMPGp4q3BlByUMWI+rNmnUSu8G55eAaCKi0GZZYf3vD1foA 48q8pxcUV4xEj14bEw4mZKaVdoKTp0C+KwDowrN47lqmvO857o1KL3ApeIwTYRWI vgQBFgoAZgUCVy/dZF8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45D5uAQCrSsxNXD3oPdqDZIsaVeqlfCpQ 43P8qUkZ/8QHydbjmAEAw6xKvZ8AsSQXljFFHjUsDYdBK1DZY6grJHuxdMiwTgU= =lpNo -----END PGP SIGNATURE----- From gniibe at fsij.org Mon May 9 03:34:22 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 9 May 2016 10:34:22 +0900 Subject: Speading up key generation In-Reply-To: <572DC16C.5050100@openfortress.nl> References: <572DC16C.5050100@openfortress.nl> Message-ID: <572FE91E.40504@fsij.org> On 05/07/2016 07:20 PM, Rick van Rein wrote: > I do like the idea of harvesting CPU-internal data, but do not feel free > of worries about this implementation style. There should be a more > accurate model of its entropy before I'd trust it. But once it has > this, the principle might expand to include much more probably switches, > such as through multiple processes or threading. [...] > I'm curious if anyone has different opinions on this! If there is no other sources, it is good to use haveged. I think that haveged implementations depends on CPU and something like High Precision Event Timer (HPET), but user would just use haveged with no HPET system, or even on a VM. While harvesting CPU-internal data is convenient, it would be controversial. It would be easier for attackers to maliciously control the key generation when it's not external source. I use my own TRNG for my key generation. Let's Make "NeuG USB Device" by STM32 Nucleo F103, together: http://www.fsij.org/gnuk/neug-on-stm32-nucleo-f103.html -- From rjh at sixdemonbag.org Mon May 9 04:12:11 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 8 May 2016 22:12:11 -0400 Subject: how to configure default sign key for particular user? In-Reply-To: <20160508231409.GA24983@smemsh.net> References: <20160508231409.GA24983@smemsh.net> Message-ID: > Otherwise, any application [which knows only username/email] has > to be know also the specific keyid to override gpg's default > selection (which I'm guessing is the first key in the keyring); > this seems wrong... It is wrong. You should file a bug with the software package which is mistakenly using UIDs as unique identifiers, as they are not. > it should be configurable in gpg Probably not. The bug is in the software package you're using, not GnuPG. Adding new features to a package to remedy the brokenness of another package is usually counterproductive. From bernhard at intevation.de Mon May 9 09:19:26 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 9 May 2016 09:19:26 +0200 Subject: [tool / utility] check-trustpaths, a command-line tool for retrieving and checking chains of signatures in the web of trust In-Reply-To: <20160505092809.00f7f3d1@mangold.snakenest.scot> References: <20160504091804.74f1212c@mangold.snakenest.scot> <201605041626.14819.bernhard@intevation.de> <20160505092809.00f7f3d1@mangold.snakenest.scot> Message-ID: <201605090919.30434.bernhard@intevation.de> Moin Johannes, [discussing https://github.com/jnxx/check-trustpaths ] Am Donnerstag, 5. Mai 2016 10:28:09 schrieb Johannes Nix: > > Maybe you can add a link to your tool to wiki.gnupg.org? > > Sure, if that's OK for a still somewhat experimental stage. yes, the wiki is also there for drafts and experimental content. When in doubt, just mark it as such. > > Did you consider pyme or > > pygpgme? (See https://wiki.gnupg.org/APIs ) > > I did search for current gnupg Python bindings and thought > that there ought to be a in-process solution, but > have to confess that until three days ago, > I wasn't even aware that both exist. BTW: That is one of the reasons for the wiki, we need to collect information together in a central place. There is so much interesting going on around GnuPG, but a lot of stuff is hard to find. Help on the wiki is always appreciated, this is a wiki for GnuPG users, developers and neighbouring Free Software initiatives. Just use your bugs.gnupg.org credentials. Best Regards, Bernhard -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 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: 473 bytes Desc: This is a digitally signed message part. URL: From scott at smemsh.net Mon May 9 21:08:49 2016 From: scott at smemsh.net (Scott Mcdermott) Date: Mon, 9 May 2016 12:08:49 -0700 Subject: how to configure default sign key for particular user? In-Reply-To: <1829694350.20160509014419@riseup.net> References: <20160508231409.GA24983@smemsh.net> <1829694350.20160509014419@riseup.net> Message-ID: <20160509190849.GA32656@smemsh.net> MFPA on 2016/05/09 +0100 @01:44:19: > > (aside: the default key selected for a userid should > > probably be the later key anyways, I would think, under the > > assumption that one always want to use the newer key, not > > the oldest one.) > > That would enable a "denial of service" attack: I publish a > key containing your email address in a UID, people encrypt to > my newer key instead of your older key. I'm talking about signing, not encrypting, which uses my own secret key, not a published key. -- Scott From scott at smemsh.net Mon May 9 21:28:46 2016 From: scott at smemsh.net (Scott Mcdermott) Date: Mon, 9 May 2016 12:28:46 -0700 Subject: how to configure default sign key for particular user? In-Reply-To: References: <20160508231409.GA24983@smemsh.net> Message-ID: <20160509192846.GB32656@smemsh.net> Robert J. Hansen on 2016/05/08 -0400 @22:12:11: > > Otherwise, any application [which knows only username/email] > > has to be know also the specific keyid to override gpg's > > default selection (which I'm guessing is the first key in > > the keyring); this seems wrong... > > It is wrong. You should file a bug with the software package > which is mistakenly using UIDs as unique identifiers, as they > are not. Any such application, and myself, would never claim that a userid was unique. A key is chosen if not specified; gpg already has an algorithm to do this. If it was wrong to choose a key, then gpg should bomb out if a uid is given instead of a full key id, and furthermore there should be no default-key configuration option at all. Instead, what it does is to select a key; probably, it uses the first key found in the keyring that matches the uid. > > it should be configurable in gpg > > Probably not. The bug is in the software package you're > using, not GnuPG. Adding new features to a package to remedy > the brokenness of another package is usually > counterproductive. There is a configurable 'default-key' already for a reason: to instruct gpg what to do if an application asks to sign something, but doesn't specify the userid at all. The information about default key preferences should be kept in gpg, not every single application. Here we have a case where *more* information is provided than none (which is the case when 'default-key' is used), i.e. userid, but less information is provided than the specific keyid. In such a case, a default should be configurable. Possibly, gpg could overload default-key based on how many args: default-key uid1 keyid1 default-key uid2 keyid2 default-key keyid3 If no userid is specified, keyid3 is chosen, otherwise the specified keyid is chosen. If an unconfigured uid is specified, the current algorithm is used (presumably first on keyring -- although I personally think this should be last on keyring for signing, but that's a separate matter). -- Scott From peter at digitalbrains.com Mon May 9 22:12:30 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 9 May 2016 22:12:30 +0200 Subject: how to configure default sign key for particular user? In-Reply-To: <20160509192846.GB32656@smemsh.net> References: <20160508231409.GA24983@smemsh.net> <20160509192846.GB32656@smemsh.net> Message-ID: <5730EF2E.5010902@digitalbrains.com> On 09/05/16 21:28, Scott Mcdermott wrote: > Possibly, gpg could overload default-key based on how many args: > > default-key uid1 keyid1 > default-key uid2 keyid2 > default-key keyid3 I think the configuration option "group" already covers your use case. In my gpg.conf: group peter=de500b3e group test=DCDFDFA4 Testing it: $ echo hi | gpg2 -u test -s|gpg2 hi gpg: Signature made Mon 09 May 2016 22:09:50 CEST using RSA key ID DCDFDFA4 [...] $ echo hi | gpg2 -u peter -s|gpg2 hi gpg: Signature made Mon 09 May 2016 22:10:14 CEST using RSA key ID DE6CDCA1 [...] Oh right, that's a bit unclear, DE6CDCA1 is a subkey of DE500B3E :-). HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Mon May 9 22:17:43 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 9 May 2016 22:17:43 +0200 Subject: how to configure default sign key for particular user? In-Reply-To: <5730EF2E.5010902@digitalbrains.com> References: <20160508231409.GA24983@smemsh.net> <20160509192846.GB32656@smemsh.net> <5730EF2E.5010902@digitalbrains.com> Message-ID: <5730F067.6060705@digitalbrains.com> On 09/05/16 22:12, Peter Lebbing wrote: > group peter=de500b3e > group test=DCDFDFA4 Crap. I did it wrong. It was a bit silly of me to choose group names that overlapped with the uid's! It doesn't work, I'm sorry. Okay, then maybe group could be accepted for -u (since multiple -u are allowed, it's not strange either). That would be a feature request. Hope that helps more than my previous message :), Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From daniel at hillsdalecorp.com Mon May 9 23:08:37 2016 From: daniel at hillsdalecorp.com (Daniel H. Werner) Date: Mon, 9 May 2016 14:08:37 -0700 Subject: Help needed - again In-Reply-To: References: Message-ID: <97F8AE3E-BA36-4E81-B7FD-23F06D553941@hillsdalecorp.com> Robert, Thanks you, in advance, for your help. I have to say here that I am more than a bit embarrassed because I seem to know so little about what I am doing. OK, here we go. First, I have 2 Macs, a laptop and an iMac. I am writing to you from the desktop and the laptop is right here on my desk for reference. As I said earlier, I want to get the laptop going first so that, perhaps, I will learn a thing to two that I can use to properly setup the desktop. Incidentally, I had tried to set up the desktop but, with all the difficulties I was having, I just Uninstalled GPG. > >> I downloaded the suite and did the install on my laptop (I did not want > > Which suite? Several different groups package GnuPG for OS X. > > * Macports > * Homebrew > * Fink > * GPGTools > * GPGOSX GPGTools, v2015.09 > > Without knowing precisely what package you installed, my advice here > will have to be general. > >> The Keychain was moved from my old machine to the new one. > > PGP stores its public and secret keys in two files called "pubring.pkr" > and "secring.skr". These are not stored on the Apple Keychain. Did you > migrate the pubring.pkr and secring.skr files, or did you migrate the > Apple Keychain? I moved: PGP Private Keyring.skr and PGP Public Keyring.pkr > Do you recognize the certificate ID associated with this set? I don?t know how/where to look. And I am not sure I would know what I was looking at. > >> After getting some help from some of you, it appeared that the install >> was good. I could send an encrypted and signed message to myself and >> receive it. > > Which certificate did you use to encrypt to yourself? The one you found > which you believe was mistakenly created, or your certificate from 2003? I believe it was the 03 version. > >> He did and ? I cannot decrypt his message. > > How do you know that he used your certificate to encrypt the message? > Oftentimes, when we can't decrypt traffic sent to us, it's because the > person sending us email used the wrong certificate. He said he used the key I sent to him. > >> I still have the previous/original secret and public keys. When I tried >> to Import them, I get a prompt telling me: > > How are you trying to import them? I put them on a USB flash drive from my old (G5) machine, plugged that flash drive into the laptop and hit Import in the GPG Keychain window. > > Open a Terminal window (Applications/Utilities/Terminal.app). At the > prompt, which I'm going to assume is "$" (although it probably won't > be), type: > > $ find ~ -name "*ring.?kr? I am obviously missing something here because I am getting ? nothing! > > When you respond to this email, include the output of this command, > please. (You should, of course, first check to make sure you're not > revealing any confidential information. This command is perfectly safe, > but you shouldn't take my word for it.) > > > > * Is the certificate ID of the mystery certificate the same as that of > your normal certificate? > > If you don't know your normal certificate's ID, then just answer "I > don't know". It's okay. :) Don?y know. > * Which certificate did you use to encrypt to yourself? > > Take the email that you could read and save it (in encrypted form) to > your Desktop as "my_message.eml?. I do not see the encrypted message. I see the message I just sent to myself. In the Header it says: Security: Encrypted, Signed (daniel at hillsdalecorp.com) > From Terminal.app, run this: > > $ gpg -vvvv $HOME/Desktop/my_message.eml Again, nothing! > ... Do all this, and we should be much better able to help you figure > this thing out. :) I hope, Robert, that my responses here are useful in developing the next step. Daniel _______________________________ Daniel H. Werner, President Hillsdale Corporation 9 Oregon Yacht Club Portland, OR 97202 USA www.hillsdalecorp.com Cell: (503) 709-0950 Confidentiality Notice: The information contained in this e-mail is confidential and for the intended recipient(s) alone. It may contain privileged and confidential information and is covered by Non-Disclosure Agreements. If you are not an intended recipient, you must not copy, distribute or take any action in reliance on it. If you have received this e-mail in error, please notify us immediately. Thank You. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: HSDL_Logo_H.smjpg.jpg Type: image/jpeg Size: 8411 bytes Desc: not available URL: From daniel at hillsdalecorp.com Mon May 9 23:34:40 2016 From: daniel at hillsdalecorp.com (Daniel H. Werner) Date: Mon, 9 May 2016 14:34:40 -0700 Subject: Help needed - again In-Reply-To: References: Message-ID: Robert, As I may have said earlier, it appears that I am not very bright. I looked again in the GPG Keyring and I see that my Public Key was created in 2000, using an old email address. Can I update the key with the new and current email address? If yes, how? _______________________________ Daniel H. Werner, President Hillsdale Corporation 9 Oregon Yacht Club Portland, OR 97202 USA www.hillsdalecorp.com Cell: (503) 709-0950 Confidentiality Notice: The information contained in this e-mail is confidential and for the intended recipient(s) alone. It may contain privileged and confidential information and is covered by Non-Disclosure Agreements. If you are not an intended recipient, you must not copy, distribute or take any action in reliance on it. If you have received this e-mail in error, please notify us immediately. Thank You. _______________________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: HSDL_Logo_H.smjpg.jpg Type: image/jpeg Size: 8411 bytes Desc: not available URL: From dashohoxha at gmail.com Tue May 10 04:17:07 2016 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Tue, 10 May 2016 04:17:07 +0200 Subject: 'No pinentry' error (--pinentry-mode loopback with --delete-secret-and-public-key) In-Reply-To: <20160507153213.30F5F1031C18@remailer.paranoici.org> References: <20160504225534.2DFAC101222B@remailer.paranoici.org> <20160507105914.45E761031C14@remailer.paranoici.org> <20160507153213.30F5F1031C18@remailer.paranoici.org> Message-ID: On Sat, May 7, 2016 at 5:32 PM, Carola Grunwald wrote: > > You're right, there's no passphrase request with > > | d:\gpg>gpg.exe --batch --homedir "d:\gpgdat" --no-auto-key-locate > --no-default-keyring --keyring "d:\gpgdat\pubring.kbx" > --delete-secret-and-public-key "66C040ADBE2C5728022F81DCCE09E0556C2C8CE0" > > But that way a 'Pinentry' window opens, which I have to avoid: > > | Pinentry > | > | Do you really want to permanently delete the > | OpenPGP secret key: > | "John Doe " > | 2048-bit RSA key, ID 6C2C8CE0, > | created 2016-04-23. > | ? > | > | [ Delete key ] [ No ] > > followed by > > | Pinentry > | > | Do you really want to permanently delete the > | OpenPGP secret subkey key: > | "John Doe " > | 2048-bit RSA key, ID 174B70A0, > | created 2016-04-23 (main key ID 6C2C8CE0). > | ? > | > | [ Delete key ] [ No ] > I agree, this is anoying. And the docs say that with --batch and --yes and "fingerprint" no questions will be asked (this is the meaning of batch after all). But I just realized that you can delete everything on "$GNUPGHOME/private-keys-v1.d/" and all the private keys will be deleted, no questions asked. This is simpler and cleaner. Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Tue May 10 08:32:41 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 10 May 2016 08:32:41 +0200 Subject: 'No pinentry' error (--pinentry-mode loopback with --delete-secret-and-public-key) In-Reply-To: (Dashamir Hoxha's message of "Tue, 10 May 2016 04:17:07 +0200") References: <20160504225534.2DFAC101222B@remailer.paranoici.org> <20160507105914.45E761031C14@remailer.paranoici.org> <20160507153213.30F5F1031C18@remailer.paranoici.org> Message-ID: <87posuctiu.fsf@wheatstone.g10code.de> On Tue, 10 May 2016 04:17, dashohoxha at gmail.com said: > But I just realized that you can delete everything on > "$GNUPGHOME/private-keys-v1.d/" and all the private keys will be deleted, > no questions asked. This is simpler and cleaner. Take care: This deletes _all_ keys including ssh and X.509 keys. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From caro at nymph.paranoici.org Tue May 10 09:47:34 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Tue, 10 May 2016 07:47:34 +0000 (UTC) Subject: 'No pinentry' error (--pinentry-mode loopback with --delete-secret-and-public-key) References: <20160504225534.2DFAC101222B@remailer.paranoici.org> <20160507105914.45E761031C14@remailer.paranoici.org> <20160507153213.30F5F1031C18@remailer.paranoici.org> Message-ID: <20160510074734.CAF25100B057@remailer.paranoici.org> Hello Dashamir, on Tue, 10 May 2016 04:17:07 +0200, you wrote: >On Sat, May 7, 2016 at 5:32 PM, Carola Grunwald >wrote: > >> >> You're right, there's no passphrase request with >> >> | d:\gpg>gpg.exe --batch --homedir "d:\gpgdat" --no-auto-key-locate >> --no-default-keyring --keyring "d:\gpgdat\pubring.kbx" >> --delete-secret-and-public-key "66C040ADBE2C5728022F81DCCE09E0556C2C8CE0" >> >> But that way a 'Pinentry' window opens, which I have to avoid: >> >> | Pinentry >> | >> | Do you really want to permanently delete the >> | OpenPGP secret key: >> | "John Doe " >> | 2048-bit RSA key, ID 6C2C8CE0, >> | created 2016-04-23. >> | ? >> | >> | [ Delete key ] [ No ] >> >> followed by >> >> | Pinentry >> | >> | Do you really want to permanently delete the >> | OpenPGP secret subkey key: >> | "John Doe " >> | 2048-bit RSA key, ID 174B70A0, >> | created 2016-04-23 (main key ID 6C2C8CE0). >> | ? >> | >> | [ Delete key ] [ No ] >> > >I agree, this is anoying. And the docs say that with --batch and --yes and >"fingerprint" no questions will be asked (this is the meaning of batch >after all). Meanwhile I'm sure it's a bug similar to https://bugs.gnupg.org/gnupg/issue2324. GnuPG 2.1 isn't ready for embedded usage yet. It's still experimental, so we have to wait. >But I just realized that you can delete everything on >"$GNUPGHOME/private-keys-v1.d/" and all the private keys will be deleted, >no questions asked. This is simpler and cleaner. That's not future-proof. When GPG caches file system data it may fail. Kind regards Caro From dashohoxha at gmail.com Tue May 10 10:24:28 2016 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Tue, 10 May 2016 10:24:28 +0200 Subject: 'No pinentry' error (--pinentry-mode loopback with --delete-secret-and-public-key) In-Reply-To: <20160510074734.CAF25100B057@remailer.paranoici.org> References: <20160504225534.2DFAC101222B@remailer.paranoici.org> <20160507105914.45E761031C14@remailer.paranoici.org> <20160507153213.30F5F1031C18@remailer.paranoici.org> <20160510074734.CAF25100B057@remailer.paranoici.org> Message-ID: On Tue, May 10, 2016 at 9:47 AM, Carola Grunwald wrote: > > Meanwhile I'm sure it's a bug similar to > https://bugs.gnupg.org/gnupg/issue2324. > Some other people may claim that it is a feature. I am not able to judge on these issues, so I have no opinion. > >But I just realized that you can delete everything on > >"$GNUPGHOME/private-keys-v1.d/" and all the private keys will be deleted, > >no questions asked. This is simpler and cleaner. > > That's not future-proof. > When GPG caches file system data it may fail. > Maybe. But at least for 2.1.11 and 2.1.12 it works. On the future we will see what to do. Cross the bridge when you are at the bridge :) Regards, Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Tue May 10 11:35:33 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 10 May 2016 11:35:33 +0200 Subject: 'No pinentry' error (--pinentry-mode loopback with --delete-secret-and-public-key) In-Reply-To: <20160510074734.CAF25100B057@remailer.paranoici.org> (Carola Grunwald's message of "Tue, 10 May 2016 07:47:34 +0000 (UTC)") References: <20160504225534.2DFAC101222B@remailer.paranoici.org> <20160507105914.45E761031C14@remailer.paranoici.org> <20160507153213.30F5F1031C18@remailer.paranoici.org> <20160510074734.CAF25100B057@remailer.paranoici.org> Message-ID: <87a8jyb6hm.fsf@wheatstone.g10code.de> On Tue, 10 May 2016 09:47, caro at nymph.paranoici.org said: > Meanwhile I'm sure it's a bug similar to > https://bugs.gnupg.org/gnupg/issue2324. Not really. > GnuPG 2.1 isn't ready for embedded usage yet. > It's still experimental, so we have to wait. No, it is not experimental, but you have a rare use case by doing unattended deletion of secret keys. FWIW, You would have run into a very similar problem with gpgsm for more than a decade. I just pushed the attached fix. (consider s/--disallow-loopback-passpharse/--no-allow-loopback-pinentry/ for the commit message) You should be able to apply this to 2.1.12. GPGME probably needs an update too. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-gpg-Allow-unattended-deletion-of-secret-keys.patch Type: text/x-diff Size: 7038 bytes Desc: not available URL: From caro at nymph.paranoici.org Wed May 11 01:20:54 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Tue, 10 May 2016 23:20:54 +0000 (UTC) Subject: 'No pinentry' error (--pinentry-mode loopback with --delete-secret-and-public-key) References: <20160504225534.2DFAC101222B@remailer.paranoici.org> <20160507105914.45E761031C14@remailer.paranoici.org> <20160507153213.30F5F1031C18@remailer.paranoici.org> <20160510074734.CAF25100B057@remailer.paranoici.org> <87a8jyb6hm.fsf@wheatstone.g10code.de> Message-ID: <20160510232054.BDD78100B172@remailer.paranoici.org> On Tue, 10 May 2016 11:35:33 +0200, Werner Koch wrote: >On Tue, 10 May 2016 09:47, caro at nymph.paranoici.org said: > >> Meanwhile I'm sure it's a bug similar to >> https://bugs.gnupg.org/gnupg/issue2324. > >Not really. > >> GnuPG 2.1 isn't ready for embedded usage yet. >> It's still experimental, so we have to wait. > >No, it is not experimental, but you have a rare use case by doing >unattended deletion of secret keys. FWIW, You would have run into a >very similar problem with gpgsm for more than a decade. When an application creates a key it also has to get it deleted. With the 1.4 branch I interacted with the GnuPG process completely unattended through standard-I/O pipes, which now are replaced by the pinentry mechanism, where redirections fail. > >I just pushed the attached fix. (consider > s/--disallow-loopback-passpharse/--no-allow-loopback-pinentry/ >for the commit message) > >You should be able to apply this to 2.1.12. GPGME probably needs an >update too. Many thanks. But I'm on Windows, dependent on binaries. Without nightly builds I have to wait for the next release, or try to crosscompile it in my Debian VM, which I doubt to manage. Kind regards Caro From dashohoxha at gmail.com Wed May 11 04:42:40 2016 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Wed, 11 May 2016 04:42:40 +0200 Subject: 'No pinentry' error (--pinentry-mode loopback with --delete-secret-and-public-key) In-Reply-To: <20160510232054.BDD78100B172@remailer.paranoici.org> References: <20160504225534.2DFAC101222B@remailer.paranoici.org> <20160507105914.45E761031C14@remailer.paranoici.org> <20160507153213.30F5F1031C18@remailer.paranoici.org> <20160510074734.CAF25100B057@remailer.paranoici.org> <87a8jyb6hm.fsf@wheatstone.g10code.de> <20160510232054.BDD78100B172@remailer.paranoici.org> Message-ID: On Wed, May 11, 2016 at 1:20 AM, Carola Grunwald wrote: > > When an application creates a key it also has to get it deleted. > > With the 1.4 branch I interacted with the GnuPG process completely > unattended through standard-I/O pipes, which now are replaced by the > pinentry mechanism, where redirections fail. > Pinentry may be a good feature, but there should be an easy way to bypass or disable it. > Many thanks. But I'm on Windows, dependent on binaries. Without > nightly builds I have to wait for the next release, or try to > crosscompile it in my Debian VM, which I doubt to manage. > Maybe the realse schedule should include alpha and beta, before making a stable release, so that the community has a change to test and find out any problems, which can hopefully be fixed before the final release. Peace, Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alexander.Strobel at giepa.de Wed May 11 10:54:20 2016 From: Alexander.Strobel at giepa.de (Alexander Strobel) Date: Wed, 11 May 2016 10:54:20 +0200 Subject: Create subkey with same passphrase Message-ID: <5732F33C.4030203@giepa.de> I wanted to know if there is a way to create a new subkey without giving it a new passphrase but using the same one as the primary key and the first subkey. AFAIK while creating the first subkey there is no passphrase question, it simply uses the passphrase given for the primary key. The use case behind my question is that I want to create a combined RSA/ECC key in a batch like way without getting the ?Please enter your passphrase/Please repeat your passphrase? twice (which means 4 dialogs in total). gpg --batch --gen-key > Key-Type: RSA > ? > Subkey-Type: RSA > ? > %commit gpg --edit-key abcd1234 addkey > ecc/e > curve25519 > ? Best regards Alex Strobel www.gpg4o.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed May 11 11:51:59 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 11 May 2016 11:51:59 +0200 Subject: 'No pinentry' error (--pinentry-mode loopback with --delete-secret-and-public-key) In-Reply-To: (Dashamir Hoxha's message of "Wed, 11 May 2016 04:42:40 +0200") References: <20160504225534.2DFAC101222B@remailer.paranoici.org> <20160507105914.45E761031C14@remailer.paranoici.org> <20160507153213.30F5F1031C18@remailer.paranoici.org> <20160510074734.CAF25100B057@remailer.paranoici.org> <87a8jyb6hm.fsf@wheatstone.g10code.de> <20160510232054.BDD78100B172@remailer.paranoici.org> Message-ID: <87wpn053cw.fsf@wheatstone.g10code.de> On Wed, 11 May 2016 04:42, dashohoxha at gmail.com said: > Maybe the realse schedule should include alpha and beta, before making a Alfa releases don't make sense because that is defined as in-house tests. We do not have them due to our public development model. We did beta releases and release candidates for many years but it turned out that they are only rarely used. Those who are keen to test things either build from the repo or wait for a released version. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From anthony at cajuntechie.org Thu May 12 02:09:37 2016 From: anthony at cajuntechie.org (Anthony Papillion) Date: Wed, 11 May 2016 19:09:37 -0500 Subject: Documentation on --with-colons output? Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I'm writing a tool that needs to parse output from GnuPG. I'll be using the --with-colons option to make output easier to parse. Is there any doc on what the different fields are in the output? Specifically, for things like --list-public-keys? Thanks, Anthony - -- OpenPGP Key: 4096R/028ADF7453B04B15 Other Key Info: http://www.cajuntechie.org/p/my-pgp-key.html XMPP?Jabber: cypher at chat.cpunk.us -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXM8nBAAoJEAKK33RTsEsV2AoQAKdiXW0OZTH5PnP232VfmR7e Gr+uQfs3PFGmwmn33LfUDotZhnqnfxeE+nLyda+rlQtsT3gjr9Zwe8DTdFpwvhE5 +YPiLzQmRm8HsRA+SF+/sbAQX5KLUlFbOGH/NK+917DaKzMTMmkNVYnqKZ1s6Uh5 WezSBiXWauavWGgbC8kbfy75YqRwKFp9RaqnxnyRFzG4SQsNH0rcTMPKNjqNivp4 S/O6EHFoYT8xdOHxrIeDj/94Vc/D00hrm0lnKbWyzkPHb37ktFoDdGEKCBemCo/t 4BWyue26FdoZ2dtWGVm1JaXAkwiIATy3Gst8Km3QDYiRcrRsGrfgAypQMWbJ6Qs6 3re5OxT2PhVy5HnXwhGQHcULvmv6E4lKmKmqNXwdIkTgl+pY7hWpR1/qRCsCroLf y1ljIE+eiQsba2sdoP4EzHT4viXCf4SgGvS2AFNpTHLHGlwOuWtg++eqXrBlhuoF m6pqtxsg78YyomPIpMmWCPMgkoUnfxQJDsMWyAik+X919ldezvaoxz0F3FTYk8vx F6N34iDqdleQk+/ckhkfnIT3fTPNaht0jqtD1sLUBSNX98Kv8eRhvlk9p6zcyvyB V4r6rchikxTRJJcWc0IQdlyfy7cUT/YY8xElarAOVx9GhmK9WrcHSAo2RQbsaG6K M8l4itWcBrBTIX8pfYKp =NtJN -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Thu May 12 04:12:57 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 11 May 2016 22:12:57 -0400 Subject: Documentation on --with-colons output? In-Reply-To: References: Message-ID: <0f311b4c-e8d4-a1e5-7b21-56a9dfdb7258@sixdemonbag.org> > I'm writing a tool that needs to parse output from GnuPG. I'll be > using the --with-colons option to make output easier to parse. Is > there any doc on what the different fields are in the output? Use --fixed-list-mode and look at the DETAILS file. From cyril.martin at technomedia.com Thu May 12 11:55:57 2016 From: cyril.martin at technomedia.com (Cyril Martin) Date: Thu, 12 May 2016 09:55:57 +0000 Subject: Decryption error: open(CONOUT$) failed Message-ID: Hello, since few days we face of an issue to decrypt files (.gpg) with GNUPG 1.4.9 We get error: *********************** gpg: fatal: open(CONOUT$) failed: The system cannot find the file specified. secmem usage: 0/0 bytes in 0/0 blocks of pool 0/32768 *********************** If issue was due to < the file specified > I think we should get this error : ************************ gpg: can't open `FILE_SPECIFIED' gpg: decrypt_message failed: file open error ************************* Decryption is processed by a program launched with a Windows service account. Manually with my personal account, it's OK I can decrypt, but not with the program I have keyrings under: C:\Users\windows_service_account\AppData\Roaming\gnupg Could you help me please? GNUPG 1.4.9 Windows server 2008 R2 Cyril -------------- next part -------------- An HTML attachment was scrubbed... URL: From 2014-667rhzu3dc-lists-groups at riseup.net Fri May 13 01:59:56 2016 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Fri, 13 May 2016 00:59:56 +0100 Subject: Create subkey with same passphrase In-Reply-To: <5732F33C.4030203@giepa.de> References: <5732F33C.4030203@giepa.de> Message-ID: <863062035.20160513005956@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Wednesday 11 May 2016 at 9:54:20 AM, in , Alexander Strobel wrote: > I wanted to know if there is a way to create a new > subkey without giving > it a new passphrase but using the same one as the > primary key and the > first subkey. Just enter the same passphrase as already used for this key when prompted for the passphrase for the new subkey. - -- Best regards MFPA Dreams come true on this side of the Rainbow too! -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJXNRkSXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwUOUH/RjUbJh4u0AyAi81+tUQ5u14 bTnie0C+EyOfyoUNjTQlHjjNoiDzNO/d/ZINzeijJ94yOZyspdX7Z0vMFnJPe6+d 0A+51t7qGstRlZ+955Uw/+DzdwfGmRA3pOWsKzr+0d391u8w5LjolpM7+NYWneQX RqnzHdob7jDRvW+ZEY2pDhM0A44jyVsegupdotF7qeM9r5ZIoTnOf1rq4ZafjXch xN5qQtX7yW2vI3VlYJ8/B5MLyxreAIyMHANiIoklqN/PVnv0vHmp3+/NdwMeYoqL MO4seUyA4vJytrg5YcwgjV0QXBvTEu7mVbctkLiqspYWs7MlMNrc2OkET6VGCE6I vgQBFgoAZgUCVzUZG18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45A1BAP4s5EbPZFt9IcMURwjL+BoXtO+2 IMB+U/LMAtyJlpTR0gD/cqI8uNSUIpk86I10AAAFbU3N2wMVajCQ7hJ7kky/Tg8= =Zeo1 -----END PGP SIGNATURE----- From dashohoxha at gmail.com Fri May 13 04:28:08 2016 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Fri, 13 May 2016 04:28:08 +0200 Subject: Create subkey with same passphrase In-Reply-To: <863062035.20160513005956@riseup.net> References: <5732F33C.4030203@giepa.de> <863062035.20160513005956@riseup.net> Message-ID: On Fri, May 13, 2016 at 1:59 AM, MFPA < 2014-667rhzu3dc-lists-groups at riseup.net> wrote: > > > I wanted to know if there is a way to create a new > > subkey without giving > > it a new passphrase but using the same one as the > > primary key and the first subkey. > > Just enter the same passphrase as already used for this key when > prompted for the passphrase for the new subkey. > The best solution in my opinion would be to allow batch mode [1] to create more than one subkey. The manual says "Currently only one subkey can be handled". I don't know, is it difficult to implement, or it is considered bad practice (and thus the restriction). Dashamir [1]: https://www.gnupg.org/documentation/manuals/gnupg/Unattended-GPG-key-generation.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From dashohoxha at gmail.com Fri May 13 12:08:20 2016 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Fri, 13 May 2016 12:08:20 +0200 Subject: Do we need more than one subkey? Message-ID: > The best solution in my opinion would be to allow batch mode [1] to create > more than one subkey. The manual says "Currently only one subkey can be > handled". > I don't know, is it difficult to implement, or it is considered bad practice (and thus > the restriction). On a second thinking, I believe that in a typical case no more than one subkey is needed. And one subkey is actually required (in a typical case) in order to have a different key for signing and for decryption (which is a recomended best practice). Peace, Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From Daniel.Ranft at giepa.de Fri May 13 11:38:28 2016 From: Daniel.Ranft at giepa.de (Daniel Ranft) Date: Fri, 13 May 2016 11:38:28 +0200 Subject: Having issues with dirmngr in gpg 2.1 Message-ID: <1DC3C8C67280FB4C9A402CB6DB1358F51B8FF0BAC8@S2008SBS.intern.giepa.de> Hi, Since a few weeks I cannot search keys anymore. When I use gpg --keyserver --search-keys , the commandline freezes and the process explorer does not show me a dirmngr.exe instance. I then tried to investigate this further by trying to start the dirmngr manually with following result: C:\Program Files (x86)\GNU\GnuPG\2.1.12\bin>dirmngr.exe --daemon dirmngr[5020]: Error while opening `C:\ProgramData\GNU\etc\gnupg\ldapservers.conf': No such file or directory dirmngr[5020]: The socket cannot be bound to `C:\Windows\S.dirmngr': Unknown error I localized some parts of the string by myself as they were german. What worked for me was to start the dirmngr manually with explicit --homedir %appdata%\gnupg, but I do not use an alternative homedirectory by environment variable or registry key. Therefore I think, gpg should try to create the socket file under %appdata%\gnupg instead of under C:\Windows. Any suggestions where I should look for a mistake in my configuration? -- Best regards, Daniel From swehack at gmail.com Sat May 14 19:25:15 2016 From: swehack at gmail.com (Stefan Midjich) Date: Sat, 14 May 2016 19:25:15 +0200 Subject: Problems with USB access to Omnikey 4321 Message-ID: Hi list users My goal was to reset one of my GnuPG v2.1 smartcards because the PIN counter had reached 3 and it had been locked "permanently". I am using Fedora 23 with the PCMCIA Omnikey AG Cardman 4321. I read many posts on the list showing me how to do this but I couldn't communicate with my card using gpg-connect-agent console, every scd command I attempted gave me a card error, except for scd restart which said OK and started scdaemon if I had killed it. Here is the output of gpg --card-status --debug-ccid-driver with the locked card inserted: https://paste.fedoraproject.org/366386/24579314/ And here is my scdaemon.log when I've killed scdaemon, inserted my card and attempt to use the command 'scd serialno' in the gpg-connect-agent console. https://paste.fedoraproject.org/366394/32464351/ In the scdaemon.log I can see errors like "ccid-driver: usb_bulk_read error: F?rbindelsen dog ut (timeout)" which means connection timed out, and "apdu_send_simple(0) failed: card I/O error" further down. On the console it replies ERR 100696113 In/ut-fel which means I/O error, gpg-connect-agent does not listen when I set LANGUAGE=C in the environment so I can't force english errors. My ~/.gnupg/scdaemon.conf looks like this. pcsc-driver /usr/lib64/pcsc/drivers/ifdokccid_linux_x86_64-v4.1.8.bundle/Contents/Linux/ifdokccid.so disable-pinpad log-file /home/stemid/.gnupg/scdaemon.log debug-all debug-ccid-driver The driver I downloaded from here hidglobal.com/drivers because I think it was necessary for my card reader. I have another Gemalto reader that seems to work without any additional drivers but it's external. Pcscd is not running however. I hope someone here understands what is wrong. -- V?nliga H?lsningar / Sincerely Stefan M From peter at digitalbrains.com Sat May 14 20:54:23 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 14 May 2016 20:54:23 +0200 Subject: Problems with USB access to Omnikey 4321 In-Reply-To: References: Message-ID: <5737745F.6030705@digitalbrains.com> On 14/05/16 19:25, Stefan Midjich wrote: > On the console it replies ERR 100696113 In/ut-fel which means > I/O error, gpg-connect-agent does not listen when I set LANGUAGE=C in > the environment so I can't force english errors. I haven't looked into your problem, but let me give this quick hint: try LC_ALL=C . It should override all language settings. I think if you kill the agent, and do something like: $ export LC_ALL=C $ gpg-connect-agent /bye Then I would hope that the started agent would inherit the setting for the logs... HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From humanify at gmx.de Sat May 14 09:39:30 2016 From: humanify at gmx.de (Simon Eisel) Date: Sat, 14 May 2016 09:39:30 +0200 Subject: Documentation gap: User-agent configuration under windows 8.1 Message-ID: <845edc81-a919-1124-de88-8bf3811ebf48@gmx.de> Dear GPG user community, Got to admit it took me ridiculously long to find a way to pass arguments to the gpg-agent under windows 8.1 like setting max-cache time values The documentation so far doesn't mention that the gpg-agent.conf file has to be placed in the C:\Users\USERNAME\AppData\Roaming\gnupg directory in order to be considered when gpg-agent.exe is invoked by gpg.exe I'd strongly suggest to include this detail in the documentation. Kind regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From swehack at gmail.com Sun May 15 13:28:14 2016 From: swehack at gmail.com (Stefan Midjich) Date: Sun, 15 May 2016 13:28:14 +0200 Subject: Problems with USB access to Omnikey 4321 In-Reply-To: <5737745F.6030705@digitalbrains.com> References: <5737745F.6030705@digitalbrains.com> Message-ID: Thanks for showing me, I tried gpgconf --kill scdaemon, then did your trick but the scdaemon.log after that was still giving the occasional swedish error just like the one I pasted. And same with the scd command in the gpg-connect-agent console. 2016-05-14 20:54 GMT+02:00 Peter Lebbing : > On 14/05/16 19:25, Stefan Midjich wrote: >> On the console it replies ERR 100696113 In/ut-fel which means >> I/O error, gpg-connect-agent does not listen when I set LANGUAGE=C in >> the environment so I can't force english errors. > > I haven't looked into your problem, but let me give this quick hint: try > LC_ALL=C . It should override all language settings. > > I think if you kill the agent, and do something like: > > $ export LC_ALL=C > $ gpg-connect-agent /bye > > Then I would hope that the started agent would inherit the setting for > the logs... > > HTH, > > Peter. > > -- > I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. > You can send me encrypted mail if you want some privacy. > My key is available at -- V?nliga H?lsningar / Sincerely Stefan M From wk at gnupg.org Sun May 15 13:52:08 2016 From: wk at gnupg.org (Werner Koch) Date: Sun, 15 May 2016 13:52:08 +0200 Subject: Documentation gap: User-agent configuration under windows 8.1 In-Reply-To: <845edc81-a919-1124-de88-8bf3811ebf48@gmx.de> (Simon Eisel's message of "Sat, 14 May 2016 09:39:30 +0200") References: <845edc81-a919-1124-de88-8bf3811ebf48@gmx.de> Message-ID: <87lh3bo7x3.fsf@wheatstone.g10code.de> On Sat, 14 May 2016 09:39, humanify at gmx.de said: > The documentation so far doesn't mention that the gpg-agent.conf file > has to be placed in the C:\Users\USERNAME\AppData\Roaming\gnupg That directory depends on your systems configuration. Thus we can't mention this in the man page. For all configuration files as well as public and private keys, GnuPG uses its home directory (often called GNUPGHOME after the environment variable to force the use of a non-default home directory. All GnuPG versions show you the used home directory with this command: gpg --version which prints for example (here on Unix): Home: ~/.gnupg On Windows _you_ will see the directory you mentioned above. Since GnuPG 2.0, the gpgconf command can be used to list the various directories in use by GnUPG. For example: $ gpgconf --list-dirs sysconfdir:/etc/gnupg bindir:/usr/local/bin libexecdir:/usr/local/libexec libdir:/usr/local/lib/gnupg datadir:/usr/local/share/gnupg localedir:/usr/local/share/locale dirmngr-socket:/home/someuser/.gnupg/S.dirmngr dirmngr-sys-socket:/usr/local/var/run/gnupg/S.dirmngr agent-socket:/home/someuser/.gnupg/S.gpg-agent homedir:/home/someuser/.gnupg Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ From peter at digitalbrains.com Sun May 15 18:36:31 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 15 May 2016 18:36:31 +0200 Subject: Problems with USB access to Omnikey 4321 In-Reply-To: References: <5737745F.6030705@digitalbrains.com> Message-ID: <5738A58F.2000405@digitalbrains.com> On 15/05/16 13:28, Stefan Midjich wrote: > Thanks for showing me, I tried gpgconf --kill scdaemon, then did your > trick but the scdaemon.log after that was still giving the occasional > swedish error just like the one I pasted. Oh, then what I showed is not sufficient to get the agent and scdaemon to change locale, that's too bad. I'll get back to your earlier mail now. On 14/05/16 19:25, Stefan Midjich wrote: > Here is the output of gpg --card-status --debug-ccid-driver with the > locked card inserted: https://paste.fedoraproject.org/366386/24579314/ Can you tell what version of GnuPG you are using? I can't readily tell... Anyway, your card still seems responsive. You can still select the OpenPGP application on it and list its data. > And here is my scdaemon.log when I've killed scdaemon, inserted my > card and attempt to use the command 'scd serialno' in the > gpg-connect-agent console. > https://paste.fedoraproject.org/366394/32464351/ I'm getting technical, which is also intended to help along any other people trying to look into your problem. So if you don't understand what I'm saying, just read on. Where in the dump of your gpg --card-status --debug-ccid-driver, GnuPG seems to immediately request for the OpenPGP application by Application Identifier, and this succeeds, the gpg-connect-agent dump first tries a different SELECT command, I think for the MF, Master File[1]. Then your card seems to go silent and does not respond anymore. On contrast, with a v2.0 card I have here where I depleted the tries for the PINs, and using GnuPG v2.1, my GnuPG will always do the SELECT MF from [1], also with gpg2 --card-status. My card then replies with SW1-SW2=6B00, indicating the SELECT failed. The difference is it doesn't go silent like yours. Subsequently, my scdaemon request the OpenPGP application by AID[2], this succeeds by SW1-SW2=9000, and everything goes peachy. Whereas your card is never heard from again... At this point, I'd really like to know which version of GnuPG you're using. And if you're using GnuPG 1.4, do you have 2.x installed? Could you easily install 2.1 if you don't have a 2.x installed already? My issue here is that my installation issues different commands to my card than yours. At least, sometimes. The first part of a dump of my scdaemon log when I do a gpg2 --card-status can be found here[3]. > My ~/.gnupg/scdaemon.conf looks like this. > > pcsc-driver /usr/lib64/pcsc/drivers/ifdokccid_linux_x86_64-v4.1.8.bundle/Contents/Linux/ifdokccid.so Now don't trust me on this, but it seems to me that scdaemon is using its internal CCID driver for your card reader, and this line, AFAIK, is only relevant to setups where PC/SC is used, that is, not the internal CCID driver. So I think it's not relevant. > The driver I downloaded from here hidglobal.com/drivers because I > think it was necessary for my card reader. I /think/ this was thus unneeded, as is a running pcscd. In fact, a different program also accessing the card reader will cause issues when scdaemon is using its own CCID driver. Cheers, Peter. [1] The raw APDU is 00 A4 00 0C 02 3F 00 [2] The raw APDU is 00 A4 04 00 06 D2 76 00 01 24 01 [3] https://paste.fedoraproject.org/366760/ -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Sun May 15 18:51:44 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 15 May 2016 18:51:44 +0200 Subject: Problems with USB access to Omnikey 4321 In-Reply-To: <5738A58F.2000405@digitalbrains.com> References: <5737745F.6030705@digitalbrains.com> <5738A58F.2000405@digitalbrains.com> Message-ID: <5738A920.7090800@digitalbrains.com> On 15/05/16 18:36, Peter Lebbing wrote: > At this point, I'd really like to know which version of GnuPG you're using. And > if you're using GnuPG 1.4, do you have 2.x installed? Could you easily install > 2.1 if you don't have a 2.x installed already? On reflection, the difference in behaviour is in the scdaemon, not in the gpg binary which talks to the agent. I don't recommend you use the gpg program from GnuPG 1.4, but do it all with GnuPG 2.x, but it's not that which causes the difference from how it goes here. The difference is that your gpg --card-status does a "scd serialno openpgp", unlike your "scd serialno". But for me, "scd serialno openpgp" also tries the SELECT MF first. By far the easiest way to factory reset an OpenPGP card is with GnuPG v2.1's command factory-reset from --card-edit. The thing is, there are cards where the two commands involved where accidentally switched around. This keeps on confusing me, I still can't say which card needs which order of reset commands to work. You could try to do what you're doing with "scd serialno openpgp" instead of "scd serialno", to see if it works then. But it's odd this is needed. The "scd serialno undefined" you can also find is probably unneeded at this point because that's for cards where the OpenPGP application is in "Terminated" state or something like that, and your OpenPGP application is still responsive when you do --card-status. Which instructions are you trying to follow? HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From Daniel.Ranft at giepa.de Tue May 17 14:58:41 2016 From: Daniel.Ranft at giepa.de (Daniel Ranft) Date: Tue, 17 May 2016 14:58:41 +0200 Subject: Go gpg, guess, what I want Message-ID: <1DC3C8C67280FB4C9A402CB6DB1358F51B8FF0BB6D@S2008SBS.intern.giepa.de> Hi, Today I want to discuss about a situation, where gpg seems to guess, what I want to do (which is IMHO not a good idea). If I export a keypair (gpg -a -o C:\some\where.asc --export-secret-keys abcd1234), the pinentry will pop up for each primary-/subkey to prompt for the passphrase. So far, so good. When I cancel the first prompt, gpg still tries to export the other subkeys to generate a somehow usefull output. That is, what I think is guessing. Result when I only cancel the first prompt, but not the second: I get a file which contains only the secret subkey and its binding sig: # off=0 ctb=9d tag=7 hlen=3 plen=966 :secret sub key packet: version 4, algo 1, created 1283427770, expires 0 pkey[0]: [2048 bits] pkey[1]: [17 bits] iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: =LONGKEY= protect count: 4980736 (195) protect IV: 2f 89 b9 0a 22 c5 6d 50 4d 8b a2 53 1f 53 50 bf skey[2]: [v4 protected] keyid: 82AE4F2683F549E5 # off=969 ctb=89 tag=2 hlen=3 plen=293 :signature packet: algo 1, keyid =LONGKEY= version 4, created 1427802947, md5len 0, sigclass 0x18 digest algo 2, begin of digest 13 ab hashed subpkt 27 len 1 (key flags: 0C) hashed subpkt 2 len 4 (sig created 2015-03-31) hashed subpkt 9 len 4 (key expires after 6y211d0h12m) subpkt 16 len 8 (issuer key ID =LONGKEY=) data: [2044 bits] FWIW: When I cancel the first prompt, gpg should stop the export of the complete key. If there are several keys to export, gpg should still process the other keys. If I would have wanted to export the subkey only, I would have used the exclamation mark syntax. -- Best regards, Daniel Ranft From samir at samirnassar.com Tue May 17 18:00:19 2016 From: samir at samirnassar.com (Samir Nassar) Date: Tue, 17 May 2016 18:00:19 +0200 Subject: Feedback requested: GnuPG lookup and retrieval of PGP certificates via DNS Message-ID: <664801ba-ed12-4aa5-f675-da983ab8759d@samirnassar.com> I put together a short 1-page document of around 300 words to illuminate the mechanics to a group of friends of the new key lookup via PKA and DANE(1). The document is available in PNG format at https://beta.samirnassar.com/pgpdns/latest.png and please don't bookmark the URI for long-term use. It is not a cool URI(2). I used "Publishing Keys in DNS(3)" by Damien Goutte-Gattat as a reference. I did not use the OPENPGPKEY RR type since it is not implemented in my DNS server yet(4). I used TYPE37 for PKA and TYPE61 for DANE. If you have comments, concerns, additions, detractions, denouncements, or applause, the document and a sufficiently recent version of GnuPG should help you find a way to share this with me. If you decide to reply to the mailing list, keep in mind that it is a public list and to be considerate of the others on this list. [1] I know, I know: I am not using DNSSEC. [2] Cool URIs don't change: https://www.w3.org/Provider/Style/URI.html [3] Publishing Keys in DNS: https://incenp.org/notes/2015/keys-in-dns.html [4] Knot DNS features: https://www.knot-dns.cz/docs/2.x/singlehtml/index.html#knot-dns-features -- Samir Nassar web: samirnassar.com email: samir at samirnassar.com PGP: pgp.samirnassar.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed May 18 16:27:04 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 May 2016 16:27:04 +0200 Subject: [Announce] Join us for the first OpenPGP conference Message-ID: <87h9dvbfwn.fsf@wheatstone.g10code.de> Hello! The German Unix User Group (GUUG) is pleased to announce the first public conference on the OpenPGP protocol taking place in Cologne, Germany on September 8+9, 2016. OpenPGP.conf is a conference for users and implementers of the OpenPGP protocol, the popular standard for encrypted email communication and protection of data at rest. That protocol is the foundation of encryption software like PGP, GnuPG, Mailvelope, OpenKeyChain, and others. OpenPGP.conf is a place to meet, discuss, and learn about latest developments of OpenPGP aware applications and what technical measures can be deployed to repel the ever increasing trend to mass surveillance. Topics are: - The OpenPGP protocol and its planned revision - Current status of OpenPGP applications - Interesting use cases - Key discovery and distribution - Ubiquitous end-to-end encryption - Security analysis - User interface studies - Anonymous mail and the spam problem The Call for Presentations is available at: https://gnupg.org/conf/cfp.html More information will be published at the conference site: https://gnupg.org/conf/ Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ -------------- 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 justus at g10code.com Thu May 19 10:46:13 2016 From: justus at g10code.com (Justus Winter) Date: Thu, 19 May 2016 10:46:13 +0200 Subject: GnuPG in 2016 Message-ID: <20160519084613.8210.64369@thinkbox.jade-hamburg.de> Hello, this is the plain text version of a new blog entry I wrote up. If you have questions or want to comment, please group-reply to this mail. Cheers, Justus GnuPG in 2016 ============= This is an overview of what happened in the first half of 2016 in the GnuPG project and community. Development ~~~~~~~~~~~ There has been one release of the current stable branch of GnuPG, version [2.0.30]. Our development branch GnuPG modern saw two releases, [2.1.11], and [2.1.12]. Among many bugfixes and other improvements GnuPG 2.1.11 added a new command `--export-ssh-key' that replaces the `gpgkey2ssh' tool, and we now use the CA certificate of `hkps.pool.sks-keyservers.net' to secure communications with the servers in the pool without further configuration. Furthermore, we now print a warning if a GnuPG component is using an older version of our backend daemons. 2.1.12 brought support for a new experimental "Web Key Directory" key location service, read-support for a new private key protection format and the new extended private key format, improved Tofu support, use of the new libusb 1.0 API, and countless small features and fixes. Daniel Genkin, Lev Pachmanov, Itamar Pipman, and Eran Tromer from the Tel Aviv University demonstrated a practical way to extract ECDH keys via low-bandwidth electromagnetic attacks on PCs[1]. Libgcrypt version 1.6.5 and an updated Windows installer for GnuPG 2.1.11 has been [released] to mitigate this attack. In April we released a new stable version of Libgcrypt, version [1.7]. It retains full API and ABI compatibiliy to the 1.6 series. Its main features are new algorithms, curves, and performance improvements. Andre worked on PGP/MIME support in GpgOL, and the current stable version [2.3.1] of Gpg4win includes an option to enable experimental support for sending GPG/MIME and S/MIME. He also worked on Kleopatra, removing some dependencies on KDE components and DBUS, and porting it to newer KDE frameworks, making it easier to build, maintain and hack. A [beta version] of Gpg4win 3.0.0 has been released featuring the leaner Kleopatra with newer KDE libraries. Andre also worked on registering file extensions in Windows integrating encryption and decryption of files into the desktop environment, and implementing a 'Show Password' feature for the pinentries. Jussi worked on libgcrypt, most notably [adding] an ARM assembly implementation of SHA-512, and Intel PCMUL implementations for CRC algorithms. Justus worked on a new [test framework] for GnuPG and related projects, a new [extensible storage format] for private keys, [implemented] elliptic-curve cryptography in libssh using libgcrypt as backend, and triaged and fixed GnuPG bugs. Kai evaluated Mailpile. As the future of Mozilla Thunderbird - and with it Enigmails - is uncertain, we decided to explore alternative end-user-friendly mail clients with support for GnuPG. Gniibe worked on GnuPG and libgcrypt. He ported GnuPG's `scdaemon' to libusb 1.0, and worked with the team from Tel Aviv University to protect libgcrypt against the sidechannel attack. Gniibe also maintains GnuPG-related packages in Debian. He updated both [Poldi] and [Scute]. Gniibe designs and sells the FST-1, a small microcontroller that depending on the firmware either acts as an OpenPGP smart card or a hardware random number generator. As the stock is running low and some components cannot be sourced any longer, he is [working] on the successor featuring a simpler design, a button, and support for elliptic curve cryptography. [2.0.30] https://lists.gnupg.org/pipermail/gnupg-announce/2016q1/000385.html [2.1.11] https://lists.gnupg.org/pipermail/gnupg-announce/2016q1/000383.html [2.1.12] https://lists.gnupg.org/pipermail/gnupg-announce/2016q2/000387.html [released] https://lists.gnupg.org/pipermail/gnupg-announce/2016q1/000384.html [1.7] https://lists.gnupg.org/pipermail/gnupg-announce/2016q2/000386.html [2.3.1] http://lists.wald.intevation.org/pipermail/gpg4win-announce/2016-April/000068.html [beta version] https://wiki.gnupg.org/Gpg4win/Testversions [adding] https://lists.gnupg.org/pipermail/gcrypt-devel/2016-January/003671.html [test framework] https://lists.gnupg.org/pipermail/gnupg-devel/2016-April/031027.html [extensible storage format] https://lists.gnupg.org/pipermail/gnupg-devel/2016-April/031001.html [implemented] https://www.libssh.org/archive/libssh/2016-03/0000058.html [Poldi] https://tracker.debian.org/pkg/poldi [Scute] https://tracker.debian.org/pkg/scute [working] http://www.gniibe.org/memo/development/fs-bb48/fs-bb48-idea.html Press ~~~~~ Werner received the [Award for the Advancement of Free Software] for his work on GnuPG. [Award for the Advancement of Free Software] https://www.fsf.org/news/library-freedom-project-and-werner-koch-are-2015-free-software-awards-winners Discussions ~~~~~~~~~~~ Andre [asked] how to obtain a key in a format suitable for SSH's `authorized_keys' file from an OpenPGP public certificate now that `gpgkey2ssh' has been deprecated. The discussion was [taken to the bug tracker], and a solution released with GnuPG 2.1.11. Lachlan J. Gunn, Andrew Allison, and Derek Abbott wrote a paper about how Tor can be used to detect malicious key servers[2]. The [announcement] contains more information including a link to their implementation. Daniel [reported] that there have been discussions on building a Live-CD for securely managing OpenPGP master keys and smart cards over at debian-devel, and he asked if anyone knows about such an effort, or has comments on his proposal. The discussion went into all kinds of directions, but the consensus was that this is a useful idea. Bernhard [wrote] about work being done for the EasyGpg2016 project. They produced [user archetypes and stories] that should guide the refinement of GnuPG and related tools, and a [key distribution concept]. [asked] http://lists.gnupg.org/pipermail/gnupg-users/2016-January/054943.html [taken to the bug tracker] https://bugs.gnupg.org/gnupg/issue2212 [announcement] http://lists.gnupg.org/pipermail/gnupg-users/2016-February/055326.html [reported] https://lists.gnupg.org/pipermail/gnupg-users/2016-April/055819.html [wrote] https://lists.gnupg.org/pipermail/gnupg-devel/2016-May/031042.html [user archetypes and stories] https://wiki.gnupg.org/EasyGpg2016/VisionAndStories [key distribution concept] https://wiki.gnupg.org/EasyGpg2016/CertDistributionConcept Donations ~~~~~~~~~ We received this year until now about 90 donations summing up to 3000 Euro. Thanks for that help. Sure, that is not enough to pay our costs, but fortunately we still have enough money in our accounts to keep bread, water, and beer on our tables for this year and somewhat longer. We will eventually run a new donation campaign, though. It is probably less know that that we offer SEPA payments which can be used for recurring donations. We have not received many payments through SEPA yet and thus this method is only semi-automated and the cause for delays between a donation and a confirmation mail. There is an obvious way to make us automate this ;-) Lastly, let us confirm that we were meanwhile able to clarify our perceived problem with the Facebook donation promise. This was all due to an unfortunate misunderstanding between us. Facebook will keep on supporting GnuPG in 2016 with a donation of 50000 USD. About this news posting ======================= We try to write a news posting each month (though we must admit that we slipped a little in 2016). However, other work may have a higher priority (e.g. security fixes) and thus there is no promise for a fixed publication date. If you have an interesting topic for a news posting, please send it to us. A regular summary of the mailing list discussions would make a nice column on this news. Footnotes _________ [1] Daniel Genkin, Lev Pachmanov, Itamar Pipman, Eran Tromer, ECDH key-extraction via low-bandwidth electromagnetic attacks on PCs, proc. RSA Conference Cryptographers' Track (CT-RSA) 2016, LNCS 9610, 219-235, Springer, 2016, [https://www.cs.tau.ac.il/~tromer/ecdh/] [2] Lachlan J. Gunn, Andrew Allison, Derek Abbott, Verifying public keys without trust: How anonymity can guarantee data integrity, arXiv preprint arXiv:1602.03316, 2016, [http://arxiv.org/pdf/1602.03316v1.pdf] From rjh at sixdemonbag.org Mon May 23 20:19:51 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 23 May 2016 14:19:51 -0400 Subject: Encoding of user ID strings Message-ID: <485278db-6c1a-a771-c18e-b46d5eb484f7@sixdemonbag.org> Is there any way to determine the encoding for a user ID string? At first blush it appears the answer is "no, but most people use UTF-8." If so that's fine, but I'll have to silently discard a number of user IDs that appear to be in foreign encodings or are garbled UTF-8. I'd prefer not to do this, so if there's some magic way of discovering the intended encoding, I'd love to know about it. :) From RAcharya at carnival.com Mon May 23 14:34:50 2016 From: RAcharya at carnival.com (Acharya, Rohit (Contractor)) Date: Mon, 23 May 2016 12:34:50 +0000 Subject: problem with make in gpg2 Message-ID: <963DF0C368956849BD845B8EDB137D28350A07@CCLPRDEXDAG1.carnival.com> I am getting this error when running the command make. I would appreciate any help I could get. ../../g10/gpg2 --homedir . --quiet --yes --no-permission-warning --import ./pubdemo.asc ld.so.1: gpg2: fatal: relocation error: file /usr/lib/libgcrypt.so.20: symbol gpgrt_lock_lock: referenced symbol not found make: Fatal error: Command failed for target `all-recursive' Current working directory /var/spool/pkg/gnupg-2.0.30 *** Error code 1 make: Fatal error: Command failed for target `all' spirit1# ldd -r make ldd: make: cannot open file: No such file or directory Thanks, Rohit Acharya -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrewg at andrewg.com Mon May 23 23:03:06 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 23 May 2016 23:03:06 +0200 Subject: Encoding of user ID strings In-Reply-To: <485278db-6c1a-a771-c18e-b46d5eb484f7@sixdemonbag.org> References: <485278db-6c1a-a771-c18e-b46d5eb484f7@sixdemonbag.org> Message-ID: <62C7A898-2AD5-45D7-A50C-8C22E9B74194@andrewg.com> > On 23 May 2016, at 20:19, Robert J. Hansen wrote: > > Is there any way to determine the encoding for a user ID string? > > At first blush it appears the answer is "no, but most people use UTF-8." You can tell fairly reliably if someone is using either vanilla ascii or UTF8, in the cases of "7-bit characters only" and "8 bit characters in strictly valid UTF8 order" respectively. An off the shelf UTF8 validator should be able to do that for you. In the case of "all 8-bit characters, no 7-bit" you're dealing with either a practical joker or EBCDIC. Same thing really... After that you're into heuristics. There are quite a few programs out there that attempt to detect encodings statistically, but with such a short string of data you might as well pick a number. ;-) A From mls at bjoern-kahl.de Mon May 23 21:56:32 2016 From: mls at bjoern-kahl.de (Bjoern Kahl) Date: Mon, 23 May 2016 21:56:32 +0200 Subject: How to convert (ancient) key in "version 2" to more modern "version 4" format? Message-ID: <80d0245c-8dcf-af94-0682-4effcc10496e@bjoern-kahl.de> Dear All, I have a long use key that has been created back in 2002 using - I think - some gpg 1.0.x version. This key, at least when exported with "gpg2 --export" (or "--export-secret-key"), seems to be in some "key packet version 2" format, as "gpg2 --export | gpg2 --list-packets" shows: -------8<----8<------- :public key packet: version 2, algo 1, created 1022270000, expires 0 pkey[0]: [1024 bits] pkey[1]: [5 bits] keyid: 1234567890123456 ... ------->8---->8------- (Yes, it's only 1024 bits and that's not really up to modern needs, and while I eventually have to phase out this key, I still need to have it around for the time being. -- Key-rollover isn't a strength of the whole PGP system. :-( ) Modern keys generated with gpg2 show a "version 4" in the second line. I'd like to convert the existing secret key and the corresponding public key, preferably without destroying the signatures, from "version 2" to "version 4". For one thing, it would allow me to specify key preferences or set the primary ID, which seems to be not possible in the old format. For the other reason, I need to import the key into another software, in this case "Mailvelope", which does not support "version 2" keys. Is there a way to have gpg2 convert and export the key? Looking through gpg2's online help and trying to "google" an answer with varying queries did not show up any definite advise. I am currently using gpg2 version 2.0.29 with libgcrypt 1.7.0, installed using MacPorts on MacOS X 10.9.5. Thanks Bj?rn -- | Bjoern Kahl +++ Siegburg +++ Germany | | "mls at -my-domain-" +++ www.bjoern-kahl.de | | Languages: German, English, Ancient Latin (a bit :-)) | From kristian.fiskerstrand at sumptuouscapital.com Mon May 23 23:20:07 2016 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Mon, 23 May 2016 23:20:07 +0200 Subject: How to convert (ancient) key in "version 2" to more modern "version 4" format? In-Reply-To: <80d0245c-8dcf-af94-0682-4effcc10496e@bjoern-kahl.de> References: <80d0245c-8dcf-af94-0682-4effcc10496e@bjoern-kahl.de> Message-ID: On 05/23/2016 09:56 PM, Bjoern Kahl wrote: > I'd like to convert the existing secret key and the corresponding > public key, preferably without destroying the signatures, from > "version 2" to "version 4". This is not possible. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP certificate at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Primum ego, tum ego, deinde ego First I, then I, thereafter I. -------------- 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 May 23 23:24:08 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 23 May 2016 17:24:08 -0400 Subject: Encoding of user ID strings In-Reply-To: <62C7A898-2AD5-45D7-A50C-8C22E9B74194@andrewg.com> References: <485278db-6c1a-a771-c18e-b46d5eb484f7@sixdemonbag.org> <62C7A898-2AD5-45D7-A50C-8C22E9B74194@andrewg.com> Message-ID: <3de6e0bd-4e6b-1455-a9c0-9964e5ca0c8d@sixdemonbag.org> > In the case of "all 8-bit characters, no 7-bit" you're dealing with > either a practical joker or EBCDIC. Same thing really... Or KOI-8R/Windows-1251. > After that you're into heuristics. There are quite a few programs out > there that attempt to detect encodings statistically, but with such a > short string of data you might as well pick a number. ;-) Yeah, that's what I'm afraid of. It's not valid UTF-8 encodings that trouble me: it's having to deal with unknown encodings. From andrewg at andrewg.com Mon May 23 23:54:47 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 23 May 2016 23:54:47 +0200 Subject: Encoding of user ID strings In-Reply-To: <3de6e0bd-4e6b-1455-a9c0-9964e5ca0c8d@sixdemonbag.org> References: <485278db-6c1a-a771-c18e-b46d5eb484f7@sixdemonbag.org> <62C7A898-2AD5-45D7-A50C-8C22E9B74194@andrewg.com> <3de6e0bd-4e6b-1455-a9c0-9964e5ca0c8d@sixdemonbag.org> Message-ID: <8128073F-D307-483E-AA1B-3E6E643FF8D3@andrewg.com> On 23 May 2016, at 23:24, Robert J. Hansen wrote: >> In the case of "all 8-bit characters, no 7-bit" you're dealing with >> either a practical joker or EBCDIC. Same thing really... > > Or KOI-8R/Windows-1251. I'd forgotten about that. Or any of the iso-8859 that encode non-Latin scripts. Or shift-jis. Or... Or... :-( > Yeah, that's what I'm afraid of. It's not valid UTF-8 encodings that > trouble me: it's having to deal with unknown encodings. One of the little-appreciated advantages of UTF8 is that its horribly inefficient byte level encoding is so distinctive. I'm afraid this is one more case where the only reasonable position to take is "speak UTF8 or the management cannot be held responsible"... ;-) A From wk at gnupg.org Tue May 24 08:26:54 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 24 May 2016 08:26:54 +0200 Subject: Encoding of user ID strings In-Reply-To: <485278db-6c1a-a771-c18e-b46d5eb484f7@sixdemonbag.org> (Robert J. Hansen's message of "Mon, 23 May 2016 14:19:51 -0400") References: <485278db-6c1a-a771-c18e-b46d5eb484f7@sixdemonbag.org> Message-ID: <87oa7wrmxd.fsf@wheatstone.g10code.de> On Mon, 23 May 2016 20:19, rjh at sixdemonbag.org said: > At first blush it appears the answer is "no, but most people use UTF-8." > If so that's fine, but I'll have to silently discard a number of user OpenPGP requires that the user id is UTF-8 encoded. Older PGP versions did not care about encoding and used whatever the system provided. Thus there are lot's of (e.g.) M?ller with wrong encodings. This is what GPA uses to fix the problem for most of the western world's PGP users: --8<---------------cut here---------------start------------->8--- /* Due to a bug in old and not so old PGP versions user IDs have been copied verbatim into the key. Thus many users with Umlauts et al. in their name will see their names garbled. Although this is not an issue for me (;-)), I have a couple of friends with Umlauts in their name, so let's try to make their life easier by detecting invalid encodings and convert that to Latin-1. We use this even for X.509 because it may make things even better given all the invalid encodings often found in X.509 certificates. */ for (s = string; *s && !(*s & 0x80); s++) ; if (*s && ((s[1] & 0xc0) == 0x80) && ( ((*s & 0xe0) == 0xc0) || ((*s & 0xf0) == 0xe0) || ((*s & 0xf8) == 0xf0) || ((*s & 0xfc) == 0xf8) || ((*s & 0xfe) == 0xfc)) ) { /* Possible utf-8 character followed by continuation byte. Although this might still be Latin-1 we better assume that it is valid utf-8. */ return g_strdup (string); } else if (*s && !strchr (string, 0xc3)) { /* No 0xC3 character in the string; assume that it is Latin-1. */ return g_convert (string, -1, "UTF-8", "ISO-8859-1", NULL, NULL, NULL); } else { /* Everything else is assumed to be UTF-8. We do this even that we know the encoding is not valid. However as we only test the first non-ascii character, valid encodings might follow. */ return g_strdup (string); } --8<---------------cut here---------------end--------------->8--- [ Feel free to reuse - I put this snippet into the public-domain or under CC-0 ] Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ From wk at gnupg.org Tue May 24 08:32:48 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 24 May 2016 08:32:48 +0200 Subject: How to convert (ancient) key in "version 2" to more modern "version 4" format? In-Reply-To: <80d0245c-8dcf-af94-0682-4effcc10496e@bjoern-kahl.de> (Bjoern Kahl's message of "Mon, 23 May 2016 21:56:32 +0200") References: <80d0245c-8dcf-af94-0682-4effcc10496e@bjoern-kahl.de> Message-ID: <87h9dormnj.fsf@wheatstone.g10code.de> On Mon, 23 May 2016 21:56, mls at bjoern-kahl.de said: > :public key packet: > version 2, algo 1, created 1022270000, expires 0 That was created by an very old PGP-2 versions. gpg bever created a version 2 key. > Is there a way to have gpg2 convert and export the key? Looking The formats are diffefrent and even if you would use the same key material, the fingerprint and the keyid will be diffewrent. Thus there is no practial way of using it [1]. Salam-Shalom, Werner [1] if you use the key material and make a v4 key out of it, gpg should be able to decrypt keys with a wild-card keyid (--throw-keyid in gpg, can't remember the PGP-2 option). -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ From kloecker at kde.org Tue May 24 22:17:45 2016 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Tue, 24 May 2016 22:17:45 +0200 Subject: Encoding of user ID strings In-Reply-To: <87oa7wrmxd.fsf@wheatstone.g10code.de> References: <485278db-6c1a-a771-c18e-b46d5eb484f7@sixdemonbag.org> <87oa7wrmxd.fsf@wheatstone.g10code.de> Message-ID: <14083872.vVqXkvDLgD@thufir> On Tuesday 24 May 2016 08:26:54 Werner Koch wrote: > On Mon, 23 May 2016 20:19, rjh at sixdemonbag.org said: > > At first blush it appears the answer is "no, but most people use > > UTF-8."> > > If so that's fine, but I'll have to silently discard a number of > > user > > OpenPGP requires that the user id is UTF-8 encoded. Older PGP > versions did not care about encoding and used whatever the system > provided. Thus there are lot's of (e.g.) M?ller with wrong > encodings. This is what GPA uses to fix the problem for most of the > western world's PGP users: > > --8<---------------cut here---------------start------------->8--- [snip] > --8<---------------cut here---------------end--------------->8--- And if you are interested in how KMail decoded user IDs (before we completely switched to gpgme) have a look at lines 682-755 of https://quickgit.kde.org/?p=kdepim.git&a=blob&h=59d0d50433455e45680d65deaffbccd3028f2169&hb=855053a0d5a07301e1627757abf8f8d56d9759eb&f=libkpgp%2FkpgpbaseG.cpp Interesting. The code appears to be GPL2+ licensed. I would have thought that it was LGPL2+. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From cmorenot at mx1.ibm.com Tue May 24 22:09:21 2016 From: cmorenot at mx1.ibm.com (Carlos Alberto Moreno Torres) Date: Tue, 24 May 2016 15:09:21 -0500 Subject: GnuPG - Encryption process issues. Message-ID: <20160524200926.9DE6BBE038@b03ledav005.gho.boulder.ibm.com> To whom it might concern, In recent days, Human Resources Department had some issues while using the Encryption Program GnuPG in payroll activities, this issue caused a delay since files where encrypted but information was in blank (like if encryption process did not finish.) As part of remediation process, we found out that it could only work with Root Permissions but not with the current user. We want to confirm how does the encryption process works and if you can share any thoughts of what might could happen. If you require more information, please do not hesitate to ask me. Thanks in advance. Carlos A. Moreno Torres Problem Management -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Fri May 27 18:40:27 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 27 May 2016 12:40:27 -0400 Subject: problem with make in gpg2 In-Reply-To: <963DF0C368956849BD845B8EDB137D28350A07@CCLPRDEXDAG1.carnival.com> References: <963DF0C368956849BD845B8EDB137D28350A07@CCLPRDEXDAG1.carnival.com> Message-ID: <878tyvo3no.fsf@alice.fifthhorseman.net> On Mon 2016-05-23 08:34:50 -0400, Acharya, Rohit (Contractor) wrote: > I am getting this error when running the command make. I would appreciate any help I could get. > > > ../../g10/gpg2 --homedir . --quiet --yes --no-permission-warning --import ./pubdemo.asc > ld.so.1: gpg2: fatal: relocation error: file /usr/lib/libgcrypt.so.20: symbol gpgrt_lock_lock: referenced symbol not found is it possible that you're building against a different version of libgpg-error than you have installed on your system? --dkg From dkg at fifthhorseman.net Fri May 27 17:32:19 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 27 May 2016 11:32:19 -0400 Subject: GnuPG - Encryption process issues. In-Reply-To: <20160524200926.9DE6BBE038@b03ledav005.gho.boulder.ibm.com> References: <20160524200926.9DE6BBE038@b03ledav005.gho.boulder.ibm.com> Message-ID: <87r3cno6t8.fsf@alice.fifthhorseman.net> On Tue 2016-05-24 16:09:21 -0400, Carlos Alberto Moreno Torres wrote: > In recent days, Human Resources Department had some issues while using the > Encryption Program GnuPG in payroll activities, this issue caused a delay > since files where encrypted but information was in blank (like if > encryption process did not finish.) > > As part of remediation process, we found out that it could only work with > Root Permissions but not with the current user. We want to confirm how does > the encryption process works and if you can share any thoughts of what > might could happen. If you require more information, please do not hesitate > to ask me. It sounds to me like the installation of gnupg that you are using is misconfigured. GnuPG depends heavily on a "keyring" -- a collection of public key material (and sometimes private key material, if decryption or signing is needed), which it maintains in the .gnupg directory within the running user's home directory (found by the environment variable $HOME). If you've started with a normal user account, but have then run gnupg as root (e.g. using "su") without resetting $HOME to root's actual homedir (usually /root on the systems i use), then it's possible that you've created ~/.gnupg with the wrong permissions. Or, it's possible that the .gnupg directory is *only* available within root's homedir. Does your non-privileged user have a ~/.gnupg directory? if so, does it have read and write access to it? What error messages do you get from invoking gpg directly? --dkg From dashohoxha at gmail.com Sat May 28 15:32:04 2016 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Sat, 28 May 2016 15:32:04 +0200 Subject: gpg2 --fetch-keys Message-ID: Hi, I get this general error and I have no idea what is wrong: $ gpg2 --fetch-keys https://github.com/dashohoxha/egpg/raw/gnupg-2.1/tests/gnupg/DA94668A.gpg.asc gpg: requesting key from ' https://github.com/dashohoxha/egpg/raw/gnupg-2.1/tests/gnupg/DA94668A.gpg.asc ' gpg: WARNING: unable to fetch URI https://github.com/dashohoxha/egpg/raw/gnupg-2.1/tests/gnupg/DA94668A.gpg.asc: General error I am trying it in ubuntu 16.04, gpg (GnuPG) 2.1.11, libgcrypt 1.6.5 By the way, is there any reason that the ubuntu package is not updated yet to gnupg-2.1.12? It seems to me that the latest version should be more stable (more bugs fixed, etc.) Thanks, Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristian.fiskerstrand at sumptuouscapital.com Sat May 28 17:23:09 2016 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Sat, 28 May 2016 17:23:09 +0200 Subject: gpg2 --fetch-keys In-Reply-To: References: Message-ID: <7d9b7ef0-f4d4-29b5-41b2-faf2d96a3e8a@sumptuouscapital.com> On 05/28/2016 03:32 PM, Dashamir Hoxha wrote: > Hi, > > I get this general error and I have no idea what is wrong: you can increase the dirmngr verbosity in dirmngr.conf using log-file and debug / debug-level / debug-all . at least two things to look for, (i) is dirmngr compiled with gnutls support for tls and properly linked[1] (ii) is root ca properly specified[2] Notes: [1] since 2.1.12 the output of echo "KEYSERVER --help" | gpg-connect-agent --dirmngr will accurately report https depending on whether or not gnutls is included, before this easist way is likely checking ldd [2] iirc using system provided root CAs wasn't included until 2.1.12 either -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP certificate at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "When I was kidnapped, my parents snapped into action. They rented out my room." (Woody Allen) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From dashohoxha at gmail.com Sat May 28 18:08:01 2016 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Sat, 28 May 2016 18:08:01 +0200 Subject: gpg2 --fetch-keys In-Reply-To: <7d9b7ef0-f4d4-29b5-41b2-faf2d96a3e8a@sumptuouscapital.com> References: <7d9b7ef0-f4d4-29b5-41b2-faf2d96a3e8a@sumptuouscapital.com> Message-ID: On Sat, May 28, 2016 at 5:23 PM, Kristian Fiskerstrand < kristian.fiskerstrand at sumptuouscapital.com> wrote: > On 05/28/2016 03:32 PM, Dashamir Hoxha wrote: > > Hi, > > > > I get this general error and I have no idea what is wrong: > > you can increase the dirmngr verbosity in dirmngr.conf using log-file > and debug / debug-level / debug-all . Kristian, thanks for your detailed instructions. However it is not my intention to debug and to fix it. I wondered whether I, as a user, was doing something wrong. By the way, it has an easy workaround. Instead of using: gpg2 --fetch-keys uri-1 uri-2 I can do: wget -q uri-1 uri-2 gpg2 --import * Regards, Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From gpg at arccotangent.net Sat May 28 19:09:10 2016 From: gpg at arccotangent.net (Arccotangent) Date: Sat, 28 May 2016 13:09:10 -0400 Subject: problem with make in gpg2 In-Reply-To: <963DF0C368956849BD845B8EDB137D28350A07@CCLPRDEXDAG1.carnival.com> References: <963DF0C368956849BD845B8EDB137D28350A07@CCLPRDEXDAG1.carnival.com> Message-ID: <5749D0B6.6030609@arccotangent.net> This looks like a linker error with libgcrypt to me. What version of libgcrypt do you have installed? On 05/23/2016 08:34 AM, Acharya, Rohit (Contractor) wrote: > > I am getting this error when running the command make. I would > appreciate any help I could get. > > ../../g10/gpg2 --homedir . --quiet --yes --no-permission-warning > --import ./pubdemo.asc > > ld.so.1: gpg2: fatal: relocation error: file /usr/lib/libgcrypt.so.20: > symbol gpgrt_lock_lock: referenced symbol not found > > make: Fatal error: Command failed for target `all-recursive' > > Current working directory /var/spool/pkg/gnupg-2.0.30 > > *** Error code 1 > > make: Fatal error: Command failed for target `all' > > spirit1# ldd -r make > > ldd: make: cannot open file: No such file or directory > > Thanks, > > Rohit Acharya > > > > _______________________________________________ > 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 mls at bjoern-kahl.de Sat May 28 20:30:58 2016 From: mls at bjoern-kahl.de (Bjoern Kahl) Date: Sat, 28 May 2016 20:30:58 +0200 Subject: How to convert (ancient) key in "version 2" to more modern "version 4" format? In-Reply-To: <87h9dormnj.fsf@wheatstone.g10code.de> References: <80d0245c-8dcf-af94-0682-4effcc10496e@bjoern-kahl.de> <87h9dormnj.fsf@wheatstone.g10code.de> Message-ID: Am 24.05.16 um 08:32 schrieb Werner Koch: > On Mon, 23 May 2016 21:56, mls at bjoern-kahl.de said: > >> :public key packet: >> version 2, algo 1, created 1022270000, expires 0 > > That was created by an very old PGP-2 versions. gpg bever created a > version 2 key. > >> Is there a way to have gpg2 convert and export the key? Looking > > The formats are diffefrent and even if you would use the same key > material, the fingerprint and the keyid will be diffewrent. Thus there > is no practial way of using it [1]. > [1] if you use the key material and make a v4 key out of it, gpg should > be able to decrypt keys with a wild-card keyid (--throw-keyid in > gpg, can't remember the PGP-2 option). > thanks a lot for the explanations. So while theoretically possible, it would be a pretty useless exercise, since it would change the keyid and break all collected signatures. Which leaves me with the other option, teach mailvelop / openpgp.js to read v2 keys. Looking at the RFC-4880, it seems V3 and V2 keys share the same structure (section 5.5.2, page 41). Openpgp.js does handle V3 keys, but not V2. Which makes me wonder if it is enough to let V2 keys run through the same code path as the supported V3 keys, or if I am missing something important here. Thanks Bj?rn -- | Bjoern Kahl +++ Siegburg +++ Germany | | "mls at -my-domain-" +++ www.bjoern-kahl.de | | Languages: German, English, Ancient Latin (a bit :-)) | From mlisten at hammernoch.net Sat May 28 22:24:08 2016 From: mlisten at hammernoch.net (=?UTF-8?B?THVkd2lnIEjDvGdlbHNjaMOkZmVy?=) Date: Sat, 28 May 2016 22:24:08 +0200 Subject: How to convert (ancient) key in "version 2" to more modern "version 4" format? In-Reply-To: References: <80d0245c-8dcf-af94-0682-4effcc10496e@bjoern-kahl.de> <87h9dormnj.fsf@wheatstone.g10code.de> Message-ID: <39be5242-d86e-b6a4-a24a-1e07a7475c54@hammernoch.net> On 28.05.16 20:30, Bjoern Kahl wrote: > Which leaves me with the other option, teach mailvelop / > openpgp.js to read v2 keys. > > Looking at the RFC-4880, it seems V3 and V2 keys share the same > structure (section 5.5.2, page 41). Openpgp.js does handle V3 > keys, but not V2. Which makes me wonder if it is enough to let V2 > keys run through the same code path as the supported V3 keys, or if > I am missing something important here. Bj?rn, why would you want to put energy in support of such ancient keys? V3 keys aren't supported any more by GnuPG 2.1, and nobody mentioned V2 keys here for years. Usually, those keys are at best 1024 bits long which suggests that they are replaced by a adequate V4 key with recommended key length right now. They are obsolete in every aspect. Ludwig -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From mls at bjoern-kahl.de Sun May 29 00:04:13 2016 From: mls at bjoern-kahl.de (Bjoern Kahl) Date: Sun, 29 May 2016 00:04:13 +0200 Subject: How to convert (ancient) key in "version 2" to more modern "version 4" format? In-Reply-To: <39be5242-d86e-b6a4-a24a-1e07a7475c54@hammernoch.net> References: <80d0245c-8dcf-af94-0682-4effcc10496e@bjoern-kahl.de> <87h9dormnj.fsf@wheatstone.g10code.de> <39be5242-d86e-b6a4-a24a-1e07a7475c54@hammernoch.net> Message-ID: <4bc3d15a-523e-03ce-c7b6-ed19de66551c@bjoern-kahl.de> Dear Ludwig, Am 28.05.16 um 22:24 schrieb Ludwig H?gelsch?fer: > On 28.05.16 20:30, Bjoern Kahl wrote: > >> Which leaves me with the other option, teach mailvelop / >> openpgp.js to read v2 keys. >> >> Looking at the RFC-4880, it seems V3 and V2 keys share the same >> structure (section 5.5.2, page 41). Openpgp.js does handle V3 >> keys, but not V2. Which makes me wonder if it is enough to let V2 >> keys run through the same code path as the supported V3 keys, or if >> I am missing something important here. > > Bj?rn, why would you want to put energy in support of such ancient > keys? V3 keys aren't supported any more by GnuPG 2.1, and nobody > mentioned V2 keys here for years. Usually, those keys are at best 1024 > bits long which suggests that they are replaced by a adequate V4 key > with recommended key length right now. Very simple: Because I have *tons* of mails (and other archived data files) that have been signed and / or encrypted with such keys and I (I have to use such a strong word here) *insist* on being able to continue to read these mails and files whenever the need arises. > They are obsolete in every aspect. They may not be a wise choice for creating new data (mails, files) for their limited key length and other shortcomings mentioned in 4880 and elsewhere. But they are perfectly fine and necessary to access historic data. Best Bj?rn -- | Bjoern Kahl +++ Siegburg +++ Germany | | "mls at -my-domain-" +++ www.bjoern-kahl.de | | Languages: German, English, Ancient Latin (a bit :-)) | From antony at blazrsoft.com Sun May 29 08:06:58 2016 From: antony at blazrsoft.com (Antony Prince) Date: Sun, 29 May 2016 02:06:58 -0400 Subject: How to convert (ancient) key in "version 2" to more modern "version 4" format? In-Reply-To: <4bc3d15a-523e-03ce-c7b6-ed19de66551c@bjoern-kahl.de> References: <80d0245c-8dcf-af94-0682-4effcc10496e@bjoern-kahl.de> <87h9dormnj.fsf@wheatstone.g10code.de> <39be5242-d86e-b6a4-a24a-1e07a7475c54@hammernoch.net> <4bc3d15a-523e-03ce-c7b6-ed19de66551c@bjoern-kahl.de> Message-ID: <574A8702.9030602@blazrsoft.com> On 5/28/2016 6:04 PM, Bjoern Kahl wrote: > > Because I have *tons* of mails (and other archived data files) that > have been signed and / or encrypted with such keys and I (I have to > use such a strong word here) *insist* on being able to continue to > read these mails and files whenever the need arises. > > >> They are obsolete in every aspect. > > They may not be a wise choice for creating new data (mails, files) for > their limited key length and other shortcomings mentioned in 4880 and > elsewhere. But they are perfectly fine and necessary to access > historic data. > The best solution I could think of would be to use a version of PGP that is capable of decrypting the mails and using a newer key with a modern version of gpg to re-encrypt them to your new key for storage. A script could be written for the purpose. This still doesn't solve the problem of the signatures, but at the least you would be able to keep the archived files encrypted with the newer standards and eliminate the need for supporting obsolete keys any further than this point for decryption. Not the most elegant solution or even one you may want, but it is *a* solution, provided that you can find software to use the V2 keys of course. -- Antony -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 884 bytes Desc: OpenPGP digital signature URL: From flapflap at riseup.net Sun May 29 13:43:18 2016 From: flapflap at riseup.net (flapflap) Date: Sun, 29 May 2016 11:43:18 +0000 Subject: How to convert (ancient) key in "version 2" to more modern "version 4" format? In-Reply-To: <574A8702.9030602@blazrsoft.com> References: <80d0245c-8dcf-af94-0682-4effcc10496e@bjoern-kahl.de> <87h9dormnj.fsf@wheatstone.g10code.de> <39be5242-d86e-b6a4-a24a-1e07a7475c54@hammernoch.net> <4bc3d15a-523e-03ce-c7b6-ed19de66551c@bjoern-kahl.de> <574A8702.9030602@blazrsoft.com> Message-ID: <574AD5D6.7010500@riseup.net> Antony Prince: > On 5/28/2016 6:04 PM, Bjoern Kahl wrote: >> >> Because I have *tons* of mails (and other archived data files) that >> have been signed and / or encrypted with such keys and I (I have to >> use such a strong word here) *insist* on being able to continue to >> read these mails and files whenever the need arises. >> >> >>> They are obsolete in every aspect. >> >> They may not be a wise choice for creating new data (mails, files) for >> their limited key length and other shortcomings mentioned in 4880 and >> elsewhere. But they are perfectly fine and necessary to access >> historic data. >> > > The best solution I could think of would be to use a version of PGP that > is capable of decrypting the mails and using a newer key with a modern > version of gpg to re-encrypt them to your new key for storage. A script > could be written for the purpose. This still doesn't solve the problem > of the signatures, but at the least you would be able to keep the > archived files encrypted with the newer standards and eliminate the need > for supporting obsolete keys any further than this point for decryption. > Not the most elegant solution or even one you may want, but it is *a* > solution, provided that you can find software to use the V2 keys of course. (Disclaimer: I'm not 100% sure if this really works, it's just how I think it could work with more recent keys) You could try the "Decrypt Permanently" or "Create Decrypted Copy" functions added by Enigmail to the Thunderbird Message Filters (Tools -> Message Filters) and use an old version of gnupg that still supportes your old keys (has GPG ever supported V2 keys?). This decrypts the messages but also strips/removes signatures on messages, so you loose information whether a message was signed or not afterwards. By doing this on an encrypted disk (e.g., LUKS) you don't accidentially store decrypted copies of the confidential emails and for future usage you won't need the old keys any more (just the passphrase for LUKS). ~flapflap From holtzm at cox.net Sun May 29 20:29:02 2016 From: holtzm at cox.net (Bob Holtzman) Date: Sun, 29 May 2016 11:29:02 -0700 Subject: no passphrase request Message-ID: <20160529182902.GA11127@cox.net> Running Debian Jessie with mutt 1.5.23 and gnupg 1.4.18-7 (yeah, I know it's old, but then so am I) Trying to send an test message to myself using mutts' compiled-in gpg support. After selecting an action from the menu, (sign encrypt, etc) and hitting return, I'm prompted for a key ID, never for a passphrase. The message then refuses to send. In checking for mutts' compiled options, I ran across this which may have some bearing on what I'm seeing, or not. The options in question are: +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME +CRYPT_BACKEND_GPGME. I'm assuming if it handles classic pgp it will also handle gnupg. Yes? Searches and doc reading haven't turned up much of anything. Any pointers on how to get out of this appreciated. -- Bob Holtzman A man is a man who will fight with a sword or conquer Mt. Everest in snow. But the bravest of all owns a '34 Ford and tries for six thousand in low. From dkg at fifthhorseman.net Tue May 31 17:04:43 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 31 May 2016 11:04:43 -0400 Subject: no passphrase request In-Reply-To: <20160529182902.GA11127@cox.net> References: <20160529182902.GA11127@cox.net> Message-ID: <874m9ei7zo.fsf@alice.fifthhorseman.net> On Sun 2016-05-29 14:29:02 -0400, Bob Holtzman wrote: > Running Debian Jessie with mutt 1.5.23 and gnupg 1.4.18-7 (yeah, I know > it's old, but then so am I) > > Trying to send an test message to myself using mutts' compiled-in gpg > support. After selecting an action from the menu, (sign encrypt, etc) and > hitting return, I'm prompted for a key ID, never for a passphrase. The > message then refuses to send. > > In checking for mutts' compiled options, I ran across this which may > have some bearing on what I'm seeing, or not. The options in question > are: +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME > +CRYPT_BACKEND_GPGME. I'm assuming if it handles classic pgp it will > also handle gnupg. Yes? > > Searches and doc reading haven't turned up much of anything. > > Any pointers on how to get out of this appreciated. This sounds like a Mutt issue more than a GnuPG issue. You might try the Mutt mailing lists or the Mutt wiki: http://www.mutt.org/mail-lists.html https://dev.mutt.org/trac/wiki/MuttWiki hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From dkg at fifthhorseman.net Tue May 31 19:47:41 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 31 May 2016 13:47:41 -0400 Subject: Fw: GnuPG - Encryption process issues. In-Reply-To: <20160531155720.8725ABE04C@b03ledav005.gho.boulder.ibm.com> References: <20160531155720.8725ABE04C@b03ledav005.gho.boulder.ibm.com> Message-ID: <87shwyglvm.fsf@alice.fifthhorseman.net> Hi Carlos-- Please reply in the original thread, to make it easier for people to follow the discussion. I've added some References: headers back in here so some mailers might merge the threads, but this won't work for everyone. Also, when sharing terminal transcripts, sending mail without unnecessary line-wrapping will make them much easier for your readers to interpret. It looks like you're trying to sign the file (that's what the "-s" part of "-se" means). For whatever reason, the signature itself is likely to be what is failing, and not the encryption. If you drop the signatures in your test (using -e instead of -se) do they all complete cleanly? To be clear: I'm not saying you shouldn't sign at the same time as encrypting, i'm trying to help you narrow down the cause of the problem. I also see you fiddling with the ownership of ~/.gnupg/random_seed -- you really shouldn't need to do that, and ideally each user will control their own random_seed automatically -- you shouldn't be sharing a gnupg home directory between to different user accounts unless you absolutely need to. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From cmorenot at mx1.ibm.com Tue May 31 17:57:14 2016 From: cmorenot at mx1.ibm.com (Carlos Alberto Moreno Torres) Date: Tue, 31 May 2016 10:57:14 -0500 Subject: Fw: GnuPG - Encryption process issues. In-Reply-To: References: Message-ID: <20160531155752.6F78512404E@b01ledav002.gho.pok.ibm.com> Dear Daniel Kahn Gillmor, Please find the information/evidence requested below provided by our Unix Team Specialist, it is very important for us your input since it will help to find the specific Root Cause. If you require additional details, please do not hesitate to ask. Thanks in advance. @ Thanks Ankit for your detailed response. Carlos A. Moreno Torres Problem Management | CEMEX Global Technology Services | IBM Corporation Office:?(+52-81) 8328-5251 IBM E-mail:?cmorenot at mx1.ibm.com Av. Constituci?n No. 444 Pte. IBM @ CEMEX Collaboration HUB: ibm.biz/Bdx93b Monterrey, NL 64000 M?xico From: Ankit Bhardwaj5/India/IBM To: Carlos Alberto Moreno Torres/Mexico/Contr/IBM at IBMMX Cc: Ajay B Challa/India/IBM at IBMIN, Ivan Fernando Montes de Oca Tavera/Mexico/Contr/IBM at IBMMX, "Juan Carlos Garcia" , Samuel Ramos Javier/Mexico/IBM at IBMMX, "Samuel Mizrain Ramos Javier" , Srinivas Masetty/India/IBM at IBMIN Date: 05/31/2016 10:46 AM Subject: Re: Fw: GnuPG - Encryption process issues. Hello Carlos Please share below information with GPG team i think by seeing the results of test performed by us on system they will able to give us the solution We have tested below things in envirnoment -> Userd Details used in this test root ehpadm Permissions under user "root" -> Directory Permission of root drwx------ 2 root sapsys 4096 May 31 09:39 /home/root/.gnupg -> Files Under /home/root/.gnupg -rw------- 1 root sapsys 1280 Sep 13 2011 trustdb.gpg -rw------- 1 root sapsys 4805 Sep 13 2011 secring.gpg -r-------- 1 root sapsys 9088 Sep 13 2011 gpg.conf -rw------- 1 root sapsys 7438 May 21 2013 pubring.gpg~ -rw------- 1 root sapsys 8557 Nov 8 2013 pubring.gpg -rw------- 1 root sapsys 11 Apr 28 08:44 .#lk200104a8.mxoccsapehpn2.8716480 -rw------- 1 root sapsys 11 Apr 28 08:53 .#lk2000c2c8.mxoccsapehpn2.11141460 -rw------- 1 root sapsys 11 Apr 28 12:00 .#lk200104b8.mxoccsapehpn2.8978598 -rw------- 1 root sapsys 11 Apr 29 08:57 .#lk2000c2c8.mxoccsapehpn2.12911042 -rw------- 1 root sapsys 11 May 2 11:32 .#lk200104b8.mxoccsapehpn2.10748294 -rw------- 1 root sapsys 11 May 2 19:34 .#lk200104b8.mxoccsapehpn2.7471568 -rw------- 1 root sapsys 11 May 2 22:23 .#lk2000c328.mxoccsapehpn2.12058746 -rw------- 1 root sapsys 11 May 2 23:46 .#lk200104b8.mxoccsapehpn2.6750230 -rw------- 1 root sapsys 11 May 3 10:28 .#lk200104b8.mxoccsapehpn2.14221392 -rw------- 1 root sapsys 11 May 3 13:45 .#lk200104b8.mxoccsapehpn2.9240874 -rw------- 1 root sapsys 600 May 31 09:39 random_seed ->Permissions under user "ehpadm" drwx------ 2 ehpadm sapsys 4096 May 31 09:48 /home/ehpadm/.gnupg -> Files Under /home/ehpadm/.gnupg -rw------- 1 ehpadm sapsys 1200 May 3 21:54 trustdb.gpg -rw------- 1 ehpadm sapsys 7438 May 3 21:54 pubring.gpg~ -rw------- 1 ehpadm sapsys 8557 May 3 21:54 pubring.gpg -rw------- 1 ehpadm sapsys 4805 May 3 21:54 secring.gpg -rw------- 1 ehpadm sapsys 11 May 3 22:03 .#lk200104b8.mxoccsapehpn2.6488076 -rw------- 1 ehpadm sapsys 9029 May 4 11:18 gpg.conf -rw------- 1 ehpadm sapsys 11 May 4 13:43 .#lk2000c328.mxoccsapehpn2.6160766 -rw------- 1 ehpadm sapsys 11 May 4 13:55 .#lk2000c328.mxoccsapehpn2.8913004 -rw------- 1 ehpadm sapsys 11 May 4 15:55 .#lk2000c328.mxoccsapehpn2.12976528 -rw------- 1 ehpadm sapsys 11 May 4 17:58 .#lk2000c328.mxoccsapehpn2.10158578 -rw------- 1 ehpadm sapsys 11 May 4 18:06 .#lk2000c328.mxoccsapehpn2.5308674 -rw------- 1 ehpadm sapsys 0 May 31 10:00 random_seed #### Test 1 ##### -------Failed Test ->Created file name "testehpadm" in ehpadm home directory -rw-r--r-- 1 ehpadm sapsys 6 May 31 10:06 /home/ehpadm/testehpadm -> Invoke GPG progrma using below command /opt/freeware/gnupg/bin/gpg -v -u cxcxmxmt-py -se --armor --output /home/ehpadm/testehpadm.pgp -r HSBCnet******2020-07-20 --trust-model always /home/ehpadm/testehpadm -> Output of command gpg: using subkey B6BC9FE5 instead of primary key D8F5ECAE gpg: No trust check due to `--trust-model always' option gpg: writing to `/home/ehpadm/testehpadm.pgp' -> command is not exiting , we have to forecfully kill the command every time and file generated by PGP is zero bytes -rw-r--r-- 1 ehpadm sapsys 0 May 31 10:06 /home/ehpadm/testehpadm.pgp #### Test 2 ##### --------Successful Test ->Created file name "testroot" in root home directory -rw-r--r-- 1 root system 7 May 31 10:11 /home/root/testroot -> Invoke GPG progrma using below command /opt/freeware/gnupg/bin/gpg -v -u cxcxmxmt-py -se --armor --output /home/root/testroot.pgp -r HSBCnet******2020-07-20 --trust-model always /home/root/testroot -> Output of command gpg: using subkey B6BC9FE5 instead of primary key D8F5ECAE gpg: No trust check due to `--trust-model always' option gpg: writing to `/home/root/testroot.pgp' gpg: RSA/AES256 encrypted for: "B6BC9FE5 HSBCnet******2020-07-20" gpg: RSA/SHA1 signature from: "5FBFB2DF cxcxmxmt-py (exp:2026-07-22)" Test completed successfully with no errors -rw-r--r-- 1 root system 1649 May 31 10:12 /home/root/testroot.pgp #### Test 3 ##### ---------Test is successful but giving some error ->Created file name "testehpadm" in ehpadm home directory -rw-r--r-- 1 ehpadm sapsys 6 May 31 10:06 /home/ehpadm/testehpadm -> Changed the owner of "random seed" file to root so that ehpadm can not write to random_seed file -rw------- 1 root system 0 May 31 10:00 /home/ehpadm/.gnupg/random_seed -> Invoke GPG progrma using below command /opt/freeware/gnupg/bin/gpg -v -u cxcxmxmt-py -se --armor --output /home/ehpadm/testehpadm.pgp -r HSBCnet******2020-07-20 --trust-model always /home/ehpadm/testehpadm -> Output of command gpg: using subkey B6BC9FE5 instead of primary key D8F5ECAE gpg: No trust check due to `--trust-model always' option File `/home/ehpadm/testehpadm.pgp' exists. Overwrite? (y/N) y gpg: writing to `/home/ehpadm/testehpadm.pgp' gpg: can't open `/home/ehpadm/.gnupg/random_seed': Permission denied gpg: RSA/AES256 encrypted for: "B6BC9FE5 HSBCnet******2020-07-20" gpg: RSA/SHA1 signature from: "5FBFB2DF cxcxmxmt-py (exp:2026-07-22)" gpg: note: random_seed file not updated -> command is exiting successfully , but below errors are coming gpg: can't open `/home/ehpadm/.gnupg/random_seed': Permission denied gpg: note: random_seed file not updated Encrypted file is generated -rw-r--r-- 1 ehpadm sapsys 1654 May 31 10:25 /home/ehpadm/testehpadm.pgp So when we have original random seed file in home directory of ehpadm user, gpg encryption program is not working and when we change the owner of this file and make root as the owner gpg is bypassing this file and it generated the encypted file with below error as in TEST 3 gpg: can't open `/home/ehpadm/.gnupg/random_seed': Permission denied gpg: note: random_seed file not updated Regards, ANKIT BHARDWAJ SME - AIX Mobile: 91-9000-146341 IBM E-mail: ankit.bhardwaj3 at in.ibm.com From: Carlos Alberto Moreno Torres/Mexico/Contr/IBM To: Ankit Bhardwaj5/India/IBM at IBMIN Cc: "Juan Carlos Garcia" , Srinivas Masetty/India/IBM at IBMIN, Ajay B Challa/India/IBM at IBMIN, Samuel Ramos Javier/Mexico/IBM at IBMMX, "Samuel Mizrain Ramos Javier" , Ivan Fernando Montes de Oca Tavera/Mexico/Contr/IBM at IBMMX Date: 05/31/2016 07:11 PM Subject: Fw: GnuPG - Encryption process issues. Hi Ankit, Please confirm if information provided by GnuPG Support Team lead us to a specific Root Cause or if more details are required, since issue can occur again, generating another RCA with higher visibility. Thanks in advance. Carlos A. Moreno Torres Problem Management | CEMEX Global Technology Services | IBM Corporation Office:?(+52-81) 8328-5251 IBM E-mail:?cmorenot at mx1.ibm.com Av. Constituci?n No. 444 Pte. IBM @ CEMEX Collaboration HUB: ibm.biz/Bdx93b Monterrey, NL 64000 M?xico ----- Forwarded by Carlos Alberto Moreno Torres/Mexico/Contr/IBM on 05/31/2016 08:36 AM ----- From: Carlos Alberto Moreno Torres/Mexico/Contr/IBM To: "Juan Carlos Garcia" , Juan Carlos Garcia Dominguez/Mexico/Contr/IBM at IBMMX, Ankit Bhardwaj5/India/IBM at IBMIN Cc: Samuel Ramos Javier/Mexico/IBM at IBMMX, "Samuel Mizrain Ramos Javier" , Ivan Fernando Montes de Oca Tavera/Mexico/Contr/IBM at IBMMX Date: 05/27/2016 03:05 PM Subject: Fw: GnuPG - Encryption process issues. FYI Carlos A. Moreno Torres Problem Management | CEMEX Global Technology Services | IBM Corporation Office:?(+52-81) 8328-5251 IBM E-mail:?cmorenot at mx1.ibm.com Av. Constituci?n No. 444 Pte. IBM @ CEMEX Collaboration HUB: ibm.biz/Bdx93b Monterrey, NL 64000 M?xico ----- Forwarded by Carlos Alberto Moreno Torres/Mexico/Contr/IBM on 05/27/2016 03:04 PM ----- From: Daniel Kahn Gillmor To: Carlos Alberto Moreno Torres/Mexico/Contr/IBM at IBMMX, gnupg-users at gnupg.org Date: 05/27/2016 10:32 AM Subject: Re: GnuPG - Encryption process issues. On Tue 2016-05-24 16:09:21 -0400, Carlos Alberto Moreno Torres wrote: > In recent days, Human Resources Department had some issues while using the > Encryption Program GnuPG in payroll activities, this issue caused a delay > since files where encrypted but information was in blank (like if > encryption process did not finish.) > > As part of remediation process, we found out that it could only work with > Root Permissions but not with the current user. We want to confirm how does > the encryption process works and if you can share any thoughts of what > might could happen. If you require more information, please do not hesitate > to ask me. It sounds to me like the installation of gnupg that you are using is misconfigured. GnuPG depends heavily on a "keyring" -- a collection of public key material (and sometimes private key material, if decryption or signing is needed), which it maintains in the .gnupg directory within the running user's home directory (found by the environment variable $HOME). If you've started with a normal user account, but have then run gnupg as root (e.g. using "su") without resetting $HOME to root's actual homedir (usually /root on the systems i use), then it's possible that you've created ~/.gnupg with the wrong permissions. Or, it's possible that the .gnupg directory is *only* available within root's homedir. Does your non-privileged user have a ~/.gnupg directory? if so, does it have read and write access to it? What error messages do you get from invoking gpg directly? --dkg -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 06468598.gif Type: image/gif Size: 2022 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: