in the interests of saying something useful instead of idle musing:
We're all fretting about sourcing entropy for our master secrets (seed phrases if you prefer), but what about for the nonces we use when we sign?
Normal signing can use RFC6979 [1], also known as 'deterministic nonces': this trick means your wallet *doesn't need* to source any entropy/randomnes when it makes a signature; it creates a 'pseudorandom' value that is tied to the private key and the transaction you're signing; no one can figure it out, and you yourself can't screw up and accidentally use a low entropy, or repeated nonce. All good so far.
So the headline is, for most of us, nothing to worry about with nonces, ever. However there are 2 bad things: the first is very counterintuitive but worth explaining: a master secret can be a few bits short in entropy (say, 120 bits instead of 128 of pure randomness) and it's very unlikely to ever matter. But this is not true of nonces! If you sign say 100 times with a private key p, and you use nonces k that are just *a few bits less random than full 256 bits* you can leak your private key to a sophisticated mathematical attack. In this, you might think, 'well I don't use addresses so there'll never be 100 signatures on one key p' -- but, careful: if you use an HD wallet (and everyone does), then knowing the pubkey means knowing the relationship between all the private keys on the branch, so the attack can still work if the attacker knows the xpub. **None of this matters if you use RFC6979**.
Second bad thing: RFC6979 cannot be used in MuSig2 or DahLIAS. It is profoundly insecure. It can be used, of course, in traditional multisig.
[1] RFC written by thomas pornin back in 2013; outside of bitcoin it's not well known, as most people back in the day, outside of bitcoin, thought using bernstein curve25519 was the solid industry standard and bitcoin's secp256k1 ECDSA was weird flaky nonsense that 'didn't even have deterministic nonces'; true, it originally didn't until this standard arrived [2]; btw people like Greg Maxwell were actively reviewing with Pornin at the time. As I recall Greg didn't like it a huge amount because it is quite an obscure construction and not so easy to byte-for-byte implement correctly. But obviously the idea is not only sound, but absolutely vital.
[2] and true, ECDSA *is* weird flaky nonsense...
We're all fretting about sourcing entropy for our master secrets (seed phrases if you prefer), but what about for the nonces we use when we sign?
Normal signing can use RFC6979 [1], also known as 'deterministic nonces': this trick means your wallet *doesn't need* to source any entropy/randomnes when it makes a signature; it creates a 'pseudorandom' value that is tied to the private key and the transaction you're signing; no one can figure it out, and you yourself can't screw up and accidentally use a low entropy, or repeated nonce. All good so far.
So the headline is, for most of us, nothing to worry about with nonces, ever. However there are 2 bad things: the first is very counterintuitive but worth explaining: a master secret can be a few bits short in entropy (say, 120 bits instead of 128 of pure randomness) and it's very unlikely to ever matter. But this is not true of nonces! If you sign say 100 times with a private key p, and you use nonces k that are just *a few bits less random than full 256 bits* you can leak your private key to a sophisticated mathematical attack. In this, you might think, 'well I don't use addresses so there'll never be 100 signatures on one key p' -- but, careful: if you use an HD wallet (and everyone does), then knowing the pubkey means knowing the relationship between all the private keys on the branch, so the attack can still work if the attacker knows the xpub. **None of this matters if you use RFC6979**.
Second bad thing: RFC6979 cannot be used in MuSig2 or DahLIAS. It is profoundly insecure. It can be used, of course, in traditional multisig.
[1] RFC written by thomas pornin back in 2013; outside of bitcoin it's not well known, as most people back in the day, outside of bitcoin, thought using bernstein curve25519 was the solid industry standard and bitcoin's secp256k1 ECDSA was weird flaky nonsense that 'didn't even have deterministic nonces'; true, it originally didn't until this standard arrived [2]; btw people like Greg Maxwell were actively reviewing with Pornin at the time. As I recall Greg didn't like it a huge amount because it is quite an obscure construction and not so easy to byte-for-byte implement correctly. But obviously the idea is not only sound, but absolutely vital.
[2] and true, ECDSA *is* weird flaky nonsense...
92❤️5❤️1👀1🖤1🤔1
