19:51:35 <sarang> peach34: What are you using as your math reference for the code in https://github.com/monero-project/monero/blob/master/src/crypto/crypto.cpp#L515 ?
19:51:57 <sarang> The original ring signature scheme proposed in the CryptoNote whitepaper is on page 9 here: https://cryptonote.org/whitepaper.pdf
19:52:12 <sarang> It's not the same as the LSAG signature by Liu et al.
19:55:38 <sarang> IIRC the Zero to Monero reference doesn't even address the older ring signature algorithm (but I'd need to check this)
19:57:27 <peach34> Both the cryptonote whitepaper and the zero to monero document
19:58:09 <peach34> https://cryptonote.org/whitepaper.pdf page 9
19:58:26 <peach34> https://www.getmonero.org/library/Zero-to-Monero-1-0-0.pdf
19:58:31 <peach34> Page 22 and 23
19:59:23 <peach34> I'm concerned with the part where you close the ring ( r = q - ck  in both documents)
19:59:57 <peach34> k is the private key for the stealth address P that belong to the signer of the ring ( P =kG)
20:01:11 <peach34> ie the same key used to sign the key image ( I=kH(P))
20:03:38 <sarang> The notation you're using here seems inconsistent with the code, since that function uses `k` to mean what `q_s` is in the CN paper
20:04:11 <sarang> `sec` in the function would be `x` in the CN paper
20:04:24 <peach34> yes, sure. The notation is different everywhere
20:04:28 <peach34> The principle is the same
20:04:34 <sarang> But ok, carry on
20:04:46 <peach34> yes, sec in the code should be x
20:04:49 <sarang> (let's use the code's notation for clarity here, perhaps)
20:05:01 <peach34> The same x in Image = x H(P)
20:05:13 <peach34> P is the stealth address of the genuine input being spent
20:05:15 <sarang> Yes, the discrete log of the public key and key image are the same
20:06:23 <sarang> (relative to G and H(P), respectively)
20:06:35 <peach34> const secret_key &sec passed into generate_ring_signature, comes from struct input_generation_context_data    {      keypair in_ephemeral;    };    std::vector<input_generation_context_data> in_contexts;
20:07:01 <peach34>       in_contexts.push_back(input_generation_context_data());
20:07:07 <peach34> That's all that happens
20:07:21 <peach34> Where is the assignment to the x that we're speaking of
20:07:46 <sarang> `x` isn't used in the code; I was trying to bridge the gap between the paper's notation and the code's notation
20:07:47 <peach34> ie P=xG and I=xH(P)
20:07:56 <peach34> i know
20:08:04 <peach34> Ok , so
20:08:44 <sarang> The signing-index public key is asserted to have the proper relationship to the secret key here: https://github.com/monero-project/monero/blob/master/src/crypto/crypto.cpp#L535
20:08:56 <sarang> and for the key image here: https://github.com/monero-project/monero/blob/master/src/crypto/crypto.cpp#L537
20:08:59 <peach34> in the code, the line sc_mulsub(&sig[sec_index].r, &sig[sec_index].c, &unwrap(sec), &k);  is meant to be the line qs−csx   modl in the whitepaper
20:09:15 <sarang> yes
20:09:49 <peach34> yes so what i'm asking is, the sec that is fed into the generate_ring_signature function, where is it set to x
20:10:10 <peach34> it looks like it's just coming from a random ephemeral key generation inside src/cryptonote_core/cryptonote_tx_utils.cpp
20:11:06 <peach34> lines 299 -319
20:11:24 <peach34> and NOT the key x pertaining to P=xG and I=xH(P)
20:12:24 <peach34> this is the only dealing with it before it's passed into generate_ring_signature:
20:12:26 <peach34> struct input_generation_context_data    {      keypair in_ephemeral;    };    std::vector<input_generation_context_data> in_contexts;    uint64_t summary_inputs_money = 0;    //fill inputs    int idx = -1;    for(const tx_source_entry& src_entr:  sources)    {      ++idx;      if(src_entr.real_output >= src_entr.outputs.size())      {
20:12:27 <peach34> LOG_ERROR("real_output index (" << src_entr.real_output << ")bigger than output_keys.size()=" << src_entr.outputs.size());        return false;      }      summary_inputs_money += src_entr.amount;      //key_derivation recv_derivation;      in_contexts.push_back(input_generation_context_data());
20:13:48 <peach34> My question ultimately is, where in src/cryptonote_core/cryptonote_tx_utils.cpp is the sec assigned to the private key corresponding to the public stealth key P
20:15:26 <peach34> (x in the whitepaper)... it seems like it's just assigned a random ephemeral key instead during lines 299-319 in src/cryptonote_core/cryptonote_tx_utils.cpp before generate_ring_signature is called in the same scope
20:22:05 <sarang> Appears to be here, but this is only after cursory examination: https://github.com/monero-project/monero/blob/master/src/cryptonote_basic/cryptonote_format_utils.cpp#L334
20:24:28 <peach34> sorry i am checked out to an older version, dif lines i think
20:24:41 <sarang> ah ok
20:25:01 <peach34> ill find the bit i mean on master
20:26:49 <peach34> same file, line 483
20:26:56 <peach34> That's where generate_ring_signature is called
20:27:20 <peach34> Ie it's called in the function scope of construct_tx_with_tx_key
20:27:20 <sarang> Can you link to a GitHub line to ensure we're absolutely looking at the same thing?
20:27:29 <peach34> kk
20:28:35 <peach34> https://github.com/monero-project/monero/blob/3e3db923039da6507add4e9023fde57d4045d7a6/src/cryptonote_core/cryptonote_tx_utils.cpp#L483
20:29:26 <sarang> Prior to that, this is called: https://github.com/monero-project/monero/blob/3e3db923039da6507add4e9023fde57d4045d7a6/src/cryptonote_core/cryptonote_tx_utils.cpp#L326
20:29:43 <sarang> The secret key in that structure is then set: https://github.com/monero-project/monero/blob/master/src/cryptonote_basic/cryptonote_format_utils.cpp#L334
20:30:03 <sarang> That secret key is then used in generate_ring_signature as expected
20:31:47 <peach34> Ah I see that:
20:31:47 <peach34> keypair& in_ephemeral = in_contexts.back().in_ephemeral;
20:31:53 <peach34> it's set to the memory address
20:32:23 <peach34> I did not notice. Thanks for your help for making me realise that
20:32:42 <sarang> Glad everything is clear now!
20:32:57 <peach34> Sorry if this appeared as a time waste. I am going through all of Monero to make sure I know it all
20:33:13 <peach34> I guess you probably get worse questions eh haha
20:33:19 <sarang> Additional eyes on the code and math are always appreciated
20:33:38 <sarang> especially since much of the code lacks clarifying comments
20:33:42 <peach34> at least my math was on point, which gives me confidence
20:33:44 <sarang> and the notation is often not consistent :/
20:33:50 <peach34> Yeah ^ absolutely
20:34:01 <peach34> Like there was no need to assign the memory address
20:34:19 <peach34> in another variable
20:34:55 <peach34> There are very few comments too yeah.
20:35:38 <peach34> Thank you Sarang
20:37:09 <sarang> No prob
20:44:27 <needmonero90> peach34: are there any comments you could PR that would make this process easier for the next person to stumble across it?
20:46:07 <peach34> Yeah probably. I'll do soon.
20:47:04 <peach34> I have one other question
20:48:29 <peach34> if for one stealth address created via P = H(rA)G+B, and spent using x =H(aR) + b
20:50:00 <peach34> If a third party found out what a was, so they could compute H(aR) and also what x was, is it possible to work out b from x - H(aR)
20:50:56 <peach34> ie, if somehow you leaked your private viewkey and the tx private key for a single tx, could someone work backwards to the private spendkey
20:54:46 <sarang> If by "tx privkey" you mean "output privkey" (i.e. `x`) then yes
20:54:56 <peach34> I do mean that
20:54:59 <peach34> That is fascinating
20:55:14 <peach34> So you're only as secure as any one of your tx private keys
20:55:20 <moneromooo> The fuck ?
20:55:23 <sarang> Yeah, it's been previously noted that the affine construction of the outputs leads to this
20:55:37 <scoobybejesus> hm.. i was gonna say that didn't sound right
20:55:58 <peach34> yes but the maths doesn't lie :P
20:56:21 <sarang> If someone has access to a recipient's output private key and can construct the DH shared secret, they can recover the private spend key, yes
20:57:13 <sarang> peach34: note that "tx privkey" and "output privkey" are _not_ the same thing
20:57:24 <sarang> "tx privkey" would be the scalar `r` such that `R = rG`
20:57:29 <peach34> yes i understand
20:57:40 <sarang> ok
20:57:43 <peach34> sorry i get the naming wrong, my colleague uses the opposite nomenclature
20:57:53 <moneromooo> Ooooh, phew.
20:58:08 <peach34> I mean x such that stealth address P = xG
20:58:18 <sarang> Yes, that's the "output privkey"
20:58:54 <moneromooo> That'd have been a massive problem given we told people to send the tx secret key to prove payment before.
20:59:59 <moneromooo> So *that* is safe, right ? Give away both your view secret key and a tx secret key ?
21:00:57 <sarang> Knowledge of a secret view key is roughly equivalent to knowledge of a tx secret key (for constructing DH shared secrets)
21:01:04 <sarang> Passing around your output privkeys is a bad idea
21:01:28 <sarang> That being said, IMO it's a much safer idea to prove knowledge of the tx secret key rather than give it away
21:01:34 <sarang> i.e. using a Schnorr proof
21:01:39 <sarang> (as has been discussed elsewhere)
21:02:14 <peach34> correct yes^
21:02:22 <peach34> signing with r rather than disclosing r
21:02:52 <sarang> righto
21:03:02 * moneromooo notes that sarang did not say yes...
21:03:09 <peach34> haha
21:03:10 <sarang> ?
21:03:24 <sarang> Well, depends on what you're looking for
21:03:50 <sarang> If I give away `r` as some kind of "proof", then that person could conduct the same "proof" by giving `r` away to someone else
21:04:14 <moneromooo> Yes, that's fine. Can that person nick your monero ?
21:04:31 <moneromooo> 99% sure it's "no" after hte clarification of "tx private key" above, but I want to make sure.
21:04:35 <sarang> Not without knowledge of either your spend private key or your output's private key
21:04:50 <sarang> Otherwise any sender could steal funds
21:04:53 <moneromooo> OK, thank you.
21:04:54 <peach34> only with the output private key
21:05:20 <peach34> subtract hash of(private view*R)
21:05:28 <sarang> correct
21:07:29 <sarang> peach34: if you have particular interest in the math behind signature constructions, have a look at CLSAG, a new construction that I worked on with collaborators
21:07:37 <sarang> https://eprint.iacr.org/2019/654
21:07:41 <sarang> It has not yet been deployed
21:08:00 <sarang> It's a modification of our current MLSAG signatures to save space and time
21:08:20 <peach34> Awesome. I will save it and take a look some time
21:08:33 <sarang> We're currently revising the security model in response to some reviewers
21:08:49 <sarang> Any comments on the math/proofs would be appreciated
21:09:21 <peach34> Many thanks
21:09:36 <sarang> thanks for looking over that code
21:09:45 <peach34> I will try and look at it . What is your background? Do you just do this for fun?
21:09:49 <peach34> Or are you at a university?
21:10:11 <sarang> I am not at a university, but I have a background in math
21:10:43 <peach34> Right. I am from theoretical physics, but I only recently started learning cryptography.
21:10:59 <sarang> It's a fascinating area of study
21:11:10 <sarang> Particularly because provable security is so different from other types of proof
21:11:19 <peach34> Do you do it for your day job too?
21:11:31 <sarang> yes
21:11:48 <peach34> Can I ask what you do?
21:12:24 <sarang> I receive community funding to work on cryptography
21:12:48 <needmonero90> From the Monero community, believe it or not :)
21:13:02 <needmonero90> Our two researchers get paid quarterly.
21:14:40 <peach34> So you actually work for Monero? Nice.
21:15:04 <sarang> What's your interest? Trying to learn some applied cryptography for fun?
21:15:24 <peach34> I work for another cryptocurrency. The name I can't mention :P
21:15:25 <sarang> The Monero codebase is probably not the ideal venue for learning :/
21:15:39 <sarang> ah ok
21:16:07 <peach34> We like Monero though. We like the complexity.
21:16:29 <sarang> ok
21:16:44 <chameleon_es_bor> Is ristretto something that could be implemented for monero? It seems like it is just a safe way to encode/decode/hash to point/equate that avoids the cofactor issues...
21:17:30 <sarang> It would have to be tied to the C++ code, and there would need to be assurances that existing point representations play nicely with things like hash inputs
21:19:04 <chameleon_es_bor> in your opinion, would the complexity of adding it (if possible) outweigh any benefit?
21:19:27 <sarang> That's not clear to me
21:19:43 <peach34> Sarang, do you work full time for Monero?
21:20:25 <sarang> Why?
21:21:14 <peach34> Just wondering. You are clearly talented and are paid less / year than you would in the private sector for full time work
21:21:37 <peach34> I wondered how much of your involvement is out of pure affinity for the system
21:21:40 <sarang> I appreciate the compliment peach34
21:21:51 <peach34> I am watching your video on youtube lol
21:21:58 <sarang> Which video?
21:22:24 <peach34> https://www.youtube.com/watch?v=6lEWqIMLzUU&t=2561s
21:22:53 <sarang> Ah, bulletproofs
21:28:42 <peach34> I just looked up your background
21:28:48 <peach34> I also did a bit of work on atomic clocks
21:28:50 <peach34> :P
21:31:20 <peach34> Did you ever work with University of Birmingham UK? Or read any research from them?
21:33:21 <needmonero90> When did this channel turn into Monero-research-inquisition
21:33:55 <peach34> lol
21:34:31 <peach34> My apologies. It's just interesting to me that blockchain is full of physicists.
21:38:59 <chameleon_es_bor> Thinkers like thinking.
21:39:27 <needmonero90> [citation needed]
21:39:54 <chameleon_es_bor> https://xkcd.com/356/
21:40:40 <sarang> -___-
21:47:25 <moneromooo> lol
21:55:48 <peach34> sarang am I right in thinking that the output private key doesn't leave the hwdevice?
21:56:09 <peach34> Doing so would be equivalent to leaking the wallet spendkey, as per out prior conversation
21:57:42 <peach34> our*
23:08:23 <peach34> sarang say I was doing a ring signature in accordance with https://cryptonote.org/whitepaper.pdf at the bottom of page 9, and i never disclose x
23:09:43 <peach34> What is the minimum amount of other information, if intercepted, that could help a third party calculate x?
23:12:53 <peach34> say they somehow got all variables used right at the bottom for the various c_i  and r_i
23:13:09 <peach34> apart from x. Could they compute x
23:14:57 <peach34> q_s - c_s*x = r                  I guess so right? (r-q)/c_s   ?
23:16:16 <peach34> well there is a modulus involved so it changes things slightly
23:22:10 <peach34> Going to sleep will think about this tomorrow morning
23:30:19 <peach34> my chat might be deleted too lol so i will ask again tomorrow.