From rjh at sixdemonbag.org Thu Dec 1 03:54:06 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 30 Nov 2016 21:54:06 -0500 Subject: libgpgme-11.dll Message-ID: For long and boring reasons I need to be able to call GPGME from Microsoft Visual C++. The MSVC linker requires .lib files, which are not shipped with GnuPG. That's okay: the procedure to make them is pretty straightforward. For each of libgpgme-11.dll, libgpg-error-0.dll, and libassuan-0.dll, I: 1. ran dumpbin /exports on it, to recover the function names 2. put these function names in a text file with "EXPORTS" at the top 3. ran lib /def:somefile.def /out:somefile.lib to create the .libs (Insert appropriate filenames for "somefile", of course.) A really basic test of GPGME passes: I can link against gpgme_check_version and confirm the correct version of GPGME. However, I can't actually *do* anything with it: gpgme_engine_check_version continually throws an invalid engine error, and gpgme_get_dirinfo keeps on returning nulls. So, if I had to wager a guess, GPGME isn't able to find GnuPG. My sample code runs just fine on OS X and Linux, incidentally, so I doubt the problem is with it. (If people want to see it just to make sure, I'm happy to provide it.) Anyone have any ideas? From wk at gnupg.org Thu Dec 1 09:21:26 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 01 Dec 2016 09:21:26 +0100 Subject: Is there a =?utf-8?B?4oCcZ3JvdW5kLXVw4oCd?= explanation of PGP/GnuPG? In-Reply-To: <87a8ch2ahd.fsf@vps.i-did-not-set--mail-host-address--so-tickle-me> (Chris's message of "Wed, 30 Nov 2016 16:33:50 +0000") References: <87a8ch2ahd.fsf@vps.i-did-not-set--mail-host-address--so-tickle-me> Message-ID: <87oa0w3vqx.fsf@wheatstone.g10code.de> On Wed, 30 Nov 2016 17:33, k at rdw.se said: > Is there a "from the ground up" good guide to PGP that allows me to > break out of this pattern? You may watch Neal's "An Advanced Intro to GnuPG": Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From wk at gnupg.org Thu Dec 1 09:33:56 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 01 Dec 2016 09:33:56 +0100 Subject: libgpgme-11.dll In-Reply-To: (Robert J. Hansen's message of "Wed, 30 Nov 2016 21:54:06 -0500") References: Message-ID: <87k2bk3v63.fsf@wheatstone.g10code.de> On Thu, 1 Dec 2016 03:54, rjh at sixdemonbag.org said: > For long and boring reasons I need to be able to call GPGME from > Microsoft Visual C++. The MSVC linker requires .lib files, which are > not shipped with GnuPG. That's okay: the procedure to make them is The gnupg 2.1 installer actually installs all header files as well as the the .lib files (look for *.imp). Note that the -11 suffix is not used with the imp files. If you are using glib or gtk+ make sure to link against libgpgme-glib.imp. > My sample code runs just fine on OS X and Linux, incidentally, so I > doubt the problem is with it. (If people want to see it just to make set GPGME_DEBUG=9;c:/temp/gpgme.log mygpgmebasedtool and then look at the log file. It will show you where it looks for gnupg. The code in gpgme works even for gnupg 1.4 but it prefers gnupg 2.x. Did you install gpgme-w32spawn.exe alongside gpgme-11.dll ? This wrapper is required due to pecularities of Windows' CreateProcess API. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From rjh at sixdemonbag.org Thu Dec 1 12:51:27 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 1 Dec 2016 06:51:27 -0500 Subject: libgpgme-11.dll In-Reply-To: <87k2bk3v63.fsf@wheatstone.g10code.de> References: <87k2bk3v63.fsf@wheatstone.g10code.de> Message-ID: <718bf166-751e-c070-6829-63d9ed13eb85@sixdemonbag.org> > Did you install gpgme-w32spawn.exe alongside gpgme-11.dll ? This > wrapper is required due to pecularities of Windows' CreateProcess > API. I did not, and this was the problem. Thank you, Werner. :) From dsaklad at gnu.org Fri Dec 2 00:54:19 2016 From: dsaklad at gnu.org (Don Saklad) Date: Thu, 01 Dec 2016 18:54:19 -0500 Subject: How do you let your M.D. know about emailselfdefense.org and gnupg.org so that it's easier for folks unfamiliar to setup and use than having to go over the too long material, the too complicated material? Message-ID: <5i1sxrb3ys.fsf@fencepost.gnu.org> How do you let your M.D. know about emailselfdefense.org and gnupg.org so that it's easier for folks unfamiliar to setup and use than having to go over the too long material, the too complicated material? From lists at bertram-scharpf.de Fri Dec 2 03:12:50 2016 From: lists at bertram-scharpf.de (Bertram Scharpf) Date: Fri, 2 Dec 2016 03:12:50 +0100 Subject: Proof for a creation date Message-ID: <20161202021250.GA69543@becker.bs.l> Hi, we all know that kidnappers do publish a picture of their hostage holding up a todays newpaper. The purpose of this is to proof that the victim was alive _after_ a certain point of time. I want to do the opposite. I want to make evidence that I created a document _before_ a certain point of time. I could use self-darkening ink but that won't be reflected in a JPEG scan and my pen won't make the job that TeX does. I could sign a newspapers home page but that cannot be reproduced at a later point of time to verify the signature. Is there a standard way in GnuPG and in the keyholder infrastructure to accomplish this task? Thanks in advance. Bertram -- Bertram Scharpf Stuttgart, Deutschland/Germany http://www.bertram-scharpf.de From dkg at fifthhorseman.net Fri Dec 2 05:49:38 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 01 Dec 2016 23:49:38 -0500 Subject: Proof for a creation date In-Reply-To: <20161202021250.GA69543@becker.bs.l> References: <20161202021250.GA69543@becker.bs.l> Message-ID: <87polbue8t.fsf@alice.fifthhorseman.net> On Thu 2016-12-01 21:12:50 -0500, Bertram Scharpf wrote: > I want to make evidence that I created a document _before_ a certain > point of time. One approach i've seen recommended is to create a cryptographically-strong digest of the signed document in question and then post it to a public, append-only log somewhere. For example, take the SHA256 digest of the document, pretend that value is the address of a bitcoin wallet, and throw a little bit of bitcoin into it (this value will never be recoverable because no one knows the corresponding secret key). This puts the digest into the blockchain at a acertain date for anyone to see. Your subsequent argument is that one of the two possibilities must hold: (a) you have some ability to perform a collision attack against SHA-256, or (b) the signed document existed at some point before the bitcoin transaction was publicly logged. since most people won't believe (a), (b) looks pretty likely. You could use any other globally-visible log that allows for injection of a bitstring long enough for a strong digest (32 octets is probably sufficient), it doesn't have to be the bitcoin blockchain. for example, if you can get something into a public X.509 certificate, you could post it to one of the certificate transparency logs. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From aarcane at aarcane.org Fri Dec 2 04:59:15 2016 From: aarcane at aarcane.org (Schlacta, Christ) Date: Thu, 1 Dec 2016 19:59:15 -0800 Subject: Proof for a creation date In-Reply-To: <20161202021250.GA69543@becker.bs.l> References: <20161202021250.GA69543@becker.bs.l> Message-ID: The easiest way is to publish your code to a publicly controlled source with a signature on or before your desired date. Not sure if there's a *better* way. On Dec 1, 2016 7:43 PM, "Bertram Scharpf" wrote: > Hi, > > we all know that kidnappers do publish a picture of their > hostage holding up a todays newpaper. The purpose of this is > to proof that the victim was alive _after_ a certain point > of time. I want to do the opposite. I want to make evidence > that I created a document _before_ a certain point of time. > > I could use self-darkening ink but that won't be reflected > in a JPEG scan and my pen won't make the job that TeX does. > I could sign a newspapers home page but that cannot be > reproduced at a later point of time to verify the signature. > > Is there a standard way in GnuPG and in the keyholder > infrastructure to accomplish this task? > > Thanks in advance. > > Bertram > > > -- > Bertram Scharpf > Stuttgart, Deutschland/Germany > http://www.bertram-scharpf.de > > _______________________________________________ > 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 rjh at sixdemonbag.org Fri Dec 2 07:05:44 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 2 Dec 2016 01:05:44 -0500 Subject: gpgme 1.8 build failure (again) Message-ID: Last month I had a build failure for GPGME 1.8 on macOS. I reported it to the list and received a useful answer about a custom preprocessor define that should've been, but was apparently was not, used. Unfortunately I didn't write this down, and the email thread is not in the archive. (Only one message seems to be: https://lists.gnupg.org/pipermail/gnupg-users/2016-November/057047.html ) Can anyone give me once again the magic invocation needed? Thanks. :) From christian.heinrich at cmlh.id.au Fri Dec 2 05:51:30 2016 From: christian.heinrich at cmlh.id.au (Christian Heinrich) Date: Fri, 2 Dec 2016 15:51:30 +1100 Subject: How do you let your M.D. know about emailselfdefense.org and gnupg.org so that it's easier for folks unfamiliar to setup and use than having to go over the too long material, the too complicated material? In-Reply-To: <5i1sxrb3ys.fsf@fencepost.gnu.org> References: <5i1sxrb3ys.fsf@fencepost.gnu.org> Message-ID: Don, S/MIME has a lower barrier to entry if it is just for e-mail in Outlook, etc On Fri, Dec 2, 2016 at 10:54 AM, Don Saklad wrote: > How do you let your M.D. know about emailselfdefense.org and gnupg.org > so that it's easier for folks unfamiliar to setup and use than having to > go over the too long material, the too complicated material? -- Regards, Christian Heinrich http://cmlh.id.au/contact From quanzhou822 at gmail.com Fri Dec 2 06:37:00 2016 From: quanzhou822 at gmail.com (Quan Zhou) Date: Fri, 2 Dec 2016 13:37:00 +0800 Subject: Proof for a creation date In-Reply-To: References: <20161202021250.GA69543@becker.bs.l> Message-ID: so GnuPG's timestamping isn't an option for this? Even X509 has a timestamping feature for this kind of use. On Fri, Dec 2, 2016 at 11:59 AM, Schlacta, Christ wrote: > The easiest way is to publish your code to a publicly controlled source > with a signature on or before your desired date. Not sure if there's a > *better* way. > > On Dec 1, 2016 7:43 PM, "Bertram Scharpf" > wrote: > >> Hi, >> >> we all know that kidnappers do publish a picture of their >> hostage holding up a todays newpaper. The purpose of this is >> to proof that the victim was alive _after_ a certain point >> of time. I want to do the opposite. I want to make evidence >> that I created a document _before_ a certain point of time. >> >> I could use self-darkening ink but that won't be reflected >> in a JPEG scan and my pen won't make the job that TeX does. >> I could sign a newspapers home page but that cannot be >> reproduced at a later point of time to verify the signature. >> >> Is there a standard way in GnuPG and in the keyholder >> infrastructure to accomplish this task? >> >> Thanks in advance. >> >> Bertram >> >> >> -- >> Bertram Scharpf >> Stuttgart, Deutschland/Germany >> http://www.bertram-scharpf.de >> >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users >> > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > -- Regards, Quan Zhou +------------------------+ |pub [expires 2019-05-04]| |D7CF DCE8 2EBA 2766 499A| |20DF 8273 6C6F ABCD 0A0F| +------------------------+ |pub [revoked 2016-04-16]| |44D2 0307 1643 E80F 2E31| |F081 FAFA 6643 7F9F D46F| +------------------------+ |quanzhou822 at gmail.com | |https://keybase.io/qzhou| +------------------------+ -------------- next part -------------- An HTML attachment was scrubbed... URL: From vedaal at nym.hush.com Fri Dec 2 05:22:16 2016 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Thu, 01 Dec 2016 23:22:16 -0500 Subject: How do you let your M.D. know about emailselfdefense.org and gnupg.org so that it's easier for folks unfamiliar to setup and use than having to go over the too long material, the too complicated material? In-Reply-To: <5i1sxrb3ys.fsf@fencepost.gnu.org> Message-ID: <20161202042216.72F89200FC@smtp.hushmail.com> On 12/1/2016 at 7:40 PM, "Don Saklad" wrote:How do you let your M.D. know about emailselfdefense.org and gnupg.org so that it's easier for folks unfamiliar to setup and use than having to go over the too long material, the too complicated material? ===== Hushmail has a marketing pitch to Medical Personnel about compliance with medical privacy laws, and allows hushmail users to send encrypted e-mails to any email address even if the receiver does not use hushmail. The receiver gets a message that an encrypted e-mail has been sent, and a link to a site where it is stored for only 72 hours. Upon following the link, the receiver types in an answer to a pre-arranged question between the doctor and the patient, and sees the plaintext, and/or the file attachment. The receiver is allowed only 3 tries, and if all are wrong, the message is removed from the site. So it's pretty simple to use, (simple enough that busy doctors are not interested in learning GnuPG :-((((( ) The doctor calls the patient, and arranges the question and answer, and then can send files encrypted as attachments. An MITM attack is not practical as the doctor and patient share the secret over a different channel (phone, person to person in the office, etc.) It is, however, very vulnerable to a DNS attack. The MITM can simply access the site, enter the wrong answer 3 times, and the message is removed. I pointed this out to a doctor who uses this, and his response was basically that it's "not in his threat model", (although it was much longer in ordinary language.) The only suggestion I would have, is for a similar e-mail service that uses GnuPG, without a backdoor for the government, which Hushmail has, and market this to the "Patients", and have a link to an easy GnuPG gui tutorial, once people think that encryption can be useful and 'fun'. vedaal -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernhard at intevation.de Fri Dec 2 08:39:20 2016 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 2 Dec 2016 08:39:20 +0100 Subject: How do you help someone to encrypted email (Re: How do you let your M.D. ...) In-Reply-To: <5i1sxrb3ys.fsf@fencepost.gnu.org> References: <5i1sxrb3ys.fsf@fencepost.gnu.org> Message-ID: <201612020839.24050.bernhard@intevation.de> > so that it's easier for folks unfamiliar to setup and use than having to > go over the too long material Within next year, someone will just need to use an email client that support the following technical solution: https://wiki.gnupg.org/WKD This is something the GnuPG team is actively working on. 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 wk at gnupg.org Fri Dec 2 10:44:25 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 02 Dec 2016 10:44:25 +0100 Subject: gpgme 1.8 build failure (again) In-Reply-To: (Robert J. Hansen's message of "Fri, 2 Dec 2016 01:05:44 -0500") References: Message-ID: <87lgvywtqe.fsf@wheatstone.g10code.de> On Fri, 2 Dec 2016 07:05, rjh at sixdemonbag.org said: > Unfortunately I didn't write this down, and the email thread is not in > the archive. (Only one message seems to be: The mails went to gnupg-devel and only one to gnupg-users. I am not sure whether this was helpful but I wrote We are still using x86_64-apple-darwin15.5.0 with ./configure --prefix=/Users/jenkins/prefix/native --enable-maintainer-mode 'CFLAGS= -D_DARWIN_C_SOURCE=900000L -fPIC' 'CXXFLAGS= -D_DARWIN_C_SOURCE=900000L -fPIC -std=c++11' and we see no problems. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From stebe at mailbox.org Fri Dec 2 14:46:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Fri, 02 Dec 2016 13:46:00 +0000 Subject: Proof for a creation date In-Reply-To: References: <20161202021250.GA69543@becker.bs.l> Message-ID: <96a4d163-02fb-096e-a75e-980f0ee61da3@mailbox.org> Hi Quan Zhou, Quan Zhou: > so GnuPG's timestamping isn't an option for this? > Even X509 has a timestamping feature for this kind of use. > > On Fri, Dec 2, 2016 at 11:59 AM, Schlacta, Christ > wrote: > >> The easiest way is to publish your code to a publicly controlled source >> with a signature on or before your desired date. Not sure if there's a >> *better* way. >> >> On Dec 1, 2016 7:43 PM, "Bertram Scharpf" >> wrote: [...] >>> I want to do the opposite. I want to make evidence >>> that I created a document _before_ a certain point of time. [...] >>> Is there a standard way in GnuPG and in the keyholder >>> infrastructure to accomplish this task? since it is possible to fake system time by modifying system time in BIOS (all OS with BIOS or similar) and (on GNU/Linux systems) by using faketool application-wide, or, more specifically, gpg's --fake-system-time EPOCH (usable from 2.1 on if gnupg was compiled using debug flags; although this option is documented for previous versions as to the 2.0.x manpages or the gnupg's info manual, it only is implemented and usable in gpg 2.1. see (1)(2)(3)(4) gpg's signature timestamp (on a given file) would NOT be a real proof of a document being allegedly signed at that specific date or (prior to a determined date). So it would NOT either be a credible proof of a document being allegedly created before a determined date, if you decided to sign it immediately after creating it in order to document its creation date via signature time). Cheers Stephan (1) https://lists.gnupg.org/pipermail/gnupg-devel/2014-September/028724.html (2) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760354 (3) https://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/2014-September/001774.html (4) https://marc.info/?l=gnupg-commit-watchers&m=146009708822599&w=2 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x4218732B.asc Type: application/pgp-keys Size: 4089 bytes Desc: not available URL: -------------- 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 Fri Dec 2 15:20:50 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 2 Dec 2016 09:20:50 -0500 Subject: GnuPG version info from GPGME? Message-ID: <158b2666-e74b-b4f1-d4a5-3e89fc393c6c@sixdemonbag.org> I'm working on a command-line application to migrate profiles not just between machines, but versions of GnuPG. E.g., 1.4 on machine A -> 2.1 on machine B, or vice-versa. For this, I need a way to discover which version of GnuPG is currently installed. A quick look through the GPGME manual doesn't reveal anything. Have I just overlooked it, or do I really need to launch gpg --version and parse the output? From rjh at sixdemonbag.org Fri Dec 2 15:22:05 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 2 Dec 2016 09:22:05 -0500 Subject: GnuPG version info from GPGME? In-Reply-To: <158b2666-e74b-b4f1-d4a5-3e89fc393c6c@sixdemonbag.org> References: <158b2666-e74b-b4f1-d4a5-3e89fc393c6c@sixdemonbag.org> Message-ID: > Have I just overlooked it, or do I really need to launch gpg --version > and parse the output? And literally two seconds after clicking "Send", I found the answer. Never mind. :) From brian at minton.name Fri Dec 2 14:50:14 2016 From: brian at minton.name (Brian Minton) Date: Fri, 2 Dec 2016 08:50:14 -0500 Subject: Proof for a creation date In-Reply-To: References: <20161202021250.GA69543@becker.bs.l> Message-ID: <20161202135012.sdq5x5aprynmjjr2@brian.minton.name> On Fri, Dec 02, 2016 at 01:37:00PM +0800, Quan Zhou wrote: > so GnuPG's timestamping isn't an option for this? > Even X509 has a timestamping feature for this kind of use. > No, because you could just set your computer's clock to anything you want, then create the GnuPG /X509 timestamp. I agree with some of the other posters; the best way is to either post the whole message, or a cryptographically strong hash of it to some public append-only location, and the Bitcoin blockchain or a certificate transparency log both do it the same way, via a cryptographic hash inserted into a Merkle tree. That has the desired properties of being append-only and publicly auditable. -- Brian Minton brian at minton dot name http://brian.minton.name Live long, and prosper longer! OpenPGP fingerprint = 8213 71DD 4665 CF4F AE20 2206 0424 DC19 B678 A1A9 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 390 bytes Desc: not available URL: From duane at nofroth.com Fri Dec 2 15:57:14 2016 From: duane at nofroth.com (Duane Whitty) Date: Fri, 2 Dec 2016 10:57:14 -0400 Subject: How do you help someone to encrypted email (Re: How do you let your M.D. ...) In-Reply-To: <201612020839.24050.bernhard@intevation.de> References: <5i1sxrb3ys.fsf@fencepost.gnu.org> <201612020839.24050.bernhard@intevation.de> Message-ID: <58418BCA.9080308@nofroth.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 16-12-02 03:39 AM, Bernhard Reiter wrote: >> so that it's easier for folks unfamiliar to setup and use than >> having to go over the too long material > > Within next year, someone will just need to use an email client > that support the following technical solution: > > https://wiki.gnupg.org/WKD > > This is something the GnuPG team is actively working on. > > Best Regards, Bernhard > > > > _______________________________________________ Gnupg-users mailing > list Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > First let me say thank you to the developers of gnupg and all the tools and scripts and everything else that goes into creating and running a project as complex as this. And thanks to all the helpful people on the list. Regarding WKD: I'm sure this will be a great tool for fetching public keys and will make life easier for many people on this list. Thank you for your efforts Bernhard! (Putting on fireproof suit :-) ) My personal feeling and opinion however is that public key management is not the barrier to adoption of gnupg for everyday users who would like to increase their security. I believe that outside of the lack of awareness that their privacy is being ignored, the problem is mostly private key management and the unfortunate fact that most of the email clients that most people use on the most popular platforms don't support encrypting and decrypting mail. I'll be the first to admit that I don't know how to make it easy for users to be able to generate a private/public key pair wherein the private key can be stored relatively securely and be available for use with their gmail or other email platform of choice from the desktop, laptop, tablet, and phone. Sure you can use a smart card reader to solve the availability issues but then you have to deal with all the software issues. Most people have no knowledge about any of this let alone the existence of tools like smart card readers. I realize there is an argument to be made that people need to exercise personal responsibility when it comes to their security. But I believe adoption will be limited to the technically adept until we can make using encryption and decryption an understandable and short process for people who only use their computers to run "canned" applications and send mail. (Thinking out loud) I wonder if a solution akin to what the password managers do is possible? Maybe storing a private key in a password manager would work for a lot of users. It's not as if anyone would be forced to do this. Create a partnership with a few of the password managers that would require a key be protected by a 30+ character random password and then users could access their private key from anywhere once they've logged into their password manager. Just a thought and clearly it's not the most secure method but maybe it is secure enough? Still doesn't solve the problem of having gnupg available and integrated on all the different platforms. (keeping fireproof suit on for a while :-) ) Thanks for your indulgence and patience :-) Best Regards, Duane - -- Duane Whitty duane at nofroth.com -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYQYvKAAoJEOJfpr8UVxtkJPgH/1iH2Lk9WFUgE+mkhbJRivsc HnPOzCY+XqWQkWSy7T9kgGddvnf/0jhanApsOnkOiVIUI44XOxuH2dViUbkoEDbj bl+eAjVttVzpyoyVhgwU7jmnsxj4BRvH+6vbTWp3bWt1Cdwz5MTcvsL1nfAgm7zR gAXR251Ul0kL+rFuM/SWe6DXlYoj5ZPWZRpCUR+cuP55PzYJTnoJeAvSMtoktBbH aFDVVyltNJhjikMRTDZ93VJWd0KAytGjCZntnYtwssFbxNkBJIh92ODkEuB8Rj/M mAqnzpKW7TLOjaAFXnD3Nyg4ATy4M3oK0hm+qV6IbTqEjzXspHlw/wubBHwZWfA= =Dm3t -----END PGP SIGNATURE----- From gmane.bl4 at gishpuppy.com Fri Dec 2 16:11:33 2016 From: gmane.bl4 at gishpuppy.com (gmane.bl4 at gishpuppy.com) Date: Fri, 2 Dec 2016 15:11:33 +0000 (UTC) Subject: Proof for a creation date [GishPuppy] Message-ID: <20161202151134.2BAAD47ACC@mail.gishpuppy.com> Bertram Scharpf wrote: > I want to make evidence that I created a document > _before_ a certain point of time. > http://www.itconsult.co.uk/stamper.htm Gishpuppy | To change the delivery settings for this email, click here: http://www.gishpuppy.com/cgi-bin/edit.py?email=gmane.bl4 at gishpuppy.com From andrewg at andrewg.com Fri Dec 2 18:21:12 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 2 Dec 2016 17:21:12 +0000 Subject: How do you help someone to encrypted email (Re: How do you let your M.D. ...) In-Reply-To: <58418BCA.9080308@nofroth.com> References: <5i1sxrb3ys.fsf@fencepost.gnu.org> <201612020839.24050.bernhard@intevation.de> <58418BCA.9080308@nofroth.com> Message-ID: <5b9cd938-41bc-3056-9ecc-b7e48bdbf540@andrewg.com> On 02/12/16 14:57, Duane Whitty wrote: > > I believe that outside of the lack of awareness that their privacy is > being ignored, the problem is mostly private key management and the > unfortunate fact that most of the email clients that most people use > on the most popular platforms don't support encrypting and decrypting > mail. Yes. Secret key generation, backups, and portability. Also, the fact that so many people now use webmail rather than a local client. > Sure you can use a smart card reader to > solve the availability issues but then you have to deal with all the > software issues. Most people have no knowledge about any of this let > alone the existence of tools like smart card readers. Yep. I've been using a smart card reader for a while, and although I'm comfortable with it now, initially it was daunting. I ended up writing a tool to automate the key generation and backup process (https://andrewg.com/frith.html). There is a similar project under development in Debian (https://danielpocock.com/outreachy-gsoc-2017-pki-clean-room). I wouldn't ask my mother to use either of them. Enabling the smart card for use across multiple machines was a long, trial and error process. Once it is working the convenience is great. But I wouldn't expect anyone else to do it. > I realize there is an argument to be made that people need to exercise > personal responsibility when it comes to their security. But I > believe adoption will be limited to the technically adept until we can > make using encryption and decryption an understandable and short > process for people who only use their computers to run "canned" > applications and send mail. Yes. Arguing "personal responsibility" is too often a means of passing the buck. If it is too difficult or time consuming to be a responsible citizen, people won't. This applies across all walks of life, not just computer security. The best systems make Good Things easy, and Bad Things more trouble than they're worth. Poor systems make Bad easier than Good and then spend all their energy chasing up people who took the lazy way out - which in extreme cases can mean literally everyone. > (Thinking out loud) > I wonder if a solution akin to what the password managers do is > possible? Maybe storing a private key in a password manager would > work for a lot of users. GPG's secret keyring is a password protected database, just like a password manager. The main thing it does not do that many password managers provide is automatically store the encrypted secret in the cloud for easy synchronisation. This is a questionable practice however. Much better to store your secret key material on a smart card. Of course that buggers up mobile. > Still doesn't solve the problem of having gnupg available and > integrated on all the different platforms. Exactly. 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 glenn at rempe.us Fri Dec 2 17:36:25 2016 From: glenn at rempe.us (Glenn Rempe) Date: Fri, 2 Dec 2016 08:36:25 -0800 Subject: Proof for a creation date In-Reply-To: <20161202135012.sdq5x5aprynmjjr2@brian.minton.name> References: <20161202021250.GA69543@becker.bs.l> <20161202135012.sdq5x5aprynmjjr2@brian.minton.name> Message-ID: <92147657-56d2-4691-afe0-ec03a1c4b90c@Spark> Tierion creates a Merkle tree of incoming hashes and puts the root of the Merkle tree on the Bitcoin blockchain which proves that the hash was placed there prior to the time embedded in the BTC transaction. You want to use their HashAPI. https://tierion.com/features Other similar services are: http://truetimestamp.org https://proofofexistence.com These services don't need GnuPG, but nothing to stop you from hashing a signed document. -------------- next part -------------- An HTML attachment was scrubbed... URL: From glenn at rempe.us Fri Dec 2 19:24:09 2016 From: glenn at rempe.us (Glenn Rempe) Date: Fri, 2 Dec 2016 10:24:09 -0800 Subject: Proof for a creation date [GishPuppy] In-Reply-To: <20161202151134.2BAAD47ACC@mail.gishpuppy.com> References: <20161202151134.2BAAD47ACC@mail.gishpuppy.com> Message-ID: <031bd928-d01e-4097-94e3-9513c177743d@Spark> Unfortunately, I think the public key from that service is no longer importable in modern GnuPG. https://gnupg.org/faq/whats-new-in-2.1.html#nopgp2 Trying to import the public key on this page results in no public key being imported. Without this the service cannot be used to verify the signature on a timestamp report (I reported this to them several years ago. No changes were made). ?Also, this service is not a very secure source of time. They use their own clock. They claim some security by using an incrementing counter and publishing signed snapshots to a usenet group. ?Bottom line though is this service is pretty ancient and requires a lot of trust on your part of the administrator. http://www.itconsult.co.uk/stamper/stampinf.htm $ gpg2 --verbose --import stamper.asc gpg: armor header: Version: 2.6.3i gpg: Total number processed: 3 gpg: ? ? skipped PGP-2 keys: 3 $ gpg2 --version gpg (GnuPG) 2.1.16 > Bertram Scharpf wrote: > > > I want to make evidence that I created a document > > _before_ a certain point of time. > > > > > http://www.itconsult.co.uk/stamper.htm > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony at cajuntechie.org Fri Dec 2 23:59:16 2016 From: anthony at cajuntechie.org (Anthony Papillion) Date: Fri, 2 Dec 2016 16:59:16 -0600 Subject: Still trying to troubleshoot --refresh-keys error Message-ID: <5d1e1080-aadd-7016-e630-f70c8beb3bff@cajuntechie.org> For the last few weeks, I've talked about how, when I try to refresh the keys on my ring, I get an error from GnuPG. Today, I noticed a message that I hadn't noticed before and I strongly suspect this might be the cause of the problem I'm having. When I issued the gpg2 --refresh-keys command, GnuPG connected to the SKS pool and sent a request for all the keys on my ring. At the end of the refresh attempt, I saw the following: gpg: no valid OpenPGP data found. gpg: Total number processed: 0 gpg: keyserver communications error: keyserver helper internal error gpg: keyserver communications error: General error gpg: keyserver refresh failed: General error IIRC, Stephen mentioned something about the helper program the last time I posted. This seems to confirm that. However, since it's not giving me much information, I can't really troubleshoot further. This is GnuPG 2.0.3 (GpG4Win 2.3.3) on Windows 10. This issue DOES NOT happen on Linux. Can anyone offer a bit of insight? Thanks, Anthony -- VoIP/SIP: 1259010 at localphone.com Skype: cajuntechie XMPP/Jabber: papillion at dukgo.com PGP Key: 0xCC9D1E072AC97369 Other Info: http://www.cajuntechie.org/p/my-pgp-key.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From 2014-667rhzu3dc-lists-groups at riseup.net Sat Dec 3 14:42:13 2016 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sat, 3 Dec 2016 13:42:13 +0000 Subject: Proof for a creation date In-Reply-To: <96a4d163-02fb-096e-a75e-980f0ee61da3@mailbox.org> References: <20161202021250.GA69543@becker.bs.l> <96a4d163-02fb-096e-a75e-980f0ee61da3@mailbox.org> Message-ID: <76590991.20161203134213@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Friday 2 December 2016 at 1:46:00 PM, in , Stephan Beck wrote:- > gpg's signature timestamp (on a given file) would NOT > be a real proof of > a document being allegedly signed at that specific > date or (prior to a > determined date). Maybe use a digital timestamping service, such as ? Or publish an encrypted (or not) copy in the small ads of a newspaper. - -- Best regards MFPA An idealist is a person who helps other people to be prosperous -----BEGIN PGP SIGNATURE----- iL4EARYKAGYFAlhCy71fFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDMzQUNFRDRFRTkxMzRFRUJERTZBODUwNjE3 MTJCQzQ2MUFGNzc4RTQACgkQFxK8Rhr3eOSHtQEA8/8Lrit4l+I1qgxnCWSov6ai dF/2/9n31AmG4/0k5HsA/30W1f52Ae3Dmx6B5Gt0DYIXgLDTit8mISD2GvFvHdgN iQF8BAEBCgBmBQJYQsvOXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwNlYIALPOm8l1bgXq1Gn9nuXahN+m oTKHJMegDoGsYhjDou8YSHHPj998evdAAhsg6yeZwNmq37FRYIyrqx2aMsmQy6qx lKMyCA0OFDgetFfKS/C/jGkkY0YyZvv5z8mecokmnc82C5T3HpfmzGAazheh+Nm0 SHAp34rkTUL+8zukKbTpnMXhFItlrflThEc4ZoLIj+df7XD3ajWuMgwnf1vEgQY+ CRHCurgWYkVSAEuyqf7ehKhumCfawELbGmfYWQXWpiUfQ9rbRigRQ+OkG/Aw5Ggo w2HjJI23aAy9ZZRm8T01KYQXR7+0Uy9hyzU+dS1lTZfETtHFdsbHPYqKSyfgzm8= =7mgK -----END PGP SIGNATURE----- From zepmaster at gmx.net Sat Dec 3 14:28:37 2016 From: zepmaster at gmx.net (zep) Date: Sat, 3 Dec 2016 14:28:37 +0100 Subject: private subkey not found In-Reply-To: <87shq9715j.fsf@wheatstone.g10code.de> References: <42e8f41e-8ee5-e16b-5672-e2aef80dc095@gmx.net> <87shq9715j.fsf@wheatstone.g10code.de> Message-ID: <11ffab13-43ee-b3e4-0662-2d903a2cc3f9@gmx.net> Hello Werner, Thanks for your reply > That does not look like the standard output of gpg 2.1.15 - Please > remove the keyid-format option from your gpg.conf. Here is the output you requested: sec# rsa4096 2016-11-19 [C] [expires: 2021-11-18] some_hex_value uid [ultimate] zep ssb> rsa4096 2016-11-19 [S] [expires: 2021-11-18] ssb> rsa4096 2016-11-19 [E] [expires: 2021-11-18] ssb> rsa4096 2016-11-19 [A] [expires: 2021-11-18] sec rsa4096 2015-04-07 [SCA] [expires: 2020-04-05] some_other_hex_value uid [ultimate] zep ssb rsa4096 2015-04-07 [E] [expires: 2020-04-05] I have two different keysets: One offline master key and three subkeys for zep which are stored on a nitrokey. Then I have one master key and one subkey for zep , which are not stored on a smartcard. > Are all keyfiles in ~/.gnupg/private-keys-v1.d/ readable ? Check the > permissions. Indeed, my master private key for other_mail at provider.tlp in ~/.gnupg/private-keys-v1.d/ is only a symlink to the real key, which is on an LUKS encrypted USB drive. I moved the symlink out of the way, and checked again using gpg-connect-agent, keyinfo --list: > keyinfo --list S KEYINFO some_hex T some_hex OPENPGP.2 - - - - - S KEYINFO some_hex D - - - P - - - S KEYINFO some_hex T some_hex OPENPGP.2 - - - - - S KEYINFO some_hex T some_hex OPENPGP.1 - - - - - S KEYINFO some_hex T some_hex OPENPGP.1 - - - - - S KEYINFO some_hex D - - - P - - - S KEYINFO some_hex T some_hex OPENPGP.3 - - - - - ERR 67108952 Invalid name Signing, Encrypting and Decryption using the first keyset (on the nitrokey) does work. But decryption using the subkey of the second keyset does not work. Is it possible to have two keysets each having the same name, but a different email address ? E.g. zep zep Thanks, Cheers, zep On 11/30/2016 10:44 AM, Werner Koch wrote: > On Tue, 29 Nov 2016 21:19, zepmaster at gmx.net said: > >> sec rsa4096/0xABCDEFGH 2015-04-07 [SCA] [expires: 2020-04-05] >> Key fingerprint = ABCD ABCD ABCD .... > > That does not look like the standard output of gpg 2.1.15 - Please > remove the keyid-format option from your gpg.conf. > >> gpg-connect-agent >>> keyinfo --list >> S KEYINFO "some hex string" D - - - P - - - >> ERR 67108891 Not found > > Are all keyfiles in ~/.gnupg/private-keys-v1.d/ readable ? Check the > permissions. > > > Shalom-Salam, > > Werner > From peter at digitalbrains.com Sat Dec 3 15:35:09 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 3 Dec 2016 15:35:09 +0100 Subject: Implications of a common private keys directory in 2.1 In-Reply-To: <20161124230301.3055810320F5@remailer.paranoici.org> References: <20161016012250.2CB31101F1EA@remailer.paranoici.org> <20161120203740.CAB33100A200@remailer.paranoici.org> <20161123230916.5960A10320FB@remailer.paranoici.org> <3b776db4-4161-35cc-31ac-b343b12edf7a@digitalbrains.com> <20161124131636.82DF810320FB@remailer.paranoici.org> <20161124230301.3055810320F5@remailer.paranoici.org> Message-ID: <17f5cadc-c7fb-c43a-a141-5d269ab45eaa@digitalbrains.com> On 25/11/16 00:03, Carola Grunwald wrote: > Let's just say I hold two nym accounts at different nym servers > > https://en.wikipedia.org/wiki/Pseudononymous_remailer#Contemporary_nym_servers Right, you're also hiding the proxy server. So if the proxy used the same public key for multiple nym accounts, that would link them up as all using the same proxy. That makes sense, I didn't know you were also hiding the proxy you're building. I think it would be better to implement the proxy on the client machine, instead of on a server machine. That way, all secrets stay on the client machine, and you could still use regular e-mail clients, just with an IMAP server at the localhost. This seems *so* much better than a server which can decrypt all client data! But let's take for granted that you want to do it as you want to do it, on a server. I doubt you would run into any trouble just using a separate homedir per user account. I don't think agents take a lot of resources. When the user logs out, you make the agent quit as well. You could remove its socket; it will notice and quit within a short while. There's also the Assuan command KILLAGENT which does what it says on the tin. I don't know what interface to GnuPG you were planning to use, but I would strongly suggest GPGME; it's the official way of programmatically using GnuPG. That said, I don't know if GPGME offers a way to issue the KILLAGENT command. A separate homedir per user means you get the separation you wanted. I don't see the purpose of using the password of the user account for encrypting the private key, though. It doesn't seem to add security and does seem to add problems. If you're worried about seizure of the data at rest, you could use a single server-wide passphrase to encrypt all private keys used by GnuPG. You could use disk encryption, that seems like an easy way out and would protect other sensitive data as well. Or you could use a specialized pinentry implementation, that always returns the same passphrase, which could be seeded when the server boots up. Pinentries are easy to write. If you really want to cut down on the number of running agents, I'd first discuss this with the GnuPG developers. Is the agent well suited to serve dozens, hundreds of private keys? If the design never accounted for this possiblity, it might be horribly inefficient or expose unexpected issues. (You could take the middle road and serve, say, 32 clients per agent.) However, that still presents a serious issue with private key ownership, both in the case of multiple recipients and with --throw-keyids, which you would not have with an agent per user. GPGME tells you which private key was used to decrypt the message. However, if there are multiple recipients on the same proxy and they share an agent, GnuPG will only use the first one that succeeds. If your proxy software would inspect the recipient and only allow the owner of the indicated key to read the message, the other recipients wouldn't be able to read the message, because the agent never needed to use their key in the first place. Argh. For hidden recipients, it would be a serious resource hog to try all keys, and would additionally have the same problem with multiple recipients. An option --only-try-secret would solve both (your software would know which to try for a given nym account), but such an option is not available. You could try to make the case that such an option would be a good idea to implement. It would serve more scenarios than just yours. For instance, people with smartcards could use it when a message is also encrypted to an on-disk key, when they can't or don't want to insert their smartcard. And if somebody knows which key is the hidden recipient, but has multiple secret keys, it would save them declining all the dialogs for the keys that aren't the recipient. You are worried about all other kinds of key management issues. I don't think that is really so worrisome. You could simply zap the revocation certificate already on creation, or periodically zap the contents of the openpgp-revocs.d dir altogether, I don't think they serve much of a purpose in your scenario. And once a user account is deleted, simply delete the accompanying secret key (--delete-secret-keys, not --delete-secret-and-public-key). As long as you don't meddle with multiple public keyrings, this is just fine. You might say multiple keyrings "without doubt have stood the test of time in GnuPG 1.4", but I suspect this test of time is precisely what has shown the people actually maintaining this feature that it is riddled with hard issues. While we're touching on that subject, if you go the single agent route, you could just hold all public keys in one keyring. I think it's built to be big. GnuPG 2.1 is a lot more efficient with large keyrings than previous versions. And public data is public data, right? No need to wall it off. That does leave deletion of public keys, but you could do reference counting in your proxy server. If somebody, through your interface, imports a public key you already have, you increment its reference count. When the user deletes the public key or the account is deleted, you decrease the reference count. Once it hits zero, --delete-public-key. Perhaps multiple keyrings would have saved you of this, but it doesn't seem very complicated, there are no dependencies to track or anything, just a simple reference count. Or you could use --no-default-keyring along with --keyring and use a public keyring per user, that still works in GnuPG 2.1 right? Multiple keyrings at the same time has interesting ambiguities, like where to delete from and where to add to, which one to use when there are several versions of a key, etcetera. I think your issue stemmed from using --delete-secret-and-public-key rather than --delete-secret-keys. The former is a combination of --delete-secret-keys and --delete-keys, and with multiple public keyrings, --delete-keys gets "interesting". Again, a large part of this mail could just be thrown away unread (or unwritten :) if you simply use a single homedir per user account. Is this perceived saving of resources worth all this trouble? Changing secret keyrings in GnuPG 1.4 is more or less replaced by changing homedirs in GnuPG 2.1. It's not this difference which you're coming up against here, it's the difference that 1.4 does everything in a single process that quits when it's done. In 2.1, there's the agent, which survives. Something totally different, but brought up by other people before. Do the generated private keys hold UID's? And if so, it's just the nym e-mail address, right? No name portion. You'd better *very* clearly inform your users then that your server is pretending to be the owner of their nym address, and very clearly inform them that your server can read all this encrypted data! You say they are free to add another layer of encryption. Sure, but make them realise that without this, they are placing a huge amount of trust in your server and its operators, and where it is housed etcetera. If your software would run on the client, this wouldn't be an issue. And it's a huge issue, IMHO. > Simple answer: You never know who your opponents are. How can you be > sure the recipient of your mail isn't one of them? Or his network > infiltrated and his computer compromised? Right, yes, pseudonymity, the recipient could be the adversary. I'm not used to thinking about Alice or Bob that way. Anonymous remailers solve the time issue by random delays. You could do that here as well: hold onto the mail for a random time once it's submitted, then sign it, then hold onto it for some more time (random), and only then submit it to the anonymous remailers. It's just two hops extra random delay in the remailer network, in the sense of time spent. But if you want to drop timestamps, I doubt --faked-system-time is your friend. Like the manual says, "only useful for testing"! It affects everything. If someone creates a key and sends it to their correspondent, and the correspondent would use a --faked-system-time from before the creation date, *poof*. GnuPG will notice the key seems to come from the future and deny to encrypt to it. Everything breaks down. Same with expirations and extensions thereof. Also, there's the trust database, which is periodically rebuilt and timestamped. Interestingly, my GnuPG 2.1.11 didn't complain that the trust database was from the future, but I wouldn't depend on this staying this way. Another nice edge case: a key is created at 14:54, but it's trying to issue a signature at 12:00. Oops: $ echo hoi | gpg2 --faked-system-time "20161203T110000" -u 0E675C27 -s gpg: WARNING: running with faked system time: 2016-12-03 11:00:00 gpg: key 0E675C27 was created 10495 seconds in the future (time warp or clock problem) gpg: key 0E675C27 was created 10495 seconds in the future (time warp or clock problem) gpg: skipped "0E675C27": Unusable secret key gpg: signing failed: Unusable secret key (I'm on CET, and --faked... is in UTC). And I wouldn't be surprised if there are more snags when you pretend you're not living in the now. I just checked the OpenPGP RFC, and though the signature timestamp is a separate subpacket that could be omitted, there is a MUST requirement that it is present. So to create an OpenPGP compliant message without a good timestamp, you do have to fake a timestamp, unfortunately. Maybe you could make the case that faking a signature timestamp should be a feature? I can imagine a different use case: not letting the recipient know you were still working on stuff at 3:00 in the night, even though you were. But it doesn't seem like a high-priority feature request to me (sorry). > Footnote: > A pinch of paranoia helps develop solid anonymity software. > Act as if there's no one out there you can trust. Yes. My mind is used to thinking about the recipient as implicitly trusted with knowledge, which just isn't the case in a pseudonymous system. Anonymity is easier in that respect: signatures make no sense at all. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From rjh at sixdemonbag.org Sat Dec 3 16:16:14 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 3 Dec 2016 10:16:14 -0500 Subject: gpgme 1.8 build failure (again) In-Reply-To: <87lgvywtqe.fsf@wheatstone.g10code.de> References: <87lgvywtqe.fsf@wheatstone.g10code.de> Message-ID: > I am not sure whether this was helpful but I wrote That was the one I needed. :) For some reason, something in the GPGME build requires _DARWIN_C_SOURCE to be set. From 2014-667rhzu3dc-lists-groups at riseup.net Sat Dec 3 18:21:47 2016 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sat, 3 Dec 2016 17:21:47 +0000 Subject: Implications of a common private keys directory in 2.1 In-Reply-To: <17f5cadc-c7fb-c43a-a141-5d269ab45eaa@digitalbrains.com> References: <20161016012250.2CB31101F1EA@remailer.paranoici.org> <20161120203740.CAB33100A200@remailer.paranoici.org> <20161123230916.5960A10320FB@remailer.paranoici.org> <3b776db4-4161-35cc-31ac-b343b12edf7a@digitalbrains.com> <20161124131636.82DF810320FB@remailer.paranoici.org> <20161124230301.3055810320F5@remailer.paranoici.org> <17f5cadc-c7fb-c43a-a141-5d269ab45eaa@digitalbrains.com> Message-ID: <549335770.20161203172147@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Saturday 3 December 2016 at 2:35:09 PM, in , Peter Lebbing wrote:- > An option --only-try-secret would solve both > (your software > would know which to try for a given nym account), but > such an option is > not available. You could try to make the case that > such an option would > be a good idea to implement. It would serve more > scenarios than just > yours. For instance, people with smartcards could use > it when a message > is also encrypted to an on-disk key, when they can't > or don't want to > insert their smartcard. And if somebody knows which > key is the hidden > recipient, but has multiple secret keys, it would > save them declining > all the dialogs for the keys that aren't the recipient. If the recipients are hidden, doesn't GnuPG first try the key set with - --default-key, followed by any keys set with --try-secret-key? That is sufficient for your smartcard and known-hidden-key examples, but not for Caro's situation. And I don't think --try-secret-key can be followed by --skip-hidden-recipients to mean "try this/these key(s) and if they won't decrypt it, give up on hidden recipients". - -- Best regards MFPA Only dead fish go with the flow -----BEGIN PGP SIGNATURE----- iL4EARYKAGYFAlhC/zNfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDMzQUNFRDRFRTkxMzRFRUJERTZBODUwNjE3 MTJCQzQ2MUFGNzc4RTQACgkQFxK8Rhr3eOSWUQEAirYk4e7jhPN6SMo2LaMOof8A efmDpGFFhAcT06ognGQBAL+PfFELjcOKnuFrWI+kiHTKOdoffBDMddy1VDhaTdEJ iQF8BAEBCgBmBQJYQv9BXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwT0sIALLFwBD+2X00uYv6TxX6lcez kv88jkOdlYZJ0iAKnKmwYXESi++iT9tvCyX4acJ6mytLxG/aGoGYTcyan68MaAMT O2e88RYlPZyA6ZQD1TkJy6Xr5OdBngJcc35SOq/3Ay09hLyVEV/26Ue1FDY5bdS3 8u39+oQYf3cGQcu4ZRaWbphePqnXK00jlFqtqkvqrxig3gGGgvfeeImVpMY/d16D UZbg+xJO4JezjR2UJqQxvnqDECW+BE32k67iFVwE8JazQcsZUSHBxWIiSuw8WeKP rAzKinXU3RUkqQykqB6PkCaLqKxqyRPWleTsWv0PlWjlwWY7agZd5Ws1b4Cq/CY= =w7RF -----END PGP SIGNATURE----- From peter at digitalbrains.com Sat Dec 3 18:41:05 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 3 Dec 2016 18:41:05 +0100 Subject: Implications of a common private keys directory in 2.1 In-Reply-To: <549335770.20161203172147@riseup.net> References: <20161016012250.2CB31101F1EA@remailer.paranoici.org> <20161120203740.CAB33100A200@remailer.paranoici.org> <20161123230916.5960A10320FB@remailer.paranoici.org> <3b776db4-4161-35cc-31ac-b343b12edf7a@digitalbrains.com> <20161124131636.82DF810320FB@remailer.paranoici.org> <20161124230301.3055810320F5@remailer.paranoici.org> <17f5cadc-c7fb-c43a-a141-5d269ab45eaa@digitalbrains.com> <549335770.20161203172147@riseup.net> Message-ID: <7a63c053-58bb-daab-d581-58a683eb68ea@digitalbrains.com> On 03/12/16 18:21, MFPA wrote: > If the recipients are hidden, doesn't GnuPG first try the key set > with --default-key, followed by any keys set with --try-secret-key? Hey, I didn't know that! Thanks! > That is sufficient for your smartcard and known-hidden-key examples, > but not for Caro's situation. The smartcard case seems to work anyway, in a test it seems to be tried only after the on-disk keys. It is indeed sufficient for the known-hidden-key example, but not for the case with known recipients. I just tried, if there are two secret keys that are encrypted to and they are named, it will try them in order, no matter --default-key. Perhaps --default-key could be extended to always try that first? > And I don't think --try-secret-key can be followed by > --skip-hidden-recipients to mean "try this/these key(s) and if they > won't decrypt it, give up on hidden recipients". I think in fact --default-key is enough... I just tried with GnuPG 2.1, and it only tried that secret key. Any additional keys need to be added via --try-secret-key or --try-all-secrets. So it seems to complete solve the hidden recipient problem, only the known multiple recipients problem remains. 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 stebe at mailbox.org Sun Dec 4 12:33:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Sun, 04 Dec 2016 11:33:00 +0000 Subject: Still trying to troubleshoot --refresh-keys error In-Reply-To: <5d1e1080-aadd-7016-e630-f70c8beb3bff@cajuntechie.org> References: <5d1e1080-aadd-7016-e630-f70c8beb3bff@cajuntechie.org> Message-ID: Anthony Papillion: > For the last few weeks, I've talked about how, when I try to refresh the > keys on my ring, I get an error from GnuPG. Today, I noticed a message > that I hadn't noticed before and I strongly suspect this might be the > cause of the problem I'm having. > > When I issued the > > gpg2 --refresh-keys > > command, GnuPG connected to the SKS pool and sent a request for all the > keys on my ring. At the end of the refresh attempt, I saw the following: > > gpg: no valid OpenPGP data found. > gpg: Total number processed: 0 > gpg: keyserver communications error: keyserver helper internal error > gpg: keyserver communications error: General error > gpg: keyserver refresh failed: General error > > IIRC, Stephen mentioned something about the helper program the last time > I posted. This seems to confirm that. However, since it's not giving me > much information, I can't really troubleshoot further. > > This is GnuPG 2.0.3 (GpG4Win 2.3.3) on Windows 10. This issue DOES NOT > happen on Linux. > > Can anyone offer a bit of insight? Ah, you're using gpg4win! So you already do have activated Kleopatra's log files following instructions given in chapter 23.1 of the Gpg4win Compendium? Cheers Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x4218732B.asc Type: application/pgp-keys Size: 4089 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From stebe at mailbox.org Sun Dec 4 12:37:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Sun, 04 Dec 2016 11:37:00 +0000 Subject: Proof for a creation date In-Reply-To: <76590991.20161203134213@riseup.net> References: <20161202021250.GA69543@becker.bs.l> <96a4d163-02fb-096e-a75e-980f0ee61da3@mailbox.org> <76590991.20161203134213@riseup.net> Message-ID: <0970de53-c09d-a4f1-04e5-b47044933f88@mailbox.org> MFPA: > > > On Friday 2 December 2016 at 1:46:00 PM, in > , Stephan Beck > wrote:- > > > >> gpg's signature timestamp (on a given file) would NOT >> be a real proof of >> a document being allegedly signed at that specific >> date or (prior to a >> determined date). > > > Maybe use a digital timestamping service, such as > ? > > Or publish an encrypted (or not) copy in the small ads of a newspaper. > > > Yes, that's it, publish it in the papers. Everyone would agree on that this would be a "real" proof, i.e. one that would be accepted in the courtroom. Luckily, communicating (as via email, as among humans) you do not always need to have that degree of certainty. :-) Cheers Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x4218732B.asc Type: application/pgp-keys Size: 4089 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Sun Dec 4 14:33:47 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 4 Dec 2016 14:33:47 +0100 Subject: Hybrid keysigning party, your opinion? Message-ID: Hi all, In just a few weeks, the 33C3 will be held in Hamburg, the 33th Chaos Communication Congress organized by the Chaos Computer Club. I intend to organize a keysigning party, just because they are fun. I am asking for your thoughts on a variant of the organization of the keysigning party. I'll explain my reasoning and intentions, and I would like to know if you think I forgot to think of something important. Is there a way a malicious party could get people to sign the wrong UID, because I didn't think of that way? I'm not interested in ways people could cheat at the usual "informal" keysigning party model, with exchanging paper keyslips. This is because this would be my fallback model, if the proposed model doesn't work out. So I'm only interested in cases where the proposed model introduces extra issues compared to the informal exchanging keyslips model. There are several methods to do a keysigning party. One of them is the "Sassaman efficient" version. It requires preparation, and this preparation must be done in time that everybody can print out their copy of the list. With a congress spanning several days, this means the preparation should probably be done before the congress, since in general you shouldn't print your list on a printer you don't completely trust, and most people don't bring a printer (I did! :). Now Sassaman efficient has a very big issue. There will always be people who also wish to attend the keysigning party who did not participate in the preparations. As far as I can see, these people could just participate as equals with printed out keyslips to hand out to the other people. However, I've seen multiple times that these late guests were treated as second-class participants. I've actually seen them delegated to the corridor outside the room where the party was held, told to wait until the others were done! I never got a chance to exchange fingerprints with these people because of course they left a long time before the party inside was done. I can't imagine this was a very pleasant experience for them. The common denominator of the Sassaman efficient and the informal method is that you form a line of people that folds in on itself. Now, as I see it, you can just form a line beginning with the people on the list and ending with the people who joined late.[1] With the people on the list, you only check ID's and place a checkmark on your list when satisfied. Once you get to the part with the late attendants[2], you instead exchange key slips. I don't see why the people who are not on the list should not be allowed to be in the same line, yet it is what I've seen happening. Anyway, so, Sassaman efficient has a major problem. It also has advantages. At the bottom line, there is only one advantage I find relevant. With Sassaman efficient, you actually only have to check one SHA256 hash and your own fingerprint. No matter how many attendees, you don't have to check anyone else's fingerprint manually. Just the two! This is because you have a SHA256-protected list of fingerprints already in digital form; no need to compare to printed out digits on paper. All attendees who participated in the preparation have gotten a text file which contains all fingerprints of the participants, and they print out this list as well as compute its checksum. Additionally, they check that their *own* fingerprint in this list is correct. At the event, the SHA256 checksum of the text file is read aloud and everybody compares it to the checksum on their piece of paper. Next, each participant on the list is asked in turn whether their fingerprint checked out.[3] After the event, you'll go home and sign keys, using the verified text file that has the correct SHA256 checksum. Now when you use CA - Fire and Forget, caff, all you have to check are the UID's you are signing. The SHA256 checksum has already ascertained that the fingerprints in the text file are correct; anyone altering a fingerprint will necessarily alter the checksum of the file. And caff checks the fingerprint for you from the known-correct file! As long as all participants verified that their own fingerprint is correct in the file with the correct SHA256 hash, all fingerprints have been verified already. It will still be *very* important to verify the UID's manually. What if the official list had a key with fingerprint X and UID , but once you download the key with fingerprint X, there's instead an UID ? You need to check that you only sign UID's carrying Alice's name that you verified from her passport or similar thing. I quite like it that I don't have to verify dozens of fingerprints manually; I'd like to keep the list if possible. So can we improve on the party where there is a line of both people on the list and people with keyslips? I think we can. I think ideally, the participants who only joined after the preparations should also be able to use the list for the people that are on it, to put checkmarks and be able to sign without manual fingerprint verification. But you can't /just/ give them a copy of the list on paper to trust on, because that printout could have been altered. If they have a printout with an altered fingerprint, this will confuse them and lead them down a bad road. But they don't actually need to check the fingerprint, right? Why print it out then? First, let me show you a possible participant list for Sassaman efficient, as produced by gpgparticipants (signing-party package of Debian). Then let me show what I'd like to alter. CUT HERE -----------------------------8<------------------>8----------------------------- Sunday, December 4, 2016; 12:00 Gyro Gearloose T E S T H Y B R I D P A R T Y List of Participants (v 1.0) Here's what you have to do with this file: (1) Print this UTF-8 encoded file to paper. (2) Compute this file's SHA256 checksum. gpg2 --print-md SHA256 ksp-test.txt (3) Fill in the hash values on the printout. (4) Bring the printout, a pen, and proof of identity to the key signing party (and be on time!). SHA256 Checksum: ____ ____ ____ ____ ____ ____ ____ ____ ____ ____ ____ ____ ____ ____ ____ ____ [ ] 001 [ ] Fingerprint OK [ ] ID OK pub rsa2048/35FEAAB2 2011-03-18 [SC] [expired: 2014-08-15] Key fingerprint = 7AA6 6193 3AFB F009 D3FF 931D 5A48 8393 35FE AAB2 uid Scrooge McDuck _______________________________________________________________________________ 002 [ ] Fingerprint OK [ ] ID OK pub rsa2048/17C05EBD 2014-08-13 [SC] [expired: 2015-05-29] Key fingerprint = 9BF2 FC98 F2C5 8E7C 2F1A BBB1 9D39 0555 17C0 5EBD uid Donald Duck _______________________________________________________________________________ 003 [ ] Fingerprint OK [ ] ID OK pub rsa1024/503560C4 2014-08-14 [SC] [expired: 2014-08-21] Key fingerprint = C956 4F26 D57B 160F 7258 7865 6CBD 1E35 5035 60C4 uid Daisy Duck _______________________________________________________________________________ 004 [ ] Fingerprint OK [ ] ID OK pub rsa2048/DE500B3E 2009-11-12 [C] [expires: 2017-10-19] Key fingerprint = 8FA9 4E79 AD6A B56E E38C E5CB AC46 EFE6 DE50 0B3E uid Peter Lebbing _______________________________________________________________________________ 005 [ ] Fingerprint OK [ ] ID OK pub rsa1024/DCDFDFA4 2012-03-17 [SC] [expires: 2016-12-10] Key fingerprint = 8254 72F3 7172 B95A DC73 49BE 98B6 7DE4 DCDF DFA4 uid 167-671 <167-671 at example.org> _______________________________________________________________________________ 006 [ ] Fingerprint OK [ ] ID OK pub rsa1024/0E675C27 2016-12-03 [SC] [expires: 2016-12-10] Key fingerprint = 9995 E685 2227 CB3F A7D0 D426 B0D4 EDBE 0E67 5C27 uid Magica De Spell _______________________________________________________________________________ -----------------------------8<------------------>8----------------------------- CUT HERE You can further process this list before printing with gpgsigs, which will annotate the list with both the checksum and an indication when you have already signed an UID (this changes the "uid" lines above to the format as seen in the next bit). Now I'm proposing to remove all information that does not need to be manually checked, and give all participants who didn't do the preparation this scrubbed list. It would look like this: CUT HERE -----------------------------8<------------------>8----------------------------- Sunday, December 4, 2016; 12:00 Gyro Gearloose T E S T H Y B R I D P A R T Y List of Participants (v 1.0) Here's what you have to do with this file: (1) Print this UTF-8 encoded file to paper. (2) Compute this file's SHA256 checksum. gpg2 --print-md SHA256 ksp-test.txt (3) Fill in the hash values on the printout. (4) Bring the printout, a pen, and proof of identity to the key signing party (and be on time!). SHA256 Checksum: CEA0 9114 F8AD 5FDD A0F4 7984 47C8 D1C1 3B1F B76B 68AC 3B12 78FE C3EC E95B 73D8 [ ] 001 [ ] Fingerprint OK [ ] ID OK ( ) Scrooge McDuck _______________________________________________________________________________ 002 [ ] Fingerprint OK [ ] ID OK ( ) Donald Duck _______________________________________________________________________________ 003 [ ] Fingerprint OK [ ] ID OK ( ) Daisy Duck _______________________________________________________________________________ 004 [ ] Fingerprint OK [ ] ID OK ( ) Peter Lebbing _______________________________________________________________________________ 005 [ ] Fingerprint OK [ ] ID OK ( ) 167-671 <167-671 at example.org> _______________________________________________________________________________ 006 [ ] Fingerprint OK [ ] ID OK ( ) Magica De Spell -----------------------------8<------------------>8----------------------------- CUT HERE Now once these people get home, they get the original text file from the organizer, and verify its checksum using their paper copy. Additionally, they need to check that the UID's on their paper copy have the same serial number as the ones in their digital copy. This is an additional task compared to what the other participants need to do; since the others printed their own version they *know* the only way UID's could have been swapped or added is if they did it themselves before printing. After the late participants have verified the checksum and the serial<->UID mapping, they can continue as the other people, not verifying fingerprints because they already verified the SHA256 sum. The reason for wiping out the parts that aren't checked is so people will not get confused should they mismatch. If the one doing the printing was malicious, they could alter fingerprints on the list. This would entice people to sign the key with that fingerprint, even though it is the wrong one. You could tell people that they need to ignore this unverified information and use the official, SHA256-verified digital list only, but that is asking for trouble. Just remove this unverified information and be done with it! So, thank you for reaching the bottom of my mail. What do you think? Does it work? If not, I'm falling back to the informal model, to remove the perverse incentive that arises from using Sassaman efficient, the incentive to treat latecomers as second-class (since my proposal includes them explicitly in the process, they won't be left out). Thanks, Peter. [1] The only reason I group the list people and the keyslip people is so you only have to switch exchange method twice; you start out with one group, halfway switch to the other group, and then later switch back to the first group. The people at the very beginning and end of the line only switch once. [2] Well, late as in not early. Let's hope they're not deceased by then ;-P. [3] There will be an issue here if the checksum did not check out for someone; the organizer should make clear that once your checksum is wrong, you should stop using that mangled version at once. -- 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 caro at nymph.paranoici.org Sun Dec 4 21:59:23 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Sun, 4 Dec 2016 20:59:23 +0000 (UTC) Subject: Implications of a common private keys directory in 2.1 References: <20161120203740.CAB33100A200@remailer.paranoici.org> <3b776db4-4161-35cc-31ac-b343b12edf7a@digitalbrains.com> <20161124131636.82DF810320FB@remailer.paranoici.org> <20161124230301.3055810320F5@remailer.paranoici.org> <17f5cadc-c7fb-c43a-a141-5d269ab45eaa@digitalbrains.com> Message-ID: <20161204205923.ADB011031FF9@remailer.paranoici.org> Peter Lebbing wrote: >On 25/11/16 00:03, Carola Grunwald wrote: >I think it would be better to implement the proxy on the client machine, >instead of on a server machine. That way, all secrets stay on the client >machine, and you could still use regular e-mail clients, just with an >IMAP server at the localhost. This seems *so* much better than a server >which can decrypt all client data! But let's take for granted that you >want to do it as you want to do it, on a server. You can do it either way. For several years now I myself run the proxy server on my laptop computer, holding a few dozen nyms for different purposes. > >I doubt you would run into any trouble just using a separate homedir per >user account. I don't think agents take a lot of resources. When the >user logs out, you make the agent quit as well. You could remove its >socket; it will notice and quit within a short while. There's also the >Assuan command KILLAGENT which does what it says on the tin. I don't >know what interface to GnuPG you were planning to use, but I would >strongly suggest GPGME; it's the official way of programmatically using >GnuPG. That said, I don't know if GPGME offers a way to issue the >KILLAGENT command. It's not about planning, the proxy system is in use for years. I started the project in 2006, for a short time with PGP 6.x DLLs, then moved to GnuPG 1.4, which, apart from the missing --faked-system-time option still works great, very reliable, extremely stable. Three months ago I thought it was time to adapt it to GnuPG 2.1, and the problems began. Just at the moment I have seven (!) gpg-agent.exe entries sharing the same HomeDir listed in the Windows Task-Manager, six of them frozen, one hopefully still alive. The system is up now for no more than 48 hours. You can't run a server this way. Users ask what's going on. I'm in trouble, seriously considering to return to 1.4. I don't use the GPGME interface, rather call gpg.exe directly. I don't think it makes any difference concerning performance. On program shutdown I terminate gpg-agent.exe based on its ProcessID. > >A separate homedir per user means you get the separation you wanted. So first of all I have to give every keyring its separate homedir to avoid the side effect of unintentional secret key deletion across keyrings, and to address the passphrase caching flaw I even have to keep each single secret key isolated in its own directory. > >I don't see the purpose of using the password of the user account for >encrypting the private key, though. It doesn't seem to add security and >does seem to add problems. If you're worried about seizure of the data >at rest, you could use a single server-wide passphrase to encrypt all >private keys used by GnuPG. You could use disk encryption, that seems >like an easy way out and would protect other sensitive data as well. Or >you could use a specialized pinentry implementation, that always returns >the same passphrase, which could be seeded when the server boots up. >Pinentries are easy to write. Full ACK. User accounts usually are LAN accounts, not that much under attack as the encrypted message, which needs a strong key and passphrase. > >If you really want to cut down on the number of running agents, I'd >first discuss this with the GnuPG developers. Is the agent well suited >to serve dozens, hundreds of private keys? If the design never accounted >for this possiblity, it might be horribly inefficient or expose >unexpected issues. Works fine with 1.4. > >(You could take the middle road and serve, say, 32 clients per agent.) > >However, that still presents a serious issue with private key ownership, >both in the case of multiple recipients and with --throw-keyids, which >you would not have with an agent per user. > >GPGME tells you which private key was used to decrypt the message. >However, if there are multiple recipients on the same proxy and they >share an agent, GnuPG will only use the first one that succeeds. If your >proxy software would inspect the recipient and only allow the owner of >the indicated key to read the message, the other recipients wouldn't be >able to read the message, because the agent never needed to use their >key in the first place. Argh. > >For hidden recipients, it would be a serious resource hog to try all >keys, and would additionally have the same problem with multiple recipients. > >An option --only-try-secret would solve both (your software >would know which to try for a given nym account), but such an option is >not available. You could try to make the case that such an option would >be a good idea to implement. It would serve more scenarios than just >yours. For instance, people with smartcards could use it when a message >is also encrypted to an on-disk key, when they can't or don't want to >insert their smartcard. And if somebody knows which key is the hidden >recipient, but has multiple secret keys, it would save them declining >all the dialogs for the keys that aren't the recipient. I'm not sure whether gpg.exe can handle the concatenation of dozens of '--try-secret-key A7DD28F363B0924E3B735F22A49104AD3835E227' parameters and stop using keys not on that list even with their passphrases in the cache. > >You are worried about all other kinds of key management issues. I don't >think that is really so worrisome. You could simply zap the revocation >certificate already on creation, or periodically zap the contents of the >openpgp-revocs.d dir altogether, I don't think they serve much of a >purpose in your scenario. Right. Revocation certificates are irrelevant. > And once a user account is deleted, simply >delete the accompanying secret key (--delete-secret-keys, not >--delete-secret-and-public-key). If it were that simple. Every user account can hold an unrestricted number of nym and WME accounts. When the mail client starts a POP3 request mail is retrieved from different sources. That may be a normal POP3 account as well as anonymous newsgroups repositories like alt.anonymous.messages from where incoming messages are downloaded, if necessary decoded, then sent to the client in one go. > >As long as you don't meddle with multiple public keyrings, this is just >fine. You might say multiple keyrings "without doubt have stood the test >of time in GnuPG 1.4", but I suspect this test of time is precisely what >has shown the people actually maintaining this feature that it is >riddled with hard issues. Don't get me wrong, but wasn't it just indolence to do without a separate sec key folder for each keyring? > >While we're touching on that subject, if you go the single agent route, >you could just hold all public keys in one keyring. I think it's built >to be big. GnuPG 2.1 is a lot more efficient with large keyrings than >previous versions. And public data is public data, right? No need to >wall it off. > >That does leave deletion of public keys, but you could do reference >counting in your proxy server. If somebody, through your interface, >imports a public key you already have, you increment its reference >count. When the user deletes the public key or the account is deleted, >you decrease the reference count. Once it hits zero, >--delete-public-key. Perhaps multiple keyrings would have saved you of >this, but it doesn't seem very complicated, there are no dependencies to >track or anything, just a simple reference count. > >Or you could use --no-default-keyring along with --keyring and use a >public keyring per user, that still works in GnuPG 2.1 right? Multiple >keyrings at the same time has interesting ambiguities, like where to >delete from and where to add to, which one to use when there are several >versions of a key, etcetera. I think your issue stemmed from using >--delete-secret-and-public-key rather than --delete-secret-keys. The >former is a combination of --delete-secret-keys and --delete-keys, and >with multiple public keyrings, --delete-keys gets "interesting". Exactly. For a user it looks like he has a key pair listed on one keyring, and when he adds and removes that key pair from a completely different keyring the secret key is removed from both. > >Again, a large part of this mail could just be thrown away unread (or >unwritten :) if you simply use a single homedir per user account. Is >this perceived saving of resources worth all this trouble? Changing >secret keyrings in GnuPG 1.4 is more or less replaced by changing >homedirs in GnuPG 2.1. It's not this difference which you're coming up >against here, it's the difference that 1.4 does everything in a single >process that quits when it's done. In 2.1, there's the agent, which >survives. I think a different agent for each of my current keyrings may be an option I could deal with. But ending up with dozens if not hundreds of agents around, working or frozen? I hope you understand that I don't like to bear responsibility for such a freaky scenario. It's a small tool running as a background task residing in the system tray. > >Something totally different, but brought up by other people before. Do >the generated private keys hold UID's? And if so, it's just the nym >e-mail address, right? No name portion. You'd better *very* clearly >inform your users then that your server is pretending to be the owner of >their nym address, and very clearly inform them that your server can >read all this encrypted data! You say they are free to add another layer >of encryption. Sure, but make them realise that without this, they are >placing a huge amount of trust in your server and its operators, and >where it is housed etcetera. If your software would run on the client, >this wouldn't be an issue. And it's a huge issue, IMHO. Your correspondent doesn't even have to know about your nym's key, which first and foremost is used to secure your proxy - nym server communication. He can use your nym's address as a normal mailbox without any encryption at all. But if you think client-to-client encryption is necessary then create and send him an additional key. IMHO no issue at all, the user rules. > >> Simple answer: You never know who your opponents are. How can you be >> sure the recipient of your mail isn't one of them? Or his network >> infiltrated and his computer compromised? > >Right, yes, pseudonymity, the recipient could be the adversary. I'm not >used to thinking about Alice or Bob that way. > >Anonymous remailers solve the time issue by random delays. You could do >that here as well: hold onto the mail for a random time once it's >submitted, then sign it, then hold onto it for some more time (random), >and only then submit it to the anonymous remailers. It's just two hops >extra random delay in the remailer network, in the sense of time spent. It's a transparent proxy server not caching any message. When the client sends a message, a '250 Ok' isn't returned before the proxy forwarded it to the Internet. How could the client otherwise get knowledge of processing problems. So, apart from wasting time by adding hours of latency at the sender just to get a different signature timestamp, your client would time out and drop the connection. Or think of someone who got the chance to send nym mail immediately through an open WLAN access point away from home. For him waiting is not an option. > >But if you want to drop timestamps, I doubt --faked-system-time is your >friend. Like the manual says, "only useful for testing"! It affects >everything. If someone creates a key and sends it to their >correspondent, and the correspondent would use a --faked-system-time >from before the creation date, *poof*. GnuPG will notice the key seems >to come from the future and deny to encrypt to it. Everything breaks >down. Same with expirations and extensions thereof. Also, there's the >trust database, which is periodically rebuilt and timestamped. >Interestingly, my GnuPG 2.1.11 didn't complain that the trust database >was from the future, but I wouldn't depend on this staying this way. > >Another nice edge case: a key is created at 14:54, but it's trying to >issue a signature at 12:00. Oops: > >$ echo hoi | gpg2 --faked-system-time "20161203T110000" -u 0E675C27 -s >gpg: WARNING: running with faked system time: 2016-12-03 11:00:00 >gpg: key 0E675C27 was created 10495 seconds in the future (time warp or >clock problem) >gpg: key 0E675C27 was created 10495 seconds in the future (time warp or >clock problem) >gpg: skipped "0E675C27": Unusable secret key >gpg: signing failed: Unusable secret key http://danner-net.de/omom/tutor_issues_gpg_time.gif With random time of yesterday (Day-1) for signatures or the day before (Day-2) for key creation, all UTC, it's secure. > >(I'm on CET, and --faked... is in UTC). > >And I wouldn't be surprised if there are more snags when you pretend >you're not living in the now. Sure you have to do all your timestamp calculations in UTC. Otherwise you'd even leak your timezone. > >I just checked the OpenPGP RFC, and though the signature timestamp is a >separate subpacket that could be omitted, there is a MUST requirement >that it is present. So to create an OpenPGP compliant message without a >good timestamp, you do have to fake a timestamp, unfortunately. Maybe >you could make the case that faking a signature timestamp should be a >feature? I can imagine a different use case: not letting the recipient >know you were still working on stuff at 3:00 in the night, even though >you were. But it doesn't seem like a high-priority feature request to me >(sorry). Of course that's a feature, an important feature protecting privacy, worth to be backported to v1.4. There always are situations where you want to prove the Who but not the When, which can be faked anyway. > >> Footnote: >> A pinch of paranoia helps develop solid anonymity software. >> Act as if there's no one out there you can trust. > >Yes. My mind is used to thinking about the recipient as implicitly >trusted with knowledge, which just isn't the case in a pseudonymous >system. Anonymity is easier in that respect: signatures make no sense at >all. That's correct. Many thanks for your profound considerations. Kind regards Caro From rag at ragged-software.com Sun Dec 4 22:29:02 2016 From: rag at ragged-software.com (Roy A. Gilmore) Date: Sun, 4 Dec 2016 13:29:02 -0800 Subject: Toggle the authenticate capability Message-ID: Hi, I have a keypair that was initially generated with the defaults, so the signing key also has the authenticate capability enabled. I want to add a separate authentication subkey for use with an OpenPGP smartcard. Is there any way to turn the authenticate capability off on the signing key? It doesn't sound like it should be that difficult, but I've searched using several different search terms, and I can't seem to find a way to do this. Roy A. Gilmore From andrewg at andrewg.com Mon Dec 5 00:09:38 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sun, 4 Dec 2016 23:09:38 +0000 Subject: Toggle the authenticate capability In-Reply-To: References: Message-ID: <59A0E8A8-83B5-4A66-A1CD-9FA02C6F59A2@andrewg.com> Hi Roy, You normally don't need to remove the A capability from a signing key. By default, gnupg will use the most recently created valid subkey with the appropriate capability, so all you need to do is create a new A subkey and it will be used in preference to the old one. Mathematically, authentication is just a special case of signing, so having both S and A on a subkey does not introduce extra vulnerabilities (that we know of). It is technically possible to change the capability flags on any key, but you can't do it with a vanilla version of the software. There is a patch somewhere in the archives of this list but I would recommend against it. The only use case where it would be necessary to remove a capability flag would be if you had created an encryption key that also had S or A capability - but it's almost impossible to do it by accident and in such cases it's safer to revoke the key and start again. Andrew Gallagher > On 4 Dec 2016, at 21:29, Roy A. Gilmore wrote: > > Hi, > > I have a keypair that was initially generated with the defaults, so the > signing key also has the authenticate capability enabled. I want to add > a separate authentication subkey for use with an OpenPGP smartcard. Is > there any way to turn the authenticate capability off on the signing > key? It doesn't sound like it should be that difficult, but I've > searched using several different search terms, and I can't seem to find > a way to do this. > > Roy A. Gilmore > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From rag at ragged-software.com Mon Dec 5 01:37:21 2016 From: rag at ragged-software.com (Roy A. Gilmore) Date: Sun, 4 Dec 2016 16:37:21 -0800 Subject: Toggle the authenticate capability In-Reply-To: <59A0E8A8-83B5-4A66-A1CD-9FA02C6F59A2@andrewg.com> References: <59A0E8A8-83B5-4A66-A1CD-9FA02C6F59A2@andrewg.com> Message-ID: <1653434b-d737-2cd2-9c93-d0c754237c1e@ragged-software.com> Hi Andrew, I didn't think that it would actually hurt anything, but, I wasn't sure about the internals. I'm a little bit OCD (or anal, or whatever neo-psychobabble term applies), and having the authentication capability on the signing key, after creating a authentication subkey just LOOKED wrong to me, whether it is wrong, is another story... Thank you, Roy A. Gilmore On 12/04/2016 03:09 PM, Andrew Gallagher wrote: > Hi Roy, > > You normally don't need to remove the A capability from a signing key. By default, gnupg will use the most recently created valid subkey with the appropriate capability, so all you need to do is create a new A subkey and it will be used in preference to the old one. Mathematically, authentication is just a special case of signing, so having both S and A on a subkey does not introduce extra vulnerabilities (that we know of). > > It is technically possible to change the capability flags on any key, but you can't do it with a vanilla version of the software. There is a patch somewhere in the archives of this list but I would recommend against it. The only use case where it would be necessary to remove a capability flag would be if you had created an encryption key that also had S or A capability - but it's almost impossible to do it by accident and in such cases it's safer to revoke the key and start again. > > Andrew Gallagher > >> On 4 Dec 2016, at 21:29, Roy A. Gilmore wrote: >> >> Hi, >> >> I have a keypair that was initially generated with the defaults, so the >> signing key also has the authenticate capability enabled. I want to add >> a separate authentication subkey for use with an OpenPGP smartcard. Is >> there any way to turn the authenticate capability off on the signing >> key? It doesn't sound like it should be that difficult, but I've >> searched using several different search terms, and I can't seem to find >> a way to do this. >> >> Roy A. Gilmore >> >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users >> > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From peter at digitalbrains.com Mon Dec 5 12:18:01 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 5 Dec 2016 12:18:01 +0100 Subject: Toggle the authenticate capability In-Reply-To: <59A0E8A8-83B5-4A66-A1CD-9FA02C6F59A2@andrewg.com> References: <59A0E8A8-83B5-4A66-A1CD-9FA02C6F59A2@andrewg.com> Message-ID: On 05/12/16 00:09, Andrew Gallagher wrote: > Mathematically, authentication is just a special case of > signing, so having both S and A on a subkey does not introduce extra > vulnerabilities (that we know of). Mathematically, I think you're wrong, it's very vulnerable :-). Authentication is signing the challenge sent to you by someone else, signature is signing the data you wish to approve of in some way. So if I can send you a challenge that would turn into a nice signature of you authorizing a bank payment to me, that would be easy money. However, in practice, a challenge has a different format than a data or key signature, and they can be differentiated. This isn't math, though. For RSA, you still do the modular exponentiation of RSA. When I brought up the issue some time ago here, I got no response, so I concluded it's not a problem. I was worried that some future authentication mechanism might actually produce the same data structure as a normal signature, but the lack of shared concern made me think it's probably not an issue then. > in such cases it's safer to revoke the key and start > again. If this is a signature /subkey/, they can be rotated willy-nilly. Expire the current signature key, create a new one and delete the private part of the old signature key. It doesn't need to be revoked. Which defaults produce an authentication-capable key by the way? I don't remember seeing that. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From lists at bertram-scharpf.de Mon Dec 5 13:11:01 2016 From: lists at bertram-scharpf.de (Bertram Scharpf) Date: Mon, 5 Dec 2016 13:11:01 +0100 Subject: Proof for a creation date In-Reply-To: References: <20161202021250.GA69543@becker.bs.l> Message-ID: <20161205121101.GA22821@becker.bs.l> On Thursday, 01. Dec 2016, 19:59:15 -0800, Schlacta, Christ wrote: > On Dec 1, 2016 7:43 PM, "Bertram Scharpf" wrote: > > > > we all know that kidnappers do publish a picture of their > > hostage holding up a todays newpaper. The purpose of this is > > to proof that the victim was alive _after_ a certain point > > of time. I want to do the opposite. I want to make evidence > > that I created a document _before_ a certain point of time. Thank you all for your detailed answers. I might resume it to two possibilities to accomplish the task: - Post a digest to a site where you cannot withdraw it ever and where it can be retrieved by everybody. This could be a Github issue, on Reddit or Twitter or maybe even on the GnuPG mailing list. The disadvantage is that you are dependent on the provider of the site to continue the service and that your information can be found there. This could most notably become a problem because the post is, in the end, an abuse of the forum. - Let one or more people sign your document and provide the signatures yourself. The weak point is how to find these people and to make them do what you want. The service makes signatures in a format that is no longer supported. Maybe a combination of both methods is a good way to handle the disadvantages. Bertram -- Bertram Scharpf Stuttgart, Deutschland/Germany http://www.bertram-scharpf.de From andrewg at andrewg.com Mon Dec 5 13:54:31 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 5 Dec 2016 12:54:31 +0000 Subject: Toggle the authenticate capability In-Reply-To: References: <59A0E8A8-83B5-4A66-A1CD-9FA02C6F59A2@andrewg.com> Message-ID: <79ef9ee7-7e1e-c034-3aac-a230187e37ee@andrewg.com> On 05/12/16 11:18, Peter Lebbing wrote: > On 05/12/16 00:09, Andrew Gallagher wrote: >> Mathematically, authentication is just a special case of >> signing, so having both S and A on a subkey does not introduce extra >> vulnerabilities (that we know of). > > Mathematically, I think you're wrong, it's very vulnerable :-). > Authentication is signing the challenge sent to you by someone else, > signature is signing the data you wish to approve of in some way. So if > I can send you a challenge that would turn into a nice signature of you > authorizing a bank payment to me, that would be easy money. You don't need A capability to perform this attack though - so long as you can social-engineer your way to getting someone to sign a message of your choice. This isn't a *mathematical* vulnerability but an implementation/procedural one, and it's not technically "extra" - although it could be viewed as widening an already existing hole. ;-) OK, I'm clutching at straws. I'll bail out of this argument now. ;-) > When I brought up the issue some time ago here, I got no response, so I > concluded it's not a problem. I was worried that some future > authentication mechanism might actually produce the same data structure > as a normal signature, but the lack of shared concern made me think it's > probably not an issue then. Yes, from an implementation point of view an authentication challenge and its response should be strictly formatted in a way that can't be mistaken for another protocol. Your auth routine shouldn't be blindly signing whatever plaintext the attacker suggests... >> in such cases it's safer to revoke the key and start >> again. > > If this is a signature /subkey/, they can be rotated willy-nilly. Expire > the current signature key, create a new one and delete the private part > of the old signature key. It doesn't need to be revoked. Sorry, yes expiry is as good as revocation, and this applies to both primary keys and subkeys. > Which defaults produce an authentication-capable key by the way? I don't > remember seeing that. I think it was Enigmail on OSX. This was a few years back though, and it may have changed since. Andrew. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Mon Dec 5 17:05:56 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 5 Dec 2016 17:05:56 +0100 Subject: Implications of a common private keys directory in 2.1 In-Reply-To: <20161204205923.ADB011031FF9@remailer.paranoici.org> References: <20161120203740.CAB33100A200@remailer.paranoici.org> <3b776db4-4161-35cc-31ac-b343b12edf7a@digitalbrains.com> <20161124131636.82DF810320FB@remailer.paranoici.org> <20161124230301.3055810320F5@remailer.paranoici.org> <17f5cadc-c7fb-c43a-a141-5d269ab45eaa@digitalbrains.com> <20161204205923.ADB011031FF9@remailer.paranoici.org> Message-ID: <78b30a87-43a1-bb2b-d965-c65a8a1c5b27@digitalbrains.com> On 04/12/16 21:59, Carola Grunwald wrote: > Three months ago I thought it was time to adapt it to GnuPG 2.1, and > the problems began. I would seriously consider the option of just sticking to 1.4. It's not deprecated for server use. It should still have a lot of life left in it. > Just at the moment I have seven (!) gpg-agent.exe entries sharing the > same HomeDir listed in the Windows Task-Manager, six of them frozen, > one hopefully still alive. That sounds like a bug. In fact, an agent-freezing bug was fixed a short while ago, are you runnning the latest and greatest? Otherwise, it might be a new bug. >> If you really want to cut down on the number of running agents, >> I'd first discuss this with the GnuPG developers. Is the agent well >> suited to serve dozens, hundreds of private keys? If the design >> never accounted for this possiblity, it might be horribly >> inefficient or expose unexpected issues. > > Works fine with 1.4. I understand what you mean (I think :), but you can't really draw any conclusions from that, I (also) think. The private key handling in the agent is all different code, a new architecture. That GnuPG 1.4 in practice works fine with many secret keys does not say anything about what the agent will do, even though they basically perform the same task. I might be overly cautious here; Werner might well say "well sure it handles lots of keys fine". But being cautious sometimes pays off tremendously well... > I'm not sure whether gpg.exe can handle the concatenation of dozens > of '--try-secret-key A7DD28F363B0924E3B735F22A49104AD3835E227' > parameters and stop using keys not on that list even with their > passphrases in the cache. But you know which nym address the message was addressed to, right? When somebody tries to open a message addressed to their me at nyma.com account, you only try the key associated with me at nyma.com. Two keys at max, when you're doing a key rotation and the old key is still valid. There is no need to try their me at nymb.com key, because you know it was addressed to me at nyma.com, and any message ending up there being encrypted to me at nymb.com could even be an attempt to link those identities: if me at nyma.com answers to the content of the mail, you now know they actually have the private key for me at nymb.com, and you've linked those accounts. It seems to me you *really* don't want any other keys to be tried *at all*, even if the user owns them. And similarly, if you could actually order the tried keys with non-hidden recipients, you would only specify one or two keys which both would be keys your user actually has. And --status-fd neatly tells you which key was used to decrypt, so you can easily verify the intended key was being used and not some other. However, right now, there is no way to force trying specific keys first with non-hidden recipients. > Don't get me wrong, but wasn't it just indolence to do without a > separate sec key folder for each keyring? Well, since Werner would actually like to get rid of multiple keyrings because of the problems it is giving, I can quite understand not touching it with a forty feet pole when creating something new. In fact, I wouldn't have been surprised if multiple public keyrings wasn't implemented in GnuPG 2.1. But he did maintain that feature for now. > Exactly. For a user it looks like he has a key pair listed on one > keyring, and when he adds and removes that key pair from a > completely different keyring the secret key is removed from both. Don't use --delete-secret-and-public-key, but --delete-keys and --delete-secret-keys. And as I said, multiple keyrings is asking for ambiguities when removing keys, or using a key that has multiple different versions on different keyrings. GnuPG 1.4 didn't always do the right thing with one secring and multiple pubring's either. Or, "the right thing"... I mean, "the thing the user intended". > But ending up with dozens if not hundreds of agents around, working > or frozen? I hope you understand that I don't like to bear > responsibility for such a freaky scenario. No, but the freezing seems like a bug, a bug that should be fixed if it is the agent's fault. And if you actually have hundreds of users logged in at the same time, I would not think that hundreds of agents is actually significant. Have you tried to run a test load, see what resources those agents actually take? And whether that's actually significant compared to the processing involved in handling all those mails of which they are doing the assymetric decryption part? I am assuming you kill an agent when a user logs off. > It's a small tool running as a background task residing in the system > tray. Maybe I don't understand, your proxy serving hundreds of users with each possibly dozens of nym accounts is a diminutive part of the server? Or do you mean when it is running on the client? > Your correspondent doesn't even have to know about your nym's key, > which first and foremost is used to secure your proxy - nym server > communication. The problem is the impersonation and who actually is the account holder of a nym account. Your server is pretending to be the holder, or, actually is the account holder. Your users don't own the nym account anymore. They need to know this. The proxy might allow them to use the nym address, but the proxy is the holder of the nym address. It holds the private key. QED. In the end, the nym server is actually the real /owner/. But this is more easily understood by users. They might not realize that they are actually authorizing your proxy to do their business on their behalf, impersonate them even. But it is a pseudonym, so it's less bad than impersonating them using their legal name. > But if you think client-to-client encryption is necessary then create > and send him an additional key. IMHO no issue at all, the user > rules. Iff they know how it works! User education is very important here, because if they think "it's encrypted and pseudonymous" and don't use an additional key, they are unwittingly including you (as server operator) in their private communications! > It's a transparent proxy server not caching any message. When the > client sends a message, a '250 Ok' isn't returned before the > proxy forwarded it to the Internet. How could the client otherwise > get knowledge of processing problems. So, apart from wasting time by > adding hours of latency at the sender just to get a different > signature timestamp, your client would time out and drop the > connection. This doesn't make sense to me. You don't want to expose the time the signing is done, but then you go and expose the timing of it anyway by sending the mail right away straight to its destination because your user doesn't want to wait? I think those users that can't wait also can't use anonymous remailers then? Several hops of anonymous remailers takes longer than two delays on the proxy. When they can't wait for the proxy to delay, they certainly can't wait for the anonymous remailers taking even more time. And if the anonymous remailers don't delay, they still leak the time of sending as much as your signature timestamp does, and do so to all passive listeners rather than just the nym server decrypting the message and seeing the signature. I can understand not wanting to change a design much that has been running for many years, so I am not saying you should do everything differently. But keep it as it is for the right reasons. This doesn't seem to be one to me. Unless I'm once more missing something :-). > Or think of someone who got the chance to send nym mail immediately > through an open WLAN access point away from home. For him waiting is > not an option. I'm not suggesting that the proxy force the client to wait before sending the message to the proxy, or to wait for confirmation from the proxy. That would be silly, because the actual communication over the public internet would still take place at the same time as signing, just a bit later. You want to lose the temporal connection between the client sending the message and it being processed further. I'm saying it should accept the message (do sanity checks), hold it in a queue for a while, and only then sign it. Hold on to it some more, and then send it on. An anonymous remailer wouldn't force an incoming connection to wait for a while either, right? It would accept the whole message, wait, send on. > Of course that's a feature, an important feature protecting privacy, > worth to be backported to v1.4. I think this distinction is important: *It's not a feature in any GnuPG version*. That you can abuse things to do what you want does not make it a supported feature! I see a place for such a feature, but ultimately, the maintainers decide whether it has a place in GnuPG or not, even if another developer did the work of implementing it. > Many thanks for your profound considerations. I enjoy thinking about such stuff, and I hope it is useful to people I'm thinking it aloud to... By the way, thanks for working on solutions to let people protect their privacy and identity. It's important work in today's society! 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 rag at ragged-software.com Mon Dec 5 17:07:01 2016 From: rag at ragged-software.com (Roy A. Gilmore) Date: Mon, 5 Dec 2016 08:07:01 -0800 Subject: Toggle the authenticate capability In-Reply-To: References: <59A0E8A8-83B5-4A66-A1CD-9FA02C6F59A2@andrewg.com> Message-ID: <737a3888-9208-7f99-8e49-cd2f22d530bb@ragged-software.com> Hi Peter, Well, that got me thinking, and, I generated some dummy keys with gpg from gnupg-1.4.21-1.fc24.x86_64, gpg2 from gnupg2-2.1.13-2.fc24.x86_64, and neither gpg or gpg2 enabled the authentication capability on the signing key. However, when generating dummy a key with enigmail from thunderbird-enigmail-1.9.6-1.fc24.noarch, enigmail does enable the authentication capability on the signing key. This is NOT because of gnupg defaults, this is problem with enigmail. I still wish there was an easy way to turn off this capability on existing keys. Thank you, Roy A. Gilmore On 12/05/2016 03:18 AM, Peter Lebbing wrote: > On 05/12/16 00:09, Andrew Gallagher wrote: >> Mathematically, authentication is just a special case of >> signing, so having both S and A on a subkey does not introduce extra >> vulnerabilities (that we know of). > Mathematically, I think you're wrong, it's very vulnerable :-). > Authentication is signing the challenge sent to you by someone else, > signature is signing the data you wish to approve of in some way. So if > I can send you a challenge that would turn into a nice signature of you > authorizing a bank payment to me, that would be easy money. > > However, in practice, a challenge has a different format than a data or > key signature, and they can be differentiated. This isn't math, though. > For RSA, you still do the modular exponentiation of RSA. > > When I brought up the issue some time ago here, I got no response, so I > concluded it's not a problem. I was worried that some future > authentication mechanism might actually produce the same data structure > as a normal signature, but the lack of shared concern made me think it's > probably not an issue then. > >> in such cases it's safer to revoke the key and start >> again. > If this is a signature /subkey/, they can be rotated willy-nilly. Expire > the current signature key, create a new one and delete the private part > of the old signature key. It doesn't need to be revoked. > > Which defaults produce an authentication-capable key by the way? I don't > remember seeing that. > > HTH, > > Peter. > From andrewg at andrewg.com Mon Dec 5 18:16:33 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 5 Dec 2016 17:16:33 +0000 Subject: Implications of a common private keys directory in 2.1 In-Reply-To: <20161204205923.ADB011031FF9@remailer.paranoici.org> References: <20161120203740.CAB33100A200@remailer.paranoici.org> <3b776db4-4161-35cc-31ac-b343b12edf7a@digitalbrains.com> <20161124131636.82DF810320FB@remailer.paranoici.org> <20161124230301.3055810320F5@remailer.paranoici.org> <17f5cadc-c7fb-c43a-a141-5d269ab45eaa@digitalbrains.com> <20161204205923.ADB011031FF9@remailer.paranoici.org> Message-ID: <6c0c8e60-effe-ed81-572e-e93aedac3aba@andrewg.com> On 04/12/16 20:59, Carola Grunwald wrote: > It's a small > tool running as a background task residing in the system tray. Hold on a sec. Are you running a pseudonymity service on your personal desktop? Andrew. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Mon Dec 5 19:20:17 2016 From: wk at gnupg.org (Werner Koch) Date: Mon, 05 Dec 2016 19:20:17 +0100 Subject: Toggle the authenticate capability In-Reply-To: (Roy A. Gilmore's message of "Sun, 4 Dec 2016 13:29:02 -0800") References: Message-ID: <87oa0qqlum.fsf@wheatstone.g10code.de> On Sun, 4 Dec 2016 22:29, rag at ragged-software.com said: > a separate authentication subkey for use with an OpenPGP smartcard. Is > there any way to turn the authenticate capability off on the signing > key? It doesn't sound like it should be that difficult, but I've gpg --edit-key YOURKEY Select the key you want to change using "key N", enter change-usage and follow the prompts. 2.1 only Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From rag at ragged-software.com Mon Dec 5 19:53:16 2016 From: rag at ragged-software.com (Roy A. Gilmore) Date: Mon, 5 Dec 2016 10:53:16 -0800 Subject: Toggle the authenticate capability In-Reply-To: <87oa0qqlum.fsf@wheatstone.g10code.de> References: <87oa0qqlum.fsf@wheatstone.g10code.de> Message-ID: <5bad46ca-d909-d247-641b-faa8df4f5b0c@ragged-software.com> Hi Werner, Well, I feel stupid now, after reading your message, I tried "change-usage", and it works. It's not in the man page, or listed in the --edit-key help menu, but, there is a one-line note in the NEWS file, stating that is for testing, so "change-usage" is actually documented, and I missed it somehow. Thank you very much, Roy A. Gilmore On 12/05/2016 10:20 AM, Werner Koch wrote: > On Sun, 4 Dec 2016 22:29, rag at ragged-software.com said: > >> a separate authentication subkey for use with an OpenPGP smartcard. Is >> there any way to turn the authenticate capability off on the signing >> key? It doesn't sound like it should be that difficult, but I've > gpg --edit-key YOURKEY > > > Select the key you want to change using "key N", enter > > change-usage > > and follow the prompts. 2.1 only > > > Shalom-Salam, > > Werner > From glenn at rempe.us Mon Dec 5 21:03:49 2016 From: glenn at rempe.us (Glenn Rempe) Date: Mon, 5 Dec 2016 12:03:49 -0800 Subject: Proof for a creation date In-Reply-To: <20161205121101.GA22821@becker.bs.l> References: <20161202021250.GA69543@becker.bs.l> <20161205121101.GA22821@becker.bs.l> Message-ID: <1abbc734-7040-85cd-edb1-4f7d8489a706@rempe.us> On 12/5/16 4:11 AM, Bertram Scharpf wrote: > I might resume it to two possibilities to accomplish the task: > > - Post a digest to a site where you cannot withdraw it > ever and where it can be retrieved by everybody. This > could be a Github issue, on Reddit or Twitter or maybe > even on the GnuPG mailing list. Posting on a forum or github issue does not provide immutable and cryptographically verifiable proof that a digest existed at a specific point in time. It is very weak from that standpoint. > > The disadvantage is that you are dependent on the > provider of the site to continue the service and that > your information can be found there. This could most > notably become a problem because the post is, in the > end, an abuse of the forum. If you use one of the services that implants your digest on the blockchain it is guaranteed to be immutable once transactions are layered on top of it (within minutes to hours). This approach does NOT require the service that originally posted this digest to continue to exist past that point in time as you can independently verify either the digest or the merkle tree root digest that you posted using open source software. As an example, I wrote a Ruby wrapper for the Tierion API and this Ruby code does not require Tierion to continue to exist past the point when you retrieve a receipt (which are the merkle tree root verification instructions that the code can follow). You can verify that a hash exists in the merkle tree independently and for as long as the blockchain exists (or as long as you keep your own independent copy of it). This also provides consensus from thousands of miner machines as to the rough time when a transaction containing your digest was submitted since all transactions contain the hash of the prior transactions. Changing and earlier hash would also require rebuilding all hashes on top of it which is considered computationally infeasible. This is similar to how a chain of git commits work, but distributed with real monetary value on the line. It usually takes about 10-30 minutes from when you submit the hash to when it is permanently and immutably embedded in the blockchain. Tierion is free to use, but requires you to calculate the merkle tree proof to verify it later (not hard with open source software that is available). www.proofofexistence.com directly submits your digest on the blockchain (no merkle tree, your transaction is not shared with other digests), so it is a bit easier to prove later, but you need to pay them in BTC to cover the transaction costs and their costs at the time you make the API call. I think its a couple of dollars worth of BTC. See https://github.com/grempe/tierion https://tierion.com/docs#blockchain-receipts http://www.chainpoint.org https://en.wikipedia.org/wiki/Merkle_tree https://tierion.com/docs/hashapi https://www.proofofexistence.com > - Let one or more people sign your document and provide > the signatures yourself. > > The weak point is how to find these people and to make > them do what you want. The service > makes > signatures in a format that is no longer supported. Not only does itconult.co.uk provide signatures from a key that is no longer importable in modern GnuPG, you are also relying on the fact that their system clock is accurate and can never be changed maliciously or through error. This is not an assumption you can make. There is also no immutable storage of the hash only a signature that was claimed to be made at a certain time. A claim that cannot be verified later since it is lacking context. From roman.zeyde at gmail.com Tue Dec 6 12:30:27 2016 From: roman.zeyde at gmail.com (Roman Zeyde) Date: Tue, 6 Dec 2016 13:30:27 +0200 Subject: Proof for a creation date In-Reply-To: <20161205121101.GA22821@becker.bs.l> References: <20161202021250.GA69543@becker.bs.l> <20161205121101.GA22821@becker.bs.l> Message-ID: You can also use OpenTimestamps service as described here: https://petertodd.org/2016/opentimestamps-announcement On Mon, Dec 5, 2016 at 2:11 PM, Bertram Scharpf wrote: > On Thursday, 01. Dec 2016, 19:59:15 -0800, Schlacta, Christ wrote: > > On Dec 1, 2016 7:43 PM, "Bertram Scharpf" > wrote: > > > > > > we all know that kidnappers do publish a picture of their > > > hostage holding up a todays newpaper. The purpose of this is > > > to proof that the victim was alive _after_ a certain point > > > of time. I want to do the opposite. I want to make evidence > > > that I created a document _before_ a certain point of time. > > Thank you all for your detailed answers. > > I might resume it to two possibilities to accomplish the task: > > - Post a digest to a site where you cannot withdraw it > ever and where it can be retrieved by everybody. This > could be a Github issue, on Reddit or Twitter or maybe > even on the GnuPG mailing list. > > The disadvantage is that you are dependent on the > provider of the site to continue the service and that > your information can be found there. This could most > notably become a problem because the post is, in the > end, an abuse of the forum. > > - Let one or more people sign your document and provide > the signatures yourself. > > The weak point is how to find these people and to make > them do what you want. The service > makes > signatures in a format that is no longer supported. > > Maybe a combination of both methods is a good way to handle > the disadvantages. > > Bertram > > > -- > Bertram Scharpf > Stuttgart, Deutschland/Germany > http://www.bertram-scharpf.de > > _______________________________________________ > 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 stebe at mailbox.org Tue Dec 6 15:53:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Tue, 06 Dec 2016 14:53:00 +0000 Subject: Implications of a common private keys directory in 2.1 In-Reply-To: <20161204205923.ADB011031FF9@remailer.paranoici.org> References: <20161120203740.CAB33100A200@remailer.paranoici.org> <3b776db4-4161-35cc-31ac-b343b12edf7a@digitalbrains.com> <20161124131636.82DF810320FB@remailer.paranoici.org> <20161124230301.3055810320F5@remailer.paranoici.org> <17f5cadc-c7fb-c43a-a141-5d269ab45eaa@digitalbrains.com> <20161204205923.ADB011031FF9@remailer.paranoici.org> Message-ID: <1306a235-ce87-b065-ab53-d4a821555ebf@mailbox.org> Carola Grunwald: > Peter Lebbing wrote: >> On 25/11/16 00:03, Carola Grunwald wrote: [...] >> An option --only-try-secret would solve both (your software >> would know which to try for a given nym account), but such an option is >> not available. You could try to make the case that such an option would >> be a good idea to implement. It would serve more scenarios than just >> yours. For instance, people with smartcards could use it when a message >> is also encrypted to an on-disk key, when they can't or don't want to >> insert their smartcard. And if somebody knows which key is the hidden >> recipient, but has multiple secret keys, it would save them declining >> all the dialogs for the keys that aren't the recipient. > > I'm not sure whether gpg.exe can handle the concatenation of dozens of > '--try-secret-key A7DD28F363B0924E3B735F22A49104AD3835E227' parameters > and stop using keys not on that list even with their passphrases in the > cache. If you created a special (secret) keyring file (being encrypted to your server's subkey as an additional security measure) containing all secret keys you'd need to have in there (=all those keys your particular agent instance has to serve), and use it as in gpg2 --no-default-keyring --secret-keyring file --try-secret-key [NAME=aspecificlongKeyID | fingerprint] --decrypt any_signedANDencrypted_message.txt.gpg ? Would that work? Would that be feasible? This option should be available for GNuPG's Windows version as well. (I understand that you're in a Windows (server) environment and are talking about gpg4win, are you?) Wouldn't gpg 2.1 then just use this one and only key for decryption (which is part of that secret keyring file) and, otherwise (if this key fails to decrypt), give up on decrypting? I can't reproduce your environment right now, so I can't try it out, it's just a guess. Cheers Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x4218732B.asc Type: application/pgp-keys Size: 4089 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Tue Dec 6 20:29:42 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 6 Dec 2016 20:29:42 +0100 Subject: Implications of a common private keys directory in 2.1 In-Reply-To: <1306a235-ce87-b065-ab53-d4a821555ebf@mailbox.org> References: <20161120203740.CAB33100A200@remailer.paranoici.org> <3b776db4-4161-35cc-31ac-b343b12edf7a@digitalbrains.com> <20161124131636.82DF810320FB@remailer.paranoici.org> <20161124230301.3055810320F5@remailer.paranoici.org> <17f5cadc-c7fb-c43a-a141-5d269ab45eaa@digitalbrains.com> <20161204205923.ADB011031FF9@remailer.paranoici.org> <1306a235-ce87-b065-ab53-d4a821555ebf@mailbox.org> Message-ID: On 06/12/16 15:53, Stephan Beck wrote: > [...], and use it as in > gpg2 --no-default-keyring --secret-keyring file --try-secret-key > [NAME=aspecificlongKeyID | fingerprint] --decrypt > any_signedANDencrypted_message.txt.gpg ? > Would that work? >From the GnuPG 2.1 man page: --secret-keyring file This is an obsolete option and ignored. All secret keys are stored in the ?private-keys-v1.d? directory below the GnuPG home directory. GnuPG 2.1 works in a different way with secret key material, so you can't have multiple secret keyrings in the same homedir anymore. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From ndk.clanbo at gmail.com Tue Dec 6 22:42:38 2016 From: ndk.clanbo at gmail.com (NdK) Date: Tue, 6 Dec 2016 22:42:38 +0100 Subject: Proof for a creation date In-Reply-To: References: <20161202021250.GA69543@becker.bs.l> <20161205121101.GA22821@becker.bs.l> Message-ID: <13ae387a-f287-1ebd-e882-0da7a7af88e6@gmail.com> Il 06/12/2016 12:30, Roman Zeyde ha scritto: > You can also use OpenTimestamps service as described here: > https://petertodd.org/2016/opentimestamps-announcement Interesting! To remain on-topic, I'd like to take the "footnote 3": -8<-- An interesting nuance to this is someone who has stolen a PGP key could also create a revocation, and they could backdate it to deny access to previously created signatures; there?s a lot of interesting design questions about how to deal with this with random beacons and the like that are beyond the scope of this blog post -8<-- That could actually reduce trust in any PGP signature, unless there's a way to timestamp 'something' that says "as of 'now' this key have not been revoked". Ideally that attestation should be included with the signature itself. BYtE, Diego From andrewg at andrewg.com Tue Dec 6 23:14:26 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 6 Dec 2016 22:14:26 +0000 Subject: Proof for a creation date In-Reply-To: <13ae387a-f287-1ebd-e882-0da7a7af88e6@gmail.com> References: <20161202021250.GA69543@becker.bs.l> <20161205121101.GA22821@becker.bs.l> <13ae387a-f287-1ebd-e882-0da7a7af88e6@gmail.com> Message-ID: So, essentially OCSP? Andrew Gallagher > On 6 Dec 2016, at 21:42, NdK wrote: > > That could actually reduce trust in any PGP signature, unless there's a > way to timestamp 'something' that says "as of 'now' this key have not > been revoked". Ideally that attestation should be included with the signature itself From ndk.clanbo at gmail.com Tue Dec 6 23:57:58 2016 From: ndk.clanbo at gmail.com (NdK) Date: Tue, 6 Dec 2016 23:57:58 +0100 Subject: Proof for a creation date In-Reply-To: References: <20161202021250.GA69543@becker.bs.l> <20161205121101.GA22821@becker.bs.l> <13ae387a-f287-1ebd-e882-0da7a7af88e6@gmail.com> Message-ID: <5258483c-b31f-ce8b-5e33-9399a4868091@gmail.com> Il 06/12/2016 23:14, Andrew Gallagher ha scritto: >> That could actually reduce trust in any PGP signature, unless there's a >> way to timestamp 'something' that says "as of 'now' this key have not >> been revoked". Ideally that attestation should be included with the signature itself > So, essentially OCSP? That's the idea, but in GPG trust model... Is it possible? BYtE, Diego From andrewg at andrewg.com Wed Dec 7 00:27:08 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 6 Dec 2016 23:27:08 +0000 Subject: Proof for a creation date In-Reply-To: <5258483c-b31f-ce8b-5e33-9399a4868091@gmail.com> References: <20161202021250.GA69543@becker.bs.l> <20161205121101.GA22821@becker.bs.l> <13ae387a-f287-1ebd-e882-0da7a7af88e6@gmail.com> <5258483c-b31f-ce8b-5e33-9399a4868091@gmail.com> Message-ID: <1150AD0E-49EB-45AB-B9A7-820E32A1562A@andrewg.com> I don't see any reason why it couldn't be done in principle - anyone who wants could set up an "authority" that produces a regular, signed list of all the certificates it currently trusts at each point in time. The trick is a) making sure that revocations get submitted to the authority in a timely fashion and b) working out whether to trust the authority in the first place. But that's a problem in OCSP too. In general, anything you can do in the X509 trust model you can do in PGP - but with a little more effort and a lot fewer default assumptions. Andrew Gallagher > On 6 Dec 2016, at 22:57, NdK wrote: > > Il 06/12/2016 23:14, Andrew Gallagher ha scritto: > >>> That could actually reduce trust in any PGP signature, unless there's a >>> way to timestamp 'something' that says "as of 'now' this key have not >>> been revoked". Ideally that attestation should be included with the signature itself >> So, essentially OCSP? > That's the idea, but in GPG trust model... Is it possible? > > BYtE, > Diego > From ndk.clanbo at gmail.com Wed Dec 7 06:50:40 2016 From: ndk.clanbo at gmail.com (NdK) Date: Wed, 7 Dec 2016 06:50:40 +0100 Subject: Proof for a creation date In-Reply-To: <1150AD0E-49EB-45AB-B9A7-820E32A1562A@andrewg.com> References: <20161202021250.GA69543@becker.bs.l> <20161205121101.GA22821@becker.bs.l> <13ae387a-f287-1ebd-e882-0da7a7af88e6@gmail.com> <5258483c-b31f-ce8b-5e33-9399a4868091@gmail.com> <1150AD0E-49EB-45AB-B9A7-820E32A1562A@andrewg.com> Message-ID: <7d3729f6-22ea-519b-d84d-3a6c9e22c52d@gmail.com> Il 07/12/2016 00:27, Andrew Gallagher ha scritto: > I don't see any reason why it couldn't be done in principle - anyone who wants could set up an "authority" that produces a regular, signed list of all the certificates it currently trusts at each point in time. The trick is a) making sure that revocations get submitted to the authority in a timely fashion and b) working out whether to trust the authority in the first place. But that's a problem in OCSP too. The "stapling" part is the hardest, since with OCSP usually you need to verify that something is valid "now", while with a GPG signature you should be able to attest that something will be valid "forever". The only way to obtain that (I can think of, and assuming no online verification: online services come & go...) is having at least three different kind of keys (RSA, EC, PQ) sign at least three different hash function results *each*, so that even if an algorithm or two gets cracked the signature remains valid. > In general, anything you can do in the X509 trust model you can do in PGP - but with a little more effort and a lot fewer default assumptions. That's good: this way most "implicit assumptions" must be explicited and their security impatc must be evaluated. BYtE, Diego From andrewg at andrewg.com Wed Dec 7 09:53:43 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 7 Dec 2016 08:53:43 +0000 Subject: Proof for a creation date In-Reply-To: <7d3729f6-22ea-519b-d84d-3a6c9e22c52d@gmail.com> References: <20161202021250.GA69543@becker.bs.l> <20161205121101.GA22821@becker.bs.l> <13ae387a-f287-1ebd-e882-0da7a7af88e6@gmail.com> <5258483c-b31f-ce8b-5e33-9399a4868091@gmail.com> <1150AD0E-49EB-45AB-B9A7-820E32A1562A@andrewg.com> <7d3729f6-22ea-519b-d84d-3a6c9e22c52d@gmail.com> Message-ID: > On 7 Dec 2016, at 05:50, NdK wrote: > > The "stapling" part is the hardest, since with OCSP usually you need to > verify that something is valid "now", while with a GPG signature you > should be able to attest that something will be valid "forever". No signature can possibly attest that something is valid *forever*. You're right that stapling is absolutely required in a data at rest use case, because a real time service only makes sense for ephemeral comms. But it's just a form statement by the authority which the sender appends to their signed data. > The only way to obtain that (I can think of, and assuming no online > verification: online services come & go...) is having at least three > different kind of keys (RSA, EC, PQ) sign at least three different hash > function results *each*, so that even if an algorithm or two gets > cracked the signature remains valid. Trying to protect against future compromise of a signature algorithm is really hard. And once you open that door, all data at rest signatures are questionable. Merkle trees protect against this though, as not only do you have to forge the signature, but also recreate the entire subsequent merkle tree, which should be infeasible. If you embed the OCSP response in the tree with the signed data, then it enjoys the same protection. A From stebe at mailbox.org Wed Dec 7 12:47:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Wed, 07 Dec 2016 11:47:00 +0000 Subject: Implications of a common private keys directory in 2.1 In-Reply-To: References: <20161120203740.CAB33100A200@remailer.paranoici.org> <3b776db4-4161-35cc-31ac-b343b12edf7a@digitalbrains.com> <20161124131636.82DF810320FB@remailer.paranoici.org> <20161124230301.3055810320F5@remailer.paranoici.org> <17f5cadc-c7fb-c43a-a141-5d269ab45eaa@digitalbrains.com> <20161204205923.ADB011031FF9@remailer.paranoici.org> <1306a235-ce87-b065-ab53-d4a821555ebf@mailbox.org> Message-ID: <075f88a4-81b3-0257-3d06-6ba3776689d1@mailbox.org> Peter Lebbing: > On 06/12/16 15:53, Stephan Beck wrote: >> [...], and use it as in >> gpg2 --no-default-keyring --secret-keyring file --try-secret-key >> [NAME=aspecificlongKeyID | fingerprint] --decrypt >> any_signedANDencrypted_message.txt.gpg ? >> Would that work? > >>From the GnuPG 2.1 man page: > > --secret-keyring file > This is an obsolete option and ignored. All secret keys are > stored in the ?private-keys-v1.d? directory below the GnuPG home > directory. > > GnuPG 2.1 works in a different way with secret key material, so you can't have multiple secret keyrings in the same homedir anymore. Oh, I missed this point. Thanks for putting it right. And it's more, no code left in gpg 2.1 for handling (secret) key material. Another mistake is (from what I have learned now) that you can only apply --try-secret-key together with --hidden-recipients. Anyway, if there was an "!" option as in --export-secret-subkeys keyID! you would be able to indicate/convince/force gpg 2.0.x to use a particular (sub)key. But I think this only refers to the case of having several subkeys, and at the moment of exporting one of them. And it's a 2.0.x option, I haven't checked the 2.1 manual for this particular option yet, though. Thanks Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x4218732B.asc Type: application/pgp-keys Size: 4089 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From ndk.clanbo at gmail.com Wed Dec 7 15:12:49 2016 From: ndk.clanbo at gmail.com (NdK) Date: Wed, 7 Dec 2016 15:12:49 +0100 Subject: Proof for a creation date In-Reply-To: References: <20161202021250.GA69543@becker.bs.l> <20161205121101.GA22821@becker.bs.l> <13ae387a-f287-1ebd-e882-0da7a7af88e6@gmail.com> <5258483c-b31f-ce8b-5e33-9399a4868091@gmail.com> <1150AD0E-49EB-45AB-B9A7-820E32A1562A@andrewg.com> <7d3729f6-22ea-519b-d84d-3a6c9e22c52d@gmail.com> Message-ID: <4d44f7bc-e600-be10-d3ba-3bf2b58a9cc1@gmail.com> Il 07/12/2016 09:53, Andrew Gallagher ha scritto: > No signature can possibly attest that something is valid *forever*. Well, "till the heat death of the Universe" can be enough for any practical purpose :) > You're right that stapling is absolutely required in a data at rest > use case, because a real time service only makes sense for ephemeral > comms. But it's just a form statement by the authority which the > sender appends to their signed data. My aim is something that's still secure even if some big leaps happen. Say QC becomes feasible: current pki methods (RSA and EC) are to be considered insecure. Hence I included a PQ signature (maybe NewHope?). > Trying to protect against future compromise of a signature algorithm is > really hard. And once you open that door, all data at rest signatures > are questionable. Well, actually symmetric crypto could be used with a system like the one used for one-time signatures: you sign both the (hash of the ) plaintext and the hash of the cyphertext obtained encrypting that plaintext with a (randomly generated, single use) secret key. This system allows a single arbitration: you give the judge the secret key used and he verifies that: a) the hash on the plaintext matches the signed one (everyone ca do this) b) the hash on the cyphertext matches the signed one (everyone ca do this, too) c) the hash of the plaintext encrypted under the given key matches b) A timestamping service could easily generate such a key from a "really secret key" (never disclosed) and the timestamp, maybe using a truncated hash (to prevent a possible hash inversion attack to determine the "really secret key") and remain able to disclose it to the judge without compromising other signatures' security. An attacker should be able to find another (meaningful!) messages that hashes to the same value and whose cyphertext under an unknown key would result in the other hash value. H(p')==H(p) H(Ek(p'))==H(Ek(p)) (for every k, since he does not know k) > Merkle trees protect against this though, as not only do you have to > forge the signature, but also recreate the entire subsequent merkle > tree, which should be infeasible. IIUC, merkle trees remain secure only if they continue to "evolve". If an attacker does have enough (more than 50%) computing power, he can control the tree's growth. And possibly rewrite the history (IIRC something similar happened not long ago, when a single group of miners had had for some hours the needed "quorum"). > If you embed the OCSP response in the tree with the signed data, then > it enjoys the same protection. I have to think about this a bit more... I'm not completely sure. To be at least partially in topic, it should be possible to do the signing (and the encryption) even with the current GnuPG version... BYtE, Diego From rjh at sixdemonbag.org Wed Dec 7 20:22:46 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 7 Dec 2016 14:22:46 -0500 Subject: RFC on issue 2701, default expiration time for new keys In-Reply-To: <7a1e7b19-3808-a23e-8596-ec359a197d49@digitalbrains.com> References: <87pol49bch.fsf@europa.jade-hamburg.de> <20161207133329.GB32600@zeromail.org> <7a1e7b19-3808-a23e-8596-ec359a197d49@digitalbrains.com> Message-ID: <00d901d250bf$4c5b4070$e511c150$@sixdemonbag.org> > I'd not say "THE best practices document", but rather "A RANDOM best > practices document someone wrote". There are lots of those, and can freely > be ignored, IMNSHO. I'd go one step further: this is not even a best-practices document. Any document which claims to be a best-practices document which does not have, as a high-priority item, "Figure out your threat model," is frankly just somebody pretending to be competent. [puts on FAQ maintainer hat] Every now and again I get someone asking me why there aren't best practices listed in the FAQ. The answer is always the same: because GnuPG doesn't really have them. GnuPG is a toolkit you use to implement part of your custom solution to address your particular threat model. As such, the idea of "best practices" that are one-size-fits-all is really kind of silly. There might be some merit in a "Things To Think About" document, but the idea of a single best-practices document that applies to everyone everywhere borders on the absurd. [takes off hat] > This document also recommends creating a 4K RSA key. And it complicates > matters by strongly recommending installing parcimonie and Tor over just > using --refresh-keys. That's one more hurdle for users to overcome in an > already very complicated matter, and as such, IMNSHO, it is actually > hindering user adoption. It also recommends ignoring things like the keyserver-url field on a certificate. Which is ... interesting. If Alice works for a company that's rolled out GnuPG, the company may have its own LDAP server with up-to-the-minute revocations. And the company may wish you to fetch Alice's certificate from it, in order to get up-to-the-minute details, as opposed to getting it from the keyserver network, which the company doesn't sync with. So if you follow these "best practices", you'll actually never get to update Alice's certificate, even when it's revoked after she leaves the company... Also, don't get me started on "Primary keys should be DSA2 or RSA (RSA preferred)". Right, like there's some inherent problem with DSA2 that makes RSA such a superior choice... From stebe at mailbox.org Wed Dec 7 22:44:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Wed, 07 Dec 2016 21:44:00 +0000 Subject: Hybrid keysigning party, your opinion? In-Reply-To: References: Message-ID: <6e4c97a3-de62-7ced-ba89-ad4fa9afbabc@mailbox.org> Peter Lebbing: > Hi all, > > In just a few weeks, the 33C3 will be held in Hamburg, the 33th Chaos > Communication Congress organized by the Chaos Computer Club. I intend to > organize a keysigning party, just because they are fun. > > I am asking for your thoughts on a variant of the organization of the > keysigning party. ... Doesn't your proposal imply that late attendees could make their way through all the keysigning without fingerprint verification? Or do I miss something? Cheers Stephan Thank you in any case for your detailed information, that encouraged me to install the keysigning package and have a look into it. It seems to be a great tool for organizing a key-signing event! -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x4218732B.asc Type: application/pgp-keys Size: 4091 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x4218732B.asc Type: application/pgp-keys Size: 4090 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x4218732B.asc Type: application/pgp-keys Size: 4089 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From lachlan at twopif.net Thu Dec 8 07:29:40 2016 From: lachlan at twopif.net (Lachlan Gunn) Date: Thu, 8 Dec 2016 16:59:40 +1030 Subject: Hybrid keysigning party, your opinion? In-Reply-To: <6e4c97a3-de62-7ced-ba89-ad4fa9afbabc@mailbox.org> References: <6e4c97a3-de62-7ced-ba89-ad4fa9afbabc@mailbox.org> Message-ID: <48876c1c-c029-0c53-dc60-59cba343d909@twopif.net> Le 2016-12-08 ? 08:14, Stephan Beck a ?crit : > Doesn't your proposal imply that late attendees could > make their way through all the keysigning without fingerprint > verification? Or do I miss something? If I understand correctly, the late attendees still get a copy of the fingerprints after the fact, they just don't have it on their sheet of paper. The fingerprint-less piece of paper just lets them keep a record of who they have verified, and gives them a hash of the list that does have the fingerprints, which they can compare with the people who were ready beforehand (to make sure that the fingerprints have been verified by the identity holders). I've actually thought of doing an electronic keyslip program for mobile phones/tablets that would let you build the list electronically using QR codes or NFC, or maybe doing it via the hash-on-the-projector method for maximum speed. Then you could just download the file to your signing machine and let CAFF do its thing. Would this interest anyone? Does the idea have flaws that I'm blind to? Thanks, Lachlan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Thu Dec 8 12:20:01 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 8 Dec 2016 12:20:01 +0100 Subject: Recording keysigning attendants on phone (was: Hybrid keysigning party, your opinion?) In-Reply-To: <48876c1c-c029-0c53-dc60-59cba343d909@twopif.net> References: <6e4c97a3-de62-7ced-ba89-ad4fa9afbabc@mailbox.org> <48876c1c-c029-0c53-dc60-59cba343d909@twopif.net> Message-ID: <1fa7ddb6-b010-853f-fd72-50dd4fcafc6f@digitalbrains.com> On 08/12/16 07:29, Lachlan Gunn wrote: > If I understand correctly, the late attendees still get a copy of the > fingerprints after the fact, they just don't have it on their sheet of > paper. The fingerprint-less piece of paper just lets them keep a record > of who they have verified, and gives them a hash of the list that does > have the fingerprints, which they can compare with the people who were > ready beforehand (to make sure that the fingerprints have been verified > by the identity holders). Yes, that is spot on what I had in mind. What do you think? > Does the idea have flaws that I'm blind to? I can't say as to your perception, but all these "verify at the party, sign after the party" share the problem that the list could be modified in the time between verifying and signing. Somebody could picpocket your list, add checkmarks with the same type of pen you used, and then sneak it back into your possession. That's a physical act that requires an intimate level of proximity. A phone or tablet is a wirelessly connected device that could be hacked from a distance, and it could be done even before the keysigning. I'd say the latter is in principle more vulnerable; but it depends on your threat model. If, for instance, you've already concluded that you want to have your primary key on the same phone or tablet, it doesn't matter anymore if you then also keep this party list on there. For the sake of my sanity and the fact that I'll need to make the decision about the 33C3 keysigning soon, let's please not mingle these subthreads. If you reply to my "What do you think?", I'd suggest re-instating the previous Subject:-line :-). Thank you! Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Thu Dec 8 12:35:11 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 8 Dec 2016 12:35:11 +0100 Subject: Hybrid keysigning party, your opinion? In-Reply-To: <6e4c97a3-de62-7ced-ba89-ad4fa9afbabc@mailbox.org> References: <6e4c97a3-de62-7ced-ba89-ad4fa9afbabc@mailbox.org> Message-ID: Stephan and Lachlan, thank you for thinking about this! I need to make a decision soon, I really need feedback! On 07/12/16 22:44, Stephan Beck wrote: > Doesn't your proposal imply that late attendees could > make their way through all the keysigning without fingerprint > verification? Or do I miss something? The normal attendees also don't do any fingerprint verification *at the party*. At home, before the party, they checked their own fingerprint, and generated the SHA256 checksum for the file they got. At the party, everybody together checks the SHA256 checksum by simply reading aloud each and every digit. > Thank you in any case for your detailed information, that encouraged me > to install the keysigning package and have a look into it. It seems to > be a great tool for organizing a key-signing event! It is :-) I wouldn't say my information is detailed actually, I could write a *lot* more about proper procedure. But I hoped I didn't have to, instead just focussing on what I wanted to do *differently* from usual. 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 stebe at mailbox.org Thu Dec 8 13:00:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Thu, 08 Dec 2016 12:00:00 +0000 Subject: Hybrid keysigning party, your opinion? In-Reply-To: <48876c1c-c029-0c53-dc60-59cba343d909@twopif.net> References: <6e4c97a3-de62-7ced-ba89-ad4fa9afbabc@mailbox.org> <48876c1c-c029-0c53-dc60-59cba343d909@twopif.net> Message-ID: <98dda355-d5d3-9d1e-371d-6f2d9b2a18e4@mailbox.org> Hi, Lachlan Gunn: > Le 2016-12-08 ? 08:14, Stephan Beck a ?crit : >> Doesn't your proposal imply that late attendees could >> make their way through all the keysigning without fingerprint >> verification? Or do I miss something? > > If I understand correctly, the late attendees still get a copy of the > fingerprints after the fact, they just don't have it on their sheet of > paper. The fingerprint-less piece of paper just lets them keep a record > of who they have verified, and gives them a hash of the list that does > have the fingerprints, which they can compare with the people who were > ready beforehand (to make sure that the fingerprints have been verified > by the identity holders). yes, they still get the original file from the organizer afterwards, that's true. caff automatically checks the fingerprint on import (before mailing out each of the signed keys/UID), so there's no way of tampering. If they hadn't those fingerprints (or the original file/list), caff would not let them go on. Quote from README.many-keys $ caff > I've actually thought of doing an electronic keyslip program for mobile > phones/tablets that would let you build the list electronically using QR > codes or NFC, or maybe doing it via the hash-on-the-projector method for > maximum speed. Then you could just download the file to your signing > machine and let CAFF do its thing. > > Would this interest anyone? Does the idea have flaws that I'm blind to? Yes, to your first question. How you would do that via the hash-on-the-projector method, is not clear to me, though. Would that be for generating the (initial) list of the organizers as in Sassaman Efficient (as an additional service for people using cell phones or tablets)? Or wouldn't there be any paper copy at the event? Sorry, for questions that might seem obvious to you. Thanks Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x4218732B.asc Type: application/pgp-keys Size: 4089 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From stebe at mailbox.org Thu Dec 8 14:14:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Thu, 08 Dec 2016 13:14:00 +0000 Subject: Hybrid keysigning party, your opinion? In-Reply-To: References: <6e4c97a3-de62-7ced-ba89-ad4fa9afbabc@mailbox.org> Message-ID: <630d4332-afb0-5f8b-acde-78961dd6abab@mailbox.org> Peter Lebbing: > Stephan and Lachlan, thank you for thinking about this! I need to make a > decision soon, I really need feedback! > > On 07/12/16 22:44, Stephan Beck wrote: >> Doesn't your proposal imply that late attendees could >> make their way through all the keysigning without fingerprint >> verification? Or do I miss something? > > The normal attendees also don't do any fingerprint verification *at the party*. > At home, before the party, they checked their own fingerprint, and generated the > SHA256 checksum for the file they got. At the party, everybody together checks > the SHA256 checksum by simply reading aloud each and every digit. Yes, Peter, but they are the "ordinary" participants who went through the preparation, and then state (at the event) that the checksum is {checksum} and that the corresponding fingerprint on the list is theirs and that it is correct ("check out"). The others (late attendees) just hand out their keyslip (keyslip is just an "unverified statement"), receive the keyslip from the other, together with the fingerprint-less list they have, and postpone the verification to the moment when they are at home and have been sent the list from the organizer. By that time, the other ("Sassaman's Efficient ordinary participants") can already be sure of the integrity/authenticity of the messages of their communication partners and that partner's true identity. Just some meditations: So, the late attendees can see and hear that the ordinary participants confirm the checksum and that their fingerprints check out? One that was on the list and didn't show up would not get the required marks on () fpr () id ? Would that person be (as uid-serial number, 001, 002, 003...) on the attendee's fingerprint-less list? But that person definitely would not end up as a person being included in the final list? That might produce inconsistencies in numbering. So the final list just would not include some serial numbers that once were on the "initial" list or the fingerprint-less list? Then, by checking serial numbers, as you say, it's ok :-) Cheers Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x4218732B.asc Type: application/pgp-keys Size: 4089 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From lachlan at twopif.net Thu Dec 8 14:51:06 2016 From: lachlan at twopif.net (Lachlan Gunn) Date: Fri, 9 Dec 2016 00:21:06 +1030 Subject: Hybrid keysigning party, your opinion? In-Reply-To: References: <6e4c97a3-de62-7ced-ba89-ad4fa9afbabc@mailbox.org> Message-ID: Le 2016-12-08 ? 22:05, Peter Lebbing a ?crit : > Stephan and Lachlan, thank you for thinking about this! I need to make a > decision soon, I really need feedback! Not a problem, efficient keysigning is something I've been pondering for a while, so I'm really glad to see people working in the area. > I wouldn't say my information is detailed actually, I could write a *lot* more > about proper procedure. But I hoped I didn't have to, instead just focussing on > what I wanted to do *differently* from usual. Personally I am of the mind that anything longer than that email is wishful thinking, you have to get people to actually follow it. The ones who need to do it are also only the ones who weren't organised in advance, so I think keep the extra work to a minimum if you want to maximise the useful signatures from them. To this end, another suggestion is to make the forms that they fill in identical, whether or not they are late. You could do this by putting the fingerprints at the end of the primary document and just printing out the first bit for latecomers. This might save some "I don't know how your form works, I have the prearranged one" on the day. It's late here now, but I'll try to have a look over the weekend to see if there are any missed opportunities for automation. Thanks, Lachlan From peter at digitalbrains.com Thu Dec 8 14:55:12 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 8 Dec 2016 14:55:12 +0100 Subject: Hybrid keysigning party, your opinion? In-Reply-To: <630d4332-afb0-5f8b-acde-78961dd6abab@mailbox.org> References: <6e4c97a3-de62-7ced-ba89-ad4fa9afbabc@mailbox.org> <630d4332-afb0-5f8b-acde-78961dd6abab@mailbox.org> Message-ID: <15922fc6-b6b9-34f1-7dd0-61427c7a2722@digitalbrains.com> On 08/12/16 14:14, Stephan Beck wrote: > Just some meditations: > > So, the late attendees can see and hear that the ordinary participants > confirm the checksum and that their fingerprints check out? Yes, the late attendees definitely need to be there at the beginning of the party, verifying that the SHA256 checksum printed at the top of their scrubbed list is the one being read aloud and hearing everybody confirm their fingerprint is correct. > One that was on the list and didn't show up would not get the required marks > on () fpr () id ? Correct, I actually cross out the full entry with my pen, but it would suffice not to put a check mark on Fingerprint. A check mark on ID is totally out of the question, that check mark indicates you have verified their identity! > Would that person be (as uid-serial number, 001, 002, 003...) on the > attendee's fingerprint-less list? But that person definitely would not end up > as a person being included in the final list? The list is *immutable*. It is finished before the event even starts, and has a known SHA256 checksum. People are not added to or removed from the list. Late participants get the original list as it was sent to the early registrants, with the precise, known SHA256 list. After someone has verified they at least received the correct list electronically, they're free to change whatever they like on the list for themselves, *but not to send on to others*. It is vitally important that wat is sent to people is the original list with the correct SHA256 checksum. And if somebody is unable to get a list with the correct SHA256 checksum, they have wasted their time with verifying the people on the list. But this would be an odd situation: nobody is able to send them an unmodified file? I'd worry about my computer and my internet connection then, not the time lost during the keysigning. > Then, by checking serial numbers, as you say, it's ok :-) Checking serial numbers <-> UID mappings is /purely/ to catch out dishonesty on the part of the person who printed the scrubbed lists for the late attendees. It is not to account for changes in who was present and stuff like that. Of course I'll provide the lists, so I for myself know they will be okay. However, the other people would just have my word for it, and that is wholly insufficient. 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 lachlan at twopif.net Thu Dec 8 15:08:49 2016 From: lachlan at twopif.net (Lachlan Gunn) Date: Fri, 9 Dec 2016 00:38:49 +1030 Subject: Hybrid keysigning party, your opinion? In-Reply-To: <15922fc6-b6b9-34f1-7dd0-61427c7a2722@digitalbrains.com> References: <6e4c97a3-de62-7ced-ba89-ad4fa9afbabc@mailbox.org> <630d4332-afb0-5f8b-acde-78961dd6abab@mailbox.org> <15922fc6-b6b9-34f1-7dd0-61427c7a2722@digitalbrains.com> Message-ID: <8a444fac-e669-d3da-c084-f63614b1697c@twopif.net> Le 2016-12-09 ? 00:25, Peter Lebbing a ?crit : > Yes, the late attendees definitely need to be there at the beginning of the > party, verifying that the SHA256 checksum printed at the top of their scrubbed > list is the one being read aloud and hearing everybody confirm their fingerprint > is correct. Can't they get this from the other participants in the line? Checking with a few people at random gives reasonable assurance that this is what was agreed on at the beginning, or they can check them all if they want to be certain. Thanks, Lachlan From peter at digitalbrains.com Thu Dec 8 18:12:50 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 8 Dec 2016 18:12:50 +0100 Subject: An attempt at backporting 2.1.16 from Debian sid to Debian jessie Message-ID: <0d7e39f9-d26e-6fee-1898-55000aeb807e@digitalbrains.com> Hello dkg and list! Let me start out by thanking Daniel Kahn Gillmor for all his work on GnuPG and its Debian packages. And also thanks to all the other devs! I'd like to use the latest GnuPG 2.1 on my Debian jessie machines. When the Debian package went from version 2.1.11-7 to 2.1.11-7+exp1, it started providing /usr/bin/gpg and the other stuff that was up till then provided by GnuPG 1.4. Starting with stretch, if all works out, GnuPG 1.4 will no longer be providing the major role it had in Debian so far. I forked the Debian git repo for GnuPG 2.1 [1], and had a go at what was primarily the reversal of the changes introduced by 2.1.11-7+exp1. You can find the result at GitLab at [2]. I'm running this version myself now, and it all works so far (famous last words...). I'm giving you all the loaded gun to shoot yourself in the foot. I do not recommend my fork for general use, but rather as a service to people who really want 2.1 and are prepared to deal with issues arising from having both 1.4 and 2.1 on the same system.[3] I'm very interested in feedback! I'd like it if people check my changes, do they seem okay to you? Did you run into issues? I'd also like to hear from people succesfully using it, but don't feel obliged to tell me. If you feel I shouldn't be doing this, we could discuss it further. Maybe we can work out a deterring formulation for the README to prevent people installing it :-). Or you convince me of my folly. This version will replace jessie's 2.0.26 with 2.1.16, but it will install next to GnuPG 1.4. However, mixing 1.4 and 2.1 is not for the faint of heart. There are good reasons that dkg is choosing not to support 1.4 and 2.1 on the same machine starting with Debian stretch: while on the surface they are compatible, they quickly go out of sync regarding private keys and it can get interesting with public keys as well. "Interesting" as in "May you live in interesting times". not as in "Hey, that's interesting!"... that is, not a good thing at all. *Use at your own risk! This is provided as-is without any warranties.* I tried my best, but sometimes, your best isn't good enough... ;) Oh, and I'm already behind. The latest and greatest is now 2.1.16-3, and I'm still providing 2.1.16-2~dbbp8+1 [4]. Cheers, Peter. [1] https://anonscm.debian.org/git/pkg-gnupg/gnupg2.git [2] https://gitlab.com/DigitalBrains1/alt-debian-gnupg2 [3] Hey, that's pretty good, I'll put that in the README. [4] I means: Digital Brains BackPort Debian 8.x version 1. Same numbering scheme as backports.org, different identifier. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From stebe at mailbox.org Thu Dec 8 18:13:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Thu, 08 Dec 2016 17:13:00 +0000 Subject: Hybrid keysigning party, your opinion? In-Reply-To: <15922fc6-b6b9-34f1-7dd0-61427c7a2722@digitalbrains.com> References: <6e4c97a3-de62-7ced-ba89-ad4fa9afbabc@mailbox.org> <630d4332-afb0-5f8b-acde-78961dd6abab@mailbox.org> <15922fc6-b6b9-34f1-7dd0-61427c7a2722@digitalbrains.com> Message-ID: <7bd3be31-fe92-4a12-a79c-df3383e56c15@mailbox.org> Peter Lebbing: > On 08/12/16 14:14, Stephan Beck wrote: >> Just some meditations: >> >> So, the late attendees can see and hear that the ordinary participants >> confirm the checksum and that their fingerprints check out? > > Yes, the late attendees definitely need to be there at the beginning of the > party, verifying that the SHA256 checksum printed at the top of their scrubbed > list is the one being read aloud and hearing everybody confirm their fingerprint > is correct. [...] Thanks, Peter. No more open questions! As with everything, I think I'd have to set up such an event and go through its practical application (or participate in one) to become more expert. Let me see if there are any in my region. Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x4218732B.asc Type: application/pgp-keys Size: 4089 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From tlikonen at iki.fi Thu Dec 8 18:40:04 2016 From: tlikonen at iki.fi (Teemu Likonen) Date: Thu, 08 Dec 2016 19:40:04 +0200 Subject: An attempt at backporting 2.1.16 from Debian sid to Debian jessie In-Reply-To: <0d7e39f9-d26e-6fee-1898-55000aeb807e@digitalbrains.com> (Peter Lebbing's message of "Thu, 8 Dec 2016 18:12:50 +0100") References: <0d7e39f9-d26e-6fee-1898-55000aeb807e@digitalbrains.com> Message-ID: <87fulyl3pn.fsf@iki.fi> Peter Lebbing [2016-12-08 18:12:50+01] wrote: > I forked the Debian git repo for GnuPG 2.1 [1], and had a go at what > was primarily the reversal of the changes introduced by 2.1.11-7+exp1. > You can find the result at GitLab at [2]. Thanks. I'm not brave enough to try it yet. I wonder what is the status of official backport. There's a Debian bug report about that: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822974 Quote 2016-10-06: It'll happen soon, i promise :) --dkg -- /// Teemu Likonen - .-.. // // PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 /// -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From stebe at mailbox.org Thu Dec 8 21:42:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Thu, 08 Dec 2016 20:42:00 +0000 Subject: An attempt at backporting 2.1.16 from Debian sid to Debian jessie In-Reply-To: <87fulyl3pn.fsf@iki.fi> References: <0d7e39f9-d26e-6fee-1898-55000aeb807e@digitalbrains.com> <87fulyl3pn.fsf@iki.fi> Message-ID: <7dfd50b5-6f6e-2ce0-7cf9-78345204ccde@mailbox.org> Teemu Likonen: > Peter Lebbing [2016-12-08 18:12:50+01] wrote: > >> I forked the Debian git repo for GnuPG 2.1 [1], and had a go at what >> was primarily the reversal of the changes introduced by 2.1.11-7+exp1. >> You can find the result at GitLab at [2]. > > Thanks. I'm not brave enough to try it yet. I wonder what is the status > of official backport. There's a Debian bug report about that: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822974 A few days ago, I successfully updated to 2.1.16 on my Debian Stretch installation, watching how gpg (1.4.20something) was being replaced with 2.1.16, so I don't see the real need for a forced coexistence of the two (or three) versions on Jessie. Maybe I'll cast a glance at it, though. Cheers Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From m.mansfeld at mansfeld-elektronik.de Fri Dec 9 01:52:53 2016 From: m.mansfeld at mansfeld-elektronik.de (Matthias Mansfeld) Date: Fri, 09 Dec 2016 01:52:53 +0100 Subject: Something strange with Stephan Becks Signatures? Message-ID: <584A0065.26179.994BF0@m.mansfeld.mansfeld-elektronik.de> Hello, maybe someone has similar effects or can give me a hint where to look. If not, it's OK... Windows 7 pro(64), GPGRelay 9.962 (a POP3/SMTP "proxy" or better local relay for GnuPG), GnuPG 1.4.18, Pegasus Mail 4.72de Based on something strange on my computer (blocked memory etc. up to explorer.exe freeze after some hours running) finally my GnuPG freezes >> GPGRelay freezes waiting for GnuPG >> my Mail client freezes waiting for GPGRelay, and the common is nearly always, it freezes mostly exactly during loading a signed mail from Stephan Beck. Just killing all tasks doesn't help, it needs shutdown/reeboot from the whole Windows7. Then all these mails including Stephan's mail load fine, Signature veryfies fine etc... Any ideas? Is something "special" with Stephan's signature or why happen these crashes mostly exactly with Stephan's mails? Thanks! Regards Matthias -- OpenPGP: http://www.mansfeld-elektronik.de/gnupgkey/mansfeld.asc Fingerprint: 6563 057D E6B8 9105 1CE4 18D0 4056 1F54 8B59 40EF From stebe at mailbox.org Fri Dec 9 15:01:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Fri, 09 Dec 2016 14:01:00 +0000 Subject: Something strange with Stephan Becks Signatures? In-Reply-To: <584A0065.26179.994BF0@m.mansfeld.mansfeld-elektronik.de> References: <584A0065.26179.994BF0@m.mansfeld.mansfeld-elektronik.de> Message-ID: <5ab0b842-a6c5-4309-0019-a23e9112cf6a@mailbox.org> Hi Matthias, Matthias Mansfeld: > Hello, maybe someone has similar effects or can give me a hint where > to look. If not, it's OK... > > Windows 7 pro(64), GPGRelay 9.962 (a POP3/SMTP "proxy" or better > local relay for GnuPG), GnuPG 1.4.18, Pegasus Mail 4.72de > > Based on something strange on my computer (blocked memory etc. up to > explorer.exe freeze after some hours running) finally my GnuPG > freezes >> GPGRelay freezes waiting for GnuPG >> my Mail client > freezes waiting for GPGRelay, and the common is nearly always, it > freezes mostly exactly during loading a signed mail from Stephan > Beck. Well, I can't say that I feel honored by so many references to my name, but have you checked that (I suspect compatibility of PGP plugin and your PM version as a probable reason) 1) the PGP-plugin you use is the latest as on (1) 2) this latest version of the PGP plugin (for use in 4.72) is already made fit for Windows7 [BeginQuote]IMPORTANT NOTE ON RELEASE CHANGES: Every major release change of the underlying systems (Windows, Pegasus Mail or PGP) may cause problems with the currently available version of this extension. As long as new versions aren't explicitly mentioned here there is no sufficient experience with using it with new versions of the above listed software (with regard to that I request you to any problems that are not covered in this documentation - especially with new versions of Windows).[EndOfQuote] 3) is configured properly concerning PGP/MIME support: see section Using the Program--> PGP/MIME encryption 4) gnupg 1.4.18 for Windows' debug output 5) you are using a Windows 32-bit-application in a 64 bit Windows7 environment; that should work in general, but may give some issues. I haven't investigated further here. 6) in general, for Windows 7 "debugging light": see "Event Logging" (DE_DE=Ereignisanzeige) and look for entries in the various log files, filtering as needed 7) for Windows Debugging heavy, download the Win7 Debugging Tools (4) As to logging I only found that PegasusMail(3) has a WMP log file for debugging purposes but it is not editable, as to (2).I looked for something similar to Enigmail's console (with error logging). Cheers Stephan (1) http://www.pmpgp.de/pmpgp/manualen.htm (2) https://www.file-extensions.org/wpm-file-extension-pegasus-mail-log-or-debug-file (3) http://www.pmail.com/versions.htm (4) https://developer.microsoft.com/en-us/windows/hardware/windows-driver-kit --> Debugging tools for W7-W10 (from the sdk) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From ondrejstrestik at gmail.com Fri Dec 9 16:03:42 2016 From: ondrejstrestik at gmail.com (=?utf-8?B?T25kxZllaiBTdMWZZcWhdMOtaw==?=) Date: Fri, 9 Dec 2016 16:03:42 +0100 Subject: How restore backuped /.gnupg/private-keys-v1.d Message-ID: Hello, i have reall big problem because i accydently deleted /.gnupg, but still i have backuped /.gnupg/private-keys-v1.d so i have 4 ?hashfile" name files with suffix .key I was really scared, because i thought i lost my private keys but i read here https://www.gnupg.org/faq/whats-new-in-2.1.html The file secring.gpg is not anymore used to store the secret keys. Merging of secret keys is now supported So i dont have any file from /.gnupg like secring.gpg, etc. (i saw private-keys-v1.d and i thoug backup this folder is enought - yes i am moron) - i deleted folder because i had problems with gpg configuration - i thought i will copy private-keys-v1.d back to the ./gnupg and everything will be ok (like ssh) Now i am i situation where i can not import ?raw? keys and everytime when i try to import private key i will get message like: No valid OpenGPG data found in file. Please can you help me how can i restore my pivate keys please? I google it around 12 hours and still nothing. Thank you very much for yours help, Ondrej Strestik From wk at gnupg.org Fri Dec 9 21:06:40 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 09 Dec 2016 21:06:40 +0100 Subject: How restore backuped /.gnupg/private-keys-v1.d In-Reply-To: (=?utf-8?B?Ik9uZMWZZWoJU3TFmWXFoXTDrWsiJ3M=?= message of "Fri, 9 Dec 2016 16:03:42 +0100") References: Message-ID: <87k2b8hnov.fsf@wheatstone.g10code.de> On Fri, 9 Dec 2016 16:03, ondrejstrestik at gmail.com said: > i have reall big problem because i accydently deleted /.gnupg, but still i have backuped /.gnupg/private-keys-v1.d so i have 4 ?hashfile" name files with suffix .key That good. Run gpg once to create a new .gnupg directory (or create it manually). Then copy the four files to the new private-keys-v1.d directory and you have restored the secret key material. Now you need to get a copy of your two (I guess) public keys. They should be on the keyservers or you have send them to other places, get a copy and gpg --import them. Better restart the gpg-agent (gpgconf --kill gpg-agent). That's it. If you can't find the public keys, there is no real damage because the nobody sent you encrypted data or nobody else cared to verify your data. > - i thought i will copy private-keys-v1.d back to the ./gnupg and everything will be ok (like ssh) Partly. All the secrets are restored as I explained above. > Now i am i situation where i can not import ?raw? keys and everytime > when i try to import private key i will get message like: No valid What do you mean by raw key? You are looking for files created with gpg --export or gpg --export --armor or with any other OpenPGP tool. You can implement such files with gpg --import Take care that they are not encrypted (some people do this) and that they are not gzipped etc. Using the extra option -v is always a good idea in such cases. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From tlikonen at iki.fi Sat Dec 10 07:49:30 2016 From: tlikonen at iki.fi (Teemu Likonen) Date: Sat, 10 Dec 2016 08:49:30 +0200 Subject: What is pubring.kbx? Message-ID: <87twacwa6d.fsf@iki.fi> I just noticed that a couple of days ago a new file ~/.gnupg/pubring.kbx had appeared (or last modified). Who made it and what is it for? I'm using GnuPG 2.0.26 and its manual doesn't seem to tell anything about this file. Obviously I have ~/.gnupg/pubring.gpg too. $ gpg2 --no-default-keyring --keyring ~/.gnupg/pubring.kbx --list-keys gpg: [don't know]: invalid packet (ctb=00) gpg: keydb_search_first failed: Invalid packet -- /// Teemu Likonen - .-.. // // PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 /// -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From tlikonen at iki.fi Sat Dec 10 08:39:25 2016 From: tlikonen at iki.fi (Teemu Likonen) Date: Sat, 10 Dec 2016 09:39:25 +0200 Subject: What is pubring.kbx? In-Reply-To: <444c56a9-e06b-4864-c518-ea248da23c6d@gmail.com> (Lou Wynn's message of "Fri, 9 Dec 2016 23:11:18 -0800") References: <87twacwa6d.fsf@iki.fi> <444c56a9-e06b-4864-c518-ea248da23c6d@gmail.com> Message-ID: <87pol0w7v6.fsf@iki.fi> Lou Wynn [2016-12-09 23:11:18-08] wrote: > ~/.gnupg/pubring.kbx > The public keyring using a different format. This file is sharred with > gpgsm. You should backup this file. Indeed. I recently verified someones S/MIME message. Man page of gpgsm(1) 2.0.26 says: pubring.kbx This a database file storing the certificates as well as meta information. For debugging purposes the tool kbxutil may be used to show the internal structure of this file. You should backup this file. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 454 bytes Desc: not available URL: From lewisurn at gmail.com Sat Dec 10 08:11:18 2016 From: lewisurn at gmail.com (Lou Wynn) Date: Fri, 9 Dec 2016 23:11:18 -0800 Subject: What is pubring.kbx? In-Reply-To: <87twacwa6d.fsf@iki.fi> References: <87twacwa6d.fsf@iki.fi> Message-ID: <444c56a9-e06b-4864-c518-ea248da23c6d@gmail.com> I just happened to read this page today, and it's still open in my browser. https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuration.html#GPG-Configuration ~/.gnupg/pubring.kbx The public keyring using a different format. This file is sharred with gpgsm. You should backup this file. Cheers Lou On 12/09/2016 10:49 PM, Teemu Likonen wrote: > I just noticed that a couple of days ago a new file ~/.gnupg/pubring.kbx > had appeared (or last modified). Who made it and what is it for? I'm > using GnuPG 2.0.26 and its manual doesn't seem to tell anything about > this file. Obviously I have ~/.gnupg/pubring.gpg too. > > $ gpg2 --no-default-keyring --keyring ~/.gnupg/pubring.kbx --list-keys > gpg: [don't know]: invalid packet (ctb=00) > gpg: keydb_search_first failed: Invalid packet > > > > _______________________________________________ > 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: 0xE6CE3473.asc Type: application/pgp-keys Size: 2299 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 299 bytes Desc: OpenPGP digital signature URL: From ondrejstrestik at gmail.com Sat Dec 10 11:33:54 2016 From: ondrejstrestik at gmail.com (=?UTF-8?B?T25kxZllaiBTdMWZZcWhdMOtaw==?=) Date: Sat, 10 Dec 2016 10:33:54 +0000 Subject: How restore backuped /.gnupg/private-keys-v1.d In-Reply-To: <87k2b8hnov.fsf@wheatstone.g10code.de> References: <87k2b8hnov.fsf@wheatstone.g10code.de> Message-ID: Thank you very much, It worked. Word is beautiful again :-D Ondrej p? 9. 12. 2016 v 21:12 odes?latel Werner Koch napsal: > On Fri, 9 Dec 2016 16:03, ondrejstrestik at gmail.com said: > > > i have reall big problem because i accydently deleted /.gnupg, but still > i have backuped /.gnupg/private-keys-v1.d so i have 4 ?hashfile" name files > with suffix .key > > That good. Run gpg once to create a new .gnupg directory (or create it > manually). Then copy the four files to the new private-keys-v1.d > directory and you have restored the secret key material. Now you need > to get a copy of your two (I guess) public keys. They should be on the > keyservers or you have send them to other places, get a copy and gpg > --import them. Better restart the gpg-agent (gpgconf --kill gpg-agent). > That's it. > > If you can't find the public keys, there is no real damage because the > nobody sent you encrypted data or nobody else cared to verify your data. > > > - i thought i will copy private-keys-v1.d back to the ./gnupg and > everything will be ok (like ssh) > > Partly. All the secrets are restored as I explained above. > > > Now i am i situation where i can not import ?raw? keys and everytime > > when i try to import private key i will get message like: No valid > > What do you mean by raw key? You are looking for files created with > > gpg --export > > or > > gpg --export --armor > > or with any other OpenPGP tool. You can implement such files with > > gpg --import > > Take care that they are not encrypted (some people do this) and that > they are not gzipped etc. Using the extra option -v is always a good > idea in such cases. > > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ondrejstrestik at gmail.com Sat Dec 10 11:30:53 2016 From: ondrejstrestik at gmail.com (=?UTF-8?B?T25kxZllaiBTdMWZZcWhdMOtaw==?=) Date: Sat, 10 Dec 2016 10:30:53 +0000 Subject: Can't import new public keys (can't write tu pubring.kbx) Message-ID: Hi, Today i appeard i can not import new public keys every time when i try gpg --import i will gpg: error writing keyring '/home/user/.gnupg/pubring.kbx': Unexpected error gpg: key 4D3DE5CC4DAC4561: public key "[User ID not found]" imported gpg: error reading 'Dokumenty/key.asc': Unexpected error gpg: import from 'Dokumenty/key.asc' failed: Unexpected error gpg: Total number processed: 0 gpg: imported: 1 When i try re-import some old ones a everything is OK. Do you know how can i fix it? Thanks Ondrej Strestik -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Sat Dec 10 18:31:05 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 10 Dec 2016 18:31:05 +0100 Subject: Can't import new public keys (can't write tu pubring.kbx) In-Reply-To: References: Message-ID: <87lgvnpu7a.fsf@alice.fifthhorseman.net> On Sat 2016-12-10 11:30:53 +0100, Ond?ej St?e?t?k wrote: > Today i appeard i can not import new public keys every time when i try gpg > --import i will > > gpg: error writing keyring '/home/user/.gnupg/pubring.kbx': Unexpected > error > gpg: key 4D3DE5CC4DAC4561: public key "[User ID not found]" imported > gpg: error reading 'Dokumenty/key.asc': Unexpected error > gpg: import from 'Dokumenty/key.asc' failed: Unexpected error > gpg: Total number processed: 0 > gpg: imported: 1 > > > When i try re-import some old ones a everything is OK. this sounds like a permissions problem to me. what are the permissions of Dokumenty/key.asc? what are the permissions of /home/user/.gnupg/pubring.kbx and /home/user/.gnupg ? what user account are you running "gpg --import" from? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From ondrejstrestik at gmail.com Sat Dec 10 19:55:00 2016 From: ondrejstrestik at gmail.com (=?UTF-8?B?T25kxZllaiBTdMWZZcWhdMOtaw==?=) Date: Sat, 10 Dec 2016 18:55:00 +0000 Subject: Can't import new public keys (can't write tu pubring.kbx) In-Reply-To: <87lgvnpu7a.fsf@alice.fifthhorseman.net> References: <87lgvnpu7a.fsf@alice.fifthhorseman.net> Message-ID: I thought it is permission problem, but as i wrote i am able import other pub keys. Dokumenty/key.asc have 766 .gnupg have 700 and files inside the folder have 600 and owner of all files is my account and i am running gpg import from my regular account (not like a root). Dne so 10. 12. 2016 18:37 u?ivatel Daniel Kahn Gillmor < dkg at fifthhorseman.net> napsal: > On Sat 2016-12-10 11:30:53 +0100, Ond?ej St?e?t?k wrote: > > > Today i appeard i can not import new public keys every time when i try > gpg > > --import i will > > > > gpg: error writing keyring '/home/user/.gnupg/pubring.kbx': Unexpected > > error > > gpg: key 4D3DE5CC4DAC4561: public key "[User ID not found]" imported > > gpg: error reading 'Dokumenty/key.asc': Unexpected error > > gpg: import from 'Dokumenty/key.asc' failed: Unexpected error > > gpg: Total number processed: 0 > > gpg: imported: 1 > > > > > > When i try re-import some old ones a everything is OK. > > this sounds like a permissions problem to me. what are the permissions > of Dokumenty/key.asc? what are the permissions of > /home/user/.gnupg/pubring.kbx and /home/user/.gnupg ? what user account > are you running "gpg --import" from? > > --dkg > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Sat Dec 10 20:19:56 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 10 Dec 2016 20:19:56 +0100 Subject: Can't import new public keys (can't write tu pubring.kbx) In-Reply-To: References: Message-ID: <877f77pp5v.fsf@alice.fifthhorseman.net> On Sat 2016-12-10 11:30:53 +0100, Ond?ej St?e?t?k wrote: > Today i appeard i can not import new public keys every time when i try gpg > --import i will > > gpg: error writing keyring '/home/user/.gnupg/pubring.kbx': Unexpected > error > gpg: key 4D3DE5CC4DAC4561: public key "[User ID not found]" imported > gpg: error reading 'Dokumenty/key.asc': Unexpected error > gpg: import from 'Dokumenty/key.asc' failed: Unexpected error > gpg: Total number processed: 0 > gpg: imported: 1 This key has a zero-length User ID. that is, the User ID is the empty string (""). You can see this with: 0 dkg at alice:/tmp/cdtemp.Ok5Ijz$ wget -q -O- 'http://pool.sks-keyservers.net:11371/pks/lookup?op=get&search=0x4D3DE5CC4DAC4561' | pgpdump Old: Public Key Packet(tag 6)(269 bytes) Ver 4 - new Public key creation time - Sat Jan 30 18:42:22 CET 2016 Pub alg - RSA Encrypt or Sign(pub 1) RSA n(2048 bits) - ... RSA e(17 bits) - ... Old: User ID Packet(tag 13)(0 bytes) User ID - Old: Signature Packet(tag 2)(284 bytes) Ver 4 - new Sig type - Generic certification of a User ID and Public Key packet(0x10). Pub alg - RSA Encrypt or Sign(pub 1) Hash alg - SHA1(hash 2) Hashed Sub: signature creation time(sub 2)(4 bytes) Time - Sat Jan 30 18:42:22 CET 2016 Sub: issuer key ID(sub 16)(8 bytes) Key ID - 0x4D3DE5CC4DAC4561 Hash left 2 bytes - bf d8 RSA m^d mod n(2046 bits) - ... -> PKCS-1 Old: Signature Packet(tag 2)(284 bytes) Ver 4 - new Sig type - Generic certification of a User ID and Public Key packet(0x10). Pub alg - RSA Encrypt or Sign(pub 1) Hash alg - SHA256(hash 8) Hashed Sub: signature creation time(sub 2)(4 bytes) Time - Fri Aug 19 00:29:49 CEST 2016 Sub: issuer key ID(sub 16)(8 bytes) Key ID - 0xBE3CD7444608B62A Hash left 2 bytes - b9 c0 RSA m^d mod n(2043 bits) - ... -> PKCS-1 0 dkg at alice:/tmp/cdtemp.Ok5Ijz$ i suppose someone could argue that a zero-length user ID is valid, but i don't see any use for it, and i can imagine it causing problems in a lot of situations. So i think on balance i'm that gpg rejecting it by default is doing the right thing. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From ondrejstrestik at gmail.com Sat Dec 10 20:23:12 2016 From: ondrejstrestik at gmail.com (=?UTF-8?B?T25kxZllaiBTdMWZZcWhdMOtaw==?=) Date: Sat, 10 Dec 2016 19:23:12 +0000 Subject: Can't import new public keys (can't write tu pubring.kbx) In-Reply-To: <877f77pp5v.fsf@alice.fifthhorseman.net> References: <877f77pp5v.fsf@alice.fifthhorseman.net> Message-ID: Ok i understand, but is there some switch or parameter how can i force import? Because on macos with gpgtools i am able to import this key. Dne so 10. 12. 2016 20:20 u?ivatel Daniel Kahn Gillmor < dkg at fifthhorseman.net> napsal: > On Sat 2016-12-10 11:30:53 +0100, Ond?ej St?e?t?k wrote: > > > Today i appeard i can not import new public keys every time when i try > gpg > > --import i will > > > > gpg: error writing keyring '/home/user/.gnupg/pubring.kbx': Unexpected > > error > > gpg: key 4D3DE5CC4DAC4561: public key "[User ID not found]" imported > > gpg: error reading 'Dokumenty/key.asc': Unexpected error > > gpg: import from 'Dokumenty/key.asc' failed: Unexpected error > > gpg: Total number processed: 0 > > gpg: imported: 1 > > This key has a zero-length User ID. that is, the User ID is the empty > string (""). > > You can see this with: > > 0 dkg at alice:/tmp/cdtemp.Ok5Ijz$ wget -q -O- ' > http://pool.sks-keyservers.net:11371/pks/lookup?op=get&search=0x4D3DE5CC4DAC4561' > | pgpdump > Old: Public Key Packet(tag 6)(269 bytes) > Ver 4 - new > Public key creation time - Sat Jan 30 18:42:22 CET 2016 > Pub alg - RSA Encrypt or Sign(pub 1) > RSA n(2048 bits) - ... > RSA e(17 bits) - ... > Old: User ID Packet(tag 13)(0 bytes) > User ID - > Old: Signature Packet(tag 2)(284 bytes) > Ver 4 - new > Sig type - Generic certification of a User ID and Public Key > packet(0x10). > Pub alg - RSA Encrypt or Sign(pub 1) > Hash alg - SHA1(hash 2) > Hashed Sub: signature creation time(sub 2)(4 bytes) > Time - Sat Jan 30 18:42:22 CET 2016 > Sub: issuer key ID(sub 16)(8 bytes) > Key ID - 0x4D3DE5CC4DAC4561 > Hash left 2 bytes - bf d8 > RSA m^d mod n(2046 bits) - ... > -> PKCS-1 > Old: Signature Packet(tag 2)(284 bytes) > Ver 4 - new > Sig type - Generic certification of a User ID and Public Key > packet(0x10). > Pub alg - RSA Encrypt or Sign(pub 1) > Hash alg - SHA256(hash 8) > Hashed Sub: signature creation time(sub 2)(4 bytes) > Time - Fri Aug 19 00:29:49 CEST 2016 > Sub: issuer key ID(sub 16)(8 bytes) > Key ID - 0xBE3CD7444608B62A > Hash left 2 bytes - b9 c0 > RSA m^d mod n(2043 bits) - ... > -> PKCS-1 > 0 dkg at alice:/tmp/cdtemp.Ok5Ijz$ > > > i suppose someone could argue that a zero-length user ID is valid, but i > don't see any use for it, and i can imagine it causing problems in a lot > of situations. So i think on balance i'm that gpg rejecting it by > default is doing the right thing. > > --dkg > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Sat Dec 10 20:22:55 2016 From: wk at gnupg.org (Werner Koch) Date: Sat, 10 Dec 2016 20:22:55 +0100 Subject: Can't import new public keys (can't write tu pubring.kbx) In-Reply-To: (=?utf-8?B?Ik9uZMWZZWogU3TFmWXFoXTDrWsiJ3M=?= message of "Sat, 10 Dec 2016 10:30:53 +0000") References: Message-ID: <87bmwjfv1s.fsf@wheatstone.g10code.de> On Sat, 10 Dec 2016 11:30, ondrejstrestik at gmail.com said: > gpg: import from 'Dokumenty/key.asc' failed: Unexpected error The reason for 'Unexpected error' is likely a broken key or a key which does not conform to the OpenPGP specs. For example it may have packets which are not allowed in public key file (compressed, encrypted etc,) Any clues form just running gpg Dokumenty/key.asc' or better gpg --list-packets Dokumenty/key.asc' Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From caro at nymph.paranoici.org Sun Dec 11 02:48:30 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Sun, 11 Dec 2016 01:48:30 +0000 (UTC) Subject: Implications of a common private keys directory in 2.1 References: <3b776db4-4161-35cc-31ac-b343b12edf7a@digitalbrains.com> <20161124230301.3055810320F5@remailer.paranoici.org> <17f5cadc-c7fb-c43a-a141-5d269ab45eaa@digitalbrains.com> <20161204205923.ADB011031FF9@remailer.paranoici.org> <78b30a87-43a1-bb2b-d965-c65a8a1c5b27@digitalbrains.com> Message-ID: <20161211014830.B5635103200C@remailer.paranoici.org> Peter Lebbing wrote: >On 04/12/16 21:59, Carola Grunwald wrote: >> Three months ago I thought it was time to adapt it to GnuPG 2.1, and >> the problems began. > >I would seriously consider the option of just sticking to 1.4. It's not >deprecated for server use. It should still have a lot of life left in it. If I only had a --faked-system-time option ... :-( That was the only reason why I migrated to 'modern' v2.1 - and slipped into a disaster. But what do you mean by 'deprecated for server use'? Where in https://www.gnupg.org/documentation/manuals/gnupg.pdf is GnuPG 2.1 restricted to a single-user scenario? I only found | In contrast to the standalone command gpg from GnuPG 1.x, which might be | better suited for server and embedded platforms, the 2.x version is | commonly installed under the name gpg2 and targeted to the desktop as it | requires several other modules to be installed. which is only about a more complex deployment, not about security risks. In my view crypto software that leaks information, for example caches passphrases for unauthorized access, doesn't qualify for any kind of use. Btw, a spelling error on page 102 line 15: | The encryption is done by using the command ^^ | DECRYPT > >> Just at the moment I have seven (!) gpg-agent.exe entries sharing the >> same HomeDir listed in the Windows Task-Manager, six of them frozen, >> one hopefully still alive. > >That sounds like a bug. In fact, an agent-freezing bug was fixed a short >while ago, are you runnning the latest and greatest? Otherwise, it might >be a new bug. I addressed my problems at the devel list. > >>> If you really want to cut down on the number of running agents, >>> I'd first discuss this with the GnuPG developers. Is the agent well >>> suited to serve dozens, hundreds of private keys? If the design >>> never accounted for this possiblity, it might be horribly >>> inefficient or expose unexpected issues. >> >> Works fine with 1.4. > >I understand what you mean (I think :), but you can't really draw any >conclusions from that, I (also) think. The private key handling in the >agent is all different code, a new architecture. That GnuPG 1.4 in >practice works fine with many secret keys does not say anything about >what the agent will do, even though they basically perform the same task. Initial problems with new software are okay as long as they can be fixed when they arise. > >I might be overly cautious here; Werner might well say "well sure it >handles lots of keys fine". But being cautious sometimes pays off >tremendously well... > >> I'm not sure whether gpg.exe can handle the concatenation of dozens >> of '--try-secret-key A7DD28F363B0924E3B735F22A49104AD3835E227' >> parameters and stop using keys not on that list even with their >> passphrases in the cache. > >But you know which nym address the message was addressed to, right? When >somebody tries to open a message addressed to their me at nyma.com account, >you only try the key associated with me at nyma.com. Two keys at max, when >you're doing a key rotation and the old key is still valid. > >There is no need to try their me at nymb.com key, because you know it was >addressed to me at nyma.com, and any message ending up there being >encrypted to me at nymb.com could even be an attempt to link those >identities: if me at nyma.com answers to the content of the mail, you now >know they actually have the private key for me at nymb.com, and you've >linked those accounts. It seems to me you *really* don't want any other >keys to be tried *at all*, even if the user owns them. Nevertheless the user has to get knowledge of such an attack, which is why a header entry reporting the decoding status is added to the message forwarded to the client: | O-Nym-Crypto: slot=19; sym=3; asym=1; esub=i; account=myaccount at nym.mixmin.net | O-Nym-Sig: Good signature (SHA1:[562619C278247C3B] Bananasplit Pseudonym Server (Bananasplit Pseudonymous Email Server) ; Sat, 10 Dec 2016 02:25:44 +0000) > >And similarly, if you could actually order the tried keys with >non-hidden recipients, you would only specify one or two keys which both >would be keys your user actually has. And --status-fd neatly tells you >which key was used to decrypt, so you can easily verify the intended key >was being used and not some other. However, right now, there is no way >to force trying specific keys first with non-hidden recipients. I now added --try-secret-key to all asymmetric decoding calls, which made processing a bit faster and possibly counters the passphrase cache weakness with asymmetric decryption. But there still remains the possibility of a symmetric decryption even with an invalid passphrase when the correct one is in the cache. And that will remain undetected, as there's no key-ID indicating the deviation from the given passphrase. > >> Don't get me wrong, but wasn't it just indolence to do without a >> separate sec key folder for each keyring? > >Well, since Werner would actually like to get rid of multiple keyrings >because of the problems it is giving, I can quite understand not >touching it with a forty feet pole when creating something new. In fact, >I wouldn't have been surprised if multiple public keyrings wasn't >implemented in GnuPG 2.1. But he did maintain that feature for now. When finally, what I still hope, the instabilities of the Windows build are cured, I think about running separate agents dedicated to the keyrings that hold secret keys, which I then would combine with pure public keyrings used for encryption and signature checks. That still adds a lot of complexity, but prevents erroneous secret key removal. It's not the user, it's the application that has to care about the structure and integrity of key storage. It's hard to tell users about the purpose of different key families when all of them are lumped together in one basket. > >> Exactly. For a user it looks like he has a key pair listed on one >> keyring, and when he adds and removes that key pair from a >> completely different keyring the secret key is removed from both. > >Don't use --delete-secret-and-public-key, but --delete-keys and >--delete-secret-keys. > >And as I said, multiple keyrings is asking for ambiguities when removing >keys, or using a key that has multiple different versions on different >keyrings. That's only critical with a common secret key depository. > >GnuPG 1.4 didn't always do the right thing with one secring and multiple >pubring's either. Or, "the right thing"... I mean, "the thing the user >intended". Who would use a single secret keyring with different public keyrings? > >> But ending up with dozens if not hundreds of agents around, working >> or frozen? I hope you understand that I don't like to bear >> responsibility for such a freaky scenario. > >No, but the freezing seems like a bug, a bug that should be fixed if it >is the agent's fault. And if you actually have hundreds of users logged >in at the same time, I would not think that hundreds of agents is >actually significant. Have you tried to run a test load, see what >resources those agents actually take? And whether that's actually >significant compared to the processing involved in handling all those >mails of which they are doing the assymetric decryption part? For security reasons currently all gpg calls are chained to avoid any interference. > >I am assuming you kill an agent when a user logs off. No, I don't, as a user can hold multiple nym accounts and WME related addresses, which e.g. with a POP3 download are processed in common. > >> It's a small tool running as a background task residing in the system >> tray. > >Maybe I don't understand, your proxy serving hundreds of users with each >possibly dozens of nym accounts is a diminutive part of the server? Or >do you mean when it is running on the client? Sure. It's upon the user how to deploy the software, either locally on his private computer or in an enterprise environment. > >> Your correspondent doesn't even have to know about your nym's key, >> which first and foremost is used to secure your proxy - nym server >> communication. > >The problem is the impersonation and who actually is the account holder >of a nym account. Your server is pretending to be the holder, or, >actually is the account holder. Your users don't own the nym account >anymore. They need to know this. The proxy might allow them to use the >nym address, but the proxy is the holder of the nym address. It holds >the private key. QED. With your interpretation of 'holder' gmail is the holder of all the mail accounts hosted there. In my view the one who is allowed to use an account is its holder. My software only adds the mechanisms to interact with nym servers in an easy way, which has to include to be in control of the nym acccount's key to prove one's identity when sending server commands. But this key does in no way have to be used for end-to-end encryption between dialog partners. The nym holder doesn't even have to know about the key's ID. > >In the end, the nym server is actually the real /owner/. In fact it's the proxy server resp. its administrator. The mail message you send to the nym server when creating an account includes your nym's public key, which then is used to check signatures authorizing further mail you send to the server. > But this is >more easily understood by users. They might not realize that they are >actually authorizing your proxy to do their business on their behalf, >impersonate them even. But it is a pseudonym, so it's less bad than >impersonating them using their legal name. With standard mail it's always up to you to care about end-to-end encryption. No system can know about the capabilities of your mail's recipients. You may agree on WME or normal OpenPGP encryption or no encryption at all. Nyms only provide anonymous/pseudonymous delivery. > >> But if you think client-to-client encryption is necessary then create >> and send him an additional key. IMHO no issue at all, the user >> rules. > >Iff they know how it works! User education is very important here, >because if they think "it's encrypted and pseudonymous" and don't use an >additional key, they are unwittingly including you (as server operator) >in their private communications! Of course users have to know that only the route between the proxy and the nym server is secured. > >> It's a transparent proxy server not caching any message. When the >> client sends a message, a '250 Ok' isn't returned before the >> proxy forwarded it to the Internet. How could the client otherwise >> get knowledge of processing problems. So, apart from wasting time by >> adding hours of latency at the sender just to get a different >> signature timestamp, your client would time out and drop the >> connection. > >This doesn't make sense to me. You don't want to expose the time the >signing is done, but then you go and expose the timing of it anyway by >sending the mail right away straight to its destination because your >user doesn't want to wait? Nope. It's the sender who won't understand why to waste time while getting rid of his message. Delay on the way to the recipient is a bothersome though extremely important characteristic of anonymous delivery. But delay at the sender is more of a hindrance than a help. > >I think those users that can't wait also can't use anonymous remailers >then? Several hops of anonymous remailers takes longer than two delays >on the proxy. When they can't wait for the proxy to delay, they >certainly can't wait for the anonymous remailers taking even more time. >And if the anonymous remailers don't delay, they still leak the time of >sending as much as your signature timestamp does, and do so to all >passive listeners rather than just the nym server decrypting the message >and seeing the signature. I think we are agreed that delay in a conversation, though indispensable for anonymity, can't be infinite. You now have to make a decision, either to burn much of the time you have to invest at your computer, or to fake signature timestamps and send the message immediately through a significantly longer remailer chain. And remember, without a faked timestamp, no matter how long you wait, your signature still unveils that you had access to a computer at the time you signed the message. Allow an opponent who suspects you as the nym holder to gather a few of your nym's timestamps and you're toast. > >I can understand not wanting to change a design much that has been >running for many years, so I am not saying you should do everything >differently. But keep it as it is for the right reasons. This doesn't >seem to be one to me. Unless I'm once more missing something :-). I hope I gave convincing reasons now. > >> Or think of someone who got the chance to send nym mail immediately >> through an open WLAN access point away from home. For him waiting is >> not an option. > >I'm not suggesting that the proxy force the client to wait before >sending the message to the proxy, or to wait for confirmation from the >proxy. But I do, as there's no other way to tell the proxy account holder whether local message processing succeeded. > That would be silly, because the actual communication over the >public internet would still take place at the same time as signing, just >a bit later. You want to lose the temporal connection between the client >sending the message and it being processed further. I'm saying it should >accept the message (do sanity checks), hold it in a queue for a while, >and only then sign it. Hold on to it some more, and then send it on. > >An anonymous remailer wouldn't force an incoming connection to wait for >a while either, right? It would accept the whole message, wait, send on. You're at the client site, where it's only about forwarding messages as fast and convenient as possible without revealing any important information. Chaum mixes as realized in the Mixmaster remailer network are much better in using time efficiently. > >> Of course that's a feature, an important feature protecting privacy, >> worth to be backported to v1.4. > >I think this distinction is important: *It's not a feature in any GnuPG >version*. That you can abuse things to do what you want does not make it >a supported feature! After all that discussion you still think suppressing the true timestamp of a message is 'abuse', possibly even fraud? As already discussed in the 'Proof for a creation date' thread you have to adopt other measures to provide solid evidence for the validity of a signature timestamp, which on its own is of now value at all. No sacred cow worth being protected at all hazards. > >I see a place for such a feature, but ultimately, the maintainers decide >whether it has a place in GnuPG or not, even if another developer did >the work of implementing it. > >> Many thanks for your profound considerations. > >I enjoy thinking about such stuff, and I hope it is useful to people I'm >thinking it aloud to... > >By the way, thanks for working on solutions to let people protect their >privacy and identity. It's important work in today's society! I have to thank all of you to render projects like mine possible. Kind regards Caro From stebe at mailbox.org Sun Dec 11 10:40:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Sun, 11 Dec 2016 09:40:00 +0000 Subject: Something strange with Stephan Becks Signatures? In-Reply-To: <5ab0b842-a6c5-4309-0019-a23e9112cf6a@mailbox.org> References: <584A0065.26179.994BF0@m.mansfeld.mansfeld-elektronik.de> <5ab0b842-a6c5-4309-0019-a23e9112cf6a@mailbox.org> Message-ID: <52d736c4-426a-3735-9469-3ea50717bd9c@mailbox.org> Stephan Beck: > Hi Matthias, > > Matthias Mansfeld: >> Hello, maybe someone has similar effects or can give me a hint where >> to look. If not, it's OK... >> >> Windows 7 pro(64), GPGRelay 9.962 (a POP3/SMTP "proxy" or better >> local relay for GnuPG), GnuPG 1.4.18, Pegasus Mail 4.72de >> >> Based on something strange on my computer (blocked memory etc. up to >> explorer.exe freeze after some hours running) finally my GnuPG >> freezes >> GPGRelay freezes waiting for GnuPG >> my Mail client >> freezes waiting for GPGRelay, and the common is nearly always, it >> freezes mostly exactly during loading a signed mail from Stephan >> Beck. > > Well, I can't say that I feel honored by so many references to my name, > but have you checked that (I suspect compatibility of PGP plugin and > your PM version as a probable reason) Matthias Mansfeld, could you resolve your problem or further track it down? If you remain that quiet (or you might even have gone on holiday, have you?), people unfortunately tend to believe that you are just a fudger, like the one guy, David, can't even remember his name, who asked me first in private, and when I told him to publish it on the list for everyone to see, he did that, I (and other people) answered him and he didn't say a word again. You know what a fudger is, don't you? Ah, and I'd urgently recommend to revoke (or have expired) at least the 1024 bit subkey for encryption, as it's obsolete (for some years now). If you don't know how it works, just ask the list ;-) Cheers Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Sun Dec 11 11:51:12 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 11 Dec 2016 11:51:12 +0100 Subject: Implications of a common private keys directory in 2.1 In-Reply-To: <20161211014830.B5635103200C@remailer.paranoici.org> References: <3b776db4-4161-35cc-31ac-b343b12edf7a@digitalbrains.com> <20161124230301.3055810320F5@remailer.paranoici.org> <17f5cadc-c7fb-c43a-a141-5d269ab45eaa@digitalbrains.com> <20161204205923.ADB011031FF9@remailer.paranoici.org> <78b30a87-43a1-bb2b-d965-c65a8a1c5b27@digitalbrains.com> <20161211014830.B5635103200C@remailer.paranoici.org> Message-ID: <4c35d09f-f63e-1d82-05b3-fe491bd0d506@digitalbrains.com> I'm going to respond to a few points that I already know my answer to. I might not actually have all that much interesting to say about the more complicated points, though... > But what do you mean by 'deprecated for server use'? I meant that GnuPG 1.4 is not deprecated for server use. By which I mean it is pretty much advised against for desktop use. I didn't mean that GnuPG 2.x was deprecated for anything at all :-). > which is only about a more complex deployment, not about security risks. It does say "targeted to the desktop", by the way. > In my view crypto software that leaks information, for example caches > passphrases for unauthorized access, doesn't qualify for any kind of > use. That's because it is assumed that if someone can access your ordinary agent socket, that would mean they have full access to your user account and are thus qualified to use it. It doesn't leak any information if it is simply handing that information to the user. It's just that your definition of "user" is quite different than the definition that was used in the design of the agent! (I kinda thought we had established this by now...) > Initial problems with new software are okay as long as they can be fixed > when they arise. I'm not talking about /problems/, I'm talking about /design/. I atrociously hate car analogies in IT, so I'm going to do one. If you compete with a lorry in the 24 hours Le Mans, and you finish last, would you say this is an "initial problem" in the design of your new lorry? And if you tried to deliver a load of 50 liter beer kegs to a bar in the center of a city with a lot of speedbumps, using a Le Mans Prototype racing car, would you then complain that it seems not to work altogether that brilliantly? I'm not even saying that the agent is incapable of handling a large amount of keys. I'm just saying that since it is possible that the agent was designed for use by a single human with a usual amount of keys, you could run into unforeseen problems when you use it in a totally different way. Such as that the agent doesn't have the required bottom clearance to go over speed bumps. > I now added --try-secret-key to all asymmetric decoding calls, which > made processing a bit faster and possibly counters the passphrase cache > weakness with asymmetric decryption. I really don't think it will prevent a cached passphrase from being used! Also, I doubt it serves any purpose without hidden recipients. > That's only critical with a common secret key depository. But this is what you're doing right now with GnuPG 2.1, right? AIUI, you have one agent and multiple public keyrings. This is similar to one secret keyring and multiple public keyrings in GnuPG 1.4. > Who would use a single secret keyring with different public keyrings? Erm... see above? :-) Apart from that, it's actually something people do use. It's why you need --no-default-keyring if you don't want to use multiple keyrings with --keyring. If everybody only ever used one public keyring at the same time, --no-default-keyring would be implied. >> I am assuming you kill an agent when a user logs off. > > No, I don't, as a user can hold multiple nym accounts and WME related > addresses, which e.g. with a POP3 download are processed in common. First of all, I'm saying "in this scenario of how you could solve it, I'm assuming part of the way you solve it is by killing the agent when a user logs off". So "No, I don't" is not an answer I'd expect, I'd then expect "No, I would not". Furthermore, I don't understand. When this user logs off why would it be bad to kill their agent? They've sent "QUIT" to your POP3 server and closed the TCP/IP connection: they've logged off your proxy! You can just restart the agent when they log back in. It has no relation with how many nym accounts this user has whatsoever, that's a non-sequitur to me. > With your interpretation of 'holder' gmail is the holder of all the mail > accounts hosted there. No, I said this correctly, I think. I used two different words, owner and holder. GMail is the /owner/ of all the e-mail accounts. If they decide to go bankrupt, you can balk all you want, you won't get your name back to use it. It's gone together with its owner, GMail / Google. You don't have any rights to the gmail.com name. The /holder/ is the one who has the passphrase. And since a nym account is not protected by a passphrase but by an OpenPGP keypair, the one holding the private key is the holder. And your proxy has the private key. Not your user. You yourself say they don't even need to know the key's ID, let alone its private key. If I know your GMail passphrase, and I log in and change that passphrase, I've taken your account. Would you say you still hold that account? By rights you perhaps should, but you *don't*. If you decide you quite like being the pseudonym and take it from your user, would you say they still hold that account? That's the crux of the matter. Your users know that the server operator of nyma.com can just say to them "Hey, it's my server, I don't want you to use anymore". They need to know this goes for your proxy as well. > Of course users have to know that only the route between the proxy and > the nym server is secured. I hope you mean "of course I need to inform them", not "of course users should figure this out", because it's slightly ambiguous the way you say it :-). > Delay on the way to the recipient is a > bothersome though extremely important characteristic of anonymous > delivery. But delay at the sender is more of a hindrance than a help. I'm saying you should delay delivery sign delay delivery deliver to first remailer it delays delivery .... Don't delay the action of sending, delay the action of delivery. > I think we are agreed that delay in a conversation, though indispensable > for anonymity, can't be infinite. Delay in a conversation serves no purpose at all. What the people doing conversation see: (TCP/IP connection from client to proxy) 12:00 C> Please send my message 12:00 P> Alright, please accept a delay... 12:05 P> Okay, I'm done pondering the great truths, deliver! 12:05 C> 12:05 P> Thanks and (TCP/IP connection from proxy to first remailer) 12:05 P> Got a message for ya 12:05 R> Go ahead 12:05 P> 12:05 R> Thanks What an observer sees: TCP/IP connection to proxy, originating at client: 12:00 C> 12:00 P> 12:05 P> 12:05 C> 12:05 P> TCP/IP connection from proxy to first remailer: 12:05 P> 12:05 R> 12:05 P> 12:05 R> The temporal connection between the two is glaringly obvious! You know when the client sent this message! Delay in a conversation doesn't help. You need to put a delay /between/ conversations. I can agree that delays shouldn't be infinite. Kinda goes without saying, although this would be a *very* secure system. > And remember, without a faked timestamp, no matter how long you wait, > your signature still unveils that you had access to a computer at the > time you signed the message. It only reveals that your computer was running if your proxy is running at the client. If the proxy is on a server, you could use the delay tactic and it would severely limit the use of knowing the timestamp. But when the proxy is on the client, then I think that a faked timestamp is useful. Also when you don't want to change your whole design. But how do/did you handle timestamps with GnuPG 1.4? > I hope I gave convincing reasons now. Yes. Also; when I didn't reply to things you said earlier in the discussion, that was sometimes because I agreed so had nothing interesting to say about. This tactic does make it seem like I only have counterpoints and never agree with anything, so I should probably be more aware of this effect... > But I do, as there's no other way to tell the proxy account holder > whether local message processing succeeded. This depends on the intelligence of the proxy. If it depends on the first remailer to do checks and report success, then it won't work. But if it can check the sanity of the message without doing any connections to the outside world, it can do all of those checks and only delay the signing. And I already said that I see no reason to use the user's password to encrypt the private key, so signing can't fail due to a wrong passphrase. > You're at the client site, where it's only about forwarding messages as > fast and convenient as possible without revealing any important > information. This seems to presume the proxy runs at the client. I've already said above that the delay tactic only makes sense when the proxy runs on a server, so I agree. > After all that discussion you still think suppressing the true timestamp > of a message is 'abuse', possibly even fraud? No, I said using --faked-system-time to fake a signature timestamp is abuse of functionality. The man page says "This option is only useful for testing", and that's not what you're using it for. Please read what I say. I said: I think this distinction is important: *It's not a feature in any GnuPG* *version*. That you can abuse things to do what you want does not make it a supported feature! Deconstruction: do what you want -> fake signature timestamps abuse things -> use an option that says "for testing only" You said "worth to be backported to 1.4". This seemed to imply to me you thought the worth was in faking signature timestamps, but a backport implies that we're talking about an actual feature. To which I say: *it's not a feature*. > I have to thank all of you to render projects like mine possible. Heh, well, I can't take credit for that, so I'll happily pass these thanks on to the people that do :-). Oops, this mail has gotten so much larger than I intended... 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 m.mansfeld at mansfeld-elektronik.de Sun Dec 11 11:56:20 2016 From: m.mansfeld at mansfeld-elektronik.de (Matthias Mansfeld) Date: Sun, 11 Dec 2016 11:56:20 +0100 Subject: Strange behaviour (was: Re: Something strange with .. a specific Signature?) In-Reply-To: <5ab0b842-a6c5-4309-0019-a23e9112cf6a@mailbox.org> References: <584A0065.26179.994BF0@m.mansfeld.mansfeld-elektronik.de>, <5ab0b842-a6c5-4309-0019-a23e9112cf6a@mailbox.org> Message-ID: <584D30D4.6780.31D8371@m.mansfeld.mansfeld-elektronik.de> On 9 Dec 2016 at 14:01, Stephan Beck wrote: > Hi Matthias, [..] > > Windows 7 pro(64), GPGRelay 9.962 (a POP3/SMTP "proxy" or better > > local relay for GnuPG), GnuPG 1.4.18, Pegasus Mail 4.72de > > > > Based on something strange on my computer (blocked memory etc. up > to > > explorer.exe freeze after some hours running) finally my GnuPG > > freezes >> GPGRelay freezes waiting for GnuPG >> my Mail client > > freezes waiting for GPGRelay, and the common is nearly always, it > > freezes mostly exactly during loading a signed mail from Stephan > > Beck. > Well, I can't say that I feel honored by so many references to my > name, but have you checked that (I suspect compatibility of PGP > plugin and your PM version as a probable reason) > > 1) the PGP-plugin you use is the latest as on (1) > 2) this latest version of the PGP plugin (for use in 4.72) is > already > made fit for Windows7 No, I don't use any PMail Plugin at all (you mentioned a PGP Plugin which would work well with PGP, not GnuPG. A many years old GnuPG Plugin exists, but is totally unmaintained, doesn't work well with attachments etc....) I use GPGRelay with GnuPG 1.4.18; Pegasus talks (unencrypted, unsigned) with GPGRelay on localhost with port numbers, and GPGRelay acts as "local proxy" which talks with the POP3 and SMTP servers and signs/verifies/encrypts/decrypts the mails with GnuPG. See http://sites.inka.de/tesla/gpgrelay.html > [...] 3) is configured properly concerning PGP/MIME support: see > section Using the Program--> PGP/MIME encryption I would say (concerning GPGRelay/GnuPG) yes, because (standard answer) I did not change anything, not with Pegasus Mail, not with any settings in GPGRelay and it ran perfectly. > 4) gnupg 1.4.18 for Windows' debug output > 5) you are using a Windows 32-bit-application in a 64 bit Windows7 > environment; that should work in general, but may give some issues. > I > haven't investigated further here. > 6) in general, for Windows 7 "debugging light": see "Event > Logging" > (DE_DE=Ereignisanzeige) and look for entries in the various log > files, > filtering as needed ... OK, I will try this... > 7) for Windows Debugging heavy, download the Win7 Debugging Tools > (4) > > As to logging I only found that PegasusMail(3) has a WMP log file > for > debugging purposes but it is not editable, as to logs the _complete_ TCP/IP protocol (in this case between Pegasus Mail and GPGRelay) including the decrypted mail data... maybe it helps to see what happens last before everything stucks... Similar logging exists for GPGRelay, and that is, where I see the last mail GPGRelay tries to retrieve from the POP3 server before it just hangs and where I found that it happens quite often during verifying especially your mails. That is, why I asked whether something on your signatures may be a bit "special" Currently I have not the time to go much more in depth and can live with the fact that in that moment much other stuff on this computer tends to hang and the "easiest" way for now is to reboot... It is possible that this behaviour came with one of the last MS patchdays... Thanks, best regards Matthias -- OpenPGP: http://www.mansfeld-elektronik.de/gnupgkey/mansfeld.asc Fingerprint: 6563 057D E6B8 9105 1CE4 18D0 4056 1F54 8B59 40EF From peter at digitalbrains.com Sun Dec 11 12:01:04 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 11 Dec 2016 12:01:04 +0100 Subject: Something strange with Stephan Becks Signatures? In-Reply-To: <52d736c4-426a-3735-9469-3ea50717bd9c@mailbox.org> References: <584A0065.26179.994BF0@m.mansfeld.mansfeld-elektronik.de> <5ab0b842-a6c5-4309-0019-a23e9112cf6a@mailbox.org> <52d736c4-426a-3735-9469-3ea50717bd9c@mailbox.org> Message-ID: <019b4638-0189-0c9c-b13b-4d2bcec77e8d@digitalbrains.com> Woa, easy there. While the Subject:-line of the OP wasn't perhaps chosen very wisely, please calm your tone. I don't think the OP has it in for you (though it is a possibility, but let's assume good faith). It seems like he has a killer issue, and if there really is a correlation to opening your messages, that could be worthful info for tracking down the cause. > I (and other people) answered him and he didn't say a word again. Without looking up the specific case, it happens more often that people go away satisfied without sharing their satisfaction. Hell, I've been guilty of it myself. In fact, I should still thank someone who gave nice extra information which I wanted to ponder for a bit before replying. I never actually got that far pondering and haven't thanked him yet... 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 Sun Dec 11 12:15:40 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 11 Dec 2016 12:15:40 +0100 Subject: An attempt at backporting 2.1.16 from Debian sid to Debian jessie In-Reply-To: <0d7e39f9-d26e-6fee-1898-55000aeb807e@digitalbrains.com> References: <0d7e39f9-d26e-6fee-1898-55000aeb807e@digitalbrains.com> Message-ID: I discovered I accidentally wasn't allowing public access to the repository. I've fixed this and you can now download from: https://gitlab.com/DigitalBrains1/alt-debian-gnupg2 The offending setting seemed to have been: Feature Visibility - Repository Push files to be stored in this project Now I thought setting this to "Everyone" would allow anyone to push files to the project, which seemed like a truly horrendous feature. Apparently, it allows pushes/files to be visible? 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 m.mansfeld at mansfeld-elektronik.de Sun Dec 11 11:56:20 2016 From: m.mansfeld at mansfeld-elektronik.de (Matthias Mansfeld) Date: Sun, 11 Dec 2016 11:56:20 +0100 Subject: Strange behaviour (was: Re: Something strange with .. a specific Signature?) In-Reply-To: <52d736c4-426a-3735-9469-3ea50717bd9c@mailbox.org> References: <584A0065.26179.994BF0@m.mansfeld.mansfeld-elektronik.de>, <5ab0b842-a6c5-4309-0019-a23e9112cf6a@mailbox.org>, <52d736c4-426a-3735-9469-3ea50717bd9c@mailbox.org> Message-ID: <584D30D4.16188.31D83FE@m.mansfeld.mansfeld-elektronik.de> On 11 Dec 2016 at 9:40, Stephan Beck wrote: > > Stephan Beck: > > Hi Matthias, > > > > Matthias Mansfeld: > >> Hello, maybe someone has similar effects or can give me a hint > >> where to look. If not, it's OK... > >> > >> Windows 7 pro(64), GPGRelay 9.962 (a POP3/SMTP "proxy" or better > >> local relay for GnuPG), GnuPG 1.4.18, Pegasus Mail 4.72de > >> > >> Based on something strange on my computer (blocked memory etc. up > >> to explorer.exe freeze after some hours running) finally my GnuPG > >> freezes >> GPGRelay freezes waiting for GnuPG >> my Mail client > >> freezes waiting for GPGRelay, and the common is nearly always, it > >> freezes mostly exactly during loading a signed mail from Stephan > >> Beck. > > > > Well, I can't say that I feel honored by so many references to my > > name, but have you checked that (I suspect compatibility of PGP > > plugin and your PM version as a probable reason) OK, sorry for that, I hope you are happier with the changed subject :-) > > Matthias Mansfeld, could you resolve your problem or further track it > down? No, because it is not so reproducible that I can exactly say when what happens. Sorry for my late answer.... I will answer the technical questions between the lines in your other reply. Regards Matthias -- Unsere Korrespondenz kann mitgelesen werden. Wollen Sie das erschweren, mailen wir uns gerne mit (Open)PGP verschl?sselt. - Matthias Mansfeld Elektronik * Leiterplattenlayout Neithardtstr. 3, 85540 Haar; Tel.: 089/4620 093-7, Fax: -8 Internet: http://www.mansfeld-elektronik.de OpenPGP: http://www.mansfeld-elektronik.de/gnupgkey/mansfeld.asc Fingerprint: 6563 057D E6B8 9105 1CE4 18D0 4056 1F54 8B59 40EF From ndk.clanbo at gmail.com Sun Dec 11 13:40:43 2016 From: ndk.clanbo at gmail.com (NdK) Date: Sun, 11 Dec 2016 13:40:43 +0100 Subject: Strange behaviour In-Reply-To: <584D30D4.6780.31D8371@m.mansfeld.mansfeld-elektronik.de> References: <584A0065.26179.994BF0@m.mansfeld.mansfeld-elektronik.de> <5ab0b842-a6c5-4309-0019-a23e9112cf6a@mailbox.org> <584D30D4.6780.31D8371@m.mansfeld.mansfeld-elektronik.de> Message-ID: Il 11/12/2016 11:56, Matthias Mansfeld ha scritto: > Currently I have not the time to go much more in depth and can live > with the fact that in that moment much other stuff on this computer > tends to hang and the "easiest" way for now is to reboot... It is > possible that this behaviour came with one of the last MS > patchdays... I think it could even be realated to some HW issue. Are fans clean? Are capacitors OK? Electrolytic ones, the tall cylinders, often tend to "explode": they usually have an 'X' on the top and that should be flat and clean, else the capacitor is surely bad. Did you run a RAM test? And a CPU test? I know, it's just a remote possibility, but given the "randomness" it could be worth checking. BYtE, Diego From peter at digitalbrains.com Sun Dec 11 18:15:18 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 11 Dec 2016 18:15:18 +0100 Subject: Hybrid keysigning party, your opinion? In-Reply-To: References: <6e4c97a3-de62-7ced-ba89-ad4fa9afbabc@mailbox.org> Message-ID: <9df31ca9-2eb9-2680-f671-e77bf2c78166@digitalbrains.com> On 08/12/16 14:51, Lachlan Gunn wrote: > Personally I am of the mind that anything longer than that email is > wishful thinking, you have to get people to actually follow it. The e-mail wasn't meant to be the text for participants. I've spent all afternoon writing a text at the 33C3 wiki[1], but only part of it is meant to be read by everyone, or essentially, everyone who wants to know more than the most basic. It's 1764 words. I've tried to restrict it to the important things, and I feel that cutting it further down would lose important information. I don't think it's necessary for everyone to read the whole section, though. My e-mail was 1424 words though, so I am afraid I ended up in your wishful thinking area. The remaining 1607 words are in the sections "Background" and "Option for advanced users", and those words happen to include the name Lachlan. Go check it out! ;-P > To this end, another suggestion is to make the forms that they fill in > identical, whether or not they are late. You could do this by putting > the fingerprints at the end of the primary document and just printing > out the first bit for latecomers. This might save some "I don't know > how your form works, I have the prearranged one" on the day. I really like this suggestion! I had to think about it for a while before I could see a way to make it work. The trouble is that I want caff to be able to process the file, and for that I need to keep it having much of the same patterns. I ended up not significantly altering the two files compared to what I proposed, but instead suggesting everybody should use the scrubbed version. That way, the instructions are the same for all participants. Thank you, Peter. [1] https://events.ccc.de/congress/2016/wiki/Session:Keysigning_party -- 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 Dec 11 18:22:26 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 11 Dec 2016 18:22:26 +0100 Subject: Hybrid keysigning party, your opinion? In-Reply-To: <8a444fac-e669-d3da-c084-f63614b1697c@twopif.net> References: <6e4c97a3-de62-7ced-ba89-ad4fa9afbabc@mailbox.org> <630d4332-afb0-5f8b-acde-78961dd6abab@mailbox.org> <15922fc6-b6b9-34f1-7dd0-61427c7a2722@digitalbrains.com> <8a444fac-e669-d3da-c084-f63614b1697c@twopif.net> Message-ID: <702f7123-cb6f-98c0-aab3-b5711d4e0769@digitalbrains.com> On 08/12/16 15:08, Lachlan Gunn wrote: > Can't they get this from the other participants in the line? Checking > with a few people at random gives reasonable assurance that this is what > was agreed on at the beginning, or they can check them all if they want > to be certain. Personally, I find checking a few other participants to be too weak an assurance. I don't believe in security by numbers. If I'm dealing with statistics, I want them to be on the order of "chance of one in 2^127". You might recognise the chosen quantity :-). But everybody is free to decide their own policy. And checking at everyone would hold up the process; it's 64 hex digits to verify! 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 Sun Dec 11 18:41:01 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 11 Dec 2016 18:41:01 +0100 Subject: Hybrid keysigning party, your opinion? In-Reply-To: <702f7123-cb6f-98c0-aab3-b5711d4e0769@digitalbrains.com> References: <6e4c97a3-de62-7ced-ba89-ad4fa9afbabc@mailbox.org> <630d4332-afb0-5f8b-acde-78961dd6abab@mailbox.org> <15922fc6-b6b9-34f1-7dd0-61427c7a2722@digitalbrains.com> <8a444fac-e669-d3da-c084-f63614b1697c@twopif.net> <702f7123-cb6f-98c0-aab3-b5711d4e0769@digitalbrains.com> Message-ID: On 11/12/16 18:22, Peter Lebbing wrote: > You might recognise the chosen quantity :-). Or you might not because it was based on a stupid thinking error on my side. Let's make it "a chance of 1 in 2^128", which could be the chance of you trying a symmetric encryption key and actually being right about it. 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 m.mansfeld at mansfeld-elektronik.de Sun Dec 11 18:30:30 2016 From: m.mansfeld at mansfeld-elektronik.de (Matthias Mansfeld) Date: Sun, 11 Dec 2016 18:30:30 +0100 Subject: Strange behaviour In-Reply-To: References: <584A0065.26179.994BF0@m.mansfeld.mansfeld-elektronik.de>, <584D30D4.6780.31D8371@m.mansfeld.mansfeld-elektronik.de>, Message-ID: <584D8D36.23966.FCC095@m.mansfeld.mansfeld-elektronik.de> On 11 Dec 2016 at 13:40, NdK wrote: [...] > I think it could even be realated to some HW issue. Are fans clean? Yes, and all temperatures are under monitoring > Are capacitors OK? Electrolytic ones, the tall cylinders, often > tend to "explode": they usually have an 'X' on the top and that > should be flat and clean, else the capacitor is surely bad. I did not especially look for (visually) bad ones, when I had the laptop open last time for cleaning the fan (it is an HP EliteBook 8740w). But maybe I will have a deeper look on these guys the next time... Normally I would say, the laptop is still too young for dead caps... > Did you run a RAM test? And a CPU test? I will start at least a deeper RAM test maybe tonight (or in the morning.. :-/ or if I don't need the laptop for the necessary hours.... 8GB....) Regards Matthias PS.: Resent to list as first reply was only at NdK. sorry for confusion.. -- OpenPGP: http://www.mansfeld-elektronik.de/gnupgkey/mansfeld.asc Fingerprint: 6563 057D E6B8 9105 1CE4 18D0 4056 1F54 8B59 40EF From caro at nymph.paranoici.org Sun Dec 11 20:58:57 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Sun, 11 Dec 2016 19:58:57 +0000 (UTC) Subject: Implications of a common private keys directory in 2.1 References: <3b776db4-4161-35cc-31ac-b343b12edf7a@digitalbrains.com> <17f5cadc-c7fb-c43a-a141-5d269ab45eaa@digitalbrains.com> <20161204205923.ADB011031FF9@remailer.paranoici.org> <78b30a87-43a1-bb2b-d965-c65a8a1c5b27@digitalbrains.com> <20161211014830.B5635103200C@remailer.paranoici.org> <4c35d09f-f63e-1d82-05b3-fe491bd0d506@digitalbrains.com> Message-ID: <20161211195857.37447103200C@remailer.paranoici.org> Peter Lebbing wrote: >> But what do you mean by 'deprecated for server use'? > >I meant that GnuPG 1.4 is not deprecated for server use. By which I mean >it is pretty much advised against for desktop use. > >I didn't mean that GnuPG 2.x was deprecated for anything at all :-). I see. Thanks for that clarification. > >I'm not talking about /problems/, I'm talking about /design/. I [brilliant car analogy removed] With 'problems' i referred to the GenKey bug/feature I reported a few hours ago and the IPC instabilities I experienced. Sure, the single-sec-keys-depository : multiple-pub-keyrings configuration is a design decision, though one I don't quite understand. > >> I now added --try-secret-key to all asymmetric decoding calls, which >> made processing a bit faster and possibly counters the passphrase cache >> weakness with asymmetric decryption. > >I really don't think it will prevent a cached passphrase from being used! I hope it at least plugs the security hole of a key in the sec keys folder different from the one defined with --try-secret-key being used together with a passphrase from the cache to decrypt data without any authorization. > >Also, I doubt it serves any purpose without hidden recipients. You mean --try-secret-key doesn't overrule the key parameter that comes along with the encoded material? --try-all-secrets doesn't look at the possibly 'bogus key ID' (page 61) and the manual doesn't say anything different concerning --try-secret-key. >>> >>> And as I said, multiple keyrings is asking for ambiguities when removing >>> keys, or using a key that has multiple different versions on different >>> keyrings. >> >> That's only critical with a common secret key depository. > >But this is what you're doing right now with GnuPG 2.1, right? That's only because v2.1 forces me to do so, which is what I complain about, a common secret key depository. The only alternative to avoid ambiguities with v2.1 would be to confine oneself to a single public keyring for everything, in my case - WME keys (pub/sec) - nym account keys (pub/sec) - nym server keys (pub) - remailer keys (pub) For a more complex application such a restriction means chaos. http://danner-net.de/omom/tutornymsetup.htm provides some insight. > AIUI, you >have one agent and multiple public keyrings. This is similar to one >secret keyring and multiple public keyrings in GnuPG 1.4. With 1.4 I have a one-to-one sec:pub keyring relationship, where such ambiguities don't matter, and where it's foreseeable what happens when I delete a key pair from such a single keyring pair. > >>> I am assuming you kill an agent when a user logs off. >> >> No, I don't, as a user can hold multiple nym accounts and WME related >> addresses, which e.g. with a POP3 download are processed in common. > >First of all, I'm saying "in this scenario of how you could solve it, >I'm assuming part of the way you solve it is by killing the agent when a >user logs off". So "No, I don't" is not an answer I'd expect, I'd then >expect "No, I would not". > >Furthermore, I don't understand. When this user logs off why would it be >bad to kill their agent? They've sent "QUIT" to your POP3 server and >closed the TCP/IP connection: they've logged off your proxy! You can >just restart the agent when they log back in. It has no relation with >how many nym accounts this user has whatsoever, that's a non-sequitur to me. User login/logoff represents in no way crypto task granularity, as a user may hold several nym accounts and WME related addresses and so on. If I'd take your proposal seriously the agent would have to be restarted with nearly every en-/decoding call to clear the passphrase cache. Is that what you have in mind? > >> With your interpretation of 'holder' gmail is the holder of all the mail >> accounts hosted there. > >No, I said this correctly, I think. I used two different words, owner >and holder. GMail is the /owner/ of all the e-mail accounts. If they >decide to go bankrupt, you can balk all you want, you won't get your > name back to use it. It's gone together with its >owner, GMail / Google. You don't have any rights to the gmail.com name. So the maintainer of the proxy is the owner, right? > >The /holder/ is the one who has the passphrase. Which is the account holder, who has the proxy login credentials. When he logs into the proxy to send a nym message (From: myaccount at mynymserver.org) the proxy checks whether the account holder also holds the respective nym account and, if that's the case, transforms and forwards the message to the nym server. The same holds true for signing the message of a WME supported From address. > >And since a nym account is not protected by a passphrase but by an >OpenPGP keypair, the one holding the private key is the holder. And your >proxy has the private key. Not your user. You yourself say they don't >even need to know the key's ID, let alone its private key. I see that differently. The nym service consists of two parts, the proxy represents the local non-anonymous one, the nym server is the remote part in anonymity land, both separated but also joined by the anonymizing message transfer cascade. Those parts can't do without each other, only together they function correctly, which is why they have to be seen as an indivisible unit. > >If I know your GMail passphrase, and I log in and change that >passphrase, I've taken your account. Would you say you still hold that >account? By rights you perhaps should, but you *don't*. The same goes with a proxy account. > >If you decide you quite like being the pseudonym and take >it from your user, would you say they still hold that account? Me as the proxy administrator? Well, the situation is similar to a GMail administrator, who can also use any GMail account to send messages. He's the admin, he's God. > >> Delay on the way to the recipient is a >> bothersome though extremely important characteristic of anonymous >> delivery. But delay at the sender is more of a hindrance than a help. > >I'm saying you should > >delay delivery >sign >delay delivery >deliver to first remailer >it delays delivery >.... > >Don't delay the action of sending, delay the action of delivery. > >> I think we are agreed that delay in a conversation, though indispensable >> for anonymity, can't be infinite. > >Delay in a conversation serves no purpose at all. > >What the people doing conversation see: > >(TCP/IP connection from client to proxy) > >12:00 C> Please send my message >12:00 P> Alright, please accept a delay... >12:05 P> Okay, I'm done pondering the great truths, deliver! >12:05 C> >12:05 P> Thanks > >and > >(TCP/IP connection from proxy to first remailer) >12:05 P> Got a message for ya >12:05 R> Go ahead >12:05 P> >12:05 R> Thanks > >What an observer sees: > >TCP/IP connection to proxy, originating at client: >12:00 C> >12:00 P> >12:05 P> >12:05 C> >12:05 P> When the observer sits in your LAN you're doomed anyway. It's only about an external adversary controlling the Internet. > >TCP/IP connection from proxy to first remailer: >12:05 P> >12:05 R> >12:05 P> >12:05 R> > >The temporal connection between the two is glaringly obvious! You know >when the client sent this message! > >Delay in a conversation doesn't help. You need to put a delay /between/ >conversations. I'm not sure what you mean by delay in a conversation vs. between conversations. What you need is delay between forwarding the message to entry remailers (multiple copies to increase reliability) and the delivery by the exit remailer either to the nym server or directly to the final recipient. Delay at the sender's LAN adds nothing to anonymity. > >I can agree that delays shouldn't be infinite. Kinda goes without >saying, although this would be a *very* secure system. > >> And remember, without a faked timestamp, no matter how long you wait, >> your signature still unveils that you had access to a computer at the >> time you signed the message. > >It only reveals that your computer was running if your proxy is running >at the client. If the proxy is on a server, you could use the delay >tactic and it would severely limit the use of knowing the timestamp. Bad enough. > >But when the proxy is on the client, then I think that a faked timestamp >is useful. Also when you don't want to change your whole design. But how >do/did you handle timestamps with GnuPG 1.4? With each signature creation step my application running with admin rights temporarily changes system time on a random basis. > >> I hope I gave convincing reasons now. > >Yes. Also; when I didn't reply to things you said earlier in the >discussion, that was sometimes because I agreed so had nothing >interesting to say about. This tactic does make it seem like I only have >counterpoints and never agree with anything, so I should probably be >more aware of this effect... No, no, it's okay. Let me add that I truly mean no harm though my remarks may sometimes sound eager or even offensive. For me open discussions are important to get rid of mindcuffs. > >> But I do, as there's no other way to tell the proxy account holder >> whether local message processing succeeded. > >This depends on the intelligence of the proxy. If it depends on the >first remailer to do checks and report success, then it won't work. But >if it can check the sanity of the message without doing any connections >to the outside world, it can do all of those checks and only delay the >signing. And I already said that I see no reason to use the user's >password to encrypt the private key, so signing can't fail due to a >wrong passphrase. The possibly short proxy user's passphrase is different from the key's passphrase, which is randomly created. > >> You're at the client site, where it's only about forwarding messages as >> fast and convenient as possible without revealing any important >> information. > >This seems to presume the proxy runs at the client. I've already said >above that the delay tactic only makes sense when the proxy runs on a >server, so I agree. Even the client-server interaction in a corporate LAN environment has to be assumed secure. >Deconstruction: > >do what you want -> fake signature timestamps > >abuse things -> use an option that says "for testing only" So key 'Creation-Date' (page 84) | Creation-Date: iso-date | Set the creation date of the key as stored in the key information and which is | also part of the fingerprint calculation. Either a date like "1986-04-26" or a full | timestamp like "19860426T042640" may be used. The time is considered to be | UTC. The special notation "seconds=N" may be used to directly specify a the | number of seconds since Epoch (Unix time). If it is not given the current time | is used. a v1.4 and v2 'feature', is abusive as well? I see no 'testing only' phrase in that explanation. > >You said "worth to be backported to 1.4". This seemed to imply to me you >thought the worth was in faking signature timestamps, but a backport >implies that we're talking about an actual feature. To which I say: >*it's not a feature*. It depends on what you're aiming at. Sure, PGP/GnuPG was initially developed to provide privacy by protecting contents. And it does a great job in this respect. But times have changed. We can no longer ignore that surveillance also concentrates on metadata resulting in a worldwide sociogram of the population, making social networks transparent to intelligence agencies, multinationals and whomever else. The knowledge of relationships between individuals, groups and organizations opens the way to social engineering and political oppression. That's why anonymity including the obfuscation of temporal connections isn't a negligible gimmick but a crucial measure, which IMHO GnuPG should also be obligated to. So why not reconsider the 'only useful for testing' statement and see timestamp invalidation as an important anti-surveillance strategy? > >> I have to thank all of you to render projects like mine possible. > >Heh, well, I can't take credit for that, so I'll happily pass these >thanks on to the people that do :-). Support is in no way less important than development. > >Oops, this mail has gotten so much larger than I intended... Being the instigator I take full responsibility for that. ;-) Kind regards Caro From rjh at sixdemonbag.org Sun Dec 11 21:37:19 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 11 Dec 2016 15:37:19 -0500 Subject: Hybrid keysigning party, your opinion? In-Reply-To: References: <6e4c97a3-de62-7ced-ba89-ad4fa9afbabc@mailbox.org> <630d4332-afb0-5f8b-acde-78961dd6abab@mailbox.org> <15922fc6-b6b9-34f1-7dd0-61427c7a2722@digitalbrains.com> <8a444fac-e669-d3da-c084-f63614b1697c@twopif.net> <702f7123-cb6f-98c0-aab3-b5711d4e0769@digitalbrains.com> Message-ID: <75b17677-de90-ed2f-c03d-a6d507cc5d88@sixdemonbag.org> > Or you might not because it was based on a stupid thinking error on my > side. Let's make it "a chance of 1 in 2^128", which could be the chance > of you trying a symmetric encryption key and actually being right about it. I'm glad you made the correction: that error was sooooo profound. :) (For those not up on their large-number theory: the difference is insignificant. Peter's correction was made in a spirit of utterly pedantic attention to detail [a spirit I share!], not because it mattered.) From stebe at mailbox.org Sun Dec 11 21:43:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Sun, 11 Dec 2016 20:43:00 +0000 Subject: Strange behaviour In-Reply-To: <584D30D4.6780.31D8371@m.mansfeld.mansfeld-elektronik.de> References: <584A0065.26179.994BF0@m.mansfeld.mansfeld-elektronik.de> <5ab0b842-a6c5-4309-0019-a23e9112cf6a@mailbox.org> <584D30D4.6780.31D8371@m.mansfeld.mansfeld-elektronik.de> Message-ID: Matthias Mansfeld: > On 9 Dec 2016 at 14:01, Stephan Beck wrote: > >> Hi Matthias, > [..] >>> Windows 7 pro(64), GPGRelay 9.962 (a POP3/SMTP "proxy" or better >>> local relay for GnuPG), GnuPG 1.4.18, Pegasus Mail 4.72de >>> >>> Based on something strange on my computer (blocked memory etc. up >> to >>> explorer.exe freeze after some hours running) finally my GnuPG >>> freezes >> GPGRelay freezes waiting for GnuPG >> my Mail client >>> freezes waiting for GPGRelay, and the common is nearly always, it >>> freezes mostly exactly during loading a signed mail from Stephan >>> Beck. > >> Well, I can't say that I feel honored by so many references to my >> name, but have you checked that (I suspect compatibility of PGP >> plugin and your PM version as a probable reason) >> >> 1) the PGP-plugin you use is the latest as on (1) >> 2) this latest version of the PGP plugin (for use in 4.72) is >> already >> made fit for Windows7 > > No, I don't use any PMail Plugin at all (you mentioned a PGP Plugin > which would work well with PGP, not GnuPG. A many years old GnuPG > Plugin exists, but is totally unmaintained, doesn't work well with > attachments etc....) > > I use GPGRelay with GnuPG 1.4.18; Pegasus talks (unencrypted, > unsigned) with GPGRelay on localhost with port numbers, and GPGRelay > acts as "local proxy" which talks with the POP3 and SMTP servers and > signs/verifies/encrypts/decrypts the mails with GnuPG. > > See http://sites.inka.de/tesla/gpgrelay.html > >> [...] 3) is configured properly concerning PGP/MIME support: see >> section Using the Program--> PGP/MIME encryption > > I would say (concerning GPGRelay/GnuPG) yes, because (standard > answer) I did not change anything, not with Pegasus Mail, not with > any settings in GPGRelay and it ran perfectly. > >> 4) gnupg 1.4.18 for Windows' debug output >> 5) you are using a Windows 32-bit-application in a 64 bit Windows7 >> environment; that should work in general, but may give some issues. >> I >> haven't investigated further here. >> 6) in general, for Windows 7 "debugging light": see "Event >> Logging" >> (DE_DE=Ereignisanzeige) and look for entries in the various log >> files, >> filtering as needed > > ... OK, I will try this... > > >> 7) for Windows Debugging heavy, download the Win7 Debugging Tools >> (4) >> >> As to logging I only found that PegasusMail(3) has a WMP log file >> for >> debugging purposes but it is not editable, as to > > logs the _complete_ TCP/IP protocol (in this case between Pegasus > Mail and GPGRelay) including the decrypted mail data... maybe it > helps to see what happens last before everything stucks... > > Similar logging exists for GPGRelay, and that is, where I see the > last mail GPGRelay tries to retrieve from the POP3 server before it > just hangs and where I found that it happens quite often during > verifying especially your mails. That is, why I asked whether > something on your signatures may be a bit "special" > > Currently I have not the time to go much more in depth and can live > with the fact that in that moment much other stuff on this computer > tends to hang and the "easiest" way for now is to reboot... It is > possible that this behaviour came with one of the last MS > patchdays... I'm truly interested in receiving such log files to have a look into it myself, but the list may be interested as well. If there was really something "special" about (precisely) my signatures, as you say, I'd be eager to know, check and take appropriate measures. Whereas you can live with the fact. Cheers Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Sun Dec 11 21:52:03 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 11 Dec 2016 21:52:03 +0100 Subject: Implications of a common private keys directory in 2.1 In-Reply-To: <20161211195857.37447103200C@remailer.paranoici.org> References: <3b776db4-4161-35cc-31ac-b343b12edf7a@digitalbrains.com> <17f5cadc-c7fb-c43a-a141-5d269ab45eaa@digitalbrains.com> <20161204205923.ADB011031FF9@remailer.paranoici.org> <78b30a87-43a1-bb2b-d965-c65a8a1c5b27@digitalbrains.com> <20161211014830.B5635103200C@remailer.paranoici.org> <4c35d09f-f63e-1d82-05b3-fe491bd0d506@digitalbrains.com> <20161211195857.37447103200C@remailer.paranoici.org> Message-ID: On 11/12/16 20:58, Carola Grunwald wrote: > With 'problems' i referred to the GenKey bug/feature I reported a few > hours ago and the IPC instabilities I experienced. Sure, the > single-sec-keys-depository : multiple-pub-keyrings configuration is a > design decision, though one I don't quite understand. Oh, I thought you were referring to my warning that running the agent with lots of private keys might hit some unforeseen issues. > You mean --try-secret-key doesn't overrule the key parameter that comes > along with the encoded material? No, it specifies which keys to try for a hidden recipient. This is easy to investigate if you create a few test private keys and create some test messages. I did that earlier, and I could see no overruling behaviour or even a preference to --default-key or --try-secret-key. > With 1.4 I have a one-to-one sec:pub keyring relationship, where such > ambiguities don't matter, and where it's foreseeable what happens when I > delete a key pair from such a single keyring pair. This is comparable to a one-homedir-per-user setup in GnuPG v2.1. However, that means multiple agents. > User login/logoff represents in no way crypto task granularity, as a > user may hold several nym accounts and WME related addresses and so on. Okay, I don't really understand. In the POP3 usage scenarios I'm familiar with, the client downloads all new mail since last time it connected, and then disconnects. I get the feeling you do something different, and that's what is causing the confusion. > So the maintainer of the proxy is the owner, right? The owner of is the nym-a.com's operator, not the proxy. > I see that differently. The nym service consists of two parts, the proxy > represents the local non-anonymous one, the nym server is the remote > part in anonymity land, both separated but also joined by the > anonymizing message transfer cascade. Those parts can't do without each > other, only together they function correctly, which is why they have to > be seen as an indivisible unit. Surely you can use nym accounts without your proxy? Are you saying everybody who uses a nym service uses your proxy? I'd consider them an indivisible unit only if they are run by the same operator. So if you run both nym server and the proxy, then yes, it's one unit. But this seems rare: wouldn't it defeat the whole purpose of spreading the message over so many systems? You hold entry and end point, what is still anonymous about that? If the nym server is run by someone else than the proxy, that means there are two parties involved. You depend on the nym server operator to keep operating your account for you on that end, and on the proxy server operator to do the same on the other end. > Me as the proxy administrator? Well, the situation is similar to a GMail > administrator, who can also use any GMail account to send messages. He's > the admin, he's God. Yes, they are. This, most people will realise. That the proxy server operator is not only doing work on behalf of the user, but is actually acting as account holder on behalf of the user is something that I wouldn't think obvious. Any proxy server that sees cleartext passphrases can abuse that power. But normally, it is just a gateway passing passphrases. Your proxy is actually the one *having* the passphrase so to say, not the user. This is unusual and needs to be clearly communicated. That's all I'm advocating: clearly communicating to the user that they are not the holder of the nym account, but are only allowed to use it while the proxy holds it on their behalf. > I'm not sure what you mean by delay in a conversation vs. between > conversations. In my example, the client is forced to wait before the proxy will accept the message. This is a delay in a conversation. A delay between conversations would mean accepting the message without delay, closing the connection to the client, and then not sending on the message immediately. Only after a delay, open the conversation to the remailer. > Delay at the sender's LAN adds nothing to anonymity. First of all, you talked about a Tor hidden service earlier, not merely LANs. Secondly, if the message is signed at 12:00, but the message is only sent at 14:00, that means the signature time is no longer strongly linked to the time the message was sent. I believe this was your goal, rather than "adding mothing". It might not be the full day of difference you advocated earlier (data signatures one day earlier, key management operations two days earlier, you rougly said), but to dismiss it as nothing... > The possibly short proxy user's passphrase is different from the key's > passphrase, which is randomly created. Ah, so the proxy user can't enter a wrong passphrase for the signing key, which was my point. I don't see the use of a per-key or per-user passphrase at all, by the way. Just use a proxy-wide key or disk encryption. > Even the client-server interaction in a corporate LAN environment has to > be assumed secure. Again, I remember you mentioning Tor hidden services and TLS on client->proxy connections. > So key 'Creation-Date' (page 84) > > [...] > > a v1.4 and v2 'feature', is abusive as well? I see no 'testing only' > phrase in that explanation. That's an odd question, since you answered it so clearly, as I see it. There's no 'testing only' there, so why would it be abuse? It's abuse to use something that's clearly labeled as "for testing only" for something that is so adamantly not testing. >> To which I say: *it's not a feature*. > > It depends on what you're aiming at. "A feature" here meant: something that is supported by the program. If a program does not have a certain feature, it means that the program currently is not designed to do that. I'm saying GnuPG does not have a feature to fake signature times. It could be a worthy addition to its features, but it is not a feature that the current program has. 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 Sun Dec 11 22:21:20 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 11 Dec 2016 22:21:20 +0100 Subject: (OT) Hybrid keysigning party, your opinion? In-Reply-To: <75b17677-de90-ed2f-c03d-a6d507cc5d88@sixdemonbag.org> References: <6e4c97a3-de62-7ced-ba89-ad4fa9afbabc@mailbox.org> <630d4332-afb0-5f8b-acde-78961dd6abab@mailbox.org> <15922fc6-b6b9-34f1-7dd0-61427c7a2722@digitalbrains.com> <8a444fac-e669-d3da-c084-f63614b1697c@twopif.net> <702f7123-cb6f-98c0-aab3-b5711d4e0769@digitalbrains.com> <75b17677-de90-ed2f-c03d-a6d507cc5d88@sixdemonbag.org> Message-ID: <8300a967-9de8-6bc1-07ec-6d93f1750b3e@digitalbrains.com> On 11/12/16 21:37, Robert J. Hansen wrote: > Peter's correction was made in a spirit of utterly pedantic attention > to detail [a spirit I share!] Hah! Guilty as charged :-). 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 m.mansfeld at mansfeld-elektronik.de Mon Dec 12 00:41:47 2016 From: m.mansfeld at mansfeld-elektronik.de (Matthias Mansfeld) Date: Mon, 12 Dec 2016 00:41:47 +0100 Subject: Strange behaviour In-Reply-To: References: <584A0065.26179.994BF0@m.mansfeld.mansfeld-elektronik.de>, <584D30D4.6780.31D8371@m.mansfeld.mansfeld-elektronik.de>, Message-ID: <584DE43B.27007.37C2F1@m.mansfeld.mansfeld-elektronik.de> On 11 Dec 2016 at 20:43, Stephan Beck wrote: > I'm truly interested in receiving such log files to have a look > into it myself, but the list may be interested as well. If there was > really something "special" about (precisely) my signatures, as you > say, I'd be eager to know, check and take appropriate measures. > Whereas you can live with the fact. I will activate logging in PMail (in GPGRelay it is already running) and post it (as zipped attachment would be fine?... I just need to purge the passwords in the logfiles...). How can I start the most verbose logging from GnuPG itself (gpg.conf option?) Please let me a few days time for this stuff, because the GnuPG problem itself has currently no show-stopper priority (other stuff must be done.... some printed wired board layouts ready before Xmas, my main business...) Regards Matthias PS.: > Ah, and I'd urgently recommend to revoke (or have expired) at least > the 1024 bit subkey for encryption, as it's obsolete (for some years > now). OK, these keys are rather old... I think I prefer expire (.. a bit afraid of making some mistakes with revokation stuff and then messing up the whole keys....) The remainig subkey (2048 bit RSA) should be fine for encryption? -- OpenPGP: http://www.mansfeld-elektronik.de/gnupgkey/mansfeld.asc Fingerprint: 6563 057D E6B8 9105 1CE4 18D0 4056 1F54 8B59 40EF From caro at nymph.paranoici.org Mon Dec 12 04:06:55 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Mon, 12 Dec 2016 03:06:55 +0000 (UTC) Subject: Implications of a common private keys directory in 2.1 References: <17f5cadc-c7fb-c43a-a141-5d269ab45eaa@digitalbrains.com> <78b30a87-43a1-bb2b-d965-c65a8a1c5b27@digitalbrains.com> <20161211014830.B5635103200C@remailer.paranoici.org> <4c35d09f-f63e-1d82-05b3-fe491bd0d506@digitalbrains.com> <20161211195857.37447103200C@remailer.paranoici.org> Message-ID: <20161212030655.2A455103200C@remailer.paranoici.org> Peter Lebbing wrote: >On 11/12/16 20:58, Carola Grunwald wrote: >> With 'problems' i referred to the GenKey bug/feature I reported a few >> hours ago and the IPC instabilities I experienced. Sure, the >> single-sec-keys-depository : multiple-pub-keyrings configuration is a >> design decision, though one I don't quite understand. > >Oh, I thought you were referring to my warning that running the agent >with lots of private keys might hit some unforeseen issues. > >> You mean --try-secret-key doesn't overrule the key parameter that comes >> along with the encoded material? > >No, it specifies which keys to try for a hidden recipient. This is easy >to investigate if you create a few test private keys and create some >test messages. I did that earlier, and I could see no overruling >behaviour or even a preference to --default-key or --try-secret-key. You're right, unbelievable. I specify --try-secret-key with a [GNUPG:] ENC_TO 0000000000000000 18 0 message and gpg still tries out two dozen WME keys with a passphrase not valid for them. What a waste of time! Today I added symmetric dummy encodings to my application, performed in 5 minute intervals to keep gpg - agent IPC alive. So far no more 259/$103 GPG_ERR_ASS_CONNECT_FAILED (IPC connect call failed) errors. Let's see. I can't believe that I'm the only one who has to deal with such problems. > >> User login/logoff represents in no way crypto task granularity, as a >> user may hold several nym accounts and WME related addresses and so on. > >Okay, I don't really understand. In the POP3 usage scenarios I'm >familiar with, the client downloads all new mail since last time it >connected, and then disconnects. I get the feeling you do something >different, and that's what is causing the confusion. No confusion. The proxy server just assembles mail from different sources, which are a normal external POP3 account and a local repository of newsgroups, where nym replies are stored for being downloaded anonymously by the nym holder, e.g. alt.anonymous.messages. > >> So the maintainer of the proxy is the owner, right? > >The owner of is the nym-a.com's operator, not the proxy. > >> I see that differently. The nym service consists of two parts, the proxy >> represents the local non-anonymous one, the nym server is the remote >> part in anonymity land, both separated but also joined by the >> anonymizing message transfer cascade. Those parts can't do without each >> other, only together they function correctly, which is why they have to >> be seen as an indivisible unit. > >Surely you can use nym accounts without your proxy? Are you saying >everybody who uses a nym service uses your proxy? > >I'd consider them an indivisible unit only if they are run by the same >operator. So if you run both nym server and the proxy, then yes, it's >one unit. But this seems rare: wouldn't it defeat the whole purpose of >spreading the message over so many systems? You hold entry and end >point, what is still anonymous about that? > >If the nym server is run by someone else than the proxy, that means >there are two parties involved. You depend on the nym server operator to >keep operating your account for you on that end, and on the proxy server >operator to do the same on the other end. The nym server doesn't know who you are nor, with additional end-to-end encryption, will he know about the data you exchange. He can only cease his service for whatever reason, which doesn't mean any security risk. And there is the user, who is in complete control of the sending machinery. It's only about whom you see as the user. If it's an individual who acts on his own responsibility he has to deploy the proxy within his sphere of influence, e.g. on his computer side by side with the mail client. When it's a corporation on behalf of which the proxy is used it won't matter whether the corresponding employee and the proxy admin are different persons, as both are bound to the company's rules to act in concert. > >> Me as the proxy administrator? Well, the situation is similar to a GMail >> administrator, who can also use any GMail account to send messages. He's >> the admin, he's God. > >Yes, they are. This, most people will realise. > >That the proxy server operator is not only doing work on behalf of the >user, but is actually acting as account holder on behalf of the user is >something that I wouldn't think obvious. > >Any proxy server that sees cleartext passphrases can abuse that power. >But normally, it is just a gateway passing passphrases. Your proxy is >actually the one *having* the passphrase so to say, not the user. This >is unusual and needs to be clearly communicated. That's all I'm >advocating: clearly communicating to the user that they are not the >holder of the nym account, but are only allowed to use it while the >proxy holds it on their behalf. See my comments above about business rules. For a corporation it's important to centralize communication and to keep the ordinary user of its infrastructure from having access to crucial information like communication keys. > >> I'm not sure what you mean by delay in a conversation vs. between >> conversations. > >In my example, the client is forced to wait before the proxy will accept >the message. This is a delay in a conversation. > >A delay between conversations would mean accepting the message without >delay, closing the connection to the client, and then not sending on the >message immediately. Only after a delay, open the conversation to the >remailer. > >> Delay at the sender's LAN adds nothing to anonymity. > >First of all, you talked about a Tor hidden service earlier, not merely >LANs. I see no relevant difference between a client - proxy server connection within a LAN and through the Tor network to the proxy's .onion address. With some Tor cover traffic on the client and proxy side an adversary won't have a chance to detect the mail message transfer via the Tor network. > >Secondly, if the message is signed at 12:00, but the message is only >sent at 14:00, that means the signature time is no longer strongly >linked to the time the message was sent. I believe this was your goal, >rather than "adding mothing". It might not be the full day of difference >you advocated earlier (data signatures one day earlier, key management >operations two days earlier, you rougly said), but to dismiss it as >nothing... It's better than nothing. Nevertheless it's a compromise I see no reason for when otherwise there's a chance to manipulate the timestamp directly and avoid any latency between the client and the entry remailer(s). Btw, apart from regular remailer messages the proxy sends randomly dummy messages to invalid addresses to disguise true communication. > >> The possibly short proxy user's passphrase is different from the key's >> passphrase, which is randomly created. > >Ah, so the proxy user can't enter a wrong passphrase for the signing >key, which was my point. No. The proxy user logs i with jdoe:PaSsWoRd, the nym / WME key's true passphrase, stored at the proxy, looks like "8OSdA0cKTHrxtfJ7ii+s3VtssXtUf4w2x1wfXN75F+U". > >I don't see the use of a per-key or per-user passphrase at all, by the >way. Just use a proxy-wide key or disk encryption. ??? It's about the protection of data in transit, not about securing the proxy server. With compromized keys a single passphrase for different nyms is a solid proof for a similar origin. > >> Even the client-server interaction in a corporate LAN environment has to >> be assumed secure. > >Again, I remember you mentioning Tor hidden services and TLS on >client->proxy connections. TLS isn't very expensive, it's active here even with localhost connections. And connections to Tor hidden services at home can be seen as anonymous VPN connections, not much worse than true LAN connections. > >> So key 'Creation-Date' (page 84) >> >> [...] >> >> a v1.4 and v2 'feature', is abusive as well? I see no 'testing only' >> phrase in that explanation. > >That's an odd question, since you answered it so clearly, as I see it. >There's no 'testing only' there, so why would it be abuse? It's abuse to >use something that's clearly labeled as "for testing only" for something >that is so adamantly not testing. Don't get me wrong, but what I see here is the difference between enlightened thinking and servile obedience overinterpreting the wording. Tools have to serve purposes, and if they are imperfect in doing so they have to be adapted, at least as long as the author(s) have no objections to the given purpose, which here means anonymous communication. So I'll immediately shut up in case Werner says Internet anonymity is a bad thing. Kind regards Caro From lachlan at twopif.net Mon Dec 12 06:27:48 2016 From: lachlan at twopif.net (Lachlan Gunn) Date: Mon, 12 Dec 2016 15:57:48 +1030 Subject: Hybrid keysigning party, your opinion? In-Reply-To: <9df31ca9-2eb9-2680-f671-e77bf2c78166@digitalbrains.com> References: <6e4c97a3-de62-7ced-ba89-ad4fa9afbabc@mailbox.org> <9df31ca9-2eb9-2680-f671-e77bf2c78166@digitalbrains.com> Message-ID: Le 2016-12-12 ? 03:45, Peter Lebbing a ?crit : > My e-mail was 1424 words though, so I am afraid I ended up in your > wishful thinking area. > > The remaining 1607 words are in the sections "Background" and "Option > for advanced users", and those words happen to include the name Lachlan. > Go check it out! ;-P My apologies if I came across as overly harsh. What I meant was that it took me a little bit of time to work out exactly what you meant, so someone unfamilar with the web of trust will probably not follow exactly; it may just have been that I went through your email too late at night. Something along the lines of the following might make it more clear to everyone who is familiar with the hashed-list approach: Those who are in the advance list are certified in the usual way, and latecomers hand out keyslips in order to get themselves certified. If you are late you need to check when you get home that the names and serial numbers on the form that we gave out match those on the one whose hash is on the projector. But this is just me nitpicking about presentation. I think the idea is good, and falls into that wonderful category of things that are obvious in retrospect, but in need of someone clever to make the breakthrough without the benefit of hindsight. One last thought: This may be na?vely optimistic, but if everyone finishes at the same time then you can always do a second confirmation of the list-hash at the end for people who are late to the session. Or if you're into arts and crafts, give them a copy of the master hash on overhead transparency that they can use to very quickly check against someone else's. Thanks, Lachlan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From lachlan at twopif.net Mon Dec 12 06:35:37 2016 From: lachlan at twopif.net (Lachlan Gunn) Date: Mon, 12 Dec 2016 16:05:37 +1030 Subject: Recording keysigning attendants on phone (was: Hybrid keysigning party, your opinion?) In-Reply-To: <98dda355-d5d3-9d1e-371d-6f2d9b2a18e4@mailbox.org> References: <6e4c97a3-de62-7ced-ba89-ad4fa9afbabc@mailbox.org> <48876c1c-c029-0c53-dc60-59cba343d909@twopif.net> <98dda355-d5d3-9d1e-371d-6f2d9b2a18e4@mailbox.org> Message-ID: <43a55d73-4ead-7609-429d-39b06baa5cf9@twopif.net> Le 2016-12-08 ? 22:30, Stephan Beck a ?crit : > Yes, to your first question. How you would do that via the > hash-on-the-projector method, is not clear to me, though. Would that be > for generating the (initial) list of the organizers as in Sassaman > Efficient (as an additional service for people using cell phones or > tablets)? Or wouldn't there be any paper copy at the event? > Sorry, for questions that might seem obvious to you. Yes, sorry. There wouldn't be any paper copy, which might be a problem, unless you have a printer available to produce printed copies on demand which can be checked later. The idea is to allow people to add themselves to the list right up until the last minute, then someone cuts the ribbon, the system emails it to everyone and displays it on the projector, and they all follow either the standard Sassaman method or Peter's hybrid one. Thanks, Lachlan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From lachlan at twopif.net Mon Dec 12 07:02:08 2016 From: lachlan at twopif.net (Lachlan Gunn) Date: Mon, 12 Dec 2016 16:32:08 +1030 Subject: Hybrid keysigning party, your opinion? In-Reply-To: <9df31ca9-2eb9-2680-f671-e77bf2c78166@digitalbrains.com> References: <6e4c97a3-de62-7ced-ba89-ad4fa9afbabc@mailbox.org> <9df31ca9-2eb9-2680-f671-e77bf2c78166@digitalbrains.com> Message-ID: <29f73550-51e6-254d-ebba-0b816b6b3eb1@twopif.net> Le 2016-12-12 ? 03:45, Peter Lebbing a ?crit : > I really like this suggestion! I had to think about it for a while > before I could see a way to make it work. The trouble is that I want > caff to be able to process the file, and for that I need to keep it > having much of the same patterns. I ended up not significantly altering > the two files compared to what I proposed, but instead suggesting > everybody should use the scrubbed version. That way, the instructions > are the same for all participants. Also, while I promised to forever hold my peace, you might want to give people a a programmatic way to make the scrubbed list so that those who print their own don't need to manually verify it. This might add too much complexity, so I don't know whether it is worthwhile. Something like sed -re '/^(pub|\s+Key fingerprint).*$/d' scrubbed.txt is easy enough to verify by eye as not being a trick. The //d (rather than s///) is important because unless it makes the list shorter, there isn't any incentive to go to the trouble :) Thanks, Lachlan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From e.sovetkin at gmail.com Mon Dec 12 10:11:02 2016 From: e.sovetkin at gmail.com (Jenya Sovetkin) Date: Mon, 12 Dec 2016 10:11:02 +0100 Subject: gpg-agent, multiple requests Message-ID: <20161212091102.a6cg5fymk3aurqoc@albus> Hello everyone! recently I have encountered a problem with gpg-agent. When there are several simultaneous requests made for decryption, then gpg-agent "forgets" the passphrase and queries it again (for example when there are several cronjobs being invoked that require decryption). In other words, multiple simultaneous requests make cache entry invalid (ignoring --max-cache-ttl and --default-cache-ttl parameters). Here is the script kindly written by [@woodape](https://bbs.archlinux.org/viewtopic.php?pid=1675818#p1675818) which reproduces the behaviour #!/bin/bash echo "test" | gpg -e -r "$1" -o test.gpg for i in {1..8} ; do gpg -d test.gpg & done I am currently using version 2.1.16, however, the behaviour may have appeared a bit earlier. My question is whether this is a feature (lock access to a secret key during a decryption instance) or a bug? If this is a feature, then why the access to secret key should be locked during decryption, as for the secret key it is a read-only operation. Correct me if I wrong, but I haven't found any references to this feature in recent news/release notes or this mailing list discussions. Jenya -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From stebe at mailbox.org Mon Dec 12 12:38:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Mon, 12 Dec 2016 11:38:00 +0000 Subject: Strange behaviour In-Reply-To: <584DE43B.27007.37C2F1@m.mansfeld.mansfeld-elektronik.de> References: <584A0065.26179.994BF0@m.mansfeld.mansfeld-elektronik.de> <584D30D4.6780.31D8371@m.mansfeld.mansfeld-elektronik.de> <584DE43B.27007.37C2F1@m.mansfeld.mansfeld-elektronik.de> Message-ID: <10f1e455-f09d-fd41-313d-d533bc50d3ff@mailbox.org> Matthias Mansfeld: > On 11 Dec 2016 at 20:43, Stephan Beck wrote: > >> I'm truly interested in receiving such log files to have a look >> into it myself, but the list may be interested as well. If there was >> really something "special" about (precisely) my signatures, as you >> say, I'd be eager to know, check and take appropriate measures. >> Whereas you can live with the fact. > > I will activate logging in PMail (in GPGRelay it is already running) > and post it (as zipped attachment would be fine?... I just need to > purge the passwords in the logfiles...). > How can I start the most verbose logging from GnuPG itself (gpg.conf > option?) I am not working with gnupg 1.4.18 for Windows. Usually you would activate the debug flag, and, considering you most likely want to trace the communication protocol of gpg-agent with gnupg itself (and with other servers), which is the Assuan protocol, while verifying my signature, you might be able to use (at the Windows prompt) gpg --debug 1024 --verify mymessage.txt.sig mymessage.txt As in Windows, differing from UNIX-Systems, the communication is not made using pipes, this option in Windows should be automatically enabled and create the so-called temp-files. I've seen them added, though. Anyway, other Windows user might help you here. [QUOTE gnupg.info on --use-temp-files] This option forces GnuPG to use temporary files to communicate. On some platforms (such as Win32 and RISC OS), this option is always enabled. [QUOTE gnupg.info] I have a test installation with Windows7 and gpg4win (i.e. GnuPG 2.0.x), but not with GnuPG for Windows 1.4.18 stand-alone, so I unfortunately cannot reproduce your system's environment. I don't know (and haven't investigated) the special impact of gpgrelay on this either. When sending those log files, please send them as txt files within the body of a message sent to the list and in CC to me. > > Please let me a few days time for this stuff, because the GnuPG > problem itself has currently no show-stopper priority (other > stuff must be done.... some printed wired board layouts ready before > Xmas, my main business...) Are you kidding? Go ahead! I don't want to be responsible for someone not receiving his or her X-mas present in time. But, strictly speaking, up to now, we've only heard your observations and assumptions but have seen no proof or document sustaining what you are saying. > OK, these keys are rather old... I think I prefer expire (.. a bit > afraid of making some mistakes with revokation stuff and then messing > up the whole keys....) The remainig subkey (2048 bit RSA) should be > fine for encryption? It is a 2048 bit encryption sub key with no expiry date. sub 2048R/847E9FF0 created: 2002-10-18 expires: never usage: E You MIGHT consider having it expired as well, setting a decent expiry date (maybe, expiry within 2 or 3 years). Cheers Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Mon Dec 12 13:34:56 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 12 Dec 2016 13:34:56 +0100 Subject: Strange behaviour In-Reply-To: <10f1e455-f09d-fd41-313d-d533bc50d3ff@mailbox.org> References: <584A0065.26179.994BF0@m.mansfeld.mansfeld-elektronik.de> <584D30D4.6780.31D8371@m.mansfeld.mansfeld-elektronik.de> <584DE43B.27007.37C2F1@m.mansfeld.mansfeld-elektronik.de> <10f1e455-f09d-fd41-313d-d533bc50d3ff@mailbox.org> Message-ID: On 12/12/16 12:38, Stephan Beck wrote: > You MIGHT consider having it expired as well, setting a decent expiry > date (maybe, expiry within 2 or 3 years). No, I don't think that is good advice if given without a specific reason to do so. The expiry of a main key already establishes that others need to periodically refresh the key, which will mean changes propagate. There are reasons to use expiries on subkeys, but it is an expert option and should just be left alone without a specific reason. 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 stebe at mailbox.org Mon Dec 12 18:20:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Mon, 12 Dec 2016 17:20:00 +0000 Subject: Implications of a common private keys directory in 2.1 In-Reply-To: <20161212030655.2A455103200C@remailer.paranoici.org> References: <17f5cadc-c7fb-c43a-a141-5d269ab45eaa@digitalbrains.com> <78b30a87-43a1-bb2b-d965-c65a8a1c5b27@digitalbrains.com> <20161211014830.B5635103200C@remailer.paranoici.org> <4c35d09f-f63e-1d82-05b3-fe491bd0d506@digitalbrains.com> <20161211195857.37447103200C@remailer.paranoici.org> <20161212030655.2A455103200C@remailer.paranoici.org> Message-ID: <9cca136f-4ccf-7d45-3317-23de025825f5@mailbox.org> Carola Grunwald: > Peter Lebbing wrote: > >> On 11/12/16 20:58, Carola Grunwald wrote: >>> With 'problems' i referred to the GenKey bug/feature I reported a few >>> hours ago and the IPC instabilities I experienced. Sure, the >>> single-sec-keys-depository : multiple-pub-keyrings configuration is a >>> design decision, though one I don't quite understand. >> >> Oh, I thought you were referring to my warning that running the agent >> with lots of private keys might hit some unforeseen issues. >> >>> You mean --try-secret-key doesn't overrule the key parameter that comes >>> along with the encoded material? >> >> No, it specifies which keys to try for a hidden recipient. This is easy >> to investigate if you create a few test private keys and create some >> test messages. I did that earlier, and I could see no overruling >> behaviour or even a preference to --default-key or --try-secret-key. > > You're right, unbelievable. I specify --try-secret-key with a > > [GNUPG:] ENC_TO 0000000000000000 18 0 > > message and gpg still tries out two dozen WME keys with a passphrase not > valid for them. What a waste of time! If you knew the cacheIDs of all cached passphrases you could use "2.6.8 Remove a cached passphrase -------------------------------- Use this command to remove a cached passphrase. CLEAR_PASSPHRASE [--mode=normal] The '--mode=normal' option can be used to clear a CACHE_ID that was set by gpg-agent." for removing all passphrases but one (the one you would like to be used). If you'd want to make sure that the right passphrase is provided, why don't you use --pinentry-mode loopback "Use a loopback pinentry. This fakes a pinentry by using inquiries back to the caller to ask for a passphrase." Sorry, I can't reproduce your environment for now and only have these "dispersed notes" exposed here (but found your description of your system very instructive and largely followed it). I merely point you to options the usefulness of which you are more experienced to assess. Cheers Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From stebe at mailbox.org Mon Dec 12 19:00:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Mon, 12 Dec 2016 18:00:00 +0000 Subject: Recording keysigning attendants on phone In-Reply-To: <43a55d73-4ead-7609-429d-39b06baa5cf9@twopif.net> References: <6e4c97a3-de62-7ced-ba89-ad4fa9afbabc@mailbox.org> <48876c1c-c029-0c53-dc60-59cba343d909@twopif.net> <98dda355-d5d3-9d1e-371d-6f2d9b2a18e4@mailbox.org> <43a55d73-4ead-7609-429d-39b06baa5cf9@twopif.net> Message-ID: <5cd4e394-831f-b9b4-5adc-2c5501c46026@mailbox.org> Lachlan Gunn: > Le 2016-12-08 ? 22:30, Stephan Beck a ?crit : >> Yes, to your first question. How you would do that via the >> hash-on-the-projector method, is not clear to me, though. Would that be >> for generating the (initial) list of the organizers as in Sassaman >> Efficient (as an additional service for people using cell phones or >> tablets)? Or wouldn't there be any paper copy at the event? >> Sorry, for questions that might seem obvious to you. > > Yes, sorry. There wouldn't be any paper copy, which might be a problem, > unless you have a printer available to produce printed copies on demand > which can be checked later. > > The idea is to allow people to add themselves to the list right up until > the last minute, then someone cuts the ribbon, the system emails it to > everyone and displays it on the projector, and they all follow either > the standard Sassaman method or Peter's hybrid one. Thanks for the explanation, Lachlan. Ok, I see, preparations (required in the Sassaman Efficient keysigning event model), in your scheme, are done electronically right before the event starts, are they? Well, that may be fine for many people. Don't ask me why, but, personally, I'd always prefer an additional paper copy as a security measure. Cheers Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From stebe at mailbox.org Mon Dec 12 21:09:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Mon, 12 Dec 2016 20:09:00 +0000 Subject: Strange behaviour In-Reply-To: References: <584A0065.26179.994BF0@m.mansfeld.mansfeld-elektronik.de> <584D30D4.6780.31D8371@m.mansfeld.mansfeld-elektronik.de> <584DE43B.27007.37C2F1@m.mansfeld.mansfeld-elektronik.de> <10f1e455-f09d-fd41-313d-d533bc50d3ff@mailbox.org> Message-ID: Peter Lebbing: > On 12/12/16 12:38, Stephan Beck wrote: >> You MIGHT consider having it expired as well, setting a decent expiry >> date (maybe, expiry within 2 or 3 years). > > No, I don't think that is good advice if given without a specific reason > to do so. Well, the specific reason is that best practices exclude the usage of sub keys without any expiry. See the FSFE's instructions in the known Offline master key and multiple subkeys on smart card guide (or similar, don't have the link right now). > > The expiry of a main key already establishes that others need to > periodically refresh the key, which will mean changes propagate. Expiry of a main key? The OP holds a main key without expiry date. In such a case, I'd set an expiry date on subkeys. And I was talking about his subkeys, because the 1024 bit subkey caught my attention. > > There are reasons to use expiries on subkeys, but it is an expert option > and should just be left alone without a specific reason. On the other hand, given the fact that the OP's key has additional subkeys, he already used advanced user options. Cheers Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From sivmu at web.de Tue Dec 13 00:23:48 2016 From: sivmu at web.de (sivmu) Date: Tue, 13 Dec 2016 00:23:48 +0100 Subject: Smartcards and tokens Message-ID: <3abc5c59-3956-e16d-d430-4090ff9ce4c9@web.de> Hi, recently I came across the toptic of hardware tokens for pgp keys and I am thinking about getting one myself. From what I have found so far there are several candidates such as the Openpgp smartcard, Yubikey and Nitrokey USB tokens. One question remaining is what is the difference between the openpgp smartcard and the USB based tokens. Also how much would you trust those vendors and can the use of such tokens actually decrease security? Any advise would be welcome Regards, sivmu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From caro at nymph.paranoici.org Tue Dec 13 01:43:13 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Tue, 13 Dec 2016 00:43:13 +0000 (UTC) Subject: Implications of a common private keys directory in 2.1 References: <17f5cadc-c7fb-c43a-a141-5d269ab45eaa@digitalbrains.com> <78b30a87-43a1-bb2b-d965-c65a8a1c5b27@digitalbrains.com> <4c35d09f-f63e-1d82-05b3-fe491bd0d506@digitalbrains.com> <20161211195857.37447103200C@remailer.paranoici.org> <20161212030655.2A455103200C@remailer.paranoici.org> <9cca136f-4ccf-7d45-3317-23de025825f5@mailbox.org> Message-ID: <20161213004313.1264E10322B2@remailer.paranoici.org> Stephan Beck wrote: >Carola Grunwald: >> Peter Lebbing wrote: >>>> You mean --try-secret-key doesn't overrule the key parameter that comes >>>> along with the encoded material? >>> >>> No, it specifies which keys to try for a hidden recipient. This is easy >>> to investigate if you create a few test private keys and create some >>> test messages. I did that earlier, and I could see no overruling >>> behaviour or even a preference to --default-key or --try-secret-key. >> >> You're right, unbelievable. I specify --try-secret-key with a >> >> [GNUPG:] ENC_TO 0000000000000000 18 0 >> >> message and gpg still tries out two dozen WME keys with a passphrase not >> valid for them. What a waste of time! > >If you knew the cacheIDs of all cached passphrases you could use > >"2.6.8 Remove a cached passphrase >-------------------------------- > >Use this command to remove a cached passphrase. > > CLEAR_PASSPHRASE [--mode=normal] > > The '--mode=normal' option can be used to clear a CACHE_ID that was >set by gpg-agent." > >for removing all passphrases but one (the one you would like to be used). Removing all cached passphrases sounds great. But does that mean I have to invoke the agent directly using the Assuan protocol? And what would be the way to get a list of all valid cache_ids? > > >If you'd want to make sure that the right passphrase is provided, why >don't you use --pinentry-mode loopback >"Use a loopback pinentry. This fakes a pinentry by using > inquiries back to the caller to ask for a passphrase." That's what I actually do: | G:\MyGnuPG\gpg\gpg.exe --pinentry-mode loopback --no-default-recipient --no-default-keyring --keyring "G:\MyGnuPG\key\rcp.kbx" --status-fd 2 [...] --decrypt --command-fd 0 --try-secret-key F69A3C70E1A93A2A --passphrase "DNJwzwnRaUzhEr0Ys3XpnSY309DpXdk/Nu4f+sFPdQM" --output "G:\MyGnuPG\gpg\tmp\txt_clr.906" "G:\MyGnuPG\gpg\tmp\txt_enc.906" There's the id of a secret key with its passphrase, but if decoding doesn't succeed with that key-passphrase combination or if the key doesn't exist there are decryption attempts with all other secret keys in the private-keys-v1.d folder, which only waste time: | [GNUPG:] ENC_TO 0000000000000000 18 0 | [GNUPG:] KEY_CONSIDERED B5A49F253CE924DD2978A2C1F69A3C70E1A93A2A 0 <- the targeted one | [GNUPG:] KEY_CONSIDERED 5A2915D0E26A7FD3301A35D82F1E01D95F23CBA9 0 | [GNUPG:] KEY_CONSIDERED A2C2DA81C60217BA9FC60295F021F62304A579D2 0 | [GNUPG:] KEY_CONSIDERED ... AFAICS it always uses the same given passphrase with all the keys, which is good: | gpg: DBG: chan_0x0000009c <- INQUIRE PASSPHRASE | gpg: DBG: chan_0x0000009c -> D DNJwzwnRaUzhEr0Ys3XpnSY309DpXdk/Nu4f+sFPdQM What I need here is the restriction to just the given key. > > >Sorry, I can't reproduce your environment for now and only have these >"dispersed notes" exposed here (but found your description of your >system very instructive and largely followed it). I merely point you to >options the usefulness of which you are more experienced to assess. I appreciate every hint I can get on my way back to a fully operational stable system. :-) Many thanks and kind regards Caro From mstanichenko at gmail.com Tue Dec 13 10:12:39 2016 From: mstanichenko at gmail.com (Marat Stanichenko) Date: Tue, 13 Dec 2016 12:12:39 +0300 Subject: gpg2 export-secret-key if no master key present Message-ID: Hello, I created a master gpg key and an additional signing subkey. I also backed up the whole .gnupg directory to /my/save/place and deleted the primary key from the original .gnupg directory by simply removing the corresponding file under the private-keys-v1.d. So far so good, gpg2 -K shows a sec# instead of sec and gpg2 --homedir=/my/save/place -K shows sec as expected. However, if I run $ gpg2 --export-secret-keys --armor > secret-key and $ gpg2 --homedir=/my/save/place --export-secret-keys --armor > secret-key-original both commands return something of similar size. Although results are different. Could you please elaborate what exactly is returned in the former and the latter cases? What command one should run to get the private master key properly to save with paperkey afterwards? Many thanks in advance! From peter at digitalbrains.com Tue Dec 13 18:17:07 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 13 Dec 2016 18:17:07 +0100 Subject: Expiration of subkeys (was: Strange behaviour) In-Reply-To: References: <584A0065.26179.994BF0@m.mansfeld.mansfeld-elektronik.de> <584D30D4.6780.31D8371@m.mansfeld.mansfeld-elektronik.de> <584DE43B.27007.37C2F1@m.mansfeld.mansfeld-elektronik.de> <10f1e455-f09d-fd41-313d-d533bc50d3ff@mailbox.org> Message-ID: <9b33646a-4f5d-8fcf-c255-c0bbc6873562@digitalbrains.com> On 12/12/16 21:09, Stephan Beck wrote: > Well, the specific reason is that best practices exclude the usage of > sub keys without any expiry. There's nothing inherently wrong with non-expiring subkeys. Without knowing the threat model, I don't see a reason to either start using expiring subkeys *or* stop using them. Coincidentally, expiration of subkeys by default was just discussed on gnupg-devel; you might be interested in that little thread: [1]. If you want to read the whole thread[2], not just this subthread, note that Robert J. Hansen's contribution[3] went to gnupg-users instead of gnupg-devel. I recommend reading Robert's message anyway, since it also deals with the whole concept of "best practices" in general. It's a good post and apt here as well. > See the FSFE's instructions in the known > Offline master key and multiple subkeys on smart card guide (or similar, > don't have the link right now). When I did a quick look-see, I found that their recommended Card HOWTO[4] actually creates a non-expiring key. I don't know which intended public the FSFE's instructions have, or what threat models they considered. > The OP holds a main key without expiry date. In > such a case, I'd set an expiry date on subkeys. I'd set an expiry on the main key, or trust the OP to guard his revocation certificate well (in the sense of not losing it). HTH, Peter. [1] https://lists.gnupg.org/pipermail/gnupg-devel/2016-December/032328.html [2] https://lists.gnupg.org/pipermail/gnupg-devel/2016-December/032298.html [3] https://lists.gnupg.org/pipermail/gnupg-users/2016-December/057229.html [4] http://wiki.fsfe.org/TechDocs/CardHowtos/CardWithSubkeysUsingBackups -- 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 Tue Dec 13 18:56:07 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 13 Dec 2016 18:56:07 +0100 Subject: Hybrid keysigning party, your opinion? In-Reply-To: <29f73550-51e6-254d-ebba-0b816b6b3eb1@twopif.net> References: <6e4c97a3-de62-7ced-ba89-ad4fa9afbabc@mailbox.org> <9df31ca9-2eb9-2680-f671-e77bf2c78166@digitalbrains.com> <29f73550-51e6-254d-ebba-0b816b6b3eb1@twopif.net> Message-ID: <69364141-95c6-73c5-ad0a-e7d9ebd52f13@digitalbrains.com> On 12/12/16 07:02, Lachlan Gunn wrote: > Also, while I promised to forever hold my peace, you might want to give > people a a programmatic way to make the scrubbed list so that those who > print their own don't need to manually verify it. If they want to have a known good copy, they can just print the detailed list! They then also have the opportunity to have gpgsigs annotate it with the signatures they already did at an earlier keysigning party, saving them the trouble of re-identifying someone for nothing. (Note that not all people consider this "for nothing", some actually like to have a new signature). > The //d (rather > than s///) is important because unless it makes the list shorter, there > isn't any incentive to go to the trouble :) I chose to replace them by empty lines so the lists still line up if you choose the screen font to be a similar size as the printed font. I will be literally holding my paper list next to my monitor, it's useful if they line up and all information that is the same looks exactly the same. You spot errors much quicker that way. Thanks for your thoughts, 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 Tue Dec 13 19:04:52 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 13 Dec 2016 19:04:52 +0100 Subject: Hybrid keysigning party, your opinion? In-Reply-To: References: <6e4c97a3-de62-7ced-ba89-ad4fa9afbabc@mailbox.org> <9df31ca9-2eb9-2680-f671-e77bf2c78166@digitalbrains.com> Message-ID: <9329b1b8-d33b-1a25-69cc-4205752e6ce5@digitalbrains.com> On 12/12/16 06:27, Lachlan Gunn wrote: > My apologies if I came across as overly harsh. Oh, not at all, I hadn't even noticed one could see it that way. . What I meant was that it > took me a little bit of time to work out exactly what you meant, so > someone unfamilar with the web of trust will probably not follow > exactly; This was a mail to a crypto-mailing list asking cryppies for advice on how to cripple... er... subvert a certain setup. Totally different audience! > One last thought: This may be na?vely optimistic, but if everyone > finishes at the same time then you can always do a second confirmation > of the list-hash at the end for people who are late to the session. Hmm, interesting idea. Could be possible. > Or > if you're into arts and crafts, give them a copy of the master hash on > overhead transparency that they can use to very quickly check against > someone else's. Or hang a truly huge printout on the wall and at the start of the session, together observe that it is correct. Any latecomers can be told "look, everybody thinks it's completely normal that we have a 64 digit hex code on the wall, and that's because we all agreed it's the right one". 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 peter at digitalbrains.com Tue Dec 13 19:20:40 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 13 Dec 2016 19:20:40 +0100 Subject: An attempt at backporting 2.1.16 from Debian sid to Debian jessie In-Reply-To: <7dfd50b5-6f6e-2ce0-7cf9-78345204ccde@mailbox.org> References: <0d7e39f9-d26e-6fee-1898-55000aeb807e@digitalbrains.com> <87fulyl3pn.fsf@iki.fi> <7dfd50b5-6f6e-2ce0-7cf9-78345204ccde@mailbox.org> Message-ID: On 08/12/16 21:42, Stephan Beck wrote: > [...], so I don't see the real need for a forced coexistence of the two > (or three) versions on Jessie. I did that because all the software in jessie that depends on GnuPG 1.4 might not work with GnuPG 2.1. So by doing it like this, I'm not breaking any packages that have the package "gnupg" in their dependency tree. 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 dgouttegattat at incenp.org Tue Dec 13 18:15:08 2016 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Tue, 13 Dec 2016 18:15:08 +0100 Subject: gpg2 export-secret-key if no master key present In-Reply-To: References: Message-ID: On 12/13/2016 10:12 AM, Marat Stanichenko wrote: Hello, > Could you please elaborate what exactly is returned in the former and > the latter cases? In the former case (in the absence of the secret primary key), the --export-secret-keys command will still export a secret packet key corresponding to the missing key, but it will be marked as a "dummy key". Try running the following command: $ gpg2 --list-packets secret-key You should see (among other things) something like the following: :secret key packet: version 4 [...] pkey[0]: [xxxx bits] pkey[1]: [xxxx bits] gnu-dummy S2K, algo: 0, simple checksum, hash: 0 The "gnu-dummy S2K" is the marker which will tell GnuPG that this file does *not* actually contain the secret key. > What command one should run to get the private master key properly to > save with paperkey afterwards? I would just use $ gpg2 --homedir=/my/save/place --export-secret-keys | paperkey | lpr (the last command "| lpr" would send the output directly to the printer). This would export both the primary key and all the subkeys. If you want to save with paperkey only the primary key, specify its ID and append a '!' at the end: $ gpg2 --homedir=/my/save/place --export-secret-keys '0xABCDEF10!' \ | paperkey | lpr Hope that helps, Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From mstanichenko at gmail.com Wed Dec 14 14:37:02 2016 From: mstanichenko at gmail.com (Marat Stanichenko) Date: Wed, 14 Dec 2016 16:37:02 +0300 Subject: gpg2 export-secret-key if no master key present In-Reply-To: References: Message-ID: Hello, > Hope that helps Definitely, that answers my question completely. Thank you very much, Marat From 8104woodvale at gmail.com Wed Dec 14 22:41:09 2016 From: 8104woodvale at gmail.com (Mark Maxwell) Date: Wed, 14 Dec 2016 15:41:09 -0600 Subject: Ubuntu Version, Desktop Interface, and GUI Question(s) Message-ID: Any suggestions on which ubuntu version (trusty, xenial, etc . . . ) to install (chroot) for using GnuPG? And which desktop interface (xfce4, lxde, gnome, etc . . .) to go with? And finally -- what about a GUI frontend (Seahorse, Kleopatra, etc . . . ) to use. HP Chromebook 14 G4, preparing to re-re-re-reinstall linux. I've used (tried to use) both the precise version and xenial version. Both versions with the xfce4 desktop. No joy thus far with Kleopaatra nor Seahorse. Back to a fresh powerwash and gearing up for another butt-whooping. OBTW -- Kleopatra works well for me on a Windows box. Maybe I should just warm up to not using a GUI and learning command lines? -------------- next part -------------- An HTML attachment was scrubbed... URL: From gniibe at fsij.org Thu Dec 15 02:35:04 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 15 Dec 2016 10:35:04 +0900 Subject: Smartcards and tokens In-Reply-To: <3abc5c59-3956-e16d-d430-4090ff9ce4c9@web.de> References: <3abc5c59-3956-e16d-d430-4090ff9ce4c9@web.de> Message-ID: <877f72gek7.fsf@iwagami.gniibe.org> sivmu wrote: > One question remaining is what is the difference between the openpgp > smartcard and the USB based tokens. I think that the OpenPGP card (the physical smartcard) is included in Nitrokey Pro USB Token. So, it's exactly same from the view point of smartcard. When you want to use a smartcard, you need a card reader to access the card. And the card reader you use would bring another attack vectors. In this point, Nitrokey Pro USB Token is the best approach, I suppose. IIUC, Yubikey products are JavaCard implementations and somehow emulate OpenPGP card protocol by "app", and they work as CCID card reader + OpenPGP card. In Nitrokey Start USB Token, there is no OpenPGP card physically, but it is implemented by Gnuk, the software. > Also how much would you trust those vendors and can the use of such > tokens actually decrease security? This is the point. The hardware OpenPGP card in Nitrokey Pro USB Token could be replaced by man in the middle (or its vendor). The hardware MCU chip in Nitrokey Start USB Token could be replaced, too. The software (Gnuk) in Nitrokey Start USB Token could be replaced (with JTAG/SWD debugger), too. Or, we should consider possibility of backdoor of OpenPGP card. Well, I don't know about Yubikey. When it is replaced to be malicious one to enable an access by others (to your private keys), or it already has a backdoor in the first place, it kills the purpose of USB security token. Here, the question is: how can we build up such a "trust"? It seems for me that there are two different approaches; (1) physical difficulty (for example, plastic molding for "protection"), (2) reproducibility and transparency/openness. Note that some method of former makes latter difficult. For myself, I take (2), and I did my best to make my product as reproducible. (Since I don't manufacture semiconductor things, reproducibility is not 100%, and this part of manufacturing and technology is not open at all.) And I intentionally deliver my product in a style of "transparent" or "open". Distribution channel is also difficult. I do in person, and I ask FSF for my TRNG. Are there any good method? Obvious drawback of the apporoach (2) is that people with enough concern/attention have tendency to do it under their control. Reasonable. Since it's reproducible (somehow), it's possible, by definition. And then, I can't sell many. -- From rjh at sixdemonbag.org Thu Dec 15 04:59:39 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 14 Dec 2016 22:59:39 -0500 Subject: Ubuntu Version, Desktop Interface, and GUI Question(s) In-Reply-To: References: Message-ID: > Any suggestions on which ubuntu version (trusty, xenial, etc . . . ) to > install (chroot) for using GnuPG? The latest version. > And which desktop interface (xfce4, lxde, gnome, etc . . .) to go with? Whatever the default for your Ubuntu version is. > And finally -- what about a GUI frontend (Seahorse, Kleopatra, etc . . . > ) to use. GPA or the Enigmail key manager come to mind. > Maybe I should just warm up to not using a GUI and learning command lines? Probably wise. ;) From lewisurn at gmail.com Thu Dec 15 08:34:20 2016 From: lewisurn at gmail.com (Lou Wynn) Date: Wed, 14 Dec 2016 23:34:20 -0800 Subject: Smartcards and tokens In-Reply-To: <877f72gek7.fsf@iwagami.gniibe.org> References: <3abc5c59-3956-e16d-d430-4090ff9ce4c9@web.de> <877f72gek7.fsf@iwagami.gniibe.org> Message-ID: <8c35f02a-6f56-b5ee-1309-2b245cda5a57@gmail.com> I've come cross a simple and secure approach at this post: http://zacharyvoase.com/2009/08/20/openpgp/ In the MAKING BACKUPS section, this method simply places your gnupg directory in an encrypted usb drive and make a symlink to it like this: ln -s /Volumes/EncDrive/gnupg ~/.gnupg That's all. As long as you use a good passphrase, this is very secure method to me. When you unplug the USB, your keys are gone. If your USB drive is lost, its content is encrypted by your passphrase, so no worry about it. On 12/14/2016 05:35 PM, NIIBE Yutaka wrote: > sivmu wrote: >> One question remaining is what is the difference between the openpgp >> smartcard and the USB based tokens. > I think that the OpenPGP card (the physical smartcard) is included in > Nitrokey Pro USB Token. So, it's exactly same from the view point of > smartcard. > > When you want to use a smartcard, you need a card reader to access the > card. And the card reader you use would bring another attack vectors. > In this point, Nitrokey Pro USB Token is the best approach, I suppose. > > IIUC, Yubikey products are JavaCard implementations and somehow emulate > OpenPGP card protocol by "app", and they work as CCID card reader + > OpenPGP card. > > In Nitrokey Start USB Token, there is no OpenPGP card physically, but it > is implemented by Gnuk, the software. > >> Also how much would you trust those vendors and can the use of such >> tokens actually decrease security? > This is the point. > > The hardware OpenPGP card in Nitrokey Pro USB Token could be replaced by > man in the middle (or its vendor). The hardware MCU chip in Nitrokey > Start USB Token could be replaced, too. The software (Gnuk) in Nitrokey > Start USB Token could be replaced (with JTAG/SWD debugger), too. Or, we > should consider possibility of backdoor of OpenPGP card. Well, I don't > know about Yubikey. > > When it is replaced to be malicious one to enable an access by others > (to your private keys), or it already has a backdoor in the first place, > it kills the purpose of USB security token. > > Here, the question is: how can we build up such a "trust"? > > It seems for me that there are two different approaches; (1) physical > difficulty (for example, plastic molding for "protection"), (2) > reproducibility and transparency/openness. Note that some method of > former makes latter difficult. > > > For myself, I take (2), and I did my best to make my product as > reproducible. (Since I don't manufacture semiconductor things, > reproducibility is not 100%, and this part of manufacturing and > technology is not open at all.) And I intentionally deliver my product > in a style of "transparent" or "open". > > Distribution channel is also difficult. I do in person, and I ask FSF > for my TRNG. Are there any good method? > > Obvious drawback of the apporoach (2) is that people with enough > concern/attention have tendency to do it under their control. > Reasonable. Since it's reproducible (somehow), it's possible, by > definition. And then, I can't sell many. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gpg at rmf.io Thu Dec 15 10:24:29 2016 From: gpg at rmf.io (R. Martinho Fernandes) Date: Thu, 15 Dec 2016 10:24:29 +0100 Subject: Smartcards and tokens In-Reply-To: <8c35f02a-6f56-b5ee-1309-2b245cda5a57@gmail.com> References: <3abc5c59-3956-e16d-d430-4090ff9ce4c9@web.de> <877f72gek7.fsf@iwagami.gniibe.org> <8c35f02a-6f56-b5ee-1309-2b245cda5a57@gmail.com> Message-ID: <1481793869.354345.819785617.795947AE@webmail.messagingengine.com> There's an important distinction to be made between using this approach and using a SmartCard. The encrypted USB drive approach leaks the keys into the machine you're using it from; they're accessible by simply reading the filesystem (thus the claim that "When you unplug the USB, your keys are gone." is wrong). The keys in a SmartCard are write-only; the SmartCard performs all the encryption on-chip. You need to have an attack on the SmartCard to get the keys, while with the USB drive approach, you just need to attack the host machine. On Thu, Dec 15, 2016, at 08:34 AM, Lou Wynn wrote: > I've come cross a simple and secure approach at this post: > http://zacharyvoase.com/2009/08/20/openpgp/ > In the MAKING BACKUPS section, this method simply places your > gnupg directory in an encrypted usb drive and make a symlink to it > like this: > ln -s /Volumes/EncDrive/gnupg ~/.gnupg > > That's all. As long as you use a good passphrase, this is very secure > method to me. When you unplug the USB, your keys are gone. If your USB > drive is lost, its content is encrypted by your passphrase, so no > worry about it. > > > > > On 12/14/2016 05:35 PM, NIIBE Yutaka wrote: >> sivmu wrote: >> >>> One question remaining is what is the difference between the openpgp >>> smartcard and the USB based tokens. >>> >> I think that the OpenPGP card (the physical smartcard) is included in >> Nitrokey Pro USB Token. So, it's exactly same from the view point of >> smartcard. When you want to use a smartcard, you need a card reader >> to access the card. And the card reader you use would bring another >> attack vectors. In this point, Nitrokey Pro USB Token is the best >> approach, I suppose. IIUC, Yubikey products are JavaCard >> implementations and somehow emulate OpenPGP card protocol by "app", >> and they work as CCID card reader + OpenPGP card. In Nitrokey Start >> USB Token, there is no OpenPGP card physically, but it is implemented >> by Gnuk, the software. >> >>> Also how much would you trust those vendors and can the use of such >>> tokens actually decrease security? >>> >> This is the point. The hardware OpenPGP card in Nitrokey Pro USB >> Token could be replaced by man in the middle (or its vendor). The >> hardware MCU chip in Nitrokey Start USB Token could be replaced, too. >> The software (Gnuk) in Nitrokey Start USB Token could be replaced >> (with JTAG/SWD debugger), too. Or, we should consider possibility of >> backdoor of OpenPGP card. Well, I don't know about Yubikey. When it >> is replaced to be malicious one to enable an access by others (to >> your private keys), or it already has a backdoor in the first place, >> it kills the purpose of USB security token. Here, the question is: >> how can we build up such a "trust"? It seems for me that there are >> two different approaches; (1) physical difficulty (for example, >> plastic molding for "protection"), (2) reproducibility and >> transparency/openness. Note that some method of former makes latter >> difficult. For myself, I take (2), and I did my best to make my >> product as reproducible. (Since I don't manufacture semiconductor >> things, reproducibility is not 100%, and this part of manufacturing >> and technology is not open at all.) And I intentionally deliver my >> product in a style of "transparent" or "open". Distribution channel >> is also difficult. I do in person, and I ask FSF for my TRNG. Are >> there any good method? Obvious drawback of the apporoach (2) is that >> people with enough concern/attention have tendency to do it under >> their control. Reasonable. Since it's reproducible (somehow), it's >> possible, by definition. And then, I can't sell many. >> > > _________________________________________________ > 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 wk at gnupg.org Thu Dec 15 10:46:00 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 15 Dec 2016 10:46:00 +0100 Subject: [Announce] Libgcrypt 1.7.5 released Message-ID: <87mvfx7cfb.fsf@wheatstone.g10code.de> Hi! The GnuPG Project is pleased to announce the availability of Libgcrypt version 1.7.5. This is a maintenace release. Libgcrypt is a general purpose library of cryptographic building blocks. It is originally based on code used by GnuPG. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required to use Libgcrypt. Noteworthy changes in version 1.7.5 (2016-12-15) ------------------------------------------------ * Bug fixes: - Fix regression in mlock detection introduced with 1.7.4 [bug#2870]. Noteworthy changes in version 1.7.4 (2016-12-09) ------------------------------------------------ * Performance: - More ARMv8/AArch32 improvements for AES, GCM, SHA-256, and SHA-1. - Add ARMv8/AArch32 assembly implementation for Twofish and Camellia. - Add bulk processing implementation for ARMv8/AArch32. - Add Stribog OIDs. - Improve the DRBG performance and sync the code with the Linux version. * Internal changes: - When secure memory is requested by the MPI functions or by gcry_xmalloc_secure, they do not anymore lead to a fatal error if the secure memory pool is used up. Instead new pools are allocated as needed. These new pools are not protected against being swapped out (mlock can't be used). However, these days this is considered a minor issue and can easily be mitigated by using encrypted swap space. * Bug fixes: - Fix GOST 28147 CryptoPro-B S-box. - Fix error code handling of mlock calls. Download ======== Source code is hosted at the GnuPG FTP server and its mirrors as listed at https://gnupg.org/download/mirrors.html . On the primary server the source tarball and its digital signature are: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.5.tar.bz2 (2816k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.5.tar.bz2.sig That file is bzip2 compressed. A gzip compressed version is here: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.5.tar.gz (3365k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.5.tar.gz.sig The same files are also available via HTTP: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.5.tar.bz2 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.5.tar.bz2.sig https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.5.tar.gz https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.5.tar.gz.sig In order to check that the version of Libgcrypt you downloaded is an original and unmodified file please follow the instructions found at . In short, you may use one of the following methods: - Check the supplied OpenPGP signature. For example to check the signature of the file libgcrypt-1.7.5.tar.bz2 you would use this command: gpg --verify libgcrypt-1.7.5.tar.bz2.sig libgcrypt-1.7.5.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 the end of this mail 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 libgcrypt-1.7.5.tar.bz2, you run the command like this: sha1sum libgcrypt-1.7.5.tar.bz2 and check that the output matches the first line from the this list: fa485d854748fc06ea041b3057b2de2f12fbc17f libgcrypt-1.7.5.tar.bz2 9dc6171c0d6b46a7bc38e4af65091044633dc59a libgcrypt-1.7.5.tar.gz You should also verify that the checksums above are authentic by matching them with copies of this announcement. Those copies can be found at other mailing lists, web sites, and search engines. Copying ======= Libgcrypt is distributed under the terms of the GNU Lesser General Public License (LGPLv2.1+). The helper programs as well as the documentation are distributed under the terms of the GNU General Public License (GPLv2+). The file LICENSES has notices about contributions that require that these additional notices are distributed. Support ======= For help on developing with Libgcrypt you should read the included manual and optional ask on the gcrypt-devel mailing list [1]. A listing with commercial support offers for Libgcrypt and related software is available at the GnuPG web site [2]. If you are a developer and you may need a certain feature for your project, please do not hesitate to bring it to the gcrypt-devel mailing list for discussion. Maintenance and development of Libgcrypt is mostly financed by donations; see . We currently employ 3 full-time developers, one part-timer, and one contractor to work on GnuPG and closely related software like Libgcrypt. Thanks ====== We like to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Also many thanks to all our donors [3]. For the GnuPG hackers, Werner [1] https://lists.gnupg.org/mailman/listinfo/gcrypt-devel [2] https://www.gnupg.org/service.html [3] https://gnupg.org/donate/kudos.html p.s. This is an announcement only mailing list. Please send replies only to the gcrypt-devel 'at' gnupg.org mailing list. p.p.s List of 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: 2020-10-30] 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. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 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 tokktokk at riseup.net Thu Dec 15 12:03:11 2016 From: tokktokk at riseup.net (unknown) Date: Thu, 15 Dec 2016 12:03:11 +0100 Subject: Changing comment in userID Message-ID: <83efcdb1-7861-3eda-2ae9-2df3cf5ad751@riseup.net> Hi, i've made a keypair with a comment in the userID. Is it possible to delete this part of the key or do I have completely delete the key and make a new one? I also uploaded it to the sks keyserver. What effect will it have on the keyserver? Thanks. From e.sovetkin at gmail.com Thu Dec 15 12:46:41 2016 From: e.sovetkin at gmail.com (Evgenii Sovetkin) Date: Thu, 15 Dec 2016 12:46:41 +0100 Subject: Changing comment in userID In-Reply-To: <83efcdb1-7861-3eda-2ae9-2df3cf5ad751@riseup.net> References: <83efcdb1-7861-3eda-2ae9-2df3cf5ad751@riseup.net> Message-ID: <20161215114641.5wurcbxjhpgqcfln@albus> > i've made a keypair with a comment in the userID. Is it possible to > delete this part of the key or do I have completely delete the key and > make a new one? > I also uploaded it to the sks keyserver. What effect will it have on the > keyserver? You can simply edit key. and upload it again without deleting it... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From gniibe at fsij.org Thu Dec 15 12:58:39 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 15 Dec 2016 20:58:39 +0900 Subject: Changing comment in userID In-Reply-To: <83efcdb1-7861-3eda-2ae9-2df3cf5ad751@riseup.net> References: <83efcdb1-7861-3eda-2ae9-2df3cf5ad751@riseup.net> Message-ID: <635cc0ff-fd14-b9d6-1074-0bed3418b0b6@fsij.org> On 12/15/2016 08:03 PM, unknown wrote: > i've made a keypair with a comment in the userID. Is it possible to > delete this part of the key or do I have completely delete the key and > make a new one? > I also uploaded it to the sks keyserver. What effect will it have on the > keyserver? Please note that modifying user ID (even if it's a comment in user ID) makes different user ID. And when people certify your key, signature is about user ID. You don't need to create new key. You can add new user ID to existing key by: gpg --edit-key YOUR-KEY and "adduid" sub command. You can also revoke an old user ID by "revuid" sub command, if you want. Then, you can upload updated key to keyserver. There is also "deluid" sub command but it only affects key on your PC, since keyservers never support deletion of record. You need to get your user ID certified again. Thus, it would be simpler starting with new key with new user ID. -- From tokktokk at riseup.net Thu Dec 15 14:05:19 2016 From: tokktokk at riseup.net (unknown) Date: Thu, 15 Dec 2016 14:05:19 +0100 Subject: Upgrade to gpg2 Message-ID: <007d3416-6c14-f51a-39eb-479863e356fa@riseup.net> Hi, i'm running Mint with gpg 1.4 I'd like to upgrade to the newer version of gnupg. Do I have to delete the old one? What about my configuration file, is this only for the older version? I don't know how to build from the source. Greetings. From fmv1992 at gmail.com Thu Dec 15 13:05:42 2016 From: fmv1992 at gmail.com (Felipe Vieira) Date: Thu, 15 Dec 2016 10:05:42 -0200 Subject: Fwd: tar, compress, split and then encrypt a list of files In-Reply-To: References: Message-ID: Dear mailing list, right now I have a working workstream that gets paths from a text file and: tar -> compress -> encrypt -> split (over each line/entry) Probably there is a security issue here as some of the paths are dozens of gigabytes in size. I would like to swap the 'encrypt -> split' part but I'm unable to do so using the GNU split functionality. Writing to disk then opening the split files is a big performance hit. Can I accomplish this in a single step? (installing/using other tools is not a problem) Best regards, Felipe (not signed/sent from public computer) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Thu Dec 15 17:39:16 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 15 Dec 2016 11:39:16 -0500 Subject: Upgrade to gpg2 In-Reply-To: <007d3416-6c14-f51a-39eb-479863e356fa@riseup.net> References: <007d3416-6c14-f51a-39eb-479863e356fa@riseup.net> Message-ID: <179317fa-e3c2-b73b-86d3-fad135d32241@sixdemonbag.org> > Do I have to delete the old one? No. > What about my configuration file, is this only for the > older version? Most older configuration files will work just fine with GnuPG 2.0 and 2.1. >From the Mint command line: sudo apt-get install gnupg2 It'll install GnuPG 2.0 (2.1 in Sarah) and you'll be ready to go. From lewisurn at gmail.com Thu Dec 15 20:24:07 2016 From: lewisurn at gmail.com (Lou Wynn) Date: Thu, 15 Dec 2016 11:24:07 -0800 Subject: Smartcards and tokens In-Reply-To: <1481793869.354345.819785617.795947AE@webmail.messagingengine.com> References: <3abc5c59-3956-e16d-d430-4090ff9ce4c9@web.de> <877f72gek7.fsf@iwagami.gniibe.org> <8c35f02a-6f56-b5ee-1309-2b245cda5a57@gmail.com> <1481793869.354345.819785617.795947AE@webmail.messagingengine.com> Message-ID: <3707f9e0-3ac7-851f-4dbb-79ea600d8541@gmail.com> If the host machine is compromised, what's the purpose of doing encryption on the SmartCard? Attackers don't need to know the key to get your plaint ext, because it is on the host machine. I guess that what you meant was signing, using a SmartCard to sign has the benefits you mentioned, but not encryption. On 12/15/2016 01:24 AM, R. Martinho Fernandes wrote: > There's an important distinction to be made between using this > approach and using a SmartCard. The encrypted USB drive approach leaks > the keys into the machine you're using it from; they're accessible by > simply reading the filesystem (thus the claim that "When you unplug > the USB, your keys are gone." is wrong). The keys in a SmartCard are > write-only; the SmartCard performs all the encryption on-chip. > > You need to have an attack on the SmartCard to get the keys, while > with the USB drive approach, you just need to attack the host machine. > > > On Thu, Dec 15, 2016, at 08:34 AM, Lou Wynn wrote: >> >> I've come cross a simple and secure approach at this post: >> >> http://zacharyvoase.com/2009/08/20/openpgp/ >> >> In the MAKING BACKUPS section, this method simply places your gnupg >> directory in an encrypted usb drive and make a symlink to it like this: >> >> ln -s /Volumes/EncDrive/gnupg ~/.gnupg >> >> That's all. As long as you use a good passphrase, this is very secure >> method to me. When you unplug the USB, your keys are gone. If your >> USB drive is lost, its content is encrypted by your passphrase, so no >> worry about it. >> >> >> >> >> On 12/14/2016 05:35 PM, NIIBE Yutaka wrote: >>> sivmu wrote: >>> >>>> One question remaining is what is the difference between the openpgp >>>> smartcard and the USB based tokens. >>>> >>> I think that the OpenPGP card (the physical smartcard) is included in >>> Nitrokey Pro USB Token. So, it's exactly same from the view point of >>> smartcard. >>> >>> When you want to use a smartcard, you need a card reader to access the >>> card. And the card reader you use would bring another attack vectors. >>> In this point, Nitrokey Pro USB Token is the best approach, I suppose. >>> >>> IIUC, Yubikey products are JavaCard implementations and somehow emulate >>> OpenPGP card protocol by "app", and they work as CCID card reader + >>> OpenPGP card. >>> >>> In Nitrokey Start USB Token, there is no OpenPGP card physically, but it >>> is implemented by Gnuk, the software. >>> >>> >>>> Also how much would you trust those vendors and can the use of such >>>> tokens actually decrease security? >>>> >>> This is the point. >>> >>> The hardware OpenPGP card in Nitrokey Pro USB Token could be replaced by >>> man in the middle (or its vendor). The hardware MCU chip in Nitrokey >>> Start USB Token could be replaced, too. The software (Gnuk) in Nitrokey >>> Start USB Token could be replaced (with JTAG/SWD debugger), too. Or, we >>> should consider possibility of backdoor of OpenPGP card. Well, I don't >>> know about Yubikey. >>> >>> When it is replaced to be malicious one to enable an access by others >>> (to your private keys), or it already has a backdoor in the first place, >>> it kills the purpose of USB security token. >>> >>> Here, the question is: how can we build up such a "trust"? >>> >>> It seems for me that there are two different approaches; (1) physical >>> difficulty (for example, plastic molding for "protection"), (2) >>> reproducibility and transparency/openness. Note that some method of >>> former makes latter difficult. >>> >>> >>> For myself, I take (2), and I did my best to make my product as >>> reproducible. (Since I don't manufacture semiconductor things, >>> reproducibility is not 100%, and this part of manufacturing and >>> technology is not open at all.) And I intentionally deliver my product >>> in a style of "transparent" or "open". >>> >>> Distribution channel is also difficult. I do in person, and I ask FSF >>> for my TRNG. Are there any good method? >>> >>> Obvious drawback of the apporoach (2) is that people with enough >>> concern/attention have tendency to do it under their control. >>> Reasonable. Since it's reproducible (somehow), it's possible, by >>> definition. And then, I can't sell many. >>> >> >> _________________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users > > > > _______________________________________________ > 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 sivmu at web.de Thu Dec 15 20:35:23 2016 From: sivmu at web.de (sivmu) Date: Thu, 15 Dec 2016 20:35:23 +0100 Subject: Smartcards and tokens In-Reply-To: <877f72gek7.fsf@iwagami.gniibe.org> References: <3abc5c59-3956-e16d-d430-4090ff9ce4c9@web.de> <877f72gek7.fsf@iwagami.gniibe.org> Message-ID: <29122609-b93b-ccff-ff3c-f63dcdcfa335@web.de> Am 15.12.2016 um 02:35 schrieb NIIBE Yutaka: > sivmu wrote: >> One question remaining is what is the difference between the openpgp >> smartcard and the USB based tokens. > > I think that the OpenPGP card (the physical smartcard) is included in > Nitrokey Pro USB Token. So, it's exactly same from the view point of > smartcard. > > When you want to use a smartcard, you need a card reader to access the > card. And the card reader you use would bring another attack vectors. > In this point, Nitrokey Pro USB Token is the best approach, I suppose. > > IIUC, Yubikey products are JavaCard implementations and somehow emulate > OpenPGP card protocol by "app", and they work as CCID card reader + > OpenPGP card. > > In Nitrokey Start USB Token, there is no OpenPGP card physically, but it > is implemented by Gnuk, the software. > >> Also how much would you trust those vendors and can the use of such >> tokens actually decrease security? > > This is the point. > > The hardware OpenPGP card in Nitrokey Pro USB Token could be replaced by > man in the middle (or its vendor). The hardware MCU chip in Nitrokey > Start USB Token could be replaced, too. The software (Gnuk) in Nitrokey > Start USB Token could be replaced (with JTAG/SWD debugger), too. Or, we > should consider possibility of backdoor of OpenPGP card. Well, I don't > know about Yubikey. > > When it is replaced to be malicious one to enable an access by others > (to your private keys), or it already has a backdoor in the first place, > it kills the purpose of USB security token. > > Here, the question is: how can we build up such a "trust"? > > It seems for me that there are two different approaches; (1) physical > difficulty (for example, plastic molding for "protection"), (2) > reproducibility and transparency/openness. Note that some method of > former makes latter difficult. > > > For myself, I take (2), and I did my best to make my product as > reproducible. (Since I don't manufacture semiconductor things, > reproducibility is not 100%, and this part of manufacturing and > technology is not open at all.) And I intentionally deliver my product > in a style of "transparent" or "open". > > Distribution channel is also difficult. I do in person, and I ask FSF > for my TRNG. Are there any good method? > > Obvious drawback of the apporoach (2) is that people with enough > concern/attention have tendency to do it under their control. > Reasonable. Since it's reproducible (somehow), it's possible, by > definition. And then, I can't sell many. > From what I understand, a malicious token can e.g. perform encryption operations with weak randomness to create some kind of backdoor that is hard to detect. Maybe there is also a way to secretly send the secret keys loaded onto the smartcard/token to the adversary using the PC and network it is used on. If there is no way to detect such malicious devices and given that certain organisations tend to mess with security tokens and crypto devices, it seems using those specific devices actually decreases security, assuming it is easy to manipulate specialised vendors of security hardware compared to manipulating electronic hardware in general. Or is this too much of a conspiracy theorie? (not that those do not have a tendency to be outrun by reality anyway) With nitrokey, both the hardware design and the software is open source and both have been audited. Bu I don't think that will keep some people from intercepting deliveries of such devices or mess with the production. I'm really not sure if specialised devices for crypto is a good idea, give that it presents such a promising target. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From lewisurn at gmail.com Thu Dec 15 22:02:08 2016 From: lewisurn at gmail.com (Lou Wynn) Date: Thu, 15 Dec 2016 13:02:08 -0800 Subject: Smartcards and tokens In-Reply-To: <3707f9e0-3ac7-851f-4dbb-79ea600d8541@gmail.com> References: <3abc5c59-3956-e16d-d430-4090ff9ce4c9@web.de> <877f72gek7.fsf@iwagami.gniibe.org> <8c35f02a-6f56-b5ee-1309-2b245cda5a57@gmail.com> <1481793869.354345.819785617.795947AE@webmail.messagingengine.com> <3707f9e0-3ac7-851f-4dbb-79ea600d8541@gmail.com> Message-ID: Hi Martinho, After I thought about it more, I have kind of drawn the conclusion that even for signing, only using a SmartCard cannot achieve authenticity. With a write-only SmartCard which computes signature on the card, it's true that it can protect the signing key. However, if it's used in a hacked machine or malicious environment, the hash sent to the card can be modified to be the hash of something else, not the hash of the document that you think you're reading on screen. Even if your signing key is kept secret on the card, but it blindly signs a fake hash. What's good about this? So using a write-only SmartCard alonewithout a secure host environment cannot give you the security level you think you get. Unless I missed something from your original description. This actually boils down a minimal trusted computing base (TCB). SmartCard itself does not form a complete TCB, which must include certain trusted host environment. On 12/15/2016 11:24 AM, Lou Wynn wrote: > > If the host machine is compromised, what's the purpose of doing > encryption on the SmartCard? Attackers don't need to know the key to > get your plaint ext, because it is on the host machine. > > I guess that what you meant was signing, using a SmartCard to sign has > the benefits you mentioned, but not encryption. > > > On 12/15/2016 01:24 AM, R. Martinho Fernandes wrote: >> There's an important distinction to be made between using this >> approach and using a SmartCard. The encrypted USB drive approach >> leaks the keys into the machine you're using it from; they're >> accessible by simply reading the filesystem (thus the claim that >> "When you unplug the USB, your keys are gone." is wrong). The keys >> in a SmartCard are write-only; the SmartCard performs all the >> encryption on-chip. >> >> You need to have an attack on the SmartCard to get the keys, while >> with the USB drive approach, you just need to attack the host machine. >> >> >> On Thu, Dec 15, 2016, at 08:34 AM, Lou Wynn wrote: >>> >>> I've come cross a simple and secure approach at this post: >>> >>> http://zacharyvoase.com/2009/08/20/openpgp/ >>> >>> In the MAKING BACKUPS section, this method simply places your gnupg >>> directory in an encrypted usb drive and make a symlink to it like this: >>> >>> ln -s /Volumes/EncDrive/gnupg ~/.gnupg >>> >>> That's all. As long as you use a good passphrase, this is very >>> secure method to me. When you unplug the USB, your keys are gone. If >>> your USB drive is lost, its content is encrypted by your passphrase, >>> so no worry about it. >>> >>> >>> >>> >>> On 12/14/2016 05:35 PM, NIIBE Yutaka wrote: >>>> sivmu wrote: >>>> >>>>> One question remaining is what is the difference between the openpgp >>>>> smartcard and the USB based tokens. >>>>> >>>> I think that the OpenPGP card (the physical smartcard) is included in >>>> Nitrokey Pro USB Token. So, it's exactly same from the view point of >>>> smartcard. >>>> >>>> When you want to use a smartcard, you need a card reader to access the >>>> card. And the card reader you use would bring another attack vectors. >>>> In this point, Nitrokey Pro USB Token is the best approach, I suppose. >>>> >>>> IIUC, Yubikey products are JavaCard implementations and somehow emulate >>>> OpenPGP card protocol by "app", and they work as CCID card reader + >>>> OpenPGP card. >>>> >>>> In Nitrokey Start USB Token, there is no OpenPGP card physically, but it >>>> is implemented by Gnuk, the software. >>>> >>>> >>>>> Also how much would you trust those vendors and can the use of such >>>>> tokens actually decrease security? >>>>> >>>> This is the point. >>>> >>>> The hardware OpenPGP card in Nitrokey Pro USB Token could be replaced by >>>> man in the middle (or its vendor). The hardware MCU chip in Nitrokey >>>> Start USB Token could be replaced, too. The software (Gnuk) in Nitrokey >>>> Start USB Token could be replaced (with JTAG/SWD debugger), too. Or, we >>>> should consider possibility of backdoor of OpenPGP card. Well, I don't >>>> know about Yubikey. >>>> >>>> When it is replaced to be malicious one to enable an access by others >>>> (to your private keys), or it already has a backdoor in the first place, >>>> it kills the purpose of USB security token. >>>> >>>> Here, the question is: how can we build up such a "trust"? >>>> >>>> It seems for me that there are two different approaches; (1) physical >>>> difficulty (for example, plastic molding for "protection"), (2) >>>> reproducibility and transparency/openness. Note that some method of >>>> former makes latter difficult. >>>> >>>> >>>> For myself, I take (2), and I did my best to make my product as >>>> reproducible. (Since I don't manufacture semiconductor things, >>>> reproducibility is not 100%, and this part of manufacturing and >>>> technology is not open at all.) And I intentionally deliver my product >>>> in a style of "transparent" or "open". >>>> >>>> Distribution channel is also difficult. I do in person, and I ask FSF >>>> for my TRNG. Are there any good method? >>>> >>>> Obvious drawback of the apporoach (2) is that people with enough >>>> concern/attention have tendency to do it under their control. >>>> Reasonable. Since it's reproducible (somehow), it's possible, by >>>> definition. And then, I can't sell many. >>>> >>> >>> _________________________________________________ >>> Gnupg-users mailing list >>> Gnupg-users at gnupg.org >>> http://lists.gnupg.org/mailman/listinfo/gnupg-users >> >> >> >> _______________________________________________ >> 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 dgouttegattat at incenp.org Thu Dec 15 22:17:48 2016 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Thu, 15 Dec 2016 22:17:48 +0100 Subject: Smartcards and tokens In-Reply-To: <29122609-b93b-ccff-ff3c-f63dcdcfa335@web.de> References: <3abc5c59-3956-e16d-d430-4090ff9ce4c9@web.de> <877f72gek7.fsf@iwagami.gniibe.org> <29122609-b93b-ccff-ff3c-f63dcdcfa335@web.de> Message-ID: On 12/15/2016 08:35 PM, sivmu wrote: > From what I understand, a malicious token can e.g. perform encryption > operations with weak randomness to create some kind of backdoor that is > hard to detect. The token is normally not used to perform any *encryption*. You encrypt with the public key of your correspondant, which is stored on your computer, not on your token (there's no need to protect it since it is a *public* key). You use your token to *decrypt* messages that were sent to you--and at that time, even if the token is malicious there's nothing it can do to mess with the encryption. What a malicious (or faulty) token *could* do is generate a weak key, that your opponent could break once and for all and then use to decrypt all messages sent to you. Smartcards generating weak keys have already been observed in the wild [1]. If you worry about that, simply generate your keys on a computer you trust, then load them onto the token, without ever using the token's own random number generator. > Maybe there is also a way to secretly send the secret > keys loaded onto the smartcard/token to the adversary using the PC and > network it is used on. I'll admit readily that I am not an expert on this, but I don't see how that could be feasible without the help of the host PC--meaning your opponent would have to both (1) compromise your PC and (2) send you a malicious token. But if he could compromise your PC, he would have no need for a malicious token. I guess your attacker could use a USB token as the mean to compromise your PC (names like "Bad USB" come to mind), but if you worry about such attacks, you should be wary of *any* USB device you buy (keyboards, mice, mass storage sticks... or even desktop missile launchers), not only cryptographic devices. Damien [1] https://eprint.iacr.org/2013/599 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From lewisurn at gmail.com Thu Dec 15 23:32:52 2016 From: lewisurn at gmail.com (Lou Wynn) Date: Thu, 15 Dec 2016 14:32:52 -0800 Subject: ways to ensure that GPG public key belongs to right person in business to business communication In-Reply-To: References: <87oa26esv7.fsf@alice.fifthhorseman.net> Message-ID: <652d3ca1-f5cc-1f2b-74f9-4345eab5920b@gmail.com> Let me analyze your steps to see what you'd like to achieve in each of them. 0. Alice and Bob knows each other's email addresses: alice at A and bob at B. 1. Bob sends Alice his public key at Alice email address alice at A. 2. Alice relies to Bob with her public key. 3. Alice calls B's support and asks to get Bob on the phone. 4. Bob tells Alice the fingerprint of his public key, and Alice checks it against what she received at (1). 5. Alice tells Bob her public key fingerprint, and Bob verifies it. You try to use step 4 and 5 to verify step 1 and 2, but it doesn't work. Suppose that Ted sends Alice his public key impersonating Bob by a faked from address but replies to Ted. Ted can be B's support guy who answers phones. Then your method makes Alice think that Ted is Bob. Step 4 and 5 don't add much value because Bob's public key fingerprint is public, and the guy in Step 3 doesn't have to be Bob. Basically, step 3 is useless, and step 4 and 5 are like PGP's web of trust: if someone says Bob's has that public key, then let's just believe it. The real value starts with 0, which makes Alice believe that she knows the owner of email of bob at B when sending to that address. The same holds true for Bob. In step 2, you should make Alice send her public key to the bob at B address because that's all the knowledge she has about Bob in terms of reachability, not reply. I'm working on a PGP key management system for organizational email communication. In this system, what I verify is not the identity of a person; instead, it's the owner of an email address. When I send to an email address with some secret and get the reply, then I know that I've been in contact with the owner of the email. I don't care about the real name of the person who owns the email, or I don't care if it's a shared email used by several people. All I care about is that I've been in contact with the email address. The security of organizational email system starts from here. If you're interested in this concept and trying out this system, I'll be happy to introduce you more, but it's off topic to this thread. Thanks, Lou On 10/27/2016 01:52 PM, Martin T wrote: > Hi, > > thanks for reply! Unfortunately, Alice and Bob cannot meet in person > because of geographical distance. If they could, then this would > definitely be the best way to exchange public keys. I further > simplified my initial idea: > > Alice from company A asks Bob from company B to send her Bobs public > key using an e-mail. Both Alice and Bob know each other e-mail > addresses because they have been in contact before during a project > which involves both company A and company B. Now when Alice receives > Bobs public key, she will send hers in return to same e-mail address > which she received the Bobs public key. Then she looks up the phone > number of the customer support department of company B from company B > official website and calls there and asks for Bob. Once she gets Bob > on the phone, she asks Bob to tell the fingerprint of his public key > and then Alice tells her public key fingerprint to Bob and asks Bob to > confirm that it matches. > > I guess this provides reasonable security? > > > thanks, > Martin > > > On Wed, Oct 26, 2016 at 11:51 PM, Daniel Kahn Gillmor > wrote: >> Hi Martin-- >> >> On Wed 2016-10-26 16:21:48 -0400, Martin T wrote: >> >>> let's say that Alice from company A and Bob from company B need to >>> exchange some private data with each other. Alice and Bob need to >>> encrypt data just that one time, they do not belong to web-of-trust, >>> but both company A and company B websites are trusted by certification >>> authority, secure and available only over TLS. This gives a first >>> option where both Alice and Bob ask their IT departments to publish >>> their public keys on the company website so Alice can get Bobs public >>> key over TLS from company B website and the other way around. Or when >>> for example website of company B is not trusted by CA, then Alice can >>> pick up the phone, call the customer-support of the company B and ask >>> for Bob and then ask Bob to send her an e-mail with a public key and >>> verify the fingerprint of the public key over a phone? Are there >>> better(easier to use or more secure) ways to ensure that GPG public >>> key belongs to right person in business to business communication? >> It depends on how much involvement you want the IT department to have. >> >> There are a few more options: >> >> * if Alice and Bob can meet in person, they can give each other >> business cards with their fingerprints on them. If this is how Alice >> finds Bob's e-mail address in the first place, this is a natural >> place to exchange cryptographic details as well. >> >> * the two companies could use WKD (web key directory), which is in its >> infancy, but is at least supported by GnuPG 2.1.x. >> >> * Alice and Bob could submit their keys to a third-party notary like >> Symantec's PGP Global Directory (if such a thing still exists) >> >> * Alice and Bob could publish their public keys in the public >> keyservers (e.g. gpg --send-key $FINGERPRINT) when they create their >> keys. Then they could look each other up in the public keyservers; >> if Alice finds only one public key associated with Bob's e-mail >> address, she might just decide to assume it's the right one. >> >> These all have slightly different security properties and failure modes, >> which might have different value to Alice and Bob, depending on their >> threat model and any other economic or logistical pressure they're >> under. >> >> --dkg > _______________________________________________ > 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 aranea at aixah.de Thu Dec 15 23:28:09 2016 From: aranea at aixah.de (Luis Ressel) Date: Thu, 15 Dec 2016 23:28:09 +0100 Subject: [Announce] Libgcrypt 1.7.5: secmem trouble In-Reply-To: <87mvfx7cfb.fsf@wheatstone.g10code.de> References: <87mvfx7cfb.fsf@wheatstone.g10code.de> Message-ID: <20161215232801.3ad99d25@gentp.lnet> Hello, since I've upgraded to libgcrypt 1.7.5, gpg emits the warning 'Warning: using insecure memory!' (and hence refuses to run, since my config file includes 'require-secmem'). Any hints for debugging this issue would the greatly appreciated. Regards, Luis Ressel From andrewg at andrewg.com Fri Dec 16 01:18:09 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 16 Dec 2016 00:18:09 +0000 Subject: Smartcards and tokens In-Reply-To: <3707f9e0-3ac7-851f-4dbb-79ea600d8541@gmail.com> References: <3abc5c59-3956-e16d-d430-4090ff9ce4c9@web.de> <877f72gek7.fsf@iwagami.gniibe.org> <8c35f02a-6f56-b5ee-1309-2b245cda5a57@gmail.com> <1481793869.354345.819785617.795947AE@webmail.messagingengine.com> <3707f9e0-3ac7-851f-4dbb-79ea600d8541@gmail.com> Message-ID: > On 15 Dec 2016, at 19:24, Lou Wynn wrote: > > If the host machine is compromised, what's the purpose of doing encryption on the SmartCard? Attackers don't need to know the key to get your plaint ext, because it is on the host machine. The difference is that if you use a smart card in a compromised host, the plaintext of particular messages may be compromised but the key itself remains secure. It also helps in the case of hardware loss or theft, because an encrypted drive can be brute forced, but smartcards have retry limits that can't be worked around short of dissecting the silicon. That's assuming it has been sufficiently hardened against side channel attacks, of course. And if you leave the smart card in the machine with an insufficient pass phrase timeout, the attacker could feed an arbitrary number of messages through it without you knowing. So it's no panacea. Andrew From gniibe at fsij.org Fri Dec 16 01:25:05 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 16 Dec 2016 09:25:05 +0900 Subject: Smartcards and tokens In-Reply-To: <29122609-b93b-ccff-ff3c-f63dcdcfa335@web.de> References: <3abc5c59-3956-e16d-d430-4090ff9ce4c9@web.de> <877f72gek7.fsf@iwagami.gniibe.org> <29122609-b93b-ccff-ff3c-f63dcdcfa335@web.de> Message-ID: <87wpf0vhy6.fsf@iwagami.gniibe.org> sivmu writes: > it seems using those specific devices actually decreases > security, assuming it is easy to manipulate specialised vendors of > security hardware compared to manipulating electronic hardware in general. Exactly, that's my point. This is the reason why my approach of Gnuk and NeuG tries to avoid specialized things. Even, I avoid using crypto accelerator, which (many of) experts say mandatory. I think that an approach using commodity hardware makes sense. My theory is that if it's simpler and cheap enough, difficulty putting backdoor would increase. I don't know if this is true, but I considered opposite must be likely; With enough space of silicon and enough complexly in design, attackers can do something more. > With nitrokey, both the hardware design and the software is open source > and both have been audited. Is it audited? I didn't know that. For me, audit by an expert (or two) is not enough. It should be possible by anyone, or at least, by any user who purchases it. It's sad for me that Nitrokey is not easy to open physically. I mean, opening the device to examine the board. > Bu I don't think that will keep some people from intercepting > deliveries of such devices or mess with the production. I don't know about the former, it depends on country. For the latter, it is real concern for me now. I make the hardware design as simple as possible so that inspection by human eye can be effective against replacing/adding chip. Difficult part (for me) is to assure initial firmware flashing in a factory. In (most of) factory environment, proprietary operating system dominates. I'm not sure if this is the weakest link, but this could be weaker point. When an attacker replaces the firmware to be written, it affects all devices to be shipped. Perhaps, it would be good if an MCU has a feature of reporting hash of its content of flash memory (even if flash is protected and it is not possible to read out its content). Then, an end user could examine the hash code. I think that the better current practice is: purchase commodity hardware and flash at the user side. -- From sivmu at web.de Fri Dec 16 03:30:24 2016 From: sivmu at web.de (sivmu) Date: Fri, 16 Dec 2016 03:30:24 +0100 Subject: Smartcards and tokens In-Reply-To: References: <3abc5c59-3956-e16d-d430-4090ff9ce4c9@web.de> <877f72gek7.fsf@iwagami.gniibe.org> <29122609-b93b-ccff-ff3c-f63dcdcfa335@web.de> Message-ID: Am 15.12.2016 um 22:17 schrieb Damien Goutte-Gattat: > On 12/15/2016 08:35 PM, sivmu wrote: >> From what I understand, a malicious token can e.g. perform encryption >> operations with weak randomness to create some kind of backdoor that is >> hard to detect. > > The token is normally not used to perform any *encryption*. You encrypt > with the public key of your correspondant, which is stored on your > computer, not on your token (there's no need to protect it since it is a > *public* key). You use your token to *decrypt* messages that were sent > to you--and at that time, even if the token is malicious there's nothing > it can do to mess with the encryption. > I assumed the public key of the recipient is transferred to the token so that it can do the encrytion internally. This is one of the things I worry about. If the token does the encryption (and signing) operations, it needs randomness. Something that is often messed with and hard to produce reliably compared to a device with user interaction. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From lachlan at twopif.net Fri Dec 16 04:19:21 2016 From: lachlan at twopif.net (Lachlan Gunn) Date: Fri, 16 Dec 2016 13:49:21 +1030 Subject: Hybrid keysigning party, your opinion? In-Reply-To: <9329b1b8-d33b-1a25-69cc-4205752e6ce5@digitalbrains.com> References: <6e4c97a3-de62-7ced-ba89-ad4fa9afbabc@mailbox.org> <9df31ca9-2eb9-2680-f671-e77bf2c78166@digitalbrains.com> <9329b1b8-d33b-1a25-69cc-4205752e6ce5@digitalbrains.com> Message-ID: <8cbd938a-685b-8060-f3e9-2e1a105c6f0b@twopif.net> Le 2016-12-14 ? 04:34, Peter Lebbing a ?crit : > Oh, not at all, I hadn't even noticed one could see it that way. My bad; such is the life of the email-user. > Or hang a truly huge printout on the wall and at the start of the > session, together observe that it is correct. Any latecomers can be told > "look, everybody thinks it's completely normal that we have a 64 digit > hex code on the wall, and that's because we all agreed it's the right one". Yes, with paper that would work. I rejected it because I was imagining a projector, which obviously could change the hash halfway through. Thanks, Lachlan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Fri Dec 16 07:12:46 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 16 Dec 2016 15:12:46 +0900 Subject: [Announce] Libgcrypt 1.7.5: secmem trouble In-Reply-To: <20161215232801.3ad99d25@gentp.lnet> References: <87mvfx7cfb.fsf@wheatstone.g10code.de> <20161215232801.3ad99d25@gentp.lnet> Message-ID: <87r358v1up.fsf@iwagami.gniibe.org> Luis Ressel wrote: > since I've upgraded to libgcrypt 1.7.5, gpg emits the warning 'Warning: > using insecure memory!' (and hence refuses to run, since my config file > includes 'require-secmem'). > > Any hints for debugging this issue would the greatly appreciated. I think that you need to debug libgcrypt to locate the bug. If you are familiar with GDB, run gpg under GDB with a break point at main, and then a break point at lock_pool_pages. Well, please show us the information in which architecuture/OS you runs GnuPG. Are you using GnuPG 2.1.x or another version? I'm afraid you are using libgcrypt 1.7.4. In version 1.7.4, there was a bug in configure script, which might cause such a trouble. -- From peter at digitalbrains.com Fri Dec 16 12:34:14 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 16 Dec 2016 12:34:14 +0100 Subject: Smartcards and tokens In-Reply-To: References: <3abc5c59-3956-e16d-d430-4090ff9ce4c9@web.de> <877f72gek7.fsf@iwagami.gniibe.org> <29122609-b93b-ccff-ff3c-f63dcdcfa335@web.de> Message-ID: <14bbfefc-dc9b-5733-f176-8ea0546414f0@digitalbrains.com> On 15/12/16 22:17, Damien Goutte-Gattat wrote: > I'll admit readily that I am not an expert on this, but I don't see how > that could be feasible without the help of the host PC--meaning your > opponent would have to both (1) compromise your PC and (2) send you a > malicious token. But if he could compromise your PC, he would have no > need for a malicious token. However, the defining property of a smartcard is that in principle, the private key cannot be extracted. That no longer holds for the party who backdoored the smartcard, since they could add a special command that extracts the private key. > I guess your attacker could use a USB token as the mean to compromise > your PC (names like "Bad USB" come to mind) Also note that someone could "borrow" your card without you noticing, rather than compromise your PC. This does depend on physically close attackers being in your threat model. Your USB token could actually have been compromised remotely on a different system, as a roundabout way of compromising your machine in the end. So that one is actually possible for remote attackers. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From andrewg at andrewg.com Fri Dec 16 13:36:19 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 16 Dec 2016 12:36:19 +0000 Subject: Smartcards and tokens In-Reply-To: References: <3abc5c59-3956-e16d-d430-4090ff9ce4c9@web.de> <877f72gek7.fsf@iwagami.gniibe.org> <29122609-b93b-ccff-ff3c-f63dcdcfa335@web.de> Message-ID: <40cd4798-5a78-b98b-20b4-e5ea81568d8e@andrewg.com> On 16/12/16 02:30, sivmu wrote: > If the token does the encryption (and signing) operations, Smartcards perform signing and DEcryption (which in the case of RSA are mathematically identical). > it needs randomness. That's true of DSA and ElGamal, but smartcards normally implement RSA. Remember also that PGP uses a two-step encryption process. The random symmetric session key is generated on the host rather than the smartcard, and the secure hash used in signing is deterministic. The smartcard itself only RSA-decrypts the session key (or hash), and this doesn't require an RNG. Andrew. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From lewisurn at gmail.com Fri Dec 16 19:33:48 2016 From: lewisurn at gmail.com (Lou Wynn) Date: Fri, 16 Dec 2016 10:33:48 -0800 Subject: Smartcards and tokens In-Reply-To: References: <3abc5c59-3956-e16d-d430-4090ff9ce4c9@web.de> <877f72gek7.fsf@iwagami.gniibe.org> <8c35f02a-6f56-b5ee-1309-2b245cda5a57@gmail.com> <1481793869.354345.819785617.795947AE@webmail.messagingengine.com> <3707f9e0-3ac7-851f-4dbb-79ea600d8541@gmail.com> Message-ID: On 12/15/2016 04:18 PM, Andrew Gallagher wrote: >> On 15 Dec 2016, at 19:24, Lou Wynn wrote: >> >> If the host machine is compromised, what's the purpose of doing encryption on the SmartCard? Attackers don't need to know the key to get your plaint ext, because it is on the host machine. > The difference is that if you use a smart card in a compromised host, the plaintext of particular messages may be compromised but the key itself remains secure. It also helps in the case of hardware loss or theft, because an encrypted drive can be brute forced, but smartcards have retry limits that can't be worked around short of dissecting the silicon. I agree that a SmartCard can protect a private key, but that's a marginal benefit because the bottom line of using a SmartCard is the same as that of using an encrypted USB drive, which is Do not use it in an untrusted or compromised host environment. If you stick to the bottom line, then there is no point to emphasize the difference. The difference only comes in when you violate the bottom line and want to use it in an untrusted or compromised host and "wish" that you could get security. In this case, SmartCard can prevent your key from being read. However, I would suggest anyone who uses a SmartCard not to do it at all because using it in such an environment cannot give you security: either signature or encryption. I'd like to say more about "brute force" since you seem to misunderstand the basic threat model of modern cryptography, whose design goal is only to allow brute force attacks. However, it's computationally infeasible in practice to guess the correct key by using brute force. A successful cryptographic design is one where there is no systematic way to break it unless an opponent can enumerate over the key space. SmartCard is no immune to this. A brute force attack doesn't need to read the card, and it simply enumerates keys in the key space used by the SmartCard. What you said--limiting the number of reads on the card--is not a measure against brute force. It is a measure to prevent reading secret materials. -- Thanks, Lou From andrewg at andrewg.com Fri Dec 16 19:38:33 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 16 Dec 2016 18:38:33 +0000 Subject: Smartcards and tokens In-Reply-To: References: <3abc5c59-3956-e16d-d430-4090ff9ce4c9@web.de> <877f72gek7.fsf@iwagami.gniibe.org> <8c35f02a-6f56-b5ee-1309-2b245cda5a57@gmail.com> <1481793869.354345.819785617.795947AE@webmail.messagingengine.com> <3707f9e0-3ac7-851f-4dbb-79ea600d8541@gmail.com> Message-ID: On 16/12/16 18:33, Lou Wynn wrote: > A brute force attack doesn't need to read the card, and > it simply enumerates keys in the key space used by the SmartCard. Yes, but the key space of the smartcard is much larger than the key space of a USB drive encrypted using a key derived from a human-readable passphrase... 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 xinayder at airmail.cc Fri Dec 16 23:19:17 2016 From: xinayder at airmail.cc (Alexandre Oliveira) Date: Fri, 16 Dec 2016 20:19:17 -0200 Subject: Common directory for different installs of GnuPG Message-ID: Hello. I'm a newbie when it comes to using GnuPG and PGP. I have 2 different versions currently installed in my system, so I'd like to know if setting both versions to point at the same directory to obtain the pubring.gpg, secring.gpg and trustdb.gpg files can cause critical issues. Thank you. From rjh at sixdemonbag.org Sat Dec 17 02:16:13 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 16 Dec 2016 20:16:13 -0500 Subject: Common directory for different installs of GnuPG In-Reply-To: References: Message-ID: <2ca1ee78-649d-d358-ebfa-fd2fd165d94e@sixdemonbag.org> > I'd like to know if setting both versions to point at the same > directory to obtain the pubring.gpg, secring.gpg and trustdb.gpg > files can cause critical issues. Unlikely. It's technically possible to have configuration files that don't work with 1.4 and 2.0/2.1, but it involves options you likely shouldn't have set in the first place. From xinayder at airmail.cc Sat Dec 17 02:26:08 2016 From: xinayder at airmail.cc (Alexandre Oliveira) Date: Fri, 16 Dec 2016 23:26:08 -0200 Subject: Common directory for different installs of GnuPG In-Reply-To: <2ca1ee78-649d-d358-ebfa-fd2fd165d94e@sixdemonbag.org> References: <2ca1ee78-649d-d358-ebfa-fd2fd165d94e@sixdemonbag.org> Message-ID: <93a63427-7e30-9afb-0234-46d56f14f3e6@airmail.cc> Is there somewhere I can check what settings were added and removed in the "update"? -- Alexandre Oliveira 167F D82F 514A E8D1 2E9E C62D 1B63 9D4A 7E9D DA9D From stebe at mailbox.org Sat Dec 17 01:57:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Sat, 17 Dec 2016 00:57:00 +0000 Subject: Implications of a common private keys directory in 2.1 In-Reply-To: <20161213004313.1264E10322B2@remailer.paranoici.org> References: <17f5cadc-c7fb-c43a-a141-5d269ab45eaa@digitalbrains.com> <78b30a87-43a1-bb2b-d965-c65a8a1c5b27@digitalbrains.com> <4c35d09f-f63e-1d82-05b3-fe491bd0d506@digitalbrains.com> <20161211195857.37447103200C@remailer.paranoici.org> <20161212030655.2A455103200C@remailer.paranoici.org> <9cca136f-4ccf-7d45-3317-23de025825f5@mailbox.org> <20161213004313.1264E10322B2@remailer.paranoici.org> Message-ID: Hi Caro, Carola Grunwald: > Stephan Beck wrote: >> Carola Grunwald: >>> Peter Lebbing wrote: > > > Removing all cached passphrases sounds great. But does that mean I have > to invoke the agent directly using the Assuan protocol? And what would > be the way to get a list of all valid cache_ids? well, now as you explained it again (below), and rethinking the whole issue, the use of this command does not let you get any closer to a solution, so I haven't investigated it further. > >> >> >> If you'd want to make sure that the right passphrase is provided, why >> don't you use --pinentry-mode loopback >> "Use a loopback pinentry. This fakes a pinentry by using >> inquiries back to the caller to ask for a passphrase." > > That's what I actually do: > > | G:\MyGnuPG\gpg\gpg.exe --pinentry-mode loopback --no-default-recipient --no-default-keyring --keyring "G:\MyGnuPG\key\rcp.kbx" --status-fd 2 [...] --decrypt --command-fd 0 --try-secret-key F69A3C70E1A93A2A --passphrase "DNJwzwnRaUzhEr0Ys3XpnSY309DpXdk/Nu4f+sFPdQM" --output "G:\MyGnuPG\gpg\tmp\txt_clr.906" "G:\MyGnuPG\gpg\tmp\txt_enc.906" Wouldn't you have to add, differing from version 1.4, the --batch option when using --passphrase string with gpg2.1? > > There's the id of a secret key with its passphrase, but if decoding > doesn't succeed with that key-passphrase combination or if the key > doesn't exist there are decryption attempts with all other secret keys > in the private-keys-v1.d folder, which only waste time: > > | [GNUPG:] ENC_TO 0000000000000000 18 0 > | [GNUPG:] KEY_CONSIDERED B5A49F253CE924DD2978A2C1F69A3C70E1A93A2A 0 <- the targeted one > | [GNUPG:] KEY_CONSIDERED 5A2915D0E26A7FD3301A35D82F1E01D95F23CBA9 0 > | [GNUPG:] KEY_CONSIDERED A2C2DA81C60217BA9FC60295F021F62304A579D2 0 > | [GNUPG:] KEY_CONSIDERED ... > > AFAICS it always uses the same given passphrase with all the keys, which > is good: > > | gpg: DBG: chan_0x0000009c <- INQUIRE PASSPHRASE > | gpg: DBG: chan_0x0000009c -> D DNJwzwnRaUzhEr0Ys3XpnSY309DpXdk/Nu4f+sFPdQM > > What I need here is the restriction to just the given key. And the agent's SETKEY command? gpg-connect-agent > help SETKEY SIGKEY SETKEY Set the key used for a sign or decrypt operation. To get a list of the secret keys with keygrip gpg --with-keygrip -K Cheers, Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From stebe at mailbox.org Sat Dec 17 02:21:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Sat, 17 Dec 2016 01:21:00 +0000 Subject: An attempt at backporting 2.1.16 from Debian sid to Debian jessie In-Reply-To: References: <0d7e39f9-d26e-6fee-1898-55000aeb807e@digitalbrains.com> <87fulyl3pn.fsf@iki.fi> <7dfd50b5-6f6e-2ce0-7cf9-78345204ccde@mailbox.org> Message-ID: Peter Lebbing: > On 08/12/16 21:42, Stephan Beck wrote: >> [...], so I don't see the real need for a forced coexistence of the two >> (or three) versions on Jessie. > > I did that because all the software in jessie that depends on GnuPG 1.4 > might not work with GnuPG 2.1. So by doing it like this, I'm not > breaking any packages that have the package "gnupg" in their dependency > tree. > Yes, I understand, and it's great work! I just wanted to say that I, personally, don't see the need since I upgraded to a 2.1 only installation. Cheers Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From dougb at dougbarton.email Sat Dec 17 04:02:37 2016 From: dougb at dougbarton.email (Doug Barton) Date: Fri, 16 Dec 2016 19:02:37 -0800 Subject: PM from David Adamson -please ask on-list In-Reply-To: <7106d356-f1ed-456a-166f-2bfa132e6b23@mailbox.org> References: <7106d356-f1ed-456a-166f-2bfa132e6b23@mailbox.org> Message-ID: <0beac23f-7437-83b5-f1cc-175b6be8239d@dougbarton.email> On 11/25/2016 02:28 AM, Stephan Beck wrote: > Hi David, > > I kindly invite you to post your PM on-list. It might be of interest for > other people as well. Why send this to the list, rather than to him privately? From stebe at mailbox.org Sat Dec 17 14:13:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Sat, 17 Dec 2016 13:13:00 +0000 Subject: PM from David Adamson -please ask on-list In-Reply-To: <0beac23f-7437-83b5-f1cc-175b6be8239d@dougbarton.email> References: <7106d356-f1ed-456a-166f-2bfa132e6b23@mailbox.org> <0beac23f-7437-83b5-f1cc-175b6be8239d@dougbarton.email> Message-ID: <811c6780-7a19-3c4c-2d46-44d2016b813a@mailbox.org> Doug Barton: > On 11/25/2016 02:28 AM, Stephan Beck wrote: >> Hi David, >> >> I kindly invite you to post your PM on-list. It might be of interest for >> other people as well. > > Why send this to the list, rather than to him privately? Why not? I supposed that he was reading the list. Cheers Stephan From aranea at aixah.de Sat Dec 17 16:14:27 2016 From: aranea at aixah.de (Luis Ressel) Date: Sat, 17 Dec 2016 16:14:27 +0100 Subject: [Announce] Libgcrypt 1.7.5: secmem trouble In-Reply-To: <87r358v1up.fsf@iwagami.gniibe.org> References: <87mvfx7cfb.fsf@wheatstone.g10code.de> <20161215232801.3ad99d25@gentp.lnet> <87r358v1up.fsf@iwagami.gniibe.org> Message-ID: <20161217161427.36abd24f@gentp.lnet> On Fri, 16 Dec 2016 15:12:46 +0900 NIIBE Yutaka wrote: > [...] > I'm afraid you are using libgcrypt 1.7.4. In version 1.7.4, there was > a bug in configure script, which might cause such a trouble. Indeed. Looks like I mixed up those versions; it was the 1.7.3 -> 1.7.4 upgrade which caused the issue, and 1.7.5 fixes it again. Thanks for your help, and sorry about the noise! Regards, Luis Ressel From 2014-667rhzu3dc-lists-groups at riseup.net Sat Dec 17 16:30:37 2016 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sat, 17 Dec 2016 15:30:37 +0000 Subject: Common directory for different installs of GnuPG In-Reply-To: <2ca1ee78-649d-d358-ebfa-fd2fd165d94e@sixdemonbag.org> References: <2ca1ee78-649d-d358-ebfa-fd2fd165d94e@sixdemonbag.org> Message-ID: <1568266281.20161217153037@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Saturday 17 December 2016 at 1:16:13 AM, in , Robert J. Hansen wrote:- >> I'd like to know if setting both versions to point >> at the same >> directory to obtain the pubring.gpg, secring.gpg >> and trustdb.gpg >> files can cause critical issues. > Unlikely. It's technically possible to have > configuration files that > don't work with 1.4 and 2.0/2.1, but it involves > options you likely > shouldn't have set in the first place. You can use different configuration files. A couple of years ago, dkg shared [0]:- > gpg 2.1.0 will look for the following files in $GNUPGHOME and choose the > first one it finds: > > gpg.conf-2.1.0 > gpg.conf-2.1 > gpg.conf-2 > gpg.conf > > gpg 1.4.18 will do the same sort of search: > > gpg.conf-1.4.18 > gpg.conf-1.4 > gpg.conf-1 > gpg.conf [0] - -- Best regards MFPA The secret to creativity is knowing how to hide your sources. -----BEGIN PGP SIGNATURE----- iL4EARYKAGYFAlhVWh9fFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDMzQUNFRDRFRTkxMzRFRUJERTZBODUwNjE3 MTJCQzQ2MUFGNzc4RTQACgkQFxK8Rhr3eOQDqgD/bq5bp2+Gt2w3CWQ0SROMvLBu ffCrw7IlhPAfvRJoZnYA/Rm8WvN8etm3a5lDFXvcI7GMr1t50fyDtR5n0dPN02UO iQF8BAEBCgBmBQJYVVouXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXw+wcH/R7DhPSl3v0ScIbLTdDxt5SZ WsFnAxNp9ur2qzsfHhVFp6utLi3QLRI5lievbs4GSaLGgpTKC/BtbiIo+GKY0XxS /mlma3GLHVIYvMiSp64I72O+jKU7fXaqwmmkKK9cEvjdCnevPQZrORuDHeeX1+WH 9ZzQU11iIPww28zvgQH5U30FDKYuN3BWw49ZIZlPM354iBxIg3x3s01EB9PUgdNn rtUlGBTvBvZBZou8nRHNwbkBpYjMkTzGarqztj78YL0JQnUcIHYSf7F+jycqO8ib cRR/5tdWsPIBRHkuUhOUZ2WaSb9YmQGPngGn22KFwubJ3ZOnv2nNXvtcBcajx6M= =T3iL -----END PGP SIGNATURE----- From m.mansfeld at mansfeld-elektronik.de Sat Dec 17 17:40:55 2016 From: m.mansfeld at mansfeld-elektronik.de (Matthias Mansfeld) Date: Sat, 17 Dec 2016 17:40:55 +0100 Subject: Strange behaviour In-Reply-To: References: <584A0065.26179.994BF0@m.mansfeld.mansfeld-elektronik.de>, , Message-ID: <58556A97.31334.2F0ABA@m.mansfeld.mansfeld-elektronik.de> Hello list, I just want to tell as it is now: It seems to happen something strange with network access within this PC. If it happens again, the mail client Pegasus cannot connect at all to localhost (neither to 127.0.0.1) where GPGRelay (the GnuPG "Proxy") would listen - If GPGRelay just would not reply, then I would get the timeout error from Pegasus, but nothing, Pegasus just freezes totally, nothing interesting in the Pegasus TCP/IP log. But it seems not to be only pegasus-related, as if this has happened, I cannot even ping anything in my lan, not by name, not by IP, and also nowhere in the web. I guess I have to learn more about how TCP/IP etc. is supposed to work and how to debug it if it doesn't work anymore. -- Stephan, your signatures are probably completely "Not guilty".... Sorry for all that trouble.... Regards Matthias -- OpenPGP: http://www.mansfeld-elektronik.de/gnupgkey/mansfeld.asc Fingerprint: 6563 057D E6B8 9105 1CE4 18D0 4056 1F54 8B59 40EF From xinayder at airmail.cc Sat Dec 17 18:30:02 2016 From: xinayder at airmail.cc (Alexandre Oliveira) Date: Sat, 17 Dec 2016 15:30:02 -0200 Subject: Common directory for different installs of GnuPG In-Reply-To: <1568266281.20161217153037@riseup.net> References: <2ca1ee78-649d-d358-ebfa-fd2fd165d94e@sixdemonbag.org> <1568266281.20161217153037@riseup.net> Message-ID: > > You can use different configuration files. A couple of years ago, dkg > shared [0]:- > >> gpg 2.1.0 will look for the following files in $GNUPGHOME and choose the >> first one it finds: > >> gpg.conf-2.1.0 >> gpg.conf-2.1 >> gpg.conf-2 >> gpg.conf > >> gpg 1.4.18 will do the same sort of search: > >> gpg.conf-1.4.18 >> gpg.conf-1.4 >> gpg.conf-1 >> gpg.conf > > [0] > > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > Thank you! -- Alexandre Oliveira 167F D82F 514A E8D1 2E9E C62D 1B63 9D4A 7E9D DA9D From lists at bertram-scharpf.de Sat Dec 17 19:42:02 2016 From: lists at bertram-scharpf.de (Bertram Scharpf) Date: Sat, 17 Dec 2016 19:42:02 +0100 Subject: PM from David Adamson -please ask on-list In-Reply-To: <0beac23f-7437-83b5-f1cc-175b6be8239d@dougbarton.email> References: <7106d356-f1ed-456a-166f-2bfa132e6b23@mailbox.org> <0beac23f-7437-83b5-f1cc-175b6be8239d@dougbarton.email> Message-ID: <20161217184202.GA19112@becker.bs.l> On Friday, 16. Dec 2016, 19:02:37 -0800, Doug Barton wrote: > On 11/25/2016 02:28 AM, Stephan Beck wrote: > > Hi David, > > > > I kindly invite you to post your PM on-list. It might be of interest for > > other people as well. > > Why send this to the list, rather than to him privately? Because it might be of interest for other people as well. Bertram -- Bertram Scharpf Stuttgart, Deutschland/Germany http://www.bertram-scharpf.de From ml.throttle at xoxy.net Sun Dec 18 00:27:51 2016 From: ml.throttle at xoxy.net (Helmut Waitzmann) Date: Sun, 18 Dec 2016 00:27:51 +0100 Subject: Fwd: tar, compress, split and then encrypt a list of files In-Reply-To: (Felipe Vieira's message of "Thu, 15 Dec 2016 10:05:42 -0200") References: Message-ID: <87oa0aqgoe.fsf@helmutwaitzmann.news.arcor.de> Felipe Vieira : > right now I have a working workstream that gets paths from a text file and: > > tar -> compress -> encrypt -> split (over each line/entry) > > Probably there is a security issue here as some of the paths are dozens of > gigabytes in size. > > I would like to swap the 'encrypt -> split' part but I'm unable to do so > using the GNU split functionality. I suppose, the problem is, that ?split? can't split to stdout. Maybe ?dd? could be a replacement for ?split? for getting chunks of data and then using the shell to compute file names with sequence numbers? tar ... | compress | ( # put a block size and number of blocks per file of your choice here: bs=1024k count=1024 # number of digits to be used for the sequence number: suffixlength=3 # put a filename prefix of your choice here: prefix= seqnum=0 test=test until { if ! "$test" "${#seqnum}" -le "${suffixlength:=1}" then printf >&2 '%s\n' 'The sequence numbers excede the suffix length.' test=: fi file="$( printf "%s%.${suffixlength}d" "$prefix" "$seqnum" )" { LC_ALL=POSIX dd ${bs:+bs="$bs"} ${count:+count="$count"} 3>&- | encrypt > "${file}" 2>&3 3>&- } 3>&2 2>&1 | { grep -F -q -x -e '0+0 records in' && cat ; } > /dev/null } do seqnum="$(( ${seqnum} + 1 ))" done ) As this problem is more one of split/dd/shell than of gpg, how about discussing this in the usenet group ?comp.unix.shell? rather than in the ?gnupg-users? mailinglist? From sivmu at web.de Sun Dec 18 01:17:44 2016 From: sivmu at web.de (sivmu) Date: Sun, 18 Dec 2016 01:17:44 +0100 Subject: Smartcards and tokens In-Reply-To: <40cd4798-5a78-b98b-20b4-e5ea81568d8e@andrewg.com> References: <3abc5c59-3956-e16d-d430-4090ff9ce4c9@web.de> <877f72gek7.fsf@iwagami.gniibe.org> <29122609-b93b-ccff-ff3c-f63dcdcfa335@web.de> <40cd4798-5a78-b98b-20b4-e5ea81568d8e@andrewg.com> Message-ID: <0d6813c2-d093-a802-232d-ad3ad824418a@web.de> Am 16.12.2016 um 13:36 schrieb Andrew Gallagher: > On 16/12/16 02:30, sivmu wrote: >> If the token does the encryption (and signing) operations, > > Smartcards perform signing and DEcryption (which in the case of RSA are > mathematically identical). > >> it needs randomness. > > That's true of DSA and ElGamal, but smartcards normally implement RSA. > > Remember also that PGP uses a two-step encryption process. The random > symmetric session key is generated on the host rather than the > smartcard, and the secure hash used in signing is deterministic. > Thats what i wanted to hear. If the symmetric key is generated on the host, that stops any scenario where the smartcard can subvertly compromise the encryption process, assuming.... > The smartcard itself only RSA-decrypts the session key (or hash), and > this doesn't require an RNG. ... that this means RSA encrzption is reproducable, meaning encrypted files of the same plaintext result in the same ciphertext, as this woul make the process reproduceable and any malfunction can be easily noticed. Signing could still be manipulated by a compromised smartcard I guess -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Sun Dec 18 01:30:36 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sun, 18 Dec 2016 00:30:36 +0000 Subject: Smartcards and tokens In-Reply-To: <0d6813c2-d093-a802-232d-ad3ad824418a@web.de> References: <3abc5c59-3956-e16d-d430-4090ff9ce4c9@web.de> <877f72gek7.fsf@iwagami.gniibe.org> <29122609-b93b-ccff-ff3c-f63dcdcfa335@web.de> <40cd4798-5a78-b98b-20b4-e5ea81568d8e@andrewg.com> <0d6813c2-d093-a802-232d-ad3ad824418a@web.de> Message-ID: > On 18 Dec 2016, at 00:17, sivmu wrote: > > ... that this means RSA encrzption is reproducable, meaning encrypted > files of the same plaintext result in the same ciphertext, as this woul > make the process reproduceable and any malfunction can be easily noticed. No, because the plaintext is symmetric-encrypted with a random session key on the host. The smartcard just asymmetric-encrypts the session key. This two step process is used mainly because asymmetric encryption is comparatively slow, but it also means that two identical plain texts won't get encrypted to the same ciphertext, due to the random session key. A From rjh at sixdemonbag.org Sun Dec 18 01:56:43 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 17 Dec 2016 19:56:43 -0500 Subject: Smartcards and tokens In-Reply-To: <0d6813c2-d093-a802-232d-ad3ad824418a@web.de> References: <3abc5c59-3956-e16d-d430-4090ff9ce4c9@web.de> <877f72gek7.fsf@iwagami.gniibe.org> <29122609-b93b-ccff-ff3c-f63dcdcfa335@web.de> <40cd4798-5a78-b98b-20b4-e5ea81568d8e@andrewg.com> <0d6813c2-d093-a802-232d-ad3ad824418a@web.de> Message-ID: <2c164051-7b3a-a86e-3769-1c48705eeb83@sixdemonbag.org> >> The smartcard itself only RSA-decrypts the session key (or hash), >> and this doesn't require an RNG. > > ... that this means RSA encrzption is reproducable, meaning > encrypted files of the same plaintext result in the same ciphertext, > as this woul make the process reproduceable and any malfunction can > be easily noticed. Nope. OpenPGP requires each RSA encryption add at least eight random bytes to the data pre-encryption in order to make even identical messages encrypt to different ciphertexts. Search RFC4880 for a reference to RFC3447 7.2.1, then look up RFC3447 7.2.1 and see how EME-PKCS1-v1_5 encoding is defined. From sivmu at web.de Sun Dec 18 02:53:58 2016 From: sivmu at web.de (sivmu) Date: Sun, 18 Dec 2016 02:53:58 +0100 Subject: Smartcards and tokens In-Reply-To: References: <3abc5c59-3956-e16d-d430-4090ff9ce4c9@web.de> <877f72gek7.fsf@iwagami.gniibe.org> <29122609-b93b-ccff-ff3c-f63dcdcfa335@web.de> <40cd4798-5a78-b98b-20b4-e5ea81568d8e@andrewg.com> <0d6813c2-d093-a802-232d-ad3ad824418a@web.de> Message-ID: <1b921970-261e-8ff4-e09d-4f6295c502e9@web.de> Am 18.12.2016 um 01:30 schrieb Andrew Gallagher: > >> On 18 Dec 2016, at 00:17, sivmu wrote: >> >> ... that this means RSA encrzption is reproducable, meaning encrypted >> files of the same plaintext result in the same ciphertext, as this woul >> make the process reproduceable and any malfunction can be easily noticed. > > No, because the plaintext is symmetric-encrypted with a random session key on the host. The smartcard just asymmetric-encrypts the session key. This two step process is used mainly because asymmetric encryption is comparatively slow, but it also means that two identical plain texts won't get encrypted to the same ciphertext, due to the random session key. > > A > You are right, I forgot that. Having some kind of way to check if the card is operating normally would be awesome though... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From guanx.bac at gmail.com Sun Dec 18 01:47:49 2016 From: guanx.bac at gmail.com (Guan Xin) Date: Sun, 18 Dec 2016 01:47:49 +0100 Subject: Fwd: tar, compress, split and then encrypt a list of files In-Reply-To: <87oa0aqgoe.fsf@helmutwaitzmann.news.arcor.de> References: <87oa0aqgoe.fsf@helmutwaitzmann.news.arcor.de> Message-ID: On Sun, Dec 18, 2016 at 12:27 AM, Helmut Waitzmann wrote: > > As this problem is more one of split/dd/shell than of gpg, how > about discussing this in the usenet group ?comp.unix.shell? rather > than in the ?gnupg-users? mailinglist? > Actually there is reason to discuss it here because the original problem was if splitting before encryption is necessary. For the "split" part, a "--filter" option has been available since five years ago (version 8.13 of gnu coreutils). From peter at digitalbrains.com Sun Dec 18 10:49:39 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 18 Dec 2016 10:49:39 +0100 Subject: Smartcards and tokens In-Reply-To: <2c164051-7b3a-a86e-3769-1c48705eeb83@sixdemonbag.org> References: <3abc5c59-3956-e16d-d430-4090ff9ce4c9@web.de> <877f72gek7.fsf@iwagami.gniibe.org> <29122609-b93b-ccff-ff3c-f63dcdcfa335@web.de> <40cd4798-5a78-b98b-20b4-e5ea81568d8e@andrewg.com> <0d6813c2-d093-a802-232d-ad3ad824418a@web.de> <2c164051-7b3a-a86e-3769-1c48705eeb83@sixdemonbag.org> Message-ID: On 18/12/16 01:56, Robert J. Hansen wrote: > Nope. OpenPGP requires each RSA encryption add at least eight random > bytes to the data pre-encryption in order to make even identical > messages encrypt to different ciphertexts. However, this randomness is added by the host, not by the smartcard. The OpenPGP smartcard really only does a deterministic action, and its correctness can be verified simply by doing the RSA public key operation on the output and checking that the result is identical to what was fed to the smartcard. I can't think of a side channel to leak the private key to an attacker through an uncompromised host, but I wouldn't be surprised if there is such a side channel. Does anybody have a cool way to leak this? Single bits at a time will do! :-) (We've already established that if the private key is generated on-card, it is trivial to reconstruct it for an attacker that can insert a backdoor into the smartcard) 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 ml.throttle at xoxy.net Sun Dec 18 17:28:31 2016 From: ml.throttle at xoxy.net (Helmut Waitzmann) Date: Sun, 18 Dec 2016 17:28:31 +0100 Subject: Fwd: tar, compress, split and then encrypt a list of files In-Reply-To: (Guan Xin's message of "Sun, 18 Dec 2016 01:47:49 +0100") References: <87oa0aqgoe.fsf@helmutwaitzmann.news.arcor.de> Message-ID: <874m21p5fa.fsf@helmutwaitzmann.news.arcor.de> Guan Xin : > On Sun, Dec 18, 2016 at 12:27 AM, Helmut Waitzmann wrote: >> >> As this problem is more one of split/dd/shell than of gpg, how >> about discussing this in the usenet group ?comp.unix.shell? rather >> than in the ?gnupg-users? mailinglist? >> > > Actually there is reason to discuss it here because the original > problem was if splitting before encryption is necessary. > > For the "split" part, a "--filter" option has been available since > five years ago (version 8.13 of gnu coreutils). Thank you for your clarification. From caro at nymph.paranoici.org Sun Dec 18 20:25:37 2016 From: caro at nymph.paranoici.org (Carola Grunwald) Date: Sun, 18 Dec 2016 19:25:37 +0000 (UTC) Subject: Implications of a common private keys directory in 2.1 References: <78b30a87-43a1-bb2b-d965-c65a8a1c5b27@digitalbrains.com> <4c35d09f-f63e-1d82-05b3-fe491bd0d506@digitalbrains.com> <20161212030655.2A455103200C@remailer.paranoici.org> <9cca136f-4ccf-7d45-3317-23de025825f5@mailbox.org> <20161213004313.1264E10322B2@remailer.paranoici.org> Message-ID: <20161218192537.5838E1032154@remailer.paranoici.org> Stephan Beck wrote: >Carola Grunwald: >> Stephan Beck wrote: >>> Carola Grunwald: >>>> Peter Lebbing wrote: >> >> >> Removing all cached passphrases sounds great. But does that mean I have >> to invoke the agent directly using the Assuan protocol? And what would >> be the way to get a list of all valid cache_ids? > >well, now as you explained it again (below), and rethinking the whole >issue, the use of this command does not let you get any closer to a >solution, so I haven't investigated it further. >> >>> >>> >>> If you'd want to make sure that the right passphrase is provided, why >>> don't you use --pinentry-mode loopback >>> "Use a loopback pinentry. This fakes a pinentry by using >>> inquiries back to the caller to ask for a passphrase." >> >> That's what I actually do: >> >> | G:\MyGnuPG\gpg\gpg.exe --pinentry-mode loopback --no-default-recipient --no-default-keyring --keyring "G:\MyGnuPG\key\rcp.kbx" --status-fd 2 [...] --decrypt --command-fd 0 --try-secret-key F69A3C70E1A93A2A --passphrase "DNJwzwnRaUzhEr0Ys3XpnSY309DpXdk/Nu4f+sFPdQM" --output "G:\MyGnuPG\gpg\tmp\txt_clr.906" "G:\MyGnuPG\gpg\tmp\txt_enc.906" > >Wouldn't you have to add, differing from version 1.4, the --batch option >when using --passphrase string with gpg2.1? Obviously not (see 'INQUIRE PASSPHRASE' below). > >> >> There's the id of a secret key with its passphrase, but if decoding >> doesn't succeed with that key-passphrase combination or if the key >> doesn't exist there are decryption attempts with all other secret keys >> in the private-keys-v1.d folder, which only waste time: >> >> | [GNUPG:] ENC_TO 0000000000000000 18 0 >> | [GNUPG:] KEY_CONSIDERED B5A49F253CE924DD2978A2C1F69A3C70E1A93A2A 0 <- the targeted one >> | [GNUPG:] KEY_CONSIDERED 5A2915D0E26A7FD3301A35D82F1E01D95F23CBA9 0 >> | [GNUPG:] KEY_CONSIDERED A2C2DA81C60217BA9FC60295F021F62304A579D2 0 >> | [GNUPG:] KEY_CONSIDERED ... >> >> AFAICS it always uses the same given passphrase with all the keys, which >> is good: >> >> | gpg: DBG: chan_0x0000009c <- INQUIRE PASSPHRASE >> | gpg: DBG: chan_0x0000009c -> D DNJwzwnRaUzhEr0Ys3XpnSY309DpXdk/Nu4f+sFPdQM >> >> What I need here is the restriction to just the given key. > >And the agent's SETKEY command? >gpg-connect-agent >> help SETKEY >SIGKEY >SETKEY >Set the key used for a sign or decrypt operation. Isn't there a gpg SETKEY option for decryption? AFAICS --default-key is only for signing, --recipient for encryption. Is --try-secret-key the SETKEY equivalent for decryption? Can a developer shed light on this? Kind regards Caro From vsrinu26f at gmail.com Sun Dec 18 17:37:01 2016 From: vsrinu26f at gmail.com (Srinivas V) Date: Sun, 18 Dec 2016 11:37:01 -0500 Subject: CCID token Serial numbers: same subkeys on multiple cards Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, Here is my setup: 1 offline master key pair 4096 Certify only 4 Yuby keys, 2 gnuk tokens : same 2048 E, S, A subkeys on all tokens My problem is some programs depend on card number and not on the keys on the card. Example "OpenPGP Encryption applet". Instead of me switching between gnupg home directories for the key I have in hand, I would like to know if there is a way to add more than one card number to the same sub key? Thanks Srinivas Vengala -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJYVrr+AAoJENH8Wz/S9r4LawwH/0nJi2pnAmB3swV5m41teZ65 Ssls06QxsyWS8yYRyWzl9dJRvyPaS/eUatFWYHgLjtSR0KKCNXT6l79thRrD3JHI 8EoA2OMh2AQt+5sKrdCl0x3DqOIhXfIIe7yREfE2uWSsQ1n6QoMWXlUW0GNzuJ9f XJjtiGmjrO1tu4JMPSrTvnFRyHUIBe/R8DGlyzJgcxJOWmea331Jexxme5cKzacG 9DNm2T2CJXF54Vu6brcKTcF4JbUtrw+s2iUoF6Unyqzb7exoqCBt6FobWppA/dCQ dbzZF8sUU45Yk580fyaAaVT86Uaj51HjBsd/mu0XE9dRImbnipKpjdixiN9ut3w= =XHRs -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at digitalbrains.com Sun Dec 18 21:02:36 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 18 Dec 2016 21:02:36 +0100 Subject: CCID token Serial numbers: same subkeys on multiple cards In-Reply-To: References: Message-ID: <6c35d734-451d-abed-b65c-4745f31added@digitalbrains.com> On 18/12/16 17:37, Srinivas V wrote: > Instead of me switching between gnupg home directories for the key I > have in hand, I would like to know if there is a way to add more than > one card number to the same sub key? As far as I am aware, that is not possible. 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 jkt at kde.org Mon Dec 19 02:20:57 2016 From: jkt at kde.org (=?iso-8859-1?Q?Jan_Kundr=E1t?=) Date: Mon, 19 Dec 2016 02:20:57 +0100 Subject: gpg-agent 2.1.16 needs about 10s for initialization saying =?iso-8859-1?Q?need=5Fentropy_before_it_completes_its_first_op?= Message-ID: <0b3a5bed-d26a-47b4-9cc4-ac24fbe0de9a@kde.org> Hi, we're using gpgme's C++ bindings in Trojita [1], an IMAP e-mail client. After an update of gnupg from 2.1.15 to 2.1.16, gpg-agent appears to need more than 10s to initialize itself during startup -- or at least our very first decryptAndVerify() operation takes more than 10s. An initial report arrived for Fedora [2] because our unit tests have a 10s timeout for crypto operations. I was able to reproduce this on my Gentoo laptop after some detours [3]. Based on instructions at [4] I ran the test with watchgnupg, and here's its output: $ watchgnupg --force --time-only /home/jkt/work/prog/_trojita-build/qt5/keys/S.log [client at fd 4 connected (local)] 4 - 01:57:57 gpg-agent[28761]: listening on socket '/home/jkt/work/prog/_trojita-build/qt5/keys/S.gpg-agent' 4 - 01:57:57 gpg-agent[28761]: listening on socket '/home/jkt/work/prog/_trojita-build/qt5/keys/S.gpg-agent.extra' 4 - 01:57:57 gpg-agent[28761]: listening on socket '/home/jkt/work/prog/_trojita-build/qt5/keys/S.gpg-agent.browser' 4 - 01:57:57 gpg-agent[28761]: listening on socket '/home/jkt/work/prog/_trojita-build/qt5/keys/S.gpg-agent.ssh' 4 - 01:57:57 gpg-agent[28762]: gpg-agent (GnuPG) 2.1.16 started 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 -> OK Pleased to meet you, process 28759 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 <- RESET 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 -> OK 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 <- OPTION ttytype=xterm-256color 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 -> OK 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 <- OPTION display=:0 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 -> OK 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 <- OPTION xauthority=/tmp/xauth-1000-_0 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 -> OK 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 <- GETINFO version 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 -> D 2.1.16 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 -> OK 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 <- OPTION allow-pinentry-notify 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 -> OK 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 <- OPTION agent-awareness=2.1.0 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 -> OK 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 <- HAVEKEY 04078EF4E8DDFBD9A79369C9369222972F1E7B70 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 -> OK 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 <- HAVEKEY CD99D55B7555C542EDC5A144A8349E1E21DC412D 04078EF4E8DDFBD9A79369C9369222972F1E7B70 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 -> OK 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 <- HAVEKEY 04078EF4E8DDFBD9A79369C9369222972F1E7B70 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 -> OK 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 <- RESET 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 -> OK 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 <- SETKEY 04078EF4E8DDFBD9A79369C9369222972F1E7B70 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 -> OK 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 <- SETKEYDESC Please+enter+the+passphrase+to+unlock+the+OpenPGP+secret+key:%0A%22Valid+%22%0A1024-bit+RSA+key,+ID+521933E50559E38D,%0Acreated+2016-12-17+(main+key+ID+DD48D22EA8745250).%0A 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 -> OK 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 <- PKDECRYPT 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 -> S INQUIRE_MAXLEN 4096 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 -> INQUIRE CIPHERTEXT 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 <- [ 44 20 28 37 3a 65 6e 63 2d 76 61 6c 28 33 3a 72 ...(144 byte(s) skipped) ] 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 <- END 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:57:58 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:57:59 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:57:59 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:57:59 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:57:59 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:57:59 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:57:59 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:57:59 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:57:59 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:57:59 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:57:59 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:00 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:00 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:00 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:00 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:00 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:00 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:00 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:00 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:00 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:00 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:01 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:01 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:01 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:01 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:01 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:01 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:01 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:01 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:01 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:01 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:02 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:02 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:02 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:02 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:02 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:02 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:02 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:02 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:02 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:02 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:03 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:03 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:03 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:03 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:03 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:03 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:03 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:03 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:03 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:03 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:04 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:04 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:04 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:04 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:04 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:04 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:04 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:04 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:04 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:04 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:05 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:05 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:05 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:05 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:05 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:05 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:05 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:05 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:05 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:05 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:06 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:06 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:06 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:06 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:06 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:06 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:06 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:06 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:06 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:06 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:07 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:07 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:07 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:07 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:07 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:07 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:07 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:07 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:07 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:07 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:08 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:08 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:08 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:08 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:08 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:08 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:08 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:08 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:08 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:08 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> [ 44 20 28 35 3a 76 61 6c 75 65 31 32 37 3a 02 a0 ...(133 byte(s) skipped) ] 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> OK 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- [eof] 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> OK Pleased to meet you, process 28775 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- RESET 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> OK 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- OPTION ttytype=xterm-256color 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> OK 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- OPTION display=:0 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> OK 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- OPTION xauthority=/tmp/xauth-1000-_0 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> OK 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- GETINFO version 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> D 2.1.16 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> OK 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- OPTION allow-pinentry-notify 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> OK 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- OPTION agent-awareness=2.1.0 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> OK 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- HAVEKEY 87AAAE497897F9936043F9C3B20CE5FDDCD489C2 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> OK 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- HAVEKEY 99BBCCA120222186A19AC89190ECEE7EF87997A0 87AAAE497897F9936043F9C3B20CE5FDDCD489C2 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> OK 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- HAVEKEY 87AAAE497897F9936043F9C3B20CE5FDDCD489C2 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> OK 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- RESET 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> OK 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- SETKEY 87AAAE497897F9936043F9C3B20CE5FDDCD489C2 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> OK 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- SETKEYDESC Please+enter+the+passphrase+to+unlock+the+OpenPGP+secret+key:%0A%22Expired+%22%0A1024-bit+RSA+key,+ID+D4EA7265FDDDE374,%0Acreated+2016-12-17+(main+key+ID+35927423786DCCCE).%0A 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> OK 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- PKDECRYPT 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> S INQUIRE_MAXLEN 4096 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> INQUIRE CIPHERTEXT 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- [ 44 20 28 37 3a 65 6e 63 2d 76 61 6c 28 33 3a 72 ...(147 byte(s) skipped) ] 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- END 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> [ 44 20 28 35 3a 76 61 6c 75 65 31 32 37 3a 02 f8 ...(127 byte(s) skipped) ] 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> OK 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- [eof] ^C It seems that my symptoms actually look pretty much like that bugreport [4] in Debian. I checked what my kernel thinks about this (/proc/sys/kernel/random/entropy_avail). It started at 3985 before I ran the test, then went a bit lower to 3735, then started slowly growing back. The relevant packages are: app-crypt/gpgme-1.8.0-r1:1/11::gentoo USE="cxx qt5 -common-lisp -python -static-libs" PYTHON_TARGETS="python2_7 python3_4" app-crypt/gnupg-2.1.16::gentoo USE="bzip2 gnutls nls readline smartcard usb -doc -ldap (-selinux) -tofu -tools -wks-server" dev-libs/libgpg-error-1.24::gentoo USE="nls -common-lisp -static-libs" dev-libs/npth-1.3::gentoo USE="-static-libs" dev-libs/libassuan-2.4.3::gentoo USE="-static-libs" What should I do to get gpg-agent completing these requests sooner than after ten seconds? I could probably start it a bit sooner during the build, but that sounds a bit ugly. In the meanwhile, I increased the test timeout, but that is pretty ugly, too. Cheers, Jan [1] http://trojita.flaska.net/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=1401716 [3] https://bugs.kde.org/show_bug.cgi?id=373374 [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847552#35 -- Trojit?, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/ From peter at digitalbrains.com Mon Dec 19 12:22:32 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 19 Dec 2016 12:22:32 +0100 Subject: Implications of a common private keys directory in 2.1 In-Reply-To: <20161212030655.2A455103200C@remailer.paranoici.org> References: <17f5cadc-c7fb-c43a-a141-5d269ab45eaa@digitalbrains.com> <78b30a87-43a1-bb2b-d965-c65a8a1c5b27@digitalbrains.com> <20161211014830.B5635103200C@remailer.paranoici.org> <4c35d09f-f63e-1d82-05b3-fe491bd0d506@digitalbrains.com> <20161211195857.37447103200C@remailer.paranoici.org> <20161212030655.2A455103200C@remailer.paranoici.org> Message-ID: I think I've made my point, but more importantly, I feel that you understood what I tried to get across. You reach a different conclusion than I, but I think any further discussion on these points would lead to rehashing of previously made arguments. On 12/12/16 04:06, Carola Grunwald wrote: > You're right, unbelievable. I specify --try-secret-key with a > > [GNUPG:] ENC_TO 0000000000000000 18 0 > > message and gpg still tries out two dozen WME keys with a passphrase > not valid for them. What a waste of time! Hmmmmm, it looks like --try-secret-key only suppresses passphrase queries for keys, any cached keys are tried anyway? I didn't notice this before. I did use 2.1.11 before and now I'm using 2.1.16, but I don't know if I tested this properly with 2.1.11. > No confusion. The proxy server just assembles mail from different > sources, which are a normal external POP3 account and a local > repository of newsgroups, where nym replies are stored for being > downloaded anonymously by the nym holder, e.g. > alt.anonymous.messages. Well, never mind the confusion, of which I still think there is some, as I fail to understand your conclusions. You say a logoff is so frequent it will not be a good idea to kill the agent then (I think, or something on that order). Okay. You don't need to use the logoff as the signal to stop the agent, you could easily do a timeout as well. First of all, in the following, assume a homedir and thus agent per proxy user account. Once you invoke a private key operation, you also put a timestamp somewhere. Maybe a file called "last_used" in the GnuPG homedir, it could also be a timestamp in a database. Everytime you use a particular homedir(/agent) to decrypt or sign, you update this timestamp. Now you have a reaper process that looks at all "last_used" stamps there are, every minute. Once it notices that "last_used" is more than a minute ago, it'll kill the agent for that homedir, and remove the "last_used" stamp. This way, as soon as your user has done nothing for a minute, their agent is stopped. When they do something again, the agent is just started up again, and stays alive until the client is idle again, at which point it is once again stopped. So, agents are only running for clients that where active in the last minute. This should not waste resources at any appreciable level. > When it's a corporation on behalf of which the proxy is used it won't > matter whether the corresponding employee and the proxy admin are > different persons, as both are bound to the company's rules to act in > concert. I actually thought you were also offering a proxy server to the wide public, not just as a corporation to its own employees. But you know what, never mind. You seem to have understood my point. > It's better than nothing. Nevertheless it's a compromise I see no > reason for when otherwise there's a chance to manipulate the > timestamp directly and avoid any latency between the client and the > entry remailer(s). I presented it as an alternative to fake timestamps, to avoid having to do them. When you say "I see no reason to do that when you have fake timestamps", well... Yeah. You'd be right. That's pretty much what alternatives are for. To do the same thing in a different way. > ??? It's about the protection of data in transit, not about securing > the proxy server. With compromized keys a single passphrase for > different nyms is a solid proof for a similar origin. I was talking about the encryption of the private keys sitting on the multi-user proxy; there's no need to use different "passphrases" for different keys. This is /not/ data in transit. These passphrases that encrypt the private key never leave the proxy, it's private information to the proxy. > Don't get me wrong, but what I see here is the difference between > enlightened thinking and servile obedience overinterpreting the > wording. Don't get me wrong, but... you know what? Let's just not. > So I'll immediately shut up in case Werner says Internet anonymity is > a bad thing. And that's an unnecessary, cheap shot. It will not make feature requests any more likely to succeed if you pour them in such a mould; on the contrary. 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 Mon Dec 19 12:17:22 2016 From: wk at gnupg.org (Werner Koch) Date: Mon, 19 Dec 2016 12:17:22 +0100 Subject: gpg-agent 2.1.16 needs about 10s for initialization saying need_entropy before it completes its first op In-Reply-To: <0b3a5bed-d26a-47b4-9cc4-ac24fbe0de9a@kde.org> ("Jan =?utf-8?Q?Kundr=C3=A1t=22's?= message of "Mon, 19 Dec 2016 02:20:57 +0100") References: <0b3a5bed-d26a-47b4-9cc4-ac24fbe0de9a@kde.org> Message-ID: <87twa0yxq5.fsf@wheatstone.g10code.de> On Mon, 19 Dec 2016 02:20, jkt at kde.org said: > dev-libs/libgpg-error-1.24::gentoo USE="nls -common-lisp -static-libs" Plead use libgpg-error 1.25 and test again. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From peter at digitalbrains.com Mon Dec 19 12:28:05 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 19 Dec 2016 12:28:05 +0100 Subject: Implications of a common private keys directory in 2.1 In-Reply-To: <20161211014830.B5635103200C@remailer.paranoici.org> References: <3b776db4-4161-35cc-31ac-b343b12edf7a@digitalbrains.com> <20161124230301.3055810320F5@remailer.paranoici.org> <17f5cadc-c7fb-c43a-a141-5d269ab45eaa@digitalbrains.com> <20161204205923.ADB011031FF9@remailer.paranoici.org> <78b30a87-43a1-bb2b-d965-c65a8a1c5b27@digitalbrains.com> <20161211014830.B5635103200C@remailer.paranoici.org> Message-ID: <0be7b29c-a7a3-4f87-b21e-0db23f72cc42@digitalbrains.com> On 11/12/16 02:48, Carola Grunwald wrote: > Nevertheless the user has to get knowledge of such an attack, which is > why a header entry reporting the decoding status is added to the message > forwarded to the client: > > | O-Nym-Crypto: slot=19; sym=3; asym=1; esub=i; account=myaccount at nym.mixmin.net > | O-Nym-Sig: Good signature (SHA1:[562619C278247C3B] Bananasplit Pseudonym Server (Bananasplit Pseudonymous Email Server) ; Sat, 10 Dec 2016 02:25:44 +0000) And is the message still delivered decrypted to the client? Because in that case, it seems that the only thing preventing a user from disastrously exposing the relation between two nym accounts is them noticing the mismatch in this little header in the mail. That seems like a really riskful user interface. Hopefully the message text is merely saying "Message encrypted to wrong key", right? 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 jkt at kde.org Mon Dec 19 13:10:49 2016 From: jkt at kde.org (=?iso-8859-1?Q?Jan_Kundr=E1t?=) Date: Mon, 19 Dec 2016 13:10:49 +0100 Subject: gpg-agent 2.1.16 needs about 10s for initialization saying =?iso-8859-1?Q?need=5Fentropy_before_it_completes_its_first_op?= In-Reply-To: <87twa0yxq5.fsf@wheatstone.g10code.de> References: <0b3a5bed-d26a-47b4-9cc4-ac24fbe0de9a@kde.org> <87twa0yxq5.fsf@wheatstone.g10code.de> Message-ID: <015ddef7-3d59-42d4-9b50-a784952773f3@kde.org> On pond?l? 19. prosince 2016 12:17:22 CET, Werner Koch wrote: > Plead use libgpg-error 1.25 and test again. I don't see any difference in behavior after updating to libgpg-error-1.25 and `killall gpg-agent`. There are still at least 10 seconds of this in watchgnupg: 4 - 13:09:53 gpg-agent[16749]: DBG: chan_9 -> S PROGRESS need_entropy X 30 120 4 - 13:09:54 gpg-agent[16749]: DBG: chan_9 -> S PROGRESS need_entropy X 120 120 With kind regards, Jan -- Trojit?, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/ From stebe at mailbox.org Mon Dec 19 20:05:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Mon, 19 Dec 2016 19:05:00 +0000 Subject: Implications of a common private keys directory in 2.1 In-Reply-To: <20161218192537.5838E1032154@remailer.paranoici.org> References: <78b30a87-43a1-bb2b-d965-c65a8a1c5b27@digitalbrains.com> <4c35d09f-f63e-1d82-05b3-fe491bd0d506@digitalbrains.com> <20161212030655.2A455103200C@remailer.paranoici.org> <9cca136f-4ccf-7d45-3317-23de025825f5@mailbox.org> <20161213004313.1264E10322B2@remailer.paranoici.org> <20161218192537.5838E1032154@remailer.paranoici.org> Message-ID: <77a3e5e3-190b-cac7-1db9-667715257d49@mailbox.org> Hi, Carola Grunwald: > Stephan Beck wrote: >> Carola Grunwald: >>> Stephan Beck wrote: >>>> Carola Grunwald: >>>>> Peter Lebbing wrote: >>> [...] > > Removing all cached passphrases sounds great. But does that mean I have > to invoke the agent directly using the Assuan protocol? And what would > be the way to get a list of all valid cache_ids? I thought that after paying attention to the fact that, in your example, there was only one single passphrase for all the different WME keys (that's what I had understood), thinking of ways to remove the (one and only) passphrase would make no sense. Sorry for my confusion! But, effectively, every passphrase cache entry consists of a cache ID which can be expressed as the keygrip of the key, so there are really several different cached passphrase entries=cacheIDs. Please see [BEGIN QUOTE] This is gnupg.info, produced by makeinfo version 5.2 from gnupg.texi. This is the 'The GNU Privacy Guard Manual' (version 2.1.16-beta394, November 2016). (C) 2002, 2004, 2005, 2006, 2007, 2010 Free Software Foundation, Inc. (C) 2013, 2014, 2015 Werner Koch. (C) 2015 g10 Code GmbH. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version. The text of the license can be found in the section entitled "Copying". 2.6.7 Ask for a passphrase -------------------------- [...] CACHE_ID is expected to be a string used to identify a cached passphrase. Use a 'X' to bypass the cache. With no other arguments the agent returns a cached passphrase or an error. By convention either the hexified fingerprint of the key shall be used for CACHE_ID or an arbitrary string prefixed with the name of the calling application and a colon: Like 'gpg:somestring'. [END QUOTE] So, yes, and sorry for my hesitation, the only way (I see) is to invalidate the passphrase cache removing all its entries and manually presetting the one keygrip/key to use on the command line. (If it was about ssh keys and the ssh control file you could precede a ! to the respective entry in order to disable the corresponding key. But in the info manual this is only mentioned in the context of ssh control file) So, given that "your" passphrase cache contains keygrips for all the keys in your secret keyring (the private-keys folder): gpg --with-keygrip -K outputs all keygrips. A SIGHUP sent to the agent flushes the passphrase cache. [There may be other ways of invalidating cache entries.] Then you add the --allow-preset-passphrase and the --preset-passphrase [keygrip of the targeted key] options to your command line and it should work (i.e. no other key will be used for decryption - there isn't any other in the passphrase cache!) Given that I can't reproduce your environment this is not validated by testing, though. >>> What I need here is the restriction to just the given key. >> >> And the agent's SETKEY command? >> gpg-connect-agent >>> help SETKEY >> SIGKEY >> SETKEY >> Set the key used for a sign or decrypt operation. > > Isn't there a gpg SETKEY option for decryption? AFAICS --default-key is > only for signing, --recipient for encryption. Is --try-secret-key the > SETKEY equivalent for decryption? Can a developer shed light on this? Well, as mentioned above, I guess that the interesting gpg option would be the --preset-passphrase [keygrip] option, associating the passphrase with the keygrip (SHA-1 hash of the canonical encoded S-expression of the key). Interestingly, the thread about the "gpg-agent 2.1.16 needs about 10s for initialization saying need_entropy before it completes its first op" reproduces watchgnupg's debugging output of such a SETKEY --> PKDECRYPT operation. > 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- HAVEKEY 87AAAE497897F9936043F9C3B20CE5FDDCD489C2 > 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> OK > 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- HAVEKEY 99BBCCA120222186A19AC89190ECEE7EF87997A0 87AAAE497897F9936043F9C3B20CE5FDDCD489C2 > 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> OK > 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- HAVEKEY 87AAAE497897F9936043F9C3B20CE5FDDCD489C2 > 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> OK > 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- RESET > 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> OK > 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- SETKEY 87AAAE497897F9936043F9C3B20CE5FDDCD489C2 > 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> OK > 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- SETKEYDESC Please+enter+the+passphrase+to+unlock+the+OpenPGP+secret+key:%0A%22Expired+%22%0A1024-bit+RSA+key,+ID+D4EA7265FDDDE374,%0Acreated+2016-12-17+(main+key+ID+35927423786DCCCE).%0A > 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> OK > 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- PKDECRYPT > 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> S INQUIRE_MAXLEN 4096 > 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> INQUIRE CIPHERTEXT > 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- [ 44 20 28 37 3a 65 6e 63 2d 76 61 6c 28 33 3a 72 ...(147 byte(s) skipped) ] > 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- END > 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> [ 44 20 28 35 3a 76 61 6c 75 65 31 32 37 3a 02 f8 ...(127 byte(s) skipped) ] > 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 -> OK > 4 - 01:58:09 gpg-agent[28762]: DBG: chan_9 <- [eof] The first action after INQUIRE CIPHERTEXT is the decryption, the second (just before the final 'eof' has to be the verifying. Generally speaking, HAVEKEY given with more than one keygrip outputs OK if at least for one of the given keygrips there is a secret key held by the agent in its passphrase cache. So we wouldn't be able to say that the example above on its own proves that there is really more than one key in the cache... But then one has to ask how can it (within the message decryption workflow) happen that there is a second HAVEKEY request that outputs an additional keygrip: only when there is a second recipient to whom the message is encrypted to, the second HAVEKEY request is being emitted. So, final conclusion: the SETKEY, as seen here, sets the key to use when there is a hidden recipient the message is encrypted to, and IS another way of saying --try-secret-key. Cheers Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Mon Dec 19 20:40:02 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 19 Dec 2016 20:40:02 +0100 Subject: Implications of a common private keys directory in 2.1 In-Reply-To: <77a3e5e3-190b-cac7-1db9-667715257d49@mailbox.org> References: <78b30a87-43a1-bb2b-d965-c65a8a1c5b27@digitalbrains.com> <4c35d09f-f63e-1d82-05b3-fe491bd0d506@digitalbrains.com> <20161212030655.2A455103200C@remailer.paranoici.org> <9cca136f-4ccf-7d45-3317-23de025825f5@mailbox.org> <20161213004313.1264E10322B2@remailer.paranoici.org> <20161218192537.5838E1032154@remailer.paranoici.org> <77a3e5e3-190b-cac7-1db9-667715257d49@mailbox.org> Message-ID: <62d5afeb-18a5-abba-c8d9-455538c742ae@digitalbrains.com> On 19/12/16 20:05, Stephan Beck wrote: > So, yes, and sorry for my hesitation, the only way (I see) is to > invalidate the passphrase cache removing all its entries and manually > presetting the one keygrip/key to use on the command line. Why don't you just disable passphrase caching if that is the only problem? (max-cache-ttl 0, I think that works, didn't check). I think one of the underlying problems is that Carola wants to prevent keys from being used even though the correct passphrase is presented. Come to think of it, if you include the keygrip in the passphrase, the passphrase would ever only match the one key. Heh. The same would work if you include the proxy user name, if that is the level of division you want. Pretty obvious once you think of it. Still, it seems like a small part of the overall puzzle presented by Carola. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From sivmu at web.de Tue Dec 20 09:55:08 2016 From: sivmu at web.de (sivmu) Date: Tue, 20 Dec 2016 09:55:08 +0100 Subject: gpg-agent 2.1.16 needs about 10s for initialization saying need_entropy before it completes its first op In-Reply-To: <0b3a5bed-d26a-47b4-9cc4-ac24fbe0de9a@kde.org> References: <0b3a5bed-d26a-47b4-9cc4-ac24fbe0de9a@kde.org> Message-ID: <54035f5f-1a39-88ac-8e2f-1c097058efa9@web.de> Am 19.12.2016 um 02:20 schrieb Jan Kundr?t: > Hi, > we're using gpgme's C++ bindings in Trojita [1], an IMAP e-mail client. > After an update of gnupg from 2.1.15 to 2.1.16, gpg-agent appears to > need more than 10s to initialize itself during startup -- or at least > our very first decryptAndVerify() operation takes more than 10s. > I can confirm simular behavior. After upgrading to 2.1.16 it takes 10 seconds on the first operation performed. Any following operations are fast as usual. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From sivmu at web.de Tue Dec 20 09:56:30 2016 From: sivmu at web.de (sivmu) Date: Tue, 20 Dec 2016 09:56:30 +0100 Subject: Smartcards and tokens In-Reply-To: References: <3abc5c59-3956-e16d-d430-4090ff9ce4c9@web.de> <877f72gek7.fsf@iwagami.gniibe.org> <29122609-b93b-ccff-ff3c-f63dcdcfa335@web.de> <40cd4798-5a78-b98b-20b4-e5ea81568d8e@andrewg.com> <0d6813c2-d093-a802-232d-ad3ad824418a@web.de> <2c164051-7b3a-a86e-3769-1c48705eeb83@sixdemonbag.org> Message-ID: <8c202c8a-38b0-db99-d69d-1a79dde132aa@web.de> Am 18.12.2016 um 10:49 schrieb Peter Lebbing: > On 18/12/16 01:56, Robert J. Hansen wrote: >> Nope. OpenPGP requires each RSA encryption add at least eight random >> bytes to the data pre-encryption in order to make even identical >> messages encrypt to different ciphertexts. > > However, this randomness is added by the host, not by the smartcard. The > OpenPGP smartcard really only does a deterministic action, and its > correctness can be verified simply by doing the RSA public key operation > on the output and checking that the result is identical to what was fed > to the smartcard. > Thats good to know. Thanks > I can't think of a side channel to leak the private key to an attacker > through an uncompromised host, but I wouldn't be surprised if there is > such a side channel. Does anybody have a cool way to leak this? Single > bits at a time will do! :-) > Implement a GSM chip into the token? :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Tue Dec 20 11:32:21 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 20 Dec 2016 05:32:21 -0500 Subject: File perms for conf files Message-ID: So, as some of you may remember, I've been working on something to help users back up their user directories and migrate them to new machines. We really have no good tools at present to do this, so I'm putting together a small Qt application to make this easier. https://github.com/rjhansen/sherpa (Note: it is not complete and not ready for user testing.) It *almost* works on macOS and Linux; it's a little further from finished on Windows. I'm now at the point where I need to restore files from a zip archive, and part of that means ensuring I have the correct POSIX permissions on each file. The files which, if present, are backed up: gpg-agent.conf gpg.conf pubring.gpg secring.gpg trustdb.gpg pubring.kbx sshcontrol dirmngr.conf gpa.conf scdaemon.conf gpgsm.conf policies.txt trustlist.txt scd-event tofu.db gpg.conf-2.1 gpg.conf-2.0 gpg.conf-2 gpg.conf-1.4 gpg.conf-1 crls.d/* openpgp-revocs.d/[A-Fa-f0-9]{40}\.rev private-keys-v1.d/[A-Fa-f0-9]{40}\.key So, two questions: (a) Is this list missing anything important? (b) What's the official, GnuPG-approved permission for each? (Oh, sure, I could just assume my GnuPG installation had correct perms and use those. But for something like this, I'd like to be sure.) From wk at gnupg.org Tue Dec 20 12:29:35 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Dec 2016 12:29:35 +0100 Subject: [Announce] GnuPG 2.1.17 released Message-ID: <87inqeyh28.fsf@wheatstone.g10code.de> Hello! Today marks the 19th anniversary of GnuPG and we are pleased to announce the availability of a new release: GnuPG 2.1.17. See below for a list of new features and bug fixes. About GnuPG ============= 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) comes with the latest features and is suggested for most users. This announcement is about this branch. - GnuPG "stable" (2.0) is the currently mostly used branch which will be maintain until 2017-12-31. - GnuPG "classic" (1.4) is a simplified version of GnuPG, required on very old platforms or to decrypt data created with PGP-2 keys. 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.17 ==================================== * gpg: By default new keys expire after 2 years. * gpg: New command --quick-set-expire to conveniently change the expiration date of keys. * gpg: Option and command names have been changed for easier comprehension. The old names are still available as aliases. * gpg: Improved the TOFU trust model. * gpg: New option --default-new-key-algo. * scd: Support OpenPGP card V3 for RSA. * dirmngr: Support for the ADNS library has been removed. Instead William Ahern's Libdns is now source included and used on all platforms. This enables Tor support on all platforms. The new option --standard-resolver can be used to disable this code at runtime. In case of build problems the new configure option --disable-libdns can be used to build without Libdns. * dirmngr: Lazily launch ldap reaper thread. * tools: New options --check and --status-fd for gpg-wks-client. * The UTF-8 byte order mark is now skipped when reading conf files. * Fixed many bugs and regressions. * Major improvements to the test suite. For example it is possible to run the external test suite of GPGME. A detailed description of the changes found in this 2.1 branch can be found at . Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.1.17 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.17.tar.bz2 (5830k) ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.17.tar.bz2.sig or here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.17.tar.bz2 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.17.tar.bz2.sig An installer for Windows without any graphical frontend except for a very minimal Pinentry tool is available here: ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.17_20161220.exe (3665k) ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.17_20161220.exe.sig or here https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.17_20161220.exe https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.17_20161220.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; it is still missing HKPS and Web Key Directory 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.17.tar.bz2 you would use this command: gpg --verify gnupg-2.1.17.tar.bz2.sig gnupg-2.1.17.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 the end of this mail 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.17.tar.bz2, you run the command like this: sha1sum gnupg-2.1.17.tar.bz2 and check that the output matches the next line: d83ab893faab35f37ace772ca29b939e6a5aa6a7 gnupg-2.1.17.tar.bz2 a95758912ed5354235ff9947a3c402108d5ec67e gnupg-w32-2.1.17_20161220.exe a358666de565a1f86ba9cd6bc8700a8224ea1078 gnupg-w32-2.1.17_20161220.tar.xz Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese, Czech, French, German, Japanese, Norwegian, Russian, and Ukrainian being almost completely translated. Due to expected changes in forthcoming releases some strings pertaining to the TOFU code are not yet translated. 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 and . 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 . If you need commercial support check out . 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. The GnuPG project employs 3 full-time developers, one part-timer, and one contractor. They all work exclusivly on GnuPG and closely related software like Libgcrypt, GPGME, 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. The GnuPG hackers, Andre, dkg, gniibe, Justus, Neal, and Werner p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users'at'gnupg.org mailing list. p.p.s List of 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: 2020-10-30] 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. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 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 cmt at burggraben.net Tue Dec 20 13:46:23 2016 From: cmt at burggraben.net (Christoph Moench-Tegeder) Date: Tue, 20 Dec 2016 13:46:23 +0100 Subject: [Announce] GnuPG 2.1.17 released In-Reply-To: <87inqeyh28.fsf@wheatstone.g10code.de> References: <87inqeyh28.fsf@wheatstone.g10code.de> Message-ID: <20161220124623.GB1615@elch.exwg.net> Hi, I believe there's something wrong with the signature of the latest release. ## Werner Koch (wk at gnupg.org): > * 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.17.tar.bz2 you would use this command: > > gpg --verify gnupg-2.1.17.tar.bz2.sig gnupg-2.1.17.tar.bz2 This fails: gpg: Signature made Tue Dec 20 11:33:11 2016 CET gpg: using RSA key D8692123C4065DEA5E0F3AB5249B39D24F25E3B6 gpg: BAD signature from "Werner Koch (dist sig)" [unknown] But the SHA1 hash of the release tarball matches the one in the release announcement. I downloaded directly from gnupg.org. For reference, the hashes of the release file and the signature (as downloaded here) are: SHA1 (gnupg-2.1.17.tar.bz2) = d83ab893faab35f37ace772ca29b939e6a5aa6a7 SHA1 (gnupg-2.1.17.tar.bz2.sig) = 34cea3e6d139cb340bf14f04ff217cb6960cf36d Or is that just me and a local issue? Regards, Christoph -- Spare Space From mls at dabpunkt.eu Tue Dec 20 16:21:37 2016 From: mls at dabpunkt.eu (Daniel Baur) Date: Tue, 20 Dec 2016 16:21:37 +0100 Subject: [Announce] GnuPG 2.1.17 released In-Reply-To: <20161220124623.GB1615@elch.exwg.net> References: <87inqeyh28.fsf@wheatstone.g10code.de> <20161220124623.GB1615@elch.exwg.net> Message-ID: <4aaf714d-0327-d16d-b84f-7c1fa5f87815@dabpunkt.eu> Hello, Am 20.12.2016 um 13:46 schrieb Christoph Moench-Tegeder: > SHA1 (gnupg-2.1.17.tar.bz2) = d83ab893faab35f37ace772ca29b939e6a5aa6a7 > SHA1 (gnupg-2.1.17.tar.bz2.sig) = 34cea3e6d139cb340bf14f04ff217cb6960cf36d > > Or is that just me and a local issue? it works for me (see below), but the sig-file I downloaded has another hash (dfdfe72c4dd7e10bef283d25fa365cfa022305de) than yours, so maybe there was an issue and it is fixed already? Sincerely, DaB. PS: What?s ?public key algorithm 22?? -- snip --- 16:15:39dab at dabpc:/tmp$ LC_ALL=C gpg2 -v gnupg-2.1.17.tar.bz2.sig :signature packet: algo 1, keyid 249B39D24F25E3B6 version 4, created 1482242390, md5len 0, sigclass 0x00 digest algo 8, begin of digest d8 f7 hashed subpkt 33 len 21 (?) hashed subpkt 2 len 4 (sig created 2016-12-20) subpkt 16 len 8 (issuer key ID 249B39D24F25E3B6) data: [2046 bits] gpg: assuming signed data in 'gnupg-2.1.17.tar.bz2' gpg: Signature made Tue Dec 20 14:59:50 2016 CET gpg: using RSA key 0x249B39D24F25E3B6 gpg: can't handle public key algorithm 22 gpg: using PGP trust model gpg: key 0x2D3EE2D42B255885: accepted as trusted key gpg: Good signature from "Werner Koch (dist sig)" [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 gpg: binary signature, digest algorithm SHA256 -- snap --- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 880 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Tue Dec 20 18:33:12 2016 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 20 Dec 2016 18:33:12 +0100 Subject: [Announce] GnuPG 2.1.17 released In-Reply-To: <4aaf714d-0327-d16d-b84f-7c1fa5f87815@dabpunkt.eu> References: <87inqeyh28.fsf@wheatstone.g10code.de> <20161220124623.GB1615@elch.exwg.net> <4aaf714d-0327-d16d-b84f-7c1fa5f87815@dabpunkt.eu> Message-ID: On 12/20/2016 04:21 PM, Daniel Baur wrote: > PS: What?s ?public key algorithm 22?? Elliptic Curves, specifically, EdDSA (in this case the warning is likely related to a signature on the key used for verification that is using Ed25519 which can't be verified by your client application) -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- Nulla regula sine exceptione No rule without exception -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From stebe at mailbox.org Tue Dec 20 18:50:00 2016 From: stebe at mailbox.org (Stephan Beck) Date: Tue, 20 Dec 2016 17:50:00 +0000 Subject: [Announce] GnuPG 2.1.17 released In-Reply-To: <20161220124623.GB1615@elch.exwg.net> References: <87inqeyh28.fsf@wheatstone.g10code.de> <20161220124623.GB1615@elch.exwg.net> Message-ID: <80dd59cf-ecc2-b5c5-6cae-0c6c2075443a@mailbox.org> Hi, Christoph Moench-Tegeder: > Hi, > > I believe there's something wrong with the signature of the latest > release. > > ## Werner Koch (wk at gnupg.org): > >> * 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.17.tar.bz2 you would use this command: >> >> gpg --verify gnupg-2.1.17.tar.bz2.sig gnupg-2.1.17.tar.bz2 > > This fails: > gpg: Signature made Tue Dec 20 11:33:11 2016 CET > gpg: using RSA key D8692123C4065DEA5E0F3AB5249B39D24F25E3B6 > gpg: BAD signature from "Werner Koch (dist sig)" [unknown] > using the command --recv-keys you have to retrieve the key D8692123C4065DEA5E0F3AB5249B39D24F25E3B6 from keyservers and then do the --verify again. If it's still BAD SIGNATURE then, you'll have a good reason for opening a new thread. :-) Note that you cannot verify a signature of a gnupg tarball if you do not have a (previous) version of gpg installed. In this case, you can only check the checksum, or use another system with gpg installed for verifying. Do not verify the signature using the gpg version you just downloaded. Well, that's all part of the text of the usual announce mail posted on this very list. Cheers Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From cmt at burggraben.net Tue Dec 20 19:08:56 2016 From: cmt at burggraben.net (Christoph Moench-Tegeder) Date: Tue, 20 Dec 2016 19:08:56 +0100 Subject: [Announce] GnuPG 2.1.17 released In-Reply-To: <20161220124623.GB1615@elch.exwg.net> References: <87inqeyh28.fsf@wheatstone.g10code.de> <20161220124623.GB1615@elch.exwg.net> Message-ID: <20161220180856.GC1615@elch.exwg.net> ## Christoph Moench-Tegeder (cmt at burggraben.net): > This fails: > gpg: Signature made Tue Dec 20 11:33:11 2016 CET Since then, this has been fixed: gpg: Signature made Tue Dec 20 14:59:50 2016 CET gpg: using RSA key D8692123C4065DEA5E0F3AB5249B39D24F25E3B6 gpg: Good signature from "Werner Koch (dist sig)" [unknown] Note the newer timestamp. Also, HTTP reports that the signature has been replaced: "Last-Modified: Tue, 20 Dec 2016 14:05:28 GMT" (Almost) everything is fine, Christoph -- Spare Space From wk at gnupg.org Tue Dec 20 19:24:42 2016 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Dec 2016 19:24:42 +0100 Subject: [Announce] GnuPG 2.1.17 released In-Reply-To: <20161220124623.GB1615@elch.exwg.net> (Christoph Moench-Tegeder's message of "Tue, 20 Dec 2016 13:46:23 +0100") References: <87inqeyh28.fsf@wheatstone.g10code.de> <20161220124623.GB1615@elch.exwg.net> Message-ID: <877f6uwj9x.fsf@wheatstone.g10code.de> On Tue, 20 Dec 2016 13:46, cmt at burggraben.net said: > I believe there's something wrong with the signature of the latest > release. Sorry, my fault. To create the signature I use gpg -sbvu SIGNINGKEY gnupg-2.1.17.tar.bz2 Today I forgot the -b and thus a non-detached signature was created (suffix .gpg). After realizing that I fixed that but probably I did gpg -sbvu SIGNINGKEY gnupg-2.1.17.tar.bz2.gpg which is obviously wrong. Then I copied gnupg-2.1.17.tar.bz2{,.sig} to the final locations. The end result is that the detached signature was over a binary signed tarball and not over the plain tarball. I can't prove that anymore because I deleted the .gpg files before I noticed that the signature were wrong. Before you ask: Yes, I should add a make target for signing. Actually I did this for the Windows installer's yesterday. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From htd+ml at fritha.org Tue Dec 20 18:21:21 2016 From: htd+ml at fritha.org (Heinz Diehl) Date: Tue, 20 Dec 2016 18:21:21 +0100 Subject: [Announce] GnuPG 2.1.17 released In-Reply-To: <20161220124623.GB1615@elch.exwg.net> References: <87inqeyh28.fsf@wheatstone.g10code.de> <20161220124623.GB1615@elch.exwg.net> Message-ID: <20161220172121.GA4111@fritha.org> On 20.12.2016, Christoph Moench-Tegeder wrote: > Or is that just me and a local issue? Most probably. For me, it works: [htd at chiara Downloads]$ gpg --verify gnupg-2.1.17.tar.bz2.sig gnupg-2.1.17.tar.bz2 gpg: Signature made Tue 20 Dec 2016 14:59:50 CET using RSA key ID 4F25E3B6 gpg: Good signature from "Werner Koch (dist sig)" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 From bjoern at schiessle.org Tue Dec 20 22:44:35 2016 From: bjoern at schiessle.org (Bjoern Schiessle) Date: Tue, 20 Dec 2016 22:44:35 +0100 Subject: publishing PGP keys in DNS Message-ID: <20161220224435.6892920c@potato.fritz.box> Hi all, I want to publish my GnuPG key in DNS, therefore I followed this Howto: http://www.gushi.org/make-dns-cert/HOWTO.html I can lookup the DNS entry and it looks OK to me: $ dig +short bjoern._pka.schiessle.org. TXT "v=pka1;fpr=244FCEB0CB099524B21FB8962378A753E2BF04F6;uri=https://www.schiessle.org/privacy/gpg-key.txt" But if I try to test it with gpg like described in the Howto: echo "foo" | gpg --no-default-keyring --keyring /tmp/gpg-$$ --encrypt --armor --auto-key-locate pka -r bjoern at schiessle.org I get this error: gpg: 0xE2BF04F6: skipped: No public key gpg: [stdin]: encryption failed: No public key Any idea what's wrong? Thanks! Bj?rn -- Bj?rn Schie?le www: http://www.schiessle.org twitter: @schiessle gnupg/pgp key: 0x0x2378A753E2BF04F6 verify: https://keybase.io/BeS fingerprint: 244F CEB0 CB09 9524 B21F B896 2378 A753 E2BF 04F6 From wk at gnupg.org Wed Dec 21 09:22:17 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 21 Dec 2016 09:22:17 +0100 Subject: publishing PGP keys in DNS In-Reply-To: <20161220224435.6892920c@potato.fritz.box> (Bjoern Schiessle's message of "Tue, 20 Dec 2016 22:44:35 +0100") References: <20161220224435.6892920c@potato.fritz.box> Message-ID: <87tw9xu1xi.fsf@wheatstone.g10code.de> Hi Bjoern, On Tue, 20 Dec 2016 22:44, bjoern at schiessle.org said: > I want to publish my GnuPG key in DNS, therefore I followed this Howto: > http://www.gushi.org/make-dns-cert/HOWTO.html I huess that this howto is too old. > $ dig +short bjoern._pka.schiessle.org. TXT > "v=pka1;fpr=244FCEB0CB099524B21FB8962378A753E2BF04F6;uri=https://www.schiessle.org/privacy/gpg-key.txt" With version 2.1.3 the PKA method was changed (it was never in widespread use): * gpg: New option --print-pka-records. Changed the PKA method to use CERT records and hashed names. [Update: --print-pka-records replaced in 2.1.14.] and in 2.1.14 * gpg: Removed options --print-dane-records and --print-pka-records. The new export options "export-pka" and "export-dane" can instead be used with the export command. Here is how you can create such records: $ gpg --export-options export-pka --export wk at gnupg.org $ORIGIN _pka.gnupg.org. ; ECAF7590EB3443B5C7CF3ACB6C7EE1B8621CC013 ; Werner Koch nq6t9teux7edsnwdksswydu4o9i5es3f TYPE37 \# 26 0006 0000 00 14 [...] [...] Anyway, I would suggest to avoid DNS and use the Web Key Directory instead. See . I can also offer to work with schokokeks.org to setup the whole thing for all their users. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From bjoern at schiessle.org Wed Dec 21 12:00:40 2016 From: bjoern at schiessle.org (Bjoern Schiessle) Date: Wed, 21 Dec 2016 12:00:40 +0100 Subject: publishing PGP keys in DNS In-Reply-To: <87tw9xu1xi.fsf@wheatstone.g10code.de> References: <20161220224435.6892920c@potato.fritz.box> <87tw9xu1xi.fsf@wheatstone.g10code.de> Message-ID: <20161221120040.5b9bfd8b@potato.fritz.box> Hi Werner, thanks for the explanation. On Wed, 21 Dec 2016 09:22:17 +0100 Werner Koch wrote: > > Anyway, I would suggest to avoid DNS and use the Web Key Directory > instead. See > . I > can also offer to work with schokokeks.org to setup the whole thing > for all their users. Yesterday I already set this up successfully for my domain (schiessle.org). I just thought that having the DNS record as well would be a nice addition. But then I will just keep the WKD if this is the recommended way. One more question to the WKD. I changed my gpg.conf to: auto-key-locate cert pka wkd keyserver Does this means that gpg will try to find a WKD and a corresponding public key automatically if I write a email to someone I don't have a public key yet? Or will the lookup happen if I receive a mail? Thanks! Bj?rn -- Bj?rn Schie?le www: http://www.schiessle.org twitter: @schiessle gnupg/pgp key: 0x0x2378A753E2BF04F6 verify: https://keybase.io/BeS fingerprint: 244F CEB0 CB09 9524 B21F B896 2378 A753 E2BF 04F6 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed Dec 21 12:46:31 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 21 Dec 2016 12:46:31 +0100 Subject: publishing PGP keys in DNS In-Reply-To: <20161221120040.5b9bfd8b@potato.fritz.box> (Bjoern Schiessle's message of "Wed, 21 Dec 2016 12:00:40 +0100") References: <20161220224435.6892920c@potato.fritz.box> <87tw9xu1xi.fsf@wheatstone.g10code.de> <20161221120040.5b9bfd8b@potato.fritz.box> Message-ID: <877f6ttsh4.fsf@wheatstone.g10code.de> On Wed, 21 Dec 2016 12:00, bjoern at schiessle.org said: > auto-key-locate cert pka wkd keyserver > > Does this means that gpg will try to find a WKD and a corresponding > public key automatically if I write a email to someone I don't have a > public key yet? Or will the lookup happen if I receive a mail? Right; but only as long as the key has been specified by mail address. First gpg looks into the local keyring, then tries to find a CERT record, then tries to get the fingerprint via PKA and downloads the key From the included URL or a configured keyserver, then it tries to locate via WKD, and finally b a simple keyserver search. I would suggest to use auto-key-locate wkd,dane,pka if you want to find keys for signature verification you can also use auto-key-retrieve to fetch a key from a keyserver. The drawback is that you need to wait for the keyserver. That latter will eventually be improved by using a lower timeout and queue the request for later background retrieval Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From jkt at kde.org Fri Dec 23 16:32:21 2016 From: jkt at kde.org (=?iso-8859-1?Q?Jan_Kundr=E1t?=) Date: Fri, 23 Dec 2016 16:32:21 +0100 Subject: gpg-agent 2.1.16 needs about 10s for initialization saying =?iso-8859-1?Q?need=5Fentropy_before_it_completes_its_first_op?= In-Reply-To: <015ddef7-3d59-42d4-9b50-a784952773f3@kde.org> References: <0b3a5bed-d26a-47b4-9cc4-ac24fbe0de9a@kde.org> <87twa0yxq5.fsf@wheatstone.g10code.de> <015ddef7-3d59-42d4-9b50-a784952773f3@kde.org> Message-ID: <1aa68760-a919-485b-956b-6a0ad3c9dc3f@kde.org> > I don't see any difference in behavior after updating to > libgpg-error-1.25 and `killall gpg-agent`. There are still at > least 10 seconds of this in watchgnupg: > > 4 - 13:09:53 gpg-agent[16749]: DBG: chan_9 -> S PROGRESS > need_entropy X 30 120 > 4 - 13:09:54 gpg-agent[16749]: DBG: chan_9 -> S PROGRESS > need_entropy X 120 120 Is there something else that can help point out the root cause of this regression? With kind regards, Jan -- Trojit?, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/ From guy.wyers at gmail.com Sat Dec 24 16:40:57 2016 From: guy.wyers at gmail.com (Guy Wyers) Date: Sat, 24 Dec 2016 16:40:57 +0100 Subject: Unable to import Private Key Message-ID: I'm using Gnupg2.0 and I'm in a situation where I need to restore my configuration. I have an ascii armored export of my private key which looks like -----BEGIN PGP PRIVATE KEY BLOCK----- Version: GnuPG v2 ... -----END PGP PRIVATE KEY BLOCK----- When I try to import his using "gpg --import", I get: gpg: no valid OpenPGP data found. gpg: Total number processed: 0 Any ideas? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Sun Dec 25 21:22:09 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 25 Dec 2016 15:22:09 -0500 Subject: Unable to import Private Key In-Reply-To: References: Message-ID: > Any ideas? Try verbose mode. gpg -v --import keyfile.asc If that doesn't give you enough information, try ultra-verbose mode: gpg -vv --import keyfile.asc From guy.wyers at gmail.com Mon Dec 26 10:34:40 2016 From: guy.wyers at gmail.com (Guy Wyers) Date: Mon, 26 Dec 2016 10:34:40 +0100 Subject: Unable to import Private Key In-Reply-To: References: Message-ID: Here is the output I get with the -vv option: gpg: armor: BEGIN PGP PRIVATE KEY BLOCK gpg: armor header: Version: GnuPG v2 # off=0 ctb=9d tag=7 hlen=3 plen=966 :secret sub key packet: version 4, algo 1, created 1481270099, expires 0 pkey[0]: [2048 bits] pkey[1]: [17 bits] iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: B7A9DC9B5F3CF65E protect count: 2883584 (182) protect IV: 9f aa 8f 73 4b 73 60 8c 9c a3 0c 57 a8 78 d7 cc skey[2]: [v4 protected] keyid: F46485A39A95FE89 # off=969 ctb=89 tag=2 hlen=3 plen=287 :signature packet: algo 1, keyid B1E1E404A5BBB5FB version 4, created 1481270099, md5len 0, sigclass 0x18 digest algo 8, begin of digest 3b fa hashed subpkt 2 len 4 (sig created 2016-12-09) hashed subpkt 27 len 1 (key flags: 0C) subpkt 16 len 8 (issuer key ID B1E1E404A5BBB5FB) data: [2048 bits] gpg: Total number processed: 0 Guy Wyers On Sun, Dec 25, 2016 at 9:22 PM, Robert J. Hansen wrote: > > Any ideas? > > Try verbose mode. > > gpg -v --import keyfile.asc > > If that doesn't give you enough information, try ultra-verbose mode: > > gpg -vv --import keyfile.asc > > > _______________________________________________ > 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 dgouttegattat at incenp.org Mon Dec 26 17:25:11 2016 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Mon, 26 Dec 2016 17:25:11 +0100 Subject: Unable to import Private Key In-Reply-To: References: Message-ID: On 12/26/2016 10:34 AM, Guy Wyers wrote: > Here is the output I get with the -vv option: Your file seems to contain only a private *sub* key. I don't think GnuPG can import such a file (I've just tested with a similar file on my system with GnuPG 2.1.17, I got a similar result). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From guy.wyers at gmail.com Mon Dec 26 18:52:17 2016 From: guy.wyers at gmail.com (Guy Wyers) Date: Mon, 26 Dec 2016 18:52:17 +0100 Subject: Unable to import Private Key In-Reply-To: References: Message-ID: That's what I feared looking at the output. Now, I have two questions: - Can I somehow recover from this? I guess that, at least theoretically, the public should be "derivable" from the private key? - How did I end up with this truncated export? As far as I remember -even if it was long long time ago- I followed the standard instructions for "storing my private key in a safe place". Guy Wyers On Mon, Dec 26, 2016 at 5:25 PM, Damien Goutte-Gattat < dgouttegattat at incenp.org> wrote: > On 12/26/2016 10:34 AM, Guy Wyers wrote: > >> Here is the output I get with the -vv option: >> > > Your file seems to contain only a private *sub* key. I don't think GnuPG > can import such a file (I've just tested with a similar file on my system > with GnuPG 2.1.17, I got a similar result). > > > _______________________________________________ > 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 dgouttegattat at incenp.org Mon Dec 26 22:21:37 2016 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Mon, 26 Dec 2016 22:21:37 +0100 Subject: Unable to import Private Key In-Reply-To: References: Message-ID: On 12/26/2016 06:52 PM, Guy Wyers wrote: > - Can I somehow recover from this? I guess that, at least theoretically, > the public should be "derivable" from the private key? The problem here is not that you are missing the public key (the public key *is* derivable from the private key, and GnuPG would automatically extract the public key upon importing the private key). The problem is that you are missing the secret *primary* key to which this secret subkey should be attached. If you do not have a backup of that primary key, I am not sure you will be able to recover. At least with GnuPG 2.1, it should be possible to re-attach the subkey to a new primary key (because GnuPG 2.1 allows to "create" a key from a pre-existing key if you know its keygrip), *but* the newly re-attached key would still have a different key creation time and thus a different key ID... meaning that it could not be used to decrypt messages encrypted to the original key. > - How did I end up with this truncated export? As far as I remember -even > if it was long long time ago- I followed the standard instructions for > "storing my private key in a safe place".M As far as I know, the only way to export a subkey only is to explicitly specify that subkey by its key ID with an appended '!', as in the following example: $ gpg2 --output backup.gpg --export-secret-keys '0xDECAFBAD!' Otherwise, GnuPG will always export the primary key and all its subkeys. What are those "standard instructions" you are referring to? If you were instructed to backup only your secret subkey instead of your entire private keyring, I am afraid you have been badly misled. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From guy.wyers at gmail.com Tue Dec 27 09:59:16 2016 From: guy.wyers at gmail.com (Guy Wyers) Date: Tue, 27 Dec 2016 09:59:16 +0100 Subject: Unable to import Private Key In-Reply-To: References: Message-ID: Thanks for the reply. At least I know where things stand now, which is not a good place :-( I guess this is another *fine* example of the principle that an insufficiently tested DR arrangement, will always break down when you need it. I'm still puzzled about this partial export, however. I'm quite sure that I made it using something like this: $ gpg2 -a --export-secret-keys [identifier] > private_key.asc Now the question as to what I used as identifier, I'm not sure. The most likely option is that I used the email address used to create the key and maybe a key identifier. I definitely have no recollection of using the exclamation mark '!' you mention. Could this be linked to using an earlier version of gpg? Or could it simply be a bug? The installation is running on a Synology, using GnuPG included in the SynoCommunity package (https://synocommunity.com/package/gnupg). Anyway, this looks like water under the bridge. Thanks for your help. -Guy On Mon, Dec 26, 2016 at 10:21 PM, Damien Goutte-Gattat < dgouttegattat at incenp.org> wrote: > On 12/26/2016 06:52 PM, Guy Wyers wrote: > >> - Can I somehow recover from this? I guess that, at least theoretically, >> the public should be "derivable" from the private key? >> > > The problem here is not that you are missing the public key (the public > key *is* derivable from the private key, and GnuPG would automatically > extract the public key upon importing the private key). > > The problem is that you are missing the secret *primary* key to which this > secret subkey should be attached. > > If you do not have a backup of that primary key, I am not sure you will be > able to recover. > > At least with GnuPG 2.1, it should be possible to re-attach the subkey to > a new primary key (because GnuPG 2.1 allows to "create" a key from a > pre-existing key if you know its keygrip), *but* the newly re-attached key > would still have a different key creation time and thus a different key > ID... meaning that it could not be used to decrypt messages encrypted to > the original key. > > > - How did I end up with this truncated export? As far as I remember -even >> if it was long long time ago- I followed the standard instructions for >> "storing my private key in a safe place".M >> > > As far as I know, the only way to export a subkey only is to explicitly > specify that subkey by its key ID with an appended '!', as in the following > example: > > $ gpg2 --output backup.gpg --export-secret-keys '0xDECAFBAD!' > > Otherwise, GnuPG will always export the primary key and all its subkeys. > > What are those "standard instructions" you are referring to? If you were > instructed to backup only your secret subkey instead of your entire private > keyring, I am afraid you have been badly misled. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 2014-667rhzu3dc-lists-groups at riseup.net Tue Dec 27 11:16:25 2016 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Tue, 27 Dec 2016 10:16:25 +0000 Subject: Unable to import Private Key In-Reply-To: References: Message-ID: <1407633450.20161227101625@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Monday 26 December 2016 at 9:21:37 PM, in , Damien Goutte-Gattat wrote:- > As far as I know, the only way to export a subkey > only is to explicitly > specify that subkey by its key ID with an appended > '!', The --export-secret-subkeys command will do what it says on the tin. - -- Best regards MFPA A fool and his money are soon partying -----BEGIN PGP SIGNATURE----- iL4EARYKAGYFAlhiP3xfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDMzQUNFRDRFRTkxMzRFRUJERTZBODUwNjE3 MTJCQzQ2MUFGNzc4RTQACgkQFxK8Rhr3eORcHgEA5C0Fu1fh64FZTwxjCWQ4C4f+ G8kckfBg5WrpcHwCyQQBAId0/YO4wxMFDMa0HQdXN9p9wqpNqxPYlFzD3wFVmUgJ iQF8BAEBCgBmBQJYYj+BXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXweMQH/jnYOyPZWIdNPglJKV28Qhmq SAxXJGJ67VsTmFCpeFWZehA5dNYS4rDTbGJhhJKWfkb2uwMAxe/orfQUg9etcyH/ GWB2Ah3kPwRGIQnF/AJ1CfVecMN4QO2tOHwdvM3ud1j5ZsmNscvNXmiKy+iCs18f hnHRGhSWhkAUECCJLmNsidnFMs0WFzNkLs1HzFq+iU5svxYGu2xdgMwhNnDjfdQT 3cZIpXfkO31kqCVxlWjG08X10J2yPOviBq3tdD7dUH5aL5kh0+0iUrwCSQbGqOuK oq+WW1CiwAP5cg6SWDrFjVtlhMG8UAR7gFgHc7Kxt+g/vM31naVrr8yEAoMOCk0= =Pi36 -----END PGP SIGNATURE----- From dgouttegattat at incenp.org Tue Dec 27 11:29:35 2016 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Tue, 27 Dec 2016 11:29:35 +0100 Subject: Unable to import Private Key In-Reply-To: <1407633450.20161227101625@riseup.net> References: <1407633450.20161227101625@riseup.net> Message-ID: <0d574fac-8c03-ba25-a166-ccc6a47d96a4@incenp.org> On 12/27/2016 11:16 AM, MFPA wrote: > The --export-secret-subkeys command will do what it says on the tin. That option would still generate a secret key packet for the primary key, it's just that this packet would not actually contain any key material. Here, what has been generated is a file containing only a secret subkey packet (and the associated binding signature). That's not the result of using --export-secret-subkeys. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From dsaklad at gnu.org Tue Dec 27 22:09:35 2016 From: dsaklad at gnu.org (Don Warner Saklad) Date: Tue, 27 Dec 2016 16:09:35 -0500 Subject: ? Comments re key servers? re gpg-encrypted mail? re key servers carry many phony keys? Message-ID: <5itw9prsds.fsf@fencepost.gnu.org> What do you kind folks out there make of comments at https://stallman.org/gpg.html >"I'm told that key servers carry many phony keys claiming to be mine. Here is info about which keys are really mine." >"Of course, to be really sure which key is mine, you need to get my key fingerprint from me or follow a chain of signatures. If a phony key appears to be signed by someone you trust, you should see what's up with that person." and 4th sentence from the top at https://stallman.org >"If you want to send me GPG-encrypted mail, do not trust key servers! Some of them have phony keys under my name and email address, made by someone else as a trick. See gpg.html for my real key." From ndk.clanbo at gmail.com Tue Dec 27 22:54:23 2016 From: ndk.clanbo at gmail.com (NdK) Date: Tue, 27 Dec 2016 22:54:23 +0100 Subject: ? Comments re key servers? re gpg-encrypted mail? re key servers carry many phony keys? In-Reply-To: <5itw9prsds.fsf@fencepost.gnu.org> References: <5itw9prsds.fsf@fencepost.gnu.org> Message-ID: <6ac3703c-151e-f413-00b7-1996269c29ed@gmail.com> Il 27/12/2016 22:09, Don Warner Saklad ha scritto: > What do you kind folks out there make of comments at > https://stallman.org/gpg.html > >"I'm told that key servers carry many phony keys claiming to be > mine. Here is info about which keys are really mine." > > >"Of course, to be really sure which key is mine, you need to get my > key fingerprint from me or follow a chain of signatures. If a phony > key appears to be signed by someone you trust, you should see what's > up with that person." > > > and 4th sentence from the top at > https://stallman.org > >"If you want to send me GPG-encrypted mail, do not trust key servers! > Some of them have phony keys under my name and email address, made by > someone else as a trick. See gpg.html for my real key." Why do you find it strange? Keyservers are just public write-only repositories that do not attempt to verify the keys. You have to verify the keys via the WoT (web of trust: "follow a chain of signatures"), or by other means ("see gpg.html for my real key"), and that's what Stallman says. Better do both: check that the chain identifies the key given in gpg.html (must be retrieved via https). BYtE, Diego From rjh at sixdemonbag.org Tue Dec 27 23:06:11 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 27 Dec 2016 17:06:11 -0500 Subject: ? Comments re key servers? re gpg-encrypted mail? re key servers carry many phony keys? In-Reply-To: <5itw9prsds.fsf@fencepost.gnu.org> References: <5itw9prsds.fsf@fencepost.gnu.org> Message-ID: <052401d2608d$6f6745e0$4e35d1a0$@sixdemonbag.org> > What do you kind folks out there make of comments at > https://stallman.org/gpg.html Completely orthodox. Certificates retrieved through the keyserver network should not be trusted until/unless verified. Some people are moving to embrace TOFU, which changes these rules somewhat. For my money, though, I don't (and won't) use TOFU. From antony at blazrsoft.com Tue Dec 27 22:46:00 2016 From: antony at blazrsoft.com (antony at blazrsoft.com) Date: Tue, 27 Dec 2016 16:46:00 -0500 Subject: ? Comments re key servers? re gpg-encrypted mail? re key servers carry many phony keys? In-Reply-To: <5itw9prsds.fsf@fencepost.gnu.org> References: <5itw9prsds.fsf@fencepost.gnu.org> Message-ID: <22FF8EF2-9EFC-48D8-9F14-F2F5374A853D@blazrsoft.com> On December 27, 2016 4:09:35 PM EST, Don Warner Saklad wrote: >What do you kind folks out there make of comments at >https://stallman.org/gpg.html > >"I'm told that key servers carry many phony keys claiming to be > mine. Here is info about which keys are really mine." > > >"Of course, to be really sure which key is mine, you need to get my > key fingerprint from me or follow a chain of signatures. If a phony > key appears to be signed by someone you trust, you should see what's > up with that person." > > >and 4th sentence from the top at >https://stallman.org > >"If you want to send me GPG-encrypted mail, do not trust key servers! > Some of them have phony keys under my name and email address, made by > someone else as a trick. See gpg.html for my real key." > >_______________________________________________ >Gnupg-users mailing list >Gnupg-users at gnupg.org >http://lists.gnupg.org/mailman/listinfo/gnupg-users Well, keys on keyservers never provide any assurance that they belong to the owner. There always needs to be some kind of verification done out of band to ensure that the key belongs to who you think it does. Whether that be fingerprint matching or actually physically meeting them and signing each other's keys after identity verification, etc. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From miro.rovis at croatiafidelis.hr Wed Dec 28 11:43:43 2016 From: miro.rovis at croatiafidelis.hr (Miroslav Rovis) Date: Wed, 28 Dec 2016 11:43:43 +0100 Subject: ? Comments re key servers? re gpg-encrypted mail? re key servers carry many phony keys? In-Reply-To: <6ac3703c-151e-f413-00b7-1996269c29ed@gmail.com> References: <5itw9prsds.fsf@fencepost.gnu.org> <6ac3703c-151e-f413-00b7-1996269c29ed@gmail.com> Message-ID: <20161228104343.GA19104@g0n.xdwgrp> On 161227-22:54+0100, NdK wrote: > Il 27/12/2016 22:09, Don Warner Saklad ha scritto: > > What do you kind folks out there make of comments at > > https://stallman.org/gpg.html > > >"I'm told that key servers carry many phony keys claiming to be > > mine. Here is info about which keys are really mine." > > > > >"Of course, to be really sure which key is mine, you need to get my > > key fingerprint from me or follow a chain of signatures. If a phony > > key appears to be signed by someone you trust, you should see what's > > up with that person." > > > > > > and 4th sentence from the top at > > https://stallman.org > > >"If you want to send me GPG-encrypted mail, do not trust key servers! > > Some of them have phony keys under my name and email address, made by > > someone else as a trick. See gpg.html for my real key." > Why do you find it strange? > Keyservers are just public write-only repositories that do not attempt > to verify the keys. > You have to verify the keys via the WoT (web of trust: "follow a chain > of signatures"), or by other means ("see gpg.html for my real key"), and > that's what Stallman says. Better do both: check that the chain > identifies the key given in gpg.html (must be retrieved via https). > It's a different topic, but it might have the unreliability of keyservers for its justification: The fact that Github, since this outgoing year, accept gpg signing only if you post your public key to their servers. Or does it? Is it more like Github wants to collect and control? I know it was possible to: $ cd $ git tag -s $ git push --tags and all was there, signed and verifiable for everbody, without the need to have previously posted your own public key to github.com. Up until just last year, IIRC. Any ideas for true reasons behind that move? And is it an improvement, or quite the contrary? -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Digital signature URL: From miro.rovis at croatiafidelis.hr Wed Dec 28 13:28:15 2016 From: miro.rovis at croatiafidelis.hr (Miroslav Rovis) Date: Wed, 28 Dec 2016 13:28:15 +0100 Subject: ? Comments re key servers? re gpg-encrypted mail? re key servers carry many phony keys? In-Reply-To: <20161228104343.GA19104@g0n.xdwgrp> References: <5itw9prsds.fsf@fencepost.gnu.org> <6ac3703c-151e-f413-00b7-1996269c29ed@gmail.com> <20161228104343.GA19104@g0n.xdwgrp> Message-ID: <20161228122815.GA19720@g0n.xdwgrp> On 161228-11:43+0100, Miroslav Rovis wrote: ... > > The fact that Github, since this outgoing year, accept gpg signing only > if you post your public key to their servers. Just some quick links in connection, for the less familiar. For users (like me): https://help.github.com/categories/gpg/ For developers (I can't make much of it): https://developer.github.com/v3/users/gpg_keys/ -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Digital signature URL: From ndk.clanbo at gmail.com Wed Dec 28 15:42:00 2016 From: ndk.clanbo at gmail.com (NdK) Date: Wed, 28 Dec 2016 15:42:00 +0100 Subject: ? Comments re key servers? re gpg-encrypted mail? re key servers carry many phony keys? In-Reply-To: <20161228122815.GA19720@g0n.xdwgrp> References: <5itw9prsds.fsf@fencepost.gnu.org> <6ac3703c-151e-f413-00b7-1996269c29ed@gmail.com> <20161228104343.GA19104@g0n.xdwgrp> <20161228122815.GA19720@g0n.xdwgrp> Message-ID: <97d82431-f4a5-d815-3f93-df8078aa93e8@gmail.com> Il 28/12/2016 13:28, Miroslav Rovis ha scritto: >> The fact that Github, since this outgoing year, accept gpg signing only >> if you post your public key to their servers. I can't say for sure, but maybe that's so so they can have an "attestation key" to use for verifying signatures, without expensive WoT checks. By loading your key, you're certifying it's yours. But it won't actually give any more assurance than "you is you" than your credentials (against GitHub): if someone steals your credentials, he can replace your pub key and sign new commits in your name. They're using GPG just as a frontend for signatures using self-signed certificates. BTW nothing prevents you from uploading your key to the keyservers and participate in the WoT -- that's the only thing that could assure who clones your repo that *you* signed those commits. Sometimes just "key persistence" is important (i.o.w. that the key that signed all the commits has always been the same, and in this case GitHub loaded key can be enough), other times it could be important to link the key used for signing a commit to (the reputation of) a real person, and in this case the WoT is needed. > Just some quick links in connection, for the less familiar. > For users (like me): > https://help.github.com/categories/gpg/ Some reccomendations could be quite questionable (always use RSA 4096, do not set an expiry on main key, no mention of generating a revocation certificate...). BYtE, Diego From xinayder at airmail.cc Wed Dec 28 17:04:23 2016 From: xinayder at airmail.cc (Alexandre Oliveira) Date: Wed, 28 Dec 2016 14:04:23 -0200 Subject: ? Comments re key servers? re gpg-encrypted mail? re key servers carry many phony keys? In-Reply-To: <20161228104343.GA19104@g0n.xdwgrp> References: <5itw9prsds.fsf@fencepost.gnu.org> <6ac3703c-151e-f413-00b7-1996269c29ed@gmail.com> <20161228104343.GA19104@g0n.xdwgrp> Message-ID: On 28/12/2016 08:43, Miroslav Rovis wrote: > > It's a different topic, but it might have the unreliability of > keyservers for its justification: > > The fact that Github, since this outgoing year, accept gpg signing only > if you post your public key to their servers. > > Or does it? Is it more like Github wants to collect and control? > > I know it was possible to: > > $ cd > $ git tag -s > $ git push --tags > > and all was there, signed and verifiable for everbody, without the need > to have previously posted your own public key to github.com. Up until > just last year, IIRC. > > Any ideas for true reasons behind that move? And is it an improvement, > or quite the contrary? > Until this year there was no way to verify the signature of commits and releases through the GitHub website, so they created a "kind of" keyserver in their own server to manage users public keys. -- Alexandre Oliveira 167F D82F 514A E8D1 2E9E C62D 1B63 9D4A 7E9D DA9D From doark at mail.com Mon Dec 26 03:50:59 2016 From: doark at mail.com (doark at mail.com) Date: Sun, 25 Dec 2016 21:50:59 -0500 Subject: Gpg key lost in self update Message-ID: <20161225215059.46dce91a@ulgy_thing> Hello, I used a config file (hand written), and concatenated several of it's lines to form a super long strong passphrase for my key. Bad news is that I foolishly changed the file and lack an old enough backup to find the original one. Now, I've read that you could use a program to crack the private key and I'd rather not create a new key since my original was never compromised. Do you know of any I might use? Thanks, David From rjh at sixdemonbag.org Wed Dec 28 22:40:18 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 28 Dec 2016 16:40:18 -0500 Subject: Gpg key lost in self update In-Reply-To: <20161225215059.46dce91a@ulgy_thing> References: <20161225215059.46dce91a@ulgy_thing> Message-ID: <05c901d26152$fc77ae00$f5670a00$@sixdemonbag.org> > Now, I've read that you could use a program to crack the private key and I'd > rather not create a new key since my original was never compromised. For a strong passphrase, there is no effective way to crack it. Sorry, you're SOL. From 2014-667rhzu3dc-lists-groups at riseup.net Thu Dec 29 13:37:03 2016 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Thu, 29 Dec 2016 12:37:03 +0000 Subject: How to prevent passphrase caching in 2.1 In-Reply-To: <20161127171555.A1137100B022@remailer.paranoici.org> References: <20161120211814.CDD7C100A216@remailer.paranoici.org> <87fumlnpro.fsf@wheatstone.g10code.de> <20161122162026.CF0C2100B129@remailer.paranoici.org> <915f84a9-2b95-75eb-3ffa-d79f8ae5d000@digitalbrains.com> <20161123022836.845501032265@remailer.paranoici.org> <87d1hifark.fsf@wheatstone.g10code.de> <20161127171555.A1137100B022@remailer.paranoici.org> Message-ID: <947121270.20161229123703@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Sunday 27 November 2016 at 5:15:55 PM, in , Carola Grunwald wrote:- > But no, unfortunately it's a Windows server > application with GnuPG, Tor, > Mixmaster and Hamster embedded. And in a server > environment it's > problematic to switch system time back and forth, Have you tried RunAsDate? "RunAsDate intercepts the kernel API calls that returns the current date and time (GetSystemTime, GetLocalTime, GetSystemTimeAsFileTime), and replaces the current date/time with the date/time that you specify." (Note: I originally sent this reply a month ago, but I just noticed my email provider had refused it "due to content violation". It turns out they do not like the URL you will now get as the first search result on the search URL I have substituted above.) - -- Best regards MFPA No matter where you go, there you are. -----BEGIN PGP SIGNATURE----- iL4EARYKAGYFAlhlA3hfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDMzQUNFRDRFRTkxMzRFRUJERTZBODUwNjE3 MTJCQzQ2MUFGNzc4RTQACgkQFxK8Rhr3eOQb0wEAynsvFDTWpdevGNOzZh0A/7XZ zYI4HBGEQNW6qhaoC+QBAI2GYnNRxm+1Vf76s074ERWOYwxjZA43wPMCL+pmnVkI iQF8BAEBCgBmBQJYZQOIXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwvkEH/RfSfowj9j/Bfc/zY8QTpEOo tcKaSOcPuOnPU8n0m/usEX8N/LzQ6Obl4jDWJwzWTQYZmstU6rWWM7byPd8vOPxZ Pmlg8NRybb8cojXSNQn7j/j6ybael+93NUClbeG3dZYKwnHIQkuuqUh2kH+0ySks i4xepeQzQivm6X/kQAiP9FfveGQ+RzOEmI9SKQ5HDHFjqI+qRUYckR6FRHnpF7cV GokjdjbGcU7WBnpjwD4nw2s2mq/qS+Is9JSaX8Z3Qf3jqsf9pkWE1apDZhKzDFL6 5smmNyteE3z6pjzPwgZxzkyT0EGar9CkxcRcn5UIlzMOWUfXj8oYxAsvXDxn1Mw= =Rvt+ -----END PGP SIGNATURE----- From miro.rovis at croatiafidelis.hr Fri Dec 30 01:35:15 2016 From: miro.rovis at croatiafidelis.hr (Miroslav Rovis) Date: Fri, 30 Dec 2016 01:35:15 +0100 Subject: ? Comments re key servers? re gpg-encrypted mail? re key servers carry many phony keys? In-Reply-To: <97d82431-f4a5-d815-3f93-df8078aa93e8@gmail.com> References: <5itw9prsds.fsf@fencepost.gnu.org> <6ac3703c-151e-f413-00b7-1996269c29ed@gmail.com> <20161228104343.GA19104@g0n.xdwgrp> <20161228122815.GA19720@g0n.xdwgrp> <97d82431-f4a5-d815-3f93-df8078aa93e8@gmail.com> Message-ID: <20161230003515.GA12603@g0n.xdwgrp> On 161228-15:42+0100, NdK wrote: > Il 28/12/2016 13:28, Miroslav Rovis ha scritto: > > >> The fact that Github, since this outgoing year, accept gpg signing only > >> if you post your public key to their servers. > I can't say for sure, but maybe that's so so they can have an > "attestation key" to use for verifying signatures, without expensive WoT > checks. Why would that be expensive? Expensive is the tracking that they let the Schmoog (y'know Schmoog the Schmoogle) do on their users... Have a look at (sorry for the title, just moved to Pale Moon): In Defence of Firefox: some Harvesting by Referal Decrypted https://forums.gentoo.org/viewtopic-t-1038896.html (where not all I could post, as my password I would revealed) Expensive (time, resources on them and on users) is the tracking... > > BTW nothing prevents you from uploading your key to the keyservers and > participate in the WoT -- that's the only thing that could assure who > clones your repo that *you* signed those commits. My keys have been since long on keyservers, but too little, and insignificant programming, I do, to have it had signed by others, yet. > > > Just some quick links in connection, for the less familiar. > > For users (like me): > > https://help.github.com/categories/gpg/ > Some reccomendations could be quite questionable (always use RSA 4096, > do not set an expiry on main key, no mention of generating a revocation > certificate...). Of course, have been using RSA since a few years back, and other things, only late to update to gnupg-2, haven't had time... Missing the funcionalities, now that I really understand ever better about it, and understood that I can trust Werner Koch, Neit Walfield ( why aren't they teaching people this: An Advanced Intro to GnuPG https://begriffs.com/posts/2016-11-05-advanced-intro-gnupg.html Exampli gratia, I can't read it all now (need to give it a re-read, but is there a suggestion in my home distro, so to call it, since 8 yrs + with it, that you get poor security if you just keep yout secret key in ~/.gnupg/ ? Is there, if any Gentooer is reading this? ... ) , and the team and what they do. And also Alexandre Olive replied (pasting his mail in here manually): > Until this year there was no way to verify the signature of commits > and releases through the GitHub website, so they created a "kind of" > keyserver in their own server to manage users public keys. No, there was no way to do so in GUI, but that's not such great advantage to have it, and you have to paste your public key, as if they couldn't get it from good keyservers, that certainly don't track people so much, such as: https://sks-keyservers.net/i/ and https://pgp.mit.edu/ Before, when your git repo, or somebody else's had a tag signed, you get the public key anywhere, and you clone the repo, and you can verify it, you didn't need a GUI... Have to go back to other work, regards! -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Digital signature URL: From jufabre at yahoo.com Fri Dec 30 00:43:15 2016 From: jufabre at yahoo.com (Jussi Fabre) Date: Thu, 29 Dec 2016 23:43:15 +0000 (UTC) Subject: informations on installation ubuntu 16.04 References: <488108398.3500821.1483054995700.ref@mail.yahoo.com> Message-ID: <488108398.3500821.1483054995700@mail.yahoo.com> hello, I try to install this software. Here are what is happening. checking for stdint.h... (cached) yeschecking for long long int... (cached) yeschecking for long double... yeschecking for intmax_t... yeschecking for uintmax_t... yeschecking for ptrdiff_t... yeschecking size of unsigned long... (cached) 8checking size of void *... 8checking for nl_langinfo and THOUSANDS_SEP... yesconfigure: checking system features for estreamconfigure:****** You need libgpg-error to build this program.** ?This library is for example available at*** ? ftp://ftp.gnupg.org/gcrypt/libgpg-error*** (at least version 1.11 is required.)***configure:****** You need libgcrypt to build this program.** ?This library is for example available at*** ? ftp://ftp.gnupg.org/gcrypt/libgcrypt/*** (at least version 1.5.0 using API 1 is required.)***configure:****** You need libassuan to build this program.*** This library is for example available at*** ? ftp://ftp.gnupg.org/gcrypt/libassuan/*** (at least version 2.0.0 (API 2) is required).***configure:****** You need libksba to build this program.*** This library is for example available at*** ? ftp://ftp.gnupg.org/gcrypt/libksba/*** (at least version 1.0.7 using API 1 is required).***configure:****** It is now required to build with support for the*** GNU Portable Threads Library (Pth). Please install this*** library first. ?The library is for example available at*** ? ftp://ftp.gnu.org/gnu/pth/*** On a Debian GNU/Linux system you can install it using*** ? apt-get install libpth-dev*** To build GnuPG for Windows you need to use the W32PTH*** package; available at:*** ? ftp://ftp.g10code.com/g10code/w32pth/***configure:****** The zlib compression library is required.*** Please install a suitable development package*** (e.g. Debian package zlib1g-dev) or download*** it from http://zlib.net and build yourself.***configure: error:?****** Required libraries not found. Please consult the above messages*** and install them before running configure again.***abcdef at abcdef-HP-Pavilion-17-Notebook-PC:~/Downloads/gnupg-2.0.30$ makemake: *** No targets specified and no makefile found. ?Stop.abcdef at abcdef-HP-Pavilion-17-Notebook-PC:~/Downloads/gnupg-2.0.30$ make installmake: *** No rule to make target 'install'. ?Stop.abcdef at abcdef-HP-Pavilion-17-Notebook-PC:~/Downloads/gnupg-2.0.30$ sudo makemake: *** No targets specified and no makefile found. ?Stop.abcdef at abcdef-HP-Pavilion-17-Notebook-PC:~/Downloads/gnupg-2.0.30$ make installmake: *** No rule to make target 'install'. ?Stop.abcdef at abcdef-HP-Pavilion-17-Notebook-PC:~/Downloads/gnupg-2.0.30$? ---------------------------------------------------------- Please can you advise what to do ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From miro.rovis at croatiafidelis.hr Fri Dec 30 02:39:56 2016 From: miro.rovis at croatiafidelis.hr (Miroslav Rovis) Date: Fri, 30 Dec 2016 02:39:56 +0100 Subject: informations on installation ubuntu 16.04 In-Reply-To: <488108398.3500821.1483054995700@mail.yahoo.com> References: <488108398.3500821.1483054995700.ref@mail.yahoo.com> <488108398.3500821.1483054995700@mail.yahoo.com> Message-ID: <20161230013956.GC12603@g0n.xdwgrp> Just one thing. It's hard to read the Yahoo HTML-emails. If you can (haven't used Yahoo in years), set it to (proper) text email. You'll see how it shows on, say: https://marc.info/?l=gnupg-users&r=1&b=201612&w=2 when it is posted there, which is not yet. It likely will show like below, which is in my Mutt mail client. Ah, see how it shows on: https://lists.gnupg.org/pipermail/gnupg-users/2016-December/057388.html On 161229-23:43+0000, Jussi Fabre wrote: > hello, > > I try to install this software. Here are what is happening. > checking for stdint.h... (cached) yeschecking for long long int... (cached) yeschecking for long double... yeschecking for intmax_t... yeschecking for uintmax_t... yeschecking for ptrdiff_t... yeschecking size of unsigned long... (cached) 8checking size of void *... 8checking for nl_langinfo and THOUSANDS_SEP... yesconfigure: checking system features for estreamconfigure:****** You need libgpg-error to build this program.** ?This library is for example available at*** ? ftp://ftp.gnupg.org/gcrypt/libgpg-error*** (at least version 1.11 is required.)***configure:****** You need libgcrypt to build this program.** ?This library is for example available at*** ? ftp://ftp.gnupg.org/gcrypt/libgcrypt/*** (at least version 1.5.0 using API 1 is required.)***configure:****** You need libassuan to build this program.*** This library is for example available at*** ? ftp://ftp.gnupg.org/gcrypt/libassuan/*** (at least version 2.0.0 (API 2) is required).***configure:****** You need libksba to build this program.*** This library is for example available at*** ? ftp://ftp.gnupg.org/gcrypt/libksba/*** (at least version 1.0.7 using API 1 is required).***configure:****** It is now required to build with support for the*** GNU Portable Threads Library (Pth). Please install this*** library first. ?The library is for example available at*** ? ftp://ftp.gnu.org/gnu/pth/*** On a Debian GNU/Linux system you can install it using*** ? apt-get install libpth-dev*** To build GnuPG for Windows you need to use the W32PTH*** package; available at:*** ? ftp://ftp.g10code.com/g10code/w32pth/***configure:****** The zlib compression library is required.*** Please install a suitable development package*** (e.g. Debian package zlib1g-dev) or download*** it from http://zlib.net and build yourself.***configure: error:?****** Required libraries not found. Please consult the above messages*** and install them before running configure again.***abcdef at abcdef-HP-Pavilion-17-Notebook-PC:~/Downloads/gnupg-2.0.30$ makemake: *** No targets specified and no makefile found. ?Stop.abcdef at abcdef-HP-Pavilion-17-Notebook-PC:~/Downloads/gnupg-2.0.30$ make installmake: *** No rule to make target 'install'. ?Stop.abcdef at abcdef-HP-Pavilion-17-Notebook-PC:~/Downloads/gnupg-2.0.30$ sudo makemake: *** No targets specified and no makefile found. ?Stop.abcdef at abcdef-HP-Pavilion-17-Notebook-PC:~/Downloads/gnupg-2.0.30$ make installmake: *** No rule to make target 'install'. ?Stop.abcdef at abcdef-HP-Pavilion-17-Notebook-PC:~/Downloads/gnupg-2.0.30$? > Regards! -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Digital signature URL: From ricul77 at gmail.com Fri Dec 30 13:15:14 2016 From: ricul77 at gmail.com (Richard Ulrich) Date: Fri, 30 Dec 2016 13:15:14 +0100 Subject: Proof for a creation date In-Reply-To: <20161202021250.GA69543@becker.bs.l> References: <20161202021250.GA69543@becker.bs.l> Message-ID: <1483100114.3137.1.camel@gmail.com> Hi Bertram, sorry for the late answer.? Blockchain was mentioned in some answers, but nothing in concrete. Check this out: https://github.com/opentimestamps Rgds Richard Am Freitag, den 02.12.2016, 03:12 +0100 schrieb Bertram Scharpf: > Hi, > > we all know that kidnappers do publish a picture of their > hostage holding up a todays newpaper. The purpose of this is > to proof that the victim was alive _after_ a certain point > of time. I want to do the opposite. I want to make evidence > that I created a document _before_ a certain point of time. > > I could use self-darkening ink but that won't be reflected > in a JPEG scan and my pen won't make the job that TeX does. > I could sign a newspapers home page but that cannot be > reproduced at a later point of time to verify the signature. > > Is there a standard way in GnuPG and in the keyholder > infrastructure to accomplish this task? > > Thanks in advance. > > Bertram > > -------------- 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 jufabre at yahoo.com Fri Dec 30 15:47:27 2016 From: jufabre at yahoo.com (Jussi Fabre) Date: Fri, 30 Dec 2016 14:47:27 +0000 (UTC) Subject: ubuntu installation failure. References: <1105011655.3741770.1483109247484.ref@mail.yahoo.com> Message-ID: <1105011655.3741770.1483109247484@mail.yahoo.com> ok will now repost this email. so failure on installation, here is output of ubuntu. Anybody willing to help me pls ? Thnx ------------------------------------- ello, I try to install this software. Here are what is happening. checking for stdint.h... (cached) yes checking for long long int... (cached) yes checking for long double... yes checking for intmax_t... yes checking for uintmax_t... yes checking for ptrdiff_t... yes checking size of unsigned long... (cached) 8 checking size of void *... 8 checking for nl_langinfo and THOUSANDS_SEP... yes configure: checking system features for estream configure: *** *** You need libgpg-error to build this program. ** This library is for example available at *** ftp://ftp.gnupg.org/gcrypt/libgpg-error *** (at least version 1.11 is required.) *** configure: *** *** You need libgcrypt to build this program. ** This library is for example available at *** ftp://ftp.gnupg.org/gcrypt/libgcrypt/ *** (at least version 1.5.0 using API 1 is required.) *** configure: *** *** You need libassuan to build this program. *** This library is for example available at *** ftp://ftp.gnupg.org/gcrypt/libassuan/ *** (at least version 2.0.0 (API 2) is required). *** configure: *** *** You need libksba to build this program. *** This library is for example available at *** ftp://ftp.gnupg.org/gcrypt/libksba/ *** (at least version 1.0.7 using API 1 is required). *** configure: *** *** It is now required to build with support for the *** GNU Portable Threads Library (Pth). Please install this *** library first. The library is for example available at *** ftp://ftp.gnu.org/gnu/pth/ *** On a Debian GNU/Linux system you can install it using *** apt-get install libpth-dev *** To build GnuPG for Windows you need to use the W32PTH *** package; available at: *** ftp://ftp.g10code.com/g10code/w32pth/ *** configure: *** *** The zlib compression library is required. *** Please install a suitable development package *** (e.g. Debian package zlib1g-dev) or download *** it from http://zlib.net and build yourself. *** configure: error: *** *** Required libraries not found. Please consult the above messages *** and install them before running configure again. *** abcdef at abcdef-HP-Pavilion-17-Notebook-PC:~/Downloads/gnupg-2.0.30$ make make: *** No targets specified and no makefile found. Stop. abcdef at abcdef-HP-Pavilion-17-Notebook-PC:~/Downloads/gnupg-2.0.30$ make install make: *** No rule to make target 'install'. Stop. abcdef at abcdef-HP-Pavilion-17-Notebook-PC:~/Downloads/gnupg-2.0.30$ sudo make make: *** No targets specified and no makefile found. Stop. abcdef at abcdef-HP-Pavilion-17-Notebook-PC:~/Downloads/gnupg-2.0.30$ make install make: *** No rule to make target 'install'. Stop. abcdef at abcdef-HP-Pavilion-17-Notebook-PC:~/Downloads/gnupg-2.0.30$ ---------------------------------------------------------- Please can you advise what to do ? From jufabre at yahoo.com Fri Dec 30 16:16:28 2016 From: jufabre at yahoo.com (Jussi Fabre) Date: Fri, 30 Dec 2016 15:16:28 +0000 (UTC) Subject: ubuntu installation failure. In-Reply-To: <004d01d262ae$60757e30$21607a90$@sixdemonbag.org> References: <1105011655.3741770.1483109247484.ref@mail.yahoo.com> <1105011655.3741770.1483109247484@mail.yahoo.com> <004d01d262ae$60757e30$21607a90$@sixdemonbag.org> Message-ID: <529221138.3766475.1483110988307@mail.yahoo.com> thx :) On Friday, December 30, 2016 5:06 PM, Robert J. Hansen wrote: > so failure on installation, here is output of ubuntu. Anybody willing to help > me pls ? Why are you installing 2.0.30 from source? GnuPG 2 is already available in the package repositories. $ sudo apt-get update $ sudo apt-get upgrade $ sudo apt-get install gnupg2 Current Ubuntu stable, Yakkety Yak, ships with 2.1.15, I think, so it's even considerably newer than 2.0.30. From rjh at sixdemonbag.org Fri Dec 30 16:07:01 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 30 Dec 2016 10:07:01 -0500 Subject: ubuntu installation failure. In-Reply-To: <1105011655.3741770.1483109247484@mail.yahoo.com> References: <1105011655.3741770.1483109247484.ref@mail.yahoo.com> <1105011655.3741770.1483109247484@mail.yahoo.com> Message-ID: <004d01d262ae$60757e30$21607a90$@sixdemonbag.org> > so failure on installation, here is output of ubuntu. Anybody willing to help > me pls ? Why are you installing 2.0.30 from source? GnuPG 2 is already available in the package repositories. $ sudo apt-get update $ sudo apt-get upgrade $ sudo apt-get install gnupg2 Current Ubuntu stable, Yakkety Yak, ships with 2.1.15, I think, so it's even considerably newer than 2.0.30. From guy.wyers at gmail.com Sat Dec 31 11:22:35 2016 From: guy.wyers at gmail.com (Guy Wyers) Date: Sat, 31 Dec 2016 11:22:35 +0100 Subject: Unable to import Private Key In-Reply-To: <0d574fac-8c03-ba25-a166-ccc6a47d96a4@incenp.org> References: <1407633450.20161227101625@riseup.net> <0d574fac-8c03-ba25-a166-ccc6a47d96a4@incenp.org> Message-ID: Hey guys, Interesting development: I rebuilt my whole setup, generated a new keypair etc. and am now in the process of creating another copy of the secret key for safekeeping and back-up purposes. And lo and behold: the problem reappeared, so I'm now in a position to reproduce the problem. The export command I'm using produces again a truncated result. By that I mean that the export I'm doing right now again produces a file that only contains part of the data, just like the old "*.asc" export that was unusable. I can see this by looking at the size of the exported file and also by doing: $ gpg --list-packets secret-key.asc which gives: # off=0 ctb=9d tag=7 hlen=3 plen=966 :secret sub key packet: version 4, algo 1, created 1482831890, expires 0 pkey[0]: [2048 bits] pkey[1]: [17 bits] iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: F1ECE95FFB36A782 protect count: 851968 (154) protect IV: f1 59 85 06 71 0a 90 df 65 88 e9 c7 a7 2f 9a 61 skey[2]: [v4 protected] keyid: 9305D7AA9D2311A4 # off=969 ctb=89 tag=2 hlen=3 plen=287 :signature packet: algo 1, keyid 16F92AB569F91A22 version 4, created 1482831890, md5len 0, sigclass 0x18 digest algo 8, begin of digest 90 08 hashed subpkt 2 len 4 (sig created 2016-12-27) hashed subpkt 27 len 1 (key flags: 0C) subpkt 16 len 8 (issuer key ID 16F92AB569F91A22) data: [2046 bits] The command used to build this export was the following (executed with the -vv option to get all the info): $ gpg2 -vv -ao secret-key.asc --export-secret-keys gpg: writing to 'secret-key.asc' gpg: key 69F91A22: asking agent for the secret parts gpg: key 69F91A22: error receiving key from agent: End of file - skipped gpg: key 69F91A22/9D2311A4: asking agent for the secret parts It asks twice for the passphrase during this process and then produces this "truncated" file. Any ideas? Thanks, -Guy On Tue, Dec 27, 2016 at 11:29 AM, Damien Goutte-Gattat < dgouttegattat at incenp.org> wrote: > On 12/27/2016 11:16 AM, MFPA wrote: > >> The --export-secret-subkeys command will do what it says on the tin. >> > > That option would still generate a secret key packet for the primary key, > it's just that this packet would not actually contain any key material. > > Here, what has been generated is a file containing only a secret subkey > packet (and the associated binding signature). That's not the result of > using --export-secret-subkeys. > > > _______________________________________________ > 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 dgouttegattat at incenp.org Sat Dec 31 20:22:43 2016 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sat, 31 Dec 2016 20:22:43 +0100 Subject: Unable to import Private Key In-Reply-To: References: <1407633450.20161227101625@riseup.net> <0d574fac-8c03-ba25-a166-ccc6a47d96a4@incenp.org> Message-ID: <9cd463b3-73cb-aa34-b7e4-4a2e20c943db@incenp.org> On 12/31/2016 11:22 AM, Guy Wyers wrote: > The command used to build this export was the following (executed with the > -vv option to get all the info): > > $ gpg2 -vv -ao secret-key.asc --export-secret-keys > > gpg: writing to 'secret-key.asc' > gpg: key 69F91A22: asking agent for the secret parts > gpg: key 69F91A22: error receiving key from agent: End of file - skipped > gpg: key 69F91A22/9D2311A4: asking agent for the secret parts So gpg asks the agent for your secret primary key (69F91A22) but the agent cannot provide it. Then it asks for the secret subkey and gets it. Next questions: * What exact version of GnuPG are you using? It looks like you are using a version from the 2.1 branch, not 2.0. Please give the output of `gpg2 --version`. * Can you *use* your secret primary key? Try performing any action requiring the secret primary key (such as signing a message, assuming you do not have a signing subkey). * If you can reproduce the issue at will, can you try exporting the private keys again, but with logging of debug informations? Add the following lines to your ~/.gnupg/gpg-agent.conf file (create that file if it does not already exist): log-file /wherever/you/want.log debug 1024 Reload the agent (gpgconf --reload gpg-agent) and try exporting again. > Any ideas? It's starting to look like a communication problem between gpg and the agent. What problem exactly, I have no clue. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Sat Dec 31 20:59:48 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 31 Dec 2016 14:59:48 -0500 Subject: File perms for conf files In-Reply-To: References: Message-ID: <54b19661-566a-868b-4b71-e366674e03d2@sixdemonbag.org> The last time I asked this I received no response, so I've been moving forward a bit in the dark here -- > So, as some of you may remember, I've been working on something to help > users back up their user directories and migrate them to new machines. > We really have no good tools at present to do this, so I'm putting > together a small Qt application to make this easier. > > https://github.com/rjhansen/sherpa Yep, still underway. > I'm now at the point where I need to restore files > from a zip archive, and part of that means ensuring I have the correct > POSIX permissions on each file. I'm going with 0x0644 (-rw-r--r--) on the .conf files, 0x0755 (-rwxr-xr-x) on the directories, and 0x0600 (-rw-------) on all files other than .confs. > So, two questions: > > (a) Is this list missing anything important? > (b) What's the official, GnuPG-approved permission for each? I need to add a (c): (c) What should the perms be on Windows? Right now I'm just uncompressing files directly into the GnuPG data directory on Win32. For all I know that's sufficient; for all I know it's wrong.