search

monero-project / research-lab

A general repo for Monero Research Lab work in progress and completed work
238 stars 77 forks source link

Seraphis Address Schemes #92

Open UkoeHB opened 2 years ago

UkoeHB commented 2 years ago

Seraphis Address Schemes

Seraphis is not compatible with CryptoNote addressing, due to a different key image design compared to CryptoNote. However, it is compatible with a variety of interesting addressing schemes. In this issue I'd like to present those schemes, so discussion can have a point of reference.

To implement Seraphis in Monero, or another existing CryptoNote-derived cryptocurrency, it would be necessary for all users to generate new public addresses from their private keys (old public addresses would become unusable). They would not need new wallets, just addresses.

The Schemes

Here are the adddress scheme variants. The 'tiers' are levels of wallet permissions. A Tier 3 wallet can always do everything, while a Tier 2 wallet can never spend funds. A 3-key address would be ~50% longer than existing addresses. Note that 'Janus' refers to the ability to detect a Janus attack.

   Type    Tier 1 Tier 2 (+ Tier 1) Tier 3 (+ Tiers 1 & 2) Address Size (#keys)
Plain A none view received spend, view spent 2
Plain B view received view spent spend 2
Plain C none view received, view spent spend 2
Plain D compute view tags view received, view spent spend 3
Janus A view received, Janus view spent spend 3
Janus B view received (no amounts) view amounts, view spent, Janus spend 3
Janus C view received (no amounts), view spent view amounts, Janus spend 3
Janus D none view received, view spent, Janus spend 3
Janus E compute view tags view received, view spent, Janus spend 4

Finally, I want to point out that Tier 2 always (except for Plain A) has 'full-view' authority. The main difference between schemes lies in Tier 1 capabilities.

P.S.

Moving to a new address scheme means it is possible to deprecate normal addresses entirely (i.e. only use subaddresses). This would allow a uniform address format, which would improve UX. Users could use their 'index 0' subaddress in place of their current normal address (or some similar convention).

Deprecating normal addresses is not required, it is just an option to consider.

LocalMonero commented 2 years ago

Unifying to just one type of address should be a design goal. The UX and DX gets exponentially worse with each additional address type.

rbrunner7 commented 2 years ago

Regarding Janus, do I read this correctly: The question is whether we judge the Janus attack to be serious enough to merit even longer addresses than today, as a sensible choice?

UkoeHB commented 2 years ago

Regarding Janus, do I read this correctly: The question is whether we judge the Janus attack to be serious enough to merit even longer addresses than today, as a sensible choice?

Yes, but part of the question is also if we want one of the Janus address schemes, due to their basic utility compared to plain schemes (I think Janus B and C are big improvements, since they allow third party scanning without leaking amounts).

rbrunner7 commented 2 years ago

Yes, but part of the question is also if we want one of the Janus address schemes, due to their basic utility compared to plain schemes (I think Janus B and C are big improvements, since they allow third party scanning without leaking amounts).

Thanks, I indeed overlooked the "amounts visible or hidden" dimension until now. Interesting.

boogerlad commented 2 years ago

For Janus C Tier 1, "view received (no amounts), view spent" does that mean spent amounts are visible?

UkoeHB commented 2 years ago

For Janus C Tier 1, "view received (no amounts), view spent" does that mean spent amounts are visible?

No... view spent just means 'view what outputs have been spent' (i.e. compute key images for received outputs to check if they exist in the ledger).

boogerlad commented 2 years ago

As you said, Janus B and C allow for third party scanning without leaking amounts, which I think makes services like MyMonero way more useful. What would the UX differences be between B and C? As in, in what situation would it be useful for services like MyMonero to know which outputs are spent and presumably when they are spent?

UkoeHB commented 2 years ago

What would the UX differences be between B and C? As in, in what situation would it be useful for services like MyMonero to know which outputs are spent and presumably when they are spent?

If a scanning service can identify spent outputs, then your personal wallet doesn't have to do any scanning. However, this has privacy costs, since the service will learn more information about your transaction flows (i.e. if the service became large enough, then it could basically eliminate the utility of ring signatures).

UkoeHB commented 2 years ago

If a scanning service can identify spent outputs, then your personal wallet doesn't have to do any scanning. However, this has privacy costs, since the service will learn more information about your transaction flows (i.e. if the service became large enough, then it could basically eliminate the utility of ring signatures).

On the other hand (I forgot...), a scanning service that can see all your received outputs can also infer most/all of your spent outputs. The reason is, most/all of the transactions you make will A) have 1+ of your owned outputs in each input's ring members, B) send a change output to you.

