--- Log opened Wed Apr 24 00:00:53 2019 01:31 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-acwcuzkbwuvmiyhx] has joined #secp256k1 02:17 -!- jtimon [~quassel@181.61.134.37.dynamic.jazztel.es] has joined #secp256k1 02:56 -!- meshcoll- [meshcollid@gateway/shell/elitebnc/x-ibvklufofrwgrkpa] has quit [Quit: ZNC 1.6.5-elitebnc:7 - http://elitebnc.org] 02:56 -!- meshcollider [meshcollid@gateway/shell/elitebnc/x-eljktkufsrujivha] has joined #secp256k1 04:53 -!- jtimon [~quassel@181.61.134.37.dynamic.jazztel.es] has quit [Quit: gone] 05:45 -!- instagibbs [~instagibb@pool-100-15-135-248.washdc.fios.verizon.net] has joined #secp256k1 07:10 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Remote host closed the connection] 07:22 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 252 seconds] 07:22 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 07:27 -!- lukedashjr is now known as luke-jr 07:29 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 07:30 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 07:51 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 07:53 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 245 seconds] 07:55 -!- lukedashjr is now known as luke-jr 08:01 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 08:02 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 08:38 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 255 seconds] 08:59 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 10:25 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-acwcuzkbwuvmiyhx] has quit [Quit: Connection closed for inactivity] 15:23 -!- echeveria [~echeveria@unaffiliated/echeveria] has joined #secp256k1 15:23 < echeveria> "On some devices, Qualcomm's TrustZone-based keystore leaks sensitive information through the branch predictor and memory caches, enabling recovery of 224 and 256-bit ECDSA keys. We demonstrate this by extracting an ECDSA P-256 private key from the hardware-backed keystore on the Nexus 5X." 15:23 < echeveria> https://www.nccgroup.trust/us/our-research/private-key-extraction-qualcomm-keystore/?research=Technical+advisories 15:24 < sipa> any bitcoin hardware devices using such a chip? 15:24 < echeveria> notably, a conditional on the last bit of the nonce leaks if it is set through speculative execution to the host, allowing for complete recovery of a key. 15:24 < echeveria> no, I don't believe it supports our curve. 15:30 < echeveria> "Supported named curves: P-224 (secp224r1), P-256 (aka secp256r1 and prime256v1), P-384 (aka secp384r1), P-521 (aka secp521r1)" 15:30 < sipa> yeah, so not secp256k1 15:31 < echeveria> still incredible they managed to recover a key through something so tenuous. 15:31 < gmaxwell> I've pointed out that the 1-bit nonce sidechannel attacks before. though the prior work only took it as far as 160 bit curves and needed unreasonable amounts of computation and storage for 224+ bit curves. 15:32 < gmaxwell> unfortunately, even though our code is constant dataflow, we still might be exposed to leaks like that. :( 15:33 < gmaxwell> our blinding, if used, may complicate it. 15:51 < echeveria> what does signing a range proof look like? 15:51 < echeveria> feels like that would almost be optimised for leakage. 15:52 < gmaxwell> the range proof code I wrote doesn't make any particular effort to hide the secret value from timing sidechannels, though it's not particularly awful in that respect. 15:53 < gmaxwell> but likely an attacker that can do timing attacks on you can also use those timing attacks to do much worse things to your privacy. 15:58 < gmaxwell> the range proof is a ring signature, for the code I did, the value is expressed in base-4. Each digit gets represented as a pedersen commitment xG + (d*p)H, where x is a random blinding secret, and d is 0-3 the value of the digit and p is the place value like 1,4,8, etc. (in base ten it would be 1 10 100 1000...)... and H is a second generator where no one knows kG=H. the pubkeys in the ring 15:58 < gmaxwell> signature are D (an ec point, D for digit), D-1pH, D-2pH, D-3pH. Say d is 2 then D-1pH = D-1H ... no one knows the private key for that point because no one knows the private key of H with respect to G. 15:59 < gmaxwell> D-2pH = xG, however, so you know the private key for that and can sign for that element of the ring. 16:00 < gmaxwell> The way the ring signing works is that it starts at a particular offset and makes its way back to the front. The looping uses variable memory accesses, so may have a pretty decent cache sidechannel. 16:01 < gmaxwell> It could be made stronger with a fairly simple modification to make the varrious loads oblivious. .... but it's really hard to justify a lot of anti-sidechannel work without a rig that can actually demonstrate the fixes doing something useful. 16:38 -!- afk11 [~afk11@79.97.107.223] has joined #secp256k1 16:39 -!- afk11 [~afk11@79.97.107.223] has quit [Changing host] 16:39 -!- afk11 [~afk11@unaffiliated/afk11] has joined #secp256k1 16:42 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Client Quit] 18:29 -!- roconnor [~roconnor@host-104-157-228-210.dyn.295.ca] has joined #secp256k1 22:13 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #secp256k1 --- Log closed Thu Apr 25 00:00:54 2019