--- Log opened Mon Dec 27 00:00:13 2021 00:48 -!- jesseposner [~jesse@c-24-5-105-39.hsd1.ca.comcast.net] has quit [Ping timeout: 268 seconds] 00:56 -!- jesseposner [~jesse@c-24-5-105-39.hsd1.ca.comcast.net] has joined #secp256k1 01:00 -!- jesseposner_ [~jesse@c-24-5-105-39.hsd1.ca.comcast.net] has joined #secp256k1 01:01 -!- jesseposner [~jesse@c-24-5-105-39.hsd1.ca.comcast.net] has quit [Ping timeout: 256 seconds] 02:27 -!- meshcollider [meshcollid@meshcollider.jujube.ircnow.org] has quit [Changing host] 02:27 -!- meshcollider [meshcollid@user/meshcollider] has joined #secp256k1 06:03 < sipa> Oh, no! It is actually fine. It rescales the previous ctx->initial point, which also changes the outcome of ecmult_gen, which on its turn results in a changed ctx->initial point again. 07:20 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection] 07:21 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #secp256k1 07:22 < real_or_random> can't follow, sorry 07:24 < sipa> So the current secp256k1_ecmult_gen_blind function does the following: projectively rescales ctx->initial (so turn (x,y,z) into (a^2 x, a^3 y, a z)), then computes a random value b, computes ctx->initial = bG, and set ctx->blind = -b. 07:24 < sipa> When I saw this, I though: oh no, it is first rescaling ctx->initial, and then overwriting it, that's pointless. 07:26 < sipa> But it isn't. The rescaled ctx->initial value is used by the ecmult_gen computation of bG, and thus affects the resulting ctx->initial value. So it does two things at once: help blind the final ctx->initial value, but also helps blind its computation itself. 09:16 < robot-dreams> So you're saying, it's important that `secp256k1_ecmult_gen(ctx, &gb, &b)` actually uses the value of `ctx->initial` 09:16 < robot-dreams> Otherwise the previous call to `secp256k1_gej_rescale(&ctx->initial, &s)` would have been pointless? 09:22 < sipa> Not just uses; the blinding's effectiveness relies on the fact that the *output* (as in the actual jacobian coefficients of) `gb` actually depend on the chosen scaling factor. 09:30 < robot-dreams> What would happen if you got gb by multiplying the generator (with no projection hardening, z = 1) by a random b, and then used that as `ctx->initial`? 09:30 < robot-dreams> Are you worried about (1) adversary discovering `ctx->initial`, (2) adversary being able to discover gn for future calls to `ecmult`, both? 09:30 < robot-dreams> I intuitively see how projection hardening helps with (1), but I don't yet see how `ctx->initial` depending on the chosen scaling factor helps with (2) 09:31 < sipa> There are two independent blinding techniques being used here. 09:31 < robot-dreams> Yes, agreed: randomizing the coordinates for a given point, and randomizing b 09:32 < sipa> The first is having ctx->initial = b*G, ctx->blind = -b. That blinds the scalar additively, and corrects for it by having a starting point that compensates. 09:32 < sipa> The second blinding technique is using randomized Jacobian coordinates for ctx->initial. 09:32 < sipa> I'm only talking about the second technique here. 09:33 < robot-dreams> Yeah that makes sense. I guess in light of that, I'd reword my question as: what goes wrong if you use the first technique only and drop the second? 09:33 < sipa> As with all blinding techniques: ideally, nothing. 09:34 < sipa> I guess that's not entirely fair. We do rely on the additive scalar blinding for some measure of resistance against power analysis. 09:35 < sipa> Which we don't provide any guarantees for, but it can't hurt to take some steps. 09:37 < sipa> But still, I think it's fair to say that all our blinding approaches are just defense-in-depth to some extent; even without any of them, the code should be (a) correct for all inputs and (b) constant-time in all secret inputs. 09:37 < robot-dreams> Makes sense! 09:44 < robot-dreams> I wish AOMDL had a shorter acronym so difficulty correlates with acronym length, DL -> AOMDL -> OMDL is weird 10:09 < real_or_random> sipa: ok, yeah I remember that I also once thought there's a dead store in this function... 10:15 < real_or_random> maybe a comment will help 10:16 < sipa> I'm redoing the SDMC code in a way that's compatible with non-uniform addition. It cannot use a ctx->initial anymore, so it rewrites all this code too. 10:17 < real_or_random> I haven't fully read the discussion 10:17 < real_or_random> is this because of the non-uniform addition? 10:18 < sipa> I think my approach is also simpler. 10:18 < sipa> Though that's perhaps a matter of opinion. 13:15 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Ping timeout: 276 seconds] 13:16 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #secp256k1 15:32 < sipa> ... in #1057, things work in GCC, but not in clang !/ 15:50 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 256 seconds] 15:52 -!- luke-jr [~luke-jr@user/luke-jr] has joined #secp256k1 17:32 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net] 17:33 -!- luke-jr [~luke-jr@user/luke-jr] has joined #secp256k1 18:26 < sipa> Fixed. 18:30 < robot-dreams> Another huge change to review incoming soon? :) you all are way too prolific 18:52 < sipa> This one has been lingering since 2018. 19:01 < sipa> First #546, then #693... now maybe #1057. --- Log closed Tue Dec 28 00:00:13 2021