--- Log opened Fri Jan 15 00:00:15 2021 03:00 -!- virtu [~virtu@gateway/tor-sasl/virtu] has quit [Remote host closed the connection] 03:00 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection] 03:05 -!- virtu [~virtu@gateway/tor-sasl/virtu] has joined #secp256k1 03:10 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #secp256k1 06:18 -!- dr-orlovsky [~dr-orlovs@31.14.40.19] has quit [Ping timeout: 256 seconds] 07:02 -!- dr-orlovsky [~dr-orlovs@31.14.40.19] has joined #secp256k1 08:13 -!- jonatack [~jon@213.152.162.74] has quit [Ping timeout: 264 seconds] 08:15 -!- jonatack [~jon@88.124.242.136] has joined #secp256k1 08:19 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #secp256k1 08:22 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 256 seconds] 08:38 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer] 08:39 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 08:47 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 240 seconds] 08:47 -!- jonatack [~jon@213.152.162.10] has joined #secp256k1 10:12 < BlueMatt> is there any interest in fuzztargeting mode upstream? We have it in libsecp and use it extensively to avoid crypto while fuzzing, we previously had some naive xor-based stuff that wasnt really self-consistent but andrew rewrote it and made itself-consistent by re-adding some crypto...there was discussion a few weeks ago about using the order-17 group for this, and presumably bitcoin core would also find it interesting, but you hit all kinds 10:12 < BlueMatt> of 'impossible' cases with it making it hard to actually use in any downstream applications....does anyone have a better idea? would upstream support a 'lol xor-based nonsense' fuzzing mode? 10:14 < sipa> what does a fuzztargeting mode entail? 10:23 < BlueMatt> as a drop-in replacement (compile-time, ie no changing size of pk/sks), make it easy for the fuzzer to guess valid pks/sks/signatures 10:24 < BlueMatt> eg easiest is do some xor operation to condense the whole pk/sk/signature down to a byte, fill the remaining bytes with zeros 10:40 < andytoshi> sipa: basically we try to maintain as much functionality as possible while making DL breakable 10:40 < andytoshi> by a fuzz harness 10:41 < andytoshi> our exhaustive test compilation mode allmost does this but then this triggers failures everywhere by producing the point at infinity with high probability 10:43 < andytoshi> one idea might be to use a tiny subgroup of the *multiplicative* scalar group rather than the *additive* scalar group 10:43 < andytoshi> e.g. in ecmult and ecmult_gen (and ecmult_multi :eek:) we compute 2^xG rather than xG ... except 2 is replaced by a suitable number to get a low order 10:44 < sipa> what is the goal? testing edge cases in libsecp? 10:44 < andytoshi> we might need to do this in conjunction with one of the tiny EC groups, because to do this correctly would require breaking DL 10:44 < sipa> or is the goal testing the calling application? 10:44 < andytoshi> the calling application 10:44 < andytoshi> though testing libsecp would be a nice side effect i suppose 10:45 < sipa> can't you just stub out all of libsecp? make a signature valid if it starts with a 0 bit, and invalid with a 1 bit? 10:45 < sipa> i feel like we've had this discussion before 10:45 < andytoshi> yes but BlueMatt wasn't part of it :P 10:46 < andytoshi> also "just" and "all of libsecp" don't fit together in a sentence :P 10:46 < sipa> i don't see the problem 10:46 < sipa> (which isn't saying there are no use cases for something like this, but i don't see them) 10:51 < BlueMatt> sipa: there isn't a "problem" per se (well, there is in the sense that its actually not entirey trivial to build, but that has to happen either way), I only noted when discussing it with andytoshi that it would likely be useful elsewhere. eg it would quite possibly be useful in bitcoin core script fuzzing 10:51 < BlueMatt> and if we just stub it out in our rust wrappers, then its not available for non-rust users. 10:52 < sipa> ah, i see 10:57 < BlueMatt> somewhat separately, its unclear exactly what the right strategy is here, and I was curious if anyone had any better ideas. 11:00 < sipa> it depends on what "consistency" you want the interface to have 11:01 < sipa> an abstract signing/verification interface can just do something very simple (xor, fixed bits, ...); it doesn't need EC-like arithmetic at all 11:01 < sipa> but if you introduce tweaking, key derivation, ... it gets harder 11:04 < andytoshi> i think we probably need bip32 and ecdh to be consistent, but nothing else 11:04 < andytoshi> making tweak_add commute with pubkey generation i don't think is too hard 11:05 < BlueMatt> right, I dont think its *too* bad, probably careful xor and fixed bit application will suffice, but it'd be nice to do something more clever 11:05 < BlueMatt> but, if there arent any ideas... 11:06 < BlueMatt> still, is this something upstream would want to have 11:08 < sipa> i'm unsure... 11:08 < sipa> i think it depends on how complex it is to come up with a useful way of stubbing 11:09 < sipa> if it's nontrivial it may be more worthwhile to have reusable 11:09 < BlueMatt> its easy for us to stub, in core, dunno 11:11 < andytoshi> i think if we did it upstream there'd be more of an obligation to do it "properly" 11:11 < andytoshi> i.e. more than just "bip32 and ecdh work, everything else will fail to be consistent" 11:13 < sipa> first of all: what should be easy? 11:14 < sipa> i expect you want to make it easy to forge a signature 11:14 < andytoshi> LN also has a case where you directly break DL, by finding a secret key "preimage" of a public key 11:14 < sipa> but should it be easy to say... guess a key derivation? 11:26 < sipa> what if arithmetic is still mod the group order, but points are just encoded with xcoord=DL, y=dontcare 11:26 < sipa> i guess that's not trivial enough; figuring out k+m*x mod n is too hard for a fuzzer 11:27 -!- belcher_ is now known as belcher 11:32 < BlueMatt> right, it really needs to boil down to a byte or two 11:32 < BlueMatt> preferably one. 11:34 < sipa> is it useful to have the group-like thing be cyclic and have order the actual scalar order? i guess not 14:57 -!- digi_james [sid281632@gateway/web/irccloud.com/x-gqeaucosxosvqckd] has quit [Ping timeout: 268 seconds] 14:58 -!- robot-dreams [sid463268@gateway/web/irccloud.com/x-weveujkfnsiccgjc] has quit [Write error: Connection reset by peer] 14:58 -!- Lightsword [~Lightswor@2604:a880:1:20::1d3:9001] has quit [Quit: ZNC] 14:58 -!- robot-dreams [sid463268@gateway/web/irccloud.com/x-uhgzatjvtwqykwof] has joined #secp256k1 14:59 -!- Lightsword [~Lightswor@2604:a880:1:20::1d3:9001] has joined #secp256k1 14:59 -!- digi_james [sid281632@gateway/web/irccloud.com/x-visoerqjrvfsrzfw] has joined #secp256k1 15:00 -!- dkrm [~dkrm@2001:41d0:8:3f7b::1] has quit [Ping timeout: 268 seconds] 15:01 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Remote host closed the connection] 15:01 -!- stackingcore21_ [~stackingc@2604:a880:2:d0::1bda:1001] has joined #secp256k1 15:01 -!- dkrm [~dkrm@2001:41d0:8:3f7b::1] has joined #secp256k1 15:05 -!- stackingcore21 [~stackingc@2604:a880:2:d0::1bda:1001] has quit [Ping timeout: 260 seconds] 16:57 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined #secp256k1 19:00 -!- queip [~queip@unaffiliated/rezurus] has quit [Read error: Connection reset by peer] 19:02 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Remote host closed the connection] 19:07 -!- queip [~queip@unaffiliated/rezurus] has joined #secp256k1 20:20 -!- andytoshi [~apoelstra@66.183.0.205] has joined #secp256k1 20:20 -!- andytoshi [~apoelstra@66.183.0.205] has quit [Changing host] 20:20 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined #secp256k1 --- Log closed Sat Jan 16 00:00:17 2021