Closed jefft0 closed 10 months ago
I agree this is a smart approach. What's important is not just having a valid password, but being able to use the private key's functions. When using alternatives like a ledger or multisig, the user experience (UX) won't be the same.
For command-line interfaces (CLI), a good method is to skip the initial checks and only check for errors or problems when you actually need to sign something with the private key.
For mobile apps or systems with a sign-up process, I see why you'd want this method, and I think it's a good enough solution.
However, with a ledger, you wouldn't do this check because it's not helpful and can be annoying. Instead, you should just confirm the public key, either through the ledger's API or by scanning a QR code or something similar. So, in some cases, like with a ledger, you might choose to not check at all and just wait until you really need to use the key.
Thanks for the detailed response. This answers our question. Should we close this issue?
The gnoclient package proposed in https://github.com/gnolang/gno/pull/1047 has a
Validate
method with a TODO for "Also verify if the password unlocks the account." GnoMobile has a copy of the gnoclient package. In our copy we have implemented the password check by creating a blank transaction and calling the available interface method forSign
. This works and is fairly compact.Our question: Is there a preferred or better way to do a test decryption of the private key? (There are lower-level functions but those are private and specific to a particular Keybase implementation.)