<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Il giorno dom 10 mar 2019 alle ore 20:10 Werner Koch <<a href="mailto:wk@gnupg.org">wk@gnupg.org</a>> ha scritto:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, 10 Mar 2019 15:54, <a href="mailto:claudio.floreani@gmail.com" target="_blank">claudio.floreani@gmail.com</a> said:<br>
<br>
> After signing a file with my sign subkey I noticed that the private key<br>
> file of the sign subkey was modified. Why? What happens?<br>
<br>
To speed up the migration and to not annoy you by asking for your<br>
passphrase for each private key, GnuPG defers a part of the migration to<br>
the time when you have to enter the passphrase anyway.  This is what<br>
happened here.<br></blockquote><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Please be aware that future versions of GnuPG _may_ update the file with<br>
the private key to record certain meta data.<br></blockquote><div>If I may ask, do you think it will be a good idea to update metadata inside the private keys?</div><div>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.</div><div>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.</div><div>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.</div><div class="gmail_quote"><br></div>Ciao,</div><div class="gmail_quote"><br></div><div class="gmail_quote">  Claudio</div></div></div></div></div></div></div>