--- Log opened Fri Jan 10 00:00:02 2020 03:19 -!- belcher [~belcher@unaffiliated/belcher] has joined #secp256k1 03:38 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 260 seconds] 03:42 -!- belcher [~belcher@unaffiliated/belcher] has quit [Remote host closed the connection] 03:44 -!- belcher [~belcher@unaffiliated/belcher] has joined #secp256k1 04:02 -!- meshcollider [meshcollid@209.141.50.204] has quit [Ping timeout: 268 seconds] 05:21 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has joined #secp256k1 05:57 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has quit [Ping timeout: 268 seconds] 05:58 -!- jonatack [~jon@213.152.161.239] has joined #secp256k1 07:42 -!- jonatack [~jon@213.152.161.239] has quit [Ping timeout: 265 seconds] 08:22 -!- meshcollider [meshcollid@209.141.50.204] has joined #secp256k1 09:08 -!- meshcollider [meshcollid@209.141.50.204] has quit [Ping timeout: 260 seconds] 09:34 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #secp256k1 10:23 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 10:25 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 260 seconds] 10:28 -!- lukedashjr is now known as luke-jr 10:54 < gmaxwell> sipa: So how do you feel about my approach to secret overflow of just running the function on a dummy constant, so that its constant time even with invalid inputs? If you're okay with that, I'll go ahead and implement it everywhere. 10:55 < gmaxwell> (I just don't want to waste my time implementing it in three places if you find the idea fundimentally distasteful) 11:11 < sipa> gmaxwell: well my concern is that it may be overkill - we generally do not actually need sidechannel resistance in case an error is returned 11:11 < sipa> so this approach is one we'd need to help automated reasoning 11:14 < sipa> also, depending on how you implement it (i haven't looked...) if you switch the input to a pointer to some constant input, you're arguably leaking whether or not the input was valid through memory access pattern 11:43 < gmaxwell> sipa: my implementation (see pastebin link) uses a cmov to move the constant into the output. 11:44 < gmaxwell> Yes, it does achieve a stronger constant timeness guarentee than is probably needed. Though I can come up with a somewhat contrived example of how the overflow behavior could potentially be used to steal secrets, in some fairly dumb application. 11:45 < gmaxwell> e.g. say that an application lets you tweak a secret additively and then leaks if secp256k1 rejected it or some other step rejected it, through the time that secp256k1 took. 11:46 < gmaxwell> sipa: basically the implementation I made just sets up a constant scalar. and then cmov(secret,constant,overflow). 11:47 < gmaxwell> and uses overflow in the return. 11:47 < gmaxwell> the reason I cmov instead of just using the overflowed value is that in most cases 0 must also be rejected, and sending in zero would violate the assumptions of other parts of the library. 11:48 < sipa> yup 11:49 < gmaxwell> sipa: if the tool were mistaken about this being non-constant time based on a secret input, I would be more inclined to take another approach... but in this case it's real, just very likely irrelevant. But I figure the history of cryptography is full of people thinking something kinda weak was uneploitable and being mistaken. 11:50 < gmaxwell> and obvious one extra cmov is not a reliably measurable slowdown. 11:50 < sipa> a single cmov compared to ecdh is indeed not something i'd expect to care about 11:50 < sipa> but maybe in other functions the same approach does matter 11:50 < sipa> e.g. tweak_add 11:53 < gmaxwell> I could cmov a pointer instead of the whole scalar, I suppose. 11:53 < sipa> gmaxwell: that would leak information through memory access, no? 11:53 < sipa> if an attacker can observe whether or not you're accessing the original input or the static constant 11:53 < gmaxwell> oh right duh you just said that (and as a result primed me to think about it. :P) 11:54 < gmaxwell> it would probably slow down the private tweak add by a non-trivial percentage, but ... does that matter? 11:54 < sipa> probably not, indeed 11:54 < gmaxwell> (I actually totally forget about the existance of the private key tweak functions) 11:57 < sipa> gmaxwell: what about things like ecdsa signing? 11:58 < sipa> it's extremely hard to make them unconditionally constant time, as there is a loop that tests for overflow 11:58 < sipa> but it's cryptographically unlikely to ever run 12:02 < gmaxwell> sipa: seperate issue, and I wanted to tackle it after handling the rest; the s==0 it's not a branch on an secret value. So what I would propose there is just introducing a way to mark the S non-secret before testing it. 12:06 < gmaxwell> hm. though now that you mention it, there should also be another one in rfc6979. 12:07 < gmaxwell> I don't even think I saw that in the output-- either it's missing it, or there is just so much junk output I didn't notice it. (part of why I want to fix these dumb ones, they hide other issues) 12:17 < gmaxwell> In any case, I think the s==0 (or now, nonce retry) loops may have no completely clean solution. But I'd like to get all the things with clean solutions fixed first, before worrying about the stuff that has to be worked around. 12:48 < gmaxwell> sipa: fwiw, cmoving the pointer just leave the calculated pointer secret as far as valgrind is concerned. 12:49 < gmaxwell> sipa: I checked it because if it worked, it would make for a cheap way to turn a boolean non-secret, and bypass the test for things like the 6979 nonce loop. 12:50 < gmaxwell> in any case, even given a "make variable defined" operation, I would prefer to still make the overflow handling constant time-- actually fix it, instead of hide it. 16:39 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 16:46 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Ping timeout: 260 seconds] 17:02 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-peewdyazmopwzjvg] has joined #secp256k1 17:48 -!- andytoshi [~apoelstra@96.53.77.134] has joined #secp256k1 17:48 -!- andytoshi [~apoelstra@96.53.77.134] has quit [Changing host] 17:48 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined #secp256k1 20:29 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1 20:33 -!- ddustin_ [~ddustin@unaffiliated/ddustin] has joined #secp256k1 20:36 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 260 seconds] 21:13 -!- ddustin_ [~ddustin@unaffiliated/ddustin] has quit [Read error: Connection reset by peer] 21:13 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1 21:56 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection] 21:56 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1 22:01 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 248 seconds] 22:31 -!- Apocalyptic [~Apocalypt@unaffiliated/apocalyptic] has quit [Ping timeout: 248 seconds] 22:31 -!- Apocalyptic_ [~Apocalypt@unaffiliated/apocalyptic] has joined #secp256k1 22:31 -!- Apocalyptic_ is now known as Apocalyptic --- Log closed Sat Jan 11 00:00:03 2020