From wk at gnupg.org  Mon Apr  1 11:18:08 2019
From: wk at gnupg.org (Werner Koch)
Date: Mon, 01 Apr 2019 11:18:08 +0200
Subject: gpg-agent: different ttl for different keys possible?
In-Reply-To: <875zs2aera.fsf@len.workgroup> (Gregor Zattler's message of "Thu, 
 28 Mar 2019 18:08:45 +0100")
References: <875zs2aera.fsf@len.workgroup>
Message-ID: <87r2amqe27.fsf@wheatstone.g10code.de>

On Thu, 28 Mar 2019 18:08, telegraph at gmx.net said:

> is it possible to configure gpg-agent to cache the passphrase
> for different OpenPGP keys for a different length of time?  if

No, that is currently not possible.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190401/d0d48956/attachment.sig>

From peter at digitalbrains.com  Tue Apr  2 13:11:50 2019
From: peter at digitalbrains.com (Peter Lebbing)
Date: Tue, 2 Apr 2019 13:11:50 +0200
Subject: Stop popup which asks for the passphrase
Message-ID: <9dc9a812-d2fe-8d20-0227-5797a99adcf9@digitalbrains.com>

I'm reposting a question[1] asked by Shweta Tyagi in a different thread,
so it is in its own thread. I feel Shweta might have chosen to seek
their answer elsewhere after they only got unhelpful responses there,
and I'd like to rectify that.

Shweta asked:

Hi All,

I am using the following command

gpg --batch --passphrase-fd n and it stops popup which asks for the
passphrase. but when I run this command on window server 12 it's not
working its always show popup for the passphrase. can someone please
help me how can I stop popup on window server 12.

[1] https://lists.gnupg.org/pipermail/gnupg-users/2019-March/061789.html

-- 
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 <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190402/b14d085e/attachment-0001.sig>

From peter at digitalbrains.com  Tue Apr  2 13:11:44 2019
From: peter at digitalbrains.com (Peter Lebbing)
Date: Tue, 2 Apr 2019 13:11:44 +0200
Subject: Please start a new thread
In-Reply-To: <CAPwDx1bT_ayu_rW1CS72Fa1BeWhC4PJoXJmtnkDzNRg41jQfJQ@mail.gmail.com>
References: <ee9c1b0c-fc6f-4e23-9ae5-0494ccc88fb6@www.fastmail.com>
 <20d02c69-3c9b-5798-b4ef-67f642b1e523@digitalbrains.com>
 <6b96902a-cf19-43ba-a2a6-31697195fc0d@www.fastmail.com>
 <5bfc24af-8b6e-a2ca-f61d-97c3409cb22b@digitalbrains.com>
 <87d0mfvwqm.fsf@wheatstone.g10code.de>
 <4b8d7681-861a-6513-37c6-9a66c5696182@digitalbrains.com>
 <87sgvauk2x.fsf@wheatstone.g10code.de>
 <b17fb451-a388-4d71-dc19-0fd1d588dba7@digitalbrains.com>
 <CAPwDx1ZMDt-4acH+JtOo0BNxeCjqkx9cVeX2QONGSqe02yZr7Q@mail.gmail.com>
 <1cfbf9df-34c8-0c90-ae52-765450d0763f@digitalbrains.com>
 <CAPwDx1bT_ayu_rW1CS72Fa1BeWhC4PJoXJmtnkDzNRg41jQfJQ@mail.gmail.com>
Message-ID: <7904ae68-45aa-6b5f-df19-79ab7e611852@digitalbrains.com>

Hello Shweta,

Seeing how you did not start a new thread, I get the feeling we "scared
you off" from posting. That is really unfortunate, and not our intention
at all. I'm sorry if you felt intimidated by the response you got.

It's rather unusual, but I took the liberty of posting your question to
the mailing list again, but now not by replying to an existing mailing
list post but addressing a mail to <gnupg-users at gnupg.org>. And
subsequently answering the question to the extent I could.

Let me conclude by copying the part of the list information page[1] that
pertains to basic rules of conduct. The rules are there to make
communication easier; for instance, if you don't trim your quotes it
becomes an effort just to read the flow of the conversation. People who
might otherwise have insightful stuff to add might have given up
reading. And if someone searches the list archive to find if someone
else was already helped with the same problem they're having, it should
be possible to quickly navigate through large amounts of conversation.
That is also why it's important to have one thread deal with one subject
only (or a set of closely related subjects at least :-).

> The topic of this is list is help and discussion among users of GnuPG.
> This includes questions on how to script GnuPG, how to create or sign
> keys and general discussion on encryption and digital signatures as
> long as it somehow pertains to GnuPG. 
>
> The contents of all messages sent to this mailing list is assumed to
> be in the public domain but posted code snippets or patches are under
> their respective license. Do not post any material which may not be
> published. Take care before posting; retracting a post is in general
> not possible. Please write only in English, *avoid* *top* *posting*
> *and* *strip* *quotes* to the necessary minimum. 
>
> Some kinds of postings will not be accepted: e.g. large ones, mails
> without the list name in the To: or CC: header and HTML mails. Your
> mail client does have an option to send plain text only messages; try
> this if you don't get your posting through or notice it in the
> archive.

HTH,

Peter.

[1] https://lists.gnupg.org/mailman/listinfo/gnupg-users

-- 
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 <http://digitalbrains.com/2012/openpgp-key-peter>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190402/0aecff7b/attachment.sig>

From peter at digitalbrains.com  Tue Apr  2 13:12:23 2019
From: peter at digitalbrains.com (Peter Lebbing)
Date: Tue, 2 Apr 2019 13:12:23 +0200
Subject: Stop popup which asks for the passphrase
In-Reply-To: <9dc9a812-d2fe-8d20-0227-5797a99adcf9@digitalbrains.com>
References: <9dc9a812-d2fe-8d20-0227-5797a99adcf9@digitalbrains.com>
Message-ID: <b6aaea44-f3bd-94e7-d9f5-8c3e969753fa@digitalbrains.com>

Hello Shweta,

> gpg --batch --passphrase-fd n and it stops popup which asks for the
> passphrase. but when I run this command on window server 12 it's not
> working its always show popup for the passphrase.

It is not clear to me which versions of GnuPG you are using. Using a
recent version, but on Linux, I cannot reproduce that this command
works, so I agree with Windows there.

What works for me is:

$ gpg --batch --pinentry-mode loopback --passphrase-fd n [...]

(obviously filling in a number for n, and continuing with more options
and a command for gpg).

With older versions of gpg-agent, it might be necessary to specify the
following in ~/.gnupg/gpg-agent.conf (rather, its location on your OS of
choice):

allow-loopback-pinentry

but this is the default now.

As a full working example, this works for me:

$ echo Hi | gpg --batch -o test.gpg -u 1819B624D400781C8988105EC97A5BCE0BFBF628 --passphrase-fd 3 --pinentry-mode loopback -s 3<<<test

Yes, the literal password for this key is "test"; it is, after all, a
test key.

If this is not enough to help you, please specify which versions of
GnuPG you are running on which operating systems, and the contents of
the various .conf files for GnuPG, and most importantly: actual command
lines and their actual output. You can edit out confidential data, but
it really helps if we can see the actual interaction with gpg to
pinpoint the culprit.

Furthermore, I myself have hardly any knowledge of Microsoft Windows, so
someone else might need to fill that void.

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 <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190402/7f282143/attachment.sig>

From sp_xie at yahoo.com  Tue Apr  2 20:00:57 2019
From: sp_xie at yahoo.com (Shaoping Xie)
Date: Tue, 2 Apr 2019 14:00:57 -0400
Subject: =?utf-8?Q?=E7=AD=94=E5=A4=8D:_Two_questions_about_system_entropy_and_upda?=
 =?utf-8?Q?te_?=
References: <mailman.13214.1553603698.30381.gnupg-users@gnupg.org>
Message-ID: <mailman.18.1554231685.30378.gnupg-users@gnupg.org>

I have tried many suggestions on the internet and none worked.

I have finally generated the key pair on another system and then exported/imported the keys.

I hope that my experience may save some time and effort of other fellows.

Regards?
Shaoping


??? Windows 10 ?????

???: Shaoping Xie
????: 2019?3?31? 8:43
???: gnupg-users at gnupg.org
??: Two questions about system entropy and update 

Good Morning ,

  I have been tried to generate a key pair and gotten the error :
  
  Not enough random bytes available.? Please do some other work to give
  the OS a chance to collect more entropy! (Need 300 more bytes)
  
  It seems that the error is very common by googling the internet . However, none of recommendations has worked and helped . 
  I am using Solaris 10 X86 system . I had generated the key pair without any problem before . Can some experts explain why I have suddenly had this problem ? Does it help if I remove the old key pair ?
  (I had tried to run the key generation while running iostat, mpstat and using find in other windows. Is there any way I may view the system entropy in Solaris system ?)
  
  My GPG is pretty old :
  gpg (GnuPG) 1.4.10; Copyright (C) 2008 Free Software Foundation, Inc.
  How can I update GPG ? I have the file transfers with dozens of clients, which are essential for business . The update cannot affect the current public/private keys . Is it safe to upgrade on the current system or I have to build a new system ?
  Can the new version solve the problem with system entropy ?
  
  Thank you,
  Shaoping 
  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190402/a6bbf28f/attachment.html>

From thomas at glanzmann.de  Thu Apr  4 14:06:17 2019
From: thomas at glanzmann.de (Thomas Glanzmann)
Date: Thu, 4 Apr 2019 14:06:17 +0200
Subject: card-sized 4 Kbit RSA Smartcard recommendation with 3 slots
Message-ID: <20190404120616.GC31330@glanzmann.de>

Hello,
I'm looking for a recommendation for a cardsized 4 kbit RSA smartcard
with 3 keyslots which works with Linux und Windows and gnupg. Has anyone
a recommendation. At the moment I use yubikey but I aquired a laptop
with a smartcard reader that I would like to use in order to free up an
USB slot.

Cheers,
        Thomas


From thomas at glanzmann.de  Thu Apr  4 14:03:22 2019
From: thomas at glanzmann.de (Thomas Glanzmann)
Date: Thu, 4 Apr 2019 14:03:22 +0200
Subject: How to tell gpg not to start gpg-agent on a remote machines when
 using gpg agent forwarding
Message-ID: <20190404120322.GB31330@glanzmann.de>

Hello,
I'm using gpg using gpg agent forwarding over ssh on a remote system.
Sometimes my agent socket is not available. If I start any gpg
operation, it starts a new agent. Is there a configuration option that I
can specify so that gpg gives up is there is no socket or no agent
behind a socket instead of starting a new agent?

Cheers,
        Thomas


From peter at digitalbrains.com  Thu Apr  4 16:58:35 2019
From: peter at digitalbrains.com (Peter Lebbing)
Date: Thu, 4 Apr 2019 16:58:35 +0200
Subject: How to tell gpg not to start gpg-agent on a remote machines when
 using gpg agent forwarding
In-Reply-To: <20190404120322.GB31330@glanzmann.de>
References: <20190404120322.GB31330@glanzmann.de>
Message-ID: <b3d90c5d-dc13-fc7c-fe10-335e0f4a5809@digitalbrains.com>

On 04/04/2019 14:03, Thomas Glanzmann wrote:
> Is there a configuration option that I can specify so that gpg gives
> up is there is no socket or no agent behind a socket instead of
> starting a new agent?

From the man page:

| --no-autostart
|       Do not start the gpg-agent or the dirmngr if it has not yet been
|       started and its service is required.  This option is mostly use?
|       ful on machines where the connection to gpg-agent has been redi?
|       rected to another machines.   If  dirmngr  is  required  on  the
|       remote  machine,  it  may  be  started  manually  using  gpgconf
|       --launch dirmngr.

If you want to put this in the gpg.conf configuration file, drop the two
leading dashes (this is generally the case).

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 <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190404/f199e063/attachment.sig>

From peter at digitalbrains.com  Thu Apr  4 17:10:53 2019
From: peter at digitalbrains.com (Peter Lebbing)
Date: Thu, 4 Apr 2019 17:10:53 +0200
Subject: card-sized 4 Kbit RSA Smartcard recommendation with 3 slots
In-Reply-To: <20190404120616.GC31330@glanzmann.de>
References: <20190404120616.GC31330@glanzmann.de>
Message-ID: <c3a0e2ad-434b-a1e2-df9b-8993ddbdac51@digitalbrains.com>

On 04/04/2019 14:06, Thomas Glanzmann wrote:
> I'm looking for a recommendation for a cardsized 4 kbit RSA smartcard
> with 3 keyslots

Well, the ZeitControl card, which was the first OpenPGP Card on the
market, is now at version 3.3 which would seem to support what you ask
for.[1] I have no personal experience, I do have v2.0 cards (and v1.1).

I don't expect 4k RSA to be very snappy, though. You might want to
reconsider your choice of algorithm and/or length.

> At the moment I use yubikey but I aquired a laptop with a smartcard
> reader that I would like to use in order to free up an USB slot.

Be warned that there are many cardreaders that will not work with larger
keys (where "larger" can already mean 2k) or even work reliably at all
with free software. So your mileage may vary a lot.

HTH,

Peter.

[1] <https://www.floss-shop.de/en/security-privacy/smartcards/13/openpgp-smart-card-v3.3>

-- 
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 <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190404/c6fc5c26/attachment.sig>

From Jennifer.Mead at pacificorp.com  Thu Apr  4 16:16:58 2019
From: Jennifer.Mead at pacificorp.com (Mead, Jennifer)
Date: Thu, 4 Apr 2019 14:16:58 +0000
Subject: FW: yubikey public key
Message-ID: <7509913649a44c559cd4b1eb2d62bc90@SLCMBXW04VP.pacificorp.us>

Second try.

From: Mead, Jennifer
Sent: Monday, April 1, 2019 2:24 PM
To: 'gnupg-users-request at gnupg.org' <gnupg-users-request at gnupg.org>
Subject: yubikey public key

Hi Everyone,

I got a yubikey 5 working with Gnupg agent by writing the key direct to the card on CentOS 7.  Then I was tasked with writing documentation for others to do the same.   I have to admit that I had been at it quite a while (trying different ways of accomplishing it) and wasn't able to instant recall all my steps.

What other folks are struggling with (just guessing this is the issue) is that when they dump the public key (to move to another server and add to the authorized_keys file) they get a different style output than I do.  I get a string that ends with cardno:NNNNNNNNNNNN and they get a regular key (bigger and without card reference).

I am hoping that someone on this forum/list will have an easy answer to that problem.  I don't remember running a converter to change the public key format.  I don't remember doing anything special.  I did generate my key on the card, but I am having them do the same thing.  Generating direct to card is a security requirement here.

I tried to run gpg with the flag -export-ssh-key and that is not available on gpg2 on CentOS 7 (I get invalid option).  Not that I think that will fix my issue, I am just desperate to find what I did different to get the cardno:NNNNNNNNNNNN public key exported.  Any help is appreciated.

Regards,

Jennifer (Jen) Mead
Security Engineer
503.813.5373
Jennifer.Mead at pacificorp.com<mailto:Jennifer.Mead at pacificorp.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190404/c7edfcea/attachment-0001.html>

From andrewg at andrewg.com  Thu Apr  4 17:43:10 2019
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Thu, 4 Apr 2019 16:43:10 +0100
Subject: card-sized 4 Kbit RSA Smartcard recommendation with 3 slots
In-Reply-To: <c3a0e2ad-434b-a1e2-df9b-8993ddbdac51@digitalbrains.com>
References: <20190404120616.GC31330@glanzmann.de>
 <c3a0e2ad-434b-a1e2-df9b-8993ddbdac51@digitalbrains.com>
Message-ID: <e6baf459-1822-7831-9fb4-95e7b4b13955@andrewg.com>

On 04/04/2019 16:10, Peter Lebbing wrote:
> I don't expect 4k RSA to be very snappy, though. You might want to
> reconsider your choice of algorithm and/or length.

On the v2.1 Zeitcontrol cards, 4096 bit RSA takes a couple of seconds
per operation. This is fine if you're just doing bits and pieces, but
when using it heavily, e.g. as an ssh auth method over ansible, it can
get *very* sluggish.

-- 
Andrew Gallagher

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190404/78b542aa/attachment.sig>

From peter at digitalbrains.com  Thu Apr  4 17:44:20 2019
From: peter at digitalbrains.com (Peter Lebbing)
Date: Thu, 4 Apr 2019 17:44:20 +0200
Subject: FW: yubikey public key
In-Reply-To: <7509913649a44c559cd4b1eb2d62bc90@SLCMBXW04VP.pacificorp.us>
References: <7509913649a44c559cd4b1eb2d62bc90@SLCMBXW04VP.pacificorp.us>
Message-ID: <d8c32568-d2ce-0525-39b3-39b6984fbff2@digitalbrains.com>

Hi Jennifer,

On 04/04/2019 16:16, Mead, Jennifer wrote:
> What other folks are struggling with (just guessing this is the issue)
> is that when they dump the public key (to move to another server and
> add to the authorized_keys file) they get a different style output
> than I do.  I get a string that ends with cardno:NNNNNNNNNNNN and they
> get a regular key (bigger and without card reference).

I think what you are looking for is

$ ssh-add -L

which will dump all the public keys known to the SSH agent. If properly
set up, your SSH agent will be gpg-agent, unless I misunderstand your
scenario.

The others are probably looking at an OpenPGP public key rather than an
SSH public key (again, a guess).

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 <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190404/5f1cff8f/attachment.sig>

From wk at gnupg.org  Thu Apr  4 19:49:44 2019
From: wk at gnupg.org (Werner Koch)
Date: Thu, 04 Apr 2019 19:49:44 +0200
Subject: FW: yubikey public key
In-Reply-To: <7509913649a44c559cd4b1eb2d62bc90@SLCMBXW04VP.pacificorp.us>
 (Jennifer Mead's message of "Thu, 4 Apr 2019 14:16:58 +0000")
References: <7509913649a44c559cd4b1eb2d62bc90@SLCMBXW04VP.pacificorp.us>
Message-ID: <8736mxpsnb.fsf@wheatstone.g10code.de>

On Thu,  4 Apr 2019 14:16, Jennifer.Mead at pacificorp.com said:

> I got a yubikey 5 working with Gnupg agent by writing the key direct
> to the card on CentOS 7.  Then I was tasked with writing documentation

FWIW, GnuPG 2.3 will have full support for Yubikey 4 and 5 which
includes support for the PIV application also with gpg.  We already have
a Debian packages for this is an early preview.  The 2.3 code base has a
some non-severe but annoying bugs.  We hope to do a first release this
summer.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190404/80ccf547/attachment.sig>

From andre at ockers.eu  Sat Apr  6 14:43:31 2019
From: andre at ockers.eu (=?UTF-8?Q?Andr=c3=a9_Ockers?=)
Date: Sat, 6 Apr 2019 14:43:31 +0200
Subject: Generating revocation certificate
Message-ID: <f29619a4-3857-cf89-e269-1fe228439b9c@ockers.eu>

Dear all,

After I've created a new key and uploaded it to a key server, I ran into
something when generating a revocation certificate.

In Seahorse, I could select the right (new) key and make a revocation
certificate from there.

But when I tried to do the some thing in Bash I ran into the following:

$ gpg -a --output andre at ockers.eu.asc.revoke --gen-revoke andre at ockers.eu

sec? 4096R/F5FE3668 2014-07-31 Andr? Ockers <andre at ockers.eu>

Which is the fingerprint of the old key.

What happened and what can I do?

Thank you very much.

Best regards,

Andr? Ockers


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190406/564209bd/attachment.sig>

From ml at mareichelt.com  Sat Apr  6 15:04:36 2019
From: ml at mareichelt.com (Markus Reichelt)
Date: Sat, 6 Apr 2019 15:04:36 +0200
Subject: Generating revocation certificate
In-Reply-To: <f29619a4-3857-cf89-e269-1fe228439b9c@ockers.eu>
References: <f29619a4-3857-cf89-e269-1fe228439b9c@ockers.eu>
Message-ID: <20190406130436.GA2370@pc21.mareichelt.com>

* Andr? Ockers <andre at ockers.eu> wrote:

> But when I tried to do the some thing in Bash I ran into the following:
> 
> $ gpg -a --output andre at ockers.eu.asc.revoke --gen-revoke andre at ockers.eu
> 
> sec? 4096R/F5FE3668 2014-07-31 Andr? Ockers <andre at ockers.eu>
> 
> Which is the fingerprint of the old key.
> 
> What happened and what can I do?

you almost had it, just use the fingerprint of the key in question
instead of an email address:

gpg -a --output andre at ockers.eu.asc.revoke --gen-revoke 7CD3FBC8F6005ED5

will create a revocation cert for the key you signed your mail with.

HTH

-- 
left blank, right bald
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190406/d19e3028/attachment-0001.sig>

From andre at ockers.eu  Sat Apr  6 18:04:51 2019
From: andre at ockers.eu (=?UTF-8?Q?Andr=c3=a9_Ockers?=)
Date: Sat, 6 Apr 2019 18:04:51 +0200
Subject: Generating revocation certificate
In-Reply-To: <20190406130436.GA2370@pc21.mareichelt.com>
References: <f29619a4-3857-cf89-e269-1fe228439b9c@ockers.eu>
 <20190406130436.GA2370@pc21.mareichelt.com>
Message-ID: <b107365f-5fc4-c9a3-f894-2f1da615b645@ockers.eu>

Dear mr. Reichelt,


Thank you for your answer.


Op 06-04-19 om 15:04 schreef Markus Reichelt:
> gpg -a --output andre at ockers.eu.asc.revoke --gen-revoke 7CD3FBC8F6005ED5

This leads to the following:

gpg: secret key "7CD3FBC8F6005ED5" not found: eof

Best regards,

Andr? Ockers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190406/66460a5a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190406/66460a5a/attachment.sig>

From ml at mareichelt.com  Sat Apr  6 18:32:29 2019
From: ml at mareichelt.com (Markus Reichelt)
Date: Sat, 6 Apr 2019 18:32:29 +0200
Subject: Generating revocation certificate
In-Reply-To: <b107365f-5fc4-c9a3-f894-2f1da615b645@ockers.eu>
References: <f29619a4-3857-cf89-e269-1fe228439b9c@ockers.eu>
 <20190406130436.GA2370@pc21.mareichelt.com>
 <b107365f-5fc4-c9a3-f894-2f1da615b645@ockers.eu>
Message-ID: <20190406163229.GA29885@pc21.mareichelt.com>

* Andr? Ockers <andre at ockers.eu> wrote:

> Op 06-04-19 om 15:04 schreef Markus Reichelt:
> > gpg -a --output andre at ockers.eu.asc.revoke --gen-revoke 7CD3FBC8F6005ED5
> 
> This leads to the following:
> 
> gpg: secret key "7CD3FBC8F6005ED5" not found: eof

i'm using on slackware64-current (if you are using windows, all hands
are off)

gpg --version
gpg (GnuPG) 2.2.15
libgcrypt 1.8.4

it looks to me you are lacking access to the secret key - you
need it in order to be able to create a revocation cert. but since
you are able to still sign mails (to this list, e.g.) that key must
be there still. 

if you run "gpg --list-keys andre at ockers.eu" (with gpg2)

does that fingerprint show up?:

0288A46FA7FF9A9B5BF64D6B7CD3FBC8F6005ED5


anyhow, if you lost (access to) that key in question, it's too late
to create a revocation cert.  best practice is to deal with that when
deploying a new key.

HTH

-- 
left blank, right bald
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190406/1915d36e/attachment.sig>

From jeandavid8 at verizon.net  Sat Apr  6 18:50:51 2019
From: jeandavid8 at verizon.net (Jean-David Beyer)
Date: Sat, 6 Apr 2019 12:50:51 -0400
Subject: Generating revocation certificate
In-Reply-To: <20190406163229.GA29885@pc21.mareichelt.com>
References: <f29619a4-3857-cf89-e269-1fe228439b9c@ockers.eu>
 <20190406130436.GA2370@pc21.mareichelt.com>
 <b107365f-5fc4-c9a3-f894-2f1da615b645@ockers.eu>
 <20190406163229.GA29885@pc21.mareichelt.com>
Message-ID: <f7cba905-8419-9d1c-5a17-d8c818374c11@verizon.net>

On 4/6/19 12:32 PM, Markus Reichelt wrote:
> i'm using on slackware64-current (if you are using windows, all hands
> are off)
> 
> gpg --version
> gpg (GnuPG) 2.2.15
> libgcrypt 1.8.4