Since a scanning service can identify most spent outputs, Janus C might be simply better than Janus B. With Janus B, identifying spent outputs with Tier 1 is not reliable enough to be provided as a feature of a scanning service, but it is reliable enough to degrade privacy. With Janus C, the UX of scanning improves, while the privacy costs stay the same.

Caveat: If membership proofs referenced the entire ledger, instead of a small ring, then inferring spent outputs would not work as well (if at all). Since achieving membership proofs on that level is a big goal of privacy-coin research, a 'forward-looking' designer might favor Janus B over Janus C. This way, if ideal membership proofs are ever implemented, the privacy dynamic around scanning is optimized.

tevador commented 2 years ago

I haven't studied Seraphis in detail, but I'm wondering if there could also be another option:

Type     Tier 1 Tier 2 (+ Tier 1) Tier 3 (+ Tiers 1 & 2) Address Size (#keys)
Plain D/Janus E view tag view received, view spent, Janus(?) spend 3

A Tier 1 wallet would only be able to identify a 2-T blockchain subset that contains all of the wallet's actual outputs (here T is the size of the view tag in bits). This would preserve more privacy when using an external scanning service at the cost of more computation for the client to filter out the false positive outputs. The size of the view tag T should be selected as a compromise between privacy and the amount of data to be downloaded.

I put a question mark next to Janus because I'm not sure if this scheme can also mitigate Janus without some additional TX data.

UkoeHB commented 2 years ago

@tevador yes I think it is possible. I will add this to the table. It would cost +1 in the address size compared to other schemes.

chaserene commented 2 years ago

Is it possible to devise an addresses scheme that won't have to be changed for a long time, e.g. not even with further ring size increases like Arcturus? Requiring everyone who wants to receive to generate a new address is a big pain point, breaking numerous use cases, both known and unknown.

UkoeHB commented 2 years ago

Is it possible to devise an addresses scheme that won't have to be changed for a long time, e.g. not even with further ring size increases like Arcturus? Requiring everyone who wants to receive to generate a new address is a big pain point, breaking numerous use cases, both known and unknown.

Why would any of the above schemes need to be changed, once implemented?

chaserene commented 2 years ago

@UkoeHB I don't know in advance. I'm following the logic that van Saberhagen didn't expect it either that it will need to be changed.

UkoeHB commented 2 years ago

@UkoeHB I don't know in advance. I'm following the logic that van Saberhagen didn't expect it either that it will need to be changed.

Likewise, there is no way for any of us to know in advance what the future will bring.

That being said, Seraphis is designed so membership proofs (e.g. ring signatures) are almost entirely independent of addressing. You can easily change the membership proof type without risking changes to the address scheme. In that sense, Seraphis is far more robust against address changes than CryptoNote.

xxmeta commented 2 years ago

I think Janus detection should be a priority.

I am leery of enabling 3rd party scanning, as with Janus B & C. 99% of people will allow 3rd party services to scan their entire wallets. The rest of us will not have much anon set, and no way to know if our anon set is any good.

I lean towards Janus A.

UkoeHB commented 2 years ago

I am leery of enabling 3rd party scanning, as with Janus B & C. 99% of people will allow 3rd party services to scan their entire wallets. The rest of us will not have much anon set, and no way to know if our anon set is any good.

@xxmeta I think it is unlikely we can prevent people from offering scanning services without completely unifying all three wallet tiers. Why do you favor Janus A over Janus B/C? Janus B's Tier 1 is significantly weaker than Janus A's Tier 1, and I think Tier 1 is what scanning services would use.

xxmeta commented 2 years ago

I am leery of enabling 3rd party scanning, as with Janus B & C. 99% of people will allow 3rd party services to scan their entire wallets. The rest of us will not have much anon set, and no way to know if our anon set is any good.

@xxmeta I think it is unlikely we can prevent people from offering scanning services without completely unifying all three wallet tiers. Why do you favor Janus A over Janus B/C? Janus B's Tier 1 is significantly weaker than Janus A's Tier 1, and I think Tier 1 is what scanning services would use.

I agree with you now about the 3rd party service risk. In light of that, Janus A & B are similar to me. I think the Janus attack can still be practically applied if users use a Tier1 key for fast sync times, so maybe I prefer Janus A for that reason, but the choice is not obvious.

Janus C is less useful I think. I can see many uses for a Tier 1 key that can't view spends, but Janus C doesn't allow that.

r4v3r23 commented 2 years ago

@UkoeHB continuing the offline-tx discussion from gitlab:

so Serpahis view-only wallets would eliminate the need to import key images and cut the process down to 3 steps?

1) create transaction on view-only wallet

