> Would anyone know if there is some documented best practice ?
The standard advice applies: stick with the defaults.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
> On 30 Jul 2017, at 21:19, Dirk-Willem van Gulik wrote:
>
> 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 i
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
__
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
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
> 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 that works nicely
>
> gpgsm --dump-
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
