From cai.0407 at gmail.com Tue Aug 1 06:36:25 2017 From: cai.0407 at gmail.com (Kosuke Kaizuka) Date: Tue, 1 Aug 2017 13:36:25 +0900 Subject: Dirmngr fails to communicate with keyservers (W32 binaries for GnuPG 2.1.22) In-Reply-To: <1989502.Z2ZSEliuAJ@esus> References: <1783960517.20170729145809@riseup.net> <1989502.Z2ZSEliuAJ@esus> Message-ID: On Mon, 31 Jul 2017 10:35:24 +0200, Andre Heinecke wrote: > Hi, > > On Sunday, July 30, 2017 11:41:01 AM CEST Kosuke Kaizuka wrote: >> On Sat, 29 Jul 2017 14:58:09 +0100, MFPA wrote:> >>> I have installed the W32 package for GnuPG 2.1.22 and I find keys >>> cannot be sent to keyservers, or fetched/refreshed. The operation >>> fails with the message "keyserver send failed: Resource temporarily >>> unavailable". >>> >>> In the event the dirmngr from 2.1.21 is already running, the operation >>> succeeds. > > Yes, slipped our testing. We are working on it: > > https://dev.gnupg.org/T3318 The problem seems to have been fixed in gnupg-w32-2.1.22_20170731. -- Kosuke Kaizuka -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 898 bytes Desc: OpenPGP digital signature URL: From 2014-667rhzu3dc-lists-groups at riseup.net Tue Aug 1 13:45:59 2017 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Tue, 1 Aug 2017 12:45:59 +0100 Subject: 'sign (and cert)' or just 'cert' on a master key with subkeus In-Reply-To: References: <52DC46AB-5B35-44FC-A818-159BBFB513BB@webweaving.org> <20170731154452.37ce66c2@Archbox> Message-ID: <894342512.20170801124559@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Monday 31 July 2017 at 10:11:16 PM, in , Gabriel Philippe wrote:- > A good practice is to define close expiration dates > for keys and > subkeys, and regularly postpone them (or renew > subkeys), which is only > possible with the "master" offline key and not with > the possibly > compromised subkeys. This forces those people who > never refresh keys > to do it, or complain, or for most of them abandon > PGP because they > get painful warnings and this stupid thing does not > work. Shouldn't "auto-key-locate" in their gpg.conf take care of this? > Furthermore, if you start sending messages signed > with a new subkey, > people who have not refreshed your key will get error > messages, > hopefully refresh the key (or complain or abandon > PGP), and get both > the revocation certificates and the new subkeys. > Without even having > to understand what happens. Doesn't "auto-key-retrieve" in their gpg.conf take care of this? - -- Best regards MFPA COMMITTEE: A body that keeps minutes and wastes hours. -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQQzrO1O6RNO695qhQYXErxGGvd45AUCWYBp+V8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNB Q0VENEVFOTEzNEVFQkRFNkE4NTA2MTcxMkJDNDYxQUY3NzhFNAAKCRAXErxGGvd4 5FEIAQDvA6JSDkleHhXh9GlhvFrjXA2L87L/PioEPaQULJ3IaAD9FNehHS/P81Wm 4+Cmo/2cBDXJuGCI2LLYgWoX7DoINAGJAZMEAQEKAH0WIQSzrn7KmoyLMCaloPVr fHTOsx8l8AUCWYBp+V8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0QjNBRTdFQ0E5QThDOEIzMDI2QTVBMEY1NkI3 Qzc0Q0VCMzFGMjVGMAAKCRBrfHTOsx8l8CjvCACqKuwJx4kkMUmTZi53BRiw/DRU Cvo8jMR412LTBATmjfbvHanv60+k+Xr/s6suzZuHDdGzePBED+Dm6Vcka6EfPAF8 DCmEBMJ4g+kduy3AyoHuuRS97h17KTfCsqeyfiKQ2gKBh1xNkW83NOj8gJxJu/PO fbKuEcPWxIUVtU7UDIAQH5YtqKn56X/qAJg0jpKX6+BG4+0Bp+UCpiDxwL2VlVdI OQeC6TZw2aAGKN5eIDtOcJjj2Td2BazHyiNGbYCkjKcZUT2DBuYXl+ZTxPr6jAKd q/qa5k0hL+mZJlBj+jR4SbpvoL1XFDWtNWBgyUjE/1W1jhROdBZW7V7CLRLR =OdAB -----END PGP SIGNATURE----- From gabri.philippe at gmail.com Tue Aug 1 16:03:25 2017 From: gabri.philippe at gmail.com (Gabriel Philippe) Date: Tue, 1 Aug 2017 16:03:25 +0200 Subject: 'sign (and cert)' or just 'cert' on a master key with subkeus In-Reply-To: <894342512.20170801124559@riseup.net> References: <52DC46AB-5B35-44FC-A818-159BBFB513BB@webweaving.org> <20170731154452.37ce66c2@Archbox> <894342512.20170801124559@riseup.net> Message-ID: On Tue, Aug 1, 2017 at 1:45 PM, MFPA <2014-667rhzu3dc-lists-groups at riseup.net> wrote: >>(...) > Shouldn't "auto-key-locate" in their gpg.conf take care of this? >> (...) > Doesn't "auto-key-retrieve" in their gpg.conf take care of this? Well, these are not defaults, hence unlikely to be defined by people who never refresh their keys. And the second looks dangerous to me with the growing use of TOFU. -- Gabriel From david at gbenet.com Tue Aug 1 19:30:05 2017 From: david at gbenet.com (david at gbenet.com) Date: Tue, 1 Aug 2017 18:30:05 +0100 Subject: Your Thoughts Message-ID: <1d1134a1-f35a-1445-51d9-ef67f850d851@gbenet.com> Hi All, I was sharing thoughts on AI in Linux facebook and Sean Rickerd shared this link https://arstechnica.com/information-technology/2016/10/google-ai-neural-network-cryptography/ David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Tue Aug 1 20:17:37 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 1 Aug 2017 14:17:37 -0400 Subject: GnuPG and standard output Message-ID: <642e1652-dede-5b93-eeeb-23f707bed9e7@sixdemonbag.org> GnuPG seems to insist on writing to a console, even where it's unnecessary and counterproductive. Consider the following Python code: ===== #!/usr/bin/env python3 args = ["/usr/local/bin/gpg", "--edit-key", "0xb44427c7", "showpref", "quit"] result = subprocess.run(args, stdout=subprocess.PIPE) print("Got {} bytes output".format(len(result.stdout))) ===== (If you're wondering why I'd do this, GPGME does not yet have a way to query key prefs, and I need them for a project.) There's no security reason to dump this to the console. It's just publicly-available information about the certificate. And yet, it consistently puts zero bytes in result.stdout, while displaying data to the console. What's the best way to get past this behavior? From dkg at fifthhorseman.net Tue Aug 1 20:35:59 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 01 Aug 2017 14:35:59 -0400 Subject: GnuPG and standard output In-Reply-To: <642e1652-dede-5b93-eeeb-23f707bed9e7@sixdemonbag.org> References: <642e1652-dede-5b93-eeeb-23f707bed9e7@sixdemonbag.org> Message-ID: <87h8xrdtkg.fsf@fifthhorseman.net> On Tue 2017-08-01 14:17:37 -0400, Robert J. Hansen wrote: > (If you're wondering why I'd do this, GPGME does not yet have a way to > query key prefs, and I need them for a project.) Thanks for the suggestion, i've recorded it here: https://dev.gnupg.org/T3323 > There's no security reason to dump this to the console. It's just > publicly-available information about the certificate. And yet, it > consistently puts zero bytes in result.stdout, while displaying data to > the console. I agree this seems like a non-useful behavior, but if you're planning on using gpg in an automated way and you want machine-parseable output, i recommend including at least the following arguments in addition to whatever else you want gpg to do: --no-tty --batch --quiet --with-colons --fixed-list-mode hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From marfig at gmx.com Tue Aug 1 21:55:28 2017 From: marfig at gmx.com (Mario Figueiredo) Date: Tue, 1 Aug 2017 20:55:28 +0100 Subject: Your Thoughts In-Reply-To: <1d1134a1-f35a-1445-51d9-ef67f850d851@gbenet.com> References: <1d1134a1-f35a-1445-51d9-ef67f850d851@gbenet.com> Message-ID: <20170801205528.55e0bd0a@Archbox> "The researchers didn't perform an exhaustive analysis of the encryption methods devised by Alice and Bob" So there isn't much that can be said. The experiment was pretty much a game of life between the couple and Eve, with the more than predictable outcome that Eve shows signs of gaining ground right until a new cypher is devised. We have that already in the real world. There's nothing here to either support or disproof Neural Networks abilities in the field of cryptology and it is not clear at all what the objective of this experiment was or what was expected to be gained from it. Except maybe an headline on Ars Technica. Known for, among other things, to also make headlines of Elon Musk verbal diarrhea. MF On Tue, 1 Aug 2017 18:30:05 +0100 "david at gbenet.com" wrote: > Hi All, > > I was sharing thoughts on AI in Linux facebook and Sean Rickerd > shared this link > > https://arstechnica.com/information-technology/2016/10/google-ai-neural-network-cryptography/ > > David -- Sinceramente / Best regards, M?rio J.G.P. Figueiredo Luanda, Angola (email) marfig at gmx.com (alt) krugar at openmailbox.org (phone) +244 934 535 121 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From gnupg.20.miller_2555 at spamgourmet.com Wed Aug 2 02:42:41 2017 From: gnupg.20.miller_2555 at spamgourmet.com (gnupg.20.miller_2555 at spamgourmet.com) Date: Tue, 1 Aug 2017 20:42:41 -0400 Subject: GPGme operations with subkeys Message-ID: <11258A6F-4500-4476-B879-D7308B8FE862@gmail.com> I have a couple encryption subkeys under my primary key. Each key is used for different applications (while I generally just use one subkey, the other is used when a specific application does not permit the use of that subkey). I would like to select specific subkeys (gpgme_subkey_t) in GPGme to perform operations (eg. gpgme_op_encrypt(...), gpgpme_op_encrypt_sign(...), etc.), but only see a way to pass entire keys (gpgme_key_t) to those functions and rely on gpg to select the key (which does not always select the correct subkey). I've been through the reference manual (edition 1.9.0, last updated Nov. 2016) and searched around a bit, including the mail list archives, but am I just missing a way to do this or does the functionality not yet exist? Appreciate the time. From rjh at sixdemonbag.org Wed Aug 2 03:05:04 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 1 Aug 2017 21:05:04 -0400 Subject: GPGme operations with subkeys In-Reply-To: <11258A6F-4500-4476-B879-D7308B8FE862@gmail.com> References: <11258A6F-4500-4476-B879-D7308B8FE862@gmail.com> Message-ID: <9bd83dc9-9988-6678-cf1a-f703fcacb590@sixdemonbag.org> > I would like to select specific subkeys (gpgme_subkey_t) in GPGme to > perform operations (eg. gpgme_op_encrypt(...) This isn't really well-supported, and for good reason: which subkey to choose is normally viewed as a decision of the OpenPGP engine, not so much of the user. If you have a set of keys, all of which provide the correct capability, GnuPG will use the most recent one under the logic that the most recently added subkey is the one the user prefers. At the command line a subkey can be specifically selected by appending an exclamation mark to the *subkey* key ID, but I don't believe GPGME supports this behavior. From wk at gnupg.org Wed Aug 2 11:40:14 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 02 Aug 2017 11:40:14 +0200 Subject: GPGme operations with subkeys In-Reply-To: <9bd83dc9-9988-6678-cf1a-f703fcacb590@sixdemonbag.org> (Robert J. Hansen's message of "Tue, 1 Aug 2017 21:05:04 -0400") References: <11258A6F-4500-4476-B879-D7308B8FE862@gmail.com> <9bd83dc9-9988-6678-cf1a-f703fcacb590@sixdemonbag.org> Message-ID: <87wp6mz4sh.fsf@wheatstone.g10code.de> On Wed, 2 Aug 2017 03:05, rjh at sixdemonbag.org said: > At the command line a subkey can be specifically selected by appending > an exclamation mark to the *subkey* key ID, but I don't believe GPGME > supports this behavior. That's right. I opened a wishlist item as https://dev.gnupg.org/T3325 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: 227 bytes Desc: not available URL: From gnupg.20.miller_2555 at spamgourmet.com Wed Aug 2 02:32:41 2017 From: gnupg.20.miller_2555 at spamgourmet.com (gnupg.20.miller_2555 at spamgourmet.com) Date: Tue, 1 Aug 2017 20:32:41 -0400 Subject: GPGme operations with subkeys Message-ID: I have a couple encryption subkeys under my primary key. Each key is used for different applications (while I generally just use one subkey, the other is used when a specific application does not permit the use of that subkey). I would like to select specific subkeys (gpgme_subkey_t) in GPGme to perform operations (eg. gpgme_op_encrypt(...), gpgpme_op_encrypt_sign(...), etc.), but only see a way to pass entire keys (gpgme_key_t) to those functions and rely on gpg to select the key (which does not always select the correct subkey). I've been through the reference manual (edition 1.9.0, last updated Nov. 2016) and searched around a bit, including the mail list archives, but am I just missing a way to do this or does the functionality not yet exist? Appreciate the time. From gnupg.20.miller_2555 at spamgourmet.com Wed Aug 2 02:35:56 2017 From: gnupg.20.miller_2555 at spamgourmet.com (gnupg.20.miller_2555 at spamgourmet.com) Date: Tue, 1 Aug 2017 20:35:56 -0400 Subject: confirm 7dc28b2cdcd51f4b7e2110b65dce16d7eb589942 In-Reply-To: References: Message-ID: <5AFFBD7A-8B8B-4997-8111-0313726981EB@gmail.com> > On Aug 1, 2017, at 20:07, gnupg-users-request at gnupg.org wrote: > > confirm 7dc28b2cdcd51f4b7e2110b65dce16d7eb589942 From stefan.claas at posteo.de Wed Aug 2 16:06:13 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Wed, 2 Aug 2017 16:06:13 +0200 Subject: Bitcoin private key from GnuPG secp256k1 secret key? Message-ID: <3xMw342rkHz10Hj@submission01.posteo.de> Hi all, just wondering if there is an easy way to generate a Bitcoin secret key from a GnuPG secp256k1 secret key. If so, how would you do that? Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 506 bytes Desc: Digitale Signatur von OpenPGP URL: From Roman.Fiedler at ait.ac.at Wed Aug 2 15:52:13 2017 From: Roman.Fiedler at ait.ac.at (Fiedler Roman) Date: Wed, 2 Aug 2017 13:52:13 +0000 Subject: Extraction of decryption session key without copying complete encrypted file Message-ID: <2ECE9D9EEF1F524185270138AE23265955AD30F7@S0MSMAIL112.arc.local> Hello list, How to decrypt large files, e.g. gpg-encrypted backups, without copying them to the machine with the GPG private key? I tried to split off the first gpg package from the encrypted file and extract the session key from that, but that did not work: * Remote: dd if=test.gpg bs=16k count=1 | gpgsplit * Local GPG machine: gpg --homedir x --show-session-key < 000001-001.pk_enc The later command does not fail but it does not print out the session key either. * Local machine workaround: By appending an unrelated zero-data length encrypted "mdc" block, the session key extraction works, but that seems to be a dirty workaround: (cat 000001-001.pk_enc; echo "0gsBAAAAAAAAAAAAAA==" | base64 -d) > test.gpg gpg --homedir x --show-session-key < test.gpg What would be a clean way to do that? Best regards, Roman ROMAN FIEDLER Scientist Information Management Center for Digital Safety & Security AIT Austrian Institute of Technology GmbH Reininghausstra?e 13/1 | 8020 Graz | Austria T +43 50550-2957 | M +43 664 8561599 | F +43 50550-2950 roman.fiedler at ait.ac.at | https://www.ait.ac.at View my researcher profile: https://www.ait.ac.at/profile/detail/Fiedler-Roman/ FN: 115980 i HG Wien | UID: ATU14703506 www.ait.ac.at/Email-Disclaimer -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4814 bytes Desc: not available URL: From stefan.claas at posteo.de Wed Aug 2 17:25:26 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Wed, 2 Aug 2017 17:25:26 +0200 Subject: Bitcoin private key from GnuPG secp256k1 secret key? In-Reply-To: <3xMw342rkHz10Hj@submission01.posteo.de> References: <3xMw342rkHz10Hj@submission01.posteo.de> Message-ID: <3xMxpS2CKYz1090@submission01.posteo.de> On Wed, 2 Aug 2017 16:06:13 +0200, Stefan Claas wrote: > Hi all, > > just wondering if there is an easy way to generate a Bitcoin secret > key from a GnuPG secp256k1 secret key. If so, how would you do that? To be more precise, i would like to see the secret Bitcoin key in WIF or WIFC format, if possible. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 506 bytes Desc: Digitale Signatur von OpenPGP URL: From gniibe at fsij.org Thu Aug 3 00:00:04 2017 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 03 Aug 2017 07:00:04 +0900 Subject: Bitcoin private key from GnuPG secp256k1 secret key? In-Reply-To: <3xMw342rkHz10Hj@submission01.posteo.de> References: <3xMw342rkHz10Hj@submission01.posteo.de> Message-ID: <87tw1pd40r.fsf@fsij.org> Stefan Claas wrote: > just wondering if there is an easy way to generate a Bitcoin secret key > from a GnuPG secp256k1 secret key. If so, how would you do that? I don't know about secret key conversion. In the past, I did something for public key: https://lists.gnupg.org/pipermail/gnupg-devel/2014-January/028147.html However, soon after this scripting, it occurred the Mt. Gox incident in Japan. And I learned that most "users" don't control their private key for Bitcoin at all, just like general citizen don't control printing of paper money. So, no further development for my side. It was not committed to GnuPG repo. (I only have a transaction with the address.) If someone will make transaction to that address for some amount, I would resume the development again. :-) -- From gnupg.20.miller_2555 at spamgourmet.com Thu Aug 3 05:05:33 2017 From: gnupg.20.miller_2555 at spamgourmet.com (gnupg.20.miller_2555 at spamgourmet.com) Date: Wed, 2 Aug 2017 23:05:33 -0400 Subject: GPGme operations with subkeys In-Reply-To: <87wp6mz4sh.fsf@wheatstone.g10code.de> References: <11258A6F-4500-4476-B879-D7308B8FE862@gmail.com> <9bd83dc9-9988-6678-cf1a-f703fcacb590@sixdemonbag.org> <87wp6mz4sh.fsf@wheatstone.g10code.de> Message-ID: <0960C336-C96C-49AA-80F6-A9D3F31A95FE@gmail.com> > On Aug 2, 2017, at 05:40, Werner Koch - wk at gnupg.org wrote: > > On Wed, 2 Aug 2017 03:05, rjh at sixdemonbag.org said: > >> At the command line a subkey can be specifically selected by appending >> an exclamation mark to the *subkey* key ID, but I don't believe GPGME >> supports this behavior. > > That's right. I opened a wishlist item as > > https://dev.gnupg.org/T3325 > > > Salam-Shalom, > > Werner Thank you both very much, and I sincerely appreciate the thoughtful comments. Truly an example of the strength of the open source community. I look forward to the ongoing effort to expand functionality. Meanwhile, I'll maintain separate keyrings as a workaround (fortunately, trust relationships have already been built by the more commonly used subkey). W From stefan.claas at posteo.de Thu Aug 3 09:04:10 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Thu, 3 Aug 2017 09:04:10 +0200 Subject: Bitcoin private key from GnuPG secp256k1 secret key? In-Reply-To: <87tw1pd40r.fsf@fsij.org> References: <3xMw342rkHz10Hj@submission01.posteo.de> <87tw1pd40r.fsf@fsij.org> Message-ID: <3xNLdd5TSVz10Hj@submission01.posteo.de> On Thu, 03 Aug 2017 07:00:04 +0900, NIIBE Yutaka wrote: > Stefan Claas wrote: > > just wondering if there is an easy way to generate a Bitcoin secret > > key from a GnuPG secp256k1 secret key. If so, how would you do > > that? > > I don't know about secret key conversion. > > In the past, I did something for public key: > > https://lists.gnupg.org/pipermail/gnupg-devel/2014-January/028147.html > > However, soon after this scripting, it occurred the Mt. Gox incident > in Japan. And I learned that most "users" don't control their > private key for Bitcoin at all, just like general citizen don't > control printing of paper money. So, no further development for my > side. It was not committed to GnuPG repo. (I only have a > transaction with the address.) Thanks for your reply! > If someone will make transaction to that address for some amount, I > would resume the development again. :-) I could imagine that no one will do this, because if you have no private key for "your" public address (according to your reply), you have no control of that address, like spending/ sending BTC from this address. Best regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 506 bytes Desc: Digitale Signatur von OpenPGP URL: From gniibe at fsij.org Thu Aug 3 09:24:05 2017 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 03 Aug 2017 16:24:05 +0900 Subject: Bitcoin private key from GnuPG secp256k1 secret key? In-Reply-To: <3xNLdd5T9dz10HZ@submission01.posteo.de> References: <3xMw342rkHz10Hj@submission01.posteo.de> <87tw1pd40r.fsf@fsij.org> <3xNLdd5T9dz10HZ@submission01.posteo.de> Message-ID: <87tw1pxgfe.fsf@fsij.org> Stefan Claas wrote: > I could imagine that no one will do this, because if you have no > private key for "your" public address (according to your reply), > you have no control of that address, like spending/ sending > BTC from this address. Sorry about my vague description. As a subkey of 0x00B45EBD4CA7BABE, I have a key of secp256k1. And the private key is controlled by me, on a Gnuk Token. But I have no "wallet", yet. This is the situation. My idea was that we can use WoT of OpenPGP to check Bitcoin address. It seems that people don't buy this idea. -- From stefan.claas at posteo.de Thu Aug 3 10:01:10 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Thu, 3 Aug 2017 10:01:10 +0200 Subject: Fw: Bitcoin private key from GnuPG secp256k1 secret key? Message-ID: <3xNMvC2xCsz108v@submission01.posteo.de> Beginn der weitergeleiteten Nachricht: Datum: Thu, 3 Aug 2017 09:57:47 +0200 Von: Stefan Claas An: NIIBE Yutaka Betreff: Re: Bitcoin private key from GnuPG secp256k1 secret key? On Thu, 03 Aug 2017 16:24:05 +0900, NIIBE Yutaka wrote: > Stefan Claas wrote: > > I could imagine that no one will do this, because if you have no > > private key for "your" public address (according to your reply), > > you have no control of that address, like spending/ sending > > BTC from this address. > > Sorry about my vague description. > > As a subkey of 0x00B45EBD4CA7BABE, I have a key of secp256k1. And the > private key is controlled by me, on a Gnuk Token. But I have no > "wallet", yet. This is the situation. Ah, o.k., i appologize. > My idea was that we can use WoT of OpenPGP to check Bitcoin address. > It seems that people don't buy this idea. I think this is a good idea, for people who have publicity posted their Bitcoin address on their web page or for example on keybase etc. Best regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 506 bytes Desc: Digitale Signatur von OpenPGP URL: From kgallagher at cloudflare.com Thu Aug 3 02:35:26 2017 From: kgallagher at cloudflare.com (Kevin Gallagher) Date: Wed, 2 Aug 2017 17:35:26 -0700 Subject: gnupg or gpg-agent options for parallelism and memory usage Message-ID: <699d3221-ba52-2923-7f39-1cfa3e8ca029@gmail.com> Hi, This is a simple question really. I've been working on some automation in which many GPG secrets are decrypted in parallel and rendered in templates. Routinely, when our system attempts to decrypt hundreds of secrets at once, GPG with gpg-agent crashes our containers and the parent process(es) by running out of memory. Is anyone aware of any options or configurations which can increase the efficiency of memory resource usage, allowing us to quickly decrypt more things at once? Kevin From gongalreddy.sirish at yahoo.com Thu Aug 3 19:24:39 2017 From: gongalreddy.sirish at yahoo.com (sirishreddyg) Date: Thu, 3 Aug 2017 10:24:39 -0700 (MST) Subject: GPG Decryption Issue Message-ID: <1501781079403-52939.post@n7.nabble.com> I am trying to decrypt the file using gpg and I am getting the following exception, Exception stderr=gpg: protection algorithm 3 is not supported gpg: encrypted with 2048-bit RSA key, ID 00754B14, created 2012-09-27 "Key Name (4508073) " gpg: public key decryption failed: Invalid cipher algorithm gpg: decryption failed: No secret key GPG Version gpg (GnuPG) 2.0.14 libgcrypt 1.4.5 Home: ~/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA Cipher: 3DES, AES, AES192, AES256 Hash: MD5, SHA1, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 What is algorithm 3? How can I enable support for algorithm 3? Thanks in advance! -- View this message in context: http://gnupg.10057.n7.nabble.com/GPG-Decryption-Issue-tp52939.html Sent from the GnuPG - User mailing list archive at Nabble.com. From Roman.Fiedler at ait.ac.at Fri Aug 4 11:56:09 2017 From: Roman.Fiedler at ait.ac.at (Fiedler Roman) Date: Fri, 4 Aug 2017 09:56:09 +0000 Subject: AW: gnupg or gpg-agent options for parallelism and memory usage In-Reply-To: <699d3221-ba52-2923-7f39-1cfa3e8ca029@gmail.com> References: <699d3221-ba52-2923-7f39-1cfa3e8ca029@gmail.com> Message-ID: <2ECE9D9EEF1F524185270138AE23265955AD42FB@S0MSMAIL112.arc.local> > Von: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] Im Auftrag von > > Hi, > > This is a simple question really. I've been working on some automation > in which many GPG secrets are decrypted in parallel and rendered in > templates. Routinely, when our system attempts to decrypt hundreds of > secrets at once, GPG with gpg-agent crashes our containers and the > parent process(es) by running out of memory. > > Is anyone aware of any options or configurations which can increase the > efficiency of memory resource usage, allowing us to quickly decrypt more > things at once? Would somethinng similar to [1] help you? Due to resource limitations and security considerations (never copy private keys), I try to separate session key extraction and decryption. LG R [1] https://lists.gnupg.org/pipermail/gnupg-users/2017-August/058821.html PS: CAVEAT, gnupg-users list seems to be configured in strange way: "reply to all" does not reply to the list, so please add address manually. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4814 bytes Desc: not available URL: From wk at gnupg.org Fri Aug 4 13:36:52 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 04 Aug 2017 13:36:52 +0200 Subject: gnupg or gpg-agent options for parallelism and memory usage In-Reply-To: <699d3221-ba52-2923-7f39-1cfa3e8ca029@gmail.com> (Kevin Gallagher's message of "Wed, 2 Aug 2017 17:35:26 -0700") References: <699d3221-ba52-2923-7f39-1cfa3e8ca029@gmail.com> Message-ID: <87lgmztvhn.fsf@wheatstone.g10code.de> On Thu, 3 Aug 2017 02:35, kgallagher at cloudflare.com said: > Is anyone aware of any options or configurations which can increase the > efficiency of memory resource usage, allowing us to quickly decrypt more > things at once? Don't use too many parallel sessions. gpg's --multifile option may help you to serialize things but that require synchronization on your site. I can imagine to implement a limit on parallel connections to gpg-agent and then either return an error code (so that gpg can retry after some time) or queue the requests up in gpg-agent. We can't do that for 2.2 anymore, though. 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: 227 bytes Desc: not available URL: From wk at gnupg.org Fri Aug 4 13:48:21 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 04 Aug 2017 13:48:21 +0200 Subject: GPG Decryption Issue In-Reply-To: <1501781079403-52939.post@n7.nabble.com> (sirishreddyg via Gnupg-users's message of "Thu, 3 Aug 2017 10:24:39 -0700 (MST)") References: <1501781079403-52939.post@n7.nabble.com> Message-ID: <87h8xntuyi.fsf@wheatstone.g10code.de> On Thu, 3 Aug 2017 19:24, gnupg-users at gnupg.org said: > stderr=gpg: protection algorithm 3 is not supported gpg: encrypted with Your private key is encrypted with CAST5 but you have disabled support for CAST5 in gpg or you disabled CAST5 when you built libgcrypt. > gpg (GnuPG) 2.0.14 > libgcrypt 1.4.5 [These are 8 year old versions. You should not use such old versions.] > Pubkey: RSA, ELG, DSA Cipher: 3DES, AES, AES192, AES256 Pubkey: RSA, ELG, DSA Cipher: 3DES, AES, AES192, AES256 Yep: No support for CAST5 - this is not the default. Rebuild Libgcrypt w/o disabling algos and while you do that you should move to a supported versions, best 1.8.0. 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: 227 bytes Desc: not available URL: From wk at gnupg.org Fri Aug 4 13:59:57 2017 From: wk at gnupg.org (Werner Koch) Date: Fri, 04 Aug 2017 13:59:57 +0200 Subject: Extraction of decryption session key without copying complete encrypted file In-Reply-To: <2ECE9D9EEF1F524185270138AE23265955AD30F7@S0MSMAIL112.arc.local> (Fiedler Roman's message of "Wed, 2 Aug 2017 13:52:13 +0000") References: <2ECE9D9EEF1F524185270138AE23265955AD30F7@S0MSMAIL112.arc.local> Message-ID: <87bmnvtuf6.fsf@wheatstone.g10code.de> On Wed, 2 Aug 2017 15:52, Roman.Fiedler at ait.ac.at said: > How to decrypt large files, e.g. gpg-encrypted backups, without copying them to the machine with the GPG private key? With GnuPG 2.1 this is easy: You use ssh's socket forwarding feature to forward gpg-agent's restricted remote socket, for example /run/user/1000/gnupg/S.gpg-agent.extra to the host and there you run gpg which will then connect back to the agent on your desktop. For details see https://wiki.gnupg.org/AgentForwarding 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: 227 bytes Desc: not available URL: From Roman.Fiedler at ait.ac.at Fri Aug 4 14:36:12 2017 From: Roman.Fiedler at ait.ac.at (Fiedler Roman) Date: Fri, 4 Aug 2017 12:36:12 +0000 Subject: AW: Extraction of decryption session key without copying complete encrypted file In-Reply-To: <87bmnvtuf6.fsf@wheatstone.g10code.de> References: <2ECE9D9EEF1F524185270138AE23265955AD30F7@S0MSMAIL112.arc.local> <87bmnvtuf6.fsf@wheatstone.g10code.de> Message-ID: <2ECE9D9EEF1F524185270138AE23265955AD444D@S0MSMAIL112.arc.local> > Von: Werner Koch [mailto:wk at gnupg.org] > > On Wed, 2 Aug 2017 15:52, Roman.Fiedler at ait.ac.at said: > > > How to decrypt large files, e.g. gpg-encrypted backups, without > copying them to the machine with the GPG private key? > > With GnuPG 2.1 this is easy: You use ssh's socket forwarding feature to > forward gpg-agent's restricted remote socket, for example > > /run/user/1000/gnupg/S.gpg-agent.extra > > to the host and there you run gpg which will then connect back to the > agent on your desktop. For details see > > https://wiki.gnupg.org/AgentForwarding Ah, that's great - and actually the first nice gpg-agent feature apart from gpg-agent being little annoying when running it on RAM-disks in early boot. The agent forwarding guide from above is fine, should be easy to implement. Just one more question: how do I restrict the private key lifetime within the agent or the number of agent requests before password repeat is needed? Best would be 0 seconds (agent should ask for passphrase every time a key is requested), but I could also live with something below 60sec. What's the best way to implement that? I did not find a gpg option by myself. If none available, I guess it might be possible to find some value for RLIMIT_CPU, that would kill the agent process when attempting to do another sign/decrypt operation? LG R -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4814 bytes Desc: not available URL: From marfig at gmx.com Fri Aug 4 14:42:54 2017 From: marfig at gmx.com (Mario Figueiredo) Date: Fri, 4 Aug 2017 13:42:54 +0100 Subject: gnupg or gpg-agent options for parallelism and memory usage In-Reply-To: <2ECE9D9EEF1F524185270138AE23265955AD42FB@S0MSMAIL112.arc.local> References: <699d3221-ba52-2923-7f39-1cfa3e8ca029@gmail.com> <2ECE9D9EEF1F524185270138AE23265955AD42FB@S0MSMAIL112.arc.local> Message-ID: <20170804134254.4651557d@Archbox> On Fri, 4 Aug 2017 09:56:09 +0000 Fiedler Roman wrote: > PS: CAVEAT, gnupg-users list seems to be configured in strange way: > "reply to all" does not reply to the list, so please add address > manually. OT sidenote: Took me a while to realize this, and I must have annoyed a few people on my early replies. All fixed now. And my apologies. MF -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From stefan.claas at posteo.de Fri Aug 4 14:46:19 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Fri, 4 Aug 2017 14:46:19 +0200 Subject: Posting short GnuPG clear signed messages on social media sites Message-ID: <3xP6B06vTgz10Hh@submission01.posteo.de> Hi all, i don't know how many of you folks use social media sites like Twitter and Facebook etc. and wondered what's a way to post a GnuPG clear signed message on those sites, due to line width limits or characters per message limits. Well, i thought about that to and i like to share an idea with you. I found out that with short GnuPG clear signed messages a good way to do that is to encode the message in the popular QR-Code format. For this task i used the package "qrencode" which is available as Linux package and can also be compiled under OS X, for example. https://fukuchi.org/works/qrencode/ So, simply prepare your short GnuPG message and then do a: $ qrencode -o message.png < message.txt.asc, to obtain a .png image, ready to be posted on social media sites. To decode such an image in Terminal simply do a: (please note: the images when downloaded are then in .jpeg format) http://zbar.sourceforge.net/download.html $ zbarimg image.jpg > output.txt && sed "s/QR-Code:-/-/g" output.txt | gpg --verify If you know a better and shorter way to decode, please let me/us know. Hope you find this little tip useful and i hope it may spread the usage of GnuPG! :-) Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 506 bytes Desc: Digitale Signatur von OpenPGP URL: From guru at unixarea.de Fri Aug 4 15:39:18 2017 From: guru at unixarea.de (Matthias Apitz) Date: Fri, 4 Aug 2017 15:39:18 +0200 Subject: Extraction of decryption session key without copying complete encrypted file In-Reply-To: <87bmnvtuf6.fsf@wheatstone.g10code.de> References: <2ECE9D9EEF1F524185270138AE23265955AD30F7@S0MSMAIL112.arc.local> <87bmnvtuf6.fsf@wheatstone.g10code.de> Message-ID: <20170804133918.GA3450@c720-r314251> El d?a viernes, agosto 04, 2017 a las 01:59:57p. m. +0200, Werner Koch escribi?: > On Wed, 2 Aug 2017 15:52, Roman.Fiedler at ait.ac.at said: > > > How to decrypt large files, e.g. gpg-encrypted backups, without copying them to the machine with the GPG private key? > > With GnuPG 2.1 this is easy: You use ssh's socket forwarding feature to > forward gpg-agent's restricted remote socket, for example > > /run/user/1000/gnupg/S.gpg-agent.extra > > to the host and there you run gpg which will then connect back to the > agent on your desktop. For details see > > https://wiki.gnupg.org/AgentForwarding But this implies that everyone with priv access on the remote host could abuse your secret key on your localhost, especially when a GnuPG-card is used and you entered the PIN to unlock the secret key. I'm wrong? matthias -- Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/ ? +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub 8. Mai 1945: Wer nicht feiert hat den Krieg verloren. 8 de mayo de 1945: Quien no festeja perdi? la Guerra. May 8, 1945: Who does not celebrate lost the War. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From andrewg at andrewg.com Fri Aug 4 16:07:22 2017 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 4 Aug 2017 15:07:22 +0100 Subject: Extraction of decryption session key without copying complete encrypted file In-Reply-To: <20170804133918.GA3450@c720-r314251> References: <2ECE9D9EEF1F524185270138AE23265955AD30F7@S0MSMAIL112.arc.local> <87bmnvtuf6.fsf@wheatstone.g10code.de> <20170804133918.GA3450@c720-r314251> Message-ID: On 04/08/17 14:39, Matthias Apitz wrote: > But this implies that everyone with priv access on the remote host could > abuse your secret key on your localhost, especially when a GnuPG-card is > used and you entered the PIN to unlock the secret key. I'm wrong? Yes, someone with root on the remote machine can do whatever they want on that machine. The solution is not to perform *any* crypto on a machine whose admins you do not trust. There's nothing that software can do to protect you from rogue sysadmins. If you don't want the sysadmins on the remote machine to abuse your private key, then you have to download the data, perform your crypto locally and then upload the data again. Once you allow any software on the remote machine to access your local resources, the remote sysadmins can access them too. This applies to all sorts of other things BTW, such as client drives and printers shared over RDP. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 862 bytes Desc: OpenPGP digital signature URL: From Roman.Fiedler at ait.ac.at Fri Aug 4 16:10:55 2017 From: Roman.Fiedler at ait.ac.at (Fiedler Roman) Date: Fri, 4 Aug 2017 14:10:55 +0000 Subject: AW: Extraction of decryption session key without copying complete encrypted file In-Reply-To: <20170804133918.GA3450@c720-r314251> References: <2ECE9D9EEF1F524185270138AE23265955AD30F7@S0MSMAIL112.arc.local> <87bmnvtuf6.fsf@wheatstone.g10code.de> <20170804133918.GA3450@c720-r314251> Message-ID: <2ECE9D9EEF1F524185270138AE23265955AD4550@S0MSMAIL112.arc.local> > Von: Matthias Apitz [mailto:guru at unixarea.de] > > El d?a viernes, agosto 04, 2017 a las 01:59:57p. m. +0200, Werner Koch > escribi?: > > > On Wed, 2 Aug 2017 15:52, Roman.Fiedler at ait.ac.at said: > > > > > How to decrypt large files, e.g. gpg-encrypted backups, without > copying them to the machine with the GPG private key? > > > > With GnuPG 2.1 this is easy: You use ssh's socket forwarding feature > to > > forward gpg-agent's restricted remote socket, for example > > > > /run/user/1000/gnupg/S.gpg-agent.extra > > > > to the host and there you run gpg which will then connect back to the > > agent on your desktop. For details see > > > > https://wiki.gnupg.org/AgentForwarding > > But this implies that everyone with priv access on the remote host could > abuse your secret key on your localhost, especially when a GnuPG-card is > used and you entered the PIN to unlock the secret key. I'm wrong? Of course, that is why, I want to get rid of the private keys after some time, probably using measures as depicted in [1]. >From the risk analysis view: If the attacker is already on the source machines, just monitoring admin behaviour, he is likely to learn how the session key exchange procedure will work and may manipulate the procedure in such a way, that I will decrypt messages for him anyway. So that first incident cannot be mitigated in any way - the drawback of performing just any operation on an untrusted computer system. The only difference would be: a) using the agent-port might be more stealthy, especially when the agent does not display information, how many decryption request were processed. Hence [1] to perform a single decryption request at most before user interaction is needed. b) interfacing the agent port might be easier than understanding a 25 line shell script and manipulating it in such a way, that it replaces the data to be decrypted before forwarding it. After that first incident, risk of agent port is higher: with the port, attacker can continue to send more sign/decrypt requests. Without that, admin would notice, that the session key produced by the decryption procedure was not correct to decrypt the target file, thus some manipulation has occurred. If fast, he might even disconnect the VM network adapter of the affected machine before the attack could have decrypted and transferred the whole file (unless he did not transfer it beforehand and just stole the session key the moment it was provided). LG Roman [1] https://lists.gnupg.org/pipermail/gnupg-users/2017-August/058834.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4814 bytes Desc: not available URL: From Roman.Fiedler at ait.ac.at Fri Aug 4 16:22:20 2017 From: Roman.Fiedler at ait.ac.at (Fiedler Roman) Date: Fri, 4 Aug 2017 14:22:20 +0000 Subject: AW: Extraction of decryption session key without copying complete encrypted file In-Reply-To: References: <2ECE9D9EEF1F524185270138AE23265955AD30F7@S0MSMAIL112.arc.local> <87bmnvtuf6.fsf@wheatstone.g10code.de> <20170804133918.GA3450@c720-r314251> Message-ID: <2ECE9D9EEF1F524185270138AE23265955AD458E@S0MSMAIL112.arc.local> > Von: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] Im Auftrag von > > On 04/08/17 14:39, Matthias Apitz wrote: > > But this implies that everyone with priv access on the remote host > could > > abuse your secret key on your localhost, especially when a GnuPG-card > is > > used and you entered the PIN to unlock the secret key. I'm wrong? > > Yes, someone with root on the remote machine can do whatever they want > on that machine. The solution is not to perform *any* crypto on a > machine whose admins you do not trust. There's nothing that software can > do to protect you from rogue sysadmins. > > If you don't want the sysadmins on the remote machine to abuse your > private key, then you have to download the data, perform your crypto > locally and ... CAVEAT here! > ... then upload the data again. Once you allow any software on > the remote machine to access your local resources, the remote sysadmins > can access them too. > > This applies to all sorts of other things BTW, such as client drives and > printers shared over RDP. So true, except for one minor thing: from risk perspective, the damage is the same if you download and upload again: if the attacker/sysadmin has replaced the file with something, you did not want to decrypt, you will decrypt the wrong thing and upload it again. The only way to prevent that is to review the unencrypted data before uploading it again. The initial workflow in [1] does not include the review either, thus should be of same security/risk level as the procedure you described. Currently I believe, that in our workflow this additional protection would not be worth it: if an attack can both replace an encrypted backup file on the main backup storage with something more valuable, encrypted with the same key, and then fetch the decrypted data from the system receiving the backup dump for restore, then we are completely done anyway. I just want to avoid to have an additional point of failure (except the keystore itself), where compromise of a single machine will compromise arbitrary backup data. LG Roman [1] https://lists.gnupg.org/pipermail/gnupg-users/2017-August/058821.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4814 bytes Desc: not available URL: From 2014-667rhzu3dc-lists-groups at riseup.net Fri Aug 4 20:15:46 2017 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Fri, 4 Aug 2017 19:15:46 +0100 Subject: gnupg or gpg-agent options for parallelism and memory usage In-Reply-To: <2ECE9D9EEF1F524185270138AE23265955AD42FB@S0MSMAIL112.arc.local> References: <699d3221-ba52-2923-7f39-1cfa3e8ca029@gmail.com> <2ECE9D9EEF1F524185270138AE23265955AD42FB@S0MSMAIL112.arc.local> Message-ID: <194837707.20170804191546@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Friday 4 August 2017 at 10:56:09 AM, in , Fiedler Roman wrote:- > PS: CAVEAT, gnupg-users list seems to be configured > in strange way: "reply to > all" does not reply to the list, It does here. I normally just use "Reply", same as other lists. - -- Best regards MFPA Wise men learn many things from their enemies. -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQQzrO1O6RNO695qhQYXErxGGvd45AUCWYS53V8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNB Q0VENEVFOTEzNEVFQkRFNkE4NTA2MTcxMkJDNDYxQUY3NzhFNAAKCRAXErxGGvd4 5NEWAP4jRg1XiSkuLYH0FZYWq/3yjpOvL7EGm6VI5TipiRRRMAEA7+/TSlEgd3CL rIMY7u19fuM4TfYWAqeClyns5LSl6wWJAZMEAQEKAH0WIQSzrn7KmoyLMCaloPVr fHTOsx8l8AUCWYS5718UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0QjNBRTdFQ0E5QThDOEIzMDI2QTVBMEY1NkI3 Qzc0Q0VCMzFGMjVGMAAKCRBrfHTOsx8l8M13B/9GvBlixYK4BRowLxs2tUbtsH8e zxl4r+J1FD7bZe5ykX6nsdmLLnwRyMRArrYmlF5zsALy2Rg1YsjxkuO10Gwwmr76 JgXOHsqrcmGU7q9Z0khdm/Vfl7maB6Y/QNVT0drZoo4cahrIofXtcQjJUyjAboZ9 vcREglQO+TrY+oVqyFZP0C0CIVB83jCDFxH0UgPcmTML8akGEoI8uMTChCeQYV/a ImLDQEj5SzYazR/eohVk2+gBvDbE6CbPtSxU93Zh4foqzFrP6W8QnZHwzajgmSKx QR3Rup9eVSA5M7g+gWTmHWEc3wZ6Wzi9VVpCwcZOwN5fzGVSIhiYJOT6oWC+ =Ydgi -----END PGP SIGNATURE----- From gongalreddy.sirish at yahoo.com Fri Aug 4 17:54:24 2017 From: gongalreddy.sirish at yahoo.com (sirishreddyg) Date: Fri, 4 Aug 2017 08:54:24 -0700 (MST) Subject: GPG Decryption Issue In-Reply-To: <87h8xntuyi.fsf@wheatstone.g10code.de> References: <1501781079403-52939.post@n7.nabble.com> <87h8xntuyi.fsf@wheatstone.g10code.de> Message-ID: <1501862064248-52955.post@n7.nabble.com> Thank you. Let me try it out and will update you as I make progress. Thanks, Sirish -- View this message in context: http://gnupg.10057.n7.nabble.com/GPG-Decryption-Issue-tp52939p52955.html Sent from the GnuPG - User mailing list archive at Nabble.com. From david at gbenet.com Sat Aug 5 00:13:26 2017 From: david at gbenet.com (david at gbenet.com) Date: Fri, 4 Aug 2017 23:13:26 +0100 Subject: Posting short GnuPG clear signed messages on social media sites In-Reply-To: <3xP6B06vTgz10Hh@submission01.posteo.de> References: <3xP6B06vTgz10Hh@submission01.posteo.de> Message-ID: <67ee5058-344f-8af2-5409-e4155132b3a6@gbenet.com> On 04/08/17 13:46, Stefan Claas wrote: > zbarimg image.jpg > output.txt && sed "s/QR-Code:-/-/g" output.txt Hello, I decided to follow your instructions: (1) I encrypted some text file size 1569 bytes (2) I ran qrencode -o david.png david.asc (3) Got david.png 291 bytes (4) I ran your command zbarimg david.png > david.asc && sed "s/QR-Code:-/-/g" david.asc (5) created david.asc 18 bytes (6) All david.asc contained was "QR-Code:david.asc" (7) Which was not the original text. (8) zbarimg can display a png like any other but seems not capable of converting it back to its original form. Am working on a solution David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From stefan.claas at posteo.de Sat Aug 5 02:55:39 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Sat, 5 Aug 2017 02:55:39 +0200 Subject: Posting short GnuPG clear signed messages on social media sites In-Reply-To: <67ee5058-344f-8af2-5409-e4155132b3a6@gbenet.com> References: <3xP6B06vTgz10Hh@submission01.posteo.de> <67ee5058-344f-8af2-5409-e4155132b3a6@gbenet.com> Message-ID: <3xPQMT4gMNzyrx@submission01.posteo.de> On Fri, 4 Aug 2017 23:13:26 +0100, david at gbenet.com wrote: > (8) zbarimg can display a png like any other but seems not capable of > converting it back to its original form. Am working on a solution Hi, sorry to hear that it is not working for you! I tried this already several times and it always worked for me. Here's again a little test without GnuPG usage. I created a padded test message with the same byte amount like your file has. Input for qrencode: Mmmhhh, that is strange! -----BEGIN MEANINGLESS GARBAGE----- MVXSBmYwx4zhaWHafBnZXSm3xnz4oGCI2wggKZSWenFAmHQ9Rhg3HRHcENXaxRZxRwTkpUZY uEh+Z76uXDJMmxFzXACmk6Ztd24RASUiP6hVAvtH3MWH74/Nevh0XaumqQKIAQ8wQZyQjPhq KKSKfLhD2rKhXuUgQGZGzrc2LXDAh1VhhRLeZqfsCzcs4CsszuxKZM+foy4r1L1isbehK8Rb Gb737313X99ohpZ7M8q2kI5TaHC5xiYhvN/VqsfWbTQc/fj56pvHg22XhR9mD8PMpR+D5+ca +/+GpnMjYpRlXT73Zq2dmsDbm3Jq+pb8tz2vqGlDsqvLfuBDWtvomftFtFs874Nz6C36g7/i iJ7r7SXeq2YZ5n0UBflnU7AuZrNTSLYeVyPniRbSy9OZWRUZ8IHhohL+NtaZCx4i9HCLJqVJ aIoDnBqIsRuZYtrsLRg+hKTFButGkemYfEd3IdpTn0G7+6B4rEgWXdr49aDHb9I8nN1XNbpj p8Yy4z2/XP/EWeoyybbh1+jH5Af+xlsxRE7zKfsbOFvVbIecKac/F8H7diaES0eQpZOolpwj JZp6h4AmUM+Y5dpdQhf0jfN4JnTvsajv8oRXlClcpguPB9SPFbiqMfmqJWh14KUTOs4vqcB0 XeuKtj+C9KYh52MY+44mMrLTGcAPkXPZYQAzy6H8SGHvTuBVw+sB2cvC9WI9E4RrYpKhuCkY 1PQ8D8aTe87aVXrEnTiG95d0S7wE6k0emsiVt6esa3gp780uOFTEir5sOZh5t+1aUDYyrjU1 lsR9/ikdODqfnJHscu1d9jwf2Si3bv6v368MaLpTFayD6s8oJxJbh5p8g9J20mLbUtdXq9x6 1taT8IHM59XMp8tHGflJdBJhx/Y6mYtmN2HzkVqM/e3B2Pm10JAok+3bgXvwSNs4Uea1RK2f 7HAggmsGvFl4mihCVH1FkhQXyH1qwbjv1wQ8f7kPDYBAXkbpK20NsNxFX8L9BoeHbutiZp4d dlhCW1tbNYLDtOTzb0Zlh7QPKWIIdlsijT21YdBtuKHoHU60S7BR8bblrCcbJbLwMOBtOJfo 6mWPFQIYQVnGv2RebLVomKqJ37xUkjyT/aEWHhzWb1aL9FOwfIe2JJJzQEZgBI7gqEORTtd3 u8Z07erxRWzpruXs5e3/owb6KCr+dlso7uj02hp95VRq7Zy5GonIkRGovFELceSOqavk6bus T8N3GJvec2li0fj3KVvtoYM71g0eCF8q5VHUitYiaZnRMTb90TpAH7DHY9pRckBX1EmGZtE4 bWIAW1cVpOmPRIbFEmdE5Ezy0o3GP2HYUc4M/5ajaKApWd8oex1oL9Au+LinzcSzq80dmPzc nRVEwxy9g9+MbXBTdNutn+3pt5+SVvOx9PVR9487UNAmwDRNO7uhuQLOUDQqSuCAtbaw3/MG VKWC3elXeQPwA -----END MEANINGLESS GARBAGE----- Output from zbarimg: QR-Code:Mmmhhh, that is strange! -----BEGIN MEANINGLESS GARBAGE----- MVXSBmYwx4zhaWHafBnZXSm3xnz4oGCI2wggKZSWenFAmHQ9Rhg3HRHcENXaxRZxRwTkpUZY uEh+Z76uXDJMmxFzXACmk6Ztd24RASUiP6hVAvtH3MWH74/Nevh0XaumqQKIAQ8wQZyQjPhq KKSKfLhD2rKhXuUgQGZGzrc2LXDAh1VhhRLeZqfsCzcs4CsszuxKZM+foy4r1L1isbehK8Rb Gb737313X99ohpZ7M8q2kI5TaHC5xiYhvN/VqsfWbTQc/fj56pvHg22XhR9mD8PMpR+D5+ca +/+GpnMjYpRlXT73Zq2dmsDbm3Jq+pb8tz2vqGlDsqvLfuBDWtvomftFtFs874Nz6C36g7/i iJ7r7SXeq2YZ5n0UBflnU7AuZrNTSLYeVyPniRbSy9OZWRUZ8IHhohL+NtaZCx4i9HCLJqVJ aIoDnBqIsRuZYtrsLRg+hKTFButGkemYfEd3IdpTn0G7+6B4rEgWXdr49aDHb9I8nN1XNbpj p8Yy4z2/XP/EWeoyybbh1+jH5Af+xlsxRE7zKfsbOFvVbIecKac/F8H7diaES0eQpZOolpwj JZp6h4AmUM+Y5dpdQhf0jfN4JnTvsajv8oRXlClcpguPB9SPFbiqMfmqJWh14KUTOs4vqcB0 XeuKtj+C9KYh52MY+44mMrLTGcAPkXPZYQAzy6H8SGHvTuBVw+sB2cvC9WI9E4RrYpKhuCkY 1PQ8D8aTe87aVXrEnTiG95d0S7wE6k0emsiVt6esa3gp780uOFTEir5sOZh5t+1aUDYyrjU1 lsR9/ikdODqfnJHscu1d9jwf2Si3bv6v368MaLpTFayD6s8oJxJbh5p8g9J20mLbUtdXq9x6 1taT8IHM59XMp8tHGflJdBJhx/Y6mYtmN2HzkVqM/e3B2Pm10JAok+3bgXvwSNs4Uea1RK2f 7HAggmsGvFl4mihCVH1FkhQXyH1qwbjv1wQ8f7kPDYBAXkbpK20NsNxFX8L9BoeHbutiZp4d dlhCW1tbNYLDtOTzb0Zlh7QPKWIIdlsijT21YdBtuKHoHU60S7BR8bblrCcbJbLwMOBtOJfo 6mWPFQIYQVnGv2RebLVomKqJ37xUkjyT/aEWHhzWb1aL9FOwfIe2JJJzQEZgBI7gqEORTtd3 u8Z07erxRWzpruXs5e3/owb6KCr+dlso7uj02hp95VRq7Zy5GonIkRGovFELceSOqavk6bus T8N3GJvec2li0fj3KVvtoYM71g0eCF8q5VHUitYiaZnRMTb90TpAH7DHY9pRckBX1EmGZtE4 bWIAW1cVpOmPRIbFEmdE5Ezy0o3GP2HYUc4M/5ajaKApWd8oex1oL9Au+LinzcSzq80dmPzc nRVEwxy9g9+MbXBTdNutn+3pt5+SVvOx9PVR9487UNAmwDRNO7uhuQLOUDQqSuCAtbaw3/MG VKWC3elXeQPwA -----END MEANINGLESS GARBAGE----- Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 506 bytes Desc: Digitale Signatur von OpenPGP URL: From stefan.claas at posteo.de Sat Aug 5 10:04:46 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Sat, 5 Aug 2017 10:04:46 +0200 Subject: Posting short GnuPG clear signed messages on social media sites In-Reply-To: <3xPQMT4gMNzyrx@submission01.posteo.de> References: <3xP6B06vTgz10Hh@submission01.posteo.de> <67ee5058-344f-8af2-5409-e4155132b3a6@gbenet.com> <3xPQMT4gMNzyrx@submission01.posteo.de> Message-ID: <3xPbtd4Dxvz101F@submission01.posteo.de> On Sat, 5 Aug 2017 02:55:39 +0200, Stefan Claas wrote: > On Fri, 4 Aug 2017 23:13:26 +0100, david at gbenet.com wrote: > > > (8) zbarimg can display a png like any other but seems not capable > > of converting it back to its original form. Am working on a > > solution > > Hi, > > sorry to hear that it is not working for you! > > I tried this already several times and it always worked for me. I re-read your reply and saw that you used in point 2: qrencode -o david.png david.asc please try: qrencode -o david.png < david.asc then it should work. I also looked for other decoders and found a C++ port of zxing, which makes the task shorter in Terminal, because we can omit sed. https://github.com/glassechidna/zxing-cpp Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 506 bytes Desc: Digitale Signatur von OpenPGP URL: From david at gbenet.com Sat Aug 5 12:30:08 2017 From: david at gbenet.com (david at gbenet.com) Date: Sat, 5 Aug 2017 11:30:08 +0100 Subject: Posting short GnuPG clear signed messages on social media sites In-Reply-To: <3xPbtd4FGdz104x@submission01.posteo.de> References: <3xP6B06vTgz10Hh@submission01.posteo.de> <67ee5058-344f-8af2-5409-e4155132b3a6@gbenet.com> <3xPQMT4gMNzyrx@submission01.posteo.de> <3xPbtd4FGdz104x@submission01.posteo.de> Message-ID: On 05/08/17 09:04, Stefan Claas wrote: > On Sat, 5 Aug 2017 02:55:39 +0200, Stefan Claas wrote: >> On Fri, 4 Aug 2017 23:13:26 +0100, david at gbenet.com wrote: >> >>> (8) zbarimg can display a png like any other but seems not capable >>> of converting it back to its original form. Am working on a >>> solution >> >> Hi, >> >> sorry to hear that it is not working for you! >> >> I tried this already several times and it always worked for me. > > I re-read your reply and saw that you used in point 2: > > qrencode -o david.png david.asc > > please try: qrencode -o david.png < david.asc > > then it should work. > > I also looked for other decoders and found a C++ port of zxing, which > makes the task shorter in Terminal, because we can omit sed. > > https://github.com/glassechidna/zxing-cpp > > Regards > Stefan > > Hello Stefan, Firstly the "<" did the trick - I used QtQr - to decode back and then to decrypt Kleopatra - and it worked fine QtQR creates pngs but did not use this feature. I've tried unsuccessfully to get people on FB to encrypt and have always promoted gnupg or gpg4win but no one seems to take thier privacy very seriously :) David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xAAD8C47D.asc Type: application/pgp-keys Size: 5036 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From stefan.claas at posteo.de Sat Aug 5 13:44:14 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Sat, 5 Aug 2017 13:44:14 +0200 Subject: Posting short GnuPG clear signed messages on social media sites In-Reply-To: References: <3xP6B06vTgz10Hh@submission01.posteo.de> <67ee5058-344f-8af2-5409-e4155132b3a6@gbenet.com> <3xPQMT4gMNzyrx@submission01.posteo.de> <3xPbtd4FGdz104x@submission01.posteo.de> Message-ID: <3xPhlr2rF0z1090@submission01.posteo.de> On Sat, 5 Aug 2017 11:30:08 +0100, david at gbenet.com wrote: > Hello Stefan, > > Firstly the "<" did the trick - I used QtQr - to decode back and then > to decrypt Kleopatra - and it worked fine QtQR creates pngs but did > not use this feature. Hi David, glad that it works now for you. > I've tried unsuccessfully to get people on FB to encrypt and have > always promoted gnupg or gpg4win but no one seems to take thier > privacy very seriously :) Well, i guess we are all here in the same boat with this... I started using PGP in 1994 and submitted my first public key to key servers in 1995. Since then i also tried to convince family members, friends and co-workers to use PGP/GnuPG, but as usual no interest was/is shown in securing email etc. A while ago i thought also to convince people to use S/MIME because their is no learning curve as with GnuPG involved, but nobody was interested either. Same goes for suggesting modern (free) Web based email providers like ProtonMail, for example. No interest either. I also started an international Facebook group a couple of years ago about PGP/GnuPG and it has the amazing number of *36* members (including me) while Facebook has now 2 billion monthly users...!!! I think the problem with encryption and GnuPG is that it has no lobby from industry giants like Apple, Microsoft, Google, etc. In post Snowden times it should be possible for developers who create commercial OS Software and mail clients that those softwares warns a user when using a commercial mail client that he/she has not set-up encryption yet, prior first usage. Whether it is a GnuPG or S/MIME. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 506 bytes Desc: Digitale Signatur von OpenPGP URL: From 2014-667rhzu3dc-lists-groups at riseup.net Sat Aug 5 14:14:13 2017 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sat, 5 Aug 2017 13:14:13 +0100 Subject: Posting short GnuPG clear signed messages on social media sites In-Reply-To: <3xP6B06vTgz10Hh@submission01.posteo.de> References: <3xP6B06vTgz10Hh@submission01.posteo.de> Message-ID: <1878036984.20170805131413@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Friday 4 August 2017 at 1:46:19 PM, in , Stefan Claas wrote:- > Hi all, > i don't know how many of you folks use social media > sites like Twitter > and Facebook etc. and wondered what's a way to post a > GnuPG clear > signed message on those sites, due to line width > limits or characters > per message limits. For Facebook, pasting in the signed and/or encrypted message and clicking "post" is the simplest way. > I found out that with short GnuPG clear signed messages a good way > to do that is to encode the message in the popular QR-Code format. I don't use Twitter but converting text to a QR code and posting it as an image is an interesting way around the 140-character limit. There are also plenty of mobile phone apps around that will read or generate QR codes, so people don't need to jump through too many hoops to read the message. - -- Best regards MFPA It is not necessary to have enemies if you go out of your way to make friends hate you. -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQQzrO1O6RNO695qhQYXErxGGvd45AUCWYW2mF8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNB Q0VENEVFOTEzNEVFQkRFNkE4NTA2MTcxMkJDNDYxQUY3NzhFNAAKCRAXErxGGvd4 5JacAPwP+P++xeGLh8XwW1EBdkfty9rFmQXyTW7dAdGsTrC06wD/cRBuVeOBdFge jEaFBH0496milX3B8KRKBrvXyLy5rQmJAZMEAQEKAH0WIQSzrn7KmoyLMCaloPVr fHTOsx8l8AUCWYW2mF8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0QjNBRTdFQ0E5QThDOEIzMDI2QTVBMEY1NkI3 Qzc0Q0VCMzFGMjVGMAAKCRBrfHTOsx8l8HEDB/4lkJXGd0pbB8K8l5XBORHQCozV 8EEmexyNYLCp19tPD6I/glzHRCp+QX4f/v/7Yjw4kBT2s3sUaWfOyWe6VdbcoDSm CofTSwKEU+QLqAtALPAJZ3e/CfNF3Voe93iHLoqt2lFjENyRkzHGl8k/Ch+jMb8R Wu84TjcGL6BRqnu2outTV753vUNkhcqAgmA14I/D9AsPHSITWmAmANPdvOVeCdgn G3y48I0mzIgvFpLBTArUnpH/KpVTBaCO/eVQAJONtYMBCkCwZR1ukGU32rncVGvl TLK5Y1T0qp6HsTXGOYciGEw+ehHEB7TJ9xkj9JVjNS/E0GAbCMeGoOpEFVwa =XMIB -----END PGP SIGNATURE----- From alex at nitrokey.com Sat Aug 5 13:23:01 2017 From: alex at nitrokey.com (Alexander Paetzelt | Nitrokey) Date: Sat, 5 Aug 2017 13:23:01 +0200 Subject: Backup-Option of 'card-edit->generate' not working as intended? Message-ID: <6cfca769-6c02-5e35-f2e2-4c4454c7c397@nitrokey.com> Hello, I really tried allot now and after fully reading this discussion https://lists.gt.net/gnupg/users/80661#80660 and after getting a confirmation and a suggestion what is probably going wrong of a user, I hope you may can help me and maybe fix the problem. *What I want to do* Create a key for a gnupg smartcard and having a backup of the whole keypair for the case that the stick got broken or just to copy the keys to another stick. To keep it simple, I tried the generation option of gpg, that intends to create the keypair and inserting it to the card or respectively create the keys on card. This have also a backup-option. *What I tried* - inserting new/reseted keycard - 'gpg --card-edit' -> 'admin' -> 'generate' - I will be asked, if I would like to have an backup generated. Oh yes, that would be great! - After completion I am told that the backup is in .gnupg/sk_xxxxx.gpg - This backup can be imported to a keyring, but neither asked for a passphrase nor contains a valid private key. - The very same seems to be done by Enigmails function to generate keys on smartcards - It is basically what is shown here https://www.gnupg.org/howtos/card-howto/en/ch03s03.html *What seems to happen* - The 'backup' probably only contains one of the three key generated in the process and therefore cannot fully restore the keys of the card - Furthermore the secret key seems to be not included or cannot be imported *What I would wish/expect from the creation with backup* I would have thought that the backup file contains everything needed to restore the key otherwise secured in the card, even the passphrase protected privkey. So either the term "backup" is misleading or something goes wrong in the process. Do you have any idea what I may doing wrong or what we can do about it? I am fully aware, that I can first create a keypair with subkey and then import them into the card. It would just be great if there would be an easier option for users as this option is far more complex. I am using gpg 2.1.21. Thank you in advance for your help! Please tell me if I anything of my explanation is unclear. Kind regards Alex From stefan.claas at posteo.de Sat Aug 5 15:56:20 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Sat, 5 Aug 2017 15:56:20 +0200 Subject: Posting short GnuPG clear signed messages on social media sites In-Reply-To: <1878036984.20170805131413@riseup.net> References: <3xP6B06vTgz10Hh@submission01.posteo.de> <1878036984.20170805131413@riseup.net> Message-ID: <3xPlhF6tbwz10HX@submission01.posteo.de> On Sat, 5 Aug 2017 13:14:13 +0100, MFPA wrote: > For Facebook, pasting in the signed and/or encrypted message and > clicking "post" is the simplest way. Well, to me the formatting then looks a bit ugly. :-) I also tried it again with a document created with Text Wrangler under OS X, clear signed it and copy and pasted the file in Facebook. But when importing back and verifying it i get: gpg: invalid armor header: Lorem ipsum dolor sit amet, consectetur adipiscing\n gpg: invalid armor header:iQEzBAEBCAAdFiEEK6+F+SgavVQ4I8fFmB63w4LsUrQFAlmFyfIACgkQmB63w4Ls\n > > I found out that with short GnuPG clear signed messages a good way > > to do that is to encode the message in the popular QR-Code format. > > I don't use Twitter but converting text to a QR code and posting it as > an image is an interesting way around the 140-character limit. There > are also plenty of mobile phone apps around that will read or generate > QR codes, so people don't need to jump through too many hoops to read > the message. That was the main idea behind it, because i know a lot of well known security / privacy experts are on Twitter and maybe they find this little tip useful. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 506 bytes Desc: Digitale Signatur von OpenPGP URL: From 2014-667rhzu3dc-lists-groups at riseup.net Sat Aug 5 16:56:02 2017 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sat, 5 Aug 2017 15:56:02 +0100 Subject: TOFU db corruption detected Message-ID: <1157971614.20170805155602@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 gpg: TOFU db corruption detected. gpg: (further info: user id '[jpeg image of size 24800]' not on key block 'Fingerprint') I see the above message when encrypting to the key whose fingerprint I have redacted above. The copy of that key on my keyring does contain an image, which I can view by gpg --list-options show-photos --list-keys Fingerptint. How do I "rebuild" the TOFU database to get rid of the corruption? - -- Best regards MFPA Amateurs built the ark. Professionals built the Titanic. -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQQzrO1O6RNO695qhQYXErxGGvd45AUCWYXchF8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNB Q0VENEVFOTEzNEVFQkRFNkE4NTA2MTcxMkJDNDYxQUY3NzhFNAAKCRAXErxGGvd4 5BxlAPwPO52UPrf2Af4R7G0HdTS8k5E2H1fYyyV0GINViNscpwD/YSux0yzWGz8K 4ZdKm7PSeo0bhFK/ZayVt/1UedGcywGJAZMEAQEKAH0WIQSzrn7KmoyLMCaloPVr fHTOsx8l8AUCWYXctl8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0QjNBRTdFQ0E5QThDOEIzMDI2QTVBMEY1NkI3 Qzc0Q0VCMzFGMjVGMAAKCRBrfHTOsx8l8AqfB/wKdES7P0NqQHYbKdYqcHn3Ch2y 7EuJ4LblNl30clAKzm2L/4rLX/RSDN5SVU/QwTO8D/3c8UWgIb+iDsTXQvSfa0wk VNG32SsYSsMU8mLXaXWsDFEMB/RTx0fRIMdPLfRW9BG41DQcNVZMOQT7xJW+C7Mp Dej7Pln41PZQLtsK7I6EcjTqB6zJtszg5AuVBketmVxnoHAGxgLBa3DksQiZi46d DOKCMfxBE2N4JyhFooaGGY73bdS6Np+CUZY8v4a9UfsLBfG+DPepebXoMXXbg71p U8sXQQrds4DuyiS4+7uxpHDSJa4SFlI7ZQA7U9MyxFYPj6P7XPMU+m6GqkOU =Bjkr -----END PGP SIGNATURE----- From tlikonen at iki.fi Sat Aug 5 17:30:12 2017 From: tlikonen at iki.fi (Teemu Likonen) Date: Sat, 05 Aug 2017 18:30:12 +0300 Subject: TOFU db corruption detected In-Reply-To: <1157971614.20170805155602@riseup.net> (MFPA's message of "Sat, 5 Aug 2017 15:56:02 +0100") References: <1157971614.20170805155602@riseup.net> Message-ID: <87mv7e118b.fsf@mithlond.arda> MFPA [2017-08-05 15:56:02+01] wrote: > How do I "rebuild" the TOFU database to get rid of the corruption? Before the developers give you more educated answers I'll point out that the tofu database is a regular Sqlite database file. So you can do: $ sqlite3 ~/.gnupg/tofu.db and then execute any SQL commands. Interesting SQL command could be "vacuum" which, in Sqlite, basically dumps the the database as SQL text commands, then deletes the database and finally reads the SQL dump again. If you want to try that, make a copy of your tofu.db file first. Then start Sqlite like the example line above and: sqlite> vacuum; https://www.sqlite.org/lang_vacuum.html -- /// 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: 487 bytes Desc: not available URL: From david at gbenet.com Sat Aug 5 19:55:51 2017 From: david at gbenet.com (david at gbenet.com) Date: Sat, 5 Aug 2017 18:55:51 +0100 Subject: Posting short GnuPG clear signed messages on social media sites In-Reply-To: <3xPhlr2pcLz108v@submission01.posteo.de> References: <3xP6B06vTgz10Hh@submission01.posteo.de> <67ee5058-344f-8af2-5409-e4155132b3a6@gbenet.com> <3xPQMT4gMNzyrx@submission01.posteo.de> <3xPbtd4FGdz104x@submission01.posteo.de> <3xPhlr2pcLz108v@submission01.posteo.de> Message-ID: On 05/08/17 12:44, Stefan Claas wrote: > On Sat, 5 Aug 2017 11:30:08 +0100, david at gbenet.com wrote: > >> Hello Stefan, >> >> Firstly the "<" did the trick - I used QtQr - to decode back and then >> to decrypt Kleopatra - and it worked fine QtQR creates pngs but did >> not use this feature. > > Hi David, > > glad that it works now for you. My experience has been from te early 80s I thought encrypted communications would grow to a world wide phenomena - but I was a bit optimistic. Top security professional in my opinion don't tell people to encrypt which is there best form of security. It seems to me there are two or three types that use encryption (1) those that actually need it (2) computer nerds who think it's some holy grail (3) ordinary people trying to get more ordinary people to see sense I posted your little bit of advice to a Linux group on FB - the reaction was not as I expected - condescending replies in the main - none of whom and the intelligence to see the implications - I felt I was defending what was a good idea. Today with increased surveillance from security forces reading everything we do you would have thought that those involved in politics would at least use encryption - they have no idea what one is talking about. Thirty odd years have past - and still 90 per cent of the population who use computers and smart phones have no idea. Well 99.9 per cent :) I seem to hanging on to a vital bit of technology - and every one I know is still throwing flint spears at Hairy Mammoths :) Rant over - I shall go back to silent observation :) David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Sat Aug 5 20:07:09 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 5 Aug 2017 14:07:09 -0400 Subject: Posting short GnuPG clear signed messages on social media sites In-Reply-To: References: <3xP6B06vTgz10Hh@submission01.posteo.de> <67ee5058-344f-8af2-5409-e4155132b3a6@gbenet.com> <3xPQMT4gMNzyrx@submission01.posteo.de> <3xPbtd4FGdz104x@submission01.posteo.de> <3xPhlr2pcLz108v@submission01.posteo.de> Message-ID: > I posted your little bit of advice to a Linux group on FB - the > reaction was not as I expected - condescending replies in the main - > none of whom and the intelligence to see the implications - I felt I > was defending what was a good idea. Some years ago while teaching computer literacy at a university, some of my students told me they'd been at a nearby restaurant complaining with each other about how stupid the class was (we were covering privacy in the information age), while they were filling out credit card applications to get a free sandwich. I asked them what they did when they realized the privacy implications. "We got our free stuff and started talking about girls." From stefan.claas at posteo.de Sat Aug 5 21:41:48 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Sat, 5 Aug 2017 21:41:48 +0200 Subject: Posting short GnuPG clear signed messages on social media sites In-Reply-To: References: <3xP6B06vTgz10Hh@submission01.posteo.de> <67ee5058-344f-8af2-5409-e4155132b3a6@gbenet.com> <3xPQMT4gMNzyrx@submission01.posteo.de> <3xPbtd4FGdz104x@submission01.posteo.de> <3xPhlr2pcLz108v@submission01.posteo.de> Message-ID: <3xPvLt0ZVqz105R@submission01.posteo.de> On Sat, 5 Aug 2017 18:55:51 +0100, david at gbenet.com wrote: > My experience has been from te early 80s I thought encrypted > communications would grow to a world wide phenomena - but I was a bit > optimistic. Top security professional in my opinion don't tell people > to encrypt which is there best form of security. > > It seems to me there are two or three types that use encryption > > (1) those that actually need it > (2) computer nerds who think it's some holy grail > (3) ordinary people trying to get more ordinary people to see sense > > I posted your little bit of advice to a Linux group on FB - the > reaction was not as I expected - condescending replies in the main - > none of whom and the intelligence to see the implications - I felt I > was defending what was a good idea. The main motivation for me, why i still deal with things like privacy, anonymity and security on the Internet is my 11 years old godchild. When she get's older and those topics should come up i then can still teach her a bit about those things. :-) -- https://www.behance.net/futagoza https://keybase.io/stefan_claas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 506 bytes Desc: Digitale Signatur von OpenPGP URL: From youcanlinux at gmail.com Sun Aug 6 02:32:09 2017 From: youcanlinux at gmail.com (Daniel Villarreal) Date: Sat, 5 Aug 2017 20:32:09 -0400 Subject: TOFU db corruption detected In-Reply-To: <87mv7e118b.fsf@mithlond.arda> References: <1157971614.20170805155602@riseup.net> <87mv7e118b.fsf@mithlond.arda> Message-ID: <12c26785-04c9-d6d9-adda-4a85aa931791@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/05/17 11:30, Teemu Likonen wrote: > MFPA [2017-08-05 15:56:02+01] wrote: > >> ... "rebuild" the TOFU database to get rid of the corruption? > > ... tofu [db] is a regular Sqlite [db] file. So you can do: > > $ sqlite3 ~/.gnupg/tofu.db > > and ... SQL commands. Interesting SQL command could be "vacuum". > [Backup] tofu.db file first. Then start Sqlite ... > > sqlite> vacuum; https://www.sqlite.org/lang_vacuum.html Thanks to Jason L. Froebe... "... run sqlite3 with vacuum, reindex and analyze on each of the *.sqlite databases." I use this script with sqlite2 also. http://froebe.net/blog/2013/01/27/optimizing-the-firefox-sqlite-database s/ and then for all my different Firefox profiles, I change for profile in *.default; do to # for profile in *; do - -- Daniel Villarreal http://www.youcanlinux.org youcanlinux at gmail.com PGP key 2F6E 0DC3 85E2 5EC0 DA03 3F5B F251 8938 A83E 7B49 https://pgp.mit.edu/pks/lookup?op=get&search=0xF2518938A83E7B49 -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZhmOBAAoJEPJRiTioPntJxy4H/1SQBA9SyyBXc95XB75xKJGE 7cz1kHjIjplTOn2z3WLK9z41/qZuQVdo8nfefUtowLXegEozgK5kt00Qfmd8yf85 qN53eea9dZfZLe6dYZMtRlgRPY+kkuJoZY4uMylzHG6i8DRjrUU+nTlYy3BxYvFH pOZHzmeoIdFYrRIcYaJKQTzjf6eZJYSEEOKdxf7bTAtDs6h+kg7t8Bm2NDxtBg+/ +K2Dxg/Zq7PulEcxPeBinU4eWKXf0Xkmdm0yfBpKlE5y6y/c+px9EVwGpE/pr/l/ nFjnK5vknc+/MAqzbnrkEiAY0/y3QnJRVoS1B/NSSBL/I/UnL+Bi0dfL1XVv+pg= =QfmK -----END PGP SIGNATURE----- From werewolf6851 at gmail.com Sun Aug 6 07:29:37 2017 From: werewolf6851 at gmail.com (Werewolf) Date: Sun, 6 Aug 2017 00:29:37 -0500 Subject: Posting short GnuPG clear signed messages on social media sites In-Reply-To: <3xP6B06vTgz10Hh@submission01.posteo.de> References: <3xP6B06vTgz10Hh@submission01.posteo.de> Message-ID: <20170806052937.GA3757@gmail.com> On Fri, Aug 04, 2017 at 02:46:19PM +0200, Stefan Claas wrote: > So, simply prepare your short GnuPG message and then do a: > > $ qrencode -o message.png < message.txt.asc, to obtain a > .png image, ready to be posted on social media sites. A simpler methode on a linux system gpg --clearsign|qrencode -o message.png > To decode such an image in Terminal simply do a: > (please note: the images when downloaded are then in .jpeg format) > > http://zbar.sourceforge.net/download.html > > $ zbarimg image.jpg > output.txt && sed "s/QR-Code:-/-/g" output.txt | > gpg --verify For Decoding message and verifying signature zbarimg message.jpg| sed "s/QR-Code:-/-/g"|gpg or just to verify signature zbarimg message.png| sed "s/QR-Code:-/-/g"|gpg --verify Wolf -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: Digital signature URL: From stefan.claas at posteo.de Sun Aug 6 10:52:59 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Sun, 6 Aug 2017 10:52:59 +0200 Subject: Posting short GnuPG clear signed messages on social media sites In-Reply-To: <20170806052937.GA3757@gmail.com> References: <3xP6B06vTgz10Hh@submission01.posteo.de> <20170806052937.GA3757@gmail.com> Message-ID: <3xQDvm3YMHz10HS@submission01.posteo.de> On Sun, 6 Aug 2017 00:29:37 -0500, Werewolf wrote: > A simpler methode on a linux system > gpg --clearsign|qrencode -o message.png > For Decoding message and verifying signature > zbarimg message.jpg| sed "s/QR-Code:-/-/g"|gpg > > or just to verify signature > zbarimg message.png| sed "s/QR-Code:-/-/g"|gpg --verify Thanks for pointing that out! And with zxing, available at https://github.com/zxing/zxing we can omit sed usage. Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 506 bytes Desc: Digitale Signatur von OpenPGP URL: From 2014-667rhzu3dc-lists-groups at riseup.net Sun Aug 6 12:16:19 2017 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sun, 6 Aug 2017 11:16:19 +0100 Subject: Posting short GnuPG clear signed messages on social media sites In-Reply-To: <3xPlhF6s6xz10Bl@submission01.posteo.de> References: <3xP6B06vTgz10Hh@submission01.posteo.de> <1878036984.20170805131413@riseup.net> <3xPlhF6s6xz10Bl@submission01.posteo.de> Message-ID: <1498706671.20170806111619@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Saturday 5 August 2017 at 2:56:20 PM, in , Stefan Claas wrote:- > Well, to me the formatting then looks a bit ugly. :-) It does look ugly. But it is a text message, not a presentation. > But when importing back and verifying it i get: > gpg: invalid armor header: Lorem ipsum dolor sit > amet, consectetur > adipiscing\n gpg: invalid armor > header:iQEzBAEBCAAdFiEEK6+F+SgavVQ4I8fFmB63w4LsUrQFAlmFyfIACgkQmB63w4Ls\n I tested using text written in Notepad under Windows 10, then clearsigned using GnuPG, pasted into Facebook, and hit "post". When the post appeared on my timeline, I copied the text back from the post and verified the signature without any errors using GnuPG. I also tested with text that I signed and encrypted; I was able to decrypt and verify without any errors the text that appeared on my timeline. - -- Best regards MFPA Always forgive your enemies; nothing annoys them so much -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQQzrO1O6RNO695qhQYXErxGGvd45AUCWYbsdV8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNB Q0VENEVFOTEzNEVFQkRFNkE4NTA2MTcxMkJDNDYxQUY3NzhFNAAKCRAXErxGGvd4 5DPtAP93H8ZWwpWTWQXZCmNzvHy8PbvPRzS4MrNjpeX0sU/7BgEAnqCft0G06wBO /qJNbLCSceqvTTAHrGzN3ZxHRiS+3QaJAZMEAQEKAH0WIQSzrn7KmoyLMCaloPVr fHTOsx8l8AUCWYbsfV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0QjNBRTdFQ0E5QThDOEIzMDI2QTVBMEY1NkI3 Qzc0Q0VCMzFGMjVGMAAKCRBrfHTOsx8l8BgqB/9P9W2EVYhGkof5U6xsJzIxfxPa VLqAwY818l0xSNjxOtHCpPoCssuK8qJls7Oo8jjGuCodn1rdJ5jSq0Fk3RY2vYio 7NRR0zKzgiNPk3LpFQj0BaYToo3WywgWe4ZCRPr+yXcvEV+35Gt5w7fihoGJV1lB nv/T0OrmjgJtz2VEjQezBT+4EZV3a1xXk8E65D8g6yQBMPKjKtO3BjgaeTIlRYHZ PgMaWatWgzzWm+02DfdV3J/oP5H0NdMf8Dr9dQdNeU6ZqB/5Fbp4anEuf/11wCa8 1ZX3pwGCoi3TYgGJW4PUGQtPM0QTh/3kl5US8UeT3l5yzRjXzz0bem4z2O00 =fdzI -----END PGP SIGNATURE----- From stefan.claas at posteo.de Sun Aug 6 13:17:58 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Sun, 6 Aug 2017 13:17:58 +0200 Subject: Posting short GnuPG clear signed messages on social media sites In-Reply-To: <1498706671.20170806111619@riseup.net> References: <3xP6B06vTgz10Hh@submission01.posteo.de> <1878036984.20170805131413@riseup.net> <3xPlhF6s6xz10Bl@submission01.posteo.de> <1498706671.20170806111619@riseup.net> Message-ID: <3xQJ741cV4z101D@submission01.posteo.de> On Sun, 6 Aug 2017 11:16:19 +0100, MFPA wrote: > I tested using text written in Notepad under Windows 10, then > clearsigned using GnuPG, pasted into Facebook, and hit "post". When > the post appeared on my timeline, I copied the text back from the post > and verified the signature without any errors using GnuPG. I also > tested with text that I signed and encrypted; I was able to decrypt > and verify without any errors the text that appeared on my timeline. Well, i can't get it to work, even when changing to Windows file format. Always same error message. But no problem, because of QR-Code... :-) Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 506 bytes Desc: Digitale Signatur von OpenPGP URL: From 2014-667rhzu3dc-lists-groups at riseup.net Sun Aug 6 13:28:41 2017 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sun, 6 Aug 2017 12:28:41 +0100 Subject: TOFU db corruption detected In-Reply-To: <87mv7e118b.fsf@mithlond.arda> References: <1157971614.20170805155602@riseup.net> <87mv7e118b.fsf@mithlond.arda> Message-ID: <892662424.20170806122841@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Saturday 5 August 2017 at 4:30:12 PM, in , Teemu Likonen wrote:- > Before the developers give you more educated answers > I'll point out that > the tofu database is a regular Sqlite database file. > So you can do: > $ sqlite3 ~/.gnupg/tofu.db > and then execute any SQL commands. Interesting SQL > command could be > "vacuum" which, in Sqlite, basically dumps the the > database as SQL text > commands, then deletes the database and finally reads > the SQL dump > again. If you want to try that, make a copy of your > tofu.db file first. > Then start Sqlite like the example line above and: > sqlite> vacuum; > https://www.sqlite.org/lang_vacuum.html Thanks for replying. I downloaded Sqlite and tried that. It reduced the size of my tofu.db from 1532 to 1432 KB but unfortunately GnuPG still reports the same issue. - -- Best regards MFPA Beware the deadly donkey falling slowly from the sky -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQQzrO1O6RNO695qhQYXErxGGvd45AUCWYb9a18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNB Q0VENEVFOTEzNEVFQkRFNkE4NTA2MTcxMkJDNDYxQUY3NzhFNAAKCRAXErxGGvd4 5BVrAQCDiwNBDNPN9AtQUd92U5hQkTiXCCFyDrQhSSsNDtDocgEA3lxrSm0oFBrp 8os/BV2NqI7772dSVa8omLB6IkiDzQWJAZMEAQEKAH0WIQSzrn7KmoyLMCaloPVr fHTOsx8l8AUCWYb9a18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0QjNBRTdFQ0E5QThDOEIzMDI2QTVBMEY1NkI3 Qzc0Q0VCMzFGMjVGMAAKCRBrfHTOsx8l8DkGB/oDmSfN/uPAeI+SGZOwPVOjrMSN o/vm9urtqTMRfjv3xCU9qY9P8Lv3WEt6nCPWK3yCH1DOujjR1dis1muyI5aGAzvI Pm7MjDTZhhawBVX3zc3JywIxPBxc3ZO+L2S6zMfywAjOQP5Zx0vKijj6PMptBRi+ jVAyfyBs403wGFyo7PWrACylJVP1tnNXBMUGhaN4Zlg+bGu8Il2voBK6DXuV1Vkz YwtcgmAWUOF+AUIp/d09BVHGs9rWRywDFlTsPCoZZOfmHRUzHboTpAYqBljY1RJh sPE7VFBLejJSSg39jj3VcC9cm+Sj2C8fVWo5YsWw9u33l8u1Jpq52VMwHVSS =s6Fh -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Sun Aug 6 13:32:08 2017 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sun, 6 Aug 2017 12:32:08 +0100 Subject: TOFU db corruption detected In-Reply-To: <12c26785-04c9-d6d9-adda-4a85aa931791@gmail.com> References: <1157971614.20170805155602@riseup.net> <87mv7e118b.fsf@mithlond.arda> <12c26785-04c9-d6d9-adda-4a85aa931791@gmail.com> Message-ID: <486681899.20170806123208@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Sunday 6 August 2017 at 1:32:09 AM, in , Daniel Villarreal wrote:- > "... run sqlite3 with vacuum, reindex and analyze Reindex and analyze shrunk my tofu.db by a further 4 KB but GnuPG unfortunately still reports the same issue. - -- Best regards MFPA Day-old pastry is hollow succour to a man who is bereft of ostrich. -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQQzrO1O6RNO695qhQYXErxGGvd45AUCWYb+Ol8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNB Q0VENEVFOTEzNEVFQkRFNkE4NTA2MTcxMkJDNDYxQUY3NzhFNAAKCRAXErxGGvd4 5NWTAP9irQI4bwxuaova0nX6neWUs2V7qsDTII+cgjq4XElw8AD9F48t5Sq4Gyxt p+OXUAvj5sxGoDduYlsM9z5pKcmuTQmJAZMEAQEKAH0WIQSzrn7KmoyLMCaloPVr fHTOsx8l8AUCWYb+Ol8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0QjNBRTdFQ0E5QThDOEIzMDI2QTVBMEY1NkI3 Qzc0Q0VCMzFGMjVGMAAKCRBrfHTOsx8l8FjxCACq6PgcIGo1N96nwDlzegXRCUWU HcyMRYkpoRSVfeod0dLvRd+0gIafj2gI6b2eUr/WYq1Gic3f3QcnSf6MOFzYqwNG nHZ5GMI8W+zT49+jRm+n0VXdnygb6KLYUTB4Ci1J1fJyW1u+j8kH8krv81d6Xb6P mx6K47GXgVYmZSHp6j6E1/J2L9VgQ02bhNS3k2sAbr60oFca6Ftn3qw29ZjwC2yo TyOy+HIn9VP/nDNVAYAn2+CxLwoe6EJI5NLcHSUJ77Kw9bN9tqfTkKLNZS3v54Rr i6VgLJqqYHMwiZjaxgVZW2YqO9wy3Vd0GLC9hxbsn45wIxjkzWYWCHpxzRq0 =zo4J -----END PGP SIGNATURE----- From neal at walfield.org Mon Aug 7 12:06:45 2017 From: neal at walfield.org (Neal H. Walfield) Date: Mon, 07 Aug 2017 12:06:45 +0200 Subject: TOFU db corruption detected In-Reply-To: <1157971614.20170805155602@riseup.net> References: <1157971614.20170805155602@riseup.net> Message-ID: <87zibbite2.wl-neal@walfield.org> Hi, Unfortunately, there isn't enough information in this report to reproduce your issue. If you feel comfortable sending me your TOFU db and your pubring.gpg / pubring.kbx per private mail, as well as telling me which key that is causing the problem, then I will take a look. Key: 8F17 7771 18A3 3DDA 9BA4 8E62 AACB 3243 6300 52D9 Thanks, :) Neal On Sat, 05 Aug 2017 16:56:02 +0200, MFPA wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > gpg: TOFU db corruption detected. > gpg: (further info: user id '[jpeg image of size 24800]' not on key > block 'Fingerprint') > > > I see the above message when encrypting to the key whose fingerprint I > have redacted above. The copy of that key on my keyring does contain > an image, which I can view by > gpg --list-options show-photos --list-keys Fingerptint. > > > How do I "rebuild" the TOFU database to get rid of the corruption? > > > - -- > Best regards > > MFPA From wk at gnupg.org Mon Aug 7 19:58:30 2017 From: wk at gnupg.org (Werner Koch) Date: Mon, 07 Aug 2017 19:58:30 +0200 Subject: AW: Extraction of decryption session key without copying complete encrypted file In-Reply-To: <2ECE9D9EEF1F524185270138AE23265955AD444D@S0MSMAIL112.arc.local> (Fiedler Roman's message of "Fri, 4 Aug 2017 12:36:12 +0000") References: <2ECE9D9EEF1F524185270138AE23265955AD30F7@S0MSMAIL112.arc.local> <87bmnvtuf6.fsf@wheatstone.g10code.de> <2ECE9D9EEF1F524185270138AE23265955AD444D@S0MSMAIL112.arc.local> Message-ID: <87r2wnmf95.fsf@wheatstone.g10code.de> On Fri, 4 Aug 2017 14:36, Roman.Fiedler at ait.ac.at said: > Ah, that's great - and actually the first nice gpg-agent feature apart from > gpg-agent being little annoying when running it on RAM-disks in early boot. (And the ssh-agent support, which is one of the mos useful features I have on my box for 10 years or so.) > The agent forwarding guide from above is fine, should be easy to implement. > Just one more question: how do I restrict the private key lifetime within the > agent or the number of agent requests before password repeat is needed? Best You can't do that yet just for --extra-socket connection. You need to do that globally with --max-cache-ttl NSECONDS Normally w.o. the leading dashes in the gpg-agent.conf. In the future we will allow to do this on a per key base (utilizing the new --enabled-extended-key-format) and also allow to set a flag to require confirmation in the same way it is possible with ssh connections. 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: 227 bytes Desc: not available URL: From wk at gnupg.org Tue Aug 8 13:48:03 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 08 Aug 2017 13:48:03 +0200 Subject: gpgsm, keygrip In-Reply-To: <72263B41-F746-4469-B292-D49A1095BF41@webweaving.org> (Dirk-Willem van Gulik's message of "Sun, 30 Jul 2017 14:52:14 +0200") References: <02E40C08-434F-4080-AC5C-D1610E92CEFE@webweaving.org> <72263B41-F746-4469-B292-D49A1095BF41@webweaving.org> Message-ID: <87mv7al1qk.fsf@wheatstone.g10code.de> On Sun, 30 Jul 2017 14:52, dirkx at webweaving.org said: > Replying to my own question ? the man page of of gpg-preset-passphrase should perhaps suggest to use ?gpg ?with-keygrip ..? or ?gpg ?with-colons ..?. Thanks for the suggestion. However there is a gug in gpgsm which does not print the keygrip in --with-colon mode as described. A workaround is to use --with-key-data but that may eventually print even more stuff. I justed fixed it for the next release. 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: 227 bytes Desc: not available URL: From dirkx at webweaving.org Tue Aug 8 14:00:31 2017 From: dirkx at webweaving.org (Dirk-Willem van Gulik) Date: Tue, 8 Aug 2017 14:00:31 +0200 Subject: gpgsm, keygrip In-Reply-To: <87mv7al1qk.fsf@wheatstone.g10code.de> References: <02E40C08-434F-4080-AC5C-D1610E92CEFE@webweaving.org> <72263B41-F746-4469-B292-D49A1095BF41@webweaving.org> <87mv7al1qk.fsf@wheatstone.g10code.de> Message-ID: <1341DCD9-019E-42C4-836D-7FC283A0B9F8@webweaving.org> > On 8 Aug 2017, at 13:48, Werner Koch wrote: > > On Sun, 30 Jul 2017 14:52, dirkx at webweaving.org said: > >> Replying to my own question ? the man page of of gpg-preset-passphrase should perhaps suggest to use ?gpg ?with-keygrip ..? or ?gpg ?with-colons ..?. > > Thanks for the suggestion. However there is a gug in gpgsm which does > not print the keygrip in --with-colon mode as described. A workaround > is to use --with-key-data but that may eventually print even more > stuff. I justed fixed it for the next release. Lovely - we just checked against the master/head of an hour ago - and that tiny change greatly simplifies a lot of our scripts. Thanks ! Dw. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 223 bytes Desc: Message signed with OpenPGP URL: From wk at gnupg.org Tue Aug 8 13:56:52 2017 From: wk at gnupg.org (Werner Koch) Date: Tue, 08 Aug 2017 13:56:52 +0200 Subject: (pre)cache password rather than use allow-loopback-pinentry In-Reply-To: <25385242-589C-469B-9CF0-7338E73245CF@webweaving.org> (Dirk-Willem van Gulik's message of "Sat, 29 Jul 2017 20:24:07 +0200") References: <6DB92A48-B034-4C9F-9ED8-0C6DBCD0F22D@webweaving.org> <87lgni9tid.fsf@wheatstone.g10code.de> <4F571CE2-F0CD-4ECA-9312-7E8435D7852C@webweaving.org> <878tji9mdx.fsf@wheatstone.g10code.de> <87zibx92a4.fsf@wheatstone.g10code.de> <25385242-589C-469B-9CF0-7338E73245CF@webweaving.org> Message-ID: <87inhyl1bv.fsf@wheatstone.g10code.de> On Sat, 29 Jul 2017 20:24, dirkx at webweaving.org said: > Lovely. Is there any way one can suppress the fingerprint of the primary key (as when doing line oriented things; bith the ?sec? and ?ssb? line are followed by structurally identical ?fpr? lines)? No. You should use a simple state machine to process them: if you want to get the fingerprints of the subkey, wait for "sub" or "ssb" and catch the fpr or grp lines until you see another "sub" or "ssb" line. Something like this: awk -F: '$1 == "pub" || $1=="sec" {subseen=0; next} $1=="sub" || $1=="ssb" {subseen=1; next} $1=="fpr" && subseen {print $10}' 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: 227 bytes Desc: not available URL: From 2014-667rhzu3dc-lists-groups at riseup.net Wed Aug 9 01:20:42 2017 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Wed, 9 Aug 2017 00:20:42 +0100 Subject: TOFU db corruption detected In-Reply-To: <87zibbite2.wl-neal@walfield.org> References: <1157971614.20170805155602@riseup.net> <87zibbite2.wl-neal@walfield.org> Message-ID: <710426267.20170809002042@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Monday 7 August 2017 at 11:06:45 AM, in , Neal H. Walfield wrote:- > Hi, > Unfortunately, there isn't enough information in this > report to > reproduce your issue. If you feel comfortable > sending me your TOFU db > and your pubring.gpg / pubring.kbx per private mail, > as well as > telling me which key that is causing the problem, > then I will take a > look. Thanks for the offer. I dumped the tofu.db to a text file, deleted the bindings relating the the problem key and to a revoked key from the same user, deleted the signature and encryption entries relating to those bindings, then restored from the dump file. I don't know what issues this may introduce but I no longer get the "TOFU db corruption detected" messages. - -- Best regards MFPA My mind works like lightning... one brilliant flash and it's gone -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQQzrO1O6RNO695qhQYXErxGGvd45AUCWYpHS18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNB Q0VENEVFOTEzNEVFQkRFNkE4NTA2MTcxMkJDNDYxQUY3NzhFNAAKCRAXErxGGvd4 5JcIAP4n5i+77g5bvkCysEatCgHB9THHiCChInhfyr96Xg01kAD/Q3YcPezGmi1+ rALQunLa7xPNuwJVnuCYihUr2swQDw6JAZMEAQEKAH0WIQSzrn7KmoyLMCaloPVr fHTOsx8l8AUCWYpHVV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0QjNBRTdFQ0E5QThDOEIzMDI2QTVBMEY1NkI3 Qzc0Q0VCMzFGMjVGMAAKCRBrfHTOsx8l8GkhCACSL74xfkv0uH3BSQ7X3+TdeaUf RJqQ0BaU6wraCV0+YBZZQlLWQxjZGLyKR09FZBVNz9OJUcV+fUVh4rbeETr4h5+f TGw358W2rVzohdWdz+IoPQhLpUMwtzSIWZ3+mus8CXokh1N/aOUL9oPUiUgkhhO3 +AX372Nd//mRQ8naCDj/HH8XILGjqp10njCUZYtIZfy9zlRaYsLvrY/UxfCKWAZu xojN0UAayoCXukxnssECVPLkHRYGFGzT85NfLgNrgcp++GWTW6B1v8F89X+sAx11 C51W7AxLQTYGNyNcCK5k0Az+l1bCWc5oErTmFuD2h0uE+hYDhedWYh/6YCsc =ZVN0 -----END PGP SIGNATURE----- From gongalreddy.sirish at yahoo.com Wed Aug 9 03:04:51 2017 From: gongalreddy.sirish at yahoo.com (sirishreddyg) Date: Tue, 8 Aug 2017 18:04:51 -0700 (MST) Subject: GPG Decryption Issue In-Reply-To: <1501862064248-52955.post@n7.nabble.com> References: <1501781079403-52939.post@n7.nabble.com> <87h8xntuyi.fsf@wheatstone.g10code.de> <1501862064248-52955.post@n7.nabble.com> Message-ID: <1502240691635-53011.post@n7.nabble.com> Hi, Actually it's issue with the Custom Adapter we use with our Integration Product. I was able to fix it now. Everything is working fine. Thank you. -- View this message in context: http://gnupg.10057.n7.nabble.com/GPG-Decryption-Issue-tp52939p53011.html Sent from the GnuPG - User mailing list archive at Nabble.com. From wk at gnupg.org Wed Aug 9 17:12:58 2017 From: wk at gnupg.org (Werner Koch) Date: Wed, 09 Aug 2017 17:12:58 +0200 Subject: [Announce] GnuPG 2.1.23 released Message-ID: <877eycixl1.fsf@wheatstone.g10code.de> Hello! The GnuPG team is pleased to announce the availability of a new release of GnuPG: version 2.1.23. See below for a list of new features and bug fixes. This a release candidate for 2.2.0. 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. As an Universal Crypto Engine 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. Noteworthy changes in version 2.1.23 ==================================== * gpg: "gpg" is now installed as "gpg" and not anymore as "gpg2". If needed, the new configure option --enable-gpg-is-gpg2 can be used to revert this. * gpg: Options --auto-key-retrieve and --auto-key-locate "local,wkd" are now used by default. Note: this enables keyserver and Web Key Directory operators to notice when a signature from a locally non-available key is being verified for the first time or when you intend to encrypt to a mail address without having the key locally. This new behaviour will eventually make key discovery much easier and mostly automatic. Disable this by adding no-auto-key-retrieve auto-key-locate local to your gpg.conf. * agent: Option --no-grab is now the default. The new option --grab allows to revert this. * gpg: New import option "show-only". * gpg: New option --disable-dirmngr to entirely disable network access for gpg. * gpg,gpgsm: Tweaked DE-VS compliance behaviour. * New configure flag --enable-all-tests to run more extensive tests during "make check". * gpgsm: The keygrip is now always printed in colon mode as documented in the man page. * Fixed connection timeout problem under Windows. 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.23 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: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.23.tar.bz2 (6374k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.23.tar.bz2.sig or via FTP: ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.23.tar.bz2 ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.23.tar.bz2.sig An installer for Windows without any graphical frontend except for a very minimal Pinentry tool is available here: https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.23_20170809.exe (3794k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.23_20170809.exe.sig or via FTP: ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.23_20170809.exe ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.23_20170809.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. The Windows installer comes with TOFU support, many translations, support for Tor, and support for HKPS and the Web Key Directory. 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.23.tar.bz2 you would use this command: gpg --verify gnupg-2.1.23.tar.bz2.sig gnupg-2.1.23.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.23.tar.bz2, you run the command like this: sha1sum gnupg-2.1.23.tar.bz2 and check that the output matches the next line: c470777eaa9657ef3258068507065c9a7caef9eb gnupg-2.1.23.tar.bz2 c95f1c2dc3aa06dda2a58ba5aefb362511f666e3 gnupg-w32-2.1.23_20170809.exe 90a692391f1e314cffa1d54fa9c28855c24ecda6 gnupg-w32-2.1.23_20170809.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. We are now in string freeze for 2.2 and updated translations are very welcome. 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 4 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. Happy hacking, Your GnuPG Team 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 five keys: 2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31] Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 Werner Koch (Release Signing Key) rsa3072/4B092E28 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (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 BCEF7E294B092E28 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 aheinlein at gmx.com Wed Aug 9 20:07:10 2017 From: aheinlein at gmx.com (Andreas Heinlein) Date: Wed, 9 Aug 2017 20:07:10 +0200 Subject: System-wide gnupg.conf? Message-ID: <2aed2469-5157-92e6-01b7-8024f87de158@gmx.com> Hello, after reading today's announcement of GNuPG 2.1.23, I had the idea of having a system-wide /etc/gnupg.conf, to disable the new auto-key-retrieve etc. User's gnupg.conf should still be used and override the same options in the system-wide conf. Has something like this ever been discussed? Bye, Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: OpenPGP digital signature URL: From bernhard at intevation.de Thu Aug 10 08:44:19 2017 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 10 Aug 2017 08:44:19 +0200 Subject: it's a 2.2.0 release candidate (Re: [Announce] GnuPG 2.1.23 released) In-Reply-To: <877eycixl1.fsf@wheatstone.g10code.de> References: <877eycixl1.fsf@wheatstone.g10code.de> Message-ID: <201708100844.25854.bernhard@intevation.de> (sic!) > GnuPG: version 2.1.23. See below for a list of new features and bug > fixes. This a release candidate for 2.2.0. Congratulations GnuPG-Dev-Team! Bernhard ps.: With Intevation I'm consider myself part of the extended Dev-Team. -- 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 Thu Aug 10 11:01:59 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 10 Aug 2017 11:01:59 +0200 Subject: System-wide gnupg.conf? In-Reply-To: <2aed2469-5157-92e6-01b7-8024f87de158@gmx.com> (Andreas Heinlein's message of "Wed, 9 Aug 2017 20:07:10 +0200") References: <2aed2469-5157-92e6-01b7-8024f87de158@gmx.com> Message-ID: <87mv77hk3c.fsf@wheatstone.g10code.de> On Wed, 9 Aug 2017 20:07, aheinlein at gmx.com said: > after reading today's announcement of GNuPG 2.1.23, I had the idea of > having a system-wide /etc/gnupg.conf, to disable the new > auto-key-retrieve etc. User's gnupg.conf should still be used and > override the same options in the system-wide conf. What you can do is to use the applygnupgddefaults script to modify all user's conf files. However, it is easier to create a profile and apply its content: Create this file: --8<---------------cut here---------------start------------->8--- [gpg] no-auto-key-retrieve auto-key-locate local --8<---------------cut here---------------end--------------->8--- and use gpgconf --apply-profile THATFILE to update the current user's gpg.conf. Or use this one liner: printf "[gpg]\nno-auto-key-retrieve\nauto-key-locate local\n" \ | gpgconf --apply-profile 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: 227 bytes Desc: not available URL: From ineiev at gnu.org Thu Aug 10 10:25:33 2017 From: ineiev at gnu.org (Ineiev) Date: Thu, 10 Aug 2017 04:25:33 -0400 Subject: [Announce] GnuPG 2.1.23 released In-Reply-To: <877eycixl1.fsf@wheatstone.g10code.de> References: <877eycixl1.fsf@wheatstone.g10code.de> Message-ID: <20170810082533.GY14914@gnu.org> Hello, On Wed, Aug 09, 2017 at 05:12:58PM +0200, Werner Koch wrote: > Internationalization > ==================== > > This version of GnuPG has support for 26 languages with Chinese, Czech, > French, German, Japanese, Norwegian, Russian, and Ukrainian being almost > completely translated. We are now in string freeze for 2.2 and updated > translations are very welcome. I submitted a Russian update on 2017-08-05 to gnupg-i18n at gnupg.org, but it looks like it was ignored; did I do anything wrong? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Digital signature URL: From wk at gnupg.org Thu Aug 10 12:41:56 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 10 Aug 2017 12:41:56 +0200 Subject: [Announce] GnuPG 2.1.23 released In-Reply-To: <20170810082533.GY14914@gnu.org> (ineiev@gnu.org's message of "Thu, 10 Aug 2017 04:25:33 -0400") References: <877eycixl1.fsf@wheatstone.g10code.de> <20170810082533.GY14914@gnu.org> Message-ID: <87inhvhfgr.fsf@wheatstone.g10code.de> On Thu, 10 Aug 2017 10:25, ineiev at gnu.org said: > I submitted a Russian update on 2017-08-05 to gnupg-i18n at gnupg.org, > but it looks like it was ignored; did I do anything wrong? My fault sorry. I should really merge my translations@ and gnupg-i18n@ folders to have only one place to check. Pushed to master and will thus be part of 2.2.0. Thanks. 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: 227 bytes Desc: not available URL: From fgunbin at fastmail.fm Thu Aug 10 16:22:43 2017 From: fgunbin at fastmail.fm (Filipp Gunbin) Date: Thu, 10 Aug 2017 17:22:43 +0300 Subject: [Announce] GnuPG 2.1.23 released In-Reply-To: <877eycixl1.fsf@wheatstone.g10code.de> (Werner Koch's message of "Wed, 09 Aug 2017 17:12:58 +0200") References: <877eycixl1.fsf@wheatstone.g10code.de> Message-ID: Hi, thanks for the release! Compilation fails on macOS: .. checking build system type... x86_64-apple-darwin16.6.0 checking host system type... x86_64-apple-darwin16.6.0 .. .. gcc -I/usr/local/include -I/usr/local/include -I/usr/local/include -O3 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wformat -Wno-format-y2k -Wformat-security -W -Wno-sign-compare -Wno-missing-field-initializers -Wdeclaration-after-statement -Wlogical-op -Wvla -Wno-pointer-sign -Wpointer-arith -g -O2 -o t-stringhelp t-stringhelp.o libcommon.a -L/usr/local/lib -lgcrypt -lgpg-error -lassuan -L/usr/local/lib -lgpg-error -L/usr/local/lib -lgpg-error -L/usr/local/lib -lintl -liconv -lc -Wl,-framework -Wl,CoreFoundation -liconv ld: warning: ignoring file libcommon.a, file was built for archive which is not the architecture being linked (x86_64): libcommon.a Undefined symbols for architecture x86_64: "_compare_filenames", referenced from: _main in t-stringhelp.o "_compare_version_strings", referenced from: _test_compare_version_strings in t-stringhelp.o .. more similar errors.. Should I provide more info? Filipp From fgunbin at fastmail.fm Thu Aug 10 22:04:57 2017 From: fgunbin at fastmail.fm (Filipp Gunbin) Date: Thu, 10 Aug 2017 23:04:57 +0300 Subject: [Announce] GnuPG 2.1.23 released In-Reply-To: (Filipp Gunbin's message of "Thu, 10 Aug 2017 17:22:43 +0300") References: <877eycixl1.fsf@wheatstone.g10code.de> Message-ID: Sorry for this, these are my local problems with toolchain (binutils vs macOS command line tools). Filipp. On 10/08/2017 17:22 +0300, Filipp Gunbin wrote: > Compilation fails on macOS: > > .. > Undefined symbols for architecture x86_64: > "_compare_filenames", referenced from: > > Should I provide more info? From alex at nitrokey.com Fri Aug 11 18:51:29 2017 From: alex at nitrokey.com (Alexander Paetzelt | Nitrokey) Date: Fri, 11 Aug 2017 18:51:29 +0200 Subject: Cache Timeout not working correctly Message-ID: <03470b7e-56c7-476c-2258-17ce4092fbc9@nitrokey.com> Hello, I try to get the max-cache-ttl-ssh in the gpg-agent.conf working, but the cache is still saved until physically disconnecting the gnupg smartcard. I have a working ~/.gnupg/gpg-agent.conf with following content: default-cache-ttl 1 max-cache-ttl 1 default-cache-ttl-ssh 1 max-cache-ttl-ssh 1 enable-ssh-support I know that configuration file is loaded correctly as I can for example change the used pinentry program with 'pinentry-program /usr/bin/pinentry-qt' but the cache settings are still not used/changed. Furthermore I tried to disable the card after some time over ~/.gnupg/scdaemon.conf as a workaround with 'card-timeout 5', but no luck either. Do you have any idea what could produce this symptons? Is there some other service/program which is caching? This is gpg (GnuPG) 2.1.22. Kind regards Alex From daniele at grinta.net Sun Aug 13 04:15:31 2017 From: daniele at grinta.net (Daniele Nicolodi) Date: Sat, 12 Aug 2017 20:15:31 -0600 Subject: --export-options export-reset-subkey-passwd Message-ID: <6308661f-1769-3e76-84d4-b25168688cf6@grinta.net> Hello, I have a workflow were I use this option to reset the subkey passphrase during export to a remote system where the subkey is used for unattended signing. This option has been removed in GnuPG 2.1, and I haven't found a way to obtain the same result. Does anyone have any tip? Thanks! Cheers, Daniele From daniele at grinta.net Sun Aug 13 08:17:16 2017 From: daniele at grinta.net (Daniele Nicolodi) Date: Sun, 13 Aug 2017 00:17:16 -0600 Subject: --export-options export-reset-subkey-passwd In-Reply-To: <6308661f-1769-3e76-84d4-b25168688cf6@grinta.net> References: <6308661f-1769-3e76-84d4-b25168688cf6@grinta.net> Message-ID: On 12/08/17 20:15, Daniele Nicolodi wrote: > Hello, > > I have a workflow were I use this option to reset the subkey passphrase > during export to a remote system where the subkey is used for unattended > signing. This option has been removed in GnuPG 2.1, and I haven't found > a way to obtain the same result. Digging a bit more, it seems that the functionality got dropped because with GnuPG 2.x all key manipulations go through gpg-agent and it does not (yet?) support password reset on expert. Is there any plan to bring back this functionality? I'm willing to contribute code, but I would need guidance on the foreseen way to implement this. Cheers, Daniele From johanw at vulcan.xs4all.nl Sun Aug 13 16:37:00 2017 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Sun, 13 Aug 2017 16:37:00 +0200 Subject: SHA1 depreciation ?? In-Reply-To: <1b3f8b29-7838-a6ea-67bf-df9797060f03@cedaron.com> References: <1b3f8b29-7838-a6ea-67bf-df9797060f03@cedaron.com> Message-ID: <5990640C.7090909@vulcan.xs4all.nl> On 28-06-2017 19:35, Joshua Hudson wrote: > I found out it's really hard to make a key that doesn't say "Digest: ... SHA1" in its attributes. Probably because RFC-4880 states that "Implementations MUST implement DSA for signatures", and DSA used to be SHA1 ony. I'm not sure if SHA2 can already be used, and even less sure if implementations without SHA1 are comforming to the standard. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From peter at digitalbrains.com Sun Aug 13 18:08:44 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 13 Aug 2017 18:08:44 +0200 Subject: Cache Timeout not working correctly In-Reply-To: <03470b7e-56c7-476c-2258-17ce4092fbc9@nitrokey.com> References: <03470b7e-56c7-476c-2258-17ce4092fbc9@nitrokey.com> Message-ID: On 11/08/17 18:51, Alexander Paetzelt | Nitrokey wrote: > I try to get the max-cache-ttl-ssh in the gpg-agent.conf working, > but the cache is still saved until physically disconnecting the gnupg > smartcard. Unless this has been fixed already, this is probably because cache-ttl has simply never worked for smartcards. They stay unlocked indefinitely. > Furthermore I tried to disable the card after some time over > ~/.gnupg/scdaemon.conf as a workaround with 'card-timeout 5', but no > luck either. I would have expected that to work, but have never used the option myself. For GnuPG 2.1.18, the documentation comes with a caveat: > Note that with the current version of Scdaemon the card is powered > down immediately at the next timer tick for any value of n other than > 0. > Is there some other service/program which is caching? It's the card itself! It'll stay unlocked until told otherwise or powered down. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From aelmahmoudy at users.sourceforge.net Sun Aug 13 02:45:28 2017 From: aelmahmoudy at users.sourceforge.net (=?UTF-8?B?2KPYrdmF2K8g2KfZhNmF2K3ZhdmI2K/Zig==?=) Date: Sun, 13 Aug 2017 00:45:28 +0000 Subject: Edit key in batch mode Message-ID: <640D7AD9-016E-4BAB-A8B9-C06E603CEE4E@users.sourceforge.net> Hello, I have gnupg 1.4 installed on my system. I am trying to edit my key in batch mode using the following command: gpg --edit-key --command-fd 0 --status-fd=2 < scr the contents of 'scr' file is: ===== adduid ???? ???????? aelmahmoudy at users.sourceforge.net Ahmed El-Mahmoudy ===== so I get the following error: Invalid command (try "help") Can someone help ? -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From duane at nofroth.com Mon Aug 14 08:32:08 2017 From: duane at nofroth.com (Duane Whitty) Date: Mon, 14 Aug 2017 03:32:08 -0300 Subject: fingerprint of key Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Tested on: $ gpg --version gpg (GnuPG) 1.4.16 $ gpg2 --version gpg (GnuPG) 2.0.22 lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 14.04.5 LTS Release: 14.04 Codename: trusty I was recently trying to compare the fingerprint of a key I downloaded to its online stated value. I thought I should be able to accomplish my goal with "gpg --fingerprint public-key-file.asc". Gpg returned "gpg: error reading key: No public key" So I did a search and found --with-fingerprint. Worked as I hoped it would. According to gpg(1) and gpg2(1) - "--with-fingerprint Same as the command --fingerprint but changes only the format of the output and may be used together with another command." So is this a bug in gpg or a bug in the man page or am I missing something so trivial and obvious that I will smack myself in the forehead when someone points it out to me? I understand dev cycles are being focused primarily(?) on the 2.1 branch but I figured this might be worth mentioning. I confess, I haven't checked the archives to see if it already has been. Best Regards, Duane - -- Duane Whitty duane at nofroth.com -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZkUPfAAoJEOJfpr8UVxtkLy8H/3ffsaDpy1YWfZNjRBTu3vGZ H/QrXGa7Mo7I9yFTojhyI9u9GCPzPu3sl/ZbvwGXEVpMoME5VuU8Fz5Dl1DGd9GF E1qT6Kk2L+H/eZiQNc4LFXjn3TQXNCIjq/HFiw7Eh/31eUcBZ+6/kjd9pvRmtzEO S4SAVn36PId23pZln/qaLJIpgmqBdGKWZ9KtmguDu9mMr63SDfJXRrSxdTvkjEBT 8w/3C3bs1/i0qEUepGXAlIIsllSQ2OgUZB477JTk8YfH/LH5WHDLvm+tHcTZ5Jg7 uYstNr8dgQEWSmqvWrQXBCZp3qTSfI1xW7Nzug8DtNFZ1Np2uhVuo2Uqv5HIZcg= =t2JQ -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Mon Aug 14 17:14:45 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 14 Aug 2017 11:14:45 -0400 Subject: fingerprint of key In-Reply-To: References: Message-ID: <87shgukwpm.fsf@fifthhorseman.net> On Mon 2017-08-14 03:32:08 -0300, Duane Whitty wrote: > I was recently trying to compare the fingerprint of a key I downloaded > to its online stated value. I thought I should be able to accomplish > my goal with "gpg --fingerprint public-key-file.asc". Gpg returned > "gpg: error reading key: No public key" "gpg --fingerprint" displays the fingerprint of a key that is already in the user's keyring. you'll need to "gpg --import public-key-file.asc" first, and then ask for its fingerprint, especially with older versions of gnupg. If you really want to isolate the imported key, you can use an ephemeral GNUPGHOME directory, like so: export GNUPGHOME=$(mktemp -d) gpg --import < public-key-file.asc gpg --fingerprint rm -rf $GNUPGHOME with more modern versions of gnupg, you can just use: gpg --with-fingerprint --import-options show-only --import < public-key-file.asc hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From duane at nofroth.com Mon Aug 14 18:25:58 2017 From: duane at nofroth.com (Duane Whitty) Date: Mon, 14 Aug 2017 13:25:58 -0300 Subject: fingerprint of key In-Reply-To: <87shgukwpm.fsf@fifthhorseman.net> References: <87shgukwpm.fsf@fifthhorseman.net> Message-ID: <4d0c133b-746d-3172-6f34-7f88470e61eb@nofroth.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 17-08-14 12:14 PM, Daniel Kahn Gillmor wrote: > On Mon 2017-08-14 03:32:08 -0300, Duane Whitty wrote: >> I was recently trying to compare the fingerprint of a key I >> downloaded to its online stated value. I thought I should be >> able to accomplish my goal with "gpg --fingerprint >> public-key-file.asc". Gpg returned "gpg: error reading key: No >> public key" > > "gpg --fingerprint" displays the fingerprint of a key that is > already in the user's keyring. > > you'll need to "gpg --import public-key-file.asc" first, and then > ask for its fingerprint, especially with older versions of gnupg. > > If you really want to isolate the imported key, you can use an > ephemeral GNUPGHOME directory, like so: > > export GNUPGHOME=$(mktemp -d) gpg --import < public-key-file.asc > gpg --fingerprint rm -rf $GNUPGHOME > > with more modern versions of gnupg, you can just use: > > gpg --with-fingerprint --import-options show-only --import < > public-key-file.asc > > hth, > > --dkg > Hi Daniel, Thanks for your response. So, what you are saying is that the man page is wrong ;-) Best Regards, Duane - -- Duane Whitty duane at nofroth.com -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZkc8RAAoJEOJfpr8UVxtk+5MIAKEtESbPZG+CHDr6hh+dkRaf OhlOQyNw9HuZzAhOXKQZKXukiwDSinlOQ+cJn4JbYtYUVZtDCQz/mu/WAkgtdN5U WM4FrZYxciDdJrZKzD4i+sc6MujKo2UEeTz4MqDO1DhKaD94fJ3EqRakPzmD6t7Y 1F6mvWDquz0Camr41NTrrkB3v6ISt7b/TA3H5v/XJCfZ9Wv5GHNKxzFeftmBEcQY lw/9geYKRahIFKGdMHVA2eQQteW4uq8wMgJSDUEOuxv/WyztWxvNeiwzZtjhAYl2 3J1j3pvL9XV7Q/Y+u/sjE941ieVSr3nbm7xy/VW5GLyWxWP3/dgjsh0CEaqGTjM= =TLc2 -----END PGP SIGNATURE----- From tmz at pobox.com Mon Aug 14 21:09:22 2017 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 14 Aug 2017 15:09:22 -0400 Subject: fingerprint of key In-Reply-To: <87shgukwpm.fsf@fifthhorseman.net> References: <87shgukwpm.fsf@fifthhorseman.net> Message-ID: <20170814190922.GC3514@zaya.teonanacatl.net> Daniel Kahn Gillmor wrote: > with more modern versions of gnupg, you can just use: > > gpg --with-fingerprint --import-options show-only --import < public-key-file.asc FWIW, I've used "gpg --with-fingerprint public-key-file.asc" for what seems like years to do this sort of quick fingerprint check of keys. It's particularly handy with linux distribution package signing keys, which are typically not something I have any need to import to my keyring. On a fedora-25 system: $ gpg --version gpg (GnuPG) 1.4.22 $ gpg --with-fingerprint /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-primary pub 4096R/FDB19C98 2016-03-31 Fedora 25 Primary (25) Key fingerprint = C437 DCCD 558A 66A3 7D6F 4372 4089 D8F2 FDB1 9C98 $ gpg2 --version gpg (GnuPG) 2.1.13 $ gpg2 --with-fingerprint /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-primary pub rsa4096 2016-03-31 [SCE] C437 DCCD 558A 66A3 7D6F 4372 4089 D8F2 FDB1 9C98 uid Fedora 25 Primary (25) I haven't looked at the documentation for --with-fingerprint in a while, but it does seem like it's at least leaving out some details regarding its use on key files which are not imported. I have no idea whether those differences are intended and should simply be documented or it's considered a bug that --fingerprint and --with-fingerprint differ in handling unimported keys. Also, both 2.1.13 on fedora 25 and 2.1.22 on fedora rawhide, the command above complains about the show-only option: $ gpg2 --version gpg (GnuPG) 2.1.22 $ gpg2 --with-fingerprint --import-options show-only --import < /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-primary gpg: unknown option 'show-only' gpg: invalid import options Is there a typo in that command or is show-only not in the latest release of the 2.1 branch? -- Todd ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The most overlooked advantage to owning a computer is that if they foul up, there's no law against whacking them around a little. -- Eric Porterfield -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 543 bytes Desc: not available URL: From dkg at fifthhorseman.net Mon Aug 14 22:58:53 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 14 Aug 2017 16:58:53 -0400 Subject: fingerprint of key In-Reply-To: <4d0c133b-746d-3172-6f34-7f88470e61eb@nofroth.com> References: <87shgukwpm.fsf@fifthhorseman.net> <4d0c133b-746d-3172-6f34-7f88470e61eb@nofroth.com> Message-ID: <874lt9lvci.fsf@fifthhorseman.net> On Mon 2017-08-14 13:25:58 -0300, Duane Whitty wrote: > Thanks for your response. So, what you are saying is that the man > page is wrong ;-) I didn't think that was what i was saying, but there have certainly been bugs in the documentation in the past. Is there specific text that you think is wrong? do you have a suggestion about what it should be changed to? --dkg From dkg at fifthhorseman.net Mon Aug 14 23:05:38 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 14 Aug 2017 17:05:38 -0400 Subject: fingerprint of key In-Reply-To: <20170814190922.GC3514@zaya.teonanacatl.net> References: <87shgukwpm.fsf@fifthhorseman.net> <20170814190922.GC3514@zaya.teonanacatl.net> Message-ID: <87zib1kggt.fsf@fifthhorseman.net> On Mon 2017-08-14 15:09:22 -0400, Todd Zullinger wrote: > $ gpg --with-fingerprint /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-primary > pub 4096R/FDB19C98 2016-03-31 Fedora 25 Primary (25) > Key fingerprint = C437 DCCD 558A 66A3 7D6F 4372 4089 D8F2 FDB1 9C98 > > $ gpg2 --with-fingerprint /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-primary > pub rsa4096 2016-03-31 [SCE] > C437 DCCD 558A 66A3 7D6F 4372 4089 D8F2 FDB1 9C98 > uid Fedora 25 Primary (25) the trouble with these two invocations of gpg is that they offer no command. Each invocation of GnuPG is supposed to include exactly one command and zero or more options. As the gpg(1) manpage says: gpg [--homedir dir] [--options file] [options] command [args] --with-fingerprint is a GnuPG option, not a command. When you give gpg no command, you're basically saying "hey, gpg, do whatever you think is reasonable." more recent versions of gpg will complain: gpg: WARNING: no command supplied. Trying to guess what you mean ... Please see https://dev.gnupg.org/T2943 for more discussion of this situation and why it is problematic. > Also, both 2.1.13 on fedora 25 and 2.1.22 on fedora rawhide, the > command above complains about the show-only option: > > $ gpg2 --version > gpg (GnuPG) 2.1.22 > > $ gpg2 --with-fingerprint --import-options show-only --import < /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-primary > gpg: unknown option 'show-only' > gpg: invalid import options > > Is there a typo in that command or is show-only not in the latest > release of the 2.1 branch? the latest release of the 2.1 branch is 2.1.23. show-only was added in 2.1.23. --dkg From duane at nofroth.com Tue Aug 15 00:03:19 2017 From: duane at nofroth.com (Duane Whitty) Date: Mon, 14 Aug 2017 19:03:19 -0300 Subject: fingerprint of key In-Reply-To: <874lt9lvci.fsf@fifthhorseman.net> References: <87shgukwpm.fsf@fifthhorseman.net> <4d0c133b-746d-3172-6f34-7f88470e61eb@nofroth.com> <874lt9lvci.fsf@fifthhorseman.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 17-08-14 05:58 PM, Daniel Kahn Gillmor wrote: > On Mon 2017-08-14 13:25:58 -0300, Duane Whitty wrote: >> Thanks for your response. So, what you are saying is that the >> man page is wrong ;-) > > I didn't think that was what i was saying, but there have certainly > been bugs in the documentation in the past. Is there specific text > that you think is wrong? do you have a suggestion about what it > should be changed to? > > --dkg > The situation is a little more clear since your last response. If I may quote you: "the trouble with these two invocations of gpg is that they offer no command. Each invocation of GnuPG is supposed to include exactly one command and zero or more options. ..." I ran gpg2 --with-fingerprint oracle_vbox.asc which did what I wanted and I received no complaints. I did not and still do not want to import the oracle_vbox public key into my key ring. I am happy to download it and check it each time. When I looked at the man page for how to do this it looked like gpg2 - --fingerprint oracle_vbox.asc should do the job but as you have pointed out gpg expects a key in my keyring to perform that action on. After reading the man page several times for the 1.4 and 2.0 versions I can see nothing that would make me believe that I needed to provide the program with a key from my keyring. That's fine though, I'm still learning. Now that you point it out I can see that --with-fingerprint is an option under the section "Key related options" and so it makes sense that a command should be entered as well. I am not sure I understand why it would be bad to do the following, which implies not importing the key to a keyring: gpg --with-fingerprint --fingerprint < public-key-file.asc where I substituted --fingerprint for --import However if I do that it's the same as running: gpg2 --with-fingerprint --fingerprint and the oracle_vbox.asc file containing the key is completely ignored and there are no warnings that it was ignored. Before I go down the road on offering an opinion on how the man page should be "fixed" (maybe it's not really broken) can you explain why it would be bad to let gpg generate and display the fingerprint of a key in an ascii armoured file? By the way, I really appreciate the assistance you're giving me in helping me to understand this. I know your busy. Best Regards, Duane - -- Duane Whitty duane at nofroth.com -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZkh4hAAoJEOJfpr8UVxtkwj0H/0bPfVYbKMlbvLBsF+9pTFPW 9PwNRA47dARN8eBwtRr106br0iCLFxs31ObXyh80M+cGJFTIQN61y3FfD8GsEv9/ BS9xzjHv4q/sO+pF2yOy2ygmjoxouvbPIL86yobhJA+bKBw4piH9UxaPnQmO+SLC j450uLxl2C7ZWOcSI4bi0myHTnsZkvkbrPlYfo0zjbyJXIP+3DonRZhhVR2nzUwr DNX1K5TRy2Dw4NN430o0q9Bcef05XywExJFpCaxFWDOJdTgwVOkrfodDoaXKotjx M+nqD9sduQHXiCeXR1cN7aZ9rYCJ301xeFAiRJTOHl/sTUpoEdP2sj5i3Fog+pQ= =mBYf -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Tue Aug 15 01:50:04 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 14 Aug 2017 19:50:04 -0400 Subject: fingerprint of key In-Reply-To: References: <87shgukwpm.fsf@fifthhorseman.net> <4d0c133b-746d-3172-6f34-7f88470e61eb@nofroth.com> <874lt9lvci.fsf@fifthhorseman.net> Message-ID: <87h8x9k8ur.fsf@fifthhorseman.net> On Mon 2017-08-14 19:03:19 -0300, Duane Whitty wrote: > I did not and still do not want to import the oracle_vbox public key > into my key ring. I am happy to download it and check it each time. I think this is an interesting choice, but i don't understand why you've made it. Can you say more about why you don't want to import the key, and why you prefer to fetch it each time? > Before I go down the road on offering an opinion on how the man page > should be "fixed" (maybe it's not really broken) can you explain why > it would be bad to let gpg generate and display the fingerprint of a > key in an ascii armoured file? I'm not saying it's "bad" -- it's just not what --fingerprint does. --fingerprint List all keys (or the specified ones) along with their finger? prints. This is the same output as --list-keys but with the additional output of a line with the fingerprint. May also be combined with --list-signatures or --check-signatures. If this command is given twice, the fingerprints of all secondary keys are listed too. This command also forces pretty printing of fingerprints if the keyid format has been set to "none". So it's like --list-keys, which says: --list-keys -k --list-public-keys List the specified keys. If no keys are specified, then all keys from the configured public keyrings are listed. in other words (or maybe it's not as explicitly stated as it should be), "list all the keys in your keyring that match the specification". This command is not intended for listing fingerprints of keys that come in on stdin, or of an external file. That said, you could combine it with: --no-default-keyring --keyring /path/to/file.gpg (as long as the file wasn't ascii-armored, and as long as you weren't concerned about updating your trustdb by accident, etc). Again, i'm not saying this is particularly user-friendly, i'm just trying to help you understand the current state of the tool. If you have specific suggestions for how to improve the tool, please suggest them! --dkg From duane at nofroth.com Tue Aug 15 02:50:13 2017 From: duane at nofroth.com (Duane Whitty) Date: Mon, 14 Aug 2017 21:50:13 -0300 Subject: fingerprint of key In-Reply-To: <87h8x9k8ur.fsf@fifthhorseman.net> References: <87shgukwpm.fsf@fifthhorseman.net> <4d0c133b-746d-3172-6f34-7f88470e61eb@nofroth.com> <874lt9lvci.fsf@fifthhorseman.net> <87h8x9k8ur.fsf@fifthhorseman.net> Message-ID: <1d0acd15-6cb3-49e2-6f1d-c8813c8d6936@nofroth.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 17-08-14 08:50 PM, Daniel Kahn Gillmor wrote: > On Mon 2017-08-14 19:03:19 -0300, Duane Whitty wrote: >> I did not and still do not want to import the oracle_vbox public >> key into my key ring. I am happy to download it and check it >> each time. > > I think this is an interesting choice, but i don't understand why > you've made it. Can you say more about why you don't want to > import the key, and why you prefer to fetch it each time? I perceive keys in my keyring as being ones I trust because of out-of-band confirmation and used for two-way communications. I think the VirtualBox key is just to give people assurance that they are downloading what they intended to download from the source they expected, in this case via apt or apt-get, etc. from an Oracle repo. > >> Before I go down the road on offering an opinion on how the man >> page should be "fixed" (maybe it's not really broken) can you >> explain why it would be bad to let gpg generate and display the >> fingerprint of a key in an ascii armoured file? > > I'm not saying it's "bad" -- it's just not what --fingerprint > does. > > --fingerprint List all keys (or the specified ones) along with > their finger? prints. This is the same output as --list-keys > but with the additional output of a line with the fingerprint. May > also be combined with --list-signatures or --check-signatures. > If this command is given twice, the fingerprints of all secondary > keys are listed too. This command also forces pretty printing > of fingerprints if the keyid format has been set to "none". > > So it's like --list-keys, which says: > > --list-keys -k --list-public-keys List the specified keys. If no > keys are specified, then all keys from the configured public > keyrings are listed. > > > in other words (or maybe it's not as explicitly stated as it should > be), "list all the keys in your keyring that match the > specification". This command is not intended for listing > fingerprints of keys that come in on stdin, or of an external > file. > To me that reads as "if you provide a key then the fingerprint for that key will be provided otherwise your keyring will be used". Thanks for correcting my understanding. > That said, you could combine it with: > > --no-default-keyring --keyring /path/to/file.gpg > > (as long as the file wasn't ascii-armored, and as long as you > weren't concerned about updating your trustdb by accident, etc). >> Again, i'm not saying this is particularly user-friendly, i'm >> just > trying to help you understand the current state of the tool. > > If you have specific suggestions for how to improve the tool, > please suggest them! >> --dkg > I'm not exactly sure what a good suggestion would be. Would it be correct to say that going forward usability changes would probably be more likely to happen in the 2.1 branch? If so I guess I should upgrade to the 2.1 branch. I can say that what I usually end up being challenged by is importing keys into my keyring and on being able to choose which UID I want to sign with. Maybe that just means I don't know the software well enough. For instance, last night I wanted to add a friend's new public key to my keyring. Gpg wouldn't add the key based on his email. I had to use his email to search the key server and then use the fingerprint of his new key to add it to my keyring. The approach I took was "gpg2 --search user at domain.com" and "gpg2 - --recv-keys key-fingerprint". Then I did a "gpg2 --edit-key key-fingerprint" to sign the key with my default UID. I thought I would get a menu to select options from when I used --edit-key but instead I was presented with the prompt "gpg>" and I had to type the sign command. It worked but I might have chosen to sign the key with a key from a different UID. Not sure if my method of importing to my keyring and signing the new public key was the usual or easiest method but it worked. Not sure there's actually a suggestion for improvement in there :-) but you've given me a lot to consider and digest. Sincerely, thanks! I love learning this stuff. Best Regards, Duane - -- Duane Whitty duane at nofroth.com -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZkkVBAAoJEOJfpr8UVxtkBDsH/0zoAMEuKvkkIzVC1r6v8kq9 Tmbqvd7i4Q8YobiExGilUXSx/s0psq4JKo1qcbvpuXnsRhJM+3/tH6TTgvdLJJOq Em8NN7HygzJ3Fhb7RaGZS9dBv2FQFem3qk+oFHzUMUlUGF1gF+agpeFM/CwKGsMk ClmBW9pSqQzH2z+hWXQPdAA8k8X2Wi3KH5BlrBT3kEKw+XdUJOqme8YPqWlo97XQ /BKmpPjiBiEE7qWkOXKTdD9ySIx/XO6fmcxvJEbvqygdjh/zp/Cm5jW2MrPoQC5N jWR18G8cRa5euNfXrzvyGm5o3SZTvoOEX3VHXPvQU8tyYVOV3sQVyM2hUWpyTfg= =ZuO1 -----END PGP SIGNATURE----- From duane at nofroth.com Tue Aug 15 03:12:18 2017 From: duane at nofroth.com (Duane Whitty) Date: Mon, 14 Aug 2017 22:12:18 -0300 Subject: fingerprint of key In-Reply-To: <1d0acd15-6cb3-49e2-6f1d-c8813c8d6936@nofroth.com> References: <87shgukwpm.fsf@fifthhorseman.net> <4d0c133b-746d-3172-6f34-7f88470e61eb@nofroth.com> <874lt9lvci.fsf@fifthhorseman.net> <87h8x9k8ur.fsf@fifthhorseman.net> <1d0acd15-6cb3-49e2-6f1d-c8813c8d6936@nofroth.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 17-08-14 09:50 PM, Duane Whitty wrote: > > > On 17-08-14 08:50 PM, Daniel Kahn Gillmor wrote: >> On Mon 2017-08-14 19:03:19 -0300, Duane Whitty wrote: >>> I did not and still do not want to import the oracle_vbox >>> public key into my key ring. I am happy to download it and >>> check it each time. > >> I think this is an interesting choice, but i don't understand >> why you've made it. Can you say more about why you don't want >> to import the key, and why you prefer to fetch it each time? > I perceive keys in my keyring as being ones I trust because of > out-of-band confirmation and used for two-way communications. I > think the VirtualBox key is just to give people assurance that they > are downloading what they intended to download from the source > they expected, in this case via apt or apt-get, etc. from an Oracle > repo. > > >>> Before I go down the road on offering an opinion on how the >>> man page should be "fixed" (maybe it's not really broken) can >>> you explain why it would be bad to let gpg generate and display >>> the fingerprint of a key in an ascii armoured file? > >> I'm not saying it's "bad" -- it's just not what --fingerprint >> does. > >> --fingerprint List all keys (or the specified ones) along with >> their finger? prints. This is the same output as >> --list-keys but with the additional output of a line with the >> fingerprint. May also be combined with --list-signatures or >> --check-signatures. If this command is given twice, the >> fingerprints of all secondary keys are listed too. This >> command also forces pretty printing of fingerprints if the keyid >> format has been set to "none". > >> So it's like --list-keys, which says: > >> --list-keys -k --list-public-keys List the specified keys. If >> no keys are specified, then all keys from the configured >> public keyrings are listed. > > >> in other words (or maybe it's not as explicitly stated as it >> should be), "list all the keys in your keyring that match the >> specification". This command is not intended for listing >> fingerprints of keys that come in on stdin, or of an external >> file. > > To me that reads as "if you provide a key then the fingerprint for > that key will be provided otherwise your keyring will be used". > Thanks for correcting my understanding. >> That said, you could combine it with: > >> --no-default-keyring --keyring /path/to/file.gpg > >> (as long as the file wasn't ascii-armored, and as long as you >> weren't concerned about updating your trustdb by accident, etc). >>> Again, i'm not saying this is particularly user-friendly, i'm >>> just >> trying to help you understand the current state of the tool. > >> If you have specific suggestions for how to improve the tool, >> please suggest them! >>> --dkg > > > I'm not exactly sure what a good suggestion would be. Would it be > correct to say that going forward usability changes would probably > be more likely to happen in the 2.1 branch? If so I guess I > should upgrade to the 2.1 branch. > > I can say that what I usually end up being challenged by is > importing keys into my keyring and on being able to choose which > UID I want to sign with. Maybe that just means I don't know the > software well enough. > > For instance, last night I wanted to add a friend's new public key > to my keyring. Gpg wouldn't add the key based on his email. I had > to use his email to search the key server and then use the > fingerprint of his new key to add it to my keyring. > > The approach I took was "gpg2 --search user at domain.com" and "gpg2 > --recv-keys key-fingerprint". Then I did a "gpg2 --edit-key > key-fingerprint" to sign the key with my default UID. I thought I > would get a menu to select options from when I used --edit-key but > instead I was presented with the prompt "gpg>" and I had to type > the sign command. It worked but I might have chosen to sign the > key with a key from a different UID. Not sure if my method of > importing to my keyring and signing the new public key was the > usual or easiest method but it worked. > > Not sure there's actually a suggestion for improvement in there > :-) but you've given me a lot to consider and digest. Sincerely, > thanks! I love learning this stuff. > > > Best Regards, Duane > > Actually one suggestion, the way options and commands are specified look the same. It might make things clearer if there was a difference in the way they are expressed on the command line. Perhaps keep the "--" for options and enter commands without the "--". Best Regards, Duane - -- Duane Whitty duane at nofroth.com -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZkkpvAAoJEOJfpr8UVxtkpsIH/2qGLUDNqwNMvkN+ItQw4/YZ KBhnNxomzScrGzJXN9xZ1xH5Ha0FIGZgMzYxiAA/uWU4mgkurCDpESirTxffaTBp ahuSx6EYFre4JJdYzD/3zdVMws/fSacFZ18+ODbrfo40T1VSExHcO2yVGH5SDZg+ zxvPg0jM0QrFw276eSj3uwyn9nwBKXpGAtYcW/oE7plmDvimqob0AbuNQ7AvHwKS +Uw4+JkMRTULd6WaUCFGOswTXXMogwpYCFxfI4m8XcVk9Fwd9/JS5ShJEjjyg+fJ ewuL1LcrtWa0ZTdbiAVu5S1kIOd98DcIvLud5rJ8jWHIPOOW5CsdFE9VHgsMf/k= =aT8M -----END PGP SIGNATURE----- From info at bereshka.net Wed Aug 16 23:22:06 2017 From: info at bereshka.net (Bereshka Web and Photo) Date: Wed, 16 Aug 2017 16:22:06 -0500 Subject: help with gnupg Message-ID: <49D306CD-A607-4A18-873A-275A967C6990@bereshka.net> Hello, Dear Creators :) I will very appreciate if you can help me, because I was surfing a lot in the internet looking for an answer, and read tones of forums, but did not find solution. So I installed gnupg 2 , command gpg didn?t work in Terminal. I was confused and decided to try Gnupg tools suite, I installed that and created my keys and passphrase. Later I knew that I should type gpg2 in Terminal to work with that. So I got encrypted message and I tried to decrypt it, but it just didn?t show a result, it said that by whom it was encrypted and to whom, that?s all. We decided that it might be a problem because go GPG tools suite, maybe it causes conflict. So I decided to deinstall GPG Tools. Before to do that I exported my public, private, rev certificate, then I deinstalled this software. I located all keys to a folder ?keys? at my user root folder). Then I imported all keys through terminal. To check I do ?list-keys and I see my imported key and my husband?s key that was imported as well. 1. The problem is that I can encrypt message and send it to him and that he can decrypt it. But when I get encrypted message from him I can?t decrypt it. It does?t ask my passphrase. It asked when I had GPG Tools, but even with asked passpharase with GPG Tools being installed i didn?t get a decrypted message Now I don?t have GPG Tools and when I do command gpg2 Enter and insert his message I get this gpg: public key decryption failed: No pinentry gpg: decryption failed: No secret key 2. Then, I decided that if there is so much mess with this email, I will create keys with other one (ytsan86 at mail.ru) , but I still get same error on the step of creation gpg: public key decryption failed: No pinentry gpg: decryption failed: No secret key 3. Also I found on one forum that file gpg-agent.conf should be edited with adding this line - pinentry-program /bereshka/bin/pinentry-qt but it didn?t help Below I pasted a piece of the process from my terminal. Last login: Tue Aug 15 20:37:38 on ttys000 Air-Anastasia:~ bereshka$ gpg2 gpg: WARNING: no command supplied. Trying to guess what you mean ... gpg: Go ahead and type your message ... -----BEGIN PGP MESSAGE----- hQIMAyhHtjLbTCzXARAAhWskbltRKFWbWrPGLBueMds2exvzIRYA5lFHSKBx1sN/ tPDdBlqUdVTip9PxQJ6dImuHxQFJnakxHdXftW13lZ+ceGglSbzyaOUmojhHg9lu vUmqzRnx5BbF1TSK8vaY4/Y0KbT9CPNRUveOMz+JvUieEqMX4VTEoSq37e7RbVo2 3VWKQD+zzFfWjVWp5A+qFxOkoP4COjxJiaHFpuGPoaKMRFQ0BWKdcALE0ycsNVbx yq+hy/qEGxn8LqtHnV5ucqhPodwR9ubpmvjbR5ffR1GasqYwDiGmeDezNZM0+k0L Wxbvq41CTLwIwNBFp2YcSbnsuDvKgzUMXUBNLE+L9cGoKOX0Eo/gX6KwVdHWzVJj rxkA44qGuw5wiR3OGGEHcqE5TvQyp14lEItpF6NC1rn2ADGt5f5CHNHaenIFIRHW rc74KcTssy5teyLvSwgAREpEiI6Yq06c3VGf80wu2vlZgvwtMIf2f3vhUNpvrQNm l/uLYR/LoznY+6BDvgRXLkVZkNUkGh6dOMSFc3LAg7K5HiMbdLbXXVwq7VigmcsO YBpBWtJvXUo5eOqu/AOoPryFhF6dE/TurNt8TEG8l3U5A+yyCEDb/oM0T5bbLopO ZksjQuOinUjvmlyDHVQ1Cfs+y3wiSc+InBHniRvsRxCRNH8kA2oRyzOTG2L8cMLS wQgB1sguX+Ip4pJTJA/pQXFWJgRxnwKqWUg08mgNKUJfsijPfYNcoFEnDJZTJf97 2XYIDhfBk3GqjY12k999NeL38IEkvtUUtfoT8vThptipKPUvKvdOk0ucK9pySN7N g9N753S/RqyGQEEfKV8xf9OKPEVnZUBugleyFMWtrcijwuWeSdTLqRlrve8k6dG9 EWfITDgOFKsHfm4tQ57gyfzqMkr9nt7Vop2PVduxiMuqK4qFZaFi8xxSfprcHHOxrYNaeO1XVw9Zxh13HS7vzF6xowPtFvUnCUPU V0nsbzJL6lK8pJH28rKjUmAplV5aPz49DlzWERfz/gFA4b8q3XSVFnaSTLU5Rmxt nZXuBDRqKWYOvNM2eM4qCR4/6Jr3fD41O/G2/gnUmm/Y0JOPa/S5k1eQzwvwMrbO w+TQ27PzsKZaUnMBXU83WM0JnyasZ/O2SSEeva/8Ta8xW4NQCHZ9PVeGP+mPKogx cpQUHAGXhWXZz6x7DF7k70j7xLRO5+KKNCKhuz1wCIcrBkLOLaF+0nSYnwcEVs1n TWYm6k0wqQznsf/WUJqE+7wrR4/9Nbp2oCA= =NaOa -----END PGP MESSAGE-----gpg: encrypted with 4096-bit RSA key, ID 2847B632DB4C2CD7, created 2017-08-13 "Anastasiia Gudkov " gpg: public key decryption failed: No pinentry gpg: decryption failed: No secret key ^C gpg: signal Interrupt caught ... exiting Air-Anastasia:~ bereshka$ gpg2 --list-keys /Users/bereshka/.gnupg/pubring.kbx ---------------------------------- pub rsa4096 2017-08-13 [SC] [expires: 2021-08-13] 047CFFA533E12F033800905EBC1DD3D3F8529607 uid [ unknown] Anastasiia Gudkov sub rsa4096 2017-08-13 [E] [expires: 2021-08-13] pub rsa2048 2017-08-03 [SC] [expires: 2022-08-03] E54B5F8534F9AABAE00CD4F1934B6797FB417E72 uid [ unknown] Dmitry Gudkov sub rsa2048 2017-08-03 [E] [expires: 2022-08-03] Air-Anastasia:~ bereshka$ gpg2 --gen-key gpg (GnuPG) 2.1.22; Copyright (C) 2017 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Note: Use "gpg --full-generate-key" for a full featured key generation dialog. GnuPG needs to construct a user ID to identify your key. Real name: Anastasia Gudkov Email address: ytsan86 at mail.ru You selected this USER-ID: "Anastasia Gudkov " Change (N)ame, (E)mail, or (O)kay/(Q)uit? o We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. gpg: agent_genkey failed: No pinentry Key generation failed: No pinentry Air-Anastasia:~ bereshka$ Best regards, Anastasiia Gudkov -------------- next part -------------- An HTML attachment was scrubbed... URL: From marioxcc.MT at yandex.com Thu Aug 17 04:48:14 2017 From: marioxcc.MT at yandex.com (=?UTF-8?Q?Mario_Castel=c3=a1n_Castro?=) Date: Wed, 16 Aug 2017 21:48:14 -0500 Subject: Is it possible to certify (sign) a key using a subkey? Message-ID: Suppose I would like to sign another user's key using one of my secp256k1 subkeys, instead of my primary key, because it generates smaller signatures. gpg does not appear to support this. If I try to generate a subkey with certify capability ?gpg --expert --edit-key ...? and then ?addkey?, the option to toggle capability is not shown. Also, if I try to force gpg to use an *existing* subkey for signing another key with ?gpg -u FINGERPRINT1! --sign-key ANOTER_KEY? (where FINGERPRINT1 is the fingerprint of the subkey, and it is followed by ?!? to try to force use of this subkey) it still uses my primary key. Why is this behavior? I took a glance at RFC4880 and I could not find a requirement that only primary keys are used for certifying, although it is very possible that I just missed it. Regards. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Thu Aug 17 06:17:33 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 17 Aug 2017 00:17:33 -0400 Subject: Is it possible to certify (sign) a key using a subkey? In-Reply-To: References: Message-ID: <03e883df-30d7-d7ae-130c-c2b1b411c403@sixdemonbag.org> > Why is this behavior? I took a glance at RFC4880 and I could not find a > requirement that only primary keys are used for certifying, although it > is very possible that I just missed it. Does the subkey have the certify capability on it? If the subkey isn't marked for certifying, it can't be used to certify. From shtrom at ssji.net Wed Aug 16 13:56:09 2017 From: shtrom at ssji.net (Olivier Mehani) Date: Wed, 16 Aug 2017 21:56:09 +1000 Subject: I wrote a pinentry dispatcher; is it a sane thing to do/use? Message-ID: <20170816115609.cllxjan6e6hsr3ig@cancey.fritz.box> Hi list, # Context I connect to an OS X machine either locally or via SSH. When local, I use pinentry-mac and forward my SSH agent to gpg-agent. When remote, I use $SSH_AUTH_SOCK from the forwarded connection (I'm also trying to forward the gpg-agent socket, but it doesn't work reliably due to leftover sockets, so let's ignore that for now). # Problem I can't interact with pinentry-mac when connecting over SSH, so I'd like to fallback to pinentry(-curses). Potential solution: I just banged out this script, which I am thinking about using as `pinentry-program /PATH/TO/HOME/bin/pinentry-dispatch` #!/bin/sh -x UNAME="$(uname)" GPG_SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)" PINENTRY=/usr/bin/pinentry PINENTRY_BREW=/usr/local/bin/pinentry PINENTRY_MAC=/usr/local/bin/pinentry-mac case "${UNAME}" in "Darwin") case "${SSH_AUTH_SOCK}" in "${GPG_SSH_AUTH_SOCK}") exec "${PINENTRY_MAC}" ;; *) exec "${PINENTRY_BREW}" ;; esac ;; *) exec "${PINENTRY}" ;; esac This way, I could just `gpg-connect-agent 'killagent' /bye` from my SSH session, and next time the agent spawns, it would fallback to the non-mac pinentry. # Question Is it sane? My money is on ?not very?, but I'd like a more educated discussion. One of the issues I can see is that the script is in my HOME, which could be more easily compromised than the rest of the system, and the script trivially replaced by something that captures the data (but then again, my gpg-agent.conf could also be overwritten). Can you see any other issue with (or the idea of using such a dispatcher to start with)? (Please CC me on replies, as I only sporadically check the list through GMane.) -- Olivier Mehani PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655 Confidentiality cannot be guaranteed on emails sent or received unencrypted. From marioxcc.MT at yandex.com Thu Aug 17 14:42:06 2017 From: marioxcc.MT at yandex.com (=?UTF-8?Q?Mario_Castel=c3=a1n_Castro?=) Date: Thu, 17 Aug 2017 07:42:06 -0500 Subject: Is it possible to certify (sign) a key using a subkey? In-Reply-To: <03e883df-30d7-d7ae-130c-c2b1b411c403@sixdemonbag.org> References: <03e883df-30d7-d7ae-130c-c2b1b411c403@sixdemonbag.org> Message-ID: No, it does not have the certify capability. How can I enable this capability? If I add a subkey with ?--expert --edit-key? no option is given to enable certify capability (as mentioned in my previous message), only sign and authenticate in the case of ECC keys and sign, authenticate and encrypt in the case of RSA keys. This is version 2.1.18 of GNU PG as shipped by Debian 9. Regards. On 16/08/17 23:17, Robert J. Hansen wrote: > [[elided]] > > Does the subkey have the certify capability on it? If the subkey isn't > marked for certifying, it can't be used to certify. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From dirkx at webweaving.org Thu Aug 17 15:39:28 2017 From: dirkx at webweaving.org (Dirk-Willem van Gulik) Date: Thu, 17 Aug 2017 15:39:28 +0200 Subject: export secret subkeys Message-ID: <0B5E779D-A039-4110-B1D9-754902F7F563@webweaving.org> I am trying to understand the man page with regards to secret subkey exports. --export-secret-subkeys Same as --export, but exports the secret keys instead. The exported keys are written to STDOUT or to the file given with option --output. This command is often used along with the option --armor to allow easy printing of the key for paper backup; however the external tool paperkey does a better job for creating backups on paper. Note that exporting a secret key can be a security risk if the exported keys are send over an insecure channel. .. This had me believe that export-secret-subkeys would just export a subkey. Instead the output of --list-packets (and the file size) suggests that both the master and the subkey are exported. Output below - followed by a script to reproduce. Or am I misreading this ? With kind regards, Dw. # off=0 ctb=95 tag=5 hlen=3 plen=533 :secret key packet: version 4, algo 1, created 1502976628, expires 0 pkey[0]: [4096 bits] pkey[1]: [17 bits] gnu-dummy S2K, algo: 0, simple checksum, hash: 0 protect IV: keyid: 774BFCB80257A25B # off=536 ctb=b4 tag=13 hlen=2 plen=30 :user ID packet: "Tess von Testy " # off=568 ctb=89 tag=2 hlen=3 plen=595 :signature packet: algo 1, keyid 774BFCB80257A25B version 4, created 1502976628, md5len 0, sigclass 0x13 digest algo 10, begin of digest f6 39 hashed subpkt 33 len 21 (issuer fpr v4 C1CC37B73A5DA5263699A091774BFCB80257A25B) hashed subpkt 2 len 4 (sig created 2017-08-17) hashed subpkt 27 len 1 (key flags: 03) hashed subpkt 9 len 4 (key expires after 1y0d0h0m) hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 3) hashed subpkt 21 len 4 (pref-hash-algos: 10 9 8 11) hashed subpkt 22 len 3 (pref-zip-algos: 2 1 0) hashed subpkt 30 len 1 (features: 01) hashed subpkt 23 len 1 (keyserver preferences: 80) subpkt 16 len 8 (issuer key ID 774BFCB80257A25B) data: [4095 bits] # off=1166 ctb=9d tag=7 hlen=3 plen=1862 :secret sub key packet: version 4, algo 1, created 1502976632, expires 0 pkey[0]: [4096 bits] pkey[1]: [17 bits] iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: 1B6594BA5204BCCC protect count: 16777216 (224) protect IV: a0 16 38 e5 6b a0 3c f0 16 f9 a4 17 c6 ba 14 a6 skey[2]: [v4 protected] keyid: 11A28C9369E55B8C # off=3031 ctb=89 tag=2 hlen=3 plen=572 :signature packet: algo 1, keyid 774BFCB80257A25B version 4, created 1502976632, md5len 0, sigclass 0x18 digest algo 10, begin of digest 46 b0 hashed subpkt 33 len 21 (issuer fpr v4 C1CC37B73A5DA5263699A091774BFCB80257A25B) hashed subpkt 2 len 4 (sig created 2017-08-17) hashed subpkt 27 len 1 (key flags: 0C) hashed subpkt 9 len 4 (key expires after 120d0h0m) subpkt 16 len 8 (issuer key ID 774BFCB80257A25B) data: [4094 bits] #/bin/sh set -e set -x TMPDIR=${TMPDIR:-/tmp} VOLNAME=${VOLNAME:-gnupg.tmp.$$} TMPSTORE=${TMPDIR}/${VOLNAME} GNUPGHOME=/Volumes/${VOLNAME} FIRST="Tess" LAST="von Testy" MOI="${FIRST} ${LAST} " PASSWD=12345678 NEWPIN=123456 RESET=12345678 NEWMASTER=12345678 OLDMASTER=12345678 PGP=/usr/local/bin/gpg2 SM=/usr/local/bin/gpgsm PRESET=/usr/local/libexec/gpg-preset-passphrase SIZE=5M export RANDFILE=~/.openssl.rand.state export DAYS=365 export SUBDAYS=120 killall scdaemon gpg-agent || echo Already dead killall scdaemon gpg-agent || echo Already dead if test -f /usr/bin/hdiutil; then openssl rand -base64 128 |\ /usr/bin/hdiutil hdiutil create -attach -stdinpass -quiet \ -encryption -size $SIZE -fs HFS+ \ -volname ${VOLNAME} ${TMPSTORE} rm -f ${TMPSTORE}.dmg ME} else crypted_luks 5M GNUPGHOME=${TMPSTORE} mkdir -p ${GNUPGHOME} chmod 700 ${GNUPGHOME} fi ( set -e export GNUPGHOME cd $GNUPGHOME cat > ${GNUPGHOME}/gpg.conf < ${GNUPGHOME}/gpg-agent.conf < ${GNUPGHOME}/scdaemon.conf < sub-enc.sec cat sub-enc.sec | gpg --list-packets #.. snip other unit tests ) From dgouttegattat at incenp.org Thu Aug 17 16:05:57 2017 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Thu, 17 Aug 2017 16:05:57 +0200 Subject: export secret subkeys In-Reply-To: <0B5E779D-A039-4110-B1D9-754902F7F563@webweaving.org> References: <0B5E779D-A039-4110-B1D9-754902F7F563@webweaving.org> Message-ID: <85cd281e-e8d8-de62-e76c-01af8e0ed696@incenp.org> On 08/17/2017 03:39 PM, Dirk-Willem van Gulik wrote: > This had me believe that export-secret-subkeys would just export a > subkey. > > Instead the output of --list-packets (and the file size) suggests > that both the master and the subkey are exported. Seemingly, yes. But actually, when using --export-secret-subkeys, the master private key is not really exported. The command does produce a "secret key packet" corresponding to the master key, but this packet does not actually contain the private key material. Look for the "gnu-dummy S2K" line in the details of the secret key packet: > :secret key packet: > version 4, algo 1, created 1502976628, expires 0 > pkey[0]: [4096 bits] > pkey[1]: [17 bits] > gnu-dummy S2K, algo: 0, simple checksum, hash: 0 It's the clue indicating that this packet is actually unusable. And that's what the man page means when it says: "The second form of the command has the special property to render the secret part of the primary key useless." The purpose of this command is to create a situation where only the private subkeys are available on the machine, while the master private key is stored offline. 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 peter at digitalbrains.com Thu Aug 17 16:06:39 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 17 Aug 2017 16:06:39 +0200 Subject: export secret subkeys In-Reply-To: <0B5E779D-A039-4110-B1D9-754902F7F563@webweaving.org> References: <0B5E779D-A039-4110-B1D9-754902F7F563@webweaving.org> Message-ID: <3798c722-cf08-c533-7694-641d4abfba31@digitalbrains.com> On 17/08/17 15:39, Dirk-Willem van Gulik wrote: > # off=0 ctb=95 tag=5 hlen=3 plen=533 > :secret key packet: > version 4, algo 1, created 1502976628, expires 0 > pkey[0]: [4096 bits] > pkey[1]: [17 bits] > gnu-dummy S2K, algo: 0, simple checksum, hash: 0 > protect IV: > keyid: 774BFCB80257A25B Note "gnu-dummy S2K". This is an empty placeholder for the key material. An OpenPGP secret key always contains the primary key, but this is GnuPG's method to get away with not actually including the primary key nonetheless. "S2K" means "String to Key", and an S2K is a method that derives a cryptographic key from a passphrase. The cryptographic key is subsequently used to encrypt the secret key material (well, apart from the fact that this is a dummy that doesn't actually do that). And an OpenPGP secret key always contains the public key as well, which /is/ included, in pkey[0] and pkey[1] (pkey -> public key). > :secret sub key packet: > version 4, algo 1, created 1502976632, expires 0 > pkey[0]: [4096 bits] > pkey[1]: [17 bits] > iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: 1B6594BA5204BCCC > protect count: 16777216 (224) > protect IV: a0 16 38 e5 6b a0 3c f0 16 f9 a4 17 c6 ba 14 a6 > skey[2]: [v4 protected] > keyid: 11A28C9369E55B8C And this is actually secret key material. First the public key again, then the secret key in skey[2] (skey -> secret key). It is protected by the "iter+salt" S2K. This packet will be significantly larger than the earlier packet. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From dirkx at webweaving.org Thu Aug 17 16:17:42 2017 From: dirkx at webweaving.org (Dirk-Willem van Gulik) Date: Thu, 17 Aug 2017 16:17:42 +0200 Subject: export secret subkeys In-Reply-To: <3798c722-cf08-c533-7694-641d4abfba31@digitalbrains.com> References: <0B5E779D-A039-4110-B1D9-754902F7F563@webweaving.org> <3798c722-cf08-c533-7694-641d4abfba31@digitalbrains.com> Message-ID: <9D15C4CA-F3CB-4156-A0D1-40BE82BB11FE@webweaving.org> > On 17 Aug 2017, at 16:06, Peter Lebbing wrote: > > On 17/08/17 15:39, Dirk-Willem van Gulik wrote: >> # off=0 ctb=95 tag=5 hlen=3 plen=533 >> :secret key packet: >> version 4, algo 1, created 1502976628, expires 0 >> pkey[0]: [4096 bits] >> pkey[1]: [17 bits] >> gnu-dummy S2K, algo: 0, simple checksum, hash: 0 >> protect IV: >> keyid: 774BFCB80257A25B > > Note "gnu-dummy S2K". This is an empty placeholder for the key material. > An OpenPGP secret key always contains the primary key, but this is > GnuPG's method to get away with not actually including the primary key > nonetheless. Thank you ! > "S2K" means "String to Key", and an S2K is a method that derives a > cryptographic key from a passphrase. The cryptographic key is > subsequently used to encrypt the secret key material (well, apart from > the fact that this is a dummy that doesn't actually do that). > > And an OpenPGP secret key always contains the public key as well, which > /is/ included, in pkey[0] and pkey[1] (pkey -> public key). Clear. So I need to figure out why paperkey outputs more than I am expecting when minimalizing. >> :secret sub key packet: >> version 4, algo 1, created 1502976632, expires 0 >> pkey[0]: [4096 bits] >> pkey[1]: [17 bits] >> iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: 1B6594BA5204BCCC >> protect count: 16777216 (224) >> protect IV: a0 16 38 e5 6b a0 3c f0 16 f9 a4 17 c6 ba 14 a6 >> skey[2]: [v4 protected] >> keyid: 11A28C9369E55B8C > > And this is actually secret key material. First the public key again, > then the secret key in skey[2] (skey -> secret key). It is protected by > the "iter+salt" S2K. > > This packet will be significantly larger than the earlier packet. Ok. And it is. Thanks for helping to narrow this down, Kind regards, Dw. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 223 bytes Desc: Message signed with OpenPGP URL: From marioxcc.MT at yandex.com Thu Aug 17 15:55:06 2017 From: marioxcc.MT at yandex.com (=?UTF-8?Q?Mario_Castel=c3=a1n_Castro?=) Date: Thu, 17 Aug 2017 08:55:06 -0500 Subject: export secret subkeys In-Reply-To: <0B5E779D-A039-4110-B1D9-754902F7F563@webweaving.org> References: <0B5E779D-A039-4110-B1D9-754902F7F563@webweaving.org> Message-ID: <9fd40bd5-629b-5c26-89d0-259172dd92e3@yandex.com> It is my understanding that --export-secret-subkeys outputs a *dummy* (not the actual key) for the private part of the primary key, hence the output of --list-packets. The ?gpg? man page says ?The second form of the command [i.e.: --export-secret-subkeys] has the special property to render the secret part of the primary key useless;?. Regards. On 17/08/17 08:39, Dirk-Willem van Gulik wrote: > [[elided]] > > Instead the output of --list-packets (and the file size) suggests that both the master and the subkey are exported. > > Output below - followed by a script to reproduce. > > Or am I misreading this ? > > [[elided]] -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Fri Aug 18 01:49:23 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 17 Aug 2017 19:49:23 -0400 Subject: Is it possible to certify (sign) a key using a subkey? In-Reply-To: References: <03e883df-30d7-d7ae-130c-c2b1b411c403@sixdemonbag.org> Message-ID: <87y3qhiwl8.fsf@fifthhorseman.net> On Thu 2017-08-17 07:42:06 -0500, Mario Castel?n Castro wrote: > No, it does not have the certify capability. How can I enable this > capability? I recommend re-considering this approach, because there is likely to be software out there that: (a) doesn't expect to see certifications from subkeys at all, or (b) can't handle ECDSA aiui, your main goal was because the certifications are smaller, but you're still requiring people to fetch your larger primary key. if you want to really minimize the size, just make a new OpenPGP key that is ECDSA-only. That will still leave you on the outs with people using software in the (b) category, but you won't have to worry about the (a) category of software at all, and you will decrease the size of the necessary transfered data even further. --dkg From dkg at fifthhorseman.net Fri Aug 18 02:20:35 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 17 Aug 2017 20:20:35 -0400 Subject: fingerprint of key In-Reply-To: References: <87shgukwpm.fsf@fifthhorseman.net> <4d0c133b-746d-3172-6f34-7f88470e61eb@nofroth.com> <874lt9lvci.fsf@fifthhorseman.net> <87h8x9k8ur.fsf@fifthhorseman.net> <1d0acd15-6cb3-49e2-6f1d-c8813c8d6936@nofroth.com> Message-ID: <87mv6xiv58.fsf@fifthhorseman.net> On Mon 2017-08-14 22:12:18 -0300, Duane Whitty wrote: > Actually one suggestion, the way options and commands are specified > look the same. It might make things clearer if there was a difference > in the way they are expressed on the command line. Perhaps keep the > "--" for options and enter commands without the "--". I also prefer this kind of "subcommand" syntax -- it matches what tools like git and notmuch use. However, that's a pretty radical departure from the historical GnuPG command line, and it's likely to break all sorts of existing things that expect to use the canonical interface. If we're going to make radical departures like that, perhaps we should be specifying an entirely new interface that just does "the sensible bits" without all the rest of the arcana. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From dkg at fifthhorseman.net Fri Aug 18 02:18:01 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 17 Aug 2017 20:18:01 -0400 Subject: fingerprint of key In-Reply-To: <1d0acd15-6cb3-49e2-6f1d-c8813c8d6936@nofroth.com> References: <87shgukwpm.fsf@fifthhorseman.net> <4d0c133b-746d-3172-6f34-7f88470e61eb@nofroth.com> <874lt9lvci.fsf@fifthhorseman.net> <87h8x9k8ur.fsf@fifthhorseman.net> <1d0acd15-6cb3-49e2-6f1d-c8813c8d6936@nofroth.com> Message-ID: <87pobtiv9i.fsf@fifthhorseman.net> On Mon 2017-08-14 21:50:13 -0300, Duane Whitty wrote: > I perceive keys in my keyring as being ones I trust because of > out-of-band confirmation and used for two-way communications. You're not the only person with this perception. But i'm afraid i think it's a mistake, unfortunately. Actually safely curating an OpenPGP keyring with GnuPG is a non-trivial task. As an example, here's a damned-if-you-do, damned-if-you-don't conundrum: -------- Do you refresh the OpenPGP certificates in the keyring regularly (e.g. from the keyservers)? if you do not, then you risk missing notice of revocations, so you probably have some revoked keys in your keyring which you didn't know you had. If you do refresh them regularly, then it's possible that things (new user IDs, etc) get added to the certificates in your keyring during the refresh (or possibly whole new certificates get added entirely), and it contains things you've never actually vetted. -------- So, how to resolve this? The short version is that you should treat your GnuPG keyring as an untrusted collection of OpenPGP certificates that you know about. But you can explicitly mark the certificates that you think are legitimate by certifying them ("signing the keys"). In particular, you can make non-exportable ("local") signatures over the key+userid combinations that you have actually confirmed out-of-band. Even better, if you do that with a key which you have marked with "ultimate" ownertrust, then GnuPG will report a "validity" for those user IDs you've signed that matches what you intended to do, which is to curate a list of known-valid key+userid combinations. But treating the whole local keyring as a curated store is a mistake. GnuPG doesn't work that way, and it doesn't expect to work that way :( > I think the VirtualBox key is just to give people assurance that they > are downloading what they intended to download from the source they > expected, in this case via apt or apt-get, etc. from an Oracle repo. If you fetch the key each time you download something that you want to check against the key, how do you know it's the right key over time? If it's "the right key" because it was fetched over a secure channel from Oracle, why not just fetch the software over that channel? The advantage of having a key stored locally is that you only have to risk that network-fetch once; then you can make a local certification over its sensible VirtualBox User ID, to mark it as the expected key (If the User ID is *not* sensible, please complain to VirtualBox!). Then all future updates can be verified against the same key. Do you see how that's better than fetching the key each time? > I'm not exactly sure what a good suggestion would be. Would it be > correct to say that going forward usability changes would probably be > more likely to happen in the 2.1 branch? If so I guess I should > upgrade to the 2.1 branch. If a major change is going to happen in GnuPG, it will be in the 2.1 branch (or in 2.3 once 2.2 is released). the older branches of GnuPG (1.4.x and 2.0.x) receive very few changes from upstream. > I can say that what I usually end up being challenged by is importing > keys into my keyring and on being able to choose which UID I want to > sign with. Maybe that just means I don't know the software well enough. You don't sign with a UID, you sign with a key. > The approach I took was "gpg2 --search user at domain.com" and "gpg2 > - --recv-keys key-fingerprint". Then I did a "gpg2 --edit-key > key-fingerprint" to sign the key with my default UID. I thought I > would get a menu to select options from when I used --edit-key but > instead I was presented with the prompt "gpg>" and I had to type the > sign command. It worked but I might have chosen to sign the key with > a key from a different UID. Again, i'm not sure what you mean by "sign from a UID". can you be more clear? You're signing your friend's key+uid, from (or "with") your primary key. > Not sure if my method of importing to my keyring and signing the new > public key was the usual or easiest method but it worked. Sounds reasonable to me, except that you had to use --recv-keys, rather than just selecting the key to fetch from the --search interface. here's a transcript of me fetching a key that appears to be yours from the keyservers: 0 dkg at alice:~$ gpg --search duane at nofroth.com gpg: data source: https://145.100.185.229:443 (1) Arlen Duane Whitty (Duane) 2048 bit RSA key E25FA6BF14571B64, created: 2016-06-09 Keys 1-1 of 1 for "duane at nofroth.com". Enter number(s), N)ext, or Q)uit > 1 gpg: key E25FA6BF14571B64: public key "Arlen Duane Whitty (Duane) " imported gpg: Total number processed: 1 gpg: imported: 1 0 dkg at alice:~$ Note that i just typed "1" at the prompt, and it pulled your key in directly (no need for a subsequent --recv-keys invocation). 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 duane at nofroth.com Fri Aug 18 03:39:21 2017 From: duane at nofroth.com (Duane Whitty) Date: Thu, 17 Aug 2017 22:39:21 -0300 Subject: fingerprint of key In-Reply-To: <87pobtiv9i.fsf@fifthhorseman.net> References: <87shgukwpm.fsf@fifthhorseman.net> <4d0c133b-746d-3172-6f34-7f88470e61eb@nofroth.com> <874lt9lvci.fsf@fifthhorseman.net> <87h8x9k8ur.fsf@fifthhorseman.net> <1d0acd15-6cb3-49e2-6f1d-c8813c8d6936@nofroth.com> <87pobtiv9i.fsf@fifthhorseman.net> Message-ID: <4a03b978-33ac-0e0d-16d9-c9e5c4e0e0af@nofroth.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 17-08-17 09:18 PM, Daniel Kahn Gillmor wrote: > On Mon 2017-08-14 21:50:13 -0300, Duane Whitty wrote: >> I perceive keys in my keyring as being ones I trust because of >> out-of-band confirmation and used for two-way communications. > > You're not the only person with this perception. But i'm afraid i > think it's a mistake, unfortunately. > > Actually safely curating an OpenPGP keyring with GnuPG is a > non-trivial task. As an example, here's a damned-if-you-do, > damned-if-you-don't conundrum: > > -------- Do you refresh the OpenPGP certificates in the keyring > regularly (e.g. from the keyservers)? if you do not, then you risk > missing notice of revocations, so you probably have some revoked > keys in your keyring which you didn't know you had. > > If you do refresh them regularly, then it's possible that things > (new user IDs, etc) get added to the certificates in your keyring > during the refresh (or possibly whole new certificates get added > entirely), and it contains things you've never actually vetted. > -------- > > > So, how to resolve this? > > The short version is that you should treat your GnuPG keyring as > an untrusted collection of OpenPGP certificates that you know > about. But you can explicitly mark the certificates that you think > are legitimate by certifying them ("signing the keys"). In > particular, you can make non-exportable ("local") signatures over > the key+userid combinations that you have actually confirmed > out-of-band. > > Even better, if you do that with a key which you have marked with > "ultimate" ownertrust, then GnuPG will report a "validity" for > those user IDs you've signed that matches what you intended to do, > which is to curate a list of known-valid key+userid combinations. > > But treating the whole local keyring as a curated store is a > mistake. GnuPG doesn't work that way, and it doesn't expect to work > that way :( Sounds like a good approach but for someone who has more public keys stored than me. I only exchange encrypted email with a very, very small group of people and I am in regular voice communication with them. But I definitely see the merit in what you describe and believe that it is a cautious way of proceeding. I may even try working that way just to practice for the day when perhaps I consider it necessary to exchange encrypted mail with people I don't know well and don't talk with in person or on the telephone regularly. I guess using that approach I could import public keys from users on this list and then assign them various levels of trust, right down to no trust and not locally signed at all. > >> I think the VirtualBox key is just to give people assurance that >> they are downloading what they intended to download from the >> source they expected, in this case via apt or apt-get, etc. from >> an Oracle repo. > > If you fetch the key each time you download something that you want > to check against the key, how do you know it's the right key over > time? If it's "the right key" because it was fetched over a secure > channel from Oracle, why not just fetch the software over that > channel? > I suppose I chose to use apt or apt-get because it seems like a more convenient way to update things as opposed to getting it straight from Oracle. > The advantage of having a key stored locally is that you only have > to risk that network-fetch once; then you can make a local > certification over its sensible VirtualBox User ID, to mark it as > the expected key (If the User ID is *not* sensible, please complain > to VirtualBox!). Then all future updates can be verified against > the same key. > > Do you see how that's better than fetching the key each time? > Well, I see it potentially as less work but not less risk. I downloaded the key using wget and https. Then I check the validity of the key by comparing the fingerprint generated by GnuPG with what Oracle publishes on the VirtualBox site. Downloading the key once works if I implement your previous key/keyring management solution. Also, bear in mind, no software gets updated automatically on my system. I get notified of updates but when the update happens is up to me. >> I'm not exactly sure what a good suggestion would be. Would it >> be correct to say that going forward usability changes would >> probably be more likely to happen in the 2.1 branch? If so I >> guess I should upgrade to the 2.1 branch. > > If a major change is going to happen in GnuPG, it will be in the > 2.1 branch (or in 2.3 once 2.2 is released). the older branches of > GnuPG (1.4.x and 2.0.x) receive very few changes from upstream. > >> I can say that what I usually end up being challenged by is >> importing keys into my keyring and on being able to choose which >> UID I want to sign with. Maybe that just means I don't know the >> software well enough. > > You don't sign with a UID, you sign with a key. > >> The approach I took was "gpg2 --search user at domain.com" and >> "gpg2 - --recv-keys key-fingerprint". Then I did a "gpg2 >> --edit-key key-fingerprint" to sign the key with my default UID. >> I thought I would get a menu to select options from when I used >> --edit-key but instead I was presented with the prompt "gpg>" and >> I had to type the sign command. It worked but I might have >> chosen to sign the key with a key from a different UID. > > Again, i'm not sure what you mean by "sign from a UID". can you be > more clear? You're signing your friend's key+uid, from (or "with") > your primary key. > What I mean is that I have 2 email addresses which each have a different private key. The key for duane at nofroth.com has is associated with private counterpart to the key you fetched. I have another email address with a different private key associated to it. >> Not sure if my method of importing to my keyring and signing the >> new public key was the usual or easiest method but it worked. > > Sounds reasonable to me, except that you had to use --recv-keys, > rather than just selecting the key to fetch from the --search > interface. > > here's a transcript of me fetching a key that appears to be yours > from the keyservers: > > 0 dkg at alice:~$ gpg --search duane at nofroth.com gpg: data source: > https://145.100.185.229:443 (1) Arlen Duane Whitty (Duane) > 2048 bit RSA key E25FA6BF14571B64, created: > 2016-06-09 Keys 1-1 of 1 for "duane at nofroth.com". Enter number(s), > N)ext, or Q)uit > 1 gpg: key E25FA6BF14571B64: public key "Arlen > Duane Whitty (Duane) " imported gpg: Total > number processed: 1 gpg: imported: 1 0 dkg at alice:~$ > > > Note that i just typed "1" at the prompt, and it pulled your key > in directly (no need for a subsequent --recv-keys invocation). > > Regards, > > --dkg > As always, thank you for illuminating the finer points of GnuPG. Best Regards, Duane - -- Duane Whitty duane at nofroth.com -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZlkVCAAoJEOJfpr8UVxtkr90H/0mbZePGIdLGjxJUcAxSK8Jz X8jblhmDaeQRrcubdE3jUdg4YSO2sL++oBATJt34i4NoThD7EA5t89CjOaARioW5 2dU6wQVkVcPoYG4n8cjAqJNtmbsAr8ZnYTNIDoQllbSuPE7zMyT7gqXKFv8HWID/ gfAFx1u8sIwqDDOw3q+hOtJa+/1P3VjgmnRY3Ern11zaWCBIdGes+GxV5Ptx/kOD rfjA8s3sFml2ttNBPydGHtd6Q8Kv1u0qbP9Hy3X/gH5kw644nJBNXxXRAq+NoSB4 iLfpY2U6bzAoLy9eA+j4pyQ/KNt/CNmh9nk6FoEtjLrq5HXNdYPiV9AKAW5fkbQ= =EiCQ -----END PGP SIGNATURE----- From marioxcc.MT at yandex.com Fri Aug 18 02:47:16 2017 From: marioxcc.MT at yandex.com (=?UTF-8?Q?Mario_Castel=c3=a1n_Castro?=) Date: Thu, 17 Aug 2017 19:47:16 -0500 Subject: Is it possible to certify (sign) a key using a subkey? In-Reply-To: <87y3qhiwl8.fsf@fifthhorseman.net> References: <03e883df-30d7-d7ae-130c-c2b1b411c403@sixdemonbag.org> <87y3qhiwl8.fsf@fifthhorseman.net> Message-ID: <84cd8785-1d34-e0f8-5dd2-35c06b63aadd@yandex.com> On 17/08/17 18:49, Daniel Kahn Gillmor wrote: > aiui, your main goal was because the certifications are smaller, but > you're still requiring people to fetch your larger primary key. if you > want to really minimize the size, just make a new OpenPGP key that is > ECDSA-only. I have chosen RSA as a ?known good? algorithm for the primary key because if I chose a different curve or algorithm for elliptic key once I have the required knowledge to make an informed decision it will be more convenient to change only a subkey than to generate a new primary key. For example, I can keep the signatures (certifications) that I accumulate during that time on my key, supposing I have the opportunity to go to a signing party. Also, using a subkey for signing still has a size advantage. If you have, say, 5 keys signed by my ECC subkey. there will be less size Anyway, my question still stands: How can I enable the certificate capability on a subkey with GPG? Regards. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From duane at nofroth.com Fri Aug 18 03:48:36 2017 From: duane at nofroth.com (Duane Whitty) Date: Thu, 17 Aug 2017 22:48:36 -0300 Subject: fingerprint of key In-Reply-To: <87mv6xiv58.fsf@fifthhorseman.net> References: <87shgukwpm.fsf@fifthhorseman.net> <4d0c133b-746d-3172-6f34-7f88470e61eb@nofroth.com> <874lt9lvci.fsf@fifthhorseman.net> <87h8x9k8ur.fsf@fifthhorseman.net> <1d0acd15-6cb3-49e2-6f1d-c8813c8d6936@nofroth.com> <87mv6xiv58.fsf@fifthhorseman.net> Message-ID: <69cd1859-0308-c571-434a-89aefa7b737e@nofroth.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 17-08-17 09:20 PM, Daniel Kahn Gillmor wrote: > On Mon 2017-08-14 22:12:18 -0300, Duane Whitty wrote: >> Actually one suggestion, the way options and commands are >> specified look the same. It might make things clearer if there >> was a difference in the way they are expressed on the command >> line. Perhaps keep the "--" for options and enter commands >> without the "--". > > I also prefer this kind of "subcommand" syntax -- it matches what > tools like git and notmuch use. However, that's a pretty radical > departure from the historical GnuPG command line, and it's likely > to break all sorts of existing things that expect to use the > canonical interface. > > If we're going to make radical departures like that, perhaps we > should be specifying an entirely new interface that just does "the > sensible bits" without all the rest of the arcana. > > --dkg > Well, I'm not familiar enough with the arcana to say whether it should be done away with or not but, I am a big believer in software not trying to guess what I want. As you said, in version 2.1 GnuPG would have complained that I hadn't entered a command, correct? Does this also mean it would have not carried out any action. In my opinion that would be the correct behaviour. I am also a fan of the Unix tradition of software that completes without error not having any output unless you have asked for output. Error output going to stderr of course :-) I have to admit to being a little hesitant making these types of comments because I don't feel I contributed enough (if anything) to have earned that right. But perhaps as a user the comment is a small contribution. I hope it is seen that way and not as a complaint. Best Regards, Duane - -- Duane Whitty duane at nofroth.com -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZlkdxAAoJEOJfpr8UVxtkwXwIAKg6U2hJM2v0469V3Q+dr2k8 6cn8+6nwdkARZQhABP+iSOLbFcnaGL2RLzw26+47E3pqf1X837VeHnsdBZvzQYTQ oXB/0YTmhjsjL6hpN1V5N5+CHkmMwbwyoHD7XGFpETA/1RfgrhlkqUtcfqjBCUw6 zAvUeD6/rxhASeBb1A231924iSUFqqhkf0IXGvgJmrmIU2hPCZPkdwnxEQ+Lm5K5 8AhsnEKdE3mABlqr0mMM/uuYLI1bknxYT2QtIU2Q1gwH0af4+WqLdcv9H4dMAmQS HYfYv8s8MAyoqPNZs2QXOg76TBhPHF382MYLGCzT9rHMWaRLk/6zmCZKOSiGtO0= =5mpS -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Fri Aug 18 05:14:07 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 17 Aug 2017 23:14:07 -0400 Subject: fingerprint of key In-Reply-To: <69cd1859-0308-c571-434a-89aefa7b737e@nofroth.com> References: <87shgukwpm.fsf@fifthhorseman.net> <4d0c133b-746d-3172-6f34-7f88470e61eb@nofroth.com> <874lt9lvci.fsf@fifthhorseman.net> <87h8x9k8ur.fsf@fifthhorseman.net> <1d0acd15-6cb3-49e2-6f1d-c8813c8d6936@nofroth.com> <87mv6xiv58.fsf@fifthhorseman.net> <69cd1859-0308-c571-434a-89aefa7b737e@nofroth.com> Message-ID: <87a82xin40.fsf@fifthhorseman.net> On Thu 2017-08-17 22:48:36 -0300, Duane Whitty wrote: > Well, I'm not familiar enough with the arcana to say whether it should > be done away with or not but, I am a big believer in software not > trying to guess what I want. As you said, in version 2.1 GnuPG would > have complained that I hadn't entered a command, correct? Does this > also mean it would have not carried out any action. nope, GnuPG took the conservative approach and just produced a warning while still trying to make a guess at what you meant. > I have to admit to being a little hesitant making these types of > comments because I don't feel I contributed enough (if anything) to > have earned that right. But perhaps as a user the comment is a small > contribution. I hope it is seen that way and not as a complaint. Please don't underestimate the value of suggestions and questions from a user. Free software gets better because its users talk about it and share ideas about how it can improve. You don't need to have contributed code to contribute ideas :) --dkg From dkg at fifthhorseman.net Fri Aug 18 05:25:26 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 17 Aug 2017 23:25:26 -0400 Subject: Is it possible to certify (sign) a key using a subkey? In-Reply-To: <84cd8785-1d34-e0f8-5dd2-35c06b63aadd@yandex.com> References: <03e883df-30d7-d7ae-130c-c2b1b411c403@sixdemonbag.org> <87y3qhiwl8.fsf@fifthhorseman.net> <84cd8785-1d34-e0f8-5dd2-35c06b63aadd@yandex.com> Message-ID: <874lt5iml5.fsf@fifthhorseman.net> On Thu 2017-08-17 19:47:16 -0500, Mario Castel?n Castro wrote: > I have chosen RSA as a ?known good? algorithm for the primary key > because if I chose a different curve or algorithm for elliptic key once > I have the required knowledge to make an informed decision it will be > more convenient to change only a subkey than to generate a new primary > key. For example, I can keep the signatures (certifications) that I > accumulate during that time on my key, supposing I have the opportunity > to go to a signing party. I still don't think this is a good justification, fwiw. If you think you'll be making these certifications for other people to consume, please do those other people a favor and just use your primary key. The OpenPGP world has a habit of trying to make things too fancy. Keep it simple! > Also, using a subkey for signing still has a size advantage. If you > have, say, 5 keys signed by my ECC subkey. there will be less size Where are you trying to save these bytes? > Anyway, my question still stands: How can I enable the certificate > capability on a subkey with GPG? I don't know of a way to change usage flags on an existing subkey with GnuPG without modifying the source. You can add a new subkey with your chosen usage flags in --expert mode, though. But i don't recommend it. --dkg From dkg at fifthhorseman.net Fri Aug 18 05:19:58 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 17 Aug 2017 23:19:58 -0400 Subject: fingerprint of key In-Reply-To: <4a03b978-33ac-0e0d-16d9-c9e5c4e0e0af@nofroth.com> References: <87shgukwpm.fsf@fifthhorseman.net> <4d0c133b-746d-3172-6f34-7f88470e61eb@nofroth.com> <874lt9lvci.fsf@fifthhorseman.net> <87h8x9k8ur.fsf@fifthhorseman.net> <1d0acd15-6cb3-49e2-6f1d-c8813c8d6936@nofroth.com> <87pobtiv9i.fsf@fifthhorseman.net> <4a03b978-33ac-0e0d-16d9-c9e5c4e0e0af@nofroth.com> Message-ID: <877ey1imu9.fsf@fifthhorseman.net> On Thu 2017-08-17 22:39:21 -0300, Duane Whitty wrote: > Sounds like a good approach but for someone who has more public keys > stored than me. I only exchange encrypted email with a very, very > small group of people and I am in regular voice communication with > them. If you're going to manage a keyring manually, this is the right way to do it, regardless of how many OpenPGP certificates you have in your keyring. (it's actually easier to do when you only have a few) > I guess using that approach I could import public keys from users on > this list and then assign them various levels of trust, right down to > no trust and not locally signed at all. Note that nothing i outlined in my earlier suggestions involved you setting "trust levels" (a.k.a. "ownertrust") at all. setting "full trust" on a key means "i'm willing to accept identity assertions made by the owner of this key" -- it's equivalent to "adding a root CA to your browser" in some sense. You can use GnuPG for years without ever setting any sort of ownertrust on any key but your own (and if you generated your key in gpg, it probably already has ultimate ownertrust). Start with "whose keys do i believe i've checked?" -- that's plain keysigning. then, only later, if you really want to get into the whole web-of-trust thing, should you consider setting ownertrust. > I suppose I chose to use apt or apt-get because it seems like a more > convenient way to update things as opposed to getting it straight from > Oracle. well said :) > What I mean is that I have 2 email addresses which each have a > different private key. The key for duane at nofroth.com has is > associated with private counterpart to the key you fetched. I have > another email address with a different private key associated to it. i see, so you're talking about signing with a different key (not a different uid). You might want to look into adding the --default-key or --local-user options before you do your next --edit-key operation. All the best, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From dkg at fifthhorseman.net Fri Aug 18 07:35:20 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 18 Aug 2017 01:35:20 -0400 Subject: Edit key in batch mode In-Reply-To: <640D7AD9-016E-4BAB-A8B9-C06E603CEE4E@users.sourceforge.net> References: <640D7AD9-016E-4BAB-A8B9-C06E603CEE4E@users.sourceforge.net> Message-ID: <87pobth207.fsf@fifthhorseman.net> Hi Ahmed-- On Sun 2017-08-13 00:45:28 +0000, ???? ???????? wrote: > I have gnupg 1.4 installed on my system. I am trying to edit my key in batch mode using the following command: > > gpg --edit-key --command-fd 0 --status-fd=2 < scr > > the contents of 'scr' file is: > ===== > adduid > ???? ???????? > aelmahmoudy at users.sourceforge.net > Ahmed El-Mahmoudy > ===== > > so I get the following error: > > Invalid command (try "help") > > Can someone help ? I recommend using GnuPG 2.1 and --quick-add-uid for this purpose. Regards, --dkg From marioxcc.MT at yandex.com Fri Aug 18 16:16:45 2017 From: marioxcc.MT at yandex.com (Mario =?UTF-8?B?Q2FzdGVsw6Fu?= Castro) Date: Fri, 18 Aug 2017 09:16:45 -0500 Subject: Is it possible to certify (sign) a key using a subkey? In-Reply-To: <874lt5iml5.fsf@fifthhorseman.net> References: <03e883df-30d7-d7ae-130c-c2b1b411c403@sixdemonbag.org> <87y3qhiwl8.fsf@fifthhorseman.net> <84cd8785-1d34-e0f8-5dd2-35c06b63aadd@yandex.com> <874lt5iml5.fsf@fifthhorseman.net> Message-ID: <20170818091645.7f86767c@yandex.com> On 2017-08-17 23:25 -0400 Daniel Kahn Gillmor wrote: >I still don't think this is a good justification, fwiw. If you think >you'll be making these certifications for other people to consume, >please do those other people a favor and just use your primary key. >The OpenPGP world has a habit of trying to make things too fancy. Keep >it simple! I really do not follow your argument (if any). Whether I sign with my primary key or a subkey is a low level detail. There is no any additional difficulty encountered by the user who verifies a certificate made by a subkey, assuming he is using a capable OpenPGP implementation. This is a low level detail that is for the most abstracted from the user by the implementation (GNU PG), just as users need not know number theory in order to use public key algorithms, they need not be concerned of whether I use my primary key or a subkey for certifying. >> Also, using a subkey for signing still has a size advantage. If you >> have, say, 5 keys signed by my ECC subkey. there will be less size > >Where are you trying to save these bytes? In my own and other people's keyrings and in key servers. >I don't know of a way to change usage flags on an existing subkey with >GnuPG without modifying the source. > >You can add a new subkey with your chosen usage flags in --expert mode, >though. But i don't recommend it. Like I said in a previous message, even using ?gpg --expert --edit-key? (GNU PG version 2.1.18 as shipped in Debian 9), I do not get the option to toggle the certify capability when adding a new subkey, not even if I choose the option ?choose your own capabilities?. Hmm... it looks like I will have to do some programming. This is not good. GNU PG should already have this feature. Regards. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Fri Aug 18 18:33:47 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 18 Aug 2017 18:33:47 +0200 Subject: Is it possible to certify (sign) a key using a subkey? In-Reply-To: <20170818091645.7f86767c@yandex.com> References: <03e883df-30d7-d7ae-130c-c2b1b411c403@sixdemonbag.org> <87y3qhiwl8.fsf@fifthhorseman.net> <84cd8785-1d34-e0f8-5dd2-35c06b63aadd@yandex.com> <874lt5iml5.fsf@fifthhorseman.net> <20170818091645.7f86767c@yandex.com> Message-ID: On 18/08/17 16:16, Mario Castel?n Castro wrote: > I really do not follow your argument (if any). Since making certifications using subkeys is extremely uncommon, there's a good chance people will encounter issues when checking such a certification. Since the purpose of a public certification is for other people, not you, to check it, you are not doing them a service. > In my own and other people's keyrings and in key servers. The impact of you doing this on your own seems vanishingly small. And the ratio of disk space used by a public keyring versus everything else that is commonly on a computer isn't different. If I were looking for optimizations, I'd turn to processing time of a public keyring, not its size. > GNU PG should already have this feature. I disagree. The de facto standard is that certifications are issued by the primary, even if this might not be encoded in the RFC (I didn't check, though). You could create an ECC primary if you really want to issue certifications with ECC. Do note that there are many OpenPGP clients that do not support ECC yet. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From leo at gaspard.io Fri Aug 18 19:16:03 2017 From: leo at gaspard.io (Leo Gaspard) Date: Fri, 18 Aug 2017 19:16:03 +0200 Subject: Is it possible to certify (sign) a key using a subkey? In-Reply-To: References: <03e883df-30d7-d7ae-130c-c2b1b411c403@sixdemonbag.org> <87y3qhiwl8.fsf@fifthhorseman.net> <84cd8785-1d34-e0f8-5dd2-35c06b63aadd@yandex.com> <874lt5iml5.fsf@fifthhorseman.net> <20170818091645.7f86767c@yandex.com> Message-ID: On 08/18/2017 06:33 PM, Peter Lebbing wrote:>> In my own and other people's keyrings and in key servers. > > The impact of you doing this on your own seems vanishingly small. And > the ratio of disk space used by a public keyring versus everything else > that is commonly on a computer isn't different. If I were looking for > optimizations, I'd turn to processing time of a public keyring, not its > size. Just for the record, there seem to me like there may be another reason for separate subkeys for certification, namely the one of security of the masterkey. Having a C subkey would allow to keep the masterkey entirely isolated and to only use a diode to export C subkeys to a ?keysigning machine?, that would not compromise the masterkey by its compromise. Then, in case of compromise of the keysigning machine, it'd be possible to revoke the C subkey and create another one, then re-sign all the previously signed keys with this new C subkey, all without losing the signatures on the masterkey. This is quite different from ?airgapped computers? that use USB drives to transit to-be-signed keys, as the USB stack in itself (or the filesystem, or gnupg's certification operation) could be compromised; the most obvious attack scenario being one based on badusb-like compromising the key's firmware to make it act like a keyboard typing the commands required to exfiltrate the masterkey. Then, it's quite sad if C subkeys aren't widely supported, but I guess that's another issue (and maybe it should be clearly spelled out in the RFC whether they must be supported? especially with rfc4880bis in the works, now could be a good time to choose) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From alex at nitrokey.com Mon Aug 21 17:12:53 2017 From: alex at nitrokey.com (Alexander Paetzelt | Nitrokey) Date: Mon, 21 Aug 2017 17:12:53 +0200 Subject: Powering down smartcard does not work Message-ID: Hello, I try to power down my gnupg smartcard after some time by adding 'card-timeout 15' to ~/.gnupg/scdaemon.conf but the card seems to stay powered as the PIN stays cached. Do you have any idea why the config is not working correctly? Kind regards Alex From germano.massullo at gmail.com Wed Aug 23 14:09:04 2017 From: germano.massullo at gmail.com (Germano Massullo) Date: Wed, 23 Aug 2017 14:09:04 +0200 Subject: No longer prompted for pinentry-qt (FAILURE sign 100663404) Message-ID: <4eabe042-3162-0574-a01e-d418ddd149a2@gmail.com> Good day. I am writing this e-mail after a previous help request in Enigmail forum[1] I always used Enigmail/GNUPG successfully with Thunderbird on Fedora KDE Plasma But, since I created some subkeys in order to use a Nitrokey Pro as secondary signing device, I have been unable to sign/encrypt emails with regular passphrase entered in pinentry-qt I mean, for example I don't have Nitrokey Pro plugged into the computer because I want to use the regular privatekey that is on the system: Thunderbird instead of prompting me for private key passphrase, it shows me error message "encryption command failed". In logs I could see FAILURE sign 100663404, that leads to this bugreport [2] At [3] there is an extract of Enigmail/GNUPG debug logs At [1], Patrick Brunschwig told me that the error corresponds to # gpg-error 100663404 100663404 = (6, 108) = (GPG_ERR_SOURCE_SCD, GPG_ERR_CARD) = (SCD, Card error) What can I do? Thank you [1]: https://sourceforge.net/p/enigmail/forum/support/thread/e034976e/ [2]: https://sourceforge.net/p/enigmail/bugs/673/ [3]: https://germano.fedorapeople.org/canc/em/em.txt -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Thu Aug 24 07:59:57 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 24 Aug 2017 07:59:57 +0200 Subject: --export-options export-reset-subkey-passwd In-Reply-To: (Daniele Nicolodi's message of "Sun, 13 Aug 2017 00:17:16 -0600") References: <6308661f-1769-3e76-84d4-b25168688cf6@grinta.net> Message-ID: <87mv6pqzdu.fsf@wheatstone.g10code.de> On Sun, 13 Aug 2017 08:17, daniele at grinta.net said: > Digging a bit more, it seems that the functionality got dropped because > with GnuPG 2.x all key manipulations go through gpg-agent and it does > not (yet?) support password reset on expert. Unfortunately this is still an open bug: https://dev.gnupg.org/T1753 we won't be able to fix it for 2.2.0 but given that it is marked as a bug it can and should be fixed in the soon to be release 2.2 series. 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: 227 bytes Desc: not available URL: From Roman.Fiedler at ait.ac.at Fri Aug 25 16:08:33 2017 From: Roman.Fiedler at ait.ac.at (Fiedler Roman) Date: Fri, 25 Aug 2017 14:08:33 +0000 Subject: Extraction of decryption session key without copying complete encrypted file Message-ID: <2ECE9D9EEF1F524185270138AE23265955AD9A14@S0MSMAIL112.arc.local> Addendum: agent-use > From: Werner Koch [mailto:wk at gnupg.org] > > On Fri, 4 Aug 2017 14:36, Roman.Fiedler at ait.ac.at said: > > Ah, that's great - and actually the first nice gpg-agent feature apart > > from > > gpg-agent being little annoying when running it on RAM-disks in early > > boot. > > (And the ssh-agent support, which is one of the mos useful features I > have on my box for 10 years or so.) I tried to use the agent support that way. One reason for low adoption might be, that using the provided documentation, it is just not possible to get a simple batch scenario working on Ubuntu 16.04 server setups without spending a whole day and debugging into the sources. No matter what combination of gpg/gpg2 binaries and agents you use, batch decryption fails at one or the other point when using the agent, e.g. 2017-08-25 13:03:52 gpg-agent[24047] DBG: error calling pinentry: No such device or address or gpg: DBG: chan_6 <- ERR 83918950 Inappropriate ioctl for device or related to incompatibilities between source server gpg version and target server when attempting remote configurations. I guess the agent works fine on Microsoft and perhaps also desktop systems, but it just cannot be automated in pure commandline only setups. If someone knows a script (or two to be executed in separate terminals, would also be OK) working on Ubuntu 16.05 with gpg 1.4.20 or 2.1.11 that just a) launch the agent b) batch decrypt a list of files c) asks for passphrase if new secret key is required d) after completion, terminate all processes required during a-c and perform cleanup that would be very helpful. LG R -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4814 bytes Desc: not available URL: From wally.twenty.ten at gmail.com Fri Aug 25 14:55:44 2017 From: wally.twenty.ten at gmail.com (D Mouer) Date: Fri, 25 Aug 2017 08:55:44 -0400 Subject: Need help installing 2.1.23 Message-ID: Hi, I'm currently running Fedora 25 with GnuPG v2.13 installed. I want to upgrade to v2.1.23 by manually compiling. I have downloaded: npth 1.5 libgpg-error 1.27 libgcrypt 1.8 libksba 1.3.5 libassuan 2.4.3 gnupg-2.1.23 Read the README and INSTALL for gnupg-2.1.23, which instructed to install the supporting libs in that order above. Began with npth: - read the README and INSTALL - (as sudo, executed:) ./configure, make, make check, make install - output appeared complete and successfull - verified the libraries were installed in /usr/local/lib - other files mentioned were in /usr/local/... Repeated the process for the next library (libgpg-error), results appeared ok and checked /usr/local/share/common-lisp/... Repeated the process again for libcrypt, unfortunately at the end of the ./configure step it gave this message: checking for GPG Error - version >= 1.25... no configure: error: libgpg-error is needed. See ftp://ftp.gnupg.org/gcrypt/libgpg-error/ . I thought the previous libgpg-error install succeeded, perhaps not? How do I proceed at this point? Can I repeat the build / install process for libgpg-error? Or will it fail since the files may already be there? Is there something I need to do to tell libcrypt I have libgpg-error (>=1.25) installed? Thanks. Dan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at digitalbrains.com Fri Aug 25 17:36:50 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 25 Aug 2017 17:36:50 +0200 Subject: Extraction of decryption session key without copying complete encrypted file In-Reply-To: <2ECE9D9EEF1F524185270138AE23265955AD9A14@S0MSMAIL112.arc.local> References: <2ECE9D9EEF1F524185270138AE23265955AD9A14@S0MSMAIL112.arc.local> Message-ID: <0223db8f-a44b-367b-0152-c5d7217e2a6b@digitalbrains.com> On 25/08/17 16:08, Fiedler Roman wrote: > I tried to use the agent support that way. One reason for low adoption might > be, that using the provided documentation, it is just not possible to get a > simple batch scenario working on Ubuntu 16.04 server setups without spending a > whole day and debugging into the sources. Could you explain further what you are trying to accomplish? "Batch scenario" suggests to me: the human user is not logged in. "GnuPG agent forwarding" suggests to me: the human user is logged in through SSH. So I'm obviously missing some aspect of what you are doing. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From Roman.Fiedler at ait.ac.at Fri Aug 25 18:40:38 2017 From: Roman.Fiedler at ait.ac.at (Fiedler Roman) Date: Fri, 25 Aug 2017 16:40:38 +0000 Subject: AW: Extraction of decryption session key without copying complete encrypted file In-Reply-To: <0223db8f-a44b-367b-0152-c5d7217e2a6b@digitalbrains.com> References: <2ECE9D9EEF1F524185270138AE23265955AD9A14@S0MSMAIL112.arc.local> <0223db8f-a44b-367b-0152-c5d7217e2a6b@digitalbrains.com> Message-ID: <2ECE9D9EEF1F524185270138AE23265955AD9BBF@S0MSMAIL112.arc.local> > From: Peter Lebbing [mailto:peter at digitalbrains.com] > > On 25/08/17 16:08, Fiedler Roman wrote: > > I tried to use the agent support that way. One reason for low adoption > > might > > be, that using the provided documentation, it is just not possible to get > > a > > simple batch scenario working on Ubuntu 16.04 server setups without > > spending a > > whole day and debugging into the sources. > > Could you explain further what you are trying to accomplish? The goal is to find a solution to decrypt numerous large, encrypted storage elements with a procedure, hopefully so simple, that it can be written in a SOP for execution by any Linux-admin with appropriate permissions without need to understand GPG, fight with different GPG versions on different machines, ... The problem is: 1) the encrypted elements are on a storage (trust zone A), where access to the private key is forbidden by policy 2) the elements are too large to copy them to the admin machine, where the private key is (trust zone B) 3) the elements are used on target machines with different GPG versions (some in a trust zone C, where the admin having access to the key does not have access to the machine, where decryption could occur) Idea: 1) Extract all GPG preambles of files to be decrypted to a single file (working) 2) Batch decrypt all preambles from the input file on the trusted equipment (not working in batch mode) 3) Decrypt all storage elements with the list of session keys (working) > "Batch scenario" suggests to me: the human user is not logged in. Not really for step 1, 3 - at least those steps do not require interactivity > "GnuPG agent forwarding" suggests to me: the human user is logged in > through SSH. For step 2 yes. But SSH connection, agent and session key extraction seem not to play together well on Ubuntu 16.04 Best regards, Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4814 bytes Desc: not available URL: From peter at digitalbrains.com Fri Aug 25 18:57:34 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 25 Aug 2017 18:57:34 +0200 Subject: AW: Extraction of decryption session key without copying complete encrypted file In-Reply-To: <2ECE9D9EEF1F524185270138AE23265955AD9BBF@S0MSMAIL112.arc.local> References: <2ECE9D9EEF1F524185270138AE23265955AD9A14@S0MSMAIL112.arc.local> <0223db8f-a44b-367b-0152-c5d7217e2a6b@digitalbrains.com> <2ECE9D9EEF1F524185270138AE23265955AD9BBF@S0MSMAIL112.arc.local> Message-ID: On 25/08/17 18:40, Fiedler Roman wrote: > Idea: > 1) Extract all GPG preambles of files to be decrypted to a single file > (working) > 2) Batch decrypt all preambles from the input file on the trusted equipment > (not working in batch mode) > 3) Decrypt all storage elements with the list of session keys (working) It doesn't sound like you need agent forwarding at all. I would expect that you can decrypt with a session key without an agent, since the agent is only consulted to get the session key, but you already have it. Step 2 is not working, but it is all on the system with the private key, with a locally running agent. Dit you either gpg-preset-passphrase or remove the passphrase from the key? If the agent needs to prompt the user with a pinentry, but there is no human since it is batch operation, it will error out. So it needs to know the passphrase already or the passphrase needs to be removed. I think agent forwarding is an alternative to your idea, not a way to implement it. With agent forwarding, the remote system without the private key would ask the forwarded agent to decrypt the public-key-encrypted-session-key for it and obtain the session key that way and that would avoid all the extra steps. Provided it worked :-). HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From stefan.claas at posteo.de Sat Aug 26 07:39:10 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Sat, 26 Aug 2017 07:39:10 +0200 Subject: Bitcoin private key from GnuPG secp256k1 secret key? In-Reply-To: <87tw1pxgfe.fsf@fsij.org> References: <3xMw342rkHz10Hj@submission01.posteo.de> <87tw1pd40r.fsf@fsij.org> <3xNLdd5T9dz10HZ@submission01.posteo.de> <87tw1pxgfe.fsf@fsij.org> Message-ID: <20170826073910.4d7db5ab@iria.my-fqdn.de> On Thu, 03 Aug 2017 16:24:05 +0900, NIIBE Yutaka wrote: > Stefan Claas wrote: > > I could imagine that no one will do this, because if you have no > > private key for "your" public address (according to your reply), > > you have no control of that address, like spending/ sending > > BTC from this address. > > Sorry about my vague description. > > As a subkey of 0x00B45EBD4CA7BABE, I have a key of secp256k1. And the > private key is controlled by me, on a Gnuk Token. But I have no > "wallet", yet. This is the situation. > > My idea was that we can use WoT of OpenPGP to check Bitcoin address. > It seems that people don't buy this idea. Hi NIIBE-san, while reading a bit more on the Bitcoin Wiki and reading about Bitmessage papers etc. I would like to know from you and all other experts here on the list about some thoughts i have and what you think about this. First of all, inspired by your script i looked for an easy way to extract the secret key material of a GnuPG secp256k1 sub key, which works nicely with GnuPG, without the usage of a script or programming knowledge etc. With this secret key material everybody could create a valid Bitcoin address and when using two sub keys (like a signing and a encryption key one can also generate a Bitmessage key pair with the proper Bitmessage address. Usually pub keys with Bitcoin or Bitmessage are not seen by the user, afaik. Except a Bitcoin user would sign a message with it's secret Bitcoin key and the pub key would be derived from the address and the signature data. i tried also out educational open source software for Bitcoin signing and encryption and the interesting thing was that when a user likes to encrypt a message to another user the software looks up the blockchain and checks if there was a valid transaction done. If not the encryption fails. I tried also another .html based software for Bitcoin signing out and what i liked very much about this is that users can verify a signed Bitcoin message, without needing a public key from the communication partner in advance, nor does the software collects public keys, because it's not needed. Now my thoughts about this subject. Let's say i create a valid Bitcoin address from a secret GnuPG secp256k1 sub key and import the secret key material, which i have converted to a valid WIF secret key, into my Bitcoin wallet. Now if i buy officially some Satoshi from well known traders and transfer, as a registered user, from this account the Satoshi to my newly created GnuPG Bitcoin Address the transaction is in the blockchain. If then i would send from my valid GnuPG Bitcoin address some Satoshi to a valid gnupg.org Bitcoin address i would have donated (the modern way :-)) a bit to the GnuPG Foundation and it would appear also in the block chain and i think this could be then also a sign of proof that i'm the owner of a public key, without being in the Web of Trust. keybase.io users for example have the option to publish their Bitcoin address on their page as well. The second thought. I already have lot's of GnuPG public keys collected due to reading the mailing list or signed Usenet posts. Thanks to auto-key-retrieve on. If GnuPG would allow a user in the future to use an additional flag, when signing with a secp256k1 sub key, which would produce signatures that would work like Bitcoin key signatures, users would not need to collect a ton of public keys and the signature would verify. Well, i hope that my thoughts are not to crazy, but i really would like to hear the opinion from other members here. Best regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 506 bytes Desc: Digitale Signatur von OpenPGP URL: From stefan.claas at posteo.de Sat Aug 26 08:21:38 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Sat, 26 Aug 2017 08:21:38 +0200 Subject: Bitcoin private key from GnuPG secp256k1 secret key? In-Reply-To: <20170826073910.4d7db5ab@iria.my-fqdn.de> References: <3xMw342rkHz10Hj@submission01.posteo.de> <87tw1pd40r.fsf@fsij.org> <3xNLdd5T9dz10HZ@submission01.posteo.de> <87tw1pxgfe.fsf@fsij.org> <20170826073910.4d7db5ab@iria.my-fqdn.de> Message-ID: <20170826082138.05a42c8b@iria.my-fqdn.de> On Sat, 26 Aug 2017 07:39:10 +0200, Stefan Claas wrote: > If GnuPG would allow a user in the future to use an additional flag, > when signing with a secp256k1 sub key, which would produce > signatures that would work like Bitcoin key signatures, users would > not need to collect a ton of public keys and the signature would > verify. And if GnuPG would allow in the future to export a secp256k1 sub key additionally in WIF format one could easily import the key in his/her bitcoin wallet without the usage of some scripts etc. Best regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 506 bytes Desc: Digitale Signatur von OpenPGP URL: From lwn at anarc.at Sat Aug 26 00:35:47 2017 From: lwn at anarc.at (=?utf-8?Q?Antoine_Beaupr=C3=A9?=) Date: Fri, 25 Aug 2017 18:35:47 -0400 Subject: benchmarking security tokens speed Message-ID: <87pobjcm2k.fsf@curie.anarc.at> Hi, I'm in the process of reviewing performance of various security tokens (the Yubikeys, the FST-01, Nitrokey), and I am getting somewhat interesting (if not surprising) results: -------------- next part -------------- A non-text attachment was scrubbed... Name: results-16b-all.png Type: image/png Size: 24808 bytes Desc: not available URL: -------------- next part -------------- Times are in seconds. It looks like the Yubikey 4 is the fastest, being (only?) 10 times slower than the CPU (i3-6100U). That slows down another order of magnitude with 4096 keys. The NEO is as slow in 2048 as the 4 is in 4096, and of course doesn't support 4096 at all. The FST-01 is the slowest of the bunch, taking more than a full second to kick decryption in 2048bit RSA and 8 seconds in 4096 bits. I'm looking for feedback on the results and the test procedure, which is a Python script, attached. I'm aware of the limitations of the script, namely that it treats the *whole* GPG decryption process as a blackbox, which includes AES and all sorts of stuff. In my tests, GPG chooses AES-256 which is why I chose a 16 bytes filesize. Since the timings seems to be fairly consistent, I am assuming the delays are consistent. Also, I was thinking of removing the file altogether and pipe pseudo-random bytes in to remove possible disk contention issues, but my test results are fairly consistent so I don't think that's necessary either. I'm also looking at getting my hands on Nitrokey hardware and adding elleptic curve support to complete the test suite. Any comments and help would of course be very welcome. A. -- Antoine Beaupr? LWN.net -------------- next part -------------- A non-text attachment was scrubbed... Name: bench-tokens.py Type: text/x-python Size: 14837 bytes Desc: not available URL: From phylliswalters1983 at gmail.com Sat Aug 26 23:05:16 2017 From: phylliswalters1983 at gmail.com (CORY WALTERS) Date: Sat, 26 Aug 2017 16:05:16 -0500 Subject: No subject Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From arznix at yahoo.com Sun Aug 27 11:40:09 2017 From: arznix at yahoo.com (arznix) Date: Sun, 27 Aug 2017 09:40:09 +0000 (UTC) Subject: Newbie Question: Creating a Key Server using GNUPG tools References: <884828596.3127699.1503826809831.ref@mail.yahoo.com> Message-ID: <884828596.3127699.1503826809831@mail.yahoo.com> Hi, This is a total newbie question as I have just discovered GNUPG. I am developing a closed mesh network application where I want to encrypt the traffic using PGP. The local network will have no access the the greater worldwide web so it will not be able to access existing trusted Key Servers. It is unclear from the documentation for GNUPG and some of the supporting writeups on other websites whether I can create a Key Server for the local network that will generate public and private key pairs. It looks like there is a server mode you can put the process in but it is unclear what services that gives you access to. Can anyone clarify whether it is possible to create a local Key Server using the GNUPG tools? Any links to sample code would also be great. The system is being develop with Linux as the operating system for the servers attached to the mesh network. From dgouttegattat at incenp.org Sun Aug 27 13:38:38 2017 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sun, 27 Aug 2017 13:38:38 +0200 Subject: Newbie Question: Creating a Key Server using GNUPG tools In-Reply-To: <884828596.3127699.1503826809831@mail.yahoo.com> References: <884828596.3127699.1503826809831.ref@mail.yahoo.com> <884828596.3127699.1503826809831@mail.yahoo.com> Message-ID: <208f86b9-8018-d60a-9fa9-7c84aaa3b4f9@incenp.org> Hi, On 08/27/2017 11:40 AM, arznix via Gnupg-users wrote: > Can anyone clarify whether it is possible to create a local Key Server using the > GNUPG tools? Not with GnuPG itself. The GnuPG project does not provide a keyserver software. Most keyservers out there are powered by a software called SKS (Synchronizing Key Server) [1,2]. For a local network, a LDAP-based keyserver may also be considered. The GnuPG wiki has a page on how to setup such a server [3]. Finally, with GnuPG modern (>= 2.1) you may choose to setup a Web Key Directory. This is a recently introduced approach to key distribution, for which GnuPG provides some tools and documentation [4,5]. Hope that helps, Damien [1] https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Home [2] https://keyserver.mattrude.com/guides/building-server/ [3] https://wiki.gnupg.org/LDAPKeyserver [4] https://gnupg.org/blog/20160830-web-key-service.html [5] https://gnupg.org/blog/20161027-hosting-a-web-key-directory.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From marioxcc.MT at yandex.com Sun Aug 27 15:14:02 2017 From: marioxcc.MT at yandex.com (=?UTF-8?Q?Mario_Castel=c3=a1n_Castro?=) Date: Sun, 27 Aug 2017 08:14:02 -0500 Subject: Newbie Question: Creating a Key Server using GNUPG tools In-Reply-To: <884828596.3127699.1503826809831@mail.yahoo.com> References: <884828596.3127699.1503826809831.ref@mail.yahoo.com> <884828596.3127699.1503826809831@mail.yahoo.com> Message-ID: <7bd32878-2dfa-e453-8a5d-eabee11e1517@yandex.com> On 27/08/17 04:40, arznix via Gnupg-users wrote: > I am developing a closed mesh network application where > I want to encrypt the traffic using PGP. The local network > will have no access the the greater worldwide web so it > will not be able to access existing trusted Key Servers. If it is an isolated network, it is a small network. Maybe it will be more convenient to simply export all the keys the ordinary way (?gpg .--export KEY1 KEY2 ... KEYn? and distribute that through the network. > Any links to sample code would also be great. The system is being develop with > Linux as the operating system for the servers attached to the mesh network. Linux is a kernel. You mean the GNU/Linux operating system . -- Do not eat animals, respect them as you respect people. https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Sun Aug 27 16:29:39 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 27 Aug 2017 10:29:39 -0400 Subject: Newbie Question: Creating a Key Server using GNUPG tools In-Reply-To: <884828596.3127699.1503826809831@mail.yahoo.com> References: <884828596.3127699.1503826809831.ref@mail.yahoo.com> <884828596.3127699.1503826809831@mail.yahoo.com> Message-ID: <22e0ac49-9edc-0c12-4dba-7a1d8505203b@sixdemonbag.org> > It is unclear from the documentation for GNUPG and some of the supporting > writeups on other websites whether I can create a Key Server for the local > network that will generate public and private key pairs. This doesn't sound like any keyserver I've heard of. Normally keyservers only store copies of keys people give them, not create keypairs themselves. (Or perhaps you meant "that will generate public and private key pairs" to attach to the clause "the network", not "the Key Server"?) > Can anyone clarify whether it is possible to create a local Key Server using the > GNUPG tools? Not as you intend, no. From Roman.Fiedler at ait.ac.at Mon Aug 28 09:57:52 2017 From: Roman.Fiedler at ait.ac.at (Fiedler Roman) Date: Mon, 28 Aug 2017 07:57:52 +0000 Subject: Extraction of decryption session key without copying complete encrypted file Message-ID: <2ECE9D9EEF1F524185270138AE23265955ADA072@S0MSMAIL112.arc.local> > Von: Peter Lebbing [mailto:peter at digitalbrains.com] > > On 25/08/17 18:40, Fiedler Roman wrote: > > Idea: > > 1) Extract all GPG preambles of files to be decrypted to a single file > > (working) > > 2) Batch decrypt all preambles from the input file on the trusted > equipment > > (not working in batch mode) > > 3) Decrypt all storage elements with the list of session keys > (working) > > It doesn't sound like you need agent forwarding at all. I would expect > that you can decrypt with a session key without an agent, since the > agent is only consulted to get the session key, but you already have it. > > Step 2 is not working, but it is all on the system with the private key, > with a locally running agent. Dit you either gpg-preset-passphrase or > remove the passphrase from the key? The keys are currently software-only and have a passphrase consuming at least about 2 non-parallelizable CPU-seconds in the KDF for security - thus making repeated key entry a little slow. I will try the "gpg-preset-passphrase", which could be a valid workaround while all elements are encrypted with the same key - what will/should change as soon as new access control zones are attached to the system. > If the agent needs to prompt the > user with a pinentry, but there is no human since it is batch operation, > it will error out. So it needs to know the passphrase already or the > passphrase needs to be removed. I hoped, that there would be some way to still archive it, as the session key extraction script works on a batch of input elements, but the agent is started on a separate terminal, where the admin supervising the process can input passwords or provide the appropriate hardware tokens in future implementation. But it seems, that the gpg-decryption process attempts to trigger the pinentry, not the agent and so the access to the correct controlling TTY fails. > I think agent forwarding is an alternative to your idea, not a way to > implement it. With agent forwarding, the remote system without the > private key would ask the forwarded agent to decrypt the > public-key-encrypted-session-key for it and obtain the session key that > way and that would avoid all the extra steps. Provided it worked :-). Yes, that should work also. The different Linux-Distributions, GPG versions on the various machines might be a permanent source of trouble and also the process is not that straight forward: one should still extract all required session keys at once and use them later on - otherwise the admin holding the keys and the admin using the data have to work coordinated for hours until all elements are decrypted and used (e.g. restored). With session keys, the key holder performs the session key extraction on the list of requested elements (15min with connecting, selecting the elements, ...) and then forward the list of keys to the user. LG Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4814 bytes Desc: not available URL: From wk at gnupg.org Mon Aug 28 10:04:01 2017 From: wk at gnupg.org (Werner Koch) Date: Mon, 28 Aug 2017 10:04:01 +0200 Subject: benchmarking security tokens speed In-Reply-To: <87pobjcm2k.fsf@curie.anarc.at> ("Antoine =?utf-8?Q?Beaupr?= =?utf-8?Q?=C3=A9=22's?= message of "Fri, 25 Aug 2017 18:35:47 -0400") References: <87pobjcm2k.fsf@curie.anarc.at> Message-ID: <874lssktji.fsf@wheatstone.g10code.de> On Sat, 26 Aug 2017 00:35, lwn at anarc.at said: > I'm in the process of reviewing performance of various security tokens > (the Yubikeys, the FST-01, Nitrokey), and I am getting somewhat Thanks for the numbers. However, the numbers Nitrokey are are missing. Shall I send you a "standard" Zeitcontrol card, which is probably the most widely used device and also what is crunching the numbers in a Nitrokey? The numbers are as expected. With a crypto chip RSA is much faster. By design the Gnuk can't be as fast - it is just a simple MCU. However, using Curve25519 Gnuk is really fast. 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: 227 bytes Desc: not available URL: From peter at digitalbrains.com Mon Aug 28 12:00:17 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 28 Aug 2017 12:00:17 +0200 Subject: Extraction of decryption session key without copying complete encrypted file In-Reply-To: <2ECE9D9EEF1F524185270138AE23265955ADA072@S0MSMAIL112.arc.local> References: <2ECE9D9EEF1F524185270138AE23265955ADA072@S0MSMAIL112.arc.local> Message-ID: <7cfadd2e-7fc9-0191-5a9a-b8d2a06f03a6@digitalbrains.com> On 28/08/17 09:57, Fiedler Roman wrote: > But it seems, that the gpg-decryption process attempts to trigger the > pinentry, not the agent and so the access to the correct controlling TTY > fails. The gpg process communicates its TTY to the agent so the pinentry knows where to pop up. This is a feature, not a bug. But when you deliberately want to pop it up elsewhere... I almost had it working in a test: - Start an x-terminal, invoke "tty" and see that it is /dev/pts/7. Start another x-terminal and: $ unset DISPLAY $ export GPG_TTY=/dev/pts/7 $ echo test | gpg -o /dev/null -s And indeed the pinentry-curses popped up on the other terminal. BUT: a few of my keystrokes went to the bash shell that was running there instead of the popped up pinentry. So the passphrase I entered in the pinentry was missing characters, and those characters were typed as part of a command on the command line. So my idea that GPG_TTY would override the terminal was correct, but it didn't actually work in the end. It seems that it's easier if you use a graphical pinentry, by just overriding DISPLAY in the session where the batch runs. > Yes, that should work also. The different Linux-Distributions, GPG versions on > the various machines might be a permanent source of trouble Well, agent forwarding to access a remote private key only works on GnuPG 2.1 (and later, once later exists). In general, mixing versions is not a good idea, no, not even between minor versions. But possibly this restriction is less stringent for the forwarded socket, because I expect there it will be common to mix versions. It might have been designed to account for this. > and also the > process is not that straight forward: one should still extract all required > session keys at once and use them later on - otherwise the admin holding the > keys and the admin using the data have to work coordinated for hours until all > elements are decrypted and used (e.g. restored). With session keys, the key > holder performs the session key extraction on the list of requested elements > (15min with connecting, selecting the elements, ...) and then forward the list > of keys to the user. You should consider whether you should use a passphrase at all. Usually, with unattended decryption, it's just bothersome. The passphrase protects the key at rest. If you're worried about attackers getting access to a backup, you could do the gpg-preset-passphrase dance. If an attacker that gets the privileges to read the contents of your private key dir is not part of your threat model (for instance, because it's game over), you might as well remove the passphrase and be done with this bothersome pinentry stuff, as FAQ entry 8.20 [1] says. The admin that is submitting a list of PKESK packets already effectively has unfettered access to your decryption key as far as usage is concerned, no need to worry about them. And using just a forwarded agent connection, they still have no access to the key material. HTH, Peter. [1] -- 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 justin.chiu at cern.ch Mon Aug 28 03:12:28 2017 From: justin.chiu at cern.ch (Justin Chiu) Date: Sun, 27 Aug 2017 18:12:28 -0700 Subject: Do not cache smart card PIN Message-ID: <855210ce-5265-2dbc-be7e-c77c376d4eaf@cern.ch> Hi, Is it possible to instruct a smart card to not cache its PIN or have GnuPG forcibly clear the PIN cache? My understanding is that the PIN is cached internally [1] unless if you enable "forcesig" (which only applies to signing operations). If this caching by the smart card cannot be turned off for encryption and authentication as well, then perhaps it is possible to configure GnuPG to clear the smart card's PIN cache after every operation? Thanks, Justin [1] https://lists.gnupg.org/pipermail/gnupg-users/2006-September/029321.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Mon Aug 28 12:50:11 2017 From: wk at gnupg.org (Werner Koch) Date: Mon, 28 Aug 2017 12:50:11 +0200 Subject: Extraction of decryption session key without copying complete encrypted file In-Reply-To: <7cfadd2e-7fc9-0191-5a9a-b8d2a06f03a6@digitalbrains.com> (Peter Lebbing's message of "Mon, 28 Aug 2017 12:00:17 +0200") References: <2ECE9D9EEF1F524185270138AE23265955ADA072@S0MSMAIL112.arc.local> <7cfadd2e-7fc9-0191-5a9a-b8d2a06f03a6@digitalbrains.com> Message-ID: <87ziakj7a4.fsf@wheatstone.g10code.de> On Mon, 28 Aug 2017 12:00, peter at digitalbrains.com said: > The gpg process communicates its TTY to the agent so the pinentry knows > where to pop up. This is a feature, not a bug. But when you deliberately > want to pop it up elsewhere... If you don't want that feature the --keep-tty and --keep-display options for gpg-agent may be useful: Ignore requests to change the current tty or X window system's DISPLAY variable respectively. This is useful to lock the pinentry to pop up at the tty or display you started the agent. That feature was once implemented for a user who liked to keep the pinentry popping up in fixed screen(1) session. 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: 227 bytes Desc: not available URL: From peter at digitalbrains.com Mon Aug 28 13:17:17 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 28 Aug 2017 13:17:17 +0200 Subject: pinentry-curses competing over tty (was: Extraction of decryption session key without copying complete encrypted file) In-Reply-To: <87ziakj7a4.fsf@wheatstone.g10code.de> References: <2ECE9D9EEF1F524185270138AE23265955ADA072@S0MSMAIL112.arc.local> <7cfadd2e-7fc9-0191-5a9a-b8d2a06f03a6@digitalbrains.com> <87ziakj7a4.fsf@wheatstone.g10code.de> Message-ID: On 28/08/17 12:50, Werner Koch wrote: > If you don't want that feature the --keep-tty and --keep-display options > for gpg-agent may be useful: Those options had slipped my mind... Thanks! Werner, do you know why the bash shell that was running on the X terminal where pinentry-curses popped up received several of the keypresses that were intended to go to the pinentry? If I use the passphrase abcdefghijkl, the entry line in the dialog looks like this: *b*d*f**i*k* Pinentry got the wrong passphrase, and when I get back to the shell and press Enter, bash tells me: bash: bdfik: command not found My impression is that both bash and pinentry-curses are reading from the keyboard input, and it is up to chance who gets the keypress. Pinentry echoes '*' on a keypress, and bash echoes the entered character. I've seen this before when I used a terminal-based pinentry and I did an ssh without first doing an updatestartuptty. Is pinentry-curses doing all it should to grab the terminal? Oh, and while I have your attention (I hope :-), is the extra-socket suitable for sharing with a host running a different version of GnuPG 2.1 or later? It seems useful, in a heterogeneous setting with distribution-provided GnuPG binaries. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From Roman.Fiedler at ait.ac.at Mon Aug 28 14:00:02 2017 From: Roman.Fiedler at ait.ac.at (Fiedler Roman) Date: Mon, 28 Aug 2017 12:00:02 +0000 Subject: Extraction of decryption session key without copying complete encrypted file Message-ID: <2ECE9D9EEF1F524185270138AE23265955ADA2CF@S0MSMAIL112.arc.local> > Von: Werner Koch [mailto:wk at gnupg.org] > > On Mon, 28 Aug 2017 12:00, peter at digitalbrains.com said: > > > The gpg process communicates its TTY to the agent so the pinentry > knows > > where to pop up. This is a feature, not a bug. But when you > deliberately > > want to pop it up elsewhere... > > If you don't want that feature the --keep-tty and --keep-display options > for gpg-agent may be useful: > > Ignore requests to change the current tty or X window system's > DISPLAY variable respectively. This is useful to lock the pinentry > to pop up at the tty or display you started the agent. > > That feature was once implemented for a user who liked to keep the > pinentry popping up in fixed screen(1) session. Thanks for the hint. Just for reference: with all the suggestions from you and Peter, I have created following script which performs all steps as expected: tmpDir="$(mktemp -d)" screen -S GpgAgent -d -m -- gpg-agent --homedir "${GpgHomeDir}" --daemon --log-file "${tmpDir}/agent.log" --allow-loopback-pinentry --pinentry-program /usr/bin/pinentry --debug-pinentry --keep-tty --debug-all --daemon --no-detach /bin/sleep 100000 sleep 1 GpgHomeDir="${GpgHomeDir}" tmpDir="${tmpDir}" screen -S Decryptor -d -m -- /bin/bash -c 'cat decryptlist.txt | ( cd "${tmpDir}" gpgAgentPid="$(grep -E -e "^[0-9-]{10} [0-9:]{8} gpg-agent\\[[0-9]+\\] gpg-agent .* started\$" -- "${tmpDir}/agent.log" | tail -n 1 | sed -r -e "s/^.* gpg-agent\\[([0-9]+)\\] .*/\\1/")" while read -r fileName gpgPreamble; do echo "Extracting key from ${fileName}" echo "${gpgPreamble}" | base64 -d | gpgsplit (cat 000001-001.pk_enc; echo "0gsBAAAAAAAAAAAAAA==" | base64 -d) | GPG_AGENT_INFO="${GpgHomeDir}/S.gpg-agent:${gpgAgentPid}:1" gpg --use-agent --homedir "${GpgHomeDir}" --show-session-key done) 2>&1 | tee decryptlist.log' screen -R GpgAgent -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4814 bytes Desc: not available URL: From wk at gnupg.org Mon Aug 28 13:51:11 2017 From: wk at gnupg.org (Werner Koch) Date: Mon, 28 Aug 2017 13:51:11 +0200 Subject: [Announce] GnuPG 2.2.0 released Message-ID: <87r2vvkj0w.fsf@wheatstone.g10code.de> Hello! Arguing that you don't care about the right to privacy because you have nothing to hide is no different from saying you don't care about free speech because you have nothing to say. - Edward Snowden The GnuPG team is pleased to announce the availability of a new release of GnuPG: version 2.2.0. See below for a list of new features and bug fixes. This release marks the start of a new long term support series to replace the 2.0.x series which will reach end-of-life on 2017-12-31. 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. As an Universal Crypto Engine 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. Noteworthy changes in version 2.2.0 =================================== This is the new long term stable branch. This branch will only see bug fixes and no new features. * gpg: Reverted change done in 2.1.23 so that --no-auto-key-retrieve is again the default. * Fixed a few minor bugs. This release incorporates all changes from the 2.1 series including these from the release candidate 2.1.23: * gpg: "gpg" is now installed as "gpg" and not anymore as "gpg2". If needed, the new configure option --enable-gpg-is-gpg2 can be used to revert this. * gpg: Option --auto-key-locate "local,wkd" is now used by default. Note: this enables keyserver and Web Key Directory operators to notice when you intend to encrypt to a mail address without having the key locally. This new behaviour will eventually make key discovery much easier and mostly automatic. Disable this by adding auto-key-locate local to your gpg.conf. [This description has been adjusted to include the above mentioned change in 2.2.0] * agent: Option --no-grab is now the default. The new option --grab allows to revert this. * gpg: New import option "show-only". * gpg: New option --disable-dirmngr to entirely disable network access for gpg. * gpg,gpgsm: Tweaked DE-VS compliance behaviour. * New configure flag --enable-all-tests to run more extensive tests during "make check". * gpgsm: The keygrip is now always printed in colon mode as documented in the man page. * Fixed connection timeout problem under Windows. A detailed description of the changes in the 2.2 (formerly 2.1) branch can be found at . Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.2.0 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: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.0.tar.bz2 (6379k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.0.tar.bz2.sig An installer for Windows without any graphical frontend except for a very minimal Pinentry tool is available here: https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.0_20170828.exe (3797k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.0_20170828.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. A new release candidate for Gpg4win featuring this version of GnuPG will be available in a few days. 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.2.0.tar.bz2 you would use this command: gpg --verify gnupg-2.2.0.tar.bz2.sig gnupg-2.2.0.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.2.0.tar.bz2, you run the command like this: sha1sum gnupg-2.2.0.tar.bz2 and check that the output matches the next line: 36ee693d0b2ec529ecf53dd6d397cc38ba71c0a7 gnupg-2.2.0.tar.bz2 7b0cf3912b86a6bd7655026276984a34a248e625 gnupg-w32-2.2.0_20170828.exe 0997499bdc6edfa43e2ce3d2cda9de00ecbc369d gnupg-w32-2.2.0_20170828.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. 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 4 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 for financing the project. Special thanks to Neal and Justus for all their valuable work. Happy hacking, Your GnuPG Team 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 five keys: 2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31] Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 Werner Koch (Release Signing Key) rsa3072/4B092E28 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (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 BCEF7E294B092E28 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 daniele at grinta.net Mon Aug 28 16:53:49 2017 From: daniele at grinta.net (Daniele Nicolodi) Date: Mon, 28 Aug 2017 08:53:49 -0600 Subject: --export-options export-reset-subkey-passwd In-Reply-To: <87mv6pqzdu.fsf@wheatstone.g10code.de> References: <6308661f-1769-3e76-84d4-b25168688cf6@grinta.net> <87mv6pqzdu.fsf@wheatstone.g10code.de> Message-ID: Hello Werner, On 8/23/17 11:59 PM, Werner Koch wrote: > On Sun, 13 Aug 2017 08:17, daniele at grinta.net said: > >> Digging a bit more, it seems that the functionality got dropped because >> with GnuPG 2.x all key manipulations go through gpg-agent and it does >> not (yet?) support password reset on expert. > > Unfortunately this is still an open bug: > > https://dev.gnupg.org/T1753 > > we won't be able to fix it for 2.2.0 but given that it is marked as a > bug it can and should be fixed in the soon to be release 2.2 series. I would like to help get this fix. What is the plan to implement it? Thanks. Cheers, Daniele From lwn at anarc.at Mon Aug 28 15:05:38 2017 From: lwn at anarc.at (=?utf-8?Q?Antoine_Beaupr=C3=A9?=) Date: Mon, 28 Aug 2017 09:05:38 -0400 Subject: benchmarking security tokens speed In-Reply-To: <874lssktji.fsf@wheatstone.g10code.de> References: <87pobjcm2k.fsf@curie.anarc.at> <874lssktji.fsf@wheatstone.g10code.de> Message-ID: <874lsrdeql.fsf@curie.anarc.at> On 2017-08-28 10:04:01, Werner Koch wrote: > On Sat, 26 Aug 2017 00:35, lwn at anarc.at said: > >> I'm in the process of reviewing performance of various security tokens >> (the Yubikeys, the FST-01, Nitrokey), and I am getting somewhat > > Thanks for the numbers. However, the numbers Nitrokey are are missing. > Shall I send you a "standard" Zeitcontrol card, which is probably the > most widely used device and also what is crunching the numbers in a > Nitrokey? Sure, although I'm in contact with the Nitrokey people to get a "nitrokey pro" from them. Getting wider coverage would of course be better! > The numbers are as expected. With a crypto chip RSA is much faster. By > design the Gnuk can't be as fast - it is just a simple MCU. However, > using Curve25519 Gnuk is really fast. Yes. In my tests it's faster at doing ECC encryption than the Yubikey 4 in RSA 2048, and only about 4 times slower than the system CPU, which is amazing. Thanks for your response! A. -- Antoine Beaupr? LWN.net From s7r at sky-ip.org Mon Aug 28 22:58:49 2017 From: s7r at sky-ip.org (s7r) Date: Mon, 28 Aug 2017 23:58:49 +0300 Subject: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key) Message-ID: <6ed43218-b56d-be68-86a5-3aee7a177daa@sky-ip.org> Hi list, Please help me with some information and hints. 1. Is it possible, when transporting a message from Alice to Bob, without holding any of their private keys, to do the following checks: - verify the integrity of the message and make sure it is sanitized and Bob can decrypt it with his private key; - verify that the message was encrypted for Bob and not for anyone else (Alice didn't mix recipients by mistake); 2. Is it possible to have just one key (the primary one, no subkey) with E flag also (S,C,E) -- I know this is not recommended but this is a particular use case and the risks are acknowledged. I guess gnupg will not allow you to do this by default, but is there any magic that can be done? 3. Is it possible to import a secp256k1 private key and use it? For example a secp256k1 key in the following format: 0C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D How could this be imported in gnupg? 4. Is there a way to skip the passphrase entirely and not encrypt the private key at all? Thanks. -------------- 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 Tue Aug 29 01:05:23 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 28 Aug 2017 19:05:23 -0400 Subject: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key) In-Reply-To: <6ed43218-b56d-be68-86a5-3aee7a177daa@sky-ip.org> References: <6ed43218-b56d-be68-86a5-3aee7a177daa@sky-ip.org> Message-ID: <00cb6ddf-c597-e985-bbeb-09e0596c52a6@sixdemonbag.org> > 1. Is it possible, when transporting a message from Alice to Bob, > without holding any of their private keys, to do the following checks: > - verify the integrity of the message and make sure it is sanitized and > Bob can decrypt it with his private key; No. You can check the format of the message and ensure it's not mangled, but that's about it. A loose proof of this follows: GnuPG only uses asymmetric crypto to encrypt the session key(s) for a message. The message itself is encrypted with a symmetric cipher using a randomly-generated key. A key principle of symmetric ciphers is the output of that cipher should be indistinguishable from random noise. So you have a message you're couriering. To you, it appears to be random noise. How do you do message integrity on random noise? If you can distinguish correct from incorrect encrypted data, then clearly you're able to discern information about the underlying message, which contradicts the given that the data you're looking at is indistinguishable from random noise. You might be able to attach a SHA256 of the encrypted data packet, but that only tells you if you're carrying the encrypted data packet the sender intended -- it doesn't tell you a thing about whether the *decrypted* message will be sensible to Bob. So no. Can't do this, sorry. You can check the message format to make sure all the packets are well-formed and make sense, but you can't do more than that. Only the message recipient can. > - verify that the message was encrypted for Bob and not for anyone else > (Alice didn't mix recipients by mistake); Kind of, by checking the message format. > 2. Is it possible to have just one key (the primary one, no subkey) with > E flag also (S,C,E) -- I know this is not recommended but this is a > particular use case and the risks are acknowledged. I guess gnupg will > not allow you to do this by default, but is there any magic that can be > done? Yes. > 3. Is it possible to import a secp256k1 private key and use it? For > example a secp256k1 key in the following format: Dunno. > 4. Is there a way to skip the passphrase entirely and not encrypt the > private key at all? Yes, but this is usually spectacularly unwise. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 821 bytes Desc: OpenPGP digital signature URL: From s7r at sky-ip.org Tue Aug 29 01:38:21 2017 From: s7r at sky-ip.org (s7r) Date: Tue, 29 Aug 2017 02:38:21 +0300 Subject: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key) In-Reply-To: <00cb6ddf-c597-e985-bbeb-09e0596c52a6@sixdemonbag.org> References: <6ed43218-b56d-be68-86a5-3aee7a177daa@sky-ip.org> <00cb6ddf-c597-e985-bbeb-09e0596c52a6@sixdemonbag.org> Message-ID: <11ed05d9-8335-29b1-ad08-3e5740b249b5@sky-ip.org> Thanks for the reply. See inline, Robert J. Hansen wrote: >> 1. Is it possible, when transporting a message from Alice to Bob, >> without holding any of their private keys, to do the following checks: >> - verify the integrity of the message and make sure it is sanitized and >> Bob can decrypt it with his private key; [SNIP] > So no. Can't do this, sorry. You can check the message format to make > sure all the packets are well-formed and make sense, but you can't do > more than that. Only the message recipient can. > >> - verify that the message was encrypted for Bob and not for anyone else >> (Alice didn't mix recipients by mistake); > > Kind of, by checking the message format. > If I have the public key of the recipient, I should be able to tell that a message was encrypted for that public key, except I am missing the private key to decrypt it. If I can check the message format I should be able to check this as well. How would I do this with gnupg? >> 2. Is it possible to have just one key (the primary one, no subkey) with >> E flag also (S,C,E) -- I know this is not recommended but this is a >> particular use case and the risks are acknowledged. I guess gnupg will >> not allow you to do this by default, but is there any magic that can be >> done? > > Yes. > How? I tried in expert mode but didn't manage. -------------- 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 Tue Aug 29 01:47:49 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 28 Aug 2017 19:47:49 -0400 Subject: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key) In-Reply-To: <20170828234239.GA4412@tower.spodhuis.org> References: <6ed43218-b56d-be68-86a5-3aee7a177daa@sky-ip.org> <00cb6ddf-c597-e985-bbeb-09e0596c52a6@sixdemonbag.org> <20170828234239.GA4412@tower.spodhuis.org> Message-ID: > Well, you can go one step further. Unless the sender is throwing the > key ids, you can look to see which keyids are given as hints in the > outermost layer, to see which people are expected to be able to decrypt > it. Sure, but this is a heuristic, not a formal verification. A useful heuristic, absolutely, but this is still at the level of "let's look at the packets to glean publicly available data" -- whereas message sanitization and verification would require access to the content of the message. Part of this is, I think, the OP is being a little handwavy with the idea of verification/sanitization. If what you're checking is dependent in any way on the cleartext, then you're screwed. And if what you're checking is dependent on the ciphertext, you're not really dealing with the message at all, but the container it's packaged into. From rjh at sixdemonbag.org Tue Aug 29 01:51:40 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 28 Aug 2017 19:51:40 -0400 Subject: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key) In-Reply-To: <11ed05d9-8335-29b1-ad08-3e5740b249b5@sky-ip.org> References: <6ed43218-b56d-be68-86a5-3aee7a177daa@sky-ip.org> <00cb6ddf-c597-e985-bbeb-09e0596c52a6@sixdemonbag.org> <11ed05d9-8335-29b1-ad08-3e5740b249b5@sky-ip.org> Message-ID: > If I have the public key of the recipient, I should be able to tell that > a message was encrypted for that public key, except I am missing the > private key to decrypt it. If I can check the message format I should be > able to check this as well. How would I do this with gnupg? --list-packets >>> 2. Is it possible to have just one key (the primary one, no subkey) with >>> E flag also (S,C,E) -- I know this is not recommended but this is a >>> particular use case and the risks are acknowledged. I guess gnupg will >>> not allow you to do this by default, but is there any magic that can be >>> done? >> >> Yes. >> > > How? I tried in expert mode but didn't manage. --expert --full-generate-key Options 8 or 11 should work for you. Haven't verified it. From s7r at sky-ip.org Tue Aug 29 02:08:22 2017 From: s7r at sky-ip.org (s7r) Date: Tue, 29 Aug 2017 03:08:22 +0300 Subject: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key) In-Reply-To: References: <6ed43218-b56d-be68-86a5-3aee7a177daa@sky-ip.org> <00cb6ddf-c597-e985-bbeb-09e0596c52a6@sixdemonbag.org> <20170828234239.GA4412@tower.spodhuis.org> Message-ID: <97d17160-b906-7859-25bd-89cccab0fee6@sky-ip.org> Robert J. Hansen wrote: >> Well, you can go one step further. Unless the sender is throwing the >> key ids, you can look to see which keyids are given as hints in the >> outermost layer, to see which people are expected to be able to decrypt >> it. > > Sure, but this is a heuristic, not a formal verification. A useful > heuristic, absolutely, but this is still at the level of "let's look at > the packets to glean publicly available data" -- whereas message > sanitization and verification would require access to the content of the > message. > > Part of this is, I think, the OP is being a little handwavy with the > idea of verification/sanitization. If what you're checking is dependent > in any way on the cleartext, then you're screwed. And if what you're > checking is dependent on the ciphertext, you're not really dealing with > the message at all, but the container it's packaged into. > Yes, what needs to be checked is dependent on the cipher text. Only if the message has all the packets and theoretically can be decrypted (if the recipient has the private key). It does not matter if the cleartext makes sense to the recipient or not. "look to see which keyids are given as hints in the outermost layer" -- not sure I understand here. I am trying to do a check that is natively supported by gnupg. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From s7r at sky-ip.org Tue Aug 29 02:11:29 2017 From: s7r at sky-ip.org (s7r) Date: Tue, 29 Aug 2017 03:11:29 +0300 Subject: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key) In-Reply-To: References: <6ed43218-b56d-be68-86a5-3aee7a177daa@sky-ip.org> <00cb6ddf-c597-e985-bbeb-09e0596c52a6@sixdemonbag.org> <11ed05d9-8335-29b1-ad08-3e5740b249b5@sky-ip.org> Message-ID: <978bdedc-9500-40fd-e6e2-12ed4ec705eb@sky-ip.org> Robert J. Hansen wrote: >>>> 2. Is it possible to have just one key (the primary one, no subkey) with >>>> E flag also (S,C,E) -- I know this is not recommended but this is a >>>> particular use case and the risks are acknowledged. I guess gnupg will >>>> not allow you to do this by default, but is there any magic that can be >>>> done? >>> >>> Yes. >>> >> >> How? I tried in expert mode but didn't manage. > > --expert --full-generate-key > > Options 8 or 11 should work for you. Haven't verified it. Tried both of them, not working. They only produce a single primary key (8 RSA or 11 ECC) with S,C capabilities (without E). I have even generated it normally (primary key with capabilities S,C + subkey with E capability) and tried to edit the key after that, by deleting the subkey and trying to toggle the capabilities of the primary key but E is not a valid option to select as capability for the primary key. -------------- 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 Tue Aug 29 02:21:41 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 28 Aug 2017 20:21:41 -0400 Subject: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key) In-Reply-To: <978bdedc-9500-40fd-e6e2-12ed4ec705eb@sky-ip.org> References: <6ed43218-b56d-be68-86a5-3aee7a177daa@sky-ip.org> <00cb6ddf-c597-e985-bbeb-09e0596c52a6@sixdemonbag.org> <11ed05d9-8335-29b1-ad08-3e5740b249b5@sky-ip.org> <978bdedc-9500-40fd-e6e2-12ed4ec705eb@sky-ip.org> Message-ID: <073b5c2a-ba3c-e8d0-c679-4fe58236809c@sixdemonbag.org> > Tried both of them, not working. They only produce a single primary key > (8 RSA or 11 ECC) with S,C capabilities (without E). *shrugs* Do better. Seriously, if you literally choose option 8 and just go through the defaults you'll get a single primary key with an encrypt capability. ===== quorra:~ rjh$ gpg --expert --full-generate-key Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) (7) DSA (set your own capabilities) (8) RSA (set your own capabilities) (9) ECC and ECC (10) ECC (sign only) (11) ECC (set your own capabilities) (13) Existing key Your selection? 8 Possible actions for a RSA key: Sign Certify Encrypt Authenticate Current allowed actions: Sign Certify Encrypt (S) Toggle the sign capability (E) Toggle the encrypt capability (A) Toggle the authenticate capability (Q) Finished Your selection? q RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) Requested keysize is 2048 bits Please specify how long the key should be valid. 0 = key does not expire = key expires in n days w = key expires in n weeks m = key expires in n months y = key expires in n years Key is valid for? (0) Key does not expire at all Is this correct? (y/N) y GnuPG needs to construct a user ID to identify your key. Real name: Delete Me Email address: delete.me at example.com Comment: You selected this USER-ID: "Delete Me " Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. gpg: key FD87EA81A2F00BA1 marked as ultimately trusted gpg: revocation certificate stored as '/Users/rjh/.gnupg/openpgp-revocs.d/6DBE635236A542524E7D950FFD87EA81A2F00BA1.rev' public and secret key created and signed. pub rsa2048/FD87EA81A2F00BA1 2017-08-29 [SCE] 6DBE635236A542524E7D950FFD87EA81A2F00BA1 uid Delete Me -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 821 bytes Desc: OpenPGP digital signature URL: From s7r at sky-ip.org Tue Aug 29 02:23:25 2017 From: s7r at sky-ip.org (s7r) Date: Tue, 29 Aug 2017 03:23:25 +0300 Subject: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key) In-Reply-To: <073b5c2a-ba3c-e8d0-c679-4fe58236809c@sixdemonbag.org> References: <6ed43218-b56d-be68-86a5-3aee7a177daa@sky-ip.org> <00cb6ddf-c597-e985-bbeb-09e0596c52a6@sixdemonbag.org> <11ed05d9-8335-29b1-ad08-3e5740b249b5@sky-ip.org> <978bdedc-9500-40fd-e6e2-12ed4ec705eb@sky-ip.org> <073b5c2a-ba3c-e8d0-c679-4fe58236809c@sixdemonbag.org> Message-ID: Robert J. Hansen wrote: >> Tried both of them, not working. They only produce a single primary key >> (8 RSA or 11 ECC) with S,C capabilities (without E). > > *shrugs* Do better. Seriously, if you literally choose option 8 and > just go through the defaults you'll get a single primary key with an > encrypt capability. > It works with a RSA key, but not with ECC. Try with secp256k1 and you'll only get Sign and Certify capabilities. At least this is what happens on my side. -------------- 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 Tue Aug 29 02:42:26 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 28 Aug 2017 20:42:26 -0400 Subject: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key) In-Reply-To: References: <6ed43218-b56d-be68-86a5-3aee7a177daa@sky-ip.org> <00cb6ddf-c597-e985-bbeb-09e0596c52a6@sixdemonbag.org> <11ed05d9-8335-29b1-ad08-3e5740b249b5@sky-ip.org> <978bdedc-9500-40fd-e6e2-12ed4ec705eb@sky-ip.org> <073b5c2a-ba3c-e8d0-c679-4fe58236809c@sixdemonbag.org> Message-ID: > It works with a RSA key, but not with ECC. Try with secp256k1 and you'll > only get Sign and Certify capabilities. At least this is what happens on > my side. I apologize for sounding like I'm condescending here: it's not my intent. However, there are very important things you are apparently not quite understanding, so I'm going to be excruciatingly clear. A primary key must have the Certify capability -- it's used to certify the subkeys, after all. This means algorithms which can only encrypt cannot serve as a primary key. ECC algorithms come in two varieties: ones that can sign (EdDSA, ECDSA) and ones that can encrypt (the rest). So if you insist on using ECC, you must use EdDSA or ECDSA as the primary key. Which means your primary key cannot encrypt. RSA does not have this limitation. RSA can be used for signing and encrypting. This is why my example used RSA. Use RSA. From s7r at sky-ip.org Tue Aug 29 02:56:51 2017 From: s7r at sky-ip.org (s7r) Date: Tue, 29 Aug 2017 03:56:51 +0300 Subject: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key) In-Reply-To: References: <6ed43218-b56d-be68-86a5-3aee7a177daa@sky-ip.org> <00cb6ddf-c597-e985-bbeb-09e0596c52a6@sixdemonbag.org> <11ed05d9-8335-29b1-ad08-3e5740b249b5@sky-ip.org> <978bdedc-9500-40fd-e6e2-12ed4ec705eb@sky-ip.org> <073b5c2a-ba3c-e8d0-c679-4fe58236809c@sixdemonbag.org> Message-ID: Robert J. Hansen wrote: >> It works with a RSA key, but not with ECC. Try with secp256k1 and you'll >> only get Sign and Certify capabilities. At least this is what happens on >> my side. > > I apologize for sounding like I'm condescending here: it's not my > intent. However, there are very important things you are apparently not > quite understanding, so I'm going to be excruciatingly clear. > > A primary key must have the Certify capability -- it's used to certify > the subkeys, after all. > > This means algorithms which can only encrypt cannot serve as a primary key. > > ECC algorithms come in two varieties: ones that can sign (EdDSA, ECDSA) > and ones that can encrypt (the rest). > > So if you insist on using ECC, you must use EdDSA or ECDSA as the > primary key. > > Which means your primary key cannot encrypt. > > RSA does not have this limitation. RSA can be used for signing and > encrypting. > > This is why my example used RSA. > > Use RSA. It is not a problem at all. Thanks for the feedback and your time, really appreciate it. Unfortunately, I do need secp256k1 as the encryption key, this is the reason I am asking if it can be done or not, if I could use RSA I would not even ask, I am using RSA for so many years. The thing is, if I create an ECC (ECDSA) secp256k1 primary key with Sign, Certify capabilities I can also create a subkey with E capability which is also a secp256k1 key. So, they can be used for encryption after all, so why can't I just add E capability to the primary one.. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From gnupg-users at spodhuis.org Tue Aug 29 01:42:40 2017 From: gnupg-users at spodhuis.org (Phil Pennock) Date: Mon, 28 Aug 2017 19:42:40 -0400 Subject: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key) In-Reply-To: <00cb6ddf-c597-e985-bbeb-09e0596c52a6@sixdemonbag.org> References: <6ed43218-b56d-be68-86a5-3aee7a177daa@sky-ip.org> <00cb6ddf-c597-e985-bbeb-09e0596c52a6@sixdemonbag.org> Message-ID: <20170828234239.GA4412@tower.spodhuis.org> On 2017-08-28 at 19:05 -0400, Rob J Hansen wrote: > > 1. Is it possible, when transporting a message from Alice to Bob, > > without holding any of their private keys, to do the following checks: > > - verify the integrity of the message and make sure it is sanitized and > > Bob can decrypt it with his private key; > > No. You can check the format of the message and ensure it's not > mangled, but that's about it. A loose proof of this follows: Well, you can go one step further. Unless the sender is throwing the key ids, you can look to see which keyids are given as hints in the outermost layer, to see which people are expected to be able to decrypt it. In `gpg --list-packets` output, that will be the `:pubkey enc packet:` items. GNUPGHOME=/nonexistent gpg --batch --list-packets < "${INPUT_FN:?}" It won't confirm that Bob _can_ decrypt it, since that goes into a lot of assumptions about competence, not lost keys, possession of devices, whatever. But in normal use, it'll tell you if Bob should be able to decrypt it. Privacy-sensitive environments concerned about metadata analysis will set the `throw-keyids` option in their config and that would prevent this. -Phil From rjh at sixdemonbag.org Tue Aug 29 05:27:11 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 28 Aug 2017 23:27:11 -0400 Subject: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key) In-Reply-To: References: <6ed43218-b56d-be68-86a5-3aee7a177daa@sky-ip.org> <00cb6ddf-c597-e985-bbeb-09e0596c52a6@sixdemonbag.org> <11ed05d9-8335-29b1-ad08-3e5740b249b5@sky-ip.org> <978bdedc-9500-40fd-e6e2-12ed4ec705eb@sky-ip.org> <073b5c2a-ba3c-e8d0-c679-4fe58236809c@sixdemonbag.org> Message-ID: <9639e84f-523f-4ae0-e50a-528b99df8ee6@sixdemonbag.org> > The thing is, if I create an ECC (ECDSA) secp256k1 primary key with > Sign, Certify capabilities I can also create a subkey with E > capability which is also a secp256k1 key. So, they can be used for > encryption after all, so why can't I just add E capability to the > primary one. You're confusing the field of numbers in which an algorithm operates with the algorithm itself. It's like confusing a sports car with a tour bus, thinking that since they run on the same roads they're interchangeable. secp256k1 is a certain field of numbers in which elliptical curve operations may be defined. It is not an algorithm. You do not have a secp256k1 key. You have an ECDSA key which operates in the curve defined by secp256k1. When you "create a subkey with E capability", you're creating an ECDH subkey operating in secp256k1. It's a completely different algorithm that happens to operate in the same numerical space. Different cars, different capabilities, same roads; different keys, different capabilities, same curve. ECDSA/EdDSA cannot encrypt. ECDH cannot sign or certify. Your primary key must be able to make certifications. So that means if you want to use ECC, your primary key must be ECDSA/EdDSA, and you will never be able to make it into an encryption-capable primary key. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 821 bytes Desc: OpenPGP digital signature URL: From s7r at sky-ip.org Tue Aug 29 09:14:35 2017 From: s7r at sky-ip.org (s7r) Date: Tue, 29 Aug 2017 10:14:35 +0300 Subject: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key) In-Reply-To: <20170828234239.GA4412@tower.spodhuis.org> References: <6ed43218-b56d-be68-86a5-3aee7a177daa@sky-ip.org> <00cb6ddf-c597-e985-bbeb-09e0596c52a6@sixdemonbag.org> <20170828234239.GA4412@tower.spodhuis.org> Message-ID: Phil Pennock wrote: > On 2017-08-28 at 19:05 -0400, Rob J Hansen wrote: >>> 1. Is it possible, when transporting a message from Alice to Bob, >>> without holding any of their private keys, to do the following checks: >>> - verify the integrity of the message and make sure it is sanitized and >>> Bob can decrypt it with his private key; >> >> No. You can check the format of the message and ensure it's not >> mangled, but that's about it. A loose proof of this follows: > > Well, you can go one step further. Unless the sender is throwing the > key ids, you can look to see which keyids are given as hints in the > outermost layer, to see which people are expected to be able to decrypt > it. > > In `gpg --list-packets` output, that will be the `:pubkey enc packet:` > items. > > GNUPGHOME=/nonexistent gpg --batch --list-packets < "${INPUT_FN:?}" > > It won't confirm that Bob _can_ decrypt it, since that goes into a lot > of assumptions about competence, not lost keys, possession of devices, > whatever. But in normal use, it'll tell you if Bob should be able to > decrypt it. > > Privacy-sensitive environments concerned about metadata analysis will > set the `throw-keyids` option in their config and that would prevent > this. > > -Phil > Hi Phil, Thanks - this is indeed _very_ useful for my use case. I don't think the second part is a problem since I can particularly request to not set the `throw-keyids` option, but let's say metadata becomes a problem at a given point and we decide to use this option, can I tell which recipient 'should' be able to decrypt a message based only on the encrypted message format if the `throw-keyids` option was used? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From s7r at sky-ip.org Tue Aug 29 09:09:50 2017 From: s7r at sky-ip.org (s7r) Date: Tue, 29 Aug 2017 10:09:50 +0300 Subject: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key) In-Reply-To: <9639e84f-523f-4ae0-e50a-528b99df8ee6@sixdemonbag.org> References: <6ed43218-b56d-be68-86a5-3aee7a177daa@sky-ip.org> <00cb6ddf-c597-e985-bbeb-09e0596c52a6@sixdemonbag.org> <11ed05d9-8335-29b1-ad08-3e5740b249b5@sky-ip.org> <978bdedc-9500-40fd-e6e2-12ed4ec705eb@sky-ip.org> <073b5c2a-ba3c-e8d0-c679-4fe58236809c@sixdemonbag.org> <9639e84f-523f-4ae0-e50a-528b99df8ee6@sixdemonbag.org> Message-ID: <9ed4cd82-6439-9295-7ced-db2d60281748@sky-ip.org> Robert J. Hansen wrote: >> The thing is, if I create an ECC (ECDSA) secp256k1 primary key with >> Sign, Certify capabilities I can also create a subkey with E >> capability which is also a secp256k1 key. So, they can be used for >> encryption after all, so why can't I just add E capability to the >> primary one. > > You're confusing the field of numbers in which an algorithm operates > with the algorithm itself. It's like confusing a sports car with a tour > bus, thinking that since they run on the same roads they're interchangeable. > > secp256k1 is a certain field of numbers in which elliptical curve > operations may be defined. It is not an algorithm. You do not have a > secp256k1 key. You have an ECDSA key which operates in the curve > defined by secp256k1. > > When you "create a subkey with E capability", you're creating an ECDH > subkey operating in secp256k1. It's a completely different algorithm > that happens to operate in the same numerical space. Different cars, > different capabilities, same roads; different keys, different > capabilities, same curve. > > ECDSA/EdDSA cannot encrypt. ECDH cannot sign or certify. > > Your primary key must be able to make certifications. So that means if > you want to use ECC, your primary key must be ECDSA/EdDSA, and you will > never be able to make it into an encryption-capable primary key. Thanks for this. Ok, now it's clear why the primary key cannot Encrypt. Here is a key I have just generated: sec secp256k1/BF131CA5E1642BE9 created: 2017-08-29 expires: never usage: SC trust: ultimate validity: ultimate ssb secp256k1/26882EB702DD7D4B created: 2017-08-29 expires: never usage: E [ultimate] (1). Delete Me I understand that the first one is ECDSA and the second is ECDH, but can't I use the same secp256k1 key (if I import it) but in different two representations (ECDSA representation for Sign and Certify and ECDH for Encrypt)? The subkey might have a different fingerprint because it's a different representation of course but this is not the concern, the concern is for both to be computed from the same imported private key. Thanks. -------------- 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 Tue Aug 29 15:19:59 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 29 Aug 2017 09:19:59 -0400 Subject: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key) In-Reply-To: <9ed4cd82-6439-9295-7ced-db2d60281748@sky-ip.org> References: <6ed43218-b56d-be68-86a5-3aee7a177daa@sky-ip.org> <00cb6ddf-c597-e985-bbeb-09e0596c52a6@sixdemonbag.org> <11ed05d9-8335-29b1-ad08-3e5740b249b5@sky-ip.org> <978bdedc-9500-40fd-e6e2-12ed4ec705eb@sky-ip.org> <073b5c2a-ba3c-e8d0-c679-4fe58236809c@sixdemonbag.org> <9639e84f-523f-4ae0-e50a-528b99df8ee6@sixdemonbag.org> <9ed4cd82-6439-9295-7ced-db2d60281748@sky-ip.org> Message-ID: <9dd009bd-d2d0-50e1-a53c-8290b43fcd33@sixdemonbag.org> > I understand that the first one is ECDSA and the second is ECDH, but > can't I use the same secp256k1 key (if I import it) but in > different two representations (ECDSA representation for Sign and > Certify and ECDH for Encrypt)? Please re-read my message: >> secp256k1 is a certain field of numbers in which elliptical curve >> operations may be defined. It is not an algorithm. You do not >> have a secp256k1 key. You have an ECDSA key which operates in the >> curve defined by secp256k1. What you want to do is like saying, "RSA and DSA each use prime numbers, so can't I use the same prime numbers for each?" And the answer is no, not really, because RSA and DSA are different algorithms that work in different ways. Even if you were to use the same prime numbers for both, your RSA keypair would be distinctly different from your DSA keypair. They are not interchangeable. Please stop talking about "secp256k1 keys". You do not have secp256k1 keys. You have ExDSA or ECDH keys which are not interchangeable with each other. From rjh at sixdemonbag.org Tue Aug 29 15:21:03 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 29 Aug 2017 09:21:03 -0400 Subject: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key) In-Reply-To: References: <6ed43218-b56d-be68-86a5-3aee7a177daa@sky-ip.org> <00cb6ddf-c597-e985-bbeb-09e0596c52a6@sixdemonbag.org> <20170828234239.GA4412@tower.spodhuis.org> Message-ID: <2318a804-4b32-590b-e822-77bab3fa16ac@sixdemonbag.org> > given point and we decide to use this option, can I tell which recipient > 'should' be able to decrypt a message based only on the encrypted > message format if the `throw-keyids` option was used? No. From skquinn at rushpost.com Tue Aug 29 15:24:18 2017 From: skquinn at rushpost.com (Shawn K. Quinn) Date: Tue, 29 Aug 2017 08:24:18 -0500 Subject: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key) In-Reply-To: References: <6ed43218-b56d-be68-86a5-3aee7a177daa@sky-ip.org> <00cb6ddf-c597-e985-bbeb-09e0596c52a6@sixdemonbag.org> <20170828234239.GA4412@tower.spodhuis.org> Message-ID: On 08/29/2017 02:14 AM, s7r wrote: > Hi Phil, > Thanks - this is indeed _very_ useful for my use case. I don't think the > second part is a problem since I can particularly request to not set the > `throw-keyids` option, but let's say metadata becomes a problem at a > given point and we decide to use this option, can I tell which recipient > 'should' be able to decrypt a message based only on the encrypted > message format if the `throw-keyids` option was used? No, that's the whole point of throw-keyids. All you're supposed to be able to tell when using that option, is that none of your keys will decrypt the message, so it's not for you. -- Shawn K. Quinn http://www.rantroulette.com http://www.skqrecordquest.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Tue Aug 29 16:24:28 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 29 Aug 2017 16:24:28 +0200 Subject: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key) In-Reply-To: References: <6ed43218-b56d-be68-86a5-3aee7a177daa@sky-ip.org> <00cb6ddf-c597-e985-bbeb-09e0596c52a6@sixdemonbag.org> <20170828234239.GA4412@tower.spodhuis.org> Message-ID: <09b3180c-c340-ddfc-27ba-fc9b25ed5060@digitalbrains.com> On 29/08/17 15:24, Shawn K. Quinn wrote: > All you're supposed to be > able to tell when using that option, is that none of your keys will > decrypt the message ... which you can only do by trying each private key on the encrypted session key packet and seeing whether the resulting plaintext (which contains the session key) makes sense. There isn't any information that can be learned without actually trying out a particular private key. At least for RSA, it's the only algorithm I know enough by heart about to make this claim with confidence. You don't need to decrypt the data though, just the encrypted session key, to see if it's the correct private key. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From marioxcc.MT at yandex.com Tue Aug 29 19:42:05 2017 From: marioxcc.MT at yandex.com (=?UTF-8?Q?Mario_Castel=c3=a1n_Castro?=) Date: Tue, 29 Aug 2017 12:42:05 -0500 Subject: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key) In-Reply-To: <9639e84f-523f-4ae0-e50a-528b99df8ee6@sixdemonbag.org> References: <6ed43218-b56d-be68-86a5-3aee7a177daa@sky-ip.org> <00cb6ddf-c597-e985-bbeb-09e0596c52a6@sixdemonbag.org> <11ed05d9-8335-29b1-ad08-3e5740b249b5@sky-ip.org> <978bdedc-9500-40fd-e6e2-12ed4ec705eb@sky-ip.org> <073b5c2a-ba3c-e8d0-c679-4fe58236809c@sixdemonbag.org> <9639e84f-523f-4ae0-e50a-528b99df8ee6@sixdemonbag.org> Message-ID: <209d40e9-a654-b152-f40d-84cb365b9c85@yandex.com> On 28/08/17 22:27, Robert J. Hansen wrote: > secp256k1 is a certain field of numbers in which elliptical curve > operations may be defined. It is not an algorithm. You do not have a > secp256k1 key. You have an ECDSA key which operates in the curve > defined by secp256k1. Although elliptic curves are defined *over* a field, they are not themselves a field (or at least, I am not aware of any way to define a field over them). -- Do not eat animals, respect them as you respect people. https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Tue Aug 29 19:50:10 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 29 Aug 2017 13:50:10 -0400 Subject: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key) In-Reply-To: <209d40e9-a654-b152-f40d-84cb365b9c85@yandex.com> References: <6ed43218-b56d-be68-86a5-3aee7a177daa@sky-ip.org> <00cb6ddf-c597-e985-bbeb-09e0596c52a6@sixdemonbag.org> <11ed05d9-8335-29b1-ad08-3e5740b249b5@sky-ip.org> <978bdedc-9500-40fd-e6e2-12ed4ec705eb@sky-ip.org> <073b5c2a-ba3c-e8d0-c679-4fe58236809c@sixdemonbag.org> <9639e84f-523f-4ae0-e50a-528b99df8ee6@sixdemonbag.org> <209d40e9-a654-b152-f40d-84cb365b9c85@yandex.com> Message-ID: > Although elliptic curves are defined *over* a field, they are not > themselves a field Thank you, yes. From marioxcc.MT at yandex.com Tue Aug 29 20:01:38 2017 From: marioxcc.MT at yandex.com (=?UTF-8?Q?Mario_Castel=c3=a1n_Castro?=) Date: Tue, 29 Aug 2017 13:01:38 -0500 Subject: Questions about particular use cases (integrity verification w/o private key, add E flag to primary key, import secp256k1 key) In-Reply-To: <9ed4cd82-6439-9295-7ced-db2d60281748@sky-ip.org> References: <6ed43218-b56d-be68-86a5-3aee7a177daa@sky-ip.org> <00cb6ddf-c597-e985-bbeb-09e0596c52a6@sixdemonbag.org> <11ed05d9-8335-29b1-ad08-3e5740b249b5@sky-ip.org> <978bdedc-9500-40fd-e6e2-12ed4ec705eb@sky-ip.org> <073b5c2a-ba3c-e8d0-c679-4fe58236809c@sixdemonbag.org> <9639e84f-523f-4ae0-e50a-528b99df8ee6@sixdemonbag.org> <9ed4cd82-6439-9295-7ced-db2d60281748@sky-ip.org> Message-ID: <46f67f7d-78d2-bb33-c2b0-c9d620625d9c@yandex.com> On 29/08/17 02:09, s7r wrote: > I understand that the first one is ECDSA and the second is ECDH, but > can't I use the same secp256k1 key (if I import it) but in different two > representations (ECDSA representation for Sign and Certify and ECDH for > Encrypt)? > The subkey might have a different fingerprint because it's a > different representation of course but this is not the concern, the > concern is for both to be computed from the same imported private key. You can use hash(private_key_1) to seed a cryptographically secure pseudo-random number generator (E.g.: AES in CTR mode with the seed as the key), and then use that random stream to generate (private_key_2, pubic_key_2. This is a method applicable in general. The algorithms of private_key_1 and private_key_2 need not be the same, nor do they need to be defied over the same curve. The only problem is that I do not know of a program to do they key generation from a user-provided seed. -- Do not eat animals, respect them as you respect people. https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From marioxcc.MT at yandex.com Tue Aug 29 20:21:58 2017 From: marioxcc.MT at yandex.com (=?UTF-8?Q?Mario_Castel=c3=a1n_Castro?=) Date: Tue, 29 Aug 2017 13:21:58 -0500 Subject: E-mail with deniable authentication Message-ID: Hello. We have OpenPGP/MIME to sign and encrypt e-mail, thus securing the communication. It is my understanding that the other party can publish the signature and the unencrypted message and thus prove that somebody in the possession of the private key wrote (or at least signed) the message. One way to do deniable authentication is to take a shared secret.and use that as the key to a MAC function. However, this does not seem to be implemented in OpenPGP, although it could be done as an additional layer. Is there any existing, convenient way to do deniable authentication for e-mail? Thanks. -- Do not eat animals, respect them as you respect people. https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Tue Aug 29 20:33:46 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 29 Aug 2017 14:33:46 -0400 Subject: E-mail with deniable authentication In-Reply-To: References: Message-ID: <081dd80e-b709-55ad-455e-3a023839df1d@sixdemonbag.org> > We have OpenPGP/MIME to sign and encrypt e-mail, thus securing the > communication. It is my understanding that the other party can > publish the signature and the unencrypted message and thus prove > that somebody in the possession of the private key wrote (or at > least signed) the message. This is not true except in a theoretical mathematical sense. For instance, several people in the community (I know I have, and I recall Werner saying he as well) have seen PGP-signed spam mails that are the result of a home user using Symantec's PGP mail proxy, then getting infested by malware which sends out spam. Since all mail goes through the proxy and the credentials are cached, the spam mails were signed. You can prove origination *only if* you can prove the originating PC was not compromised. Given how common compromise is today -- a few years ago Vint Cerf estimated one in four desktop PCs was compromised -- this is a very high threshold to clear. In a theoretical sense, OpenPGP is a nonrepudiable protocol. But in a practical sense, it is not. From marioxcc.MT at yandex.com Tue Aug 29 21:04:15 2017 From: marioxcc.MT at yandex.com (=?UTF-8?Q?Mario_Castel=c3=a1n_Castro?=) Date: Tue, 29 Aug 2017 14:04:15 -0500 Subject: E-mail with deniable authentication In-Reply-To: <081dd80e-b709-55ad-455e-3a023839df1d@sixdemonbag.org> References: <081dd80e-b709-55ad-455e-3a023839df1d@sixdemonbag.org> Message-ID: On 29/08/17 13:33, Robert J. Hansen wrote: > This is not true except in a theoretical mathematical sense. > > For instance, several people in the community (I know I have, and I > recall Werner saying he as well) have seen PGP-signed spam mails that > are the result of a home user using Symantec's PGP mail proxy, then > getting infested by malware which sends out spam. Since all mail goes > through the proxy and the credentials are cached, the spam mails were > signed. Ha. OpenPGP-signed spam. That is a really amusing incident. > You can prove origination *only if* you can prove the originating PC was > not compromised. Given how common compromise is today -- a few years > ago Vint Cerf estimated one in four desktop PCs was compromised -- this > is a very high threshold to clear. > > In a theoretical sense, OpenPGP is a nonrepudiable protocol. But in a > practical sense, it is not. I want to note that I said ?somebody in the possession of the private key?. I am aware of the ?somebody stole my private key? trick for signature repudiation. I did not consider the possibility of malware (thanks for bringing that into my consideration), but the problem is the same. The problem is that credible repudiation of signatures done that way requires that the legitimate key owner (that would be myself) stops using that key and moreover claims that (at least) all the signatures more recent (meaning the actual date ?for which in many cases only an upper bound is known?, not by the date claimed in the signature) than the one he wants to repudiate are illegitimate. This is something undesirable. Ideally, there should be no need to throw the key, -- Do not eat animals, respect them as you respect people. https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From vedaal at nym.hush.com Tue Aug 29 22:00:51 2017 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Tue, 29 Aug 2017 16:00:51 -0400 Subject: E-mail with deniable authentication In-Reply-To: Message-ID: <20170829200052.22DC1C02BE@smtp.hushmail.com> On 8/29/2017 at 2:26 PM, "Mario Castel?n Castro" wrote:Is there any existing, convenient way to do deniable authentication for e-mail? ===== There are workarounds to accomplish this: [1] Sender 1 sends a signed and encrypted pgp e-mail to Receiver 1, giving Receiver 1 a 'passphrase' which they will agree to use for the next encrypted messages. [2] Sender 1 and Receiver 1 now send conventionally encrypted messages with this passphrase, but without signatures. [3] They both know that only the person who knows the passphrase could have sent it. [4] If they want deniability, they can say that the passphrase 'leaked out' and anybody who it leaked to could have sent it. Alternatively, One can generate a keypair with a random name, and send it to the other one, and they can both sign with it, but encrypt to their own non-shared keys. Again, this signing key can be 'leaked' to the public for deniability, if necessary. There are probably other similar variations of this approach. vedaal -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.claas at posteo.de Wed Aug 30 07:57:26 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Wed, 30 Aug 2017 07:57:26 +0200 Subject: E-mail with deniable authentication In-Reply-To: References: Message-ID: <20170830075726.0706460d@iria.my-fqdn.de> On Tue, 29 Aug 2017 13:21:58 -0500, Mario Castel?n Castro wrote: > Is there any existing, convenient way to do deniable authentication > for e-mail? If your communication partners would use the same software, like opmsg. https://github.com/stealth/opmsg Or if you would use Bitmessage instead of classic email, then you have authenticated/encrypted messages too and can later nuke your keys, if needed. https://bitmessage.org/wiki/Main_Page Regards Stefan -- https://www.behance.net/futagoza https://keybase.io/stefan_claas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 246 bytes Desc: Digitale Signatur von OpenPGP URL: From marfig at gmx.com Wed Aug 30 11:34:10 2017 From: marfig at gmx.com (Mario Figueiredo) Date: Wed, 30 Aug 2017 10:34:10 +0100 Subject: E-mail with deniable authentication In-Reply-To: <081dd80e-b709-55ad-455e-3a023839df1d@sixdemonbag.org> References: <081dd80e-b709-55ad-455e-3a023839df1d@sixdemonbag.org> Message-ID: <20170830103410.00a97abf@Archbox> On Tue, 29 Aug 2017 14:33:46 -0400 "Robert J. Hansen" wrote: > You can prove origination *only if* you can prove the originating PC > was not compromised. Given how common compromise is today -- a few > years ago Vint Cerf estimated one in four desktop PCs was compromised > -- this is a very high threshold to clear. > > In a theoretical sense, OpenPGP is a nonrepudiable protocol. But in a > practical sense, it is not. This isn't true. The necessity for deniability arises many times in contexts where the odds aren't measured clinically, where the possibility of one's PC being compromised isn't know or established, or which has much lower thresholds of acceptance. Examples are dictatorships, and many forms of human relationships, including job relations. I would say that it is the exact opposite of what you said, in practice OpenPGP is nonrepudiable. But that's fine. One can argue that OpenPGP isn't designed to offer that feature and probably never will. Deniability, particularly when it comes to the subject of communication, requires that the message itself can be deniable. OpenPGP does not do any of that. That level of protection exists a layer up OpenPGP. If one wants to use deniability with OpenPGP, one just needs to wrap OpenPGP messages in systems that support it. -- Sinceramente / Best regards, M?rio J.G.P. Figueiredo Luanda, Angola (email) marfig at gmx.com (alt) krugar at openmailbox.org (phone) +244 934 535 121 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Wed Aug 30 11:43:46 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 30 Aug 2017 11:43:46 +0200 Subject: E-mail with deniable authentication In-Reply-To: <20170830103410.00a97abf@Archbox> References: <081dd80e-b709-55ad-455e-3a023839df1d@sixdemonbag.org> <20170830103410.00a97abf@Archbox> Message-ID: <5f78819b-000a-6ed7-ac41-dcd15d82b308@digitalbrains.com> On 30/08/17 11:34, Mario Figueiredo wrote: > Examples are > dictatorships, and many forms of human relationships, including job > relations. I don't think a repudiable message lets you off the hook in those examples either, least of all the dictatorship...! > If one wants to use deniability with OpenPGP, one just needs to wrap > OpenPGP messages in systems that support it. With a little scripting, you could create a new ECC keypair (fast!) for each message, sign the keypair with your normal key, sign the message with the ECC keypair. And when you want to backpedal on a signed message, publish the private ECC key and say "look, anybody who downloaded my private key off the web could have signed that message". Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From stefan.claas at posteo.de Wed Aug 30 12:39:23 2017 From: stefan.claas at posteo.de (Stefan Claas) Date: Wed, 30 Aug 2017 12:39:23 +0200 Subject: E-mail with deniable authentication In-Reply-To: <5f78819b-000a-6ed7-ac41-dcd15d82b308@digitalbrains.com> References: <081dd80e-b709-55ad-455e-3a023839df1d@sixdemonbag.org> <20170830103410.00a97abf@Archbox> <5f78819b-000a-6ed7-ac41-dcd15d82b308@digitalbrains.com> Message-ID: <7a2216e8-f899-ebfc-e667-f8437542b223@posteo.de> Am 30.08.2017 um 11:43 schrieb Peter Lebbing: > With a little scripting, you could create a new ECC keypair (fast!) > for each > message, sign the keypair with your normal key, sign the message with the ECC > keypair. And when you want to backpedal on a signed message, publish the private > ECC key and say "look, anybody who downloaded my private key off the web could > have signed that message". > But then it would be imho advisable that you use a different timestamp (time in the future), because when verifying the published message the timestamp would be earlier than the time the sec key would have appeared on the net, right? Regards Stefan From peter at digitalbrains.com Wed Aug 30 12:46:24 2017 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 30 Aug 2017 12:46:24 +0200 Subject: E-mail with deniable authentication In-Reply-To: <7a2216e8-f899-ebfc-e667-f8437542b223@posteo.de> References: <081dd80e-b709-55ad-455e-3a023839df1d@sixdemonbag.org> <20170830103410.00a97abf@Archbox> <5f78819b-000a-6ed7-ac41-dcd15d82b308@digitalbrains.com> <7a2216e8-f899-ebfc-e667-f8437542b223@posteo.de> Message-ID: <78dc71db-3209-14e9-f2c0-7526350d0430@digitalbrains.com> On 30/08/17 12:39, Stefan Claas wrote: > But then it would be imho advisable that you use a different timestamp (time > in the future), because when verifying the published message the timestamp > would be earlier than the time the sec key would have appeared on the net, > right? Either the timestamp can be faked and the repudiated document can have any timestamp without any proof whatsoever. Both you and the supposed faker could fake the timestamp. Or there is a trusted timestamping service which can dependably assert the minimum age of the document, and you have an extra hurdle to take. You faking the timestamp has the problem that the signature is odd or doesn't verify even during the period of time when you wish to have it validly signed. If you never intended to convey it was true in some sense, you wouldn't sign it at all. The purpose of a repudiable signature is to first assert validity and only later deny it, as I understand. It is not something I know a lot about, though. If there is a timestamping service, you need to make it credible that you had already published the key by then. It seems credible enough by default. You could do this from time to time (create ECC keypair, sign it with your key, immediately publish the keypair), so it wouldn't seem out of character. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From mizett at elude.in Wed Aug 30 17:40:26 2017 From: mizett at elude.in (mizett at elude.in) Date: Wed, 30 Aug 2017 15:40:26 -0000 Subject: key_confusion Message-ID: ******************************************************* hi all, i do not clearly understand the difference between .asc , .gpg , .sign , .sig , cert and do not know the official_usage & conventions. i made my own research before but ... unsuccessfully. i built my curve keys using these commands_options (added a sign subkey and gnupg auto-signed it), armor my public one then export it as file : $ gpg --expert --full-gen-key > long_upperlowernumberspecial $ gpg --quick-add-key fpr ed25519 sign > S $ gpg --list-sigs > 25519 $ gpg --output public.key --armor --export fpr > public.key $ gpg --armor --export you at example.com > public.asc key is also a certificate if i understood well what i read. it looks like : - gnupg uses public.key for being exported on a server_internal operation. - gnupg uses public.asc for being exported on an e-mail/mailing-list_external operation. - gnupg uses cert for server/vpn = multiple keys - key = gpg = cert ? - cert = sign = sig = every keys (subkeys included) - cert = gpg = soft/file encrypted - cert = asc = sign = sig = gpg = gpg2 ? --- is it not the same ? i do not clearly understand the difference between .cert .asc , .gpg , .sign , .sig and do not know the official_usage & conventions. - could i rename the public.* as .sign and what is the difference using .sig ? - could i export the public.key on the hkps-server or must i use the public.asc ? - could i rename public.asc in public.gpg2 ? ... and the same questions come in my mind about the *SUMS files. ... and the same confusion about user-id , fpr , e-mail : --- is it not the same ? if there are strict conventions/rules it should be a better idea to clarify & compartment the usage no ? have you a link where all these embarrassing questions are clearly explained ? thx. OFF-TOPIC : could gnupg add a special option in his settings/option : quantum resistant ? I mean an embedded version of codecrypt. ******************************************************* -----BEGIN PGP PUBLIC KEY BLOCK----- mDMEWaYFNxYJKwYBBAHaRw8BAQdAForZDwa2XHzyPK0h9HaX48zG334uB//GIzrk 5uX5pRK0GG1pemV0dCA8bWl6ZXR0QGVsdWRlLmluPoiWBBMWCAA+FiEEkHF8qdYY xDml5OIMuksBqrkkVUIFAlmmBTcCGwMFCQAJOoAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AACgkQuksBqrkkVUL1MAEAxDli/OwIkKM/V+PI30WZMooZa8i7Pb60NBEP /dafH4gBAKbJDetYDFV72Re7AyMOZ+WoncRVr+HyLg+9QWdeoRUMuDgEWaYFNxIK KwYBBAGXVQEFAQEHQCucJY+zC9uNI6EBzZnxmAc7yMkSk5RWyY6qQRPm3/omAwEI B4h+BBgWCAAmFiEEkHF8qdYYxDml5OIMuksBqrkkVUIFAlmmBTcCGwwFCQAJOoAA CgkQuksBqrkkVUJPBQEA3u8dDnu7qyAsXQkiGsVS1A4q3h6hXePQ5pN7E6QYvjIB AOrkfJ3/bhMO3Wu/BbQEwuIkwENyGoCwpTDOA9/hPW0I =oqqh -----END PGP PUBLIC KEY BLOCK----- ******************************************************** From rick at openfortress.nl Wed Aug 30 21:06:19 2017 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 30 Aug 2017 21:06:19 +0200 Subject: Looking up keys from a massive store Message-ID: <59A70CAB.6000206@openfortress.nl> Hello, I am investigating how to use GnuPG in a content_filter. I found an old post https://lists.gt.net/gnupg/users/53184 where the linear search through the keyring was mentioned as a scaling problem for the number of keys. That would probably hit us too. If I've seen it correctly, the keybox format mentioned there is not part of today's gnupg. What key search method would you recommend that is scalable to many keys and to many signatures being placed in parallel? Or is it perhaps an idea to create public keyrings just for the purpose of one email being sent? [No idea if that is possible at all, let alone how, just thinking out loud.] FWIW, the intention is to fill the LDAP store with keys that are submitted over email, and accepted based on DKIM signatures on the email. Email that is sent would be automatically encrypted with PGP, and DKIM would sign the entire message in the mail server. https://github.com/arpa2/abactis Thanks, Rick van Rein OpenFortres / ARPA2 From marioxcc.MT at yandex.com Thu Aug 31 03:40:10 2017 From: marioxcc.MT at yandex.com (=?UTF-8?Q?Mario_Castel=c3=a1n_Castro?=) Date: Wed, 30 Aug 2017 20:40:10 -0500 Subject: key_confusion In-Reply-To: References: Message-ID: <48e856d3-ad38-0290-e674-637b1a58a345@yandex.com> Hello. Your message is very bad written and I can barely understand it. I will answer what I have understood. On 30/08/17 10:40, mizett at elude.in wrote: > ******************************************************* > hi all, > > i do not clearly understand the difference between .asc , .gpg , .sign , > .sig , cert and do not know the official_usage & conventions. > i made my own research before but ... unsuccessfully. The main specification for OpenPGP (the format used by the ?gpg? command line program) is this: . *Apparently* it does not specify any file extension. There are some *conventions* regarding file names. ?.asc? is used for _ASC_II-armored OpenPGP files. ?.sig? is used for OpenPGP detached signatures (generated with ?gpg -b?). I think that GNU PG uses ?.gpg? by default for everything else (as long as it is in OpenPGP format). Anyway, what matters is the content of the file, not the file name. You can obtain a summary of the content of any OpenPGP file with ?gpg --list-packets < FILE?. > key is also a certificate if i understood well what i read. > it looks like : > - gnupg uses public.key for being exported on a server_internal operation. > - gnupg uses public.asc for being exported on an > e-mail/mailing-list_external I have no idea of what you mean by ?server_internal operation?. GNU PG does not interfaces with e-mail at all. Many e-mail clients call GNU PG in the background, but then GNU PG will do whatever the e-mail client requests. Some people use the word ?certificate? to refer to OpenPGP primary keys. Primary keys should not be confused with ?revocation certificates?. *Revocation* certificates are a type of signed message that say ?Do not longer this key; it may have been compromised or it is not longer in use? in a machine-readable way. The act of signing a key (that is, giving your word that the key belongs to whoever it claims to belong) is also called ?certification?, and the resulting signature is called a ?certification signature? in RFC 4880. > operation. > - gnupg uses cert for server/vpn = multiple keys > - key = gpg = cert ? > - cert = sign = sig = every keys (subkeys inc luded) > - cert = gpg = soft/file encrypted > - cert = asc = sign = sig = gpg = gpg2 ? > --- is it not the same ? GNU PG is the name of the software. ?gpg? is the name of one of the command line programs that GNU PG provides. I do not understand the rest. > i do not clearly understand the difference between .cert .asc , .gpg , > .sign , .sig and do not know the official_usage & conventions. > - could i rename the public.* as .sign and what is the difference using > .sig ? > - could i export the public.key on the hkps-server or must i use the > public.asc ? > - could i rename public.asc in public.gpg2 ? > ... and the same questions come in my mind about the *SUMS files. > ... and the same confusion about user-id , fpr , e-mail : > --- is it not the same ? These are all misguided questions. The filename is irrelevant. The file extensions are there for *you* to help you recognize the files, not for GNU PG. > have you a link where all these embarrassing questions are clearly > explained ? Look at the ?Documentation? page in the GNU PG web site . > OFF-TOPIC : could gnupg add a special option in his settings/option : > quantum resistant ? > I mean an embedded version of codecrypt. I am not a developer of GNU PG, but I assume that public-key algorithms resistant to quantum computing will be standardized (by some standard group like the IETF) and added to GNU PG *when* the need arises, just as support for ECC was recently added. *Currently* the factorization and discrete logarithm algorithms are enough. Also note that symmetric encryption algorithms are minimally affected by quantum computing. GNU PG implements, for example, AES-256 and SHA-512 which should be strong against quantum computers if they are strong against classical computers. Instead of worrying about quantum computers, worry about proper security practices as the end user. The chain is no stronger than the weakest link, and the user is almost always the weakest link. -- Do not eat animals; respect them as you respect people. https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From marioxcc.MT at yandex.com Thu Aug 31 04:48:50 2017 From: marioxcc.MT at yandex.com (=?UTF-8?Q?Mario_Castel=c3=a1n_Castro?=) Date: Wed, 30 Aug 2017 21:48:50 -0500 Subject: E-mail with deniable authentication In-Reply-To: <7b9b40ae-b21c-fdf7-546b-2459fa247a0a@yandex.com> References: <20170829200052.22DC1C02BE@smtp.hushmail.com> <7b9b40ae-b21c-fdf7-546b-2459fa247a0a@yandex.com> Message-ID: On 30/08/17 21:35, Mario Castel?n Castro wrote: > (2) can be signed > without deniablity implications, but is not necessary. Apologies. The authentication code should not be signed either to keep full deniability. -- Do not eat animals; respect them as you respect people. https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From marioxcc.MT at yandex.com Thu Aug 31 04:46:23 2017 From: marioxcc.MT at yandex.com (=?UTF-8?Q?Mario_Castel=c3=a1n_Castro?=) Date: Wed, 30 Aug 2017 21:46:23 -0500 Subject: E-mail with deniable authentication In-Reply-To: <20170830075726.0706460d@iria.my-fqdn.de> References: <20170830075726.0706460d@iria.my-fqdn.de> Message-ID: <44adbd09-d373-95ca-60ae-fdd530e5cd59@yandex.com> On 30/08/17 00:57, Stefan Claas wrote: > If your communication partners would use the same software, like opmsg. > > https://github.com/stealth/opmsg > > Or if you would use Bitmessage instead of classic email, then > you have authenticated/encrypted messages too and can later > nuke your keys, if needed. > > https://bitmessage.org/wiki/Main_Page According to Bitmessage does writer-receiver authentication (I do not know what is the standard term for this public key operation; clearly it is not ?signing?) with HMAC using a Diffie-Hellman key derived from the shared secret between writer and recipient. Thus the recipient can not prove to any third party that the writer wrote the message (because he also knows the shared secret and thus he can also compute the authentication code). But Bitmessage gives me the impression of an highly amateurish job. I cite the absurd use of AES-256 along with a elliptic curve providing roughly 128 bits of security (secp256k1). Moreover, anybody who cares to do so can build an FPGA miner for Bitmessage proofs of work and perform a denial of service given that many users have only a CPU to compute the POW. I would not trust my sensitive data to it. ?opmsg? gives me an even worse impression. It seems to be the work of a single man, and I do not even see a specification of the format. Also, from the readme.md ?The private part of the keys which are stored inside ~/.opmsg are NOT encrypted. It is believed that once someone gained access to your account, its all lost anyway? I would not trust a person with this way of thinking to write my cryptographic software. Regards. -- Do not eat animals; respect them as you respect people. https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From marioxcc.MT at yandex.com Thu Aug 31 04:35:49 2017 From: marioxcc.MT at yandex.com (=?UTF-8?Q?Mario_Castel=c3=a1n_Castro?=) Date: Wed, 30 Aug 2017 21:35:49 -0500 Subject: E-mail with deniable authentication In-Reply-To: <20170829200052.22DC1C02BE@smtp.hushmail.com> References: <20170829200052.22DC1C02BE@smtp.hushmail.com> Message-ID: <7b9b40ae-b21c-fdf7-546b-2459fa247a0a@yandex.com> Hello. Thanks for your reply. I am aware of the first method as well as a variation of the second (it had not occurred to me that they both can use the same key!; I had thought that each correspondent used one key of his own with a meaningless ID and used only for communication with the other correspondent). The problem is that these are an extra layer, not currently implemented in GNU PG or any other software I know of. I was hoping that OpenPGP had a feature of ?deniable authentication of [writer] to [recipient]?. It can be easily implemented with Diffie-Hellman as follows. Writer and recipient have a Diffie-Hellman key over the same group and know each other's public key. The writer computers the shared secret per the DH algorithm, and processes it with a KDF. This is the key to a MAC algorithm (e.g.: HMAC). The writer send the, the message (either encrypted or unencrypted), the authentication code, and a nonce (if the KDF requires it) to the recipient To verify, the recipient computes the shared secret, the MAC key and the authentication code of the message. The recipient knows (save for broken algorithms or leaked private keys) that only the writer or him could have computed the authentication code for the message. We assume that the recipient remembers what he has written and what he has not written, so he can discard himself, leaving the writer as the only option. The recipient can divulge the message, but he can not prove that the writer (as opposed to him) wrote the message, even if he is willing to divulge his private key. *Maybe* I will implement this scheme sometime in GNU PG as an OpenPGP extension, if somebody doesn't do it in the meantime. Alternatively, the writer can write an message encrypted to the recipient public-key consisting of 3 parts: (1) A message signed by the writer saying ?I am sending *somebody* a secret message authenticated with MAC algorithm ... and key ...?. (2) The authentication code. (3) The message itself. The signed message (1) should not include the name of the recipient. Obviously (3) should not be signed. (2) can be signed without deniablity implications, but is not necessary. The most the recipient can do is to prove that the writer wrote ?I am sending *somebody* a secret message authenticated with MAC algorithm ... and key ...?, but he can not even prove that the writer wrote that to *him*. Both of these methods require no prior agreement between sender and receiver. On 29/08/17 15:00, vedaal at nym.hush.com wrote: > There are workarounds to accomplish this: > > [1] Sender 1 sends a signed and encrypted pgp e-mail to Receiver 1, > giving Receiver 1 a 'passphrase' which they will agree to use for the > next encrypted messages. > > [2] Sender 1 and Receiver 1 now send conventionally encrypted messages > with this passphrase, but without signatures. > > [3] They both know that only the person who knows the passphrase could > have sent it. > > [4] If they want deniability, they can say that the passphrase 'leaked > out' and anybody who it leaked to could have sent it. > Alternatively, > > One can generate a keypair with a random name, and send it to the > other one, and they can both sign with it, but encrypt to their own > non-shared keys. -- Do not eat animals; respect them as you respect people. https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From info at bereshka.net Thu Aug 31 14:20:21 2017 From: info at bereshka.net (Bereshka) Date: Thu, 31 Aug 2017 07:20:21 -0500 Subject: please help "No pinentry" Message-ID: <0E8559B2-00A9-41C3-B284-664FEAB7B82A@bereshka.net> Hello, Dear Creators :) I will very appreciate if you can help me, because I was surfing a lot in the internet looking for an answer, and read tones of forums, but did not find solution. So I installed gnupg 2 , command gpg didn?t work in Terminal. I was confused and decided to try Gnupg tools suite, I installed that and created my keys and passphrase. Later I knew that I should type gpg2 in Terminal to work with that. So I got encrypted message and I tried to decrypt it, but it just didn?t show a result, it said that by whom it was encrypted and to whom, that?s all. We decided that it might be a problem because go GPG tools suite, maybe it causes conflict. So I decided to deinstall GPG Tools. Before to do that I exported my public, private, rev certificate, then I deinstalled this software. I located all keys to a folder ?keys? at my user root folder). Then I imported all keys through terminal. To check I do ?list-keys and I see my imported key and my husband?s key that was imported as well. 1. The problem is that I can encrypt message and send it to him and that he can decrypt it. But when I get encrypted message from him I can?t decrypt it. It does?t ask my passphrase. It asked when I had GPG Tools, but even with asked passpharase with GPG Tools being installed i didn?t get a decrypted message Now I don?t have GPG Tools and when I do command gpg2 Enter and insert his message I get this gpg: public key decryption failed: No pinentry gpg: decryption failed: No secret key 2. Then, I decided that if there is so much mess with this email, I will create keys with other one , but I still get same error on the step of creation gpg: public key decryption failed: No pinentry gpg: decryption failed: No secret key 3. Also I found on one forum that file gpg-agent.conf should be edited with adding this line - pinentry-program /bereshka/bin/pinentry-qt but it didn?t help Bestregards Ana Best regards, Anastasiia Gudkov Photographer +1(713)637-96-96 instagram @bereshka.photo facebook.com/bereshka.photo info at bereshka.net www.bereshka.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From marioxcc.MT at yandex.com Thu Aug 31 15:24:35 2017 From: marioxcc.MT at yandex.com (=?UTF-8?Q?Mario_Castel=c3=a1n_Castro?=) Date: Thu, 31 Aug 2017 08:24:35 -0500 Subject: please help "No pinentry" In-Reply-To: <0E8559B2-00A9-41C3-B284-664FEAB7B82A@bereshka.net> References: <0E8559B2-00A9-41C3-B284-664FEAB7B82A@bereshka.net> Message-ID: <5ceadd7c-5410-030e-c9f8-a9765565f4d5@yandex.com> On 31/08/17 07:20, Bereshka wrote: > Hello, Dear Creators :) > > I will very appreciate if you can help me, because I was surfing a lot in the internet looking for an answer, and read tones of forums, but did not find solution. > > So I installed gnupg 2 , command gpg didn?t work in Terminal. I was confused and decided to try Gnupg tools suite, I installed that and created my keys and passphrase. Later I knew that I should type gpg2 in Terminal to work with that. So I got encrypted message and I tried to decrypt it, but it just didn?t show a result, it said that by whom it was encrypted and to whom, that?s all. We decided that it might be a problem because go GPG tools suite, maybe it causes conflict. So I decided to deinstall GPG Tools. Before to do that I exported my public, private, rev certificate, then I deinstalled this software. I located all keys to a folder ?keys? at my user root folder). Then I imported all keys through terminal. To check I do ?list-keys and I see my imported key and my husband?s key that was imported as well. > > > 1. The problem is that I can encrypt message and send it to him and that he can decrypt it. But when I get encrypted message from him I can?t decrypt it. It does?t ask my passphrase. It asked when I had GPG Tools, but even with asked passpharase with GPG Tools being installed i didn?t get a decrypted message > Now I don?t have GPG Tools and when I do command gpg2 Enter and insert his message I get this > > gpg: public key decryption failed: No pinentry > gpg: decryption failed: No secret key Hello. GNU PG version 2.* uses a program called ?pinentry? to ask for passwords whenever it requires a password. There are several such pinentry programs. You can install several of them but you just need one. If you use GNU/Linux, search for ?pinentry? in the listing of package in your package manager. There will be several such programs. The only user-visible difference (as far as I know) is the way in which they ask for password and the look and feel. If you want a graphical window to ask you for password, install ?pinentry-gtk2?, ?pinentry-gnome? or ?pinentry-qt?. If you want to be asked within the terminal emulator, install ?pinentry-curses? or ?pinentry-tty?. I have never used ?GPG Tools? so I can not provide any help in this regard. Regards. -- Do not eat animals; respect them as you respect people. https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Aug 31 15:48:47 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 31 Aug 2017 15:48:47 +0200 Subject: [Announce] Libgcrypt 1.8.1 and 1.7.9 to fix CVE-2017-0379 Message-ID: <87wp5jetkw.fsf@wheatstone.g10code.de> Hi! The GnuPG Project is pleased to announce the availability of Libgcrypt versions 1.7.9 and 1.8.1. These releases fix a local side-channel attack on our implementation of Curve25519 based encryption. 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.8.1 (2017-08-27) ================================================ - Mitigate a local side-channel attack on Curve25519 dubbed "May the Fourth be With You". [CVE-2017-0379] - Add more extra bytes to the pool after reading a seed file. - Add the OID SHA384WithECDSA from RFC-7427 to SHA-384. - Fix build problems with the Jitter RNG - Fix assembler code build problems on Rasbian (ARMv8/AArch32-CE). We also released a new version of the older 1.7 branch: Noteworthy changes in version 1.7.9 (2017-08-27) ================================================ - Mitigate a local side-channel attack on Curve25519 dubbed "May the Fourth be With You". [CVE-2017-0379] Comments on the vulnerability ============================= Details on this attack can be found in the paper May the Fourth Be With You: A Microarchitectural Side Channel Attack on Real-World Applications of Curve25519 by Daniel Genkin, Luke Valenta, and Yuval Yarom https://eprint.iacr.org/2017/806. Note that this side-channel attack requires that the attacker can run arbitrary software on the hardware where the private Curve25519 encryption key is used. In GnuPG a Curve25519 key used for encryption is shown as "cv25519". Signature keys based on Curve25519 (in GnuPG "ed25519") are not affected. Allowing other users to run software on a machine with private keys should be considered a full security compromise of that machine, anyway. Thus in practice there are easier ways to access the private keys than to mount this side-channel attack. However, on boxes with virtual machines this attack may be used by one VM to steal private keys from another VM. We received a draft of that research paper on August 18th and published these releases last Sunday (August 27th). The Windows installer for GnuPG 2.2.0, as released on Monday, has already been build with the fixed Libgcrypt 1.8.1. The actually used fix can be found as commit bf76acbf0da6b0f245e491bec12c0f0a1b5be7c9 in the Libgcrypt Git repo. Niibe-san is currently working on improving our Curve25519 support for the next major Libgcrypt release. This will give us an additional protection method against this class of attacks. Download ======== Source code is hosted at the GnuPG FTP server and its mirrors as listed at . On the primary server the source tarball and its digital signature are: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.1.tar.bz2 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.1.tar.bz2.sig or gzip compressed: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.1.tar.gz https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.1.tar.gz.sig The URLS for the older 1.7 branch are: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.9.tar.bz2 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.9.tar.bz2.sig https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.9.tar.gz https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.9.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.8.1.tar.bz2 you would use this command: gpg --verify libgcrypt-1.8.1.tar.bz2.sig libgcrypt-1.8.1.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.8.1.tar.bz2, you run the command like this: sha1sum libgcrypt-1.8.1.tar.bz2 and check that the output matches the first line from the this list: dd35f00da45602afe81e01f4d60c40bbdd826fe6 libgcrypt-1.8.1.tar.bz2 1256e3981258c07c7c77884409c4cbb30cf7b55c libgcrypt-1.8.1.tar.gz 04126cdca54074d8768dea4287493a5b338a9a98 libgcrypt-1.7.9.tar.bz2 7bfec30457e4daeaf131ba9fae0bdd3b2a185a1b libgcrypt-1.7.9.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 4 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]. Happy hacking, The GnuPG Team [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 five keys: 2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31] Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 Werner Koch (Release Signing Key) rsa3072/4B092E28 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (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 BCEF7E294B092E28 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: 227 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 marioxcc.MT at yandex.com Thu Aug 31 15:45:24 2017 From: marioxcc.MT at yandex.com (=?UTF-8?Q?Mario_Castel=c3=a1n_Castro?=) Date: Thu, 31 Aug 2017 08:45:24 -0500 Subject: please help "No pinentry" In-Reply-To: <5ceadd7c-5410-030e-c9f8-a9765565f4d5@yandex.com> References: <0E8559B2-00A9-41C3-B284-664FEAB7B82A@bereshka.net> <5ceadd7c-5410-030e-c9f8-a9765565f4d5@yandex.com> Message-ID: <454ca832-ef4c-6d98-cd2a-0088e04cb32f@yandex.com> > 3. Also I found on one forum that file gpg-agent.conf should be edited with adding this line - pinentry-program /bereshka/bin/pinentry-qt > but it didn?t help In my previous message I forgot to comment about this: There should be no need to set ?pinentry-program? if you use your distribution package manager to install a pinentry. If you install the pinentry program manually, then possibly you need to specify here the path to the executable, as installed in your computer (do not simply copy and paste verbatim to the forum). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Thu Aug 31 17:04:11 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 31 Aug 2017 11:04:11 -0400 Subject: please help "No pinentry" In-Reply-To: <0E8559B2-00A9-41C3-B284-664FEAB7B82A@bereshka.net> References: <0E8559B2-00A9-41C3-B284-664FEAB7B82A@bereshka.net> Message-ID: > Hello, Dear Creators :) I'm not a creator (just a FAQ maintainer), but maybe I can shed some light on your troubles. > But when I get encrypted message from him I can?t > decrypt it. It does?t ask my passphrase. It asked when I had GPG Tools, > but even with asked passpharase with GPG Tools being installed i didn?t > get a decrypted message I think I might know the problem. If I recall correctly, GPGTools ships with its own custom pinentry dialog. When you installed GPGTools, it added a line in a configuration file telling GnuPG to use its custom pinentry dialog; when you uninstalled GPGTools, that custom pinentry dialog went away but the configuration file is still changed. So GnuPG is trying to use a pinentry dialog that doesn't exist. >From Terminal, open up ~/.gnupg/gpg-agent.conf in your text editor of choice. Look for a line called "pinentry-program" and place a hashmark ("#") in front of that line. This will cause gpg-agent to skip that line when reading the configuration file. Then, from a Terminal window: $ killall gpg-agent ... and try again to decrypt a message. From marioxcc.MT at yandex.com Thu Aug 31 17:24:26 2017 From: marioxcc.MT at yandex.com (=?UTF-8?Q?Mario_Castel=c3=a1n_Castro?=) Date: Thu, 31 Aug 2017 10:24:26 -0500 Subject: please help "No pinentry" In-Reply-To: References: <0E8559B2-00A9-41C3-B284-664FEAB7B82A@bereshka.net> <5ceadd7c-5410-030e-c9f8-a9765565f4d5@yandex.com> Message-ID: <8c3df423-b14d-cdc2-03e9-38f6245dbcc0@yandex.com> On 31/08/17 09:12, Bereshka Web and Photo wrote: > Hello, Mario > Thank you for your advice and attention. Hello. When replying to a message from a mailing list list, please reply to the mailing list instead of the sender only. Most e-mail clients have a ?Reply to list? button to do this quickly. >> There are several such >> pinentry programs. You can install several of them but you just need one. > > for example? is this program is not in the package of Gnupg? > I use Mac A pinentry program may or may not come with GNU PG. It depends on how you install it. If you compiled from source (you would know if you did that), then you need to install pinentry separately. If you used a third-party software bundle that includes GNU PG, then it depends on the choice of the developers of *that* software bundle. For examples of pinentry programs, take the ones I mentioned in my previous message. > well, then why other people on mac don?t have that problems, they just download gnupg and start using, they don?t install anything additionally) The GNU PG project does not distribute any binaries for Mac OS X. As for the people who ?download gnu pg and start using it?, I assume they install a software bundle containing GNU PG. However, although such bundle may include GNU PG, it is a third-party project, not part of GNU PG itself. Anyway, I recommend using GNU/Linux because unlike Mac OS X it is free software. Installing GNU PG in any reasonable GNU/Linux distribution is trivial. If you want to continue using Mac OS X you probably want to use one of those bundled made by a third party. *To summarize:* You are probably using an unofficial software bundle for Mac OS X that includes GNU PG. The GNU PG developers in general are not responsible for any such bundle. You must consult the documentation of your bundle. Regards. -- Do not eat animals; respect them as you respect people. https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Aug 31 18:30:30 2017 From: wk at gnupg.org (Werner Koch) Date: Thu, 31 Aug 2017 18:30:30 +0200 Subject: Looking up keys from a massive store In-Reply-To: <59A70CAB.6000206@openfortress.nl> (Rick van Rein's message of "Wed, 30 Aug 2017 21:06:19 +0200") References: <59A70CAB.6000206@openfortress.nl> Message-ID: <87fuc7em3d.fsf@wheatstone.g10code.de> On Wed, 30 Aug 2017 21:06, rick at openfortress.nl said: > for the number of keys. That would probably hit us too. If I've seen it > correctly, the keybox format mentioned there is not part of today's gnupg. The keybox is the default for new installations (that is if there is no pubring.gpg) since 2.1. I implemented it so that (iirc) were able to do 20 signature verifications from a random set of keys out of 30000 keys within a second. Unfortunately recent changes to internal workings dropped the performance again. > What key search method would you recommend that is scalable to many keys and > to many signatures being placed in parallel? Or is it perhaps an idea to > create public keyrings just for the purpose of one email being sent? [No > idea if that is possible at all, let alone how, just thinking out loud.] Try to use the fingerprint. That will be always be the fastest way to access the key material. > FWIW, the intention is to fill the LDAP store with keys that are submitted > over email, and accepted based on DKIM signatures on the email. Email that > is sent would be automatically encrypted with PGP, and DKIM would sign the > entire message in the mail server. If you want to encrypt only, there may be a simpler way: The new option -F takes a file with a single key and encrypts to that key, without any need to access the public keyring. We use it for example in our Web Key Directory tools to do a run a challenge response protocol. See gnupg/tools/gpg-wks-server.c for some hints but I can also explain usage if you explain your protocol in more detail. 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: 227 bytes Desc: not available URL: From info at bereshka.net Thu Aug 31 22:27:16 2017 From: info at bereshka.net (Bereshka Web and Photo) Date: Thu, 31 Aug 2017 15:27:16 -0500 Subject: please help "No pinentry" In-Reply-To: <8c3df423-b14d-cdc2-03e9-38f6245dbcc0@yandex.com> References: <0E8559B2-00A9-41C3-B284-664FEAB7B82A@bereshka.net> <5ceadd7c-5410-030e-c9f8-a9765565f4d5@yandex.com> <8c3df423-b14d-cdc2-03e9-38f6245dbcc0@yandex.com> Message-ID: <24C32B77-19DB-4C5A-A881-86952FE9266E@bereshka.net> Mario, I know about reply all :) but didn?t want to be annoying with all one hundred questions that I was going to ask :)) But I agree that it may help to somebody else to solve the same issue. I used this website to download and install https://www.gnupg.org/download/index.html Robert, It was my guess too, that there is a conflict between the original gnupg and that third-part GnuPG, that after deinstallation caused misunderstood in the system, causing some parameters, that it could not give anymore. Then I tried few times to uninstall gnupg using the command sudo apt-get install gnupg in Terminal. I edited this file gpg-agent.conf previously, adding this line - pinentry-program /bereshka/bin/pinentry-qt . But it didn?t help and I removed it. Actually when I opened it first time, this file, it was empty and it?s empty today too, so there is noting to comment. I was struggling with that about two weeks ago and read tones of information in the internet and nothing helped. But after I asked that question and got all your kind advices I decided what if a miracle happens and I just try to decrypt a message again. And I was very surprised, because it works. I didn?t do any changes today, I just opened again that file config to look at. And I restarted my laptop many times right after all that changes that I did two weeks ago, but it didn?t help at that time. But today it just starts to work. Thank ya?ll Best regards, Anastasiia > On 31 Aug 2017, at 10:24, Mario Castel?n Castro wrote: > > On 31/08/17 09:12, Bereshka Web and Photo wrote: >> Hello, Mario >> Thank you for your advice and attention. > > Hello. > > When replying to a message from a mailing list list, please reply to the > mailing list instead of the sender only. Most e-mail clients have a > ?Reply to list? button to do this quickly. > >>> There are several such >>> pinentry programs. You can install several of them but you just need one. >> >> for example? is this program is not in the package of Gnupg? >> I use Mac > > A pinentry program may or may not come with GNU PG. It depends on how > you install it. If you compiled from source (you would know if you did > that), then you need to install pinentry separately. > > If you used a third-party software bundle that includes GNU PG, then it > depends on the choice of the developers of *that* software bundle. > > For examples of pinentry programs, take the ones I mentioned in my > previous message. > >> well, then why other people on mac don?t have that problems, they just download gnupg and start using, they don?t install anything additionally) > > The GNU PG project does not distribute any binaries for Mac OS X. As for > the people who ?download gnu pg and start using it?, I assume they > install a software bundle containing GNU PG. However, although such > bundle may include GNU PG, it is a third-party project, not part of GNU > PG itself. > > Anyway, I recommend using GNU/Linux because unlike Mac OS X it is free > software. Installing GNU > PG in any reasonable GNU/Linux distribution is trivial. > > If you want to continue using Mac OS X you probably want to use one of > those bundled made by a third party. > > *To summarize:* You are probably using an unofficial software bundle for > Mac OS X that includes GNU PG. The GNU PG developers in general are not > responsible for any such bundle. You must consult the documentation of > your bundle. > > Regards. > > -- > Do not eat animals; respect them as you respect people. > https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Thu Aug 31 22:33:09 2017 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 31 Aug 2017 16:33:09 -0400 Subject: please help "No pinentry" In-Reply-To: <24C32B77-19DB-4C5A-A881-86952FE9266E@bereshka.net> References: <0E8559B2-00A9-41C3-B284-664FEAB7B82A@bereshka.net> <5ceadd7c-5410-030e-c9f8-a9765565f4d5@yandex.com> <8c3df423-b14d-cdc2-03e9-38f6245dbcc0@yandex.com> <24C32B77-19DB-4C5A-A881-86952FE9266E@bereshka.net> Message-ID: > Then I tried few times to uninstall gnupg using the command?sudo apt-get > install gnupg?in Terminal. That shouldn't have worked. You're on a Mac, and apt is used by derivatives of Debian GNU/Linux. (Well, wait, I guess Fink uses apt, doesn't it?) > previously, adding this line - pinentry-program > /bereshka/bin/pinentry-qt That doesn't look like a valid path. On a Mac, it would be /Users/bereshka/bin/pinentry-qt, if anything. Did you verify that the path actually exists? > But today it just starts to work. Hey, if a miracle happened and your problem got solved, then ... your problem got solved, and we're happy for you. :) From info at bereshka.net Thu Aug 31 22:41:31 2017 From: info at bereshka.net (Bereshka Web and Photo) Date: Thu, 31 Aug 2017 15:41:31 -0500 Subject: please help "No pinentry" In-Reply-To: References: <0E8559B2-00A9-41C3-B284-664FEAB7B82A@bereshka.net> <5ceadd7c-5410-030e-c9f8-a9765565f4d5@yandex.com> <8c3df423-b14d-cdc2-03e9-38f6245dbcc0@yandex.com> <24C32B77-19DB-4C5A-A881-86952FE9266E@bereshka.net> Message-ID: <2F8EB52B-140C-4042-91EB-BB9E890257F0@bereshka.net> > On 31 Aug 2017, at 15:33, Robert J. Hansen wrote: > >> Then I tried few times to uninstall gnupg using the command sudo apt-get >> install gnupg in Terminal. > > That shouldn't have worked. You're on a Mac, and apt is used by > derivatives of Debian GNU/Linux. > > (Well, wait, I guess Fink uses apt, doesn't it?) Sorry, I don?t know who is that )) I?m very new to all of this, but it?s very interesting Thanks for attention > >> previously, adding this line - pinentry-program >> /bereshka/bin/pinentry-qt > > That doesn't look like a valid path. On a Mac, it would be > /Users/bereshka/bin/pinentry-qt, if anything. Did you verify that the > path actually exists? > >> But today it just starts to work. > > Hey, if a miracle happened and your problem got solved, then ... your > problem got solved, and we're happy for you. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rick at openfortress.nl Thu Aug 31 20:26:52 2017 From: rick at openfortress.nl (Rick van Rein) Date: Thu, 31 Aug 2017 20:26:52 +0200 Subject: Looking up keys from a massive store In-Reply-To: <87fuc7em3d.fsf@wheatstone.g10code.de> References: <59A70CAB.6000206@openfortress.nl> <87fuc7em3d.fsf@wheatstone.g10code.de> Message-ID: <59A854EC.7060302@openfortress.nl> Thanks Werner! > The keybox is the default for new installations (that is if there is no > pubring.gpg) since 2.1. I implemented it so that (iirc) were able to do > 20 signature verifications from a random set of keys out of 30000 keys > within a second. Unfortunately recent changes to internal workings > dropped the performance again. Wow :) > If you want to encrypt only, there may be a simpler way: The new option > -F takes a file with a single key and encrypts to that key, without any > need to access the public keyring. Ah, that is a most useful addition :) I also found the internal API after writing this and found that I can load the keys, which is yet another way to get it done. Great! > We use it for example in our Web Key > Directory tools to do a run a challenge response protocol. See > gnupg/tools/gpg-wks-server.c for some hints but I can also explain usage > if you explain your protocol in more detail. Thanks. I am still designing, so things are still fuzzy and looking where they fit in :) The above is already quite helpful! -Rick From marioxcc.MT at yandex.com Thu Aug 31 23:24:05 2017 From: marioxcc.MT at yandex.com (=?UTF-8?Q?Mario_Castel=c3=a1n_Castro?=) Date: Thu, 31 Aug 2017 16:24:05 -0500 Subject: please help "No pinentry" In-Reply-To: <2F8EB52B-140C-4042-91EB-BB9E890257F0@bereshka.net> References: <0E8559B2-00A9-41C3-B284-664FEAB7B82A@bereshka.net> <5ceadd7c-5410-030e-c9f8-a9765565f4d5@yandex.com> <8c3df423-b14d-cdc2-03e9-38f6245dbcc0@yandex.com> <24C32B77-19DB-4C5A-A881-86952FE9266E@bereshka.net> <2F8EB52B-140C-4042-91EB-BB9E890257F0@bereshka.net> Message-ID: Well, if the problem is solved then I am glad for you))) -- Do not eat animals; respect them as you respect people. https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From info at bereshka.net Thu Aug 31 23:36:10 2017 From: info at bereshka.net (Bereshka Web and Photo) Date: Thu, 31 Aug 2017 16:36:10 -0500 Subject: please help "No pinentry" In-Reply-To: References: <0E8559B2-00A9-41C3-B284-664FEAB7B82A@bereshka.net> <5ceadd7c-5410-030e-c9f8-a9765565f4d5@yandex.com> <8c3df423-b14d-cdc2-03e9-38f6245dbcc0@yandex.com> <24C32B77-19DB-4C5A-A881-86952FE9266E@bereshka.net> <2F8EB52B-140C-4042-91EB-BB9E890257F0@bereshka.net> Message-ID: it happens all the time, solution is of itself as soon as I ask it on a forum or like John Robbins said ?My cat, as it turns out, is an excellent debugger, and she has helped me solve a number of nasty bugs when I talked to her about them? :) not exact situation, but little bit similar ) > On 31 Aug 2017, at 16:24, Mario Castel?n Castro wrote: > > Well, if the problem is solved then I am glad for you))) > > -- > Do not eat animals; respect them as you respect people. > https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users