--- Day changed Mon Feb 29 2016 00:04 < midnightmagic> i have two odroid now lots of accessories, neat little things 00:05 < gmaxwell> midnightmagic: bitcoin core syncup is able to crash my odroid via overheating, running with par=1 or with a powerful fan on it seems to fix it. 00:20 < midnightmagic> gmaxwell: xu4? 00:21 < midnightmagic> running builds + kodi + NFS-sourced high-def decode triggers the onboard fan but so far I haven't been able to freeze it. 00:22 < midnightmagic> only two issues I have so far: 1) the overscan problem/incompatibility with TV 1080p displays and the difficulty in configuring it on the odroid (argh why a reboot), and then of course the weird trusted boot thing. 02:42 -!- jtimon [~quassel@35.31.134.37.dynamic.jazztel.es] has joined #secp256k1 04:12 -!- andytoshi [~andytoshi@wpsoftware.net] has quit [Ping timeout: 246 seconds] 05:22 -!- andytoshi [~andytoshi@wpsoftware.net] has joined #secp256k1 08:21 -!- jtimon [~quassel@35.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 248 seconds] 10:14 < gmaxwell> midnightmagic: oh I hadn't noticed, but there is now an Odroid C2 that is 4x2ghz a53 and 2gb ram, for $40. 10:16 < gmaxwell> and gigabit ethernet. 11:03 -!- jtimon [~quassel@35.31.134.37.dynamic.jazztel.es] has joined #secp256k1 11:20 -!- jtimon [~quassel@35.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 248 seconds] 12:08 < TD-Linux> gmaxwell, in fact I think ARM explicitly advertises the a53 as in-order. 12:09 < gmaxwell> TD-Linux: I assume it's like a8: dual issue, but only when there is clearly no dependency. 12:10 < TD-Linux> gmaxwell, yes. 12:11 < gmaxwell> wumpus' asm for arm is quite good on a8. 12:12 < sipa> for 64-bit we can do much better i expect 12:13 < sipa> as wumpus' code uses the 10x26 layout 12:17 < gmaxwell> perhaps I should contact Michael Hamburg, at the high assurance crypto workshop he claimed to have some sage code that does machine optimization of field arithemetic. 14:24 -!- maaku [~quassel@botbot.xen.prgmr.com] has joined #secp256k1 14:24 -!- maaku is now known as Guest98911 14:59 -!- jtimon [~quassel@35.31.134.37.dynamic.jazztel.es] has joined #secp256k1 16:30 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #secp256k1 16:30 < BlueMatt> docs currently do not appear to indicate when context_randomize is useful and when it is not 16:31 < BlueMatt> eg is it true that for anything other than SECP256K1_CONTEXT_SIGN, context_randomize is useless? 16:31 < sipa> correct 16:32 < sipa> but that may change (in particular, batch validation may depend on it) 16:33 < BlueMatt> this should be in secp256k1.h :p 16:34 < andytoshi> in general _randomize should be more visible i think, but i'm not sure where it belongs. i'm constantly forgetting that it exists 16:34 < sipa> PR welcome! 16:35 < BlueMatt> andytoshi: ja 16:35 < BlueMatt> and its dangerous to not call it 16:35 < BlueMatt> so..... 16:35 < andytoshi> yeah, exactly 16:35 < BlueMatt> calls should fail if you have not called _randomize, imo 16:35 < andytoshi> can you add a note on _sign to say that if you've got the cycles, it's good to _randomize every so often before signing? 16:35 < andytoshi> hmmm 16:36 < andytoshi> so, in the absense of other timing problems (and we're aware of none), there is not a clear risk to not calling randomize 16:36 < sipa> right; it's belt and suspends 16:37 < sipa> suspenders! 16:37 < andytoshi> and the initial benefit is much greater than the additional benefit from calling multiple times 16:37 < andytoshi> and it has some resource requirements iirc that nothing else does (e.g. to a RNG, and to a mutable context pointer) 16:38 < andytoshi> so i'm not certain what the best "recommended behaviour" is, and i'm pretty sure there's no one-size-fits-all solution 16:38 < BlueMatt> sipa: for what calls in _rangeproof should i _randomize? 16:39 < sipa> none, i believe 16:39 < BlueMatt> kk 16:40 < sipa> oh, wait 16:40 < sipa> yeah 16:42 < BlueMatt> hmm? 16:43 < BlueMatt> yea, calls really need to fail if you haven't _randomize'd 16:43 < sipa> why? 16:43 < sipa> there is no known vulnerability if you don't 16:43 < andytoshi> if there were an argument for this, it'd be for just calling _randomize in context_create (at least when the sign flag is given) 16:46 < BlueMatt> sipa: oh? so its not bad to not call _randomize before things like _sign? 16:48 < andytoshi> BlueMatt: correct. if it has any effect on security, that's a (til now unknown) bug. it's just precautionary 16:49 < BlueMatt> hmm, ok 16:49 < BlueMatt> sipa: wait, so the "yeah" was "yes, there are no range proof calls i should _randomize"? 16:51 < sipa> range proof code does not seem to interact with randomize at all 16:52 < BlueMatt> kk 17:01 < gmaxwell> 16:46 < BlueMatt> sipa: oh? so its not bad to not call _randomize before things like _sign? 17:01 < gmaxwell> randomize is belt and suspenders. 17:02 < gmaxwell> We don't know if it helps at all. It _may_ make any RF sidechannels that might exist harder to exploit. 17:02 < gmaxwell> It's unlikely to make them easier to exploit. 17:02 < gmaxwell> Such sidechannels may not exist at all. 17:02 < BlueMatt> gmaxwell: thanks 17:03 < gmaxwell> we also don't know how often it should be called, ideally you'd call it between every signature; but even core doesn't do this because it needs exclusive access to the signer state. 17:03 < gmaxwell> if we implement batch validation, there is a stronger dependency on randomization, and then perhaps that call would fail without adequate randomization. 17:04 < sipa> agree 19:10 -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has quit [Ping timeout: 260 seconds] 19:11 -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has joined #secp256k1 19:43 -!- instagibbs [~instagibb@pool-100-15-114-5.washdc.fios.verizon.net] has quit [Ping timeout: 260 seconds] 19:49 -!- instagibbs [~instagibb@pool-100-15-114-5.washdc.fios.verizon.net] has joined #secp256k1 21:30 -!- andytoshi [~andytoshi@wpsoftware.net] has quit [Changing host] 21:30 -!- andytoshi [~andytoshi@unaffiliated/andytoshi] has joined #secp256k1 21:38 -!- jtimon [~quassel@35.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 276 seconds]