--- Log opened Wed Dec 08 00:00:55 2021
06:09 -!- hg [~halosghos@user/halosghost] has joined #secp256k1
06:19 -!- elsirion [~quassel@gateway/tor-sasl/elsirion] has quit [Quit: No Ping reply in 180 seconds.]
06:20 -!- elsirion [~quassel@gateway/tor-sasl/elsirion] has joined #secp256k1
08:20 -!- scgbckbone [~scgbckbon@2001:420:c0c0:1001::2b3] has joined #secp256k1
08:24 < scgbckbone> hi everyone, question about context randomization - from documentation "You should call this after secp256k1_context_create...and you may call this repeatedly afterwards." In the second part it says MAY so assume it safe to call randomize just after context creation and do not care afterwards or am I missing something ?
08:26 < sipa> more randomness is better, but no randomness is fine
08:27 < sipa> there isn't a "things will break spectacularly" regardless of what you do - randomization is just defense in depth
08:30 < scgbckbone> is there any kind of metric (like maybe time from context creation or number of sign operations (just guessing)) that would tell me - oh this context needs to go through randomization ?
08:34 < sipa> the only thing randomization *ought* to matter for is for side channel resistance
08:34 < sipa> so let me first ask whether you care about that at all
08:35 < sipa> (e.g. timing attack, difference power analysis, ...)
08:42 < scgbckbone> probably not - the context - I have created ctypes FFI to secp and thinking whether I can leave context handling behind curtains or not - explained in this issue https://github.com/scgbckbone/python-secp256k1/issues/1
08:48 < scgbckbone> in secp all functions take context as argument - in this python FFI I do not provide this option - I only create it at the init phase
08:49 < sipa> have you seen https://github.com/rustyrussell/secp256k1-py ?
08:50 < sipa> i believe it doesn't randomize at all
08:53 < scgbckbone> seen it - wanted something less heavy, CFFI is heavy --> this is alternative approach using ctypes and has no dependencies - just libsecp256k1 and python3.6+
08:55 < scgbckbone> searching over his lib - I can confirm that he does not randomize at all
08:57 < scgbckbone> based on this discussion - I think it is sufficient (even more than sufficient) to randomize only after context creatin - thanks sipa
08:58 < sipa> what is sufficient depends on the use case
08:58 < sipa> but, given that you're doing cryptography in python, i hope it isn't being used for anything serious in the first place...
09:03 < scgbckbone> nope - just needed schnorrsig for my learning lib and didn't wan to do it with CFFI - so I ended up doing this thing myself
09:03 < scgbckbone> with regards to python - you mean the issue with secrets on heap ? or something else
09:04 < scgbckbone> (no controll of memory)
09:10 < sipa> just very little guarantees about what happens with your memory, timing, ...
09:17 < scgbckbone> got ya - this project started as something that I needed and as I put some time into it I decided to write README and add docs/examples - maybe someone will find some use to it either (lerning, prototyping, ...)--> will add big WARNING to the top of readme so it is clear that it is not suitable to handle secrets
09:20 -!- elsirion [~quassel@gateway/tor-sasl/elsirion] has quit [Ping timeout: 276 seconds]
09:22 -!- elsirion [~quassel@gateway/tor-sasl/elsirion] has joined #secp256k1
09:25 < roconnor> https://github.com/bitcoin-core/secp256k1/blob/5d0dbef0183e0648bc2673d8c3709e323c0c8b0d/src/group.h#L12
09:26 < sipa> roconnor: yes?
09:27 < roconnor> I'm thinking I should reword this as something like A group element on the secp2561 curve, or occasionally some isomorphic curve of the form y^2 = x^3 + 7*t^6, in affine coordinates.
09:32 < real_or_random> sounds like a good idea
09:35 < roconnor> I guess the low-order tests aren't even on an isomorphic curve.
09:38 < roconnor> I think I'll ignore the low-order tests for now, wrt the comments.
09:39 < roconnor> basically ge is a point in a subgroup of some fixed order on some elliptic curve, or an isormorphic curve.
09:40 < roconnor> but ... that seems too pendantic for commenting on _ge?
10:04 < real_or_random> who do you expect to complain about being pedantic?
10:04 < real_or_random> (in a crypto library)
10:04 < roconnor> people trying to learn how secp256k1 works.
10:04 < real_or_random> my thinking is that the docs in the core modules are very sparse. every bit helps.
10:05 < roconnor> "here is a point on some subgroup of some elliptic curve"  WTF? Subgroups?
10:05 < real_or_random> ok yeah, I think one can phrase it in a readable way. 
10:05 < hg> I'd agree on an increase of documentation always being positive ☺
10:05 < roconnor> all for something only relevent for tests.
10:05 < hg> (speaking as a person who's working to try to understand how the library works ☺)
10:12 < real_or_random> for example, you could not mention it in the first sentence but add a note that _ge is also used in the exhaustive tests where then it can be some subgroup 
10:12 < roconnor> ok
10:12 < real_or_random> and sometimes it represents points on isomorphic curves
10:28 -!- robot-dreams [sid463268@uxbridge.irccloud.com] has quit [Read error: Connection reset by peer]
10:29 -!- robot-dreams [sid463268@id-463268.uxbridge.irccloud.com] has joined #secp256k1
10:43 < real_or_random> make
10:43 < real_or_random> -.-
11:46 < roconnor> ... so ... does anyone here compile secp256k1 with msvc?
11:47 < sipa> bitcoin core's appveyor CI does
11:48 < roconnor> so I just PR my change on bitcoin core?
11:48 < roconnor> They don't have to merge it.
11:49 < sipa> i guess maybe we should add an appveyor CI to secp256k1 itself
12:07 -!- johnzweng [~johnzweng@zweng.at] has joined #secp256k1
12:09 -!- cfields_ [~cfields@user/cfields] has joined #secp256k1
12:14 -!- johnzwen- [~johnzweng@zweng.at] has quit [Quit: Leaving...]
12:14 -!- cfields [~cfields@user/cfields] has quit [Remote host closed the connection]
13:10 -!- scgbckbone [~scgbckbon@2001:420:c0c0:1001::2b3] has quit [Quit: Client closed]
14:17 -!- hg [~halosghos@user/halosghost] has quit [Quit: WeeChat 3.3]
15:44 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Read error: Connection reset by peer]
15:46 -!- luke-jr [~luke-jr@user/luke-jr] has joined #secp256k1
--- Log closed Thu Dec 09 00:00:56 2021