peach34: What are you using as your math reference for the code in github.com/monero-project/monero/bl…b/master/src/crypto/crypto.cpp#L515 ?

The original ring signature scheme proposed in the CryptoNote whitepaper is on page 9 here: cryptonote.org/whitepaper.pdf

It's not the same as the LSAG signature by Liu et al.

IIRC the Zero to Monero reference doesn't even address the older ring signature algorithm (but I'd need to check this)

Both the cryptonote whitepaper and the zero to monero document

cryptonote.org/whitepaper.pdf page 9

Page 22 and 23

I'm concerned with the part where you close the ring ( r = q - ck in both documents)

k is the private key for the stealth address P that belong to the signer of the ring ( P =kG)

ie the same key used to sign the key image ( I=kH(P))

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

`sec` in the function would be `x` in the CN paper

yes, sure. The notation is different everywhere

The principle is the same

But ok, carry on

yes, sec in the code should be x

(let's use the code's notation for clarity here, perhaps)

The same x in Image = x H(P)

P is the stealth address of the genuine input being spent

Yes, the discrete log of the public key and key image are the same

(relative to G and H(P), respectively)

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;

in_contexts.push_back(input_generation_context_data());

That's all that happens

Where is the assignment to the x that we're speaking of

`x` isn't used in the code; I was trying to bridge the gap between the paper's notation and the code's notation

ie P=xG and I=xH(P)

i know

Ok , so

The signing-index public key is asserted to have the proper relationship to the secret key here: github.com/monero-project/monero/bl…b/master/src/crypto/crypto.cpp#L535

and for the key image here: github.com/monero-project/monero/bl…b/master/src/crypto/crypto.cpp#L537

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

yes

yes so what i'm asking is, the sec that is fed into the generate_ring_signature function, where is it set to x

it looks like it's just coming from a random ephemeral key generation inside src/cryptonote_core/cryptonote_tx_utils.cpp

lines 299 -319

and NOT the key x pertaining to P=xG and I=xH(P)

this is the only dealing with it before it's passed into generate_ring_signature:

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()) {

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());

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

(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

Appears to be here, but this is only after cursory examination: github.com/monero-project/monero/bl…ic/cryptonote_format_utils.cpp#L334

sorry i am checked out to an older version, dif lines i think

ah ok

ill find the bit i mean on master

same file, line 483

That's where generate_ring_signature is called

Ie it's called in the function scope of construct_tx_with_tx_key

Can you link to a GitHub line to ensure we're absolutely looking at the same thing?

kk

Prior to that, this is called: github.com/monero-project/monero/bl…e_core/cryptonote_tx_utils.cpp#L326

The secret key in that structure is then set: github.com/monero-project/monero/bl…ic/cryptonote_format_utils.cpp#L334

That secret key is then used in generate_ring_signature as expected

Ah I see that:

keypair& in_ephemeral = in_contexts.back().in_ephemeral;

it's set to the memory address

I did not notice. Thanks for your help for making me realise that

Glad everything is clear now!

Sorry if this appeared as a time waste. I am going through all of Monero to make sure I know it all

I guess you probably get worse questions eh haha

Additional eyes on the code and math are always appreciated

especially since much of the code lacks clarifying comments

at least my math was on point, which gives me confidence

and the notation is often not consistent :/

Yeah ^ absolutely

Like there was no need to assign the memory address

in another variable

There are very few comments too yeah.

Thank you Sarang

No prob

peach34: are there any comments you could PR that would make this process easier for the next person to stumble across it?

Yeah probably. I'll do soon.

I have one other question

if for one stealth address created via P = H(rA)G+B, and spent using x =H(aR) + b

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)

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

If by "tx privkey" you mean "output privkey" (i.e. `x`) then yes

I do mean that

That is fascinating

So you're only as secure as any one of your tx private keys

The fuck ?

Yeah, it's been previously noted that the affine construction of the outputs leads to this

hm.. i was gonna say that didn't sound right

yes but the maths doesn't lie :P

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

peach34: note that "tx privkey" and "output privkey" are _not_ the same thing

"tx privkey" would be the scalar `r` such that `R = rG`

yes i understand

ok

sorry i get the naming wrong, my colleague uses the opposite nomenclature

Ooooh, phew.

I mean x such that stealth address P = xG

Yes, that's the "output privkey"

That'd have been a massive problem given we told people to send the tx secret key to prove payment before.

So *that* is safe, right ? Give away both your view secret key and a tx secret key ?

Knowledge of a secret view key is roughly equivalent to knowledge of a tx secret key (for constructing DH shared secrets)

Passing around your output privkeys is a bad idea

That being said, IMO it's a much safer idea to prove knowledge of the tx secret key rather than give it away

i.e. using a Schnorr proof

(as has been discussed elsewhere)

correct yes^

signing with r rather than disclosing r

righto

haha

?

Well, depends on what you're looking for

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

Yes, that's fine. Can that person nick your monero ?

99% sure it's "no" after hte clarification of "tx private key" above, but I want to make sure.

Not without knowledge of either your spend private key or your output's private key

Otherwise any sender could steal funds

OK, thank you.

only with the output private key

subtract hash of(private view*R)

correct

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

It has not yet been deployed

It's a modification of our current MLSAG signatures to save space and time

Awesome. I will save it and take a look some time

We're currently revising the security model in response to some reviewers

Any comments on the math/proofs would be appreciated

Many thanks

thanks for looking over that code

I will try and look at it . What is your background? Do you just do this for fun?

Or are you at a university?

I am not at a university, but I have a background in math

Right. I am from theoretical physics, but I only recently started learning cryptography.

It's a fascinating area of study

Particularly because provable security is so different from other types of proof

Do you do it for your day job too?

yes

Can I ask what you do?

I receive community funding to work on cryptography

From the Monero community, believe it or not :)

Our two researchers get paid quarterly.

So you actually work for Monero? Nice.

What's your interest? Trying to learn some applied cryptography for fun?

I work for another cryptocurrency. The name I can't mention :P

The Monero codebase is probably not the ideal venue for learning :/

ah ok

We like Monero though. We like the complexity.

ok

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...

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

in your opinion, would the complexity of adding it (if possible) outweigh any benefit?

That's not clear to me

Sarang, do you work full time for Monero?

Why?

Just wondering. You are clearly talented and are paid less / year than you would in the private sector for full time work

I wondered how much of your involvement is out of pure affinity for the system

I appreciate the compliment peach34

I am watching your video on youtube lol

Which video?

Ah, bulletproofs

I just looked up your background

I also did a bit of work on atomic clocks

:P

Did you ever work with University of Birmingham UK? Or read any research from them?

When did this channel turn into Monero-research-inquisition

lol

My apologies. It's just interesting to me that blockchain is full of physicists.

Thinkers like thinking.

[citation needed]

-___-

lol

sarang am I right in thinking that the output private key doesn't leave the hwdevice?

Doing so would be equivalent to leaking the wallet spendkey, as per out prior conversation

our*

sarang say I was doing a ring signature in accordance with cryptonote.org/whitepaper.pdf at the bottom of page 9, and i never disclose x

What is the minimum amount of other information, if intercepted, that could help a third party calculate x?

say they somehow got all variables used right at the bottom for the various c_i and r_i

apart from x. Could they compute x

q_s - c_s*x = r I guess so right? (r-q)/c_s ?

well there is a modulus involved so it changes things slightly

Going to sleep will think about this tomorrow morning

my chat might be deleted too lol so i will ask again tomorrow.