--- Log opened Fri Dec 13 00:00:35 2019
00:03 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
00:08 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 276 seconds]
01:07 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds]
01:08 -!- belcher [~belcher@unaffiliated/belcher] has joined #secp256k1
01:49 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
01:53 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 240 seconds]
02:02 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
02:06 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 250 seconds]
03:49 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
03:54 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 252 seconds]
05:57 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
05:58 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
06:33 -!- kcalvinalvnn [~kcalvinal@ec2-52-79-199-97.ap-northeast-2.compute.amazonaws.com] has quit [Quit: ZNC 1.7.4 - https://znc.in]
06:35 -!- roconnor [~roconnor@host-23-91-187-201.dyn.295.ca] has quit [Quit: Konversation terminated!]
06:38 -!- kcalvinalvin [~kcalvinal@ec2-52-79-199-97.ap-northeast-2.compute.amazonaws.com] has joined #secp256k1
08:15 -!- andytoshi [~apoelstra@wpsoftware.net] has joined #secp256k1
08:15 -!- andytoshi [~apoelstra@wpsoftware.net] has quit [Changing host]
08:15 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined #secp256k1
09:29 < BlueMatt> ${us_generated_secret_key} * H(malicious_data) + ${other_us_generated_secret_key} * H(other_malicious_data) is infallible, correct?
09:29 < BlueMatt> (up to security of H)
09:29 < BlueMatt> if you didnt have H the malicious_data could result in the multiplication/addition failing
09:30 < sipa> modulo n?
09:30 < BlueMatt> errr, yes, and will land on the curve
09:30 < BlueMatt> (with sufficiently high prob)
09:31 < sipa> can you describe the context a bit more?
09:32 < BlueMatt> i generated some private keys, now i have a counterparty who is adding in some data, and I need to generate a private key
09:32 < BlueMatt> the final private key must be valid
09:32 < BlueMatt> but i want to refactor to not actually have private key data at the time i need to check this
09:32 < sipa> just the first term is enough, i think
09:33 < BlueMatt> right, well ie multiplying by (sha256) hash of otherwise-malicious data is, with high p, never going to generate something invalid
09:34 < sipa> yes unless the hash is 0 or equal to n
09:34 < BlueMatt> right, well, or over n
09:34 < sipa> if you interpret the result mod n, that doesn't matter
09:34 < BlueMatt> ok, so I will throw away the result of secp256k1_ec_privkey_tweak_mul :)
09:35 < BlueMatt> ah...I dont think we do that
09:35 < sipa> i don't know what tweak_mul does
09:35 < BlueMatt> multiplies, last I checked
09:36 < BlueMatt> ah, nvm, the docs are sufficiently descriptive
09:37 < BlueMatt> next question, without knowing the private key, can I determine if another private key is "the complement of the [original] private key"
09:37 < sipa> do you have the corresponding public keys?
09:38 < BlueMatt> yea
09:38 < BlueMatt> sorry, duh
09:38 < sipa> complementary public keys differ in their sign (so their x coord will be the same  y coord will differ)
09:38 < BlueMatt> ah, ok, thanks
09:40 < sipa> yw
09:41 < real_or_random> https://github.com/bitcoin-core/secp256k1/blob/master/include/secp256k1.h#L589
09:41 < real_or_random> we have a method for this :)
09:41 < real_or_random> (well, almost)
09:42 < real_or_random> it would actually be safer if the tweak methods always used SHA256 internally
09:43 < real_or_random> this would make them less powerful but much safer to use
09:44 < real_or_random> are there reasonable use cases where the tweak is not a hash?
09:45 < sipa> real_or_random: i think they're always hashes or things derived from hashes
09:45 < sipa> in bip32 they're one half of a sha512
09:54 < BlueMatt> ohhh, wait, is the above construction not actually broken? assuming the counterparty has the public parts to both of our generated secret keys, can they not do a collision attack in order to use their two malicious data bits to make the two halves of the final addition complements?
09:55 < sipa> collision attacks don't work in groups in which the DL is hard
09:56 < sipa> hmm, wait
09:56 < sipa> that's not relevant here
09:57 < sipa> yeah with 2^128 work you can construct inputs that make the sum fail
09:57 < sipa> but that should be acceptable, as 128 bits is the security target anyway
09:58 < sipa> BlueMatt: are you reusing these keys in the scheme multiple times?
09:59 < BlueMatt> one, yes, the other......maybe?
10:00 < sipa> are the secret keys bip32 derived?
10:00 < BlueMatt> no
10:00 < sipa> ok, actually randomly generated? the second one?
10:00 < BlueMatt> (this scheme is in use today in ln)
10:00 < sipa> ah
10:03 < BlueMatt> the first key is random, maybe, but could be bip32 derived (implementation defined). the second key is the output of a sha256 in a particular way
10:11 < BlueMatt> alright, so...the counterparty would have to do ~2**128 to make any of the tweaks out of range, which is fine, and assuming the tweaks are in range, the counterparty would have to do 2**128 to make the two parts complements, which is also fine?
10:12 < BlueMatt> oh wait lol i got this all wrong, one of the private keys is controlled by your counterparty, too, but the hash input is partially-malicious, partially-locally-generated.
10:13 < BlueMatt> right, thats much more obviously correct
10:14 < BlueMatt> sorry for the noise
11:14 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 250 seconds]
12:05 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #secp256k1
13:20 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
13:21 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
15:10 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 240 seconds]
15:46 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
15:53 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 276 seconds]
16:07 -!- wallet42 [sid154231@gateway/web/irccloud.com/x-qthzfmsivioovani] has quit [Ping timeout: 276 seconds]
16:07 -!- wallet42 [sid154231@gateway/web/irccloud.com/x-jtxugexkwtmwjqjm] has joined #secp256k1
17:36 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
19:37 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 276 seconds]
19:56 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
20:01 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
20:17 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
20:34 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
20:36 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
20:37 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1
20:41 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 250 seconds]
--- Log closed Sat Dec 14 00:00:36 2019