* To protect against differential power analysis, a different way of
> mixing in this randomness is used (masking the private key completely
> with randomness before continuing, rather than hashing them together,
> which is known in the literature to be vulnerable to DPA in some
> scenarios).
>
I
Practically speaking, most hardware wallets allow you to import your own
BIP39 seed, so you can work around key generation attacks today, with a one
time inconvenience at the start. However, with the signing nonce attacks, a
user today has no protection.
Mitigating key generation attacks would be
It seems that many on this list think deeply enough to imagine the scenario
where we have few days left before a difficulty adjustment comes up but we
also see mining power dropping off at a rate that suggests the few days
might become a few weeks, and then, possibly, a few months or even the
unth
On Sat, Mar 21, 2020 at 12:46 PM Tim Ruffing via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi Pieter,
>
> Let's take a step back first. If we believe that malicious hardware
> wallets are big enough of a concern, then signing is only part of the
> problem. The other issue is ke
Chris,
Thank you for taking the time to share your thoughts. I agree there are wide
considerations surrounding key handling and storage. I dont think my proposal
interferes with that perspective any more than BIP32 itself would. How keys are
handled is a separate matter than the cryptography of
Hi Pieter,
That's a really nice overview.
Let's take a step back first. If we believe that malicious hardware
wallets are big enough of a concern, then signing is only part of the
problem. The other issue is key generation. The PRG from which the seed
is derived can be malicious, e.g., just H(k_
