Keys in the keystore dir (private-keys-v1.d/) are being modified
Claudio Floreani
claudio.floreani at gmail.com
Tue Mar 12 15:33:11 CET 2019
Il giorno dom 10 mar 2019 alle ore 20:10 Werner Koch <wk at gnupg.org> ha
scritto:
> On Sun, 10 Mar 2019 15:54, claudio.floreani at gmail.com said:
>
> > After signing a file with my sign subkey I noticed that the private key
> > file of the sign subkey was modified. Why? What happens?
>
> To speed up the migration and to not annoy you by asking for your
> passphrase for each private key, GnuPG defers a part of the migration to
> the time when you have to enter the passphrase anyway. This is what
> happened here.
>
Thank you Werner. So, if I understood it correctly, this should happen only
once for each key, the first time it is being used. Am I correct?
Are there any discussion or extended comments about what is deferred during
the migration, without having to scrabble around the source code? In
particular, I am interested in knowing 1) whether the "partially migrated"
keys have the same level of security of the "fully migrated" keys or not 2)
if also the private master key have to be used before being fully migrated.
Please be aware that future versions of GnuPG _may_ update the file with
> the private key to record certain meta data.
>
If I may ask, do you think it will be a good idea to update metadata inside
the private keys?
I feel much more comfortable if my private keys do never change, so that I
can just compare their checksum or ask the VCS in order to know that they
have not been tampered. Sacrificing this assurance to have some less or
more useful metadata stored inside them, just doesn't seem worth the
benefits.
What I expected was that the agent could decrypt the keys in volatile
memory and then just discard them after they have been used, instead of
full rewrite the keys in the persistent memory (a mobile storage, in my
case), which in turn adds a (tiny) security risk factor.
This arguments seems even more convincing considering that the metadata
associated with the keys could as well be written (encrypted or not it
depends on the kind of metadata) in a separate file.
Ciao,
Claudio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190312/36ea82fc/attachment.html>
More information about the Gnupg-users
mailing list