On Thu, Aug 15, 2013 at 7:26 PM, Gregory Maxwell wrote:
> I am wondering if we shouldn't have a BIP32 addendum which makes the
> following signing related recommendations:
Looks like we're in the midst of another DSA duplicated K disaster.
(Now, blockchain.info mywallet)
I talked to Pieter about
I personally like the full-measure of eliminating the "CS-PRNG" entirely
from signing. If the "random" component is assumed to be untrusted,
keeping it in there adds no value, while eschewing the main benefit of
deterministic signing (ease of testing, auditing)
This just leaves the CS-PRNG
On Fri, Aug 16, 2013 at 01:32:39PM +0200, Mike Hearn wrote:
> and analysing it is really hard (plus it inverts the threat model - if you
> trust your computer and not your hardware wallet, why do you have a
> hardware wallet?)
Myself I would trust neither the hardware wallet nor my computer...
So
I filed a bug in the bitcoinj tracker for this a few days ago referencing
rfc 6967, but that RFC is very complicated and I'm not sure it's really
necessary to go that far. H(sighash||key) is easy to implement and I feel I
understand it better.
In our case it wouldn't have helped anyway - if anythi
I am wondering if we shouldn't have a BIP32 addendum which makes the
following signing related recommendations:
(1) Recommend a specific deterministic DSA derandomization procedure
(a deterministic way to generate the DSA nonce), presumably one based
on HMAC-SHA512 (since BIP32 uses that construct
5 matches
Mail list logo
