--- Day changed Sun Feb 11 2018
01:25 -!- jtimon [~quassel@41.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 256 seconds]     
04:06 -!- Cory [~Cory@unaffiliated/cory] has quit []     
08:07 < andytoshi> gmaxwell: i'm confused about the goal "the server never learns if the client authenticated or not", if the client fails to authenticate he's going to disconnect..
08:08 < andytoshi> also, does a simple protocol where the client sends an ECDH-encrypted random value x and expects to recieve x^2 (encrypted w same ECDH secret) do what you want?
08:27 -!- Cory [~Cory@unaffiliated/cory] has joined #secp256k1     
10:44 -!- jtimon [~quassel@41.31.134.37.dynamic.jazztel.es] has joined #secp256k1     
12:01 < gmaxwell> andytoshi: no he isn't.
12:02 < gmaxwell> You just leave the connection up and treat it like a ordinary random peer, perhaps flaged to be the first you replace.
12:02 < gmaxwell> while sounding your klaxons.
12:03 < andytoshi> ah ok
12:08 < gmaxwell> as far as the alternative goes, that doesn't work:  say the far end uses pubkey Q instead of P that the client expects.  Requester sends the ECDH nonce, gets back the reply with respect to Q.  Client can then go down his list and see who he was talking to and find out that Q works. (or save the data and later when he learns of Q confirm it).
12:13 < andytoshi> ah k, i missed that in your giant list of requirements :)
12:21 < andytoshi> ok, so your proposal is: client sends x, the pair compute H(x || expect pk || session ID) .. then the makes a polynomial p(Z) = x - Z which is zero only at x and sends elgamal encryptions of P0, P1 of x, -1 ... the server replies with xP0 + P1 which will be an encryption of 0 iff the server and client are thinking of the same x
12:21 < andytoshi> but if they're not, the server will reply with an apparently-random point which the client can't do anything with
12:21 < andytoshi> is that right?
12:22 < andytoshi> oh i'm using el-gamal commitments here rather than encryptions
12:22 < andytoshi> lemme remind myself how encryption works, one sec
12:23 < andytoshi> oh encryption maps the message space to points rather than numbers.. i think you were thinking of commitments too.
12:23 < sipa> map point to group element, and add an ECDh derived shared group element to it
12:24 < sipa> ^ that's elgamal encryption?
12:24 < andytoshi> yep. according to wikipedia anyway
12:24 < sipa> *map msg to group elememt
12:26 < andytoshi> gmaxwell: yeah, this is really cool
12:44 < sipa> why is it not sufficient that the responder replies with H(session || ecdh derived point) ?
12:45 < sipa> he doesn't know if that's the expected value or not
12:45 < andytoshi> because the client knows `ecdh derived point` for many peers
12:45 < andytoshi> so he can infer from the response who he's actually connected to
12:46 < sipa> ah, of course
12:48 < gmaxwell> and/or save the value and figure it out later when he learns more keys.
12:48 < sipa> yup, i see
12:49 < gmaxwell> this was the limitation in BIP150 that I started off trying to fix, in fact. Only after I first came up with send H(session||point) did I realize I could also get the property that the responder couldn't tell if auth was successful or not.
12:50 < sipa> well, one of them
12:50 < sipa> bip150 also has the property that the responder knows whether he has the key the requester wants
12:51 < sipa> oops, i need to read whole sentences before responding
12:52 < sipa> a polynomial a*x + b has -b/a as root
12:53 < sipa> if you encrypt the coefficients, it becomes (a+r1)*x + (b+r2), with r1 and r2 ecdh derived things, right?
13:01 < gmaxwell> it's useful to think of the encryption as multidimensional number pedersen commitment.  xP, zP+xQ the fact that the originator knows the DL between P/Q and so they can decrypt isn't important.
13:01 < gmaxwell> I think that makes it more clear how the encrypted evauluation works.  when you multiply the ecryption you multiply both parts, when you add you add both parts.
13:02 < sipa> multiplying the coefficients certainly results in the evaluation being multiplyed by the same value when evaluated in the same point
13:02 < sipa> but the same is not true for addition
13:04 < sipa> i think i need to see it a bit more concretely
13:06 < gmaxwell> I don't follow.
13:07 < gmaxwell> The protocol doesn't multiply the coefficients except to evaluate the encrypted polynomial.
13:07 < sipa> i guess i don't understand what 'encrypting the coefficients' means
13:07 < sipa> or at least not how that results in an encryption of 0
13:08 < sipa> when evaluated in a root
13:08 < gmaxwell> so a*x + b, a is set randomly and b is set so that h (our shared ECDH derrived secret) is a root.
13:08 < sipa> yup, so a*h + b = 0
13:09 < gmaxwell> right
13:09 < sipa> a x and b are all scalars here, mod the curve size, right?
13:09 < gmaxwell> Yes.
13:12 < sipa> can the requester not just send a*G and (b+r)*G, which the responder then evaluates in h and returns?
13:13 < sipa> and if the result is not r*G, the authentication fails
13:15 < gmaxwell> No. To make it zk when the server evaluates the encrypted polynomial he multiplies it with a random value.
13:15 < sipa> who is tbe server?
13:15 < sipa> right, this is not zk, because if i can predict what h you're going to evaluate in, i know the evaluation
13:16 < gmaxwell> The client is the guy asking the server (listener) to authenticate himself.
13:16 < gmaxwell> Otherwise the client could try different evaluation locations, and see what he gets.
13:16 < gmaxwell> right
13:16 < sipa> please stick to requester and reponder :)
13:17 < gmaxwell> concretely the elg enc of a  is  {xG, aG+xP} with P=yG some random x and y known to the client.
13:18 < sipa> i have no idea who 'server' and 'client' refer to
13:19 < sipa> client = requester, server = responder?
13:19 < gmaxwell> yes     
13:19 < gmaxwell> sorry, andrew was using client and server above.
13:21 < sipa> so how do you evaluate a polynomial whose coefficients are pairs of points?
13:27 < andytoshi> why is zk needed?
13:28 < gmaxwell> sipa: h*e(a) + e(b) = e(ha + b) =  {hxG,h(aG+xP)} + {x'G, bG+x'P}
13:28 < andytoshi> requester sends an ECDH-encrypted challenge, responder responds with an elgamal encryption which is either something specific or uniformly random
13:28 < gmaxwell> andytoshi: so the requester (client) and try a bunch of candidate server pubkeys online or offline.
13:29 < gmaxwell> It's not uniformly random unless the responder multiplies it by a random number.
13:29 < andytoshi> ah ok i see
13:29 < andytoshi> and that's also why you have to use encryption rather than commitments
13:31 < sipa> gmaxwell: what is x' ?
13:31 < gmaxwell> sipa: just a different random secret for the encryption sent for the second value.
13:32 < gmaxwell> wouldn't want to encrypt a and b with the same value. (Though I suppose you probably could get away with it in this protocol)
13:40 < gmaxwell> its nice that the protocol only needs one round trip. Should make creating an interface for it easy.
13:50 < gmaxwell> interface would be something like:
13:50 < gmaxwell> start_handshake(*state_handle, *messagebuf, mbuff_size, m_keys_he_can_try, *pubkeys_accepted_list, n_keys_accepted, *rngdata);
13:50 < gmaxwell> respond_handshake(*replym, replym_size, *chalmessage, chal_size, *privkey_list, *n_privkeys, *rngdata);
13:50 < gmaxwell> vrfy_response(*state_handle, *replym, replym_size);
13:52 < gmaxwell> plus some helper functions to tell you how big your message buffers need to be.
17:53 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 255 seconds]     
17:58 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #secp256k1     
19:09 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]     
19:10 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #secp256k1     
23:07 -!- jtimon [~quassel@41.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 248 seconds]