--- Log opened Tue Nov 06 00:00:13 2018
04:42 -!- instagibbs [~instagibb@pool-100-15-135-248.washdc.fios.verizon.net] has quit [Ping timeout: 245 seconds]
07:30 < andytoshi> sipa: wanna rebase -zkp on upstream this week? i need #354 (custom ecdh) for trezor because they're using bare points as ECDH secrets when communicating with their devices
07:56 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Ping timeout: 256 seconds]
07:57 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 256 seconds]
08:00 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #secp256k1
08:04 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #secp256k1
09:09 -!- echonaut15 [~echonaut@46.101.192.134] has quit [Remote host closed the connection]
09:09 -!- echonaut [~echonaut@46.101.192.134] has joined #secp256k1
10:58 -!- echonaut16 [~echonaut@46.101.192.134] has joined #secp256k1
10:58 -!- echonaut [~echonaut@46.101.192.134] has quit [Read error: Connection reset by peer]
14:38 -!- instagibbs [~instagibb@pool-100-15-135-248.washdc.fios.verizon.net] has joined #secp256k1
17:35 -!- ddustin [2668e0ae@unaffiliated/ddustin] has joined #secp256k1
17:36 < ddustin> I'm Trying to understand what secp256k1_ec_privkey_tweak_add does precisely.
17:36 < sipa> it adds a number to a private key
17:36 < ddustin> It adds two 32 byte numbers together, which could easily (or in fact often) result in a 33 byte number
17:36 < sipa> or put otherwise, it adds two private keys together
17:36 < ddustin> How is the resulting number trimmed back down?
17:36 < sipa> modulo the size of the curve, obviously
17:37 < ddustin> Ah so it's just a modulo
17:37 < ddustin> that makes sense
17:37 < sipa> private keys are integers modulo the size of the curve
17:37 < sipa> so all operations on them are modulo the curve size
17:37 < ddustin> Does that automatically happen inside secp256k1_scalar_add?
17:37 < sipa> yes
17:37 < sipa> secp256k1_scalar is a type for integers modulo the size of the curve :)
17:38 < ddustin> Okay thanks a bunch, this is making things much clearer
17:38 < ddustin> Is it the same for the *mul* variant?
17:39 < sipa> yes
17:39 < sipa> anything else makes no sense, as it wouldn't correspond to equivalent operations on the public keys
17:39 < ddustin> Is the size of the curver in this context 256 / 8?
17:39 < ddustin> curve*
17:39 < sipa> what?
17:40 < ddustin> Yeah that question doesn't make sense, I'm trying to articulate it in my head hold on
17:40 < sipa> the size of the curve is 115792089237316195423570985008687907852837564279074904382605163141518161494337
17:41 < sipa> or 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141 in hex
17:42 < ddustin> Okay so it's big that makes sense
17:42 < ddustin> Is the modulo'ing done in secp256k1_scalar_reduce?
17:43 < sipa> yup
17:43 < ddustin> Ah and I see the size of the curve is held in SECP256K1_N_[0-3]
17:44 < sipa> right
18:52 -!- instagibbs [~instagibb@pool-100-15-135-248.washdc.fios.verizon.net] has quit [Ping timeout: 272 seconds]
18:59 -!- ddustin [2668e0ae@unaffiliated/ddustin] has quit [Ping timeout: 260 seconds]
19:38 -!- instagibbs [~instagibb@pool-100-15-135-248.washdc.fios.verizon.net] has joined #secp256k1
--- Log closed Wed Nov 07 00:00:14 2018