Mine's bigger than yours (older, too):

$ gpg --version
gpg (GnuPG) 2.0.14
libgcrypt 1.4.5
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA
Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128,
        CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2


-- 
  .~.  Jean-David Beyer
  /V\  PGP-Key:166D840A 0C610C8B
 /( )\ Shrewsbury, New Jersey
 ^^-^^ 12:45:01 up 22:44, 2 users, load average: 4.26, 4.55, 4.53

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190406/583d2a69/attachment.sig>

From andre at ockers.eu  Sat Apr  6 20:24:11 2019
From: andre at ockers.eu (=?UTF-8?Q?Andr=c3=a9_Ockers?=)
Date: Sat, 6 Apr 2019 20:24:11 +0200
Subject: Generating revocation certificate
In-Reply-To: <20190406163229.GA29885@pc21.mareichelt.com>
References: <f29619a4-3857-cf89-e269-1fe228439b9c@ockers.eu>
 <20190406130436.GA2370@pc21.mareichelt.com>
 <b107365f-5fc4-c9a3-f894-2f1da615b645@ockers.eu>
 <20190406163229.GA29885@pc21.mareichelt.com>
Message-ID: <832fbfaf-c187-e7b7-79ec-31c43bde973c@ockers.eu>

Hi mr. Reichelt and list,



Op 06-04-19 om 18:32 schreef Markus Reichelt:
> * Andr? Ockers <andre at ockers.eu> wrote:
>
>> Op 06-04-19 om 15:04 schreef Markus Reichelt:
>>> gpg -a --output andre at ockers.eu.asc.revoke --gen-revoke 7CD3FBC8F6005ED5
>> This leads to the following:
>>
>> gpg: secret key "7CD3FBC8F6005ED5" not found: eof
> i'm using on slackware64-current (if you are using windows, all hands
> are off)
>
> gpg --version
> gpg (GnuPG) 2.2.15
> libgcrypt 1.8.4

I'm using (up to date) Trisquel

$ gpg --version
gpg (GnuPG) 1.4.20

$ gpg2 --version
gpg (GnuPG) 2.1.11
libgcrypt 1.6.5

> it looks to me you are lacking access to the secret key - you
> need it in order to be able to create a revocation cert. but since
> you are able to still sign mails (to this list, e.g.) that key must
> be there still. 
>
> if you run "gpg --list-keys andre at ockers.eu" (with gpg2)
>
> does that fingerprint show up?:
>
> 0288A46FA7FF9A9B5BF64D6B7CD3FBC8F6005ED5

$ gpg2 --list-keys andre at ockers.eu
pub?? rsa4096/F5FE3668 2014-07-31 [SCA] [revoked: 2018-12-29]
uid???????? [ revoked] Andr? Ockers <andre at ockers.eu>
uid???????? [ revoked] Andr? Ockers <ao at fsfe.org>

pub?? rsa4096/F6005ED5 2018-12-29 [SCA]
uid???????? [ultimate] Andr? Ockers <ao at fsfe.org>
uid???????? [ultimate] Andr? Ockers <andre at ockers.eu>
(plus a subkey)

> anyhow, if you lost (access to) that key in question, it's too late
> to create a revocation cert.  best practice is to deal with that when
> deploying a new key.

I already made a revocation certificate with Enigmail.

Thank you.

Best regards,

Andr? Ockers


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190406/a5126cbe/attachment.sig>

From peter at digitalbrains.com  Sat Apr  6 21:02:53 2019
From: peter at digitalbrains.com (Peter Lebbing)
Date: Sat, 6 Apr 2019 21:02:53 +0200
Subject: Generating revocation certificate
In-Reply-To: <832fbfaf-c187-e7b7-79ec-31c43bde973c@ockers.eu>
References: <f29619a4-3857-cf89-e269-1fe228439b9c@ockers.eu>
 <20190406130436.GA2370@pc21.mareichelt.com>
 <b107365f-5fc4-c9a3-f894-2f1da615b645@ockers.eu>
 <20190406163229.GA29885@pc21.mareichelt.com>
 <832fbfaf-c187-e7b7-79ec-31c43bde973c@ockers.eu>
Message-ID: <09d88a24-bad3-3046-cfe8-ba20e26388ba@digitalbrains.com>

On 06/04/2019 20:24, Andr? Ockers wrote:
>>> gpg: secret key "7CD3FBC8F6005ED5" not found: eof
> I'm using (up to date) Trisquel
> 
> $ gpg --version
> gpg (GnuPG) 1.4.20
> 
> $ gpg2 --version
> gpg (GnuPG) 2.1.11
> libgcrypt 1.6.5

The error message is really unclear, but the problem probably is that
you should have used "gpg2" instead of "gpg", consistently. So just
leave "gpg" behind and only use "gpg2" ever. Well, until an updated
Trisquel drops the old 1.4 and both refer to the same version.

GnuPG 1.4 and 2.1+ do not mix well in certain scenarios. You probably
encountered one.

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 <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190406/94a00f72/attachment-0001.sig>

From peter at digitalbrains.com  Sat Apr  6 21:10:04 2019
From: peter at digitalbrains.com (Peter Lebbing)
Date: Sat, 6 Apr 2019 21:10:04 +0200
Subject: Generating revocation certificate
In-Reply-To: <f7cba905-8419-9d1c-5a17-d8c818374c11@verizon.net>
References: <f29619a4-3857-cf89-e269-1fe228439b9c@ockers.eu>
 <20190406130436.GA2370@pc21.mareichelt.com>
 <b107365f-5fc4-c9a3-f894-2f1da615b645@ockers.eu>
 <20190406163229.GA29885@pc21.mareichelt.com>
 <f7cba905-8419-9d1c-5a17-d8c818374c11@verizon.net>
Message-ID: <05576e9a-c481-8555-5193-558391c5c9a0@digitalbrains.com>

On 06/04/2019 18:50, Jean-David Beyer via Gnupg-users wrote:
> Mine's bigger than yours (older, too):
> 
> $ gpg --version
> gpg (GnuPG) 2.0.14

Yeah, and it's probably high time to put gramps out to pasture as
well... ;-) That's a seriously old, unsupported version.

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 <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190406/0b1572c9/attachment.sig>

