--- Log opened Wed Aug 14 00:00:40 2019 00:13 -!- weez17 [~isaac@unaffiliated/weez17] has joined #secp256k1 02:28 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has quit [Ping timeout: 252 seconds] 03:31 -!- jonatack [~jon@82.102.27.195] has joined #secp256k1 03:47 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #secp256k1 03:50 -!- jonatack [~jon@82.102.27.195] has quit [Ping timeout: 245 seconds] 03:52 -!- jonatack [~jon@213.152.162.104] has joined #secp256k1 04:08 -!- jonatack [~jon@213.152.162.104] has quit [Quit: WeeChat 2.3] 04:08 -!- jonatack [~jon@213.152.162.104] has joined #secp256k1 06:25 -!- jonatack [~jon@213.152.162.104] has quit [Ping timeout: 245 seconds] 07:04 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined #secp256k1 07:41 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-rvlwnnvpylfdhovi] has joined #secp256k1 08:00 < elichai2> So I read the Purify Markdown and if I understand correctly it still requires a good ol hash function(sha2) 08:03 < elichai2> Oh I guess the regular hash function is happening outside of the circuit just to make everything 32 bytes 08:07 < real_or_random> exactly! 08:09 < real_or_random> yes, the normal hash function is outside the circuit for efficiency. it's also nice that makes everything 32 bytes but that's not the main reason. you also a random oracle here for security 08:11 < elichai2> But if you're acting as a random oracle outside of the circuit how can you prove it? 08:14 < elichai2> But it's pretty amazing to me that a random x point in a curve is uniformly random in F 08:36 < real_or_random> k*hash-to-curve(m) is a pseudorandom function onto the curve, with key k and input m 08:36 < real_or_random> if hash-to-curve is modelled as a random oracle 08:36 < real_or_random> this is all you need for the security proof 08:37 < real_or_random> now if you want to perform a ZKP over it with a public m, it happens to be the case that hash-to-curve(m) is publicly known 08:37 < real_or_random> so everybody can compute it on their own; no need to include this part in the ZKP 08:40 < elichai2> Nice :) 08:41 < sipa> real_or_random: IIRC it being a PRF wasn't actually enough? 08:41 < elichai2> I need to impl some zkp(probably bulletproofs) to get a sense of how complex operations are in proofs 08:42 < andytoshi> you should implement starks and tell me how hard it is ;) 08:43 < andytoshi> (i'm mostly kidding. bulletproofs are much more accessible.0 08:43 < real_or_random> sipa: hm not sure what you mean. we also exploit the random oracle model in another step of the security proof, yes. 08:44 < real_or_random> or do you mean that it's not enough to build a PRF that outputs a curve point, we actually need a PRF that outputs a scalar. (that's a further step then, yes) 08:46 < real_or_random> elichai2: look at andytoshi's 5000-lines PR for bulletproofs (only range proofs!) and its hundred comments 08:47 < andytoshi> in fairness a lot of the callback stuff would be much easier in rust than in C 08:47 < real_or_random> and then read the sentence about "much more accessible" again xD and you can imagine how starks are 08:47 < andytoshi> :P 08:48 < real_or_random> yes, and in fairness, we spent more time on bulletproofs than on starks... so for us, they're clearly more accessible 08:48 < elichai2> real_or_random: personally if I don't impl something myself from the paper I don't fully grasp it 08:48 < andytoshi> and it's also probable that you wouldn't need the callback stuff if you didn't implement batch verification or aggregation (but then you lose all the benefits of bulletproofs) 08:48 < elichai2> Lol so starks are that bad ha 08:48 < andytoshi> well, it's just that i haven't gotten through all the papers i need 08:49 < andytoshi> i suspect that once i actually learn them they'll be easier in a lot of ways 08:49 < andytoshi> but conceptually they're much harder (at least if you're used to ECDL stuff) 08:51 < sipa> real_or_random: iirc the proof relies on specific properties of the multiply scalar with random point map, that aren't present for any PRF 08:52 < sipa> real_or_random: in our email thread i constructed a pathological PRF somewhere that discards some key data, and the result was that signatures became insecufe 08:52 < elichai2> Lol there's a whole track on "Cryptocurrency scams" https://www.usenix.org/conference/usenixsecurity19/technical-sessions 08:55 < real_or_random> lol 08:59 < real_or_random> sipa: ah sure, informally speaking you need the property that it remains a PRF if you show the host keys 09:01 < real_or_random> but this all depends on hiding/binding of the commitments to the secret host key etc 09:02 < real_or_random> I mean perfect vs computational etc 09:02 < real_or_random> (debatable whether this is a property of the function in the end, but yes, you need more than a PRF in the end) 09:24 < sipa> real_or_random: is that all? 09:38 < real_or_random> well, as I said we also exploit the RO somewhere else. 09:42 < sipa> i seem to remember we couldn't plug in a normal hash function as PRF, even if modeled as a RO 09:42 < real_or_random> it's kind of hard to say that "this is all". in the end you have a commitment scheme, a PRF (with a RO in it), a zero-knowledge proof system etc and only if they all fit together, you can argue security. and since we exploit the specific PRF construction with its RO in the right, yes, you're right, it's not black box in the RPF 09:43 < real_or_random> *PRF. so we cannot just use another one. but I believe you could any PRF which feeds the message first into a RO 09:44 < real_or_random> and since given any PRF f and RO H, f(k,H(m)) is a PRF too, we could probably use other PRFs too. 09:45 < real_or_random> (actually this holds even for weak PRFs f; maybe we just state it in that way in the paper if this is possible. then the construction would be more black-box again... *noting that down*) 09:48 < real_or_random> concretely, what we exploit here is first that the reduction can program the RO by H(m)=z*G for a known z. so the reduction can know the dlog of the hashed point. and then, given any host key y*G of the attacker, it can compute the PRF output z*y*G on its own. 09:50 < real_or_random> so the reduction will know the nonces of every participant upfront. that makes life pretty easy 09:50 < real_or_random> (and again demonstrates how absurd the ROM is ^^) 09:52 < sipa> ha 10:03 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds] 10:27 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #secp256k1 11:30 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-rvlwnnvpylfdhovi] has quit [Quit: Connection closed for inactivity] 12:20 -!- reallll [~belcher@unaffiliated/belcher] has joined #secp256k1 12:22 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1 12:22 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection] 12:22 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Write error: Connection reset by peer] 12:22 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Write error: Connection reset by peer] 12:23 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #secp256k1 12:23 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 248 seconds] 12:25 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #secp256k1 12:27 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 250 seconds] 12:28 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #secp256k1 13:04 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds] 13:15 -!- weez17 [~isaac@unaffiliated/weez17] has quit [Remote host closed the connection] 13:49 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1 14:40 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection] 14:47 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1 15:07 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection] 15:10 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1 15:38 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection] 15:38 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1 15:40 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Read error: No route to host] 15:40 -!- ddustin_ [~ddustin@unaffiliated/ddustin] has joined #secp256k1 16:08 -!- ddustin_ [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection] 16:10 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1 16:10 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-leumsttcdrujgspm] has joined #secp256k1 16:13 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection] 16:17 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #secp256k1 16:52 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection] 18:28 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-leumsttcdrujgspm] has quit [Quit: Connection closed for inactivity] 20:19 -!- weez17 [~isaac@unaffiliated/weez17] has joined #secp256k1 --- Log closed Thu Aug 15 00:00:40 2019