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?
_______________________________________________
Gnuk-users mailing list
[email protected]
https://lists.gnupg.org/mailman/listinfo/gnuk-users
