--- Log opened Fri Oct 19 00:00:41 2018
07:05 -!- VaivarsZh [~Vaivars@user198.85-195-10.netatonce.net] has joined #secp256k1
07:12 -!- VaivarsZh [~Vaivars@user198.85-195-10.netatonce.net] has quit [Remote host closed the connection]
10:52 -!- ddustin [40470882@gateway/web/freenode/ip.64.71.8.130] has joined #secp256k1
11:14 < ddustin> Are there stats on how much faster secp256k1 is than the emed tls library?
11:17 < gmaxwell> faster at what?
11:18 < gmaxwell> for signature validation, it should probably be 10x+ faster than any well optimized field/curve-generic implementation (e.g. openssl).
11:28 < ddustin> For signing
11:28 < ddustin> gmaxwell: As well as public key generation, diffie calculations, and adding / multiplying -- but I assume those are already pretty fast
11:29 < gmaxwell> What is your application? if you're not doing signature validation or ZKP perhaps you should be using a diferent curve?
11:29 < sipa> gmaxwell: FWIW, OpenSSL on my system verifies in 400us, libsecp256k1 in 60us
11:30 < ddustin> gmaxwell: Signing bitcoin transactions
11:30 < gmaxwell> oh okay.
11:30 < gmaxwell> ddustin: signing is essentially a pubkey key generation plus some fairly trivial operations.
11:30 < sipa> why do you need ECDH, though?
11:31 < ddustin> gmaxwell: ah okay! That's great news. So its verifying that's slow?
11:31 < sipa> ddustin: signing and verifying are around the same speed
11:31 < ddustin> sipa: Dont need to, could use RSA. Just using it cause it's there mostly
11:31 < sipa> due to signing needing to be constant time, it needs to use less efficient algorithms
11:32 < gmaxwell> ddustin: pubkey gen and verifying are about the same speed, largely because secret key operations really should use sidechannel free algorithims.
11:32 < gmaxwell> (same story for ECDH)
11:33 < sipa> ECDH is slower because it can't use precomputed multiples of a fixed generator
11:34 < ddustin> sipa: Ah okay, so perhaps I should use something else for diffie
11:34 < sipa> specifically on my system: signing 40us, verifying 60us, ECDH 70us
11:34 < ddustin> Ouch, that's a big difference
11:34 < ddustin> This is all super helpful, thanks guys!
11:35 < gmaxwell> nothing else that isn't less secure is likely to be substantially faster.
11:37 < gmaxwell> sipa: we probably should add some ifdefs to offer a smaller ecmultg table easly, I'm tired of seeing embedded devices use gratitiously insecure/homebrew algorithims just because they didn't have enough expertise to figure out they can reduce the window sizes.
12:15 -!- reallll [~belcher@unaffiliated/belcher] has joined #secp256k1
12:18 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Ping timeout: 272 seconds]
12:20 -!- ddustin [40470882@gateway/web/freenode/ip.64.71.8.130] has quit [Ping timeout: 256 seconds]
16:47 -!- deusexbeer [~deusexbee@080-250-075-064-dynamic-pool-adsl.wbt.ru] has quit [Quit: Konversation terminated!]
19:15 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Read error: Connection reset by peer]
19:15 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #secp256k1
21:28 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
21:28 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
21:37 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 252 seconds]
21:44 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
23:11 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
23:11 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
23:16 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
23:16 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
23:55 -!- ken2812221 [~ken281222@110.50.135.178] has joined #secp256k1
--- Log closed Sat Oct 20 00:00:42 2018