Comments (6)
I (might) have identified the problem and will now report it to tiny-secp256k1
. I'm documenting it here as well, in case someone encounters this issue in the future.
The behaviour in libsecp256k1
for auxRand === NULL
was changed in the following commits:
However, tiny-secp256k1
(might) be using a version of libsecp256k1
prior to these changes?
from noble-curves.
Understood. So, the libraries don't follow the spec. I've opened issues:
guggero/bip-schnorr#32 bitcoin-core/secp256k1#1365
from noble-curves.
I just read your conversation with @sipa. Thanks for the feedback.
Given this new information, it's clear the inconsistency in results is not due to libsecp256k1
itself. The discrepancy might be coming from how tiny-secp256k1
(from bitcoinjs-lib
) accesses libsecp256k1
or perhaps something else that I've overlooked.
Both tiny-secp256k1
and bip-schnorr
return different results when auxRand = Buffer.alloc(32, 0x00)
than when it is not passed. This is the reason I have been unable to pass Buffer.alloc(32, 0x00)
to @noble
to get the same deterministic result. But yes, it is very clear this is not an issue with @noble
.
To replicate my findings, you can run the test:
git clone https://github.com/landabaso/sign_schnorr_test.git
cd sign_schnorr_test
npm install
npm run test
I'm still trying to make sense of why this is happening and any insight would be appreciated. Anyway, feel free to close this issue since there is nothing wrong with @noble
. Thanks!
from noble-curves.
I think the issue should be reported to tiny-secp256k1. I'm not familiar with its architecture so can't provide a feedback.
from noble-curves.
https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#user-content-Default_Signing
Using unpredictable randomness additionally increases protection against other side-channel attacks, and is recommended whenever available. Note that while this means the resulting nonce is not deterministic, the randomness is only supplemental to security
In other words, we follow the spec. Are you saying libsecp256k1 does not follow it?
When a randomness is not available, passing a 32-byte all-zeros byte array should be fine. It would also make it deterministic. How does libsecp256k1 compute auxRand? Is it similar to ECDSA RFC6979?
from noble-curves.
Thank you for looking into this!
In other words, we follow the spec.
Understood. Indeed, there isn't a problem with this package. My inquiry was more about whether I could use it to replicate the behavior of libsecp256k1.
When a randomness is not available, passing a 32-byte all-zeros byte array should be fine.
I've tried this approach, and while the result is deterministic, it differs from the output of libsecp256k1.
How does libsecp256k1 compute auxRand?
As per the original issue, it was reported that libsecp256k1 produces the same result as the "bip-schnorr" npm package, but differs from the output of noble. I personally ran some tests to verify this report and found it to be accurate—both libsecp256k1 and "bip-schnorr" return the same value when the same input parameters are used (and no auxRand).
To understand how "bip-schnorr" handles auxRand
, I looked into their implementation. This line shows how they handle auxRand
:
Based on this, I believe libsecp256k1 follows a similar strategy.
In the meantime, I have updated my package to issue a console warning whenever the resulting signature may not align with the results from tiny-secp256k1, although the signature itself is valid. Thank you again, @paulmillr, for your input!
from noble-curves.
Related Issues (20)
- EdDSA: add validate-after-sign HOT 3
- Fp.fromBytes does not mod-reduce by default HOT 2
- What is the difference between getSharedSecret and ECDH_compute_key HOT 1
- Same private keys generate different signatures HOT 1
- P256 signature verification was succeed with 2 public key. HOT 3
- Secure Curves in the Javascript Web Cryptography API - secp256k1, X25519, X448, Ed25519, Ed448 HOT 6
- Wrong signature is generated HOT 8
- seeded (instead of random) ed25519 private key generation? HOT 1
- x25519 encrypt/decrypt? HOT 1
- Signature::fromHex wrong in 1.3.0 HOT 4
- Default bls12_381 is incompatible with Ethereum beacon chain HOT 8
- Incompatibility with old bls12-381 library: not in prime-order subgroup HOT 3
- H2CPoint to ProjectivePoint HOT 2
- Montgomery sample code doesn't compile. (PR submitted) HOT 1
- G2 Curve Points for `bn254.sign()` HOT 1
- Access to Fp types and finalExponentiate method HOT 1
- How do I convert a curve point into a public key? HOT 4
- Hello
- Include sha512_256 in file noble-curves.js HOT 1
- Ideas for v2 HOT 24
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from noble-curves.