Second passphrase feature request

[gnupg.org at terminada.io]

On 27/10/23 10:22, NIIBE Yutaka wrote>
> It sounds like you have a specific use case in mind, and I'm not sure if
> use of Gnuk Token is appropriate for that.

Well, it would be good to include implementation of the Blake2b hashing 
algorithm because then a simple device like FST-01SZ could also be used 
for signing blockchain transactions on Cardano, which uses ed25519 keys.

> 
> Technically, it is possible to use data of a private key to derive
> another.  I don't think there is an existing tool for OpenPGP to help
> this use case.

Yes, that would be a good feature because it would achieve three advantages:

1. It would remove the limitation of 3 key storage.  Since different 
second passphrase would generate different keys, effectively a single 
device can manage an infinite number of keys (limited only by unique 
second passphrases).

2. It would make the secret key storage more secure, or even 
un-crackable depending on strength of the second passphrase since the 
device would then really only be storing a partial key or seed.

3. It would enable plausible deniability.  Since every possible second 
passphrase would generate a valid key.  If subjected to a "wrench 
attack" the user can reveal a valid key but this may not be his most 
valuable key.

Eg: A User can prepare a throw away key in advance for disclosure in the 
event of a "wrench attack" and say that this is "the" key he uses with 
this smartcard.  The attacker has no way of knowing if that assertion is 
correct or not because he would see a working key.  The user can 
plausibly deny that he has any other key available from this particular 
smartcard.

By contrast, the way GnuPG used with FST-01SZ works today, an attacker 
will know immediately if the correct PIN is entered because the software 
will tell him.

> 
>> Would there be a way to add such a feature to Gnuk and gnupg?
> 
> It would be.  For Gnuk, it sounds like you are suggesting (or expecting)
> another design of token, like FIDO2, which has a secret in a device to
> derive (possibly many) keys.  (Sorry, I don't know about how Trezor
> devices are implemented.)

I don't think FST-01SZ hardware needs to be changed.  Though maybe there 
are ways to simply add a secure element IC to the FST-01SZ design to 
improve the security of the partial key storage.  I don't know how 
feasible this would be or even if it would be worth doing.

> 
> It would be good to add a feature to GnuPG, which supports generating
> OpenPGP key from externally generated raw private key material (by some
> derivation mechanism using secret like existing private key (in OpenPGP
> format or whatever)).
> 
> Currently, GnuPG has a limited support to generate OpenPGP key from
> existing card key.  This feature could be generalized/enhanced.
> 

Excellent.  Would you consider adding this feature?

Note that adding this second passphrase feature can have zero impact on 
current usage patterns for users that didn't want to use it.  This is 
because using an empty passphrase would simply use the key stored, 
unchanged.  You could simply add a menu option to enable this second 
passphrase feature so the user is prompted to enter a second passphrase. 
  If the feature is not enabled, then the empty second passphrase is 
always used without any prompting, which would provide the exact same 
usage pattern as current.

This is exactly how the Trezor devices work with their second passphrase 
feature.

> 
> In Gnuk, passphrase is not stored in the device, at all.  Passphrase is
> used to decrypt your key on the device.

OK, I think that is better than what the Trezor devices are doing for 
key storage.

However, as Gnuk is currently implemented, if the key was copied from 
the device still in it's encrypted state, is it possible to know when 
the data is successfully decrypted by applying AES decryption with 
guessed PINs?  IE: Can you know when successfully decrypted because you 
see a specific header byte sequence?