From andre at ockers.eu  Sat Apr  6 21:21:12 2019
From: andre at ockers.eu (=?UTF-8?Q?Andr=c3=a9_Ockers?=)
Date: Sat, 6 Apr 2019 21:21:12 +0200
Subject: Generating revocation certificate
In-Reply-To: <09d88a24-bad3-3046-cfe8-ba20e26388ba@digitalbrains.com>
References: <f29619a4-3857-cf89-e269-1fe228439b9c@ockers.eu>
 <20190406130436.GA2370@pc21.mareichelt.com>
 <b107365f-5fc4-c9a3-f894-2f1da615b645@ockers.eu>
 <20190406163229.GA29885@pc21.mareichelt.com>
 <832fbfaf-c187-e7b7-79ec-31c43bde973c@ockers.eu>
 <09d88a24-bad3-3046-cfe8-ba20e26388ba@digitalbrains.com>
Message-ID: <edfcb04f-bb33-984e-9120-1bf4588cefea@ockers.eu>

Hi Peter and list,


Op 06-04-19 om 21:02 schreef Peter Lebbing:
> The error message is really unclear, but the problem probably is that
> you should have used "gpg2" instead of "gpg", consistently. So just
> leave "gpg" behind and only use "gpg2" ever. Well, until an updated
> Trisquel drops the old 1.4 and both refer to the same version.
>
> GnuPG 1.4 and 2.1+ do not mix well in certain scenarios. You probably
> encountered one.

I'm now running Synaptic and when I try to remove gnupg, a pop up tells
me that automatically the following packages will be removed:

  * apt,
  * apt-listchanges,
  * apt-utils,
  * libcryptui0a,
  * seahorse-daemon,
  * seahorse-nautilus,
  * signing-party,
  * tasksel,
  * tasksel-data,
  * trisquel-desktop-common,
  * trisquel-keyring,
  * trisquel-minimal,
  * trisquel-release-upgrader-gtk,
  * unattended-upgrades,
  * update-manager,
  * update-notifier and
  * update-notifier-common

which would probably be a bad idea, wouldn't it?

Thank you,

Best regards,

Andr? Ockers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190406/c88a3ba9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190406/c88a3ba9/attachment.sig>

From peter at digitalbrains.com  Sat Apr  6 21:30:38 2019
From: peter at digitalbrains.com (Peter Lebbing)
Date: Sat, 6 Apr 2019 21:30:38 +0200
Subject: Generating revocation certificate
In-Reply-To: <edfcb04f-bb33-984e-9120-1bf4588cefea@ockers.eu>
References: <f29619a4-3857-cf89-e269-1fe228439b9c@ockers.eu>
 <20190406130436.GA2370@pc21.mareichelt.com>
 <b107365f-5fc4-c9a3-f894-2f1da615b645@ockers.eu>
 <20190406163229.GA29885@pc21.mareichelt.com>
 <832fbfaf-c187-e7b7-79ec-31c43bde973c@ockers.eu>
 <09d88a24-bad3-3046-cfe8-ba20e26388ba@digitalbrains.com>
 <edfcb04f-bb33-984e-9120-1bf4588cefea@ockers.eu>
Message-ID: <3496c617-20c6-49de-9595-22196d86948a@digitalbrains.com>

Hi Andr?,

On 06/04/2019 21:21, Andr? Ockers wrote:
> which would probably be a bad idea, wouldn't it?

Quite! :-)

Your operating system probably still requires GnuPG 1.4, so you can't
remove it. But you can solemnly pledge not to use it... I wouldn't mess
with the "gpg" binary, though. Don't use some method to prevent your
access to it, or you might silently corrupt some utility that you use
under your user account that expects it to be 1.4.

This was all quite an ordeal for Debian to get right, there are a lot of
subtleties to deal with. I really think your best bet is to get that "2"
suffix in your muscle memory for when you use the command line.

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 <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190406/cbeb95db/attachment.sig>

From juergen at bruckner.tk  Sun Apr  7 20:03:57 2019
From: juergen at bruckner.tk (Juergen Bruckner)
Date: Sun, 7 Apr 2019 20:03:57 +0200
Subject: Generating revocation certificate
In-Reply-To: <edfcb04f-bb33-984e-9120-1bf4588cefea@ockers.eu>
References: <f29619a4-3857-cf89-e269-1fe228439b9c@ockers.eu>
 <20190406130436.GA2370@pc21.mareichelt.com>
 <b107365f-5fc4-c9a3-f894-2f1da615b645@ockers.eu>
 <20190406163229.GA29885@pc21.mareichelt.com>
 <832fbfaf-c187-e7b7-79ec-31c43bde973c@ockers.eu>
 <09d88a24-bad3-3046-cfe8-ba20e26388ba@digitalbrains.com>
 <edfcb04f-bb33-984e-9120-1bf4588cefea@ockers.eu>
Message-ID: <6fed0753-ad30-57c1-7ce5-312ed7935581@bruckner.tk>

Hi Andr?,

which Operating System do you use?

regards
Juergen

Am 06.04.19 um 21:21 schrieb Andr? Ockers:
> Hi Peter and list,
> 
> 
> Op 06-04-19 om 21:02 schreef Peter Lebbing:
>> The error message is really unclear, but the problem probably is that
>> you should have used "gpg2" instead of "gpg", consistently. So just
>> leave "gpg" behind and only use "gpg2" ever. Well, until an updated
>> Trisquel drops the old 1.4 and both refer to the same version.
>>
>> GnuPG 1.4 and 2.1+ do not mix well in certain scenarios. You probably
>> encountered one.
> 
> I'm now running Synaptic and when I try to remove gnupg, a pop up tells
> me that automatically the following packages will be removed:
> 
>   * apt,
>   * apt-listchanges,
>   * apt-utils,
>   * libcryptui0a,
>   * seahorse-daemon,
>   * seahorse-nautilus,
>   * signing-party,
>   * tasksel,
>   * tasksel-data,
>   * trisquel-desktop-common,
>   * trisquel-keyring,
>   * trisquel-minimal,
>   * trisquel-release-upgrader-gtk,
>   * unattended-upgrades,
>   * update-manager,
>   * update-notifier and
>   * update-notifier-common
> 
> which would probably be a bad idea, wouldn't it?
> 
> Thank you,
> 
> Best regards,
> 
> Andr? Ockers
> 
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 

-- 
Juergen M. Bruckner
juergen at bruckner.tk

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3894 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190407/5e4f5ec5/attachment-0001.bin>

From andre at ockers.eu  Mon Apr  8 20:33:07 2019
From: andre at ockers.eu (=?UTF-8?Q?Andr=c3=a9_Ockers?=)
Date: Mon, 8 Apr 2019 20:33:07 +0200
Subject: Generating revocation certificate
In-Reply-To: <6fed0753-ad30-57c1-7ce5-312ed7935581@bruckner.tk>
References: <f29619a4-3857-cf89-e269-1fe228439b9c@ockers.eu>
 <20190406130436.GA2370@pc21.mareichelt.com>
 <b107365f-5fc4-c9a3-f894-2f1da615b645@ockers.eu>
 <20190406163229.GA29885@pc21.mareichelt.com>
 <832fbfaf-c187-e7b7-79ec-31c43bde973c@ockers.eu>
 <09d88a24-bad3-3046-cfe8-ba20e26388ba@digitalbrains.com>
 <edfcb04f-bb33-984e-9120-1bf4588cefea@ockers.eu>
 <6fed0753-ad30-57c1-7ce5-312ed7935581@bruckner.tk>
Message-ID: <702b1393-4e66-877e-4204-947b9565b642@ockers.eu>

Hi Juergen,


Op 07-04-19 om 20:03 schreef Juergen Bruckner:
> which Operating System do you use?

I'm using (up to date) Trisquel.

Best regards,

Andr? Ockers

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190408/97da45cd/attachment.sig>

From juergen at bruckner.tk  Mon Apr  8 20:59:49 2019
From: juergen at bruckner.tk (Juergen Bruckner)
Date: Mon, 8 Apr 2019 20:59:49 +0200
Subject: Generating revocation certificate
In-Reply-To: <702b1393-4e66-877e-4204-947b9565b642@ockers.eu>
References: <f29619a4-3857-cf89-e269-1fe228439b9c@ockers.eu>
 <20190406130436.GA2370@pc21.mareichelt.com>
 <b107365f-5fc4-c9a3-f894-2f1da615b645@ockers.eu>
 <20190406163229.GA29885@pc21.mareichelt.com>
 <832fbfaf-c187-e7b7-79ec-31c43bde973c@ockers.eu>
 <09d88a24-bad3-3046-cfe8-ba20e26388ba@digitalbrains.com>
 <edfcb04f-bb33-984e-9120-1bf4588cefea@ockers.eu>
 <6fed0753-ad30-57c1-7ce5-312ed7935581@bruckner.tk>
 <702b1393-4e66-877e-4204-947b9565b642@ockers.eu>
Message-ID: <415dcf81-8850-5b82-c633-10192178b3fe@bruckner.tk>

Hello Andr?

> I'm using (up to date) Trisquel.
> 
That is a Ubuntu-Flavor based on Ubuntu Xenial (16.04 LTS).
This Version needs GnuPG 1.x for the signing/validating of the
Repository-Keys. So you can't uninstall GnuPG 1.x

regards
Juergen

-- 
Juergen M. Bruckner
juergen at bruckner.tk

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3894 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190408/02edb3d5/attachment.bin>

From peter at digitalbrains.com  Wed Apr 10 11:45:08 2019
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 10 Apr 2019 11:45:08 +0200
Subject: Storing key on multiple smartcards
In-Reply-To: <6c6e635d-d52c-e8d1-bf2f-0083e4cfe147@tsundere.moe>
References: <b41b05b6-39ac-d744-718e-3adf280459c5@tsundere.moe>
 <87tvf6loi8.fsf@iwagami.gniibe.org>
 <6c6e635d-d52c-e8d1-bf2f-0083e4cfe147@tsundere.moe>
Message-ID: <3b2c5935-0536-c974-5c1f-1589b7b20e54@digitalbrains.com>

I agree that GnuPG would benefit from preferring keys that are
available, both in the sense of different subkeys and different
smartcards with copies of the same subkey, in the sense you describe.
But let me pick out one detail you mentioned that is a different issue.

On 10/04/2019 09:38, Frederick Zhang via Gnupg-devel wrote:
> Currently "keytocard" replaces the keygrip with a shadow key (which I
> don't think works pretty intuitively in case of multiple smart cards,
> as it requires users to manually back up the subkey beforehand to
> transfer the same key to multiple cards)

It's less difficult than that. After a "keytocard", simply exit the
--edit-key interaction without saving, and the key will still be
on disk as well. So use "quit" or Ctrl-D rather than "save", and
confirm that you wish to exit without saving changes.

Not really intuitive, but less bothersome than backups and restores. I
think maybe "keytocard" should have an option to just leave it on disk
as well. And then you can just insert all your smartcards you want the
key on and "keytocard" them one after the other without exiting the
--edit-key menu.

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 <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190410/73a0200b/attachment-0001.sig>

From peter at digitalbrains.com  Wed Apr 10 11:57:29 2019
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 10 Apr 2019 11:57:29 +0200
Subject: Please ignore: Storing key on multiple smartcards
In-Reply-To: <3b2c5935-0536-c974-5c1f-1589b7b20e54@digitalbrains.com>
References: <b41b05b6-39ac-d744-718e-3adf280459c5@tsundere.moe>
 <87tvf6loi8.fsf@iwagami.gniibe.org>
 <6c6e635d-d52c-e8d1-bf2f-0083e4cfe147@tsundere.moe>
 <3b2c5935-0536-c974-5c1f-1589b7b20e54@digitalbrains.com>
Message-ID: <a79588a1-6c89-092a-c736-464d1b2c07b6@digitalbrains.com>

Sorry for the noise. This message was intended to go to gnupg-devel, but
I screwed up. Please ignore it.

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190410/402bfb4b/attachment.sig>

From matheus.a.m.moreira at gmail.com  Wed Apr 10 15:25:08 2019
From: matheus.a.m.moreira at gmail.com (Matheus Afonso Martins Moreira)
Date: Wed, 10 Apr 2019 10:25:08 -0300
Subject: How do I delete secret subkeys correctly?
Message-ID: <CAPtHdAUEo6a7AONjPyDLLDzkdPDy9aYrpy+iGiP2UCd_zrzh6w@mail.gmail.com>

I had some revoked subkeys that I was not going to use anymore.
I thought it would be a good idea to delete their secret keys,
so I used the gpg --delete-secret-keys command to do it.
I ended up accidentally deleting all my keys instead,
including my primary key.

I'm trying to learn from my mistake but I don't understand how or why
this happened.

I was able to reproduce what I did.
First, I generated a primary key and a subkey:

    $ gpg --batch --passphrase '' --quick-generate-key 'test key' rsa4096 cert 0
    # Generated primary key D7D79C32883EA862C586881DA52099E0E7EB77A5

    $ gpg --batch --passphrase '' \
        --quick-add-key D7D79C32883EA862C586881DA52099E0E7EB77A5 \
        rsa4096 sign 0

    $ gpg --list-keys
    pub   rsa4096/0xA52099E0E7EB77A5 2019-04-10 [C]
          Key fingerprint = D7D7 9C32 883E A862 C586  881D A520 99E0 E7EB 77A5
    uid                   [ultimate] test key
    sub   rsa4096/0x20AA2F4F7A28CD01 2019-04-10 [S]
          Key fingerprint = 9CAE 802D A78E 4624 BD8F  88FE 20AA 2F4F 7A28 CD01

Having generated a primary key and subkey,
I asked gpg to delete the subkey by specifying its fingerprint.
However, instead of operating on the specified subkey,
gpg asked me to confirm the deletion of the primary key!

    $ gpg --delete-secret-keys 9CAE802DA78E4624BD8F88FE20AA2F4F7A28CD01

    sec  rsa4096/0xA52099E0E7EB77A5 2019-04-10 test key

    Delete this key from the keyring? (y/N)

I admit that I failed to check the fingerprint reported by gpg
before confirming all three prompts, including a graphical pop-up.
However, I did double check the fingerprint I gave as argument.
In my understanding, the program decided to operate on a different key.
I specified the subkey but it acted as if I had given the primary key instead.

It was suggested that I append an exclamation mark to the fingerprint.
Indeed, the manual does seem to support this suggestion:

> an exclamation mark (!) may be appended
> to force using the specified primary or secondary key
> and not to try and calculate which primary or secondary key to use.

When I tried it with new keys, it did not seem to have any effect.

    $ gpg --delete-secret-keys 5B139477AE36C2F5D03C29E6920FD2FB0019253E!

    sec  rsa4096/0x8A1C31D584422F7A 2019-04-10 test key

    Delete this key from the keyring? (y/N)

gpg still tried to delete the primary key instead of the specified subkey.

It was also suggested that I use the subkey's ID instead of the fingerprint.
I generated new keys, tried it and it did not work either.

    $ gpg --delete-secret-keys 8395C88AD6549DEE

    sec  rsa4096/0x076968E9FF7991BC 2019-04-10 test key

    Delete this key from the keyring? (y/N)

    $ gpg --delete-secret-keys 8395C88AD6549DEE!

    sec  rsa4096/0x076968E9FF7991BC 2019-04-10 test key

    Delete this key from the keyring? (y/N)

gpg always deletes the primary key and all subkeys,
no matter what input I give it.

I am using GNU Privacy Guard 2.2.15 on Arch Linux x86_64.
I don't want to make this kind of mistake again.
Am I using the program correctly? If not, what is the correct way to do this?
Is deleting subkeys something I am not supposed to do?