2) sign tx on offline device

3) broadcast signed tx from online device

UkoeHB commented 2 years ago

@r4v3r23 yes that sounds right to me. 1 -> 2 and 2 -> 3 require communication passes to and then from the offline device.

r4v3r23 commented 2 years ago

@r4v3r23 yes that sounds right to me. 1 -> 2 and 2 -> 3 require communication passes to and then from the offline device.

yes Seraphis simplifies the process so that it can be done easily between mobile devices via QR codes

tevador commented 2 years ago

There is no doubt that Seraphis will bring quite large user-facing changes regardless of which exact addressing scheme is used. It may be worthwhile to take this opportunity to rethink the paradigm and move away from addresses completely.

I understand that this might be too radical and it's unlikely to be implemented in Monero, but I'm going to discribe it anyways in case someone cares.

I will preface this with an explaination why addresses are bad, then I will present an alternative and describe how it works from the user's point of view. The cryptographic details are at the end.

The original vision

Satoshi Nakamoto originally thought of addresses as "account numbers" and they were meant to be handled and compared by humans directly (see this comment in Bitcoin 0.1). This was also the reason why Bitcoin addresses were 160-bit hashes - to be as short as possible. A typical v1 Bitcoin address is 34 characters long, which is coincidentally the maximum length an IBAN can have.

Problems of addresses

Nowadays cryptocurrencies are not used just by enthusiasts and the inherited paradigm of base58-encoded account numbers is, in my opinion, a UX nightmare. Especially for Monero, the original vision clearly fails. 100+ character strings encoding 2-3 public keys can hardly be considered as identifiers anymore.

I'd wager that the vast majority of crypto transfers involve copy pasting meaningless strings without any feedback to the user. The main issues of this are:

  1. Security. Using humans to verify and pass around cryptographic material is just about the worst option. One of the common attacks involves clipboard address swapping malware.
  2. Susceptibility to mistakes. People send funds to the wrong address all the time. This is also the primary reason why integrated addresses are still popular and many people are against deprecating them.

  3. Addresses lack context. From a UX standpoint, the public keys only make sense when bundled with an amount, a human-readable name an a reason to pay. The terms "address" and "address book" imply that they are some sort of identifiers, which is wrong. Addresses are meant for a single use.

    OpenAlias is not the answer

    Someone might argue that OpenAlias is a working alternative to addresses. However, I don't think it can solve the problem for several reasons:

Possible solution

Everytime a Monero address is shared, there is an implicit expectation of a payment. It may either be a donation without a specific amount and specific sender, or an exact amount as a payment for goods or services. The payee is clearly defined in both cases.

Therefore we can replace addresses with payment requests. A payment request encapsulates all the information the payer's software needs to complete the payment:

  1. Version field
  2. One or more public keys
  3. Payment amount (optional)
  4. The recipient's email address or domain name (optional)
  5. Payment description (optional)
  6. Signature of the above fields with a key tied to the recipient's identity

