--- Log opened Fri Jan 24 00:00:19 2020
01:39 -!- jonatack [~jon@213.152.161.138] has quit [Ping timeout: 265 seconds]
02:51 -!- jonatack [~jon@109.202.107.15] has joined #secp256k1
05:25 -!- jonatack [~jon@109.202.107.15] has quit [Quit: jonatack]
08:15 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
08:19 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 240 seconds]
09:05 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Ping timeout: 240 seconds]
09:06 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #secp256k1
09:07 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #secp256k1
12:01 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
12:01 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Read error: Connection reset by peer]
12:02 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
12:03 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Read error: Connection reset by peer]
12:03 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
12:04 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Read error: Connection reset by peer]
12:05 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
12:06 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Read error: Connection reset by peer]
12:06 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
12:07 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Read error: Connection reset by peer]
12:08 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
12:08 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Read error: Connection reset by peer]
12:09 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
12:10 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Read error: Connection reset by peer]
12:10 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
12:11 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Read error: Connection reset by peer]
12:11 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
12:12 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Read error: Connection reset by peer]
12:13 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
12:13 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Read error: Connection reset by peer]
12:14 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
12:15 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Read error: Connection reset by peer]
12:15 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
12:16 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Read error: Connection reset by peer]
12:17 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
12:20 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Client Quit]
15:17 < andytoshi> in #701 (make arithmetic more consistent) we already had an argument about rejecting the 0 seckey in secp256k1_ec_privkey_tweak_add right?
15:17 < andytoshi> i don't want to rehash it if we already had a discussion and landed on the result in the PR
15:17 < andytoshi> but i'm a little annoyed by it
15:20 < andytoshi> i think we did have a discussion and somebody showed an example of naive code using this to turn an obviously-wrong all-zeroes key into a nonobviously-wrong result
15:21 < sipa> andytoshi: are you arguing in favor or against of rejecting privkey 0?
15:21 < andytoshi> against rejecting
15:22 < andytoshi> so that i can write "key = 0; for (tweaks in list) { seckey_add(key, tweak); }" type code
15:23 < sipa> and that would fail with the change, right?
15:24 < andytoshi> yep
15:24 < andytoshi> whereas it currently suceeds
15:24 < sipa> so, what is the problem?
15:24 < sipa> ah, you mean that should be permitted
15:24 < andytoshi> yeah
15:24 < sipa> i thought you were arguing that changing it would be insecure
15:24 < andytoshi> but like, i don't have an actual usecase for this, it's just a mathematical purity thing
15:24 < andytoshi> that i don't like operations that fail when you apply them to their identity :)
15:25 < andytoshi> no, i'm arguing that changing it would be unergonomic
15:25 < sipa> well, the function is not scalar_tweak; it's seckey_tweak, and 0 is not a valid secret key
15:25 < andytoshi> right, i think that's a reasonable argument
15:25 < sipa> and i think in general we want to move towards more application-level functions rather than lowlevel primitives
15:25 < andytoshi> yeah, i can get behind that
15:26 < sipa> if we'd have done that from the start, these functions wouldn't exist, and there'd be bip32_privkey_derive and bip32_pubkey_derive instead :)
15:26 < andytoshi> yeah that's an interesting alternate history
15:27 < andytoshi> probably we should've done that
15:27 < sipa> the annoying part is that it needs a way to pass in a SHA512 implementation or include a native one
15:29 < andytoshi> yeah
15:29 < andytoshi> i kinda wish libsecp had a companion libsha2 library
15:29 < andytoshi> but like, i'm not volunteering to maintain that :)
15:29 < sipa> yeah, exactly
15:31 < sipa> it's complicated as different applications have have different requirements; sometimes speed and code size don't matter and a built-in naive copy is fine; sometimes performance matters enough that you'd want to expose a way to use a application-provided implementation; sometimes code size matters enough that having the built-in one in the first place is a deal breaker
15:35 < gmaxwell> for tweaks 0 can make sense.  But elsewhere it doesn't, particularly because we cannot serialize the point at infinity.
15:35 < gmaxwell> If I came up with this stuff the point at infinity would be serializable and just another point.
15:36 < sipa> gmaxwell: the SEC2 standard actually specifies a serialization for the point at infinity
15:36 < sipa> 0x00
15:36 < sipa> still, it's not a valid public key
15:37 < gmaxwell> why wouldn't it be?
15:38 < sipa> well according to SEC2 it isn't :)
15:39 < sipa> they specify a serialization, but then when specifying ECDSA it takes as input a point that's not 0
15:39 < sipa> iirc
15:42 < gmaxwell> right, but e.g. w/ bip-schnorr it could be.
15:42 < sipa> it's annoying to reconcile with "public keys encode an X coordinate"
15:43 < sipa> you could have a special constant (all zeroes?) that represents infinity, but i think it adds more special cases than it removes
15:43 < gmaxwell> IIRC the affine addition law works correctly for _input_ with 0,0 as the point at infinity, I think.
15:44 < sipa> really?
15:44  * sipa checks
15:47 < sipa> i don't think so
15:49 < sipa> maybe it works for y^2 = x^3 + x, but even then i think only the output X coordinate will be correct
15:51 < sipa> no, i don't think it works for any short weierstrass curve
15:51 < roconnor> My geometric intuition for ellptic curves says it shoudln't work.
15:54 < gmaxwell> hmph. I could believe that I only cared about x being right.
15:55 < gmaxwell> in any case, infinity has to be special cased regardless then, there isn't any particular reason you couldn't use x=0 instead of a flag.
15:56 < gmaxwell> for ECDH you have the crazyness about using x's value as a number which creates additional problems, but "so don't do that".
15:56 < sipa> even there it's wrong; for (y^2 = x^3 + A*x + B), adding (0,0) to a point with X coordinate x, gives as output a point with X coordinate A/x^2 + B/x
15:57 < gmaxwell> s/ECDH/ECDSA/
16:02 < gmaxwell> real_or_random: re your "you can simply abort in this case". There is a cute (though weak) argument against doing that, based on a validation technique petertodd told me about.  Apparently you can link rust code without the panic function and linking will fail if the compiler hasn't proved that none of your code can panic.  So you don't want to go pepeering your code with unreachable failures because
16:02 < gmaxwell> they'll undermine your ability to tell if there aren't reachable falure cases that the compiler has secretly hidden behind your back.  (Not an issue for C, since the only such cases in C are things like div/mod with zero, or memory issues, none of which call abort, alas)
16:54 -!- roconnor [~roconnor@host-104-157-187-25.dyn.295.ca] has quit [Quit: Konversation terminated!]
19:52 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Ping timeout: 240 seconds]
19:54 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #secp256k1
22:29 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Ping timeout: 240 seconds]
22:31 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #secp256k1
--- Log closed Sat Jan 25 00:00:20 2020