--- Day changed Thu Oct 01 2015 01:45 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #secp256k1 05:11 -!- CodeShark_ [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 265 seconds] 07:56 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.] 07:57 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #secp256k1 10:34 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.] 10:42 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #secp256k1 10:53 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Read error: Connection reset by peer] 10:54 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #secp256k1 11:27 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.] 11:27 -!- jtimon [~quassel@95.131.169.244] has joined #secp256k1 11:45 -!- nullbyte [NSA@gateway/vpn/mullvad/x-jnxkuswngnaeyipc] has joined #secp256k1 11:56 -!- CodeShark_ [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #secp256k1 11:56 -!- jtimon [~quassel@95.131.169.244] has quit [Ping timeout: 240 seconds] 12:02 -!- jtimon [~quassel@95.131.169.244] has joined #secp256k1 12:03 -!- CodeShark_ [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [] 12:03 -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #secp256k1 12:53 -!- nullbyte [NSA@gateway/vpn/mullvad/x-jnxkuswngnaeyipc] has quit [Ping timeout: 240 seconds] 13:53 -!- jtimon [~quassel@95.131.169.244] has quit [Ping timeout: 246 seconds] 14:05 -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [] 14:13 <@gmaxwell> "Aurore Guillevic talked about solving the DLP in finite fields F_{p^n} coming from pairing applications, in particular fields coming from polynomial families like MNT and BN curves. The focus is on the “individual discrete logarithm” step. This work will appear at Asiacrypt." oh.. there is a vector I hadn't through of for attack against pairing cryptography. 14:14 <@gmaxwell> What if the integer discrete log in the transfer group is easier than expected because of extra structure imposed by selecting a pairing friendly curve in the first place. 14:16 < andytoshi> there are a lot of pairing-based schemes whose security is CDH, which if you believe "pairing is not free", hints at this avenue 14:18 <@gmaxwell> Panel at the bottom here is interesting: https://ellipticnews.wordpress.com/2015/10/01/ecc-2015-bordeaux-france-september-28-30-2015/ (from curves list) 14:18 <@gmaxwell> I'm wondering what they were talking about with valgrind? I wonder if it was anything similar to the constant time testing stuff I did before for libsecp256k1. 15:12 -!- jtimon [~quassel@95.131.169.244] has joined #secp256k1 15:51 -!- roasbeef [~root@104.131.26.124] has quit [Ping timeout: 240 seconds] 15:52 -!- roasbeef [~root@104.131.26.124] has joined #secp256k1 16:13 -!- jtimon [~quassel@95.131.169.244] has quit [Ping timeout: 240 seconds] 18:01 <@gmaxwell> andytoshi: I'm just use to thinking of finite field discrete log, excluding speical weak cases, as being a monolithic thing. This is dumb of me, the #1 lesson of number theory is that everything is stuffed full of structure. 18:13 < andytoshi> yes, i avoided it forever as a student because the unexpected structure everywhere was so overwhelming 18:14 < andytoshi> basically until i started working on libsecp :p 19:30 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has quit [Remote host closed the connection] 19:44 -!- maaku [~quassel@botbot.xen.prgmr.com] has joined #secp256k1 19:45 -!- maaku is now known as Guest18532 19:45 -!- Guest18532 is now known as maaku 19:54 -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #secp256k1 20:50 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #secp256k1 20:52 < rusty> Would it be horrible to save a byte of pubkey encoding in LN by insisting that secp256k1_fe_is_odd(&elem->y) be true (or false) for all keys? 20:52 < rusty> Because then everything aligns nicely. 20:55 <@gmaxwell> rusty: it means that things like BIP32, varrious hardware wallets, etc. won't work. The schnorr implementation in libsecp256k1 does this for the embedded ephemeral pubkey in the signature... but even there with hesitance and only because we've tried really hard to find something that breaks and found nothing so far. 20:55 <@gmaxwell> but we don't do it for the pubkey. 20:56 < rusty> gmaxwell: this is for onion routing in LN, where we use ephemeral client pubkeys. You literally generate them once and throw them away after encoding the shared secret. 20:57 < rusty> gmaxwell: I mean, receiver could brute force it too, but that seems even less elegant. 20:58 <@gmaxwell> oh. that application. No, thats not crazy. 20:58 < rusty> gmaxwell: is there some cleverer way to generate then "test and retry"? 20:59 <@gmaxwell> rusty: absolutely, if its the wrong sign you just negate it (like you s flip for lowS). 21:07 < rusty> gmaxwell: hmm, is this where I swear at libsecp for making secp256k1_pubkey an opaque type? :) 21:08 <@gmaxwell> nah, that doesn't help or hurt you. 21:08 * rusty goes back and look at the math... 21:09 <@gmaxwell> Ask for a compressed key. Always set it to if its 3 when you want all yours to be 2, you just treat it as 2 and flip your private key. 21:10 < rusty> gmaxwell: right. In this case, "flip" literally means negate as if privkey were a 32-byte signed BE number? 21:12 <@gmaxwell> (or just constrain your private key range to begin with.) No.. means the same thing as it means for s... subtract it from the group order. 21:13 <@gmaxwell> but yea, don't listen to that just throw out your private key and generate a new one if the value is 'high S', before even generating the pubkey. 21:15 <@gmaxwell> oh hm. I'm being stupid. Ignore my last ignore that and do the first thing I said. 21:15 <@gmaxwell> sorry, been a really long week. 21:23 < rusty> Hmm, writing code to subtract from "FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141" is not too bad I guess. 21:25 < rusty> gmaxwell: another dumb q: under what circumstances does secp256k1_ec_pubkey_create() fail? Not sure what overflow means in this context. ie. how likely? 21:32 <@gmaxwell> rusty: 2^256-order out of 2^256 times, if your input is a uniform 32byte random string. ... probablity is line 3.7*10^-39 says my calculator. It's cryptographically rare. 21:32 <@gmaxwell> Which is kind of annoying, but thats life. 21:49 < rusty> Yeah, classic case of "code will never run, but write the damn loop anyway". Thanks. 21:52 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 22:17 <@gmaxwell> andytoshi: hm I wonder if pairing is really screwed over by recommendations to increase to 192 bit or 256 bit security... you'd need something like a k=24... I guess there are more design options the bigger the elements used, but I expect bigger groups will really hurt the poor performance of the pairing operation. 22:29 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #secp256k1 22:54 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 244 seconds] 23:33 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 23:33 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 23:35 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 23:38 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 23:38 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #secp256k1 23:39 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Client Quit]