From 10c7360ba1d2fe8370fc2c3c9247ee9a621eef8c Mon Sep 17 00:00:00 2001 From: Chris Beck Date: Mon, 14 Mar 2022 12:16:20 -0600 Subject: [PATCH 1/9] Standardized sender signature --- text/0030-standardized-sender-sig.md | 137 +++++++++++++++++++++++++++ 1 file changed, 137 insertions(+) create mode 100644 text/0030-standardized-sender-sig.md diff --git a/text/0030-standardized-sender-sig.md b/text/0030-standardized-sender-sig.md new file mode 100644 index 00000000..b8a98ab0 --- /dev/null +++ b/text/0030-standardized-sender-sig.md @@ -0,0 +1,137 @@ +- Feature Name: Standardized Sender Signature +- Start Date: 2022-03-14 +- MCIP PR: [mobilecoinfoundation/mcips#0030](https://github.com/mobilecoinfoundation/mcips/pull/0030) +- MobileCoin Epic: None + +# Summary +[summary]: #summary + +Enact MCIP #18 (Janus Mitigation), which sets the ephemeral key in the encrypted fog hint +to be the tx private key times the Ristretto base point. The original motivation was to enact +Janus attack mitigation. + +We find a secondary use-case to motivate this: it becomes possible for the signer to create +a Schnorr signature over any payload, which a verifier can validate against the keys appearing +in a `TxOut`, without revealing the identity of the signer. We propose to both do #18 and standardize +the construction and validation of this signature. + +# Motivation +[motivation]: #motivation + +Often in a payments flow, it is necessary for the sender and recipient to exchange additional messages +and metadata about the payment. Frequently, these messages need to be authenticated. + +We have a mechanism for doing this in the memo field, which attaches fixed-size payloads to TxOut's. +However, this imposes fairly strict size requirements on the data that can be sent. + +Outside of the memo field, we have a notion of "receipts" and "confirmation numbers" which a sender +can use to identify themselves to a recipient. These are hashes of the TxOut shared secret, which +are similarly deniable, and convince the recipient that whoever sent them this number must have access +to secrets involved in the construction of the TxOut. + +However, these numbers are useless for convincing a third-party who is not a party to the transaction, +because only the recipient is able to validate these numbers. There is currently no form of receipt that +can be validated just from the blockchain. + +This is desirable by some app project developers, who would like to store encrypted metadata per TxOut, +but off-chain. For example, they might like to have a database of encrypted metadata, keyed on TxOut's sent +by users of their app, and be able to ensure that only the true sender of the TxOut can post metadata associated +to the TxOut, without learning anything about the sender, recipient, amount, etc. of the TxOut. + +After this proposal, a straightforward way to do this is that their app can sign the encrypted metadata using +the tx private key, and their server can check this signature against the public key in the encrypted fog hint. +We can simply use the Schnorrkel-based signature with Ristretto curve points that we already use in fog public addresses. + +This might also be useful because it makes the notion of receipts somewhat more robust -- arbitrary metadata +can be signed by the sender, and this form of signature will not have the deniability property. + +# Guide-level explanation +[guide-level-explanation]: #guide-level-explanation + +This MCIP will: + +* Make it possible for the builder of a transaction output to additionally sign a blob + using the tx private key. +* Make it possible for anyone to validate that signature against the TxOut, without + knowing the identity of the sender. + +# Reference-level explanation +[Reference-level-explanation]: #reference-level-explanation + +We propose to + +* Make internal changes to the transaction builder, following MCIP #18 + * Instead of being a second independent random private key, the private key used + for `mc-crypto-box` encryption will be the same as the tx private key for that + `TxOut`. + * Also, implement code for a "Janus test" which enables clients to detect the + Janus attack, as described in MCIP #18. +* Standardize a Schnorrkel-based signature using Ristretto curve points, made using the tx private key, + and validated using the ephemeral key in the fog hint. This entails: + * Make the transaction builder either optionally return the tx private key when `add_output` is called, + or, you may optionally pass it a blob to be signed, and it produces the signature and then deletes the + private key. That creates a constraint that the blob must be available to sign at the time of constructing + the TxOut, which may or may not be acceptable. +* Standardize validation code that validates a blob and its signature against a TxOut. + +# Prior art +[prior-art]: #prior-art + +This proposal touches on some earlier MCIPS: + +* [0004-Recoverable-Transaction-History](https://github.com/mobilecoinfoundation/mcips/pull/0004) +* [0018-Janus-attack-mitigation](https://github.com/mobilecoinfoundation/mcips/pull/0018) + +Outside of MobileCoin, there are many blockchain projects that want to store chain-related data off-chain. + +Popular strategies include: +* Embed hash of the stored data into the transaction +* Use a layer 2 rollup + +This signature approach gives us a third possibility, which is relatively simple to implement, +where we store off-chain data with a signature which ties it back to the chain, +and don't have to embed a hash into the main chain. + +That has several advantages: +* Adding a hash to the transaction bloats the chain, and requires a ledger format change. +* More composable. If we want to have multiple off-chain data stores, we cannot have multiple hashes + because TxOut's must be fixed-size. We could have a little hash tree (so, a hash of hashes), but this + requires that all the different off-chain data stores know about eachother in order to validate the + data, which adds a lot of complexity to each one. By relying instead on signatures from the sender, + off-chain data stores can all be fully independent. + +# Rationale and alternatives +[rationale-and-alternatives]: #rationale-and-alternatives + +An alternative worth discussing is: + +* Don't implement MCIP #18, don't make the ephemeral private key from the fog hint + the same as the tx private key. Just make that private key available to form + digital signatures with. + +This meets the motivation of this MCIP, but since this takes us almost all the way +to MCIP #18, we think we should do MCIP #18 also, since it is valuable to mitigate +Janus attacks and that MCIP is well-studied. It costs us almost nothing to start +building transactions in the way described there, and at some point, flip the switch +on clients actually flagging Janus test failures as suspicious. + +We do not believe right now that there is a simpler way to create this signature, +as the signer does not know the root of the `public_key` or `target_key` of `TxOut`'s +relative to the ristretto basepoint. The signer does know the root relative to some of +the public subaddress keys of the recipient, but such a signature cannot be verified +by someone who does not know who the recipient. + +The modification from MCIP #18 seems to be the simplest change we can make that makes +a signature like this possible, and that modification already has good motivations. + +# Unresolved questions +[unresolved-questions]: #unresolved-questions + +None at this time. + +# Future possibilities +[future-possibilities]: #future-possibilities + +It seems likely that we could find other use-cases for this digital signature scheme, +for example, to be able to create receipts that don't have the deniability property, +and which sign additional metadata. From fa67dad2973dba1235e1e6b0d40cb6c4ba165854 Mon Sep 17 00:00:00 2001 From: Chris Beck Date: Mon, 14 Mar 2022 12:24:08 -0600 Subject: [PATCH 2/9] clarify a sentence --- text/0030-standardized-sender-sig.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0030-standardized-sender-sig.md b/text/0030-standardized-sender-sig.md index b8a98ab0..0c49ebaf 100644 --- a/text/0030-standardized-sender-sig.md +++ b/text/0030-standardized-sender-sig.md @@ -31,7 +31,7 @@ to secrets involved in the construction of the TxOut. However, these numbers are useless for convincing a third-party who is not a party to the transaction, because only the recipient is able to validate these numbers. There is currently no form of receipt that -can be validated just from the blockchain. +can be validated by anyone, just from the blockchain. This is desirable by some app project developers, who would like to store encrypted metadata per TxOut, but off-chain. For example, they might like to have a database of encrypted metadata, keyed on TxOut's sent From 6ad8dea795e65a5fd8359da1bf157562a2583555 Mon Sep 17 00:00:00 2001 From: Chris Beck Date: Mon, 14 Mar 2022 12:37:32 -0600 Subject: [PATCH 3/9] Update text/0030-standardized-sender-sig.md Co-authored-by: sugargoat --- text/0030-standardized-sender-sig.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0030-standardized-sender-sig.md b/text/0030-standardized-sender-sig.md index 0c49ebaf..01ca8cd9 100644 --- a/text/0030-standardized-sender-sig.md +++ b/text/0030-standardized-sender-sig.md @@ -119,7 +119,7 @@ We do not believe right now that there is a simpler way to create this signature as the signer does not know the root of the `public_key` or `target_key` of `TxOut`'s relative to the ristretto basepoint. The signer does know the root relative to some of the public subaddress keys of the recipient, but such a signature cannot be verified -by someone who does not know who the recipient. +by someone who does not know who the recipient is. The modification from MCIP #18 seems to be the simplest change we can make that makes a signature like this possible, and that modification already has good motivations. From 0b21dedfebe6aa0ed5f706ac6c2771ebe50001a6 Mon Sep 17 00:00:00 2001 From: Chris Beck Date: Mon, 14 Mar 2022 12:46:39 -0600 Subject: [PATCH 4/9] adjust sentence about limitations of current receipts --- text/0030-standardized-sender-sig.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/text/0030-standardized-sender-sig.md b/text/0030-standardized-sender-sig.md index 01ca8cd9..b39cd3d6 100644 --- a/text/0030-standardized-sender-sig.md +++ b/text/0030-standardized-sender-sig.md @@ -29,9 +29,10 @@ can use to identify themselves to a recipient. These are hashes of the TxOut sha are similarly deniable, and convince the recipient that whoever sent them this number must have access to secrets involved in the construction of the TxOut. -However, these numbers are useless for convincing a third-party who is not a party to the transaction, -because only the recipient is able to validate these numbers. There is currently no form of receipt that -can be validated by anyone, just from the blockchain. +However, these numbers are not useful for convincing a third-party who is not a party to the transaction, +because only the recipient is able to validate these numbers. The recipient could give their private keys +away to a third party, but this entails giving up their privacy. There is currently no form of receipt that +can be validated by anyone, just from the blockchain, without such measures. This is desirable by some app project developers, who would like to store encrypted metadata per TxOut, but off-chain. For example, they might like to have a database of encrypted metadata, keyed on TxOut's sent From 25ec8a03ca3427381b86e5a5d88b3885d8254265 Mon Sep 17 00:00:00 2001 From: Chris Beck Date: Mon, 14 Mar 2022 12:57:41 -0600 Subject: [PATCH 5/9] add more comments about deniability --- text/0030-standardized-sender-sig.md | 25 +++++++++++++++++++------ 1 file changed, 19 insertions(+), 6 deletions(-) diff --git a/text/0030-standardized-sender-sig.md b/text/0030-standardized-sender-sig.md index b39cd3d6..38f8e617 100644 --- a/text/0030-standardized-sender-sig.md +++ b/text/0030-standardized-sender-sig.md @@ -26,13 +26,15 @@ However, this imposes fairly strict size requirements on the data that can be se Outside of the memo field, we have a notion of "receipts" and "confirmation numbers" which a sender can use to identify themselves to a recipient. These are hashes of the TxOut shared secret, which -are similarly deniable, and convince the recipient that whoever sent them this number must have access -to secrets involved in the construction of the TxOut. +convince the recipient that whoever sent them this number must have access to secrets involved in the +construction of the TxOut. These receipts have a "deniability" property also shared by signal messages. +This arises because they are based on the TxOut shared secret, which can be formed by the sender OR the recipient. -However, these numbers are not useful for convincing a third-party who is not a party to the transaction, -because only the recipient is able to validate these numbers. The recipient could give their private keys -away to a third party, but this entails giving up their privacy. There is currently no form of receipt that -can be validated by anyone, just from the blockchain, without such measures. +However, these confirmation numbers are not useful for convincing a third-party who is not a party to the transaction +that a particular person sent the transaction, because only the transaction recipient is able to validate these numbers. +The recipient could give their private keys away to a third party, but this entails giving up their privacy. Even then, +because of the deniability property, this still only convinces the third party that one of two people sent the Tx. +There is currently no form of receipt that can be validated by anyone, just from the blockchain. This is desirable by some app project developers, who would like to store encrypted metadata per TxOut, but off-chain. For example, they might like to have a database of encrypted metadata, keyed on TxOut's sent @@ -78,6 +80,17 @@ We propose to # Prior art [prior-art]: #prior-art +To recap on the deniability property: + +* Deniable authentication means that, when the sender "signs" a message, the signature is made by a key exchange with the recipient. + * This means that both the sender AND the recipient are technically capable of producing the signature. + * The recipient who sees the signature, and knows they didn't produce the signature, concludes the sender must have sent it. + * However, the recipient cannot convince another person that they did not forge the signature. + * As a result, if the recipient shows the message to a third party (to embarrass the sender), the sender can deny having written + the message, and claim that the recipient made the whole thing up. +* A [good intro](https://www.praetorian.com/blog/an-opinionated-series-on-why-signal-protocol-is-well-designed-deniability/) +* A (technical) Signal blog post on the topic: https://signal.org/blog/simplifying-otr-deniability/ + This proposal touches on some earlier MCIPS: * [0004-Recoverable-Transaction-History](https://github.com/mobilecoinfoundation/mcips/pull/0004) From ea33ea7558a011484154bee73f1ab56a296982b9 Mon Sep 17 00:00:00 2001 From: Chris Beck Date: Mon, 14 Mar 2022 13:12:37 -0600 Subject: [PATCH 6/9] more comments about deniability --- text/0030-standardized-sender-sig.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/text/0030-standardized-sender-sig.md b/text/0030-standardized-sender-sig.md index 38f8e617..b220b3dd 100644 --- a/text/0030-standardized-sender-sig.md +++ b/text/0030-standardized-sender-sig.md @@ -27,8 +27,9 @@ However, this imposes fairly strict size requirements on the data that can be se Outside of the memo field, we have a notion of "receipts" and "confirmation numbers" which a sender can use to identify themselves to a recipient. These are hashes of the TxOut shared secret, which convince the recipient that whoever sent them this number must have access to secrets involved in the -construction of the TxOut. These receipts have a "deniability" property also shared by signal messages. +construction of the TxOut. These confirmation numbers have a "deniability" property also shared by signal messages. This arises because they are based on the TxOut shared secret, which can be formed by the sender OR the recipient. +(For more discussion, see the prior art section.) However, these confirmation numbers are not useful for convincing a third-party who is not a party to the transaction that a particular person sent the transaction, because only the transaction recipient is able to validate these numbers. @@ -47,6 +48,7 @@ We can simply use the Schnorrkel-based signature with Ristretto curve points tha This might also be useful because it makes the notion of receipts somewhat more robust -- arbitrary metadata can be signed by the sender, and this form of signature will not have the deniability property. +This happens because it is a traditional digital signature, based on a key that only the sender has. # Guide-level explanation [guide-level-explanation]: #guide-level-explanation From 645a0d41d5581604d73e9fc77dbe702ff7b91581 Mon Sep 17 00:00:00 2001 From: Chris Beck Date: Mon, 14 Mar 2022 13:16:44 -0600 Subject: [PATCH 7/9] cleanup some text about the transaction builder changes --- text/0030-standardized-sender-sig.md | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/text/0030-standardized-sender-sig.md b/text/0030-standardized-sender-sig.md index b220b3dd..856eaba6 100644 --- a/text/0030-standardized-sender-sig.md +++ b/text/0030-standardized-sender-sig.md @@ -72,11 +72,18 @@ We propose to * Also, implement code for a "Janus test" which enables clients to detect the Janus attack, as described in MCIP #18. * Standardize a Schnorrkel-based signature using Ristretto curve points, made using the tx private key, - and validated using the ephemeral key in the fog hint. This entails: - * Make the transaction builder either optionally return the tx private key when `add_output` is called, - or, you may optionally pass it a blob to be signed, and it produces the signature and then deletes the - private key. That creates a constraint that the blob must be available to sign at the time of constructing - the TxOut, which may or may not be acceptable. + and validated using the ephemeral key in the fog hint. This entails (one of): + * Make the transaction builder take a blob to be signed when `add_output` is called. + `add_output` produces the signature as an additoinal return value. + * Make the transaction builder return a "signing context" when `add_output` is called. + This contains the tx private key and can be used to later sign any number of blobs. + This object zeroizes the tx private key when it goes out of scope. + * The idea is, perhaps some of the data that needs to be signed needs to be obtained + from an endpoint, but the app would rather not wait for that call to return before + submitting the transaction. This way, the app could build and submit a transaction + in parallel with obtaining some of the data to be signed, and pipeline calls, + potentially reducing end to end transaction times. Since it's just a thought experiment, + we don't know if it would matter in a real app. * Standardize validation code that validates a blob and its signature against a TxOut. # Prior art From 6797d0d57446552aec599f2195d28e568289b83d Mon Sep 17 00:00:00 2001 From: Chris Beck Date: Mon, 14 Mar 2022 13:41:05 -0600 Subject: [PATCH 8/9] clarify comments about deniability and confirmation numbers --- text/0030-standardized-sender-sig.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/text/0030-standardized-sender-sig.md b/text/0030-standardized-sender-sig.md index 856eaba6..c6f6b1fd 100644 --- a/text/0030-standardized-sender-sig.md +++ b/text/0030-standardized-sender-sig.md @@ -33,8 +33,9 @@ This arises because they are based on the TxOut shared secret, which can be form However, these confirmation numbers are not useful for convincing a third-party who is not a party to the transaction that a particular person sent the transaction, because only the transaction recipient is able to validate these numbers. -The recipient could give their private keys away to a third party, but this entails giving up their privacy. Even then, -because of the deniability property, this still only convinces the third party that one of two people sent the Tx. +Even if the recipient gives away their private keys to a third party, this still doesn't work, because the confirmation +numbers have the deniability property, and the recipient could say that anyone had sent them the confirmation number. +(The hmac appearing in the memos in MCIP #4 couldn't have been created by anyone, but could have been created by the recipient.) There is currently no form of receipt that can be validated by anyone, just from the blockchain. This is desirable by some app project developers, who would like to store encrypted metadata per TxOut, From e9a1f698616bb94108b71788c77578a083ef80cd Mon Sep 17 00:00:00 2001 From: Chris Beck Date: Mon, 14 Mar 2022 13:52:41 -0600 Subject: [PATCH 9/9] add a sentence in prior art --- text/0030-standardized-sender-sig.md | 1 + 1 file changed, 1 insertion(+) diff --git a/text/0030-standardized-sender-sig.md b/text/0030-standardized-sender-sig.md index c6f6b1fd..6a611038 100644 --- a/text/0030-standardized-sender-sig.md +++ b/text/0030-standardized-sender-sig.md @@ -107,6 +107,7 @@ This proposal touches on some earlier MCIPS: * [0018-Janus-attack-mitigation](https://github.com/mobilecoinfoundation/mcips/pull/0018) Outside of MobileCoin, there are many blockchain projects that want to store chain-related data off-chain. +This is often motivated by scaling considerations. Popular strategies include: * Embed hash of the stored data into the transaction