You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This encrypts the bip39 seed in RAM in the same way as the seed is
encrypted, using the secure chip for key stretching.
Since decryption (key stretching) takes around 100ms, this has a
performance impact on every operation that needs the an xprv or xpub:
- computing xpubs
- getting private keys to sign something
- etc.
This has an impact especially in Bitcoin transaction signing, as we
need the xpub at every transaction input during the first round of
input streaming and for every change output. The xprv is needed twice
per input when signing the input (once for the antiklepto nonce
commit, then for signing).
The performance impact was mitigated previously by
463b1f6, which sped up the first
round of input streaming by caching xpubs - only one xpub per script
type is needed for the whole transaction for single sig, where we only
support three script types (p2wpkh, p2wpkh-p2sh, p2tr). In multisig,
it is only one xpub.
Here are some performance numbers:
If you had a 50 inputs tx signed with antiklepto enabled, my
experiment resulted in:
- loading tx (stream inputs): ~30s, before xpub caching was activated
- loading tx (stream inputs): ~6s, after xpub caching was activated
- signing tx: 50*2*100ms: ~10s.
I.e. Xpub caching saved more than seed decrypting added.
Another place where this has a performance impact: retrieving
xpubs. When the user connects the BitBox02 for the first time to the
BitBoxApp, the BitBoxApp gets 3 xpubs right away (one per single sig
script type) for Bitcoin, 2 xpubs for Litecoin, 1 for Ethereum. Each
xpub computation is also performed twice (`see _get_xprv_twice()`) to
avoid catch potential bitflips. With 100ms per access this means a
delay of ~1.2s, which is noticable. Maybe a progress animation
can/should be added there.
0 commit comments