From peter at digitalbrains.com  Wed Apr 10 17:24:24 2019
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 10 Apr 2019 17:24:24 +0200
Subject: How do I delete secret subkeys correctly?
In-Reply-To: <CAPtHdAUEo6a7AONjPyDLLDzkdPDy9aYrpy+iGiP2UCd_zrzh6w@mail.gmail.com>
References: <CAPtHdAUEo6a7AONjPyDLLDzkdPDy9aYrpy+iGiP2UCd_zrzh6w@mail.gmail.com>
Message-ID: <1d2884c0-6045-604e-3286-d0b910c22525@digitalbrains.com>

On 10/04/2019 15:25, Matheus Afonso Martins Moreira wrote:
> If not, what is the correct way to do this?

$ gpg --edit-key [KEYID]
gpg> key N
gpg> delkey

Where N is the number of the subkey you want to delete; they are
numbered 1 for the first one listed and so on. It will indicate with a
"*" next to the "ssb" line which one(s) you have selected. Deselect by
another "key N"; it's a toggle.

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 <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190410/59a32ddf/attachment.sig>

From peter at digitalbrains.com  Wed Apr 10 17:28:54 2019
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 10 Apr 2019 17:28:54 +0200
Subject: How do I delete secret subkeys correctly?
In-Reply-To: <1d2884c0-6045-604e-3286-d0b910c22525@digitalbrains.com>
References: <CAPtHdAUEo6a7AONjPyDLLDzkdPDy9aYrpy+iGiP2UCd_zrzh6w@mail.gmail.com>
 <1d2884c0-6045-604e-3286-d0b910c22525@digitalbrains.com>
Message-ID: <03c16dff-d826-4a9c-9207-8f9420049764@digitalbrains.com>

On 10/04/2019 17:24, Peter Lebbing wrote:
> gpg> delkey

Sorry, my fatigued head was being silly. That's for deleting the public
part, not the secret part. I don't think I know the way to delete the
secret part when you just want to delete some subkey.

Sorry,

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 <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190410/d12459c2/attachment.sig>

From bex at pobox.com  Wed Apr 10 17:10:09 2019
From: bex at pobox.com (Brian Exelbierd)
Date: Wed, 10 Apr 2019 11:10:09 -0400
Subject: How do I delete secret subkeys correctly?
In-Reply-To: <CAPtHdAUEo6a7AONjPyDLLDzkdPDy9aYrpy+iGiP2UCd_zrzh6w@mail.gmail.com>
References: <CAPtHdAUEo6a7AONjPyDLLDzkdPDy9aYrpy+iGiP2UCd_zrzh6w@mail.gmail.com>
Message-ID: <19fb4345-c5da-41b3-ad6c-8111bb456d37@www.fastmail.com>



On Wed, Apr 10, 2019, at 5:06 PM, Matheus Afonso Martins Moreira wrote:
> I had some revoked subkeys that I was not going to use anymore.
> I thought it would be a good idea to delete their secret keys,
> so I used the gpg --delete-secret-keys command to do it.
> I ended up accidentally deleting all my keys instead,
> including my primary key.

I did this with 

$ gpg2 --expert --edit-key <key>
key N - to select hte proper subkey
delkey

regards,

bex

> 
> I'm trying to learn from my mistake but I don't understand how or why
> this happened.
> 
> I was able to reproduce what I did.
> First, I generated a primary key and a subkey:
> 
>     $ gpg --batch --passphrase '' --quick-generate-key 'test key' rsa4096 cert 0
>     # Generated primary key D7D79C32883EA862C586881DA52099E0E7EB77A5
> 
>     $ gpg --batch --passphrase '' \
>         --quick-add-key D7D79C32883EA862C586881DA52099E0E7EB77A5 \
>         rsa4096 sign 0
> 
>     $ gpg --list-keys
>     pub   rsa4096/0xA52099E0E7EB77A5 2019-04-10 [C]
>           Key fingerprint = D7D7 9C32 883E A862 C586  881D A520 99E0 E7EB 77A5
>     uid                   [ultimate] test key
>     sub   rsa4096/0x20AA2F4F7A28CD01 2019-04-10 [S]
>           Key fingerprint = 9CAE 802D A78E 4624 BD8F  88FE 20AA 2F4F 7A28 CD01
> 
> Having generated a primary key and subkey,
> I asked gpg to delete the subkey by specifying its fingerprint.
> However, instead of operating on the specified subkey,
> gpg asked me to confirm the deletion of the primary key!
> 
>     $ gpg --delete-secret-keys 9CAE802DA78E4624BD8F88FE20AA2F4F7A28CD01
> 
>     sec  rsa4096/0xA52099E0E7EB77A5 2019-04-10 test key
> 
>     Delete this key from the keyring? (y/N)
> 
> I admit that I failed to check the fingerprint reported by gpg
> before confirming all three prompts, including a graphical pop-up.
> However, I did double check the fingerprint I gave as argument.
> In my understanding, the program decided to operate on a different key.
> I specified the subkey but it acted as if I had given the primary key instead.
> 
> It was suggested that I append an exclamation mark to the fingerprint.
> Indeed, the manual does seem to support this suggestion:
> 
> > an exclamation mark (!) may be appended
> > to force using the specified primary or secondary key
> > and not to try and calculate which primary or secondary key to use.
> 
> When I tried it with new keys, it did not seem to have any effect.
> 
>     $ gpg --delete-secret-keys 5B139477AE36C2F5D03C29E6920FD2FB0019253E!
> 
>     sec  rsa4096/0x8A1C31D584422F7A 2019-04-10 test key
> 
>     Delete this key from the keyring? (y/N)
> 
> gpg still tried to delete the primary key instead of the specified subkey.
> 
> It was also suggested that I use the subkey's ID instead of the fingerprint.
> I generated new keys, tried it and it did not work either.
> 
>     $ gpg --delete-secret-keys 8395C88AD6549DEE
> 
>     sec  rsa4096/0x076968E9FF7991BC 2019-04-10 test key
> 
>     Delete this key from the keyring? (y/N)
> 
>     $ gpg --delete-secret-keys 8395C88AD6549DEE!
> 
>     sec  rsa4096/0x076968E9FF7991BC 2019-04-10 test key
> 
>     Delete this key from the keyring? (y/N)
> 
> gpg always deletes the primary key and all subkeys,
> no matter what input I give it.
> 
> I am using GNU Privacy Guard 2.2.15 on Arch Linux x86_64.
> I don't want to make this kind of mistake again.
> Am I using the program correctly? If not, what is the correct way to do this?
> Is deleting subkeys something I am not supposed to do?
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>


From angel at pgp.16bits.net  Thu Apr 11 02:37:19 2019
From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=)
Date: Thu, 11 Apr 2019 02:37:19 +0200
Subject: Generating revocation certificate
In-Reply-To: <3496c617-20c6-49de-9595-22196d86948a@digitalbrains.com>
References: <f29619a4-3857-cf89-e269-1fe228439b9c@ockers.eu>
 <20190406130436.GA2370@pc21.mareichelt.com>
 <b107365f-5fc4-c9a3-f894-2f1da615b645@ockers.eu>
 <20190406163229.GA29885@pc21.mareichelt.com>
 <832fbfaf-c187-e7b7-79ec-31c43bde973c@ockers.eu>
 <09d88a24-bad3-3046-cfe8-ba20e26388ba@digitalbrains.com>
 <edfcb04f-bb33-984e-9120-1bf4588cefea@ockers.eu>
 <3496c617-20c6-49de-9595-22196d86948a@digitalbrains.com>
Message-ID: <1554943039.1165.42.camel@16bits.net>

On 2019-04-06 at 21:30 +0200, Peter Lebbing wrote:
> This was all quite an ordeal for Debian to get right, there are a lot of
> subtleties to deal with. I really think your best bet is to get that "2"
> suffix in your muscle memory for when you use the command line.

Why should I need to remember to manually add that .'2' every time?

I use an even simpler approach:

 echo alias gpg=gpg2 >> ~/.bashrc


Best regards


From peter at digitalbrains.com  Thu Apr 11 10:24:40 2019
From: peter at digitalbrains.com (Peter Lebbing)
Date: Thu, 11 Apr 2019 10:24:40 +0200
Subject: Generating revocation certificate
In-Reply-To: <1554943039.1165.42.camel@16bits.net>
References: <f29619a4-3857-cf89-e269-1fe228439b9c@ockers.eu>
 <20190406130436.GA2370@pc21.mareichelt.com>
 <b107365f-5fc4-c9a3-f894-2f1da615b645@ockers.eu>
 <20190406163229.GA29885@pc21.mareichelt.com>
 <832fbfaf-c187-e7b7-79ec-31c43bde973c@ockers.eu>
 <09d88a24-bad3-3046-cfe8-ba20e26388ba@digitalbrains.com>
 <edfcb04f-bb33-984e-9120-1bf4588cefea@ockers.eu>
 <3496c617-20c6-49de-9595-22196d86948a@digitalbrains.com>
 <1554943039.1165.42.camel@16bits.net>
Message-ID: <d554de21-8cbe-6071-88a3-022e40bd94c3@digitalbrains.com>

On 11/04/2019 02:37, ?ngel wrote:
> Why should I need to remember to manually add that .'2' every time?

Because, as I said, it might silently corrupt the functioning of a
utility that expects "gpg" to be 1.4 and not 2.1. There are quite a lot
of utilities out there that parse the output of the gpg command in a way
that is not sufficiently robust. The different output generated by 2.1
might cause such a utility to misinterpret it, and silently accept an
invalid signature. The purpose of calling gpg to verify a signature was
surely to reject invalid signatures, so you might expose yourself to
attackers that way.

Depending on how the utility calls "gpg", it might be affected by your
alias and end up calling "gpg2".

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 <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190411/ee19f6c7/attachment.sig>

From hello at ezaquarii.com  Thu Apr 11 10:57:34 2019
From: hello at ezaquarii.com (Chris Narkiewicz)
Date: Thu, 11 Apr 2019 09:57:34 +0100
Subject: What to do with public key signature
Message-ID: <1A8386BF-72D9-4EF6-8365-77CEDA39461A@ezaquarii.com>

So I received a public key from a party. I verified it and I'm ready to sign it.

What's next step? What should I ideally do with that signature?

1) send back to the key owner hoping that he will publish it to the keyserver?
2) should I just push it to keyserver myself?
3) what if the key owner did not publish his key?

Best regards,
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190411/d91d6ac1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 858 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190411/d91d6ac1/attachment.sig>

From juergen at bruckner.tk  Thu Apr 11 13:00:33 2019
From: juergen at bruckner.tk (Juergen Bruckner)
Date: Thu, 11 Apr 2019 13:00:33 +0200
Subject: What to do with public key signature
In-Reply-To: <1A8386BF-72D9-4EF6-8365-77CEDA39461A@ezaquarii.com>
References: <1A8386BF-72D9-4EF6-8365-77CEDA39461A@ezaquarii.com>
Message-ID: <cef6e5f3-2d58-e301-d5b9-ee3e96755db6@bruckner.tk>

Hello Chris!

Well I think it is NOT your task to publish this key on a keyserver.
It is the decision of the owner of the key to publis it or not.
So in my opinion the best way is just to sign it and send it back to the
owner.

my 2 cents
Juergen

Am 11.04.19 um 10:57 schrieb Chris Narkiewicz via Gnupg-users:
> So I received a public key from a party. I verified it and I'm ready to sign it.
> 
> What's next step? What should I ideally do with that signature?
> 
> 1) send back to the key owner hoping that he will publish it to the keyserver?
> 2) should I just push it to keyserver myself?
> 3) what if the key owner did not publish his key?
> 
> Best regards,
> Chris
> 
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 

-- 
Juergen M. Bruckner
juergen at bruckner.tk

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3894 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190411/898d7b98/attachment-0001.bin>

From brian at minton.name  Thu Apr 11 14:42:22 2019
From: brian at minton.name (Brian Minton)
Date: Thu, 11 Apr 2019 08:42:22 -0400
Subject: What to do with public key signature
In-Reply-To: <cef6e5f3-2d58-e301-d5b9-ee3e96755db6@bruckner.tk>
References: <1A8386BF-72D9-4EF6-8365-77CEDA39461A@ezaquarii.com>
 <cef6e5f3-2d58-e301-d5b9-ee3e96755db6@bruckner.tk>
Message-ID: <CANyOob3vcK+-utrSonnjkH4W+bHH9mvhfDm_iS7jU78TG7TqdA@mail.gmail.com>

On Debian, I use the tool caff from the signing-party package.  It
signs the key, then encrypts it to the public key, and sends it via
email.


From abbot at monksofcool.net  Thu Apr 11 15:51:51 2019
From: abbot at monksofcool.net (Ralph Seichter)
Date: Thu, 11 Apr 2019 15:51:51 +0200
Subject: What to do with public key signature
In-Reply-To: <1A8386BF-72D9-4EF6-8365-77CEDA39461A@ezaquarii.com>
References: <1A8386BF-72D9-4EF6-8365-77CEDA39461A@ezaquarii.com>
Message-ID: <8736mo4pl4.fsf@ra.horus-it.com>

* Chris Narkiewicz via Gnupg-users:

> What should I ideally do with that signature?

Export the signed key and send it back to the owner. As was mentioned
here before, and I agree, it is not for you to decide whether the key
(with or without your signature) is published on a key server.

-Ralph


From matheus.a.m.moreira at gmail.com  Thu Apr 11 16:06:22 2019
From: matheus.a.m.moreira at gmail.com (Matheus Afonso Martins Moreira)
Date: Thu, 11 Apr 2019 11:06:22 -0300
Subject: How do I delete secret subkeys correctly?
In-Reply-To: <19fb4345-c5da-41b3-ad6c-8111bb456d37@www.fastmail.com>
References: <CAPtHdAUEo6a7AONjPyDLLDzkdPDy9aYrpy+iGiP2UCd_zrzh6w@mail.gmail.com>
 <19fb4345-c5da-41b3-ad6c-8111bb456d37@www.fastmail.com>
Message-ID: <CAPtHdAXZ9=4pm5jNiw2RWfHdwTH-Mx+5-_xN8nqNvx8WTEjY2Q@mail.gmail.com>

The --edit-key command did work this time. That's weird.
I tried this with my original keys and my experience matches
what Peter described. When I tried to delkey my original subkeys,
gpg deleted the public key packets, leaving the secret keys intact.

Public key list confirmed deletion of the subkeys from my public key
but the secret key list still included all my revoked subkeys.
The public key packets were promptly redownloaded and reintegrated
into the keyring when I searched for my user ID.

I don't understand why --edit-keys would work now,
or why --delete-secret-keys doesn't work as I expected.
Is it because I haven't sent my test keys to the keyservers?

The manual says delkey only deletes the public part of the key:

> delkey
> Remove a subkey (secondary key)
> Also note that this only deletes the public part of a key.

Even though it was able to delete the secret subkeys.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190411/5293858b/attachment.html>

From peter at digitalbrains.com  Thu Apr 11 16:26:55 2019
From: peter at digitalbrains.com (Peter Lebbing)
Date: Thu, 11 Apr 2019 16:26:55 +0200
Subject: How do I delete secret subkeys correctly?
In-Reply-To: <CAPtHdAXZ9=4pm5jNiw2RWfHdwTH-Mx+5-_xN8nqNvx8WTEjY2Q@mail.gmail.com>
References: <CAPtHdAUEo6a7AONjPyDLLDzkdPDy9aYrpy+iGiP2UCd_zrzh6w@mail.gmail.com>
 <19fb4345-c5da-41b3-ad6c-8111bb456d37@www.fastmail.com>
 <CAPtHdAXZ9=4pm5jNiw2RWfHdwTH-Mx+5-_xN8nqNvx8WTEjY2Q@mail.gmail.com>
