(pre)cache password rather than use allow-loopback-pinentry

With gpg2; it seems that as soon as you cat a batch.command sequence in - one can no longer use a pure terminal style TTY approach to having the agent fetch your password (gpg: signing failed: Inappropriate ioctl for device, gpg: make_keysig_packet failed: Inappropriate ioctl for device) as soon

Re: (pre)cache password rather than use allow-loopback-pinentry

> On 21 Jul 2017, at 08:46, Werner Koch wrote: > > On Thu, 20 Jul 2017 20:04, di...@webweaving.org said: > >> cat batch.commands | gpg2 --no-tty —batch —passphrase-XX XX >> --command-fd 0 --pinentry-mode loopback … > > This is not going to work. --command-fd must always be used in > co

Re: (pre)cache password rather than use allow-loopback-pinentry

> On 21 Jul 2017, at 10:05, Dirk-Willem van Gulik wrote: > >>> And then let the batch.commands (which does a complex dance of subkey >>> renewal and some chip card shuffling) run against that ? >> >> Please check wether some of the new --quick-foo command

Re: (pre)cache password rather than use allow-loopback-pinentry

> On 21 Jul 2017, at 11:20, Werner Koch wrote: > > On Fri, 21 Jul 2017 10:32, di...@webweaving.org said: > >> Those —quick commands are a huge help. The one thing missing seems to be one >> for the routine extension of the expiry of subkeys. > > In general I think that it is easier to just ad

Re: (pre)cache password rather than use allow-loopback-pinentry

On 21 Jul 2017, at 18:34, Werner Koch wrote: > > On Fri, 21 Jul 2017 11:37, di...@webweaving.org said: > >> And I really would not mind to be able to refer to subkeys by number -and- >> fpr; as the fpr of a subkey is a but cumbersome to extract afaik (double >> —fingerprint). > > Using the nu

gpgsm, keygrip

Tools such as gpg-preset-passphrase require the 40 character keygrip. The manpage of gpg-preset-passphrase(1) suggest that this is best extracted from gpgsm and that works nicely gpgsm --dump-secret-key | grep keygrip: keygrip: 123456789012345678901234567890123456789

Re: gpgsm, keygrip

> On 30 Jul 2017, at 12:39, Dirk-Willem van Gulik wrote: > > Tools such as > > gpg-preset-passphrase > > require the 40 character keygrip. The manpage of gpg-preset-passphrase(1) > suggest that this is best extracted from > > gpgsm > > and

caching of keys (passwords) during signing v.s. during --quick-add-subkey.

When I pre-cache a password of a fresh key: # Generate key gpg2 --batch --passphrase foo --quick-generate-key t...@test.com rsa4096 sign 5 .. extract keygrip of just regenated keys... # Precache password for next operations: gpg-preset-passphra

Scripted reset of PINs on smartcards.

