--- Log opened Wed Dec 23 00:00:55 2020
00:26 -!- jessepos_ [~jp@2601:645:200:162f:b9d5:4819:405c:7ac5] has quit [Quit: Textual IRC Client: www.textualapp.com]
00:27 -!- jesseposner [~jp@2601:645:200:162f:b9d5:4819:405c:7ac5] has joined #secp256k1
04:36 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 240 seconds]
05:56 < real_or_random> https://mobile.twitter.com/real_or_random/status/1341742149088518145
06:54 -!- jonatack [~jon@88.124.242.136] has joined #secp256k1
06:58 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 246 seconds]
06:58 -!- jonatack [~jon@213.152.162.15] has joined #secp256k1
07:58 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #secp256k1
08:01 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 246 seconds]
08:03 -!- belcher_ is now known as belcher
08:06 < elichai2> lol
12:44 < andytoshi> in rust-secp we have a "fuzztarget" configuration option where we stub out sign/verify to be broken enough for a fuzzer to forge signatures. ideally we'd also stub out things like ec_tweak_add etc so that somehow the fuzzer could also target specific values, but if you start down this road you quickly wind up needing to reimplement the entire libsecp API with an alternate non-DL-hard group
12:44 < andytoshi> but it just occurred to me
12:44 < andytoshi> that we could instead set EXHAUSTIVE_TEST_ORDER=13 for this purpose, and then not stub anything out
12:45 < andytoshi> figured i should mention this on this channel to see what people's reactions are. discussion https://github.com/rust-bitcoin/rust-secp256k1/pull/264
12:46 < andytoshi> https://github.com/rust-bitcoin/rust-secp256k1/pull/264#issuecomment-750465754 more specifically
12:52 -!- jesseposner [~jp@2601:645:200:162f:b9d5:4819:405c:7ac5] has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
13:02 < sanket1729> andytoshi: a basic question, why do you want to forge signatures in fuzz testing? If you want to forge, why not always return a dummysig for sign and true for verify?
13:08 < andytoshi> sanket1729: because always returning true is also not useful :)
13:09 < andytoshi> sanket1729: you need to maintain the property that signing produces a valid sig with same key/same message, and you also want to be able to exercise both sides of a signature check even if the sig came from external input
13:09 < andytoshi> hmmm..having some trouble with the schnorrsig module, which aborts during signing if it generates a bad nonce (but it does this 1/13th of the time with an order-13 group)
13:18 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #secp256k1
13:24 < andytoshi> oh, this won't be too hard to fix in the rust API actually, so the user will still see the sig succeed
14:25 -!- Lightsword [~Lightswor@2604:a880:1:20::1d3:9001] has joined #secp256k1
14:27 -!- Lightsword [~Lightswor@2604:a880:1:20::1d3:9001] has quit [Client Quit]
14:29 -!- Lightsword [~Lightswor@2604:a880:1:20::1d3:9001] has joined #secp256k1
18:14 < andytoshi> hmm, next issue is that tweaking may fail
18:14 < andytoshi> like, will wind up benig the point at infinity, with nontrivial probability
18:20 < andytoshi> BlueMatt: so, "invalid tweak" is another thing that ought to be cryptographically unreachable, but is actually pretty easy to hit when you're using a low-order group
18:21 < andytoshi> i really like this concept but if we're gonna have asserts on cryptographically unreachable conditions, i don't think it's workable
18:21 < andytoshi> an alternate strategy might be to _not_ assert on these events, and use the fuzzer to test the error paths
18:26 < andytoshi> sipa: curious if you've been following this and if you have any thuoghts
18:27 < andytoshi> the premise is basically, what if we run a fuzzer against our rust code which was able to break the discrete log problem
18:27 < andytoshi> well, even stronger than that, a fuzzer who could break the discrete log and also get 0 scalars out of hash functions
18:29 < sipa> you need a separate build anyway, is there that much advantage over specifically using the low-order group, over a simple stub that doesn't use secp256k1 at all?
18:29 < andytoshi> the low-order group stubs out every function at once, with basically zero work from me :P
18:29 < sipa> the low order group doesn't help you make hashes easy to break either, for example
18:29 < andytoshi> right, we separately have to stub out our hash lib
18:30 < andytoshi> and that'll also be a bunch of work, but hashes at least don't have a bunch of algebraic invariants that we have to maintain when we do the stubbing
18:31 < sipa> do you care about those algebraic invariants?
18:31 < andytoshi> a few of them, yes. in particular we care that two people can compute the same ECDH shared secret
18:31 < andytoshi> and i _think_ we care that the seckey tweak_add function is consistent with the pubkey tweak_add function
18:31 < andytoshi> in both xonly and the normal-pubkey cases
18:32 < sipa> right, i can see how that may matter for some use cases
18:33 < andytoshi> i think these are the only ones that they care about. but they're enough to force you to implement an actual group structure on your stub functions, and an ec_pubkey_create thhat does a homomorphism
18:33 < sipa> fwiw, i've considered a fuzz design for bitcoin script that sort of exists of "meta opcodes" read from the fuzz stream, which includes a few common pubkeys, and opcodes to push a signature (computed by the actual signer code) using the known private keys for those pubkeys, with common sighash flags
18:33 < sipa> to avoid the need for replacing any real cryptography
18:33 < sipa> obviously doesn't alleviate the need for it entirely
18:34 < andytoshi> yeah that might be a worthwhile approach. right now all of our fuzztests do adhoc byteparsing things but we really ought to implement a Core-like object which can read abitrary objects from the fuzz stream
18:34 < andytoshi> including keypairs where it can get the secret key for any public key it can get
18:35 < andytoshi> (actually maybe matt has written a proper fuzz-input framework. but all of _my_ fuzztests do little more than utf8-decoding a bytestream :P)
18:36 < andytoshi> lol i wonder even if we just stubbed out all the SecretKey and PublicKey constructors in rust-secp, if that could be enough
18:37 < sipa> most of my fuzz tests don't do any fancy deserialize-object-from-fuzz-stream... more just read a byte at a time with adhoc dispatch
18:38 < sipa> this one found many bugs: https://github.com/bitcoin/bitcoin/blob/master/src/test/fuzz/txrequest.cpp#L318L372
18:39 < andytoshi> lol. ok, yeah, that looks like the kinda thing i usually do
18:39 < andytoshi> BlueMatt somehow is building and tearing down whole lightning paths off of fuzz input
18:39 < andytoshi> but i've never looked at how he implemented that
20:50 < BlueMatt> yea, i do what sipa did, mostly, but also a few other ones....one that literally just reads fuzz input as if it were bytes off the wire has surprisingly managed to find integer overflows way deeper into state machines than I would have guessed, even if its slow enough to not be a huge win.
20:51 < BlueMatt> andytoshi: hmmmm, invalid tweak, my understanding was, is theoretically possible in some cases where you dont pick first and counterparty can figure out one input and control the other (or something like that, I'd need to go re-read comments)
20:52 < BlueMatt> andytoshi: so, at least for us, that might be ok...we handle some of the cases already, and could probably figure out how to handle others. still, maybe best to not have that fail and just do something broken and map it back in range or something?
21:20 -!- digi_james [sid281632@gateway/web/irccloud.com/x-ckjfcboybjfhlvon] has quit [Ping timeout: 260 seconds]
21:20 -!- digi_james [sid281632@gateway/web/irccloud.com/x-ajegyoyysdzbukfe] has joined #secp256k1
21:21 -!- fjahr [sid374480@gateway/web/irccloud.com/x-rtehnbkvgybyoxca] has quit [Ping timeout: 260 seconds]
21:23 -!- fjahr [sid374480@gateway/web/irccloud.com/x-vsrtwhdhadmhgjgq] has joined #secp256k1
23:16 -!- digi_james [sid281632@gateway/web/irccloud.com/x-ajegyoyysdzbukfe] has quit [Read error: Connection reset by peer]
23:16 -!- zmanian_ [sid113594@gateway/web/irccloud.com/x-gxwimwgrgmiyoyym] has quit [Read error: Connection reset by peer]
23:16 -!- robot-dreams [sid463268@gateway/web/irccloud.com/x-ctuvkgeuixnjotzd] has quit [Ping timeout: 268 seconds]
23:18 -!- fjahr [sid374480@gateway/web/irccloud.com/x-vsrtwhdhadmhgjgq] has quit [Ping timeout: 258 seconds]
23:19 -!- digi_james [sid281632@gateway/web/irccloud.com/x-bsylfsfydaxyeiwf] has joined #secp256k1
23:19 -!- fjahr [sid374480@gateway/web/irccloud.com/x-gcdbhvogjdnlkdpw] has joined #secp256k1
23:20 -!- zmanian_ [sid113594@gateway/web/irccloud.com/x-hghifhplxrtnlcvw] has joined #secp256k1
23:20 -!- robot-dreams [sid463268@gateway/web/irccloud.com/x-pniwmfroowfxqwor] has joined #secp256k1
--- Log closed Thu Dec 24 00:00:55 2020