The main difference from the existing Monero payment url scheme is that each payment request is authenticated with a signature.

The way a payment request is transferred to the wallet software can be entirely opaque to the user. There is no need to examine or compare any cryptographic information (with a single exception described in the next section).

Here are some ways how the actual data transfer can happen:

  1. Scanning a QR code
  2. Clicking a URL with a custom scheme handler
  3. Direct HTTP request
  4. Manually copying an ASCII-armored string (for text-only protocols)
  5. Manually downloading a file from a website/email attachment

All of these can easily support transferring a few hundred bytes needed for a payment request.

Authenticating the recipient

Once the payment request reaches the payer's wallet software, there are 4 options:

  1. The payee's authentication key is already stored in the sender's address book. The signature can be verified directly.
  2. The payee has a website. In that case, the authentication key can be downloaded from a DNS TXT record. Note that unlike OpenAlias, a compromised TXT record doesn't lead to a loss of funds.
  3. The sender and the receiver are communicating through an onion service. Then the onion public key can be used as the authentication key.
  4. The payee's authentication key must be verified manually by the sender. This should be done out-of-band and involves comparing short strings that look like this: QP4RJ-HIT6W-Z99R1-YFQPP-6PC1Y.

If the signature of the payment request matches, the user interface should display a prominent symbol, like a check mark: ✔. This is the same paradigm as the padlock symbol for HTTPS and is familiar to users.

(As a side note, the signature also helps with dispute resolution. The current payment proofs cannot resolve the case when Bob claims the address Alice made a payment to is not his.)

User stories

Online shopping

  1. Charlie buys goods on shop.example.com for the first time.
  2. At checkout, he scans a QR code.
  3. A prompt is displayed: "You are paying 10 XMR to shop.example.com (verified ✔). Press OK to continue."
  4. Charlie presses OK and enters the wallet password.
  5. The payment is done.

Donation

  1. Dave wants to donate to a CCS request as he usually does.
  2. He clicks a "donate" button in the CCS request and is redirected to his wallet software.
  3. A prompt is displayed: "You are transacting with Monero CCS (verified ✔). The payment is for Atomic swaps XMR/BTC. Please enter an amount to pay."
  4. Dave enters an amount, confirms and enters the wallet password.
  5. The payment is done.

Paying a friend

  1. Frank wants to repay a debt to his friend John.
  2. He receives a payment request from John via email and drag-and-drops the email attachment into his wallet software.
  3. A prompt is displayed: "You are transacting with john.smith@example.com for the first time. Please use an out-of-band communication channel and let them verify that this is their identity: QP4RJ-HIT6W-Z99R1-YFQPP-6PC1Y."
  4. Frank calls John to confirm that the identity code is his and adds him into his address book.
  5. Frank confirms the payment and enters his wallet password.
  6. The payment is done.

Paying an anonymous user

  1. Victor buys some goods from an anonymous online vendor via an onion service.
  2. The seller provides him with a payment request, which Victor pastes into his wallet software.
  3. A prompt is displayed: "You are paying 5 XMR to example3s7zyrievebrzkactalswnhakbpkazjz2ccimxcfqck52pgyd.onion (verified ✔). Press OK to continue."
  4. Victor presses OK and enters the wallet password.
  5. The payment is done.

Under the hood

This "address-less" scheme is compatible with Seraphis and behaves similar to the "Janus D" option with an extra Tier 1 capability:

