--- Log opened Fri Sep 26 00:00:51 2025
00:07 -!- jerryf_ [~jerryf@user/jerryf] has joined #secp256k1
00:09 -!- jerryf [~jerryf@user/jerryf] has quit [Remote host closed the connection]
00:53 < hebasto> some package manager maintainers consider regenerating of `precomputed_ecmult{_gen}.c` to "add a bit of security", which I don't believe is correct; thought?
03:43 < real_or_random> define "correct" ;)
03:45 < hebasto> in my opinion, regenerating these files has nothing to do with security of the provided `libsecp256k1` package (considering supply chain attacks)
03:46 < hebasto> am I wrong?
04:40 -!- tromp [~textual@2001:1c00:3487:1b00:1c2c:dead:822d:e7f7] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
06:11 -!- tromp [~textual@2001:1c00:3487:1b00:1c2c:dead:822d:e7f7] has joined #secp256k1
06:27 < andytoshi> hebasto: no, these are C files that are #include'd right into src/ecmult_gen_impl.h
06:28 < andytoshi> if an attacker could replace their contents, they could add macros that entirely replaced other functions e.g.
06:28 < andytoshi> i think this is reasonable behavior from the maintainers
06:31 < hebasto> if an attacker can alter a source/header file, they can modify any other one, right? I still can't see a reason why these 2 files are special in this context...
06:34 < sipa> i think the ability to regenerate these files from scratch is an auditability benefit
06:34 < sipa> just like inspecting the source code is an auditability benefit
06:35 < sipa> sure, if you fully trust the maintainers, then there is no point is regenerating, or reviewing the source code, or even recompiling the library
06:35 < sipa> but each of these options socializes the trust
06:36 < hebasto> in the condition where source files are compared between "before" and "after"
06:36 < hebasto> but they just regenerate them without any further check
06:43 < andytoshi> the argument i think is that the files are basically unreviewable because they're massive blobs of opaque data
06:43 < andytoshi> now, it's easy enough to review them to check that they each just define one C array and don't introduce any macros or other malicious stuff
06:44 < hebasto> I agree with this
06:44 < andytoshi> but could you confirm that the constants aren't somehow backdoored? (i believe it is impossible to do so but i'm not certain ... and I have the benefit of having worked directly on this library for some years)
06:47 < sipa> there are some reasonably extensive unit tests that verify the tables
06:47 < sipa> reviewing and running those is probably more helpful than regenerating them
06:47 < sipa> unless you also review the code that does the regeneration, i guess
06:48 < andytoshi> heh. personally i have read the regeneration code but have never looked at the unit tests for anything context-related :P
06:48 < hebasto> I'm confused; in packaging code, is regeneration of source files without verifying for potential code alterations useful?
06:48 < andytoshi> but i guess, if we're asking what a responsible maintainer/packager should do, you're right
06:49 < andytoshi> hebasto: yes, because you can read the generation code, which is way shorter
06:49 < andytoshi> and it's easy to check that it's at least "uniform" in that it's not tweaking individual numbers in a way that might slip a backdoor in. even if you don't understand the crypto behind what it's really oding
06:50 < andytoshi> i don't recall what this code looks like since the ecmult comb stuff, but the code we had some years ago was "obviously correct"
06:50 < andytoshi> a couple nested loops that did some doubles and adds
06:53 < hebasto> I agree, that precompute code is simple and easy reviewable
06:55 < hebasto> the drawback of this approach is that it is hard to achieve when cross-compiling
07:31 -!- tromp [~textual@2001:1c00:3487:1b00:1c2c:dead:822d:e7f7] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
07:35 -!- jonatack [~jonatack@user/jonatack] has joined #secp256k1
07:42 -!- jon_atack [~jonatack@user/jonatack] has joined #secp256k1
07:44 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 248 seconds]
07:52 -!- tromp [~textual@2001:1c00:3487:1b00:1c2c:dead:822d:e7f7] has joined #secp256k1
08:18 -!- jonatack [~jonatack@user/jonatack] has joined #secp256k1
08:20 -!- jon_atack [~jonatack@user/jonatack] has quit [Ping timeout: 250 seconds]
08:52 -!- jon_atack [~jonatack@user/jonatack] has joined #secp256k1
08:54 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 264 seconds]
10:28 -!- jonatack [~jonatack@user/jonatack] has joined #secp256k1
10:30 -!- jon_atack [~jonatack@user/jonatack] has quit [Ping timeout: 255 seconds]
11:07 -!- jerryf_ [~jerryf@user/jerryf] has quit [Ping timeout: 272 seconds]
11:08 -!- jerryf [~jerryf@user/jerryf] has joined #secp256k1
11:10 -!- tromp [~textual@2001:1c00:3487:1b00:1c2c:dead:822d:e7f7] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
11:14 -!- jerryf_ [~jerryf@user/jerryf] has joined #secp256k1
11:15 -!- tromp [~textual@2001:1c00:3487:1b00:1c2c:dead:822d:e7f7] has joined #secp256k1
11:18 -!- jerryf [~jerryf@user/jerryf] has quit [Ping timeout: 272 seconds]
11:27 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 250 seconds]
15:11 -!- tromp [~textual@2001:1c00:3487:1b00:1c2c:dead:822d:e7f7] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
15:17 -!- tromp [~textual@2001:1c00:3487:1b00:1c2c:dead:822d:e7f7] has joined #secp256k1
15:27 -!- tromp [~textual@2001:1c00:3487:1b00:1c2c:dead:822d:e7f7] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
16:28 -!- jonatack [~jonatack@user/jonatack] has joined #secp256k1
16:33 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 264 seconds]
--- Log closed Sat Sep 27 00:00:52 2025