Message-ID: <beadb785-c2c2-cc2e-148d-89fc477aaaad@digitalbrains.com>

On 11/04/2019 16:06, Matheus Afonso Martins Moreira wrote:
> Public key list confirmed deletion of the subkeys from my public key
> but the secret key list still included all my revoked subkeys.

Could you provide an example? I find this rather surprising, that -K
would ever list more than -k.

> The public key packets were promptly redownloaded and reintegrated
> into the keyring when I searched for my user ID.

Yes, that is expected behaviour. You can't delete stuff from the
keyserver, and everything that is valid will be incorporated into your
copy when you fetch it.

> I don't understand why --edit-keys would work now,

I cannot reproduce this on Debian stable with 2.1.18. I think you might
be misinterpreting the result, so I've built a step by step "lack of
reproduction" with comments.

What might be misleading: you say you are dealing with revoked subkeys.
Unless you specify "--list-options show-unusable-subkeys", you might not
see those in the keylistings even though they are there.

--8<---------------cut here---------------start------------->8---
$ gpg --with-keygrip -K 8CD9B759DBA3DC2EBEAA31B40D72EEEAA1274AE5
sec   rsa3072 2019-04-11 [SC] [expires: 2021-04-10]
      8CD9B759DBA3DC2EBEAA31B40D72EEEAA1274AE5
      Keygrip = 97A3F4843F1B7669524F066472CFA935F23D7574
uid           [  undef ] Testkey
ssb   rsa3072 2019-04-11 [E] [expires: 2021-04-10]
      Keygrip = 6D610FB78404E0C80954BB993E3410ED9FA463A6
--8<---------------cut here---------------end--------------->8---

The gpg binary only deals with public keys in the keyring directly.
Secret keys are delegated to gpg-agent, and gpg-agent works with
keygrips only, so to take a closer look we need the keygrip. Note that
the subkey above starts with the word "ssb" without a suffix, indicating
this is an available key. If the secret part were not available, it
would say "ssb#". So we expect that if we query the gpg-agent directly,
it will hold that key.

--8<---------------cut here---------------start------------->8---
$ gpg-connect-agent 
> keyinfo 6D610FB78404E0C80954BB993E3410ED9FA463A6
S KEYINFO 6D610FB78404E0C80954BB993E3410ED9FA463A6 D - - - P - - -
OK
> /bye
--8<---------------cut here---------------end--------------->8---

It does. I'm exporting the public key now to be able to do something
similar to "fetching from the keyserver".

--8<---------------cut here---------------start------------->8---
$ gpg -o test.gpg --export 8CD9B759DBA3DC2EBEAA31B40D72EEEAA1274AE5
File 'test.gpg' exists. Overwrite? (y/N) y
--8<---------------cut here---------------end--------------->8---

Let's delete that pesky subkey with delkey.

--8<---------------cut here---------------start------------->8---
$ gpg --edit-key 8CD9B759DBA3DC2EBEAA31B40D72EEEAA1274AE5
gpg (GnuPG) 2.1.18; 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.

Secret key is available.

sec  rsa3072/0D72EEEAA1274AE5
     created: 2019-04-11  expires: 2021-04-10  usage: SC  
     trust: never         validity: undefined
ssb  rsa3072/E7ED2961F743E804
     created: 2019-04-11  expires: 2021-04-10  usage: E   
[  undef ] (1). Testkey

gpg> key 1

sec  rsa3072/0D72EEEAA1274AE5
     created: 2019-04-11  expires: 2021-04-10  usage: SC  
     trust: never         validity: undefined
ssb* rsa3072/E7ED2961F743E804
     created: 2019-04-11  expires: 2021-04-10  usage: E   
[  undef ] (1). Testkey

gpg> delkey
Do you really want to delete this key? (y/N) y

sec  rsa3072/0D72EEEAA1274AE5
     created: 2019-04-11  expires: 2021-04-10  usage: SC  
     trust: never         validity: undefined
[  undef ] (1). Testkey

gpg> save
--8<---------------cut here---------------end--------------->8---

I'm immediately suspicious. If it would have deleted the secret part,
I'd have expected a popup from gpg-agent asking me if I was sure about
that. I got no popup. Let's see whether we still have the secret key
available (with the keygrip).

--8<---------------cut here---------------start------------->8---
$ gpg-connect-agent
> keyinfo 6D610FB78404E0C80954BB993E3410ED9FA463A6
S KEYINFO 6D610FB78404E0C80954BB993E3410ED9FA463A6 D - - - P - - -
OK
> /bye
--8<---------------cut here---------------end--------------->8---

Yep, the secret key material is still in our GnuPG homedir. Let's look
at gpg -K and then re-import the public stuff.

--8<---------------cut here---------------start------------->8---
$ gpg -K 8CD9B759DBA3DC2EBEAA31B40D72EEEAA1274AE5
sec   rsa3072 2019-04-11 [SC] [expires: 2021-04-10]
      8CD9B759DBA3DC2EBEAA31B40D72EEEAA1274AE5
uid           [  undef ] Testkey

$ gpg --import test.gpg 
gpg: key 0D72EEEAA1274AE5: "Testkey" 1 new signature
gpg: key 0D72EEEAA1274AE5: "Testkey" 1 new subkey
gpg: Total number processed: 1
gpg:            new subkeys: 1
gpg:         new signatures: 1
$ gpg -K 8CD9B759DBA3DC2EBEAA31B40D72EEEAA1274AE5
sec   rsa3072 2019-04-11 [SC] [expires: 2021-04-10]
      8CD9B759DBA3DC2EBEAA31B40D72EEEAA1274AE5
uid           [  undef ] Testkey
ssb   rsa3072 2019-04-11 [E] [expires: 2021-04-10]
--8<---------------cut here---------------end--------------->8---

Ah yes. We now have the secret key "back" as well even though it is
definitely not part of test.gpg. It says "ssb", we can use it.

I know how to delete the secret subkey, but I don't know how to do it in
a user-friendly way. Let's chat to our gpg-agent again.

--8<---------------cut here---------------start------------->8---
$ gpg-connect-agent
> delete_key 6D610FB78404E0C80954BB993E3410ED9FA463A6
OK
> /bye
$ gpg -K 8CD9B759DBA3DC2EBEAA31B40D72EEEAA1274AE5
sec   rsa3072 2019-04-11 [SC] [expires: 2021-04-10]
      8CD9B759DBA3DC2EBEAA31B40D72EEEAA1274AE5
uid           [  undef ] Testkey
ssb#  rsa3072 2019-04-11 [E] [expires: 2021-04-10]
--8<---------------cut here---------------end--------------->8---

Ah, look. This time when we invoked gpg -K, it is now correctly
indicating that we have deleted the secret part of that subkey, but we
still have the public part. It indicates knowledge of the existence of
the subkey, but it is marked as "ssb#" this time around, meaning we
don't have the secret key material anymore. So I /have/ answered your
question "how do I delete the secret subkey", but I can only do it by
fiddling with the agent directly rather than through the gpg binary.

I hope this helps your understanding!

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 <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190411/3a073534/attachment.sig>

From dkg at fifthhorseman.net  Thu Apr 11 17:29:28 2019
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 11 Apr 2019 11:29:28 -0400
Subject: How do I delete secret subkeys correctly?
In-Reply-To: <03c16dff-d826-4a9c-9207-8f9420049764@digitalbrains.com>
References: <CAPtHdAUEo6a7AONjPyDLLDzkdPDy9aYrpy+iGiP2UCd_zrzh6w@mail.gmail.com>
 <1d2884c0-6045-604e-3286-d0b910c22525@digitalbrains.com>
 <03c16dff-d826-4a9c-9207-8f9420049764@digitalbrains.com>
Message-ID: <87sguoa7c7.fsf@fifthhorseman.net>

On Wed 2019-04-10 17:28:54 +0200, Peter Lebbing wrote:
> On 10/04/2019 17:24, Peter Lebbing wrote:
>> gpg> delkey
>
> Sorry, my fatigued head was being silly. That's for deleting the public
> part, not the secret part. I don't think I know the way to delete the
> secret part when you just want to delete some subkey.

I agree with Peter that delkey doesn't do what you want it to do.

I was trying to figure out how to do it through the user interface, and
it's pretty clunky, with some scary failure modes.  I've opened
https://dev.gnupg.org/T4457 about it.

I know that with the version of GnuPG that you're using right now, you
can delete the secret key by learning its keygrip and asking gpg-agent
to delete it for you.

Start by getting a snapshot of how GnuPG sees the key:

    gpg --with-keygrip --list-secret-keys "$YOUR_FINGERRINT"

Then take the keygrip of the subkey you care about as $KEYGRIP and do:

    gpg-connect-agent "delete_key $KEYGRIP" /bye

(note that gpg-agent might prompt you about deletion when you do this)

Now you can verify that this worked by running the snapshot again and
comparing it with the earlier run:

    gpg --with-keygrip --list-secret-keys "$YOUR_FINGERPRINT"

The difference should be that you should see a "#" appear after the
"ssb" line that talks about the associated subkey.  the "#" means "no
secret key available."

hth,

        --dkg


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190411/f96294be/attachment-0001.sig>

From angel at pgp.16bits.net  Fri Apr 12 01:32:34 2019
From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=)
Date: Fri, 12 Apr 2019 01:32:34 +0200
Subject: Generating revocation certificate
In-Reply-To: <d554de21-8cbe-6071-88a3-022e40bd94c3@digitalbrains.com>
References: <f29619a4-3857-cf89-e269-1fe228439b9c@ockers.eu>
 <20190406130436.GA2370@pc21.mareichelt.com>
 <b107365f-5fc4-c9a3-f894-2f1da615b645@ockers.eu>
 <20190406163229.GA29885@pc21.mareichelt.com>
 <832fbfaf-c187-e7b7-79ec-31c43bde973c@ockers.eu>
 <09d88a24-bad3-3046-cfe8-ba20e26388ba@digitalbrains.com>
 <edfcb04f-bb33-984e-9120-1bf4588cefea@ockers.eu>
 <3496c617-20c6-49de-9595-22196d86948a@digitalbrains.com>
 <1554943039.1165.42.camel@16bits.net>
 <d554de21-8cbe-6071-88a3-022e40bd94c3@digitalbrains.com>
Message-ID: <1555025554.996.7.camel@16bits.net>

On 2019-04-11 at 10:24 +0200, Peter Lebbing wrote:
> Depending on how the utility calls "gpg", it might be affected by your
> alias and end up calling "gpg2".

Nope. ?
Kindly note that it is being added as a shell alias.

The alias will only be expanded on an interactive shell? This causes
that every program which calls a gpg binary need to be explicitly
configured to use gpg2 instead, but it is safer.


? "Aliases are not expanded when the shell is not interactive, unless
the expand_aliases shell option is set using shopt" -- bash(1)
And, even if you were using a shell script that enabled expand_aliases
(I don't think I have ever come across one), .bashrc should not have
been loaded anyway.
This is in contrast of an exported function (which would replace the
command *sometimes*, depending on how gpg was called) or a
wrapper /symlink called gpg earlier in the path.


Best regards



From matheus.a.m.moreira at gmail.com  Fri Apr 12 04:57:22 2019
From: matheus.a.m.moreira at gmail.com (Matheus Afonso Martins Moreira)
Date: Thu, 11 Apr 2019 23:57:22 -0300
Subject: How do I delete secret subkeys correctly?
In-Reply-To: <beadb785-c2c2-cc2e-148d-89fc477aaaad@digitalbrains.com>
References: <CAPtHdAUEo6a7AONjPyDLLDzkdPDy9aYrpy+iGiP2UCd_zrzh6w@mail.gmail.com>
 <19fb4345-c5da-41b3-ad6c-8111bb456d37@www.fastmail.com>
 <CAPtHdAXZ9=4pm5jNiw2RWfHdwTH-Mx+5-_xN8nqNvx8WTEjY2Q@mail.gmail.com>
 <beadb785-c2c2-cc2e-148d-89fc477aaaad@digitalbrains.com>
Message-ID: <CAPtHdAXXD+ZrrqySjwXOvauxzGMbKxK26OEL4nUy7QJpTXNiJg@mail.gmail.com>

> I think you might be misinterpreting the result
> you say you are dealing with revoked subkeys.
> Unless you specify "--list-options show-unusable-subkeys",
> you might not see those in the keylistings even though they are there.

You're right!

> The gpg binary only deals with public keys in the keyring directly.
> Secret keys are delegated to gpg-agent, and gpg-agent works with
> keygrips only

So gpg focuses on the public key ring and public key operations
while gpg-agent is responsible for the private-keys-v1.d directory.
This explains why the names of the *.key files don't match
the fingerprints of the keys, unlike the *.rev files:
gpg-agent uses keygrips in order to refer to the private keys.

Before I found the --delete-secret-keys command,
I tried to delete the subkey files manually with rm.
Since their names did not match their fingerprints,
I did not know which files were the right ones.

> If it would have deleted the secret part,
> I'd have expected a popup from gpg-agent asking me if I was sure about
> that. I got no popup.

I understand now. That is what happened when I accidentally deleted
my original keys. I got a graphical confirmation pop-up from gpg-agent.

> delete_key 6D610FB78404E0C80954BB993E3410ED9FA463A6

Looks like this is the definitive answer.

I looked up the delete_key command on the gpg-agent manual.
There seems to be only one reference to it
in the description of the --allow-loopback-pinentry option.

It does not seem to be listed on the page where the other commands are:

https://www.gnupg.org/documentation/manuals/gnupg/Agent-Protocol.html

Is this gpg-agent command not documented?

I was able to obtain some help text for it:

    $ gpg-connect-agent 'help delete_key' /bye
    # DELETE_KEY [--force|--stub-only] <hexstring_with_keygrip>
    #
    # Delete a secret key from the key store.  If --force is used
    # and a loopback pinentry is allowed, the agent will not ask
    # the user for confirmation.  If --stub-only is used the key will
    # only be deleted if it is a reference to a token.
    OK

This does seem to be very useful. The --stub-only option in particular
is very relevant to me since I have subkeys on a YubiKey and would like
to delete their stubs in case of loss or deletion.

> I hope this helps your understanding!

It did! I was able to truly delete the subkey following your steps.
Now I have a much better understanding of how gpg works.

Thank you for the detailed answer!


From matheus.a.m.moreira at gmail.com  Fri Apr 12 05:09:27 2019
From: matheus.a.m.moreira at gmail.com (Matheus Afonso Martins Moreira)
Date: Fri, 12 Apr 2019 00:09:27 -0300
Subject: How do I delete secret subkeys correctly?
In-Reply-To: <87sguoa7c7.fsf@fifthhorseman.net>
References: <CAPtHdAUEo6a7AONjPyDLLDzkdPDy9aYrpy+iGiP2UCd_zrzh6w@mail.gmail.com>
 <1d2884c0-6045-604e-3286-d0b910c22525@digitalbrains.com>
 <03c16dff-d826-4a9c-9207-8f9420049764@digitalbrains.com>
 <87sguoa7c7.fsf@fifthhorseman.net>
Message-ID: <CAPtHdAX=Vf5B1oM3dU96YQCNxM-q7VBKKGaBzbs4fVVWX+2RuA@mail.gmail.com>

> I was trying to figure out how to do it through the user interface, and
> it's pretty clunky, with some scary failure modes.  I've opened
> https://dev.gnupg.org/T4457 about it.

Thank you!

> I know that with the version of GnuPG that you're using right now, you
> can delete the secret key by learning its keygrip and asking gpg-agent
> to delete it for you.

This seems to be the definitive answer for gpg 2.2.15.
Also interesting is the --stub-only option,
which deletes the key only if it is a reference to a token.


From peter at digitalbrains.com  Fri Apr 12 12:18:35 2019
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 12 Apr 2019 12:18:35 +0200
Subject: Generating revocation certificate
In-Reply-To: <1555025554.996.7.camel@16bits.net>
References: <f29619a4-3857-cf89-e269-1fe228439b9c@ockers.eu>
 <20190406130436.GA2370@pc21.mareichelt.com>
 <b107365f-5fc4-c9a3-f894-2f1da615b645@ockers.eu>
 <20190406163229.GA29885@pc21.mareichelt.com>
 <832fbfaf-c187-e7b7-79ec-31c43bde973c@ockers.eu>
 <09d88a24-bad3-3046-cfe8-ba20e26388ba@digitalbrains.com>
 <edfcb04f-bb33-984e-9120-1bf4588cefea@ockers.eu>
 <3496c617-20c6-49de-9595-22196d86948a@digitalbrains.com>
 <1554943039.1165.42.camel@16bits.net>
 <d554de21-8cbe-6071-88a3-022e40bd94c3@digitalbrains.com>
 <1555025554.996.7.camel@16bits.net>
Message-ID: <34cd2b6e-cb58-2605-6c8d-09972795a535@digitalbrains.com>

On 12/04/2019 01:32, ?ngel wrote:
> The alias will only be expanded on an interactive shell

Thanks for this piece of information! I'm rather cautious when it comes
to these shell modes of operation. I think I'm understanding it
reasonably well now, but have been surprised about behaviour in the
past.

I note the Bash Reference Manual says:

| For almost every purpose, shell functions are preferred over aliases.

This use-case sounds like the "almost" bit :-).

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 <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190412/1518d260/attachment.sig>

