--- Day changed Mon Feb 13 2017
01:20 -!- instagibbs [~instagibb@pool-100-15-114-3.washdc.fios.verizon.net] has quit [Ping timeout: 260 seconds]     
05:31 -!- roasbeef_ [~root@104.131.26.124] has joined #secp256k1     
05:32 -!- roasbeef [~root@104.131.26.124] has quit [Write error: Broken pipe]     
05:32 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has quit [Excess Flood]     
05:33 -!- jonasschnelli_ [~jonasschn@2a01:4f8:200:7025::2] has joined #secp256k1     
05:34 -!- jonasschnelli_ [~jonasschn@2a01:4f8:200:7025::2] has quit [Client Quit]     
05:34 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has joined #secp256k1     
05:38 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has quit [Client Quit]     
05:38 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has joined #secp256k1     
06:33 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has joined #secp256k1     
11:14 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has quit [Quit: Later.]     
11:15 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has joined #secp256k1     
14:41 -!- isle2983 [~isle2983@gateway/vpn/privateinternetaccess/isle2983] has quit [Read error: Connection reset by peer]     
14:42 -!- isle2983 [~isle2983@gateway/vpn/privateinternetaccess/isle2983] has joined #secp256k1     
16:21 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 240 seconds]     
16:22 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #secp256k1     
18:04 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has quit [Quit: Later.]     
18:06 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #secp256k1     
18:07 < rusty2> TIL about secp256k1_context_randomize.  Should I call this?  When should I call this?  How often should I call this?
18:38 < andytoshi> rusty2: my opinion is you should call it after creating the context. the purpose is defense in depth against timing attacks
18:39 < andytoshi> arguably you should call it whenever your program isn't doing anything else, but my feeling is that that would make your code look messy and ad hoc
18:42 < rusty2> andytoshi: so it permutes internal tables and does not change the results in any way, right?
18:44 < andytoshi> rusty2: correct, it does not change results in any way
18:44 < andytoshi> it's simpler than permuting tables, IIRC it adds some randomness before each multiplication and then subtracts it afterward
18:45 < andytoshi> and the randomize function changes what it adds
18:45 < rusty2> andytoshi: Right, so since libsecp is supposed to be constant time, this might defend against cacheline attacks on lookup tables or something?
18:46 < andytoshi> yep     
18:46 < rusty2> OK, I am looking to update the documentation.  PR incoming...
18:46 < andytoshi> we're not aware of any attacks it prevents because we're not aware of any attacks our other hardening can't deal with :P but defense in depth
18:47 < andytoshi> that'd be awesome, i always forget this function exists
18:51 < rusty2> I only found it because libwally-core refers to it...
19:31 < GAit> we've been calling it since it was available afaik in the various wallets and backend (after validating it was better to ofc)
19:41 < GAit> i.e. since before wally
19:43 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 258 seconds]     
19:48 < gmaxwell> s/defense in depth against timing/power&rf sidechannels/ more than timing.
19:48 < gmaxwell> rusty2: we are intended to be completely constant time even with respect to cacheline behavior.
19:49 < gmaxwell> And I've now verified this on actual compiled code with a cycle accurate processor simulator and a cycle accurate dram model...   but perhaps _your_ compiler becomes extra smart and violates this.
19:50 < gmaxwell> So the context randomize improves security against power/rf analysis always, which otherwise we don't have any defense beyond being constant time (interestingly I believe we're the only open source ECC code that has any such protection); but also adds some protection against maybe your compiler managed to violate our constant timeness.
19:51 < gmaxwell> The way we're immune to cacheline behavior with our table accesses is that we always access the entire table, and select the actual value we choose using bitmasking.
19:52 < gmaxwell> But no guarentee in C that someday a sufficiently smart compiler might not understand the bitmasking and optimize it out. :P
19:53 < gmaxwell> I'd like to get the processor simulator into our CI setup.
19:54 < rusty2> Is constant time not sufficient for power/rf analysis?
19:54  * rusty2 thinks harder... I guess not.
19:55 < rusty2> Fewer gate flips for different values, for example.
20:03 < gmaxwell> rusty2: correct. Now... constant time is much of the way there... most papers on using rf/power attacks are really using non-constant timeness.  The power differences depending on the data are probably very small on anything but very low power microcontrollers... but since we can't measure it, it's hard to be sure that we're secure.
20:53 < rusty2> Is API considered stable?  Consider a randomization pointer in create() and clone().  Nonetheless, I've written some docs for review.
21:06 < rusty2> https://github.com/bitcoin-core/secp256k1/pull/441
22:34 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 276 seconds]