User:Gmaxwell/derandomized nonce notes - Revision history

Gmaxwell: /* Shouldn't Bitcoin use ed25519 because it has derandomized nonces? */

2021-03-08T02:41:18Z

Shouldn't Bitcoin use ed25519 because it has derandomized nonces?

← Older revision		Revision as of 02:41, 8 March 2021
Line 6:		Line 6:
	RFC6979 specifies a nonce scheme that any DL signature system (such as ECDSA with secp256k1) can use. It's been in common use in Bitcoin since 2015 and is now nearly ubiquitous.		RFC6979 specifies a nonce scheme that any DL signature system (such as ECDSA with secp256k1) can use. It's been in common use in Bitcoin since 2015 and is now nearly ubiquitous.

	Both standard RFC6979 and the ed25519 scheme have demonstrated some minor weaknesses in the fact of differential power analysis (power/emi ~~sidechannels~~) and as a result the state of the art these days is "synthetic nonces" which combine most of the advantages of de-randomization with by hashing secret values with the message and a counter or random input to make it so a DPA attacker can't get multiple recordings of the same trace.		Both standard RFC6979 and the ed25519 scheme have demonstrated some minor weaknesses in the fact of differential power analysis (power/emi side-channels) and as a result the state of the art these days is "synthetic nonces" which combine most of the advantages of de-randomization with by hashing secret values with the message and a counter or random input to make it so a DPA attacker can't get multiple recordings of the same trace.

	Both RFC6979 and ed25519 also lack a clear an unambiguous domain separation in their hashing. If you use the same nonce scheme in different protocols (potentially even w/ different curves) you may inadvertently reuse a nonce and compromise your security. This issue can be avoided through the use of tagged hashes and/or synthetic nonces.		Both RFC6979 and ed25519 also lack a clear an unambiguous domain separation in their hashing. If you use the same nonce scheme in different protocols (potentially even w/ different curves) you may inadvertently reuse a nonce and compromise your security. This issue can be avoided through the use of tagged hashes and/or synthetic nonces.

	Bitcoin's BIP340 learns from ed25519 and incorporates a recommended secure nonce scheme in the BIP to reduce the risk that implementer will get it wrong. The recommended scheme also learns from ~~its shortcomings~~ by using tagged hashes and supporting (optionally) synthetic nonces.		Bitcoin's BIP340 learns from ed25519 and incorporates a recommended secure nonce scheme in the BIP to reduce the risk that implementer will get it wrong. The recommended scheme also learns from the limitations of the ed25519 spec by using tagged hashes and supporting (optionally) synthetic nonces.

	It isn't technically possible to mandate any particular scheme for any of these cryptosystems, and it's just as well: People have also constructed specialized nonce schemes for BIP340 which achieve other useful properties such as provability eliminating signing devices using the nonce as a cover sidechannel, and also generating nonces in a way which is provably ~~determinstic~~ (using a large additional zero ~~knowedlge~~ proof) which is potentially useful in some multiparty protocols.		It isn't technically possible to mandate any particular scheme for any of these cryptosystems, and it's just as well: People have also constructed specialized nonce schemes for BIP340 which achieve other useful properties such as provability eliminating signing devices using the nonce as a cover sidechannel, and also generating nonces in a way which is provably deterministic (using a large additional zero knowledge proof) which is potentially useful in some multiparty protocols.

	<references/>		<references/>

Gmaxwell at 02:38, 8 March 2021

2021-03-08T02:38:50Z

← Older revision		Revision as of 02:38, 8 March 2021
Line 2:		Line 2:
	==Shouldn't Bitcoin use ed25519 because it has derandomized nonces?==		==Shouldn't Bitcoin use ed25519 because it has derandomized nonces?==

	Nonce generation in all conventional DL signature systems is purely an implementation function. The ed25519 specific had the foresight to specify a specific reasonable nonce generation scheme but unfortunately it's not possible to enforce that any particular scheme is used. As a result people have still managed to create implementations of ed25519 with insecure nonce generation, and worse<ref>some parties have have falsely assumed that the deterministic nonces were mandatory and made the signatures unique resulting in vulnerabilities.</ref>.		Nonce generation in all conventional DL signature systems is purely an implementation function. The ed25519 specific had the foresight to specify a specific reasonable nonce generation scheme but unfortunately it's not possible to enforce that any particular scheme is used. As a result people have still managed to create implementations of ed25519 with insecure nonce generation, and worse<ref>some parties have have falsely assumed that the deterministic nonces were mandatory with ed25519 and made the signatures unique resulting in serious vulnerabilities in some cryptocurrencies.</ref>.

	RFC6979 specifies a nonce scheme that any DL signature system (such as ECDSA with secp256k1) can use. It's been in common use in Bitcoin since 2015 and is now nearly ubiquitous.		RFC6979 specifies a nonce scheme that any DL signature system (such as ECDSA with secp256k1) can use. It's been in common use in Bitcoin since 2015 and is now nearly ubiquitous.

Gmaxwell: Created page with " ==Shouldn't Bitcoin use ed25519 because it has derandomized nonces?== Nonce generation in all conventional DL signature systems is purely an implementation function. The ed..."

2021-03-08T02:38:12Z

Created page with " ==Shouldn't Bitcoin use ed25519 because it has derandomized nonces?== Nonce generation in all conventional DL signature systems is purely an implementation function. The ed..."

New page

==Shouldn't Bitcoin use ed25519 because it has derandomized nonces?==

Nonce generation in all conventional DL signature systems is purely an implementation function. The ed25519 specific had the foresight to specify a specific reasonable nonce generation scheme but unfortunately it's not possible to enforce that any particular scheme is used. As a result people have still managed to create implementations of ed25519 with insecure nonce generation, and worse<ref>some parties have have falsely assumed that the deterministic nonces were mandatory and made the signatures unique resulting in vulnerabilities.</ref>.

RFC6979 specifies a nonce scheme that any DL signature system (such as ECDSA with secp256k1) can use. It's been in common use in Bitcoin since 2015 and is now nearly ubiquitous.

Both standard RFC6979 and the ed25519 scheme have demonstrated some minor weaknesses in the fact of differential power analysis (power/emi sidechannels) and as a result the state of the art these days is "synthetic nonces" which combine most of the advantages of de-randomization with by hashing secret values with the message and a counter or random input to make it so a DPA attacker can't get multiple recordings of the same trace.

Both RFC6979 and ed25519 also lack a clear an unambiguous domain separation in their hashing. If you use the same nonce scheme in different protocols (potentially even w/ different curves) you may inadvertently reuse a nonce and compromise your security. This issue can be avoided through the use of tagged hashes and/or synthetic nonces.

Bitcoin's BIP340 learns from ed25519 and incorporates a recommended secure nonce scheme in the BIP to reduce the risk that implementer will get it wrong. The recommended scheme also learns from its shortcomings by using tagged hashes and supporting (optionally) synthetic nonces.

It isn't technically possible to mandate any particular scheme for any of these cryptosystems, and it's just as well: People have also constructed specialized nonce schemes for BIP340 which achieve other useful properties such as provability eliminating signing devices using the nonce as a cover sidechannel, and also generating nonces in a way which is provably determinstic (using a large additional zero knowedlge proof) which is potentially useful in some multiparty protocols.

<references/>