Type     Tier 1 Tier 2 (+ Tier 1) Tier 3 (+ Tiers 1 & 2) Address Size (#keys)
Janus X generate payment requests view received, view spent, Janus spend 3

Wallet

A wallet is defined by two private keys ks (private spend key), kv (private view key). These can be derived as usual from a mnemonic seed.

There is an associated public spend key Ks = kv X + ks U, where X and U are generators.

Accounts

Each wallet can support up to 264 different identities, here called "accounts".

Each account index i has a private authentication key kai = H(Tident, kv, i). Note that generating authentication keys requires the private view key kv.

The associated public authentication key Kai = kai G is used to verify payment request signatures.

Each account has one public view key Kvi = kv Kai.

Payment requests

Each account can generate up to 264 different payments requests. Each payment request is defined by two indices i and j, where i is the account index and j is the payment index.

The payment request contains the following two public keys:

Note that the second key doesn't depend on the index j.

Additionally, each payment request contains a Schnorr signature (R, s) where:

Sending funds

The sender, when presented with a payment request, first needs to recover the public authentication key Kai. There are four ways to do that:

  1. Lookup the key in the address book (either by payee's name or by the key Kvi).
  2. Lookup the key in a DNS TXT record (if interacting via a domain name).
  3. Decode the key from the onion address (if interacting via an onion service).
  4. Recover the key from the Schnorr signature: Kai = H(Tsig, R, m)-1 (s G - R)

In the last case, the key should be validated manually. The validation code is simply H(Tval, Kai) truncated to 120 bits and encoded in Base32 with a Reed-Solomon checksum digit that ensures two validation codes differ in at least 2 characters.

The output is constructed as follows:

  1. A random scalar t is generated.
  2. The sender-receiver shared secret is: q = H(Tderiv, t Kvi)
  3. The one-time output key is: K = H(Tkey, q) X + Ksi, j
  4. The output public key is: Q = t Kai
  5. The output blinding factor is constructed as C = H(Tblind, q, t G) G + b H

Receiving funds

  1. Calculate nominal sender-receiver shared secret: q = H(Tderiv, kv Q)
  2. Calculate the nominal spend key Ksi, j = K - H(Tkey, q) X
  3. If Ksi, j belongs to this wallet, look up the associated private authentication key kai.
  4. Calculate C = H(Tblind, q, (1 / kai) Q) G + b H. If it doesn't match the output commitment, this is a Janus attack.

Wallet tiers

Tier 1 wallet for account i knows the public keys Ks, Kvi and the private key kai. This wallet tier is suitable to be used at the point-of-sale as it can generate and sign payment requests on demand.

Tier 2 wallet knows the public key Ks and the private key kv. This wallet tier can generate new accounts and can see the total wallet balance.

Tier 3 knows both private keys ks and kv and can spend the money in the wallet.

Payment IDs

Payment IDs are not needed in this protocol and can be removed entirely. This protocol can simulate both of the currently used payment schemes in Monero:

  1. Integrated addresses are used by merchants to identify payments and provide assurance to customers. This can be achieved by using a long-term account and generating a new payment request for each customer.
  2. Subaddresses are used where the recipient doesn't want their online activities linked together by a third party. This can be achieved by using a new account for each online purchase and only using payment requests with j=0.

A combination of these two approaches is also possible.

Edits:

fluffypony commented 2 years ago

@tevador I like payment requests, but if LN has taught us anything its that people want both payment requests AND a short, offline string they can pass around (lnurl). Is there anything fundamental in Seraphis that prevents both?

UkoeHB commented 2 years ago

@fluffypony it is possible to do both afaict. It is just a hassle from the implementation side, the more bulky the address scheme gets.

fluffypony commented 2 years ago

@UkoeHB can't be much more cumbersome than 95-character long Monero addresses, or 100+ character long integrated addresses;)

Mikerah commented 2 years ago

@tevador The main issue I see with passing around URLs is the increase risks of phishing attacks. The crypto space has spent a lot of resources and a lot of money lost to learn lessons in that URLs are not the best way to authorize funds moving from wallet to wallet. There has to be some way for a user to ensure that 1) they are sending the funds to the correct recipient and 2) that the recipient can check that they are indeed receiving the right funds from the correct sender.

LocalMonero commented 2 years ago

