--- Log opened Thu Dec 02 00:00:49 2021 03:52 < real_or_random> Here's a (possibly stupid idea): Add something like a build identifier as aux_data to the nonce function. I don't really know if this is easily possible for the deterministic builds but I thought of something like the hash of all the dependencies plus the current commit id. 03:53 < real_or_random> That's defense in depth against (compiler) bugs that introduce faults in the computation of the challenge hash and thus would leak the secret key if someone would sign with the correct code and then with the buggy code 06:33 -!- hg [~halosghos@user/halosghost] has joined #secp256k1 06:59 -!- hg [~halosghos@user/halosghost] has quit [Read error: Connection reset by peer] 07:53 < andytoshi> https://googleprojectzero.blogspot.com/2021/12/this-shouldnt-have-happened.html possibly some lessons for us, or tricks we could steal for our own QA 07:54 < andytoshi> (though maybe not, it sounds like this guy did some pretty serious novel stuff to find this bug) 07:59 < andytoshi> heh, he complains that there was an "arbitrary 10000 byte size limit" on fuzzer inputs .. i just added conceptually-similar iteration limits to Bitcoin Core's fuzzer https://github.com/bitcoin/bitcoin/pull/22508 .. but i needed to do this because otherwise the time to run the fuzzer would be unbounded. he suggests replacing 10000 with 2^24 but is this really better? 08:00 < andytoshi> similarly he complains about fuzztests which parse objects but don't do anything with them ... but "doing anything" with crypto objects is extremely slow (especially the rsa sigs that he's talking about) 08:03 < sipa> i think what he's saying is more: for *this* test it should have been expected that there could be size-related edge-cases, and thus a much larger max fuzz length would help 08:04 < sipa> but i think in the end you can't go around the fact that even delimiting what the boundaries of your test conditions should be is a human decision, and can be wrong 08:06 < andytoshi> yeah, that's the takeaway i got from it. i think his suggestion to change the specific constant sorta masks that, although he does say earlier in the article that this is ultimately a human judgement call 08:06 < andytoshi> in any case, looking forward to his new fuzzer thing being publicly available 08:07 < andytoshi> i got this from https://lwn.net/Articles/877420/ ... the first commenter links to another article about improvements to gcc's -fsanitize which are also not publicly available....because they are currently finding kernel 0days and the author wants them fixed before he releases the analysis code! 08:07 < sipa> damn 08:11 < andytoshi> (well, ok, it found *one* and this was enough to freak the author out, because he's still improving things) 09:12 < real_or_random> that project zero story is pretty remarkable 09:13 < real_or_random> (And I like way it's told. No facepalms and pointing fingers.) 09:37 -!- hg [~halosghos@user/halosghost] has joined #secp256k1 10:25 -!- hg [~halosghos@user/halosghost] has quit [Read error: Connection reset by peer] 10:26 -!- hg [~halosghos@user/halosghost] has joined #secp256k1 11:52 -!- hg [~halosghos@user/halosghost] has quit [Read error: Connection reset by peer] 13:56 -!- hg [~halosghos@user/halosghost] has joined #secp256k1 14:10 < hg> andytoshi: I think I'm starting to get my bearings for your PR work (namely, if I'm understanding the rangeproof benchmark as well, it looks like the first verify line in the bulletproof benchmark is the most-comparable). But I'm still seeing a few things which are confusing me. For example, I'm having some trouble parsing what's happening with the nonce in the prove() benchmark; any chance you 14:10 < hg> can clarify for me what's happening there? 14:14 < andytoshi> hg: what PR work is that? 14:15 < hg> #108 on secp256k1-zkp 14:18 < hg> (sorry for lack of context; I had pinged you on it earlier but that was days ago) 14:22 < cfields> andytoshi: for a bit more context, hg is new to the DCI and is poking around at bulletproofs impls to get a better understanding of what's possible. Is there somewhere better to discuss the experimental work going on outside the upstream repo? 14:31 < hg> (yeah, that was also probably useful context to provide) 14:35 < andytoshi> oh very cool! no, i think here is the best place 14:35 < andytoshi> without looking at the PR, the `nonce` field is completely immaterial to the proof, it's just used as a RNG seed 14:36 < andytoshi> so it would not surprise me if, in the benchmark, i did something very sketchy and cryptographically insecure there 14:36 < hg> haha 14:37 < hg> okay, cool; similarly, the blind is hard-coded to 0x77; is that just a random number you picked, or is that relevant? 14:38 < andytoshi> nope, just a number i picked 14:38 < hg> solid 14:38 < andytoshi> basically all the input data can be arbitrory/random 14:38 < andytoshi> arbitrary 14:39 < hg> then I have one other question which may just be a lack of understanding on my part. the n_bits parameter for prove() determines the upper-bound for the interval, and there's a separate min argument being passed (which seems to correspond to the lower-bound 14:39 < hg> the upper-bound isn't passed to verify (because it seems verify is able to determine what the proven upper-bound is directly from the proof itself), but the min value is still passed to verify() 14:40 < hg> does that mean the lower-bound needs to be preserved separate from the proof? 14:40 < andytoshi> yes 14:40 < hg> interesting; is that also true of range proofs? 14:40 < andytoshi> no, rangeproofs embed the lower bound, because it's expected to be actually used (because they're so inefficient that we expected people would want to compress the range) 14:40 < andytoshi> with BPs the lower bound should basically always be 0 14:41 < hg> ahh, gotcha 14:41 < andytoshi> unless you have some external reason (e.g. in Elements we disalow 0-value outputs so we set the min to 1) to change it 14:42 < hg> cool; not quite sure where I'll land on that; but it seems possible then that I'll end up setting the lower-bound as a hard-coded global similar to what you do 14:42 < andytoshi> yeah i'd just set it to 0 14:42 < hg> andytoshi: thanks for letting me pick your brain on this! 14:42 < andytoshi> no worries! thanks for looking at my PR! 14:43 < hg> happily! I'm reasonably new to cryptography, but I'm reading/learning a lot; perhaps I'll be able to meaningfully contribute at some point ☺ 14:43 < andytoshi> :) 15:09 < hg> andytoshi: and, part of the fact that this PR implements “uncompressed” rangeproofs is that the resulting proofs are quite a bit larger/slower than they could be; am I grasping that right? 15:09 < hg> s/range/bullet/ 15:09 < andytoshi> hg: yep 15:09 < hg> cool 15:09 < andytoshi> the real proofs are logarithmic in the size of the uncompressed proofs 15:09 < hg> nice 15:10 < andytoshi> but the compression step is computationally expensive and doesn't need to be done on secure hardware 15:10 < andytoshi> so in this (series of) PRs i am separating them out 15:10 < hg> that seems very reasonable ☺ 16:46 -!- roconnor [~roconnor@coq/roconnor] has quit [Ping timeout: 256 seconds] 17:07 -!- roconnor [~roconnor@coq/roconnor] has joined #secp256k1 17:54 -!- hg [~halosghos@user/halosghost] has quit [Quit: WeeChat 3.3] 18:34 -!- kallewoof [~quassel@user/kallewoof] has quit [Ping timeout: 268 seconds] 18:48 < robot-dreams> Question that came up as I was thinking about PR #942, why does `gej` have an explicit `infinity` flag instead of implicitly checking `z = 0`? 18:52 < sipa> checking a flag is faster than comparing a field element to zero 19:07 < robot-dreams> Makes sense, thanks! And as a follow up, I assume you usually prefer "check the flag and do nothing if it's infinity" because it's faster than "use the Jacobian coordinate formulas anyway, they work whether it's infinity or not"? 19:08 < sipa> it depends... in constant-time code you're going to need to do the arithmetic anyway --- Log closed Fri Dec 03 00:00:50 2021