--- Log opened Wed Dec 11 00:00:33 2019
00:04 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 246 seconds]
00:32 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
03:13 -!- reallll [~belcher@unaffiliated/belcher] has joined #secp256k1
03:17 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 265 seconds]
04:09 < elichai2> just making sure `secp256k1_ecmult` isn't constant time. right? (and because of that so is `secp256k1_ec_pubkey_tweak_mul`)
04:09 < elichai2> on one hand it doesn't end with `*_var` on the other the code looks variable time and there's a `secp256k1_ecmult_const`
04:10 < gmaxwell> read the code? :P
04:11 < elichai2> just making sure :) it's not easy to remember what is what with all the ifdefs there lol
04:11 < gmaxwell> You should be able to tell by what it calls. :)
04:11 < gmaxwell> thats the xG+yP function. It probably should get a _var name, I assume it doesn't just for legacy reasons.
04:13 < elichai2> well it calls `secp256k1_ecmult_strauss_wnaf` which then calls `secp256k1_scalar_split_lambda` which *is* constant time.  but also calls `secp256k1_ecmult_wnaf` which really doesn't look constant time :)
04:13 < gmaxwell> Right, any non-constant time on a secret input means the function is non-constant time. :)  Kinda complicated if there is a function with both 'public' and 'secret' inputs.
04:14 < elichai2> yeah it's not always obvious that if/for means variable time on the secret
04:15 < elichai2> but good to know I was right. I want to add to the docs that it's not constant time so people won't use this for ECDH
04:15 < elichai2> on the other hand I think everything except `pubkey_create` and `sign` is assumed to be variable time
04:16 < elichai2> (well also except stuff in the modules which there it depends lol )
04:17 < gmaxwell> elichai2: it should be renamed _var.
04:17 < gmaxwell> I think.
04:17 < elichai2> right. although i'm more concerned about the public API part. do you think that also should be renamed?
04:18 < gmaxwell> there isn't any public api that exposes low level functions like that.
04:19 < gmaxwell> The public api is all cryptographic systems, it knows what inputs are secret.
04:19 < gmaxwell> secret inputs are handled in constant time.
04:19 < elichai2> what about `secp256k1_ec_pubkey_tweak_mul`
04:19 < gmaxwell> It doesn't need _var annotations and wouldn't benefit from them because that would be asking the end user to make these decisions, which ... well if we can't make them, then they certantly can't! :)
04:19 < elichai2> people can (and do) use this to do ECDH
04:20 < gmaxwell> that function should probably go away. I don't believe there is any real use of it anymore.
04:23 < elichai2> what was the use for it?
04:25 < gmaxwell> Well, one potential use was that armory had a BIP32 like thing that used multiplication rather than addition.
04:38 < sipa> elichai2: public API functions don't have _var prefixes
04:38 < sipa> *suffixes
05:16 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined #secp256k1
06:28 < elichai2> argh so because of this xonly we also need a xonly_add method for the privkey? :/ I really hoped I can at least leave the same privatekey abstraction between ECDSA and Schnorr
06:45 -!- reallll is now known as belcher
07:40 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 276 seconds]
08:31 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack]
08:44 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #secp256k1
09:25 < andytoshi> i don't think we should do that, in the interest of preventing users mixing cryptosystems
09:26 < andytoshi> though i'm pretty confident that you cannot unsafely share key material between schnorr and ecdsa
09:27 < gmaxwell> that sounds like a challenge.
09:27 < andytoshi> heh, well, it's made quite difficult by schnorr hashing different data so you can't collide the message hashes
09:28 < gmaxwell> considering that the ECDSA hasher is entirely external, I think a sufficiently advanced idiot could do something!
09:28 < andytoshi> haha, i'll work on it some today
09:30 < gmaxwell> so, for example, if you mange to use the same nonce function for both you're hosed.
09:30 < gmaxwell> particularly _because_ the signed messages are different!
09:30 < gmaxwell> (to clarify, the same derandomized nonce function)
09:31 < andytoshi> s = k + xe  vs   sk = e' + r'x
09:31 < andytoshi> hmm yep, i can solve that
09:31 < andytoshi> yeah, wow, idk why i thought this was hard. you can totally use same key/same nonce across these schemes
09:32 < andytoshi> and if you do deterimistic nonces by hashing pubkey/message you may actually do this without needing to be too dumb
09:32 < gmaxwell> First rule of algebraic cryptography is that everything introduced a vulnerablity.
09:33 < gmaxwell> introduces*
10:51 < sipa> xif the nonce generation algorithms are distinct i suspect sbaring keys across schnorr/ecdsa is fine
10:52 < sipa> but probably hard to prove
11:14 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Remote host closed the connection]
14:01 < midnight> elichai2: These things you're encountering in terms of usage of the library -- please consider PR'ing some comments and/or additional documentation based on things you've encountered that require additional explanation
14:01 < midnight> :-)
14:04 < elichai2> Andytoshi I'm pretty sure it's quite known that mixing ecdsa and schnorr while using the same nonce function will leak the private key
14:04 < elichai2> midnight: well I am PRing things.
14:05 < midnight> elichai2: Thank you, from future posterity.
14:59 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
15:21 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
15:21 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
15:25 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 250 seconds]
--- Log closed Thu Dec 12 00:00:34 2019