@tevador a few questions for you:

  1. Could you please provide an example on how a payment URL would look like?
  2. What about deposits to exchanges, where the amount is open-ended? Requiring the user to input ahead of time how much coins they wish to deposit is a UX nightmare.
  3. Which part of the wallet do you expect to implement the DNS record calls?
  4. Is relying on DNS for the green checkmark a good idea, given the centralized nature of the control structure over domain names, where states can seize domains essentially at will? Not to mention DNS poisoning in censored jurisdictions like China, where the Chinese government can essentially change the DNS TXT records to whatever they like for whichever domain they like. This isn't going to be limited to China in the future, as the trends indicate.
  5. If DNS is no longer considered, is the manual code verification really that different from checking the address? Especially taking into consideration most people just check the first few and last few characters of an address.
tevador commented 2 years ago

@tevador I like payment requests, but if LN has taught us anything its that people want both payment requests AND a short, offline string they can pass around (lnurl). Is there anything fundamental in Seraphis that prevents both?

A bare payment request can also be passed around as a string and would not be significantly longer than a Seraphis-Janus address (~1 scalar longer).

The main issue I see with passing around URLs is the increase risks of phishing attacks.

Which URLs are you referring to?

Could you please provide an example on how a payment URL would look like?

There would not be a payment URL, at least not a human readable one because there is no need for that. QR codes can directly encode binary data and a clickable URL can look something like this: <a href="monero://M_UcZTqiEIsdlaTuJjpeze3Dx1rgxBf-E44gAH5gVM0HthU1xddkJtuHfbNgI-gOUhE6hlNPPijgN6-PIFEZJEe0dHokdvsvaJbqXgETg0ocEiL8zdYDA382S65UsTPrNmLZVLS_G_f7ZXTB1fU01K2dWLS428RTQNbSeJ8vUuQmCrrMYj3CHOb5IU2opFgirxzW0IoOvNuDB2hJQ6vxS5TKau8ofOv2gHxusTmJvrrl4J7d">PAY HERE</a>. The user will just see a "PAY HERE" button.

What about deposits to exchanges, where the amount is open-ended? Requiring the user to input ahead of time how much coins they wish to deposit is a UX nightmare.

That's why the amount is an optional field of the payment request. The only required fields are the 2 public keys and the signature.

Which part of the wallet do you expect to implement the DNS record calls?

That's not relevant to this protocol. AFAIK wallet2 currently implements DNS requests to support OpenAlias.

Is relying on DNS for the green checkmark a good idea, given the centralized nature of the control structure over domain names, where states can seize domains essentially at will? Not to mention DNS poisoning in censored jurisdictions like China, where the Chinese government can essentially change the DNS TXT records to whatever they like for whichever domain they like. This isn't going to be limited to China in the future, as the trends indicate.

There is DNSSEC, which should be a requirement for the green check mark. The idea was that the DNS verification would be used mainly for online shopping when you are already using DNS to access the website.

If DNS is no longer considered, is the manual code verification really that different from checking the address? Especially taking into consideration most people just check the first few and last few characters of an address.

The 25-character uppercase string is much easier to verify than a 95-character case-sensitive one*. Moreover, this verification would only be done once for each party you transact with. It's the same as when you import a GPG key for the first time.

* Currently, there can be valid addresses that differ just in 1 character, for example (spot the difference): 42zDXTDfErPYQDtZGE1JejQ5TsziFp5ep45afwzmjn9hAYxHUzJ5dBZ3udPZsMaQXbRFfBzBZv4CL7CGRfu17scNKXfFtiF 42zDXTDfErPYQDtZGE1JejQ5TsziFp5ep45afwzmjx9hAYxHUzJ5dBZ3udPZsMaQXbRFfBzBZv4CL7CGRfu17scNKXfFtiF

LocalMonero commented 2 years ago

There is DNSSEC, which should be a requirement for the green check mark. The idea was that the DNS verification would be used mainly for online shopping when you are already using DNS to access the website.

DNSSEC is a nightmare, a lot of registrars don't implement it or implement it poorly, and you haven't addressed the other DNS concerns.

The 25-character uppercase string is much easier to verify than a 95-character case-sensitive one

