3. get_tx_key/check_tx_key doxes sender in 2-out tx (

GitHub

Issues · monero-project/monero

Monero: the secure, private, untraceable cryptocurrency - Issues · monero-project/monero

The issue (also impacting Carrot) allows a third party who knows the sender’s primary address and receives the tx key (or equivalent d_e) to identify the change output in 2-out transactions and infer the sender. It was previously noted in the CLI user guide. Discussion covered why audits missed it (long-standing technique, UI convenience of tx keys over proofs, incomplete usage context), the higher impact in Carrot (automatic d_e learning by every recipient), proposed mitigations (extra ephemeral pubkey, drop Janus protection, research-lab Janus alternatives, external self-send removal, alternative InProof constructions), and the practical preference for wallets/services to switch to proper proofs rather than rely on deprecation alone. External self-sends exist mainly for self In/OutProofs. No immediate decision; further thinking / next week. Post-meeting note that Carrot has a separate change-derivation path so the issue is limited to legacy wallets. syntheticbird: The more you learn, the more you learn jeffro256: Spec PR is here:

GitHub

Fix 2-out sender dox by jeffro256 · Pull Request #16 · jeffro256/carrot

Resolves monero-project/monero#11586. Effectively changes the spec so that legacy key hierarchies use an internal scan where $s_{sr} = k_v$. Pros: ...

interestingband: The 1st question is why it wasn't captured during audit ? jeffro256: I should have a carrot_core PR open in the next couple days jpk68: jeffro256: Will carrot-rs be updated for this, and the earlier re-binding change? jeffro256: interestingband: I have also asked myself this. My guess is that since it's a technique that was sort of implied in the spec, and used in existing Monero code since forever, it was easy to overlook tevador: Is there a reason to support external change enotes? Jamtis only has internal self sends. interestingband: My guess ? Ask Opus 5.5 or any other AI interestingband: it was rhetorical question, LOL jeffro256: tevador: So you can make InProofs/OutProofs to yourself. Not much else AFAIK syntheticbird: Terrible: Your worst enemy (AI) actually has a great point. tevador: I think it would be better to remove the external self sends entirely. ofrnxmr: My 2c is that the specific get/check txkey doesnt really need to be deprecated, just that wallets and providers need to stop using it for public proofs (it is a secret key), ans should he giving users a more simple route to tx proofs. (like displaying it on the same page as the tx) syntheticbird: ofrnxmr: let's make the "trusted nodes" checkbox useful rbrunner: You mean rely somehow on the goodwill of everyobdy doing apps on doing the right thing? jeffro256: Yeah I was honestly impressed that Claude found the issue tevador: In Carrot, every recipient learns the d_e, this is unrelated to tx key proofs. selsta:

GitHub

monero-site/_i18n/en/resources/user-guides/monero-wallet-cli.md at 7dd3c296b47cecd680dec091cb19fecc1714b0eb · monero-project/monero-site

Contribute to monero-project/monero-site development by creating an account on GitHub.

so it appears this issue was documented in CLI user guide rucknium: rbrunner: I agree with your sarcastic meaning. Only way to prevent services from using it is to make it very difficult, and make the upgrade path easy. interestingband: jeffro256: It has been discovered 5 years before that review in my local environment by the same model by accident in the very beginning, but it felt like it's not the biggest thing I'm gonna discover in the end jeffro256: tevador: How is it unrelated? d_e is the analougue of the tx_key in Carrot selsta: > Note that this third party, if knowing your own address, will be able to see how much change was returned to you as well. interestingband: Also I'm not sure how you can reason what about the fix without having a big picture how your protocol is gonnab be used ofrnxmr: rbrunner: No, i mean its a misunderstanding. Everyone copied their homework. Wallet A provided keys, and never proofs, so wallet B did as well. We just need to talk to the wallet providers (and bisq, onion explorer etc) and have them support proofs interestingband: That's the main reason why audit didn't capture tevador: I mean it's unrelated to any use of the RPC to share the tx key, it's automatic. Apologies for bad phrasing. syntheticbird: selsta: well that kinds of breaks the whole claude is smart myths all of the sudden syntheticbird: if it was documented already jeffro256: tevador: Oh yeah I see, yeah that's why it was much higher impact than the existing issue tevador: That's the main reason why it needs to be fixed in Carrot. It's no longer "be careful when sharing your tx key". ofrnxmr: rucknium: Its not actually a huge leak iiuc. The service needs to know your primary address, and there cant be a subaddress as a recipient (iirc) jeffro256: selsta: Ah nice. NGL I've never looked at this guide in my life, but it's interesting that someone knew about it, but didn't think to put that notice anywhere more prominent rucknium: The service might ask for a refund address and users may put their main address in that field. rbrunner: Not yet fully clear to me. Is this the crucial sentence on that page: "Note that this third party, if knowing your own address, will be able to see how much change was returned to you as well." ofrnxmr: Yes ofrnxmr: But there are 2 subjects in one. The tx key, and carrot rbrunner: Hmm. But the "can trace the sender of transaction" part that jeffro mention in his problem description is missing ofrnxmr: I think people evaluating carrot fix is more important ofrnxmr: rbrunner: They can learn the value of the change output rbrunner: Anyway, maybe pointing the way to Claude is all that was needed ... jeffro256: rbrunner: That is sort of implied by being able to see what the receive address is of the change enote. A third-party can assume that if receiver in 2-out -> other address is change -> owner of address is sender ofrnxmr: ofrnxmr: This is whats currently happening on stressnet for legacy keyed wallets (passively) jeffro256: Combine this with small ring info, and smart third-party may be able to probabilistically learn info about tx graph rbrunner: I think I start to see rbrunner: That's why only 2-out transactions are in danger rbrunner: Or, in most danger ofrnxmr: jeffro256: Woukdnt the know (not assume) that the other output is change, and that the address is the owners, since that is the only combo that works ofrnxmr: 3+ out, subaddresses, non-change, dont work (..iiuc) jeffro256: Only 2-out is in danger b/c of the cryptographic way that the shared ephemeral tx pubkey is constructed jpk68: So this proposed fix will make InProofs impossible for most transactions? My bad if I'm misunderstanding something jpk68: Due to it affecting 2-out transactions jeffro256: Yes ofrnxmr:

GitHub

Fix 2-out sender dox by jeffro256 · Pull Request #16 · jeffro256/carrot

Resolves monero-project/monero#11586. Effectively changes the spec so that legacy key hierarchies use an internal scan where $s_{sr} = k_v$. Pros: ...

<< this one, right jpk? tevador: AFAICS only InProofs for self sends will be impossible. jeffro256: Yes? jpk68: Is there any other potential solution without these downsides? jeffro256: A) Put 2 ephemeral pubkeys for a 2-out tx, doubling scanning time for 2-out txs. B) Removing Janus protection jeffro256: tevador: I need to double check, but I think so jeffro256: Or C) something I haven't seen yet rbrunner: Er ... just ask Claude? :) syntheticbird: "Claude make monero post quantum. Make no mistakes" rbrunner: Now that was a bit mean, I know slowbeardigger: Use google gemini, ofc yall have to use the best one tevador: Is s_sr^ctx insufficient for an InProof? jeffro256: Yes, because an InProof prover requires that the discrete log between D_e and s_{sr} is k_v interestingband: list requirements for this part of protocol and verify in the context of involved parties that will use InProof jeffro256: There's isn't any ECDH to speak of in an internal scan interestingband: any other reply is just an opinion tevador: The purpose of an InProof is to prove that an enote was received, that's not directly related to discrete log. jeffro256: jeffro256: And provide s_sr itself thomasbuilds: if this is needed I'm willing to propose a fix with claude jeffro256: tevador: It's both. It decodes a received enote, and signs a message with a Schnorr signagture using k_v as the privkey thomasbuilds: maybe it finds C > <@jeffro256 > Or C) something I haven't seen yet jeffro256: If you simply want to prove that an enote was received to an address for a specific amount, then yes, you can provide s^ctx_sr jeffro256: But InProof also lets you sign messages that third-parties can't tevador: I'm pretty sure there is a solution. It might require an extra SecretDerive call or something like that. interestingband: thomasbuilds: It did in my case, but it wasn't isolated question rucknium: Anything need to be decided about this issue today? Or go think and come back next week? jeffro256: If we can use a Janus mitigation from here github.com/monero-project/research-lab/issues/62, and not reveal d_e, then that would work jeffro256: But the mitigations which are backwards-comptible with the current addresses typically have some compute or size overhead interestingband: You are trying to find math ops to meet algebraic equations, while cryptography requires much more and with proofs, otherwise It's all insecure tevador: I prefer to keep the current 16-byte Janus mitigation. tevador: It's a very good fit for Jamtis, which reuses the anchor field to encrypt the address index, which is a very efficient solution. (Pre-meeting related context:) spirobel: sorry using tx_key was never the right solution. after supplying the key once you cant proof anymore in the future through this route ... also after wallet recovery you dont have access to txkeys anymore spirobel: > ofrnxmr Currently most / all external services ask for tx keys instead of proofs (bisq's auto, explorers, etc). Deprecating would just be deleting the endpoints afaict, and then getting every wallet to provide proofs in their place (cake, monfluo, probably gui, feather, monerujo and every other wallet display they key on the tx details) spirobel: i think the reason this catched on was that it was more accessible in the ui of the wallets ... jeffro256: It affects Carrot schedule, so yes > rucknium jeffro256: ^ Should it? interestingband: Why does it affect ? Another audit ? jeffro256: interestingband: Decision on design change, change to Carrot spec, changes to carrot_core, integration of those changes in wider FCMP++ codebase, etc. Another follow-up audit would be good, but can be done in parallel IMO, depending on how the change is implemented interestingband: Is it a sweet spot between small and big changes where schedule is affected but audit is still optional ? interestingband: Or it's a sweet spot of uncertainty where nothing is clear and therefore no one knows what is going to happen ? interestingband: LOL jeffro256: interestingband: More this. Also not optional, but parallizable with the 6-month wait period (Post-meeting:) UkoeHB: jeffro256: I'm not seeing this De sharing issue. Carrot has a separate path for change derivation.

GitHub

carrot/carrot.md at master · jeffro256/carrot

Specification for Carrot Addressing Protocol. Contribute to jeffro256/carrot development by creating an account on GitHub.

ofrnxmr: It only affects legacy wallets ofrnxmr: (i assume that section is about carrot-keyed wallets)

#monero-research-lab

View quoted note →