From peter at digitalbrains.com  Fri Apr 12 12:27:40 2019
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 12 Apr 2019 12:27:40 +0200
Subject: Documentation for agent and scdaemon interaction (Assuan protocol)
In-Reply-To: <CAPtHdAXXD+ZrrqySjwXOvauxzGMbKxK26OEL4nUy7QJpTXNiJg@mail.gmail.com>
References: <CAPtHdAUEo6a7AONjPyDLLDzkdPDy9aYrpy+iGiP2UCd_zrzh6w@mail.gmail.com>
 <19fb4345-c5da-41b3-ad6c-8111bb456d37@www.fastmail.com>
 <CAPtHdAXZ9=4pm5jNiw2RWfHdwTH-Mx+5-_xN8nqNvx8WTEjY2Q@mail.gmail.com>
 <beadb785-c2c2-cc2e-148d-89fc477aaaad@digitalbrains.com>
 <CAPtHdAXXD+ZrrqySjwXOvauxzGMbKxK26OEL4nUy7QJpTXNiJg@mail.gmail.com>
Message-ID: <f7b90aff-fb1c-fde7-c7dd-ec454e61d90d@digitalbrains.com>

On 12/04/2019 04:57, Matheus Afonso Martins Moreira wrote:
> Is this gpg-agent command not documented?

For direct interaction with the agent and scdaemon, my first
documentation source is always the inline help. Only when I need more
than that will I look for more sources.

Talking to scdaemon is done by prefixing your command with "SCD ".

--8<---------------cut here---------------start------------->8---
$ gpg-connect-agent 
> help
# NOP
# CANCEL
[...]
# KEYTOCARD [--force] <hexstring_with_keygrip> <serialno> <id> <timestamp>
OK
> help keyinfo
# KEYINFO [--[ssh-]list] [--data] [--ssh-fpr] [--with-ssh] <keygrip>
[...]
# 
# More information may be added in the future.
OK
> scd help
# NOP
# CANCEL
[...]
# KILLSCD
OK
> scd help learn
# LEARN [--force] [--keypairinfo]
[...]
#   
# Note, that this function may even be used on a locked card.
OK
> /bye
--8<---------------cut here---------------end--------------->8---

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 <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190412/fa228f28/attachment-0001.sig>

From kynnjo at gmail.com  Fri Apr 12 13:12:18 2019
From: kynnjo at gmail.com (Kynn Jones)
Date: Fri, 12 Apr 2019 07:12:18 -0400
Subject: How to prevent passphrase-caching from within a gpgme-based Python
 script?
Message-ID: <CAFvQaj6YY0t4nJiX5TfQaKMj3aeL72iAjjZrnDjKvVJ55p7Z8A@mail.gmail.com>

Hi everyone!

The following short Python script takes three command-line arguments: a
passphrase, an input path, and an output path.  Then it uses the passphrase
to decrypt the contents of the input path, and puts the decrypted content
in the output path.

    from gpg import Context
    import sys

    pp = sys.argv[1]    # passphrase
    enc = sys.argv[2]   # input file (assumed to be encrypted)
    dec = sys.argv[3]   # output file

    with open(enc, 'rb') as reader, open(dec, 'wb') as writer, Context() as
ctx:

        try:

            ctx.decrypt(reader, sink=writer, passphrase=pp)

        except Exception as e:
            print(str(e), file=sys.stderr)


This decryption works fine, as long as the correct passphrase is provided,
but it apparently results in the caching of such correct passphrase, so
that any subsequent decryption attempts succeed irrespective of the
passphrase one provides.  (I give a fuller illustration of what I mean at
the end of this post, together with version details.)

Clearly, there's some passphrase caching going on, but I don't really
understand the details.

What I want to know is: how can I modify the Python script so that it
disables the caching of passphrases?  Note that I am not interested in how
to disable passphrase caching outside of the script!  I want the script to
disable passphrase caching autonomously.  Is that possible?

Thank you in advance!

kj

P.S. Here's a detailed example of what I alluded to in my post.  The script
./demo.py is the one whose source I listed above.  IMPORTANT: the code
given below behaved as shown only when I executed it from the command
line.  If I put in a file and execute it (or source it) as a script, then
all decryptions with the wrong passphrase fail, irrespective of any prior
successful decryptions with the correct passphrase.

    # Prologue: preparation

    # First, define some variables

    % ORIGINAL=/tmp/original.txt
    % ENCRYPTED=/tmp/encrypted.gpg
    % DECRYPTED=/tmp/decrypted.txt
    % PASSPHRASE=yowzayowzayowza

    # Next, create a cleartext original:

    % echo 'Cool story, bro!' > "$ORIGINAL"

    # Next, encrypt the original using /usr/bin/gpg

    % rm -f "$ENCRYPTED"
    % /usr/bin/gpg --batch --symmetric --cipher-algo=AES256