Again, nobody checks the whole 95 chars. People check the first few and last few. The example you gave of 1 char diff is an edge case that will essentially never occur in reality. Checking it once as opposed to every time is a benefit, though.

@tevador you should consider coming up with a different automatic green check mechanism that doesn't rely on DNS, or at least not just on DNS.

Gingeropolous commented 2 years ago

im all for a radical re-think :) . I can't comment directly on the technicals, but having to use DNS gives me the heebie-jeebies.

But yeah, with the possibility that seraphis address schemes will create even larger text strings than we have now, it'd be great if we could come up with something different.

it'd be cool if you could publish something to the blockchain that would function to do something, yeah, u bloat the chain a bit...

fluffypony commented 2 years ago

@Gingeropolous I don't think you have to use DNS, unless you want the payment request to be "verified" by a particular domain. Also agreed on the last point - aliasing on-chain is always going to be a mess, you're going to have to deal with a landrush and phishing.

fluffypony commented 2 years ago

@LocalMonero DNS is good for validating origin against a domain. Other mechanisms (eg. have a text file on the root of the domain) would require the wallet to fetch that text file, which is a BAD idea from a privacy perspective. DNS, on the other hand, is recursive by its nature, so you almost never need to fetch the records from the canonical server.

LocalMonero commented 2 years ago

@fluffypony what about onion verification?

fluffypony commented 2 years ago

@LocalMonero I don't see how that changes things. Instead of "You are paying 10 XMR to shop.example.com (verified ✔). Press OK to continue." it would say "You are paying 10 XMR to duckduckgogg42xjoc72x3sjasowoarfbgcmvfimaftt6twagswzczad.onion (verified ✔). Press OK to continue."

LocalMonero commented 2 years ago

