Best Practices for Hardware Wallets supporting Sapling

Document how a hardware wallet (that has a trusted path to the user) should construct or verify transactions in order to protect its user, as far as possible, against attacks from the untrusted computer.

In the general case we have a hardware wallet, an untrusted computer, a delegated prover, a user, and a network connection, something like this:

             network
                ↕
h/w wallet ↔ computer ↔ prover
      ⤡       ⤢
         user

The h/w wallet should not trust the computer or the prover with spend authority, and should not allow a transaction confirmed by the user on the wallet's UI to be malleated while remaining valid. Similarly the computer should not trust the prover with spend authority (this is automatic when the computer is not trusted with that authority), or ability to malleate the intended transaction.

We believe that the Sapling design supports this without requiring the h/w wallet to be able to either prove or verify Spend or Output proofs. A h/w wallet should only need to implement:

• Pedersen commitments using Jubjub arithmetic (for note and value commitments)
• BLAKE2b and BLAKE2s (and the various PRFs / CRHs they are used in)
• Nullifier check (using Jubjub arithmetic)
• KDF plus either encryption or decryption (AEAD_CHACHA20_POLY1305)
• SignatureHash algorithm
• Signatures (RedJubjub, i.e. randomized EdDSA on the Jubjub curve)
• A source of randomness.