--- Log opened Mon Aug 15 00:00:50 2022
00:01 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
00:46 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
00:56 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 268 seconds]
01:37 -!- jonatack [~jonatack@user/jonatack] has joined #secp256k1
01:57 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
02:53 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
03:04 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
03:29 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 252 seconds]
04:22 -!- jonatack [~jonatack@user/jonatack] has joined #secp256k1
04:34 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
05:18 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
06:24 -!- lukedashjr [~luke-jr@user/luke-jr] has joined #secp256k1
06:24 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 268 seconds]
06:26 -!- lukedashjr is now known as luke-jr
06:53 -!- halosghost [~halosghos@user/halosghost] has joined #secp256k1
06:54 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 248 seconds]
06:57 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
07:16 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
07:59 < real_or_random> meeting in one minute :)
08:00 -!- jonatack [~jonatack@user/jonatack] has joined #secp256k1
08:00 < sipa> hi
08:00 < hebasto> hi
08:00 < michaelfolkson> hi
08:00 < real_or_random> hi
08:01 < nickler> hi
08:02 < siv2r[m]> hi
08:02 < real_or_random> topics?
08:03 < michaelfolkson> If there aren't any others moving the MuSig2 BIP forwards?
08:03 < real_or_random> hm maybe but I don't think belong to secp256k1 
08:04 < michaelfolkson> Ah ok
08:04 < real_or_random> I'd like to talk about the doc PR
08:04 < real_or_random> though github is super slow for me right now
08:04 < sipa> shoot
08:04 < real_or_random> shoot?
08:05 < sipa> "go for it"
08:05 < real_or_random> yeah, sorry, trying to open it for 3min now  lol
08:05 < real_or_random> ahem, anyway, sipa 
08:06 < real_or_random> could you have a look and tell me if you prefer the new updates PR or the alternative variant where we'd would allow all operations on the static context?
08:06 < sipa> It's not loadinmg for me either.
08:06 < nickler> same here
08:06 < real_or_random> essentially reply to https://github.com/bitcoin-core/secp256k1/pull/1126#issuecomment-1204368079
08:06 < real_or_random> (loading for me now)
08:07 < real_or_random> then I'd could make progress there, which (I think) is the only thing which stops us from releasing 
08:07 < sipa> Yes, apologies.
08:08 < real_or_random> ah plus a review for https://github.com/bitcoin-core/secp256k1/pull/993
08:08 < real_or_random> no worries, just reminding :)
08:09 < sipa> It is the case that we've never supported signing with the static context?
08:09 < real_or_random> yes, we've never supported it so far
08:10 < sipa> In that case I think I'm fine with not changing that now.
08:11 < real_or_random> ok yes. in that case, I'll go ahead and unWIP this
08:11 < sipa> I think we may want to consider it regardless, e.g. in light of andytoshi's comment there regarding rust-wasm, but the lack of randomization makes it deserve discussion.
08:11 < sipa> I
08:11 < sipa> But it doesn't need to be a blocker for that PR, or for release.
08:12 < real_or_random> (I mean, I'll make the changes and then unWIP) 
08:12 < real_or_random> yes, I think that makes sense. 
08:13 < real_or_random> another topic I wanted to bring up... I have some notes local about side-channel protection that I wanted to turn into a GH issue. the only thing that stopped me was that I wanted to write a summary of current blinding techniques and I realized I don't know how NUMS blinding works in ecmult_gen
08:14 < real_or_random> (this will be a good start for the side-channel discussion, and we may have a clearer picture then whether we want to make the change with the static context)
08:15 < sipa> I think I can explain how it works.
08:15 < sipa> You want to do that here now, or after the meeting?
08:15 < real_or_random> Yes, we could do it afterwards
08:15 < real_or_random> Then the others don't need to stick around
08:16 < real_or_random> But the gist of this issue will be that I think we should really implement synthetic nonces for ECDSA signing. Synthetic nonces randomize the ecmult_gen during signing and don't need state at all, so they're much easier than rerandomizing the context. We just can't apply synthetic nonces to key gen, so maybe is where we should focus then for other blinding techniques 
08:17 < real_or_random> Anyway, I'll write it up and we can have a proper discussion on github then
08:18 < sipa> They're also only applicable to cases where the attacker does not know the randomness. Which is a reasonable assumption to make, but some types of blinding (like the NUMS blinding) don't rely on this.
08:18 < sipa> Too bad NUMS blinding is incompatible with multicomb.
08:19 < real_or_random> True yes, it all depends on the attacker model 
08:19 < real_or_random> One orthogonal shower thought that came up during this: Would people be opposed to move ECDSA to a module? I think it would make sense for embedded users who only need Schnorr or ECDH. I guess the reason that ECDSA is "built-in" is just because this was the first functionality of the library?
08:20 < nickler> real_or_random: how does the synthetic nonces implementation for ECDSA differ from the current one with ndata? Does it XOR key and ndata like BIP-340?
08:21 < real_or_random> nickler: Oh, on a high-level it doesn't... ndata is essentially synthetic nonces, but it seems just noone uses it
08:21 < sipa> If we'd start from scratch I'd definitely make ECDSA a separate module, but at this point... would this mean moving its header definitions to a separate file too? That will break a lot of software.
08:21 < real_or_random> so when I mean switch to synthetic nonces, this could be anything from "documenting ndata better" to "switching to a BIP-340-like nonce function"
08:22 < nickler> real_or_random: ok, sounds good
08:23 < real_or_random> sipa: oh, true, the header file is an issue... maybe something to keep in mind for a 2.0 or a larger ECDSA overhaul (which could involve  "switching to a BIP-340-like nonce function", if just for performance...)
08:23 < sipa> That would make sense, I think.
08:24 < real_or_random> ok nice, thanks. will post the issue then soon
08:24 < real_or_random> more topics? PRs that need review?
08:25 < real_or_random> by the way, I know drafting an email for the copyright stuff is still on my list, I'll try to do this until the next meeting
08:25 < sipa> Ah, yes.
08:26 < hebasto> I guess it would be better time to return to CMake after release, right?
08:26 < nickler> (for a v2.0 I'd wish that ecdsa is its own library that has a dependency on a secp internals lib *ducks*)
08:26 < real_or_random> nickler: oh yes, I wish that too :)
08:28 < real_or_random> hebasto: yeah, I think our top priority right now is getting the release out. sorry that cmake is stalled currently, but I think nothing has changed about our plans to integrate this.
08:28 < michaelfolkson> Re CMake the reservations on it for the main repo don't be shared on this libsecp256k1 repo? Have I read that right? Any particular reasons? Smaller project, less complex than the main repo?
08:29 < hebasto> I mean, changes to build system should be introduced in the beginning of the release cycle, not at the its end
08:29 < real_or_random> michaelfolkson: you mean "main repo" = "bitcoin core"?
08:30 < michaelfolkson> Yeah sorry, not being precise
08:30 < sipa> I think the concerns are very different, yes.
08:31 < real_or_random> well I haven't followed the core discussion in the past weeks but for us here, it's much easier because our builds are very simple 
08:31 < sipa> My own opinion is that for Bitcoin Core we really should try to minimize having multiple parallel build systems, and ideally switch once and for all, if at all, because build system changes are a continuous burden for lots of codebase changes.
08:32 < hebasto> ^ yes, other people raise the same concerns
08:32 < sipa> For libsecp256k1 I'm much less concerned about that, especially as we keep moving towards a model where the source code itself detects things, rather than relying on extensive build system logic to do so.
08:32 < real_or_random> +1
08:32 < michaelfolkson> sipa: And Bitcoin Core and libsecp256k1 having different build systems (if that was to happen)? Any concerns there?
08:33 < real_or_random> I guess that wouldn't be optimal on a first approximation but I don't see how this would happen
08:34 < real_or_random> I mean if our plan is to support autotools *and* cmake, core could pick whatever they want
08:34 < michaelfolkson> But surely for same reasons as Core libsecp256k1 wouldn't want to support both
08:34 < sipa> Our plan is to support both.
08:35 < michaelfolkson> Ohhhh ok
08:35 < michaelfolkson> Thanks
08:35 < sipa> As I said, the concerns about having multiple parallel build systems apply much less to libsecp256k1.
08:35 < michaelfolkson> Right
08:36 < sipa> Just because there is so little actual logic in it that's subject to change as the codebase changes.
08:37 < real_or_random> yeah... I think most of our problems with autotools are strange things in autotools themselves, not strange things in our codebase
08:37 < real_or_random> (now that we got rid of writing C files on the fly and running them etc.)
08:38 < sipa> Also libsecp256k1 aims to be usable on a wider variety of platforms than Bitcoin Core is (it runs inside hardware wallets!), some of which may not be as amenable to cmake.
08:38 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
08:39 < real_or_random> more topics? PRs?
08:39 < real_or_random> just checked the state of #1000 (int128), apparently this is ready for review again
08:39 < sipa> Ah, great.
08:42 < real_or_random> so if there are no more topics (expect NUMS), we could close?
08:44 < real_or_random> ok, I guess we're done then, thanks :)
08:45 < michaelfolkson> Thanks!
08:48 < halosghost> cheers
08:48 < real_or_random> happy to hear the about the NUMS thing then
08:48 < real_or_random> sipa
08:49 < sipa> real_or_random: So in short, our ecmult_gen code works as follows (without NUMS blinding): take the scalar, chop it into 64 groups of 4 bits. Have a precomputed table tbl[k][j] with G*j*(16^k), for j=0..15, and k=0..63. Then sum tbl[0][g0] + tbl[1][g1] + tbl[2][g2] + ... + tbl[63][g63], where g_i are the groups of bits from the scalar.
08:50 < sipa> Now observe that you could add any fixed constant to all tbl[k1][] and subtract that constant from all tbl[k2][]. That's just adding something to one term in the final sum, and subtracting it from another.
08:51 < sipa> That constant can be any group element; it doesn't need to be one with a known DL.
08:52 < sipa> So what the NUMS blinding does, is pick a NUMS point (with no known DL) N.
08:53 < sipa> And then add N to all tbl[0][]. And add 2N to all tbl[1][]. And add 4N to all tbl[2][]. ... And add (2^63)N to all tbl[63][].
08:53 < sipa> No, sorry, only up to (2^62)N to all tbl[62][].
08:54 < sipa> And then to tbl[63][] you add -(2^63-1)N, which cancels out all the other ones.
08:54 < real_or_random> ook, quite simple
08:54 < real_or_random> but then what's the attacker model for which this helps?
08:55 < sipa> So the result is that no matter what input, none of the intermediary points correspond to a point with a known DL, so even an attacker that control the input exactly cannot cause doubling/cancellation to trigger, which might be observable in power patterns or whatever.
08:56 < real_or_random> ah ok, so this is specific to doubling/cancellation
08:56 < real_or_random> or more generally, to attackers controlling (parts) of the input
08:57 < sipa> Yeah, I'd say so.
08:57 < sipa> The NUMS blinding predates the actual constant-time lookup tables.
08:57 < real_or_random> ok this makes a lot of sense now. thanks
08:58 < real_or_random> (and then it won't be related to what I'm going to open an issue about)
09:04 < sipa> ok
09:11 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
10:04 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
10:24 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
11:05 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
11:06 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
11:16 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
12:09 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
12:29 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
12:33 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
13:49 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
14:44 -!- darosior [~darosior@194.36.189.246] has quit [Read error: Connection reset by peer]
14:48 -!- darosior [~darosior@194.36.189.246] has joined #secp256k1
14:54 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
15:16 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has joined #secp256k1
15:17 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Ping timeout: 268 seconds]
15:37 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
17:38 -!- halosghost [~halosghos@user/halosghost] has quit [Quit: WeeChat 3.6]
23:37 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
--- Log closed Tue Aug 16 00:00:51 2022