@fluffypony the difference is that control over onion domains is outside of rogue state hands (both domain seizing and DNS cache poisoning, and it's not hijackable (see the recent domain hijacking scandals).

fluffypony commented 2 years ago

@LocalMonero for all of those benefits it has its own issues - eg. the private key lives on a server that people will not secure well, so then their .onion will get stolen. Either way, the reality right now is that many people are hitting a normal domain and making a payment - if they're making a payment on a .onion their threat model is likely very different.

OrvilleRed commented 2 years ago

It does make the "Paying an anonymous user" story flow identical to the "Online shopping" flow. Which is nice.

LocalMonero commented 2 years ago

@fluffypony if you can't secure your onion server you won't be able to secure your node/wallet server either.

fluffypony commented 2 years ago

It does make the "Paying an anonymous user" story flow identical to the "Online shopping" flow. Which is nice.

@OrvilleRed there's no UX improvement in showing a .onion over a pubkey. In any event, you could still have the records on a .onion, just without DNSSEC (which would have to be supported anyway, as not every TLD supports DNSSEC).

@fluffypony if you can't secure your onion server you won't be able to secure your node/wallet server either.

@LocalMonero not true. You can secure your wallet with a Ledger whilst still having an insecure server. They are VERY, VERY different targets.

tevador commented 2 years ago

@LocalMonero DNS has its flaws, but if you think about it, there are no better alternatives.

In case the domain is seized, the DNS record spoofed or censored, the worst that can happen is that the automatic check fails for first time users and it falls back to the manual check. There is no risk of losing funds unless the secondary communication channel used to deliver the payment request is also compromised.

Using an onion address is just replacing one meaningless long string with another. If you are able to securely deliver an onion address to the payer, then there is no need to do anything else because an onion address is an encoded public key and can be used directly as the authentication key (interestingly, this works because Monero and Tor use the same elliptic curve). I agree that this could be an alternative in cases the parties are already interacting via Tor, but it cannot replace the DNS verification completely.

regret-17 commented 2 years ago

I think tevador's suggestion would greatly enhance the end-user experience.

A bare payment request can also be passed around as a string and would not be significantly longer than a Seraphis-Janus address (~1 scalar longer).

I feel like this should be the way to go, though. You receive a string similar to the current address scheme, and it "collapses" into a shorter string that is easier to verify manually.

Even better if you could just pass the shorter string around and have the wallet figure out what the original was, though I'm not sure that's possible.

LocalMonero commented 2 years ago

@LocalMonero not true. You can secure your wallet with a Ledger whilst still having an insecure server.

@fluffypony We were talking in the context of an online service, clearly you need to run a node/wallet on a server. Hence, the threat model is nearly identical.

@LocalMonero DNS has its flaws, but if you think about it, there are no better alternatives.

@tevador No DNS entanglement into the Monero protocol is a preferable alternative to DNS entanglement. if most services switch to DNS-tied payment requests then that would open up a significant vector of attack. Understand the long-term implications of your proposal, especially in the context of aggressive resistance from (evil) state actors to Monero's global adoption.

Either come up with an automatic verification mechanism that doesn't have these attack vectors or don't include it at all and keep only the manual verification.

fluffypony commented 2 years ago

We were talking in the context of an online service, clearly you need to run a node/wallet on a server. Hence, the threat model is nearly identical.

@LocalMonero Huh? No you don't - an online store only needs to be able to verify receipt of the payment, so it can run a watch-only wallet.

Either come up with an automatic verification mechanism that doesn't have these attack vectors or don't include it at all and keep only the manual verification.

Why do you need in-band verification for most contexts? Sounds like a system where people will get suckered into trusting, and then it'll be abused. Plus you have the out-of-band verification example under tevador's "Paying a Friend" example.

LocalMonero commented 2 years ago

@fluffypony some can run a watch-only wallet. Others will need a hot wallet. Securing an onion server is a personal responsibility concern, DNS seizing is not.

The "paying a friend" example is what I meant by manual verification.

tevador commented 2 years ago

@LocalMonero

No DNS entanglement into the Monero protocol

This is not an entanglement, but an optional wallet feature. The built-in Monero wallet already uses DNS, but there is a command line option to disable it.

I don't see the harm in providing this function to people who want to use it. People who don't trust DNS will disable it and fall back to the manual verification.

I don't want to get dragged into a lengthy discussion about a minor feature of my proposal. If you don't want Monero to use DNS, I think you should open a separate issue.

LocalMonero commented 2 years ago

@tevador that's fine. Green checkmarks breaking if/when a DNS poisoning/hijacking/seizing happens should be sufficient.

LocalMonero commented 2 years ago

@tevador do you think one could combine DNS TXT and Onion for a more robust approach? Say the wallet checks if the DNS TXT key matches the onion service key, and if not then a security prompt prevents the sender from moving on with the transaction, like with HSTS in browsers.

And perhaps there should be two levels of checkmarks to encourage service operators to implement the DNS+Onion strategy. If a service only uses DNS TXT then it's a single checkmark (or a grey checkmark) and if verification happens with DNS+Onion then it's two green checkmarks (or a single green checkmark). This is analogous to the grey padlock HTTPS vs green padlock HTTPS.

fluffypony commented 2 years ago

@LocalMonero it's not analogous at all. Using DNS validates that the payment is going to that domain, whether it's a .com (see:"Online shopping" in Tevador's example) or a .onion (see: "Paying an anonymous user" in Tevador's example). Not using DNS means that it's effectively like paying a Monero address. There is no possible validation that can happen, since you have been given the address out-of-band and not on a website, so there is no link to that site. Encouraging some sort of link (eg. embedding the URL of the site in the URI) is a TERRIBLE idea, as it is trivial to phish "you are about to make a payment to localmonero.org" by things like Unicode zero-width joiners, similar ASCII characters, etc.

LocalMonero commented 2 years ago

@fluffypony what I meant was combining 2. Lookup the key in a DNS TXT record + 3. Decode the key from the onion address (if interacting via an onion service) for more robust verification.

tevador commented 2 years ago

@LocalMonero They cannot be combined. If you are on a clearnet website, there is no onion address to verify against. Providing the onion address in-band doesn't improve security and if there is an out-of-band channel, you can pass the verification code directly and avoid the DNS check in the first place.