Am I right in understanding that, unless one wants to get into chat-expect and a fair bit of state logic behind a `fake’ pinentry — one cannot easily edit the PINs on a (fresh) smartcard by piping in a command sequence? And in order to do so - does one really have to talk to the scdaemon directl

'sign (and cert)' or just 'cert' on a master key with subkeus

I see a growing number of keys that have well managed & expired separate subkeys for Signing, Encryption and Authentication switch from ‘SC’ on the master key to just ‘C’ (all RSA, ignoring DSA). Would anyone know if there is some documented best practice ? Dw __

Re: 'sign (and cert)' or just 'cert' on a master key with subkeus

> On 31 Jul 2017, at 17:41, Robert J. Hansen wrote: > >> Could probably be a direct application of this Debian article (1) on >> subkeys. And meant to to facilitate the recovery of the web of trust in >> case of disaster. >> >> On a separate tutorial (2), Alan Eliasen strongly advises against t

Re: gpgsm, keygrip

> On 8 Aug 2017, at 13:48, Werner Koch wrote: > > On Sun, 30 Jul 2017 14:52, di...@webweaving.org said: > >> Replying to my own question — the man page of of gpg-preset-passphrase >> should perhaps suggest to use ‘gpg —with-keygrip ..’ or ‘gpg —with-colons >> ..’. > > Thanks for the suggest

export secret subkeys

I am trying to understand the man page with regards to secret subkey exports. --export-secret-subkeys Same as --export, but exports the secret keys instead. The exported keys are written to STDOUT or to the file given with option --output. This command is often

Re: export secret subkeys

> On 17 Aug 2017, at 16:06, Peter Lebbing wrote: > > On 17/08/17 15:39, Dirk-Willem van Gulik wrote: >> # off=0 ctb=95 tag=5 hlen=3 plen=533 >> :secret key packet: >> version 4, algo 1, created 1502976628, expires 0 >> pkey[0]: [4096 bits] >>

Re: Slightly OT - i need the proper wording for a signed document

On 1 Nov 2018, at 18:32, Dirk Gottschalk via Gnupg-users wrote: > > Oh, you have also this issue? IO read about it in a Facebook group. > Libreoffice is complaining about a bad signature with Zertificates from > D-Trust even after importing the root. When you have the same problem, > they seem

Re: OpenPGP on paper (was: Where can I find some papers to read on mail (and envelope) security?)

On 1 Feb 2019, at 19:44, Stefan Claas wrote: > On Fri, 1 Feb 2019 17:53:09 +0100, Dirk-Willem van Gulik wrote: > >> It is a bit of a hack - and quite setting specific for us - but we’ve been >> using >> >> https://github.com/dirkx/gpg-offline-batch-key- &g

Re: BSI withdraws approval of GnuPG for confidential documents

> On 21 Aug 2019, at 21:28, Stefan Claas via Gnupg-users > wrote: > > Werner Koch via Gnupg-users wrote: > >> On Thu, 8 Aug 2019 17:22, gnupg-users@gnupg.org said: >> >>> maybe interesting for some community members, living in Germany. >> >> We learned about that last week and are trying t

v2.1 openpgp smartcard -- packing in after a `key to card'

During a pretty standard create key; key to card cycle (scripted) - I got an error gpg: OpenPGP card not available: Card removed just after the ‘save’ in the —edit-key. A subsequent status check gives me: gpg2 --card-status gpg: OpenPGP card not available: Card removed

Automatically generating subkey revocation certificates

When you generate the main key (even with a programmatic --quick-key-generate) - it nicely puts revocation certificats in the revocs.d directory of GNUPGHOME. But this does not seem to happen when doing a --quick-add-key subkey. Is this intentional ? Or is there a flag one can set ? Dw ___

Reason string revocation

Is there a flag that shows you the 'reason/explanation' string and cause when examining a revocation msg with gpg2 ? It seems that both --import and a simple 'gpg2 revoc.asc' show you the key - but not the rest of the info ? Dw. PS: and while on the topic - is there a deeper reason that --no

Re: Automatically generating subkey revocation certificates

> On 27 Dec 2019, at 20:52, Werner Koch wrote: > > On Thu, 26 Dec 2019 23:04, Dirk-Willem van Gulik said: > >> But this does not seem to happen when doing a --quick-add-key >> subkey. Is this intentional ? Or is there a flag one can set ? > > Right. If you

Re: Rationale/reasons for splitting Sign and Authenticate into two separate subkeys in a work-environment?

On 22 Dec 2020, at 13:31, Christian Chavez via Gnupg-users wrote: > My question is based on this awesome answer by Thomas Pornin: > https://security.stackexchange.com/a/43591 > ; > In a work-environment, what benefits does one gain by having separat

Re: Rationale/reasons for splitting Sign and Authenticate into two separate subkeys in a work-environment?

On 22 Dec 2020, at 16:16, Christian Chavez wrote: > Thanks for your reply - but I'm unfortunately lost as to your (what I surmise > is your implied) hypothetical use-case? It is a very common requirement that you find in gov. procurement documents/requirements of cryptographic technology tha

Re: Unable to decrypt file copied from USB thumb drive.

On 29 Oct 2021, at 10:17, Chris Taylor wrote: > I am developing a backup process for personal files, on USB thumb drive. I > tar and zip my files (30GB) then encrypt them with: > > gpg --no-symkey-cache --symmetric --cipher-algo AES256 my-backup.tar.gz > > I copy my-backup.tar.gz.gpg to my USB

Re: Second OpenPGP-card

> On 13 Feb 2024, at 17:32, Matthias Apitz wrote: > > El día martes, febrero 13, 2024 a las 09:57:17a. m. -0500, Henning Follmann > escribió: > >> On Tue, Feb 13, 2024 at 02:32:04PM +0100, Matthias Apitz wrote: >>> El día martes, febrero 13, 2024 a las 11:04:31a. m. +0100, Werner Koch via >>