Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MCIP Draft - View Authenticated Sender Memo #58

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

MCIP Draft - View Authenticated Sender Memo #58

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
739537d
View Authenticate Sender Memo (#54)
briancorbin Nov 9, 2022
9e49dc7
updating PR number
briancorbin Nov 9, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
46 changes: 46 additions & 0 deletions text/0058-view-authenticated-sender-memos.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,46 @@
- Feature Name: `View Authenticate Sender Memo`
- Start Date: `2022-11-09`
- MCIP PR: [mobilecoinfoundation/mcips#0058](https://github.com/mobilecoinfoundation/mcips/pull/58)

# Summary
[summary]: #summary

[#4 Recoverable Transaction History (RTH)](https://github.com/mobilecoinfoundation/mcips/pull/4) introduced three different memo types for [encrypted memos](https://github.com/mobilecoinfoundation/mcips/pull/3). This proposal specifies three more memo types:

- View Authenticated Sender
- View Authenticated Sender With Payment Request Id Memo
- View Authenticated Sender With Payment Intent Id Memo

This feature aims to extend the SenderMemo to allow for senders to use their subaddress view private keys to generate Authenticated Sender Memos

# Motivation
[motivation]: #motivation

With the introduction of the ViewAccountKey and UnsignedTransactions, generating a SenderMemo for RTH became impossible because of the requirement of the Subaddress Spend Private Key during the creation of the TxOuts for the transaction.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it's actually impossible now, we have a plan here: mobilecoinfoundation/mobilecoin#2585

The idea is to refactor the MemoBuilder object implementation that currently requires the spend key to make it more abstract, and allow that to be a hardware device connection instead.

The only one who is impacted here is Copper's multiparty compute flow.


# Guide-level explanation
[guide-level-explanation]: #guide-level-explanation

In a scenario where a user is building an unsigned transaction with a view account, instead of using SenderMemoCredential to generate an AuthenticatedSenderMemo (since this requires the subaddress spend private key which is unavailable), the user will use the subaddress view private key (which is available) to generate a SenderViewMemoCredential, used to create a ViewAuthenticatedSenderMemo.

# Drawbacks
[drawbacks]: #drawbacks

This may potentially reduce the security of the SenderMemo by requiring the view private key (which would potentially be available on an online machine) instead of the spend private key (which is only contained on an offline machine of hardware wallet). If the view private key were to ever be compromised, then the attacker could authenticate their payments using the ViewAuthenticatedSenderMemo of the compromised party, making it appear as if their sent transaction came from the compromised user.

# Rationale and alternatives
[rationale-and-alternatives]: #rationale-and-alternatives

An alternative would be to generate the SenderMemoCredential during signing and modify the TxOut during the signing process. This would require more discovery as it is uncertain if this is possible without regenerating all of the contents of the TxOut and TxPrefix, which may not be desireable (especially if signing using a hardware wallet).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We currently have designed the hardware wallets stuff to have one round where it computes memo hmacs for these sender memos (using the spend private key), and then a second round where it actually signs ring mlsags.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If copper really wants us to provide just one payload, and they would have a round where they do memo signing and then another round where they do transaction signing, and those two rounds happen in their application, that seems like it should be possible, it will just make the UnsignedTx object a lot messier.


The rationale for adding the ViewAuthenticateSenderMemo is that it allows users to utilize RTH with an offline transaction signer or hardware wallet.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The other main alternative is, do nothing. Then, RTH cannot be used with Copper (at least, the authenticated sender memos cannot be).

This may be acceptable -- after all, we did not prioritize making RTH work with mobilecoind, and I'm not sure it works with full-service right now? You would have to tell me.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It works with full service


# Unresolved questions
[unresolved-questions]: #unresolved-questions

> - Is it possible to modify just the encrypted memo portion of a TxOut without requiring the TxPrefix and OutputSecrets to be regenerated?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The TxPrefix would change, but the output secrets would not.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, then that might actually be a plausible solution for offline transaction signing


# Future possibilities
[future-possibilities]: #future-possibilities

None at this time