--compress-algo=zlib --passphrase="$PASSPHRASE" --output="$ENCRYPTED"
"$ORIGINAL"

    # Confirm encryption

    % od -c "$ENCRYPTED"
    0000000 214  \r 004  \t 003 002 306 366   ^ 236   5 250   a   b 361 322
    0000020   X 001 263 332 302 250 027 300 222 271 345 235 027   E   K 302
    0000040 306   - 346 372 324   o   6 304  \a   "   9 270   ~ 307 361 302
    0000060 227 267  \f   ` 003   & 203 317 212   ^   1 240 267 234 321   '
    0000100 361 363 277  \v   :  \f   6 366 036 224   R 370   E 033  \r 261
    0000120   9 026 337   2 363 206 017 251 027   U   A 377 336 023 217 025
    0000140   p 333   ; 257   b 223 223   G   <
    0000151


    # Now, the demonstration proper.

    # Initially, decryption with the wrong passphrase fails:

    % rm -f "$DECRYPTED"
    % python ./demo.py "certainly the wrong $PASSPHRASE" "$ENCRYPTED"
"$DECRYPTED"
    gpgme_op_decrypt_verify: GPGME: Decryption failed


    # Decryption with the right passphrase succeeds:

    % rm -f "$DECRYPTED"
    % python ./demo.py "$PASSPHRASE" "$ENCRYPTED" "$DECRYPTED"
    % od -c "$DECRYPTED"
    0000000   C   o   o   l       s   t   o   r   y   ,       b   r   o   !
    0000020  \n
    0000021


    # After the first successful decryption with the right
    # passphrase, decryption with the wrong passphrase always
    # succeeds:

    % rm -f "$DECRYPTED"
    % python ./demo.py "certainly the wrong $PASSPHRASE" "$ENCRYPTED"
"$DECRYPTED"
    % od -c "$DECRYPTED"
    0000000   C   o   o   l       s   t   o   r   y   ,       b   r   o   !
    0000020  \n
    0000021


    # Some relevant version info

    % python -c 'import gpg; print((gpg.version.versionstr,
gpg.version.gpgme_versionstr))'
    ('1.10.0', '1.8.0')

    % gpg --version
    gpg (GnuPG) 2.1.18
    libgcrypt 1.7.6-beta
    Copyright (C) 2017 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <
https://gnu.org/licenses/gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.

    Home: /home/kj146/.gnupg
    Supported algorithms:
    Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
    Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
            CAMELLIA128, CAMELLIA192, CAMELLIA256
    Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
    Compression: Uncompressed, ZIP, ZLIB, BZIP2

    % python --version
    Python 3.5.3

    % uname -ar
    Linux parakeet 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2 (2017-04-30)
x86_64 GNU/Linux
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190412/ba437641/attachment.html>

From gaurav.walia at jpl.nasa.gov  Sat Apr 13 00:09:46 2019
From: gaurav.walia at jpl.nasa.gov (Walia, Gaurav (333G))
Date: Fri, 12 Apr 2019 22:09:46 +0000
Subject: gpg-preset-passphrase installation and usage
Message-ID: <D8D65AAD.DD288%gaurav.walia@jpl.nasa.gov>

Hello,

Very new to gpg.   I?m attempting to use gpg-preset-passphrase.  But uncertain how to go about enabling it for usage.  Could someone direct me or provide me some instructions in how to go about enabling gpg-preset-passphrase?

I have the following version installed:
gpg --version
gpg (GnuPG) 2.0.22
libgcrypt 1.5.3
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ?, ?, ELG, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2


Gaurav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190412/d00837c7/attachment-0001.html>

From gaurav.walia at jpl.nasa.gov  Sat Apr 13 00:03:23 2019
From: gaurav.walia at jpl.nasa.gov (Walia, Gaurav (333G))
Date: Fri, 12 Apr 2019 22:03:23 +0000
Subject: gpg-preset-passphrase installation and usage
Message-ID: <D8D65932.DD275%gaurav.walia@jpl.nasa.gov>

Hello,

Very new to gpg.   I?m attempting to use gpg-preset-passphrase.  But uncertain how to go about enabling it for usage.  Could someone direct me or provide me some instructions in how to go about enabling gpg-preset-passphrase?

I have the following version installed:
gpg --version
gpg (GnuPG) 2.0.22
libgcrypt 1.5.3
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ?, ?, ELG, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2


Gaurav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190412/8454b678/attachment-0001.html>

From gaurav.walia at jpl.nasa.gov  Sat Apr 13 12:42:22 2019
From: gaurav.walia at jpl.nasa.gov (Walia, Gaurav (333G))
Date: Sat, 13 Apr 2019 10:42:22 +0000
Subject: gpg-preset-passphrase installation and usage
In-Reply-To: <D8D65AAD.DD288%gaurav.walia@jpl.nasa.gov>
References: <D8D65AAD.DD288%gaurav.walia@jpl.nasa.gov>
Message-ID: <D8D7022E.DD834%gaurav.walia@jpl.nasa.gov>

Ok.  Did some googling came up with the following.  Could someone confirm that I?m doing this correctly?

Objective: To save passphrase in cache to an unattended machine so that it doesn?t time out the credentials.  Specifically, using https://github.com/docker/docker-credential-helpers, with setup https://github.com/docker/docker-credential-helpers/issues/102#issuecomment-388634452.

Steps:
use gpg-preset-passphrase
Current Setup

  *   ~/.gnupg/gpg-agent.conf
     *   pinentry-program /usr/bin/pinentry-curses
     *   max-cache-ttl 60480000
     *   default-cache-ttl 60480000
     *   allow-preset-passphrase

  *   gpg --version
     *   gpg (GnuPG) 2.0.22
     *   libgcrypt 1.5.3
     *   Copyright (C) 2013 Free Software Foundation, Inc.
     *   License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
     *   This is free software: you are free to change and redistribute it.
     *   There is NO WARRANTY, to the extent permitted by law.
     *
     *   Home: ~/.gnupg
     *   Supported algorithms:
     *   Pubkey: RSA, ?, ?, ELG, DSA
     *   Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
     *           CAMELLIA128, CAMELLIA192, CAMELLIA256
     *   Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
     *   Compression: Uncompressed, ZIP, ZLIB, BZIP2
  *   gpg2 --fingerprint --fingerprint name at domain.com
     *   pub   2048R/12312312 2019-03-23
     *         Key fingerprint = 4567 4567 4567 4567 4567  4567 4567 4567 4567 4567
     *   uid                  Name <name at domain.com>
     *   sub   2048R/11121314 2019-03-23
     *         Key fingerprint = 8910 8910 8910 8910 8910  8910 8910 8910 8910 8910

Updated Setup using gpg-preset-passphrase only

  *   ~/.gnupg/gpg-agent.conf
     *   We should be able to remove the first 3 line items since we are only using gpg-preset-passphrase
     *   Final file contents
        *   allow-preset-passphrase
  *   Reload gpa-agent.conf file
     *   gpg-connect-agent reloadagent /bye
  *   Setup gpg-preset-passphrase
     *   gpg-preset-passphrase --preset 8910891089108910891089108910891089108910
  *   Now when you login to that key and enter the passphrase It should cache it until you issue the following command to remove it.
     *   gpg-preset-passphrase ?forget 8910891089108910891089108910891089108910

Question:

  1.  Is the updated setup correct in my assumption for the setup?

Thank you in advance for taking the time to help, it is greatly appreciated.

Gaurav

From: Gaurav walia <gaurav.walia at jpl.nasa.gov<mailto:gaurav.walia at jpl.nasa.gov>>
Date: Friday, April 12, 2019 at 3:09 PM
To: "gnupg-users at gnupg.org<mailto:gnupg-users at gnupg.org>" <gnupg-users at gnupg.org<mailto:gnupg-users at gnupg.org>>
Subject: gpg-preset-passphrase installation and usage

Hello,

Very new to gpg.   I?m attempting to use gpg-preset-passphrase.  But uncertain how to go about enabling it for usage.  Could someone direct me or provide me some instructions in how to go about enabling gpg-preset-passphrase?

I have the following version installed:
gpg --version
gpg (GnuPG) 2.0.22
libgcrypt 1.5.3
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ?, ?, ELG, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2


Gaurav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190413/dc2b0f64/attachment.html>

From peter at digitalbrains.com  Sat Apr 13 14:34:36 2019
From: peter at digitalbrains.com (Peter Lebbing)
Date: Sat, 13 Apr 2019 14:34:36 +0200
Subject: gpg-preset-passphrase installation and usage
In-Reply-To: <D8D7022E.DD834%gaurav.walia@jpl.nasa.gov>
References: <D8D65AAD.DD288%gaurav.walia@jpl.nasa.gov>
 <D8D7022E.DD834%gaurav.walia@jpl.nasa.gov>
Message-ID: <f573c9a0-919a-775a-e375-072ff021bf62@digitalbrains.com>

Hello!

On 13/04/2019 12:42, Walia, Gaurav (333G) via Gnupg-users wrote:
>   * gpg --version
>       o gpg (GnuPG) 2.0.22

This version is a full six years old. Not only is 2.0.22 unsupported,
the whole 2.0 branch has been end-of-life for a good bit more than a
year now.

How come you're using something ancient that upstream doesn't support
and which has known defects? Is this a distribution-supported version?
If there is no security support from any party, I think you should
switch to a supported version.

>   * Setup gpg-preset-passphrase
>       o gpg-preset-passphrase --preset 8910891089108910891089108910891089108910
>   * Now when you login to that key and enter the passphrase It should cache it until you issue the following command to remove it.
>       o gpg-preset-passphrase ?forget 8910891089108910891089108910891089108910

No, that's not how gpg-preset-passphrase works. You supply the
passphrase on the invocation of gpg-preset-passphrase. And you use the
keygrip, not the fingerprint. You can find the keygrip with the
--with-keygrip option when listing the key.

You would supply the passphrase on stdin of gpg-preset-passphrase,
probably from some utility that got it from the operator. Or with the -P
command line option directly, but this makes it visible for any user on
the system through the process list.

There is no feedback if either keygrip or passphrase is wrong. The net
result is simply you'll get a pinentry pop up when you try to use the
key.

And it will only cache it up to max-cache-ttl as mentioned in the man
page for gpg-preset-passphrase, so you probably want to not remove that
option from gpg-agent.conf.

Alternatively, you could just set default-cache-ttl to whatever value
you desire and completely forego gpg-preset-passphrase. Because it
sounds like you are okay with just supplying the passphrase on the first
invocation, it seems?

gpgconf tells us that the data type of the TTL options is uint32, so you
can make a TTL of 136 years. I notice you use a NASA e-mail address.
This TTL might be a problem on an unmanned spacecraft, but somehow I'll
expect your use case is covered ;-). (Plus, max-cache-ttl always limits
it to the 136 years anyway)

If you did not use gpg-preset-passphrase to preset the passphrase, you
can't use gpg-preset-passphrase --forget to clear it again. Either
reload the agent (this will make it forget all passphrases), or issue:

$ gpg-connect-agent 'clear_passphrase --mode=normal KEYGRIP' /bye

I'm not sure whether that last method is future-proof or might change in
some new version. In other words, I don't know if it's part of the API
or an implementation detail.

I did these things on the distribution-provided GnuPG on Debian
stretch/stable. So it's possible that it works differently on different
versions.

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 <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190413/6f7b8228/attachment.sig>

From peter at digitalbrains.com  Sat Apr 13 14:41:02 2019
From: peter at digitalbrains.com (Peter Lebbing)
Date: Sat, 13 Apr 2019 14:41:02 +0200
Subject: gpg-preset-passphrase installation and usage
In-Reply-To: <f573c9a0-919a-775a-e375-072ff021bf62@digitalbrains.com>
References: <D8D65AAD.DD288%gaurav.walia@jpl.nasa.gov>
 <D8D7022E.DD834%gaurav.walia@jpl.nasa.gov>
 <f573c9a0-919a-775a-e375-072ff021bf62@digitalbrains.com>
Message-ID: <1e38372b-c3f4-7fc2-f625-2d6098ea7e94@digitalbrains.com>

On 13/04/2019 14:34, Peter Lebbing wrote:
> Either reload the agent (this will make it forget all passphrases)

Of course I should have made that explicit. You reload the agent by:

$ gpgconf --reload gpg-agent

I should mention this before you start figuring out a way to send it
SIGHUP (which btw would also work fine, it's just that you need a PID
then).

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 <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190413/5f220713/attachment-0001.sig>

From gnupg at raf.org  Tue Apr 16 06:53:00 2019
From: gnupg at raf.org (gnupg at raf.org)
Date: Tue, 16 Apr 2019 14:53:00 +1000
Subject: gpg-preset-passphrase installation and usage
In-Reply-To: <D8D7022E.DD834%gaurav.walia@jpl.nasa.gov>
References: <D8D65AAD.DD288%gaurav.walia@jpl.nasa.gov>
 <D8D7022E.DD834%gaurav.walia@jpl.nasa.gov>
Message-ID: <20190416045300.v3cxko7iuokxgswc@raf.org>

Walia, Gaurav (333G) via Gnupg-users wrote:

> Ok.  Did some googling came up with the following.  Could someone confirm that I?m doing this correctly?
> 
> Objective: To save passphrase in cache to an unattended machine so that it doesn?t time out the credentials.  Specifically, using https://github.com/docker/docker-credential-helpers, with setup https://github.com/docker/docker-credential-helpers/issues/102#issuecomment-388634452.
> 
> Steps:
> use gpg-preset-passphrase
> Current Setup
> 
>   *   ~/.gnupg/gpg-agent.conf
>      *   pinentry-program /usr/bin/pinentry-curses
>      *   max-cache-ttl 60480000
>      *   default-cache-ttl 60480000
>      *   allow-preset-passphrase
> 
>   *   gpg --version
>      *   gpg (GnuPG) 2.0.22
>      *   libgcrypt 1.5.3
>      *   Copyright (C) 2013 Free Software Foundation, Inc.
>      *   License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>      *   This is free software: you are free to change and redistribute it.
>      *   There is NO WARRANTY, to the extent permitted by law.
>      *
>      *   Home: ~/.gnupg
>      *   Supported algorithms:
>      *   Pubkey: RSA, ?, ?, ELG, DSA
>      *   Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
>      *           CAMELLIA128, CAMELLIA192, CAMELLIA256
>      *   Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
>      *   Compression: Uncompressed, ZIP, ZLIB, BZIP2
>   *   gpg2 --fingerprint --fingerprint name at domain.com
>      *   pub   2048R/12312312 2019-03-23
>      *         Key fingerprint = 4567 4567 4567 4567 4567  4567 4567 4567 4567 4567
>      *   uid                  Name <name at domain.com>
>      *   sub   2048R/11121314 2019-03-23
>      *         Key fingerprint = 8910 8910 8910 8910 8910  8910 8910 8910 8910 8910
> 
> Updated Setup using gpg-preset-passphrase only
> 
>   *   ~/.gnupg/gpg-agent.conf
>      *   We should be able to remove the first 3 line items since we are only using gpg-preset-passphrase
>      *   Final file contents
>         *   allow-preset-passphrase
>   *   Reload gpa-agent.conf file
>      *   gpg-connect-agent reloadagent /bye
>   *   Setup gpg-preset-passphrase
>      *   gpg-preset-passphrase --preset 8910891089108910891089108910891089108910
>   *   Now when you login to that key and enter the passphrase It should cache it until you issue the following command to remove it.
>      *   gpg-preset-passphrase ?forget 8910891089108910891089108910891089108910
> 
> Question:
> 
>   1.  Is the updated setup correct in my assumption for the setup?
> 
> Thank you in advance for taking the time to help, it is greatly appreciated.
> 
> Gaurav

hi,

the best thing to do is test it. :-)
but it looks promising.

however, be warned that 2.0.22 is old and things have
changed a lot since then. especially on systems with
systemd, and especially when the subsequent uses of gpg
are from a different systemd user session to the one
that preset the passphrase.

when i used 2.0.x, i ran gpg-agent in --daemon mode with
the --write-env-file option so that the subsequent uses
of gpg knew where to find gpg-agent (since they weren't
child processes with access to the environment variables).
that option disappears in later versions.

also, in later versions you'll need to change:

  gpg2 --fingerprint --fingerprint name at domain.com

to:

  gpg2 --fingerprint --with-keygrip name at domain.com

cheers,
raf



From angel at pgp.16bits.net  Tue Apr 16 23:23:52 2019
From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=)
Date: Tue, 16 Apr 2019 23:23:52 +0200
Subject: How to prevent passphrase-caching from within a gpgme-based
 Python script?
In-Reply-To: <CAFvQaj6YY0t4nJiX5TfQaKMj3aeL72iAjjZrnDjKvVJ55p7Z8A@mail.gmail.com>
References: <CAFvQaj6YY0t4nJiX5TfQaKMj3aeL72iAjjZrnDjKvVJ55p7Z8A@mail.gmail.com>
Message-ID: <1555449832.941.48.camel@16bits.net>

On 2019-04-12 at 07:12 -0400, Kynn Jones wrote:
> Hi everyone!
> 
> The following short Python script takes three command-line arguments:
> a passphrase, an input path, and an output path.  Then it uses the
> passphrase to decrypt the contents of the input path, and puts the
> decrypted content in the output path.
> 
(...)
> This decryption works fine, as long as the correct passphrase is
> provided, but it apparently results in the caching of such correct
> passphrase, so that any subsequent decryption attempts succeed
> irrespective of the passphrase one provides.  (I give a fuller
> illustration of what I mean at the end of this post, together with
> version details.)
> 
> Clearly, there's some passphrase caching going on, but I don't really
> understand the details.

Yes. gpg will use a gpg-agent, launching it if needed, and that agent is
caching the passphrase:

>        --default-cache-ttl n
>               Set the time a cache entry is valid to n seconds.  The default is 600 seconds.
>        --max-cache-ttl n
>               Set the maximum time a cache entry is valid to n seconds.  After this time a cache  entry
>               will  be  expired even if it has been accessed recently or has been set using gpg-preset-
>               passphrase.  The default is 2 hours (7200 seconds).
> 

> 
> What I want to know is: how can I modify the Python script so that it
> disables the caching of passphrases?  Note that I am not interested in
> how to disable passphrase caching outside of the script!  I want the
> script to disable passphrase caching autonomously.  Is that possible?

There doesn't seem to be any command to set a passphrase with just a ttl
in the agent protocol. Which is not that strange, given the gpg client
passing the passphrase to the agent is the weird case. It could of
course issue a CLEAR_PASSPHRASE before each operation, but that would be
racy.

I think you should launch your own gpg-agent for your script, with the
configuration you wish. For example, I expect that running this wrapper
instead of demo.py would fix it: 

#!/bin/sh
eval $(gpg-agent --daemon --sh --max-cache-ttl 0)
exec python ./demo.py "$@"


Of course, you could instead run gpg-agent from python and set
GPG_AGENT_INFO there. The gpg python package is calling gpg under the
hood, so it should pick the GPG_AGENT_INFO variable from the
environment.


In the script above, after running the script you could do
> kill $(echo "$GPG_AGENT_INFO" | cut -d : -f 2)
since nobody would use that agent again, anyway.

A more optimized version would use a dedicated agent just for demo.py,
but reuse it amongst several invocations of demo.py.


Best regards




From peter at digitalbrains.com  Tue Apr 16 23:52:11 2019
From: peter at digitalbrains.com (Peter Lebbing)
Date: Tue, 16 Apr 2019 23:52:11 +0200
Subject: How to prevent passphrase-caching from within a gpgme-based
 Python script?
In-Reply-To: <1555449832.941.48.camel@16bits.net>
References: <CAFvQaj6YY0t4nJiX5TfQaKMj3aeL72iAjjZrnDjKvVJ55p7Z8A@mail.gmail.com>
 <1555449832.941.48.camel@16bits.net>
Message-ID: <994b9d01-122c-7b66-88b1-08d64c4dda3c@digitalbrains.com>

On 16/04/2019 23:23, ?ngel wrote:
> Of course, you could instead run gpg-agent from python and set
> GPG_AGENT_INFO there. The gpg python package is calling gpg under the
> hood, so it should pick the GPG_AGENT_INFO variable from the
> environment.

GPG_AGENT_INFO is obsolete and unused in GnuPG 2.1+ (and GnuPG 2.0 is
obsolete itself :-). So I'm afraid that won't work.

The agent and the homedir are tightly coupled. If you want to do
something special to the agent, I think you're going to have to go the
undesirable route of a separate homedir...

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 <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190416/941f6e25/attachment.sig>

From bernhard at intevation.de  Thu Apr 25 09:20:47 2019
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 25 Apr 2019 09:20:47 +0200
Subject: What is the practical strength of DSA1024/Elgamal2048 (former GnuPG
 default)?
Message-ID: <201904250920.56038.bernhard@intevation.de>

Hello,
until about 2009 GnuPG [1] had dsa1024/elg2048 as default key algorithms.
There are still keys around with those algorithmus.

Recommendations from the US and Europe [2] only list DSA between 1900
and 3000 bits as allowed for legacy use. So it is clear that DSA1024
should not be used anymore.

How urgent is it to convince people to create new keypairs?
To me this means rephrased:
   How strong or weak is this combination of keys for todays usage?
    
Wikipedia points out a strong  sensitivity of the algorithm to the quality of 
random number generators and that implementations could deliberately leak 
information in the signature [3]. This alone probably is a reason to switch 
keys.

Apart from the problems an attacker could be solving the discrete log problem.
A presentation from 2013 [4] assumes that advances are made towards solving
this in a practical time frame. Does somebody has good pointers on the state 
of the art for this?

Because dsa1024/elg2048 used to be a default of GnuPG, I think it would be 
helpful to point our users towards a well understood reasoning when and why 
they should move to a better key-pair.

What do you think?

Best Regards,
Bernhard

[1] https://lists.gnupg.org/pipermail/gnupg-devel/2009-May/025079.html
[2]
https://www.sogis.eu/documents/cc/crypto/SOGIS-Agreed-Cryptographic-Mechanisms-1.1.pdf
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf#page=66

[3]
https://en.wikipedia.org/wiki/Digital_Signature_Algorithm#Sensitivity

[4]
https://isecpartners.com/media/105564/ritter_samuel_stamos_bh_2013_cryptopocalypse.pdf
-- 
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: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190425/57c05626/attachment.sig>

From kristian.fiskerstrand at sumptuouscapital.com  Thu Apr 25 11:19:15 2019
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Thu, 25 Apr 2019 11:19:15 +0200
Subject: What is the practical strength of DSA1024/Elgamal2048 (former
 GnuPG default)?
In-Reply-To: <201904250920.56038.bernhard@intevation.de>
References: <201904250920.56038.bernhard@intevation.de>
Message-ID: <e53e2aab-fc93-8875-0f5e-560d61254459@sumptuouscapital.com>

On 4/25/19 9:20 AM, Bernhard Reiter wrote:
> Wikipedia points out a strong  sensitivity of the algorithm to the quality of 
> random number generators and that implementations could deliberately leak 
> information in the signature [3]. This alone probably is a reason to switch 
> keys.

This isn't really a major point given rfc6979 (
https://tools.ietf.org/html/rfc6979 ): Deterministic Usage of the
Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature
Algorithm (ECDSA)


-- 
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
Corruptissima re publica plurim? leges
The greater the degeneration of the republic, the more of its laws

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190425/c17aaea0/attachment-0001.sig>

From david.milet at gmail.com  Tue Apr 30 12:55:07 2019
From: david.milet at gmail.com (David Milet)
Date: Tue, 30 Apr 2019 06:55:07 -0400
Subject: Enforcing password complexity for private keys
Message-ID: <FE640438-D96C-4E80-9AE5-E2282C04FFE2@gmail.com>

Hello

We?re considering rolling out GnuPG at work for developers to sign git commits.
How can we prevent developers from choosing a trivial password?

Is there a way for GnuPG to enforce some password complexity on the private keys?

Is that something that a Yubikey could do? 

Many thanks!
David

From cyaniventer at riseup.net  Tue Apr 30 15:20:59 2019
From: cyaniventer at riseup.net (Cyaniventer)
Date: Tue, 30 Apr 2019 18:50:59 +0530
Subject: Enforcing password complexity for private keys
In-Reply-To: <FE640438-D96C-4E80-9AE5-E2282C04FFE2@gmail.com>
References: <FE640438-D96C-4E80-9AE5-E2282C04FFE2@gmail.com>
Message-ID: <20190430185059.241ce16c@lolcathost>

On Tue, 30 Apr 2019 06:55:07 -0400
David Milet <david.milet at gmail.com> wrote:

> Hello
> 
> We?re considering rolling out GnuPG at work for developers to sign
> git commits. How can we prevent developers from choosing a trivial
> password?
> 
> Is there a way for GnuPG to enforce some password complexity on the
> private keys?

imo long term solution will be to tell them more about passwords and
why choosing a good password is important.

Here are a few points you can include:
- how someone can crack their password
- what they can do to keep their accounts secure
- how to generate a good password
- how to use a password manager

-- 
Cyaniventer
BBBB 882A 5A00 FCB6 8704 E9BC 757D E342 DB4E 576C


From kauer at biplane.com.au  Tue Apr 30 17:32:37 2019
From: kauer at biplane.com.au (Karl Auer)
Date: Wed, 01 May 2019 01:32:37 +1000
Subject: Enforcing password complexity for private keys
In-Reply-To: <20190430185059.241ce16c@lolcathost>
References: <FE640438-D96C-4E80-9AE5-E2282C04FFE2@gmail.com>
 <20190430185059.241ce16c@lolcathost>
Message-ID: <1556638357.27758.10.camel@biplane.com.au>

On Tue, 2019-04-30 at 18:50 +0530, Cyaniventer wrote:
> On Tue, 30 Apr 2019 06:55:07 -0400
> David Milet <david.milet at gmail.com> wrote:
> > We?re considering rolling out GnuPG at work for developers to sign
> > git commits.
> > [...]
> imo long term solution will be to tell them more about passwords and
> why choosing a good password is important.

Might also be worth asking yourself why you feel you need to sign git
commits. Also, if the people you are asking to sign with a GPG key are
not savvy enough or interested enough to choose good passwords (I
assume you mean good passphrases?) then you might have problems that
GPG won't solve.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: 8D08 9CAA 649A AFEF E862?062A 2E97 42D4 A2A0 616D
Old fingerprint: A0CD 28F0 10BE FC21 C57C?67C1 19A6 83A4 9B0B 1D75




From juergen at bruckner.tk  Tue Apr 30 19:21:56 2019
From: juergen at bruckner.tk (Juergen Bruckner)
Date: Tue, 30 Apr 2019 19:21:56 +0200
Subject: Enforcing password complexity for private keys
In-Reply-To: <FE640438-D96C-4E80-9AE5-E2282C04FFE2@gmail.com>
References: <FE640438-D96C-4E80-9AE5-E2282C04FFE2@gmail.com>
Message-ID: <cc7cf203-cff9-2aa4-b1c8-d7c10b392b21@bruckner.tk>

Hello David,

have you ever thought about using SmartCards?
GnuPG has a built in SmartCard service.

regards
Juergen

Am 30.04.19 um 12:55 schrieb David Milet:
> Hello
> 
> We?re considering rolling out GnuPG at work for developers to sign git commits.
> How can we prevent developers from choosing a trivial password?
> 
> Is there a way for GnuPG to enforce some password complexity on the private keys?
> 
> Is that something that a Yubikey could do? 
> 
> Many thanks!
> David
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 

-- 
Juergen M. Bruckner
juergen at bruckner.tk

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3894 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190430/52486a60/attachment.bin>

From david.milet at gmail.com  Tue Apr 30 19:40:02 2019
From: david.milet at gmail.com (David Milet)
Date: Tue, 30 Apr 2019 13:40:02 -0400
Subject: Enforcing password complexity for private keys
In-Reply-To: <cc7cf203-cff9-2aa4-b1c8-d7c10b392b21@bruckner.tk>
References: <FE640438-D96C-4E80-9AE5-E2282C04FFE2@gmail.com>
 <cc7cf203-cff9-2aa4-b1c8-d7c10b392b21@bruckner.tk>
Message-ID: <CADDD1BF-D1BB-4AE5-A00A-C25371CC4674@gmail.com>

Yes, we?re considering using smart cards or usb devices like Yubikey.
Do those enforce password complexity?

To answer suggestions in other replies, our developers are savvy enough, and we do have recurring training in place to stress the importance of good passwords. But we know also that some developers will choose the weakest password the system allows, making them the weakest link.

> On Apr 30, 2019, at 13:21, Juergen Bruckner <juergen at bruckner.tk> wrote:
> 
> Hello David,
> 
> have you ever thought about using SmartCards?
> GnuPG has a built in SmartCard service.
> 
> regards
> Juergen
> 
>> Am 30.04.19 um 12:55 schrieb David Milet:
>> Hello
>> 
>> We?re considering rolling out GnuPG at work for developers to sign git commits.
>> How can we prevent developers from choosing a trivial password?
>> 
>> Is there a way for GnuPG to enforce some password complexity on the private keys?
>> 
>> Is that something that a Yubikey could do? 
>> 
>> Many thanks!
>> David
>> _______________________________________________
>> Gnupg-users mailing list
>> Gnupg-users at gnupg.org
>> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>> 
> 
> -- 
> Juergen M. Bruckner
> juergen at bruckner.tk
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users


From david.milet at gmail.com  Tue Apr 30 20:04:55 2019
From: david.milet at gmail.com (David Milet)
Date: Tue, 30 Apr 2019 14:04:55 -0400
Subject: Enforcing password complexity for private keys
In-Reply-To: <b5a97f5b286f2be999d73251226ff87592ed2fdd.camel@gentoo.org>
References: <FE640438-D96C-4E80-9AE5-E2282C04FFE2@gmail.com>
 <cc7cf203-cff9-2aa4-b1c8-d7c10b392b21@bruckner.tk>
 <CADDD1BF-D1BB-4AE5-A00A-C25371CC4674@gmail.com>
 <b5a97f5b286f2be999d73251226ff87592ed2fdd.camel@gentoo.org>
Message-ID: <2CD2D04A-6B73-410A-878E-F239F9526648@gmail.com>

Believe me we have long and passionate discussions about passwords length and complexity.

The question in my post is purely technical.


> On Apr 30, 2019, at 13:51, Micha? G?rny <mgorny at gentoo.org> wrote:
> 
>> On Tue, 2019-04-30 at 13:40 -0400, David Milet wrote:
>> Yes, we?re considering using smart cards or usb devices like Yubikey.
>> Do those enforce password complexity?
>> 
>> To answer suggestions in other replies, our developers are savvy enough, and we do have recurring training in place to stress the importance of good passwords. But we know also that some developers will choose the weakest password the system allows, making them the weakest link.
>> 
> 
> I dare say trying to enforce strong passwords via policy is usually
> a bad idea.  If you can't convince user to use and remember a good
> password, trying to force it via policy usually results either in:
> 
> a. passwords being noted down on paper, phone, etc., or
> 
> b. passwords becoming more predictable.
> 
> I can't know whether your users would actually do that but it's not
> uncommon problem that e.g. if you require password containing one digit
> and one special character, you replace trivial passwords with trivial
> passwords followed by '1!'.
> 
> -- 
> Best regards,
> Micha? G?rny
> 
> 


From juergen at bruckner.tk  Tue Apr 30 20:13:16 2019
From: juergen at bruckner.tk (Juergen Bruckner)
Date: Tue, 30 Apr 2019 20:13:16 +0200
Subject: Enforcing password complexity for private keys
In-Reply-To: <CADDD1BF-D1BB-4AE5-A00A-C25371CC4674@gmail.com>
References: <FE640438-D96C-4E80-9AE5-E2282C04FFE2@gmail.com>
 <cc7cf203-cff9-2aa4-b1c8-d7c10b392b21@bruckner.tk>
 <CADDD1BF-D1BB-4AE5-A00A-C25371CC4674@gmail.com>
Message-ID: <fbd6befd-1d04-2dbc-4f43-eb66da664cc7@bruckner.tk>

Well I may be (partly) wrong, but I guess a 6digit PIN-Code on the
GnuPG-Card may be complex enough for the most security settings.

my2c
Juergen

Am 30.04.19 um 19:40 schrieb David Milet:
> Yes, we?re considering using smart cards or usb devices like Yubikey.
> Do those enforce password complexity?
> 
> To answer suggestions in other replies, our developers are savvy enough, and we do have recurring training in place to stress the importance of good passwords. But we know also that some developers will choose the weakest password the system allows, making them the weakest link.
> 
>> On Apr 30, 2019, at 13:21, Juergen Bruckner <juergen at bruckner.tk> wrote:
>>
>> Hello David,
>>
>> have you ever thought about using SmartCards?
>> GnuPG has a built in SmartCard service.
>>
>> regards
>> Juergen
>>
>>> Am 30.04.19 um 12:55 schrieb David Milet:
>>> Hello
>>>
>>> We?re considering rolling out GnuPG at work for developers to sign git commits.
>>> How can we prevent developers from choosing a trivial password?
>>>
>>> Is there a way for GnuPG to enforce some password complexity on the private keys?
>>>
>>> Is that something that a Yubikey could do? 
>>>
>>> Many thanks!
>>> David
>>> _______________________________________________
>>> Gnupg-users mailing list
>>> Gnupg-users at gnupg.org
>>> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>>>
>>
>> -- 
>> Juergen M. Bruckner
>> juergen at bruckner.tk
>>
>> _______________________________________________
>> Gnupg-users mailing list
>> Gnupg-users at gnupg.org
>> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 

-- 
Juergen M. Bruckner
juergen at bruckner.tk

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3894 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190430/5792b6d0/attachment.bin>

From mgorny at gentoo.org  Tue Apr 30 19:51:57 2019
From: mgorny at gentoo.org (=?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=)
Date: Tue, 30 Apr 2019 19:51:57 +0200
Subject: Enforcing password complexity for private keys
In-Reply-To: <CADDD1BF-D1BB-4AE5-A00A-C25371CC4674@gmail.com>
References: <FE640438-D96C-4E80-9AE5-E2282C04FFE2@gmail.com>
 <cc7cf203-cff9-2aa4-b1c8-d7c10b392b21@bruckner.tk>
 <CADDD1BF-D1BB-4AE5-A00A-C25371CC4674@gmail.com>
Message-ID: <b5a97f5b286f2be999d73251226ff87592ed2fdd.camel@gentoo.org>

On Tue, 2019-04-30 at 13:40 -0400, David Milet wrote:
> Yes, we?re considering using smart cards or usb devices like Yubikey.
> Do those enforce password complexity?
> 
> To answer suggestions in other replies, our developers are savvy enough, and we do have recurring training in place to stress the importance of good passwords. But we know also that some developers will choose the weakest password the system allows, making them the weakest link.
> 

I dare say trying to enforce strong passwords via policy is usually
a bad idea.  If you can't convince user to use and remember a good
password, trying to force it via policy usually results either in:

a. passwords being noted down on paper, phone, etc., or

b. passwords becoming more predictable.

I can't know whether your users would actually do that but it's not
uncommon problem that e.g. if you require password containing one digit
and one special character, you replace trivial passwords with trivial
passwords followed by '1!'.

-- 
Best regards,
Micha? G?rny




From phill at thesusis.net  Tue Apr 30 20:11:54 2019
From: phill at thesusis.net (Phillip Susi)
Date: Tue, 30 Apr 2019 14:11:54 -0400
Subject: Enforcing password complexity for private keys
In-Reply-To: <CADDD1BF-D1BB-4AE5-A00A-C25371CC4674@gmail.com>
References: <FE640438-D96C-4E80-9AE5-E2282C04FFE2@gmail.com>
 <cc7cf203-cff9-2aa4-b1c8-d7c10b392b21@bruckner.tk>
 <CADDD1BF-D1BB-4AE5-A00A-C25371CC4674@gmail.com>
Message-ID: <87wojbwefp.fsf@vps.thesusis.net>

David Milet writes:

> To answer suggestions in other replies, our developers are savvy enough, and we do have recurring training in place to stress the importance of good passwords. But we know also that some developers will choose the weakest password the system allows, making them the weakest link.

And some will just write down the password on a sticky note stuck to
their monitor.  The more annoying you make password requirements, the
more likely this becomes.

Don't smartcards have a built in lockout policy that makes it impossible
to brute-force the password anyhow?  Given that, password complexity is
a moot point.



From david.milet at gmail.com  Tue Apr 30 23:59:12 2019
From: david.milet at gmail.com (David Milet)
Date: Tue, 30 Apr 2019 17:59:12 -0400
Subject: Enforcing password complexity for private keys
In-Reply-To: <fbd6befd-1d04-2dbc-4f43-eb66da664cc7@bruckner.tk>
References: <FE640438-D96C-4E80-9AE5-E2282C04FFE2@gmail.com>
 <cc7cf203-cff9-2aa4-b1c8-d7c10b392b21@bruckner.tk>
 <CADDD1BF-D1BB-4AE5-A00A-C25371CC4674@gmail.com>
 <fbd6befd-1d04-2dbc-4f43-eb66da664cc7@bruckner.tk>
Message-ID: <C2693FD5-0018-4FAD-B941-63239D6C8D17@gmail.com>

Indeed it?s specified in the OpenPGP card specs. 
I have my answers 
Thanks 
David

> On Apr 30, 2019, at 14:13, Juergen Bruckner <juergen at bruckner.tk> wrote:
> 
> Well I may be (partly) wrong, but I guess a 6digit PIN-Code on the
> GnuPG-Card may be complex enough for the most security settings.
> 
> my2c
> Juergen
> 
>> Am 30.04.19 um 19:40 schrieb David Milet:
>> Yes, we?re considering using smart cards or usb devices like Yubikey.
>> Do those enforce password complexity?
>> 
>> To answer suggestions in other replies, our developers are savvy enough, and we do have recurring training in place to stress the importance of good passwords. But we know also that some developers will choose the weakest password the system allows, making them the weakest link.
>> 
>>> On Apr 30, 2019, at 13:21, Juergen Bruckner <juergen at bruckner.tk> wrote:
>>> 
>>> Hello David,
>>> 
>>> have you ever thought about using SmartCards?
>>> GnuPG has a built in SmartCard service.
>>> 
>>> regards
>>> Juergen
>>> 
>>>> Am 30.04.19 um 12:55 schrieb David Milet:
>>>> Hello
>>>> 
>>>> We?re considering rolling out GnuPG at work for developers to sign git commits.
>>>> How can we prevent developers from choosing a trivial password?
>>>> 
>>>> Is there a way for GnuPG to enforce some password complexity on the private keys?
>>>> 
>>>> Is that something that a Yubikey could do? 
>>>> 
>>>> Many thanks!
>>>> David
>>>> _______________________________________________
>>>> Gnupg-users mailing list
>>>> Gnupg-users at gnupg.org
>>>> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>>>> 
>>> 
>>> -- 
>>> Juergen M. Bruckner
>>> juergen at bruckner.tk
>>> 
>>> _______________________________________________
>>> Gnupg-users mailing list
>>> Gnupg-users at gnupg.org
>>> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>> 
>> _______________________________________________
>> Gnupg-users mailing list
>> Gnupg-users at gnupg.org
>> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>> 
> 
> -- 
> Juergen M. Bruckner
> juergen at bruckner.tk
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users