Standardized sender signature

[cbeck88]

A proposal for a standardized signature for the sender of a TxOut, who may otherwise be anonymous.

Rendered Proposal

[sugargoat]

Is this an observation about the current state of things, or an indication that this MCIP solves this problem? My understanding is that this MCIP doesn't propose to have on-chain receipts that can be validated by anyone, but that the off-chain store could be, is that correct?

[cbeck88]

its not that the receipt lives on chain, but it's that:

• I can prove to you that I sent a particular Tx
• You don't have to even be the recipient of that Tx, and you can validated my proof just from the chain.

The receipts we have only work if you are the recipient of the Tx

[sugargoat]

LGTM!

[jcape]

I'd like to get #18 fixed up and merged first, this would simply this MCIP and resolve the major issue: you can't implement this without directly referencing an MCIP that was never accepted.

Alternatively, the contents of #18 can get merged into this one.

[mfaulk]

To make sure I'm following this: the public key that a sender would sign against is in the encrypted fog hint, so only the recipient's fog server can obtain this key and use it to verify messages signed with it? That doesn't sound right.

[cbeck88]

so, the way that mc-crypto-box works is:

• I get your public key (a Ristretto curve point)
• I choose a random scalar (private fog key, r_fog in Koe's notation in Mechanics of Mobilecoin)
• I do key exchange against your public key and r_fog, and I put r_fog * G as the first 32 bytes of the e_fog_hint.
• I use the key resulting from key exchange to encrypt and mac my payload
• I append 2 versioning bytes.

The recipient is getting those first 32 bytes, making a public key, and doing key exchange using their private key to recover the shared secret, decrypt and check the mac.

So the private key that a sender would sign against is r_fog (which now equals tx_private_key), and the signature can be validated against the public key r_fog * G, which is the first 32 bytes of fog hint.

Koe proposed that instead of having two independent random keys r and r_fog, we should just set r_fog = r, and this enables a Janus mitigation test, without really impacting fog since the r number is a perfectly fine secret key, just as good as r_fog anyways.

So this breaks some encapsulation that's separating the e_fog_hint field from the rest of the Tx math. But, it serves several useful purposes, and it's not that big a deal from the point of cryptobox / fog.

[mfaulk]

Thanks, that makes sense

[mfaulk]

We haven't merged MCIP 18, and it doesn't look like anyone has reviewed it yet. I think that needs to be reviewed and merged before we build on it. For example, I'm having a hard time finding the "fog hint ephemeral key" in the source, so it's hard for me to evaluate what's going on here.

[cbeck88]

For sure, we should definitely review that MCIP and merge it separately if we want to accept this MCIP, IMO

[mfaulk]

I'm wondering if the simplest thing to do here is to add a 'sender_signing_key' field to TxOut, which is a unique public key that is unrelated to tx_out.target_key and tx_out.public_key, and is unrelated to the fog hint. I know that would increase the size of the TxOut, but does that size increase really matter? On the flipside, it becomes extremely simple to say "this is the key that a sender should sign related data with", and anyone with access to the ledger can validate such signatures.

[cbeck88]

I'm wondering if the simplest thing to do here is to add a 'sender_signing_key' field to TxOut, which is a unique public key that is unrelated to tx_out.target_key and tx_out.public_key, and is unrelated to the fog hint. I know that would increase the size of the TxOut, but does that size increase really matter?

It matters in that, it is a ledger format change, and an enclave change, and so would require a long turn-around time to ship.

It is certainly simpler conceptually to just add a new dedicated key field, but I'm not sure it's simpler taking into account the complexity of ledger format changes.

[NotGyro]

This feels somewhat out of my depth, so this is probably a stupid question, but would the bytes signed include the memo field? I could see that being very useful.

[cbeck88]

This feels somewhat out of my depth, so this is probably a stupid question, but would the bytes signed include the memo field? I could see that being very useful.

This signature is mainly about, taking bytes and binding them to "whoever sent that Txout" without revealing who it is.

The memo field is already set by that person and it's bound to the TxOut by the blockchain hash, so if I'm understanding right I think signing those bytes would be redundant.

But, part of the point of this is to allow signing "additional" memo-like bytes for use in other contexts that don't have to appear on the chain.