Second OpenPGP-card

[Jacob Bachmeyer]

Matthias Apitz wrote:
> El día lunes, febrero 26, 2024 a las 06:40:26 -0600, Jacob Bachmeyer via Gnupg-users escribió:
>
>   
>> Matthias Apitz wrote:
>>     
>>> [...]
>>> Said/showed that, I can't imagine that, when I SCP the file
>>> .password-store/test.gpg to another mobile with another OpenPGP card,
>>> that this system would be able to decrypt the file and reencrypt it
>>> again with the new card.
>>>       
>> Correct.  You must first copy the *new* public key to the *old* system and
>> re-encrypt the password store to *both* public keys on the *old* system,
>> then transfer the encrypted blobs to the new system.
>> ...
>>     
>
> Thanks for the clarification and clear instruction.
>   

You are welcome.

>> While you are here, this is a good time to remind you to regularly check the
>> list of public keys used with your password store.  If Mallory can sneak
>> *his* key onto that list, he will be able to get your passwords!
>>     
>
> It says:
>
> purism at pureos:~$ gpg --list-keys
> /home/purism/.gnupg/pubring.kbx
> -------------------------------
> pub   rsa2048 2021-10-30 [SC]
>       336EB96892FE9FE7F6...................
> uid           [ultimate] Matthias Apitz (GnuPG CCID L5) <guru at unixarea.de>
> sub   rsa2048 2021-10-30 [A]
> sub   rsa2048 2021-10-30 [E]
>
> [...]

Are you sure that *that* is the list of public keys used by pass(1)?  It 
almost certainly is not, since GPG's public key collection is meant to 
collect keys for a variety of uses.  For example, sending encrypted 
emails or verifying signatures.  You probably do not want your password 
store encrypted to everyone you correspond with!

Therefore, pass(1) almost certainly has its own list of keys stored 
somewhere else.  Your regular public key was probably copied to that 
list when you initialized the password store.  That is the list that you 
need to regularly check, lest Mallory be able to sneak his key onto it.  
That list is *also* where you need to add your new public key in order 
to migrate your password store.

Lastly, I know that you are using a smartcard, but you are storing 
long-lived (and presumably valuable) authentication tokens here.  Does 
the card support RSA4096 or at least RSA3072?  If so, I would strongly 
recommend migrating to longer keys, as RSA2048 is currently the shortest 
not probably already broken by increasing conventional computing power 
to throw at factoring.  If I understand correctly, this is the reason 
that DSA is obsolete:  DSA (to support smartcard implementations) 
specifies exactly one allowed key length:  1024 bits.  While DSA uses 
discrete logarithms, the discrete logarithm and factoring problems have 
a mathematical equivalence that means a factoring algorithm can be used 
to derive a solution to the discrete logarithm problem and /vice 
versa/.  Accordingly, RSA1024 is now considered sufficiently dubious 
that some implementations no longer support it, such as the 
go-crypto/openpgp library used by the newer "hockeypuck" keyserver 
software, which led to an interesting recent thread on gnupg-devel and 
bunch of old keys effectively falling out of the Web of Trust.


-- Jacob