--- Log opened Thu Jan 05 00:00:05 2023
01:04 -!- jon_atack [~jonatack@user/jonatack] has quit [Ping timeout: 268 seconds]
01:06 -!- jon_atack [~jonatack@user/jonatack] has joined #secp256k1
03:03 < real_or_random> hm I started to add labels to some issues but it "touches" the issue, screwing the "recently updated" sorting... is that a problem? I could try to process in reverse order
03:09 < real_or_random> this is the list of labels I want to use: https://github.com/bitcoin-core/secp256k1/labels ... I kept invalid, wontfix, duplicate because I think these are predefined. but we don't need to use them
06:04 -!- roconnor [~quassel@coq/roconnor] has quit [Ping timeout: 268 seconds]
06:05 -!- roconnor [~quassel@coq/roconnor] has joined #secp256k1
06:48 < real_or_random> andytoshi: now that you ACKed 1186, what do you think about these two commits on top of it? https://github.com/bitcoin-core/secp256k1/pull/1187
06:48 < real_or_random> and thanks for the review by the way!
07:13 < sipa> Exhaustive tests with order 199 finished, somewhere between 146 and 176 CPU days.
07:13 < real_or_random> nice
07:19 < andytoshi> nice!
07:21 < andytoshi> real_or_random: am going out for breakfast in a moment, will check later today. but i just started my long-running "compile with a bunch of configs and valgrind" script on the whole thing
07:22 < sipa> The next bigger prime subgroup of a y^2=x^3+B curve over GF(2^256 - 2^32 - 977) that admits the GLV endomorphism has order 3319. Given that our exhaustive tests have O(order^5) complexity, I fear actually running that will remain infeasible for a while.
07:22 < real_or_random> you mean until DL is easy?
07:22 < sipa> It'd take half a million CPU years.
07:23 < real_or_random> hm I'd rather spend these on something else
07:23 < sipa> Yeah, I don't think it's particularly interesting either.
07:24 < sipa> It's great that it works for 199, but I don't think we'll learn anything from 3319 that we don't already learn from 13 and 199.
07:48 < real_or_random> the "interesting" diff of the jacobi PR is surprisingly small, given that posdivsteps is close to what we already have and some of this is just docs
07:48 -!- halosghost [~halosghos@user/halosghost] has joined #secp256k1
07:48 < sipa> Yeah, though the justification for its correctness is completely different.
08:10 < real_or_random> what does your code do when given an even modulus or modulus = 1? should it be documented that this needs to be an odd integer? (I mean it's kind of clear from the definition...) 
08:12 < sipa> You need to provide modulus^{-1} mod 2^62, which doesn't exist if the modulus is even.
08:12 < real_or_random> oh sure
08:13 < sipa> Though it could be made more explicit.
08:35 < real_or_random> added a comment
09:22 < andytoshi> oh ok i should've reviewed this PR before i left :P it just renames variables
09:22 < andytoshi> lgtm. acked.
09:29 < real_or_random> yeah I think the question is not really correctness but rather if it's a useful change. but I think yes, it clarifies the code.
09:30 < andytoshi> i definitely think it's useful
09:31 < andytoshi> as you saw in your first PR, having the lowercase `ctx` name meant that we would shadow it locally (or at least, i did, once) and it was very hard to tell
09:32 < andytoshi> real_or_random: as a final test cleanup (maybe after these PRs are done) i'd like to try to encapsulate the "ecount = 0; do_thing(ctx); CHECK(count == 1)" thing into a function so that we aren't manually setting error callbacks and maintaining the ecount variable
09:33 < sipa> Probably a macro? Otherwise you need the overhead of function pointers for everything etc.
09:33 < real_or_random> yep, probably a macro, but this will be very helpful indeed.
10:26 < andytoshi> my guess would be that the ovrehead would be okay, since most context-using ops are expensive anyway
10:27 < andytoshi> but maybe a macro would be simpler since we'd need different function pointer types
10:27 < andytoshi> and macros are untyped
10:27 < sipa> yeah, i don't think the performance impact matters
10:27 < sipa> but macros will be a lot more convenient
10:32 < halosghost> (completely random tangent: with the release of https://cpucycles.cr.yp.to/; what would people think of CI steps double-checking constant-timeness or tests documenting whether a function has degraded performance with the latest change?)
10:43 < real_or_random> sipa andytoshi: indeed, setting callbacks is just setting a pointer. that won't matter, even if the compiler can't figure out how to optimize multiple sequential invocations of the macro  
10:44 < sipa> halosghost: CI already tests constant-timeness using the valgrind technique
10:45 < sipa> And counting CPU cycles won't help for that, as there is always random jitter (even just memory layout being randomized, OS interrupts, ...) that don't matter for constant-timeness but do get measured.
10:45 < real_or_random> halosghost: checking constant-time via experiments is somewhat brittle though there are projects which do that. but yeah, I think our current approach is better.
10:45 < halosghost> 5sicool; fair enough ☺
10:45 < halosghost> yeah, that made sense
10:45 < halosghost> s/5si/sipa: /
10:46 < real_or_random> halosghost: but for benchmarks, that will make sense 
10:46 < halosghost> real_or_random: 👍
10:46 < real_or_random> our current "timing" code in the benchmarks is not that good, it could profit from using cycle counters
10:47 < sipa> the term "constant-timeness" is really badly named FWIW; it has nothing to do with being constant (even constant-time code is allowed to be variable time in public inputs or randomness), or even with time (at least not directly; just having secret-dependent memory accesses is a problem for CT on itself)
10:48 < real_or_random> and having automated and reliable infrastructure for comparing the performance of two revisions or two compilers/flags would be awesome. but that's a lot of work, and it's hard to run on cloud ci I guess ^^
10:48 < real_or_random> but if you're interested in this in general, improving the timing code in the benchmarks will certainly be useful on its own 
10:50 < real_or_random> sipa: hm, I don't think it's badly named. it's just not a property of an algorithm but of pair (algorithm, input variable). 
10:51 < real_or_random> ok in the end, we want more than just constant-time. we want also "constant-access-pattern" 
10:51 < halosghost> sipa: I suppose I've always read it as constant-time (with respect to any non-public parameter)
10:52 < halosghost> but I definitely agree that it's not really constant-time that you should care about (that's just an obvious one because timing side-channels are well-known)
10:52 < halosghost> also, I didn't mean to derail the discussion, just didn't want to forget to mention it
10:52 < sipa> I've seen people confuse constant-timeness with O(1) complexity (which it definitely has nothing to do with).
10:52 < real_or_random> indeed
10:53 < real_or_random> ok yes, that's certainly the wrong association
11:06 < andytoshi> it's also not necessarily constant -- it can be stochastic. it's just that the distribution of runtimes (and all other observable properties) needs to be independent of secret data
11:07 < sipa> ^
11:19 < halosghost> that's a totally fair point
11:20 < halosghost> also makes me want to explore adding sleeps for random times to every function call
11:20 < halosghost> sounds horrible ☺
11:20 < halosghost> but fun
11:22 < sipa> You laugh, but say you take a variable-time function, look up the time at the start, and then at the end sleep until the begin time + 10s... that's by a very reasonable interpretation "constant time" (assuming the computation never needs more than 10s), but it would not be what we'd call constant-time.
11:23 < halosghost> sipa: indeed; and I've done that before (for non-security-related purposes)
11:23 < halosghost> still, a fun notion ☺
14:02 -!- roconnor [~quassel@coq/roconnor] has quit [Ping timeout: 256 seconds]
14:02 -!- roconnor [~quassel@coq/roconnor] has joined #secp256k1
14:40 -!- halosghost [~halosghos@user/halosghost] has quit [Quit: WeeChat 3.7.1]
20:12 -!- jonatack1 [~jonatack@user/jonatack] has joined #secp256k1
20:13 -!- jon_atack [~jonatack@user/jonatack] has quit [Ping timeout: 260 seconds]
--- Log closed Fri Jan 06 00:00:06 2023