-
Notifications
You must be signed in to change notification settings - Fork 283
#264 restircted fuzz coverage due to conversion to real private -> public key conversion #271
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
So, the issue is that these unit tests reflect assumptions that are needed in real code. In particular, that if I do a BIP32 derivation on a series of secret keys, and sign with the result, that it will be verifiable by somebody who did the "same" derivation using the public keys. I think we were able to get away with having an inconsistent pubkey derivation scheme for so long because
Now that we are using the As a secondary thing, the more tests we can get to pass with the fuzztarget on, the more assuredness we have that we haven't badly broken it. For example, before the recent fuzz changes, elichai and I had totally broken context creation with |
There are a few options for how to move forward:
|
Right, I guess I also didn’t understand this as a now-supported feature - I was still under the impression fuzzing support in rust-secp remained a “well, I mean you can do it, but you’ll probably have to rewrite bits of upstream when you hit it breaking what you wanted”- feature. Which, I suppose, indeed, I hit it breaking when I went to upgrade and couldn’t easily fix our fuzztests.
In general, I’m fine with (1), and figure it’s pretty unlikely to generate much, but I admit (2) feels much nicer and more complete. Happy to take a stab at it but I’d need to think hard or have more guidance on what format you have in mind.
Matt
… On Jan 15, 2021, at 10:09, Andrew Poelstra ***@***.***> wrote:
There are a few options for how to move forward:
Do some dumb xor thing that isn't really consistent (but which we can make consistent with signing at least), and wait for people to file bugs because they hit "impossible" assertions when fuzzing.
Rewrite the whole fuzz harness to use a broken xor-y group, but make it actually be a group
Revisit using the order-17 group -- I have some ideas here which are a bit of a PITA but not nearly as much as creating a whole new group.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
As for (2), I want the following things to hold:
Unfortunately this is a really long list now. |
Can we set pk=sk? I think that would make an xor approach rather easy, though several operations would end up equivalent.
… On Jan 15, 2021, at 10:52, Andrew Poelstra ***@***.***> wrote:
As for (2), I want the following things to hold:
if you use seckey_tweak_mul then pubkey_create, or pubkey_create then pubkey_tweak_mul, you get the same result
ditto for the _add functions
ditto for the xonly variants of the above two
if you ECDSA sign with a seckey, then use pubkey_create and verify the resulting sig, it should pass
ditto for schnorr signatures
ditto for recoverable signatures
if you start with two secret keys, and turn either one of them into a pubkey with pubkey_create, then do ECDH with the resulting (secret, public) pair, you get the same result
Unfortunately this is a really long list now.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
You can, though it has the minor drawback of eliminating the "half of all pubkeys are invalid even though almost no secret keys are invalid" property. But you still have to re-implement basically the entire library in terms of that. |
This reduces the usage of real cryptography in --cfg=fuzzing, specifically replacing the secret->public key derivation with a simple copy and ECDH with XOR of the public and private parts (plus a stream of 1s to make a test pass that expected non-0 output). It leaves secret tweak addition/multiplication as-is. It also changes the context creation to over-allocate and store the context flags at the end of the context buffer, allowing us to easily test context flags in each function. While it would be nice to have something fancier (eg XOR-based), its not immediately obvious how to accomplish this, and better to fix the issues I have than spend too much time on it. Fixes rust-bitcoin#271. This partially reverts b811ec1
This reduces the usage of real cryptography in --cfg=fuzzing, specifically replacing the secret->public key derivation with a simple copy and ECDH with XOR of the public and private parts (plus a stream of 1s to make a test pass that expected non-0 output). It leaves secret tweak addition/multiplication as-is. It also changes the context creation to over-allocate and store the context flags at the end of the context buffer, allowing us to easily test context flags in each function. While it would be nice to have something fancier (eg XOR-based), its not immediately obvious how to accomplish this, and better to fix the issues I have than spend too much time on it. Fixes rust-bitcoin#271. This partially reverts b811ec1
This reduces the usage of real cryptography in --cfg=fuzzing, specifically replacing the secret->public key derivation with a simple copy and ECDH with XOR of the public and private parts (plus a stream of 1s to make a test pass that expected non-0 output). It leaves secret tweak addition/multiplication as-is. It also changes the context creation to over-allocate and store the context flags at the end of the context buffer, allowing us to easily test context flags in each function. While it would be nice to have something fancier (eg XOR-based), its not immediately obvious how to accomplish this, and better to fix the issues I have than spend too much time on it. Fixes rust-bitcoin#271. This partially reverts b811ec1
This reduces the usage of real cryptography in --cfg=fuzzing, specifically replacing the secret->public key derivation with a simple copy and ECDH with XOR of the public and private parts (plus a stream of 1s to make a test pass that expected non-0 output). It leaves secret tweak addition/multiplication as-is. It also changes the context creation to over-allocate and store the context flags at the end of the context buffer, allowing us to easily test context flags in each function. While it would be nice to have something fancier (eg XOR-based), its not immediately obvious how to accomplish this, and better to fix the issues I have than spend too much time on it. Fixes rust-bitcoin#271. This partially reverts b811ec1
This reduces the usage of real cryptography in --cfg=fuzzing, specifically replacing the secret->public key derivation with a simple copy and ECDH with XOR of the public and private parts (plus a stream of 1s to make a test pass that expected non-0 output). It leaves secret tweak addition/multiplication as-is. It also changes the context creation to over-allocate and store the context flags at the end of the context buffer, allowing us to easily test context flags in each function. While it would be nice to have something fancier (eg XOR-based), its not immediately obvious how to accomplish this, and better to fix the issues I have than spend too much time on it. Fixes rust-bitcoin#271. This partially reverts b811ec1
This reduces the usage of real cryptography in --cfg=fuzzing, specifically replacing the secret->public key derivation with a simple copy and ECDH with XOR of the public and private parts (plus a stream of 1s to make a test pass that expected non-0 output). It leaves secret tweak addition/multiplication as-is. It also changes the context creation to over-allocate and store the context flags at the end of the context buffer, allowing us to easily test context flags in each function. While it would be nice to have something fancier (eg XOR-based), its not immediately obvious how to accomplish this, and better to fix the issues I have than spend too much time on it. Fixes rust-bitcoin#271. This partially reverts b811ec1
This reduces the usage of real cryptography in --cfg=fuzzing, specifically replacing the secret->public key derivation with a simple copy and ECDH with XOR of the public and private parts (plus a stream of 1s to make a test pass that expected non-0 output). It leaves secret tweak addition/multiplication as-is. It also changes the context creation to over-allocate and store the context flags at the end of the context buffer, allowing us to easily test context flags in each function. While it would be nice to have something fancier (eg XOR-based), its not immediately obvious how to accomplish this, and better to fix the issues I have than spend too much time on it. Fixes rust-bitcoin#271. This partially reverts b811ec1
This reduces the usage of real cryptography in --cfg=fuzzing, specifically replacing the secret->public key derivation with a simple copy and ECDH with XOR of the public and private parts (plus a stream of 1s to make a test pass that expected non-0 output). It leaves secret tweak addition/multiplication as-is. It also changes the context creation to over-allocate and store the context flags at the end of the context buffer, allowing us to easily test context flags in each function. While it would be nice to have something fancier (eg XOR-based), its not immediately obvious how to accomplish this, and better to fix the issues I have than spend too much time on it. Fixes rust-bitcoin#271. This partially reverts b811ec1
This reduces the usage of real cryptography in --cfg=fuzzing, specifically replacing the secret->public key derivation with a simple copy and ECDH with XOR of the public and private parts (plus a stream of 1s to make a test pass that expected non-0 output). It leaves secret tweak addition/multiplication as-is. It also changes the context creation to over-allocate and store the context flags at the end of the context buffer, allowing us to easily test context flags in each function. While it would be nice to have something fancier (eg XOR-based), its not immediately obvious how to accomplish this, and better to fix the issues I have than spend too much time on it. Fixes rust-bitcoin#271. This partially reverts b811ec1
Sorry for the late comments on this one, but #264 is somewhat less appealing than the previous version at least in rust-lightning. Specifically, in our "lol just shove the whole library into the fuzzer" target, we want to be able to do state revocation by revealing the private key corresponding to a previously-provided public key. Obviously this would imply a real cryptographic operation on 32 bytes for the fuzzer to guess, which isn't possible. How important is it that all the tests pass in fuzz mode, and can we swap the private->public conversion to something more dummy, eg xor or simply map them 1:1?
The text was updated successfully, but these errors were encountered: