--- Day changed Tue Oct 20 2015
02:56 -!- jtimon [~quassel@212.Red-88-5-10.dynamicIP.rima-tde.net] has joined #secp256k1
08:12 -!- TD-Linux [~Thomas@about/essy/indecisive/TD-Linux] has quit [Ping timeout: 265 seconds]
08:15 -!- TD-Linux [~Thomas@about/essy/indecisive/TD-Linux] has joined #secp256k1
13:11 -!- phantomcircuit [~phantomci@strateman.ninja] has joined #secp256k1
15:16 < gmaxwell> May be of some idle interest https://briansmith.org/GFp-0
15:33 -!- sipa [~pw@2a02:348:86:3011::1] has joined #secp256k1
15:39 < gmaxwell> 10:44 < gmaxwell> sipa: do you mind if I make secp256k1_ec_pubkey_create terminate early on zero or overflow?  Right now it can hit a  runtime assertion, e.g. for a secret key of 0 it chokes on trying to seralize infinity. :P
15:39 < gmaxwell> 10:54 < gmaxwell> sipa: thoughts on moving privkey_export and privkey_import to contrib?  do we really want to encourage people to use  these things?
15:39 < gmaxwell> 12:44 < gmaxwell> sipa: pubkey_tweak_mul and privkey_tweak_mul behave inconsistently with a tweak of zero.  Privkey leaves the secret  unchanged, pubkey zeroizes the pubkey object.  Which behavior do you want?
15:40 < gmaxwell> I have a big stack of testing patches on top of your seralization changes, but I need to resolve the above before I can create a PR.
17:30 -!- jtimon [~quassel@212.Red-88-5-10.dynamicIP.rima-tde.net] has quit [Ping timeout: 255 seconds]
19:17 < sipa> gmaxwell: passing 0 or overflow to ec_pubkey_create should return 0 immediately, and memset pubkey to 0
19:17 < sipa> moving privkey_export and import to contrib: ACK... that fits nicely, as these things also don't strictly enforce DER
19:21 < sipa> gmaxwell: for the tweak functions: I'd say fail hard; if the tweak was unable to be performed, wipe the output (both pubkey or privkey, both add and mul)
19:23 < sipa> seems i also missed one argument change in #293... it didn't break anything, but bitcoin core's tests caught it
19:23 < sipa> we really need a few very basic static data tests...
19:25 < gmaxwell> sipa: I'm adding those.
19:25 < gmaxwell> oh also I protest how the algo16 works.
19:25 < sipa> oh?
19:26 < gmaxwell> +        CHECK(nonce_function_rfc6979(nonce2, zeros, zeros, zeros, NULL, 0) == 1);
19:26 < gmaxwell> +        CHECK(nonce_function_rfc6979(nonce4, zeros, zeros, zeros, (void *)zeros, 0) == 1);
19:26 < gmaxwell> compute the same nonce.
19:26 < gmaxwell> I propose, instead, to _not_ do the padding. the lengths are different so there is no way for data and algo16 to emulate each other.
19:27 < gmaxwell> alternatively algo16 could be algo15 and carry a flag if extradata is there or not.
19:27 < sipa> that's pretty ugly, but you are right
19:28 < sipa> and what if there is no algo?
19:28 < gmaxwell> the length is either 64, 80 (algo), 96 (data), 112 (algo+data)
19:28 < sipa> yes, i see that
19:29 < gmaxwell> so they are all distinct.
19:29 < gmaxwell> my patch is just
19:29 < gmaxwell> -       memset(keydata + keylen, 0, 96 - keylen);
19:29 < gmaxwell> -       memcpy(keydata + 96, algo16, 16);
19:29 < gmaxwell> -       keylen = 112;
19:29 < gmaxwell> +       memcpy(keydata + keylen, algo16, 16);
19:29 < gmaxwell> +       keylen += 16;
19:29 < gmaxwell> and comments.
19:29 < gmaxwell> (and tests)
19:30 < gmaxwell> but I wanted to ask in case you prefered another approach.
19:32 < sipa> it's not a very scalable approach... and i feel it's ugly to encode presence of particular fields into the length
19:33 < sipa> but i guess there's no choice if we want both compatibility and flexibility
19:34 < sipa> ok then
19:34 < gmaxwell> sipa: well I offered you an alternative: code it into algo16. :)
19:37 < sipa> if we need anything more, we'll just pre-hash it into extradata, and add a 1-byte flag to the overall thing to indicate the extradata is indirect
19:37 < sipa> nah
19:37 < sipa> infinite scalability
19:38 < sipa> we should have used a merkle patricia tree of data from the beginning
19:38 < sipa> for something that will likely never ever get any extras
19:38 < sipa> oh!
19:38 < sipa> i know an extra
19:38 < sipa> the sign-to-contract data
19:41 < sipa> which i'd like to make some preliminary changes for, btw
19:41 < sipa> but i'll wait until 334 is in
20:21 < gmaxwell> sipa: another related thing, so joinmarket is apparently using stolen-nonce-stealth-addresses (apparently I run my mouth too much) for donations.  The idea is that having an ephemeral key in an opreturn both wastes space and makes transactions more unusual (thus identifyable)... so one of the signature nonce values is used for the pubkey for ECDH.
20:23 < gmaxwell> they were using 6979 for generating their nonces, but need to generate the nonce before the transactions, so they can compute the address they're paying to. .. they very narrowly doged creating a vulnerability this way.
20:24 < gmaxwell> I dunno if there is anything we could to do make it less likely that someone else who needed the nonce before the transaction wouldn't manage to footgun themselves with 6979.
20:25 < gmaxwell> other than perhaps explicitly recommending the use of strongly random additional randomness if you're doing anything 'creative'.
20:25 < gmaxwell> seemed they were under the impression the 6979 was automatically safe because it had the private key in it.
20:55 < sipa> i hope they're not signing more than one message...
21:06 < gmaxwell> right. They were, but never transmitting one of them (thus narrowly)
22:00 < gmaxwell>   branches...: 93.2% (805 of 864 branches)
22:00 < gmaxwell> (cheating a little-- contrib is not counted. :) )
23:42 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 250 seconds]
23:47 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #secp256k1