NaN

tevador proceeds with Option A (standard CSIDH-1024 parameters) for Jamtis: 400-character addresses. All transactions embed a CSIDH-1024 public key in tx_extra; legacy wallets ignore it with no scan-time change. An optional interactive symmetric-crypto payment protocol is being developed for users wanting stronger PQ privacy. Discussion covered quantum-adversary capabilities, mobile-wallet UX, harvest-now-decrypt-later risks, address hygiene, and Tachyon-like alternatives. rucknium: 5. Post-quantum encryption ( #issuecomment-4281932714" target="_blank" rel="nofollow noopener">github.com/monero-project… ). tevador: Quick update: Based on the last meeting, I decided to go with Option A for Jamtis and use the standard CSIDH-1024 parameters. The address length will be 400 characters. I'm working on an interactive payment protocol that will be able to provide full privacy without an on-chain key exchange (it will be an appendix to the address specs). vtnerd: Not a fan of it being interactive - is that portion mandatory? The user cannot opt out of an interactive key exchange? tevador: To clarify: there will be both options. A non-interactive PQ key exchange based on CSIDH-1024 and an optional interactive one based on symmetric crypto only. vtnerd: Hmm. Symmetric crypto is a sure way to anger a QC rucknium: More noob questions from me, about scan time. What happens when an old-style (non-quantum-resistant) wallet scans a quantum-resistant output. Any slowdown? And the reverse: Any speedup when a new-style wallet scans a non-quantum-resistant output? jberman: I don't really see another feasible route on the table here tbh. If we want mobile wallets to be able to restore a wallet from seed, then the more secure PQ key exchange algos don't seem practical by the figures here articmine: A related question is how effective is parallel processing here? tevador: The goal is for all transactions to have a CSIDH-1024 public key in tx extra. Legacy wallets will simply ignore the key. Scan times will be about the same as now for both legacy and Jamtis. tevador: enote scanning is obviously parallelizable, but the amount of computation required makes CSIDH view tags infeasible rucknium: jberman: Do you mean the interactive protocol or Option A for non-interactive? jberman: That comment applies to both. I don't see another route on the table aside from those 2 routes: Option A for non-interactive, or the interactive protocol rucknium: What if we wait until better PQ algorithms are discovered? tevador: I also think that option A and an additional interactive protocol is the best compromise. Addresses will remain usable and the interactive protocol can be used by users who want more PQ privacy than Jamtis will offer. rucknium: Hard to know what the future may hold, of course. tevador: Waiting is not an option due to "harvest now, decrypt later". rbrunner: At least with A we don't get astronomical scan times, with mobile wallets completely unable to scan themselves jberman: It could theoretically be implemented and not deployed until the QC threat passes some threshold, and in that time if some better algo arises, perhaps we could swap it in rucknium: With Option A, a quantum adversary cannot identify all the outputs sent to an address that it does not know, correct? There would be limited ability to try to cluster the behavioral information. gingeropolous: but then there's n years of data to decrypt jpk68: As rbrunner mentioned last week (I think), making scan times infeasible for mobile wallets (basically, anything that would force you to self-host something like LWS) would eliminate a huge amount of people from being able to use Monero jpk68: In my opinion this is infinitely more of a UX burden than long addresses, for example rucknium: I think people could still use Monero. But would not be protected from a quantum adversary. jeffro256: rucknium: With option A, a QA can identify all outputs sent to any address sharing that one's view key. And it can identify spends in most cases rucknium: But not any outputs of a view key that it does not know any addresses of? endogenic: all ecdh and signing is broken by qc guys rucknium: It would ID spends because of change outputs sent to own addresses, I assume endogenic: you can't still use monero jeffro256: rucknium: Yes. but that is true of CARROT and legacy addresses too tevador: rucknium : With option A, if the QA knows one of your addresses, they can calculate primary and secondary view tags, but can only probabilistically identify enotes to unknown addresses unless the address is reused. tevador: jeffro256 : No, it cannot identify spends. rucknium: If the adversary had the addresses of the sender and recipient, that would reveal the spending behavior fully. Not the amount. Correct? tevador: Internal enotes use a symmetric key for view tags. jeffro256: tevador: I mean that it can sometimes identify the spend location of external enotes, not internal enotes luke: I agree with Rucknium's comment of potentially waiting for more PQ options. Isogeny based scheme make me nervous. tevador: If the adversary has Alice's and Bob's addresses, they can see enotes (without amounts) coming to Alice's and Bob's wallet, but can't infer they are transacting with each other. endogenic: if mallory has a and b addrs then mallory can get a and b sec keys no ? tevador: jeffro256 : It cannot, at least not for Jamtis enotes. rucknium: lu: Thank you for your comment. Could you elaborate? rucknium: (Luke S is with Cypher Stack cypherstack.com/about.html ) endogenic: I guess he's talking about lattice etc problems tevador: luke : I'm actually quite confident about CSIDH. tevador: The original idea behind CSIDH is from 1996 IIRC, so fairly old. luke: Sure. Me and the other mathematicians have spent a great deal of time talking about PQ security stuff, both at CS and in our academic careers and it is the loose consensus that isogeny based problems are the least favorite of the potential PQ primitives. jeffro256: tevador: Maybe I'm remembering an attack which works on Seraphis, but not FCMP++ because of the key image composition. I'll look at it again. At least with Jamtis previously, if two enotes were spent from the same address, even if a QA didn't know the spend key extensions, they could tell that they were the same between 2 (one-time address, key image) pair, thus allowing them to correlate where external enotes were spent jeffro256: It's been a while since I looked at that particular attack luke: Lattice based problems are fine but I personally am a big proponent of Code based cryptography. I think it is probably the most likely to retain its PQ status in the time to come. tevador: jeffro256 : IIRC that was a Seraphis-only attack, FCMP++ has perfectly hiding linking tags. jeffro256: Seraphis also had perfectly hiding linking tags, though. The foil might be the hash-to-point in FCMP++ luke: I agree, but it is entirely possible that we might see some sort of improvement in the near future. tevador: luke : Yes, McEliece would have been great if it wasn't for the 250 KB public keys :) tevador: A bit impractical for an address. tevador: Yes, but waiting means more exposed legacy addresses that will be broken and deanonymized. jberman: tevador: for the non key exchange route, Tachyon may have a better set of tradeoffs worth considering as well I think tevador: I'm not familiar with Tachyon jberman: seanbowe.com/blog/tachyon-s… jberman: As I understand it, there's an always-on server that scans state without leaking privacy, and there's no key exchange protocol tevador: jberman : I checked the Tachyon blog post. It seems that Zcash wants to eliminate non-interactive transfers, which is probably not what we want? tevador: quote : "As a start, we'll be assuming that Zcash's future payment flows involve out-of-band payments where the sender and the recipient use a separate channel for secret distribution." jberman: tevador: I agree. In any case, their intent seems to be to roll it out in phases, which implies a period of time where they'd support both. Considering how they've done things in the past, I'd assume the "tachyon" pool is incompatible with the existing anonymity pools though. And ya I would agree distinct anon pool is not what we'd want jberman: But perhaps there could be some tweak that enables a compatible anon set with an interactive protocol jberman: non-interactive* jberman: I would be surprised if that design isn't achievable jberman: tevador: I agree and am not raising it to shift UX to interactive payments jberman: You mentioned exploring an optional interactive route that would require out of band communication, I'm mentioning a Tachyon-like design as worth considering for that optional component alongside the non interactive jberman: Also it doesn't seem like the protocol requires a single centralized server, and a user could spin up their own instance. I imagine the UX would include some payment request that points to their own instance of choice jberman: That design obviously seems worth considering if we're discussing interactive payments jberman: A 3-round protocol is hard to see gaining traction without a server in between helping automate the flow jberman: I would guess that wallet apps may implement a communication protocol with their own infra (or maybe work something out with some service provider) jberman: And so long as a server would be involved, then it's worth thinking on further and weighing expected UX ixr3: I hope Jeffro implements the carrot key hierarchy soon after the HF, or earlier if the HF is significantly delayed. Internal forward secrecy will help in the meantime until better PQ solutions are available. Churning will become increasingly important for anyone concerned with post‑quantum security. ixr3: "harvest now, decrypt later" is bad and the Jamtis-PQ release will probably take longer than expected tevador: jberman : it's not about the anon pool. It's the UX shift to interactive transactions that we don't want. Zcash is a for profit company, they can afford to run infrastructure to help users interact during payments, but it's not a viable solution for Monero. jberman: I agree and am not raising it to shift UX to interactive payments You mentioned exploring an optional interactive route that would require out of band communication, I'm mentioning a Tachyon-like design as worth considering for that optional component alongside the non interactive Also it doesn't seem like the protocol requires a single centralized server, and a user could spin up their own instance. I imagine the UX would include some payment request that points to their own instance of choice That design obviously seems worth considering if we're discussing interactive payments tevador: I'm not going to place any infrastructure requirements in my proposal. The interactive payment protocol will be executed by passing 3 alphanumeric strings between the recipient and the sender over any communication channel of their choice. sgp_: some wallets already do this for payjoin. I hate implementations where this would be expected, but wallets often use stuff like this today for helper functions. The fewer that are needed, the better. #L33" target="_blank" rel="nofollow noopener">github.com/cake-tech/cake… tevador: The flow in my sketch protocol is: Receipient -> Sender -> Recipient -> Sender, where each arrow is a ~400 character string. jberman: A 3-round protocol is hard to see gaining traction without a server in between helping automate the flow I would guess that wallet apps may implement a communication protocol with their own infra (or maybe work something out with some service provider) And so long as a server would be involved, then it's worth thinking on further and weighing expected UX sgp_: I think that an interactive payment protocol would be a huge loss :( if the requirement of max address length of 420 was dropped, would BC1024 be the most appealing? or would you still prefer A?I admit to being tempted by BC512. Yes, the security guarantees are smaller with CSIDH-512 than CSIDH-1024. But the privacy gains with option B over A are considerable to me. If we consider a "collect now and decrypt later" scenario as the most dangerous at the moment, it seems to suggest that we should prefer greater privacy (1/256 enote narrowing down vs knowing all received enotes) to the security margin. If it would take "65 thousand quantum computers running for 5 years" to break the security of a single key with CSIDH-512, we at least would have ample (in relative terms, it would still suck!) time to implement a migration strategy to more secure wallets. Am I misinterpreting something? tevador: sgp_ : Why would and additional interactive protocol be a loss? If it's optional for people who want to use it. IMO it's a net gain. sgp_: I mean requiring it for PQ privacy of received enotes (even in the 1/256 form) would be unfortunate If options A or B are selected, I'm not against an optional interactive thingy for even better post quantum privacy tevador: Option B is kinda suboptimal, that's why I preferred A or C. B adds: some (but not a lot) of enote privacy, but the costs are: much larger addresses, a much larger pruned transactions (up to 2-3 KB for 16-out transactions) and awkward filter assist (light wallets are supposed to run the heavy CSIDH instead of the filter server). tevador: And B still lacks PQ unlinkability, so if you have 2 online identities and use the same wallet, they can be linked in a PQ scenario. tevador: Only option C gives full PQ privacy. sgp_: I definitely wasn't factoring in the filter assist, but I do think 1/256 is hugely better than nothing (it's like ring sigs, but better) linkability is unfortunate but we deal with janus now, so advanced users should be aware of potential limitations, and they can be informed that limitations would persist I suppose one argument for Option A is that senders already know what enotes they send to addresses they are aware of, so this could be a user education problem, where recipients are told to always use fresh addresses per sender. Address hygiene becomes more of a requirement. Basically, we try to UX our way out of most limitations (leaving some footguns), and for everything else, there's an interactive protocol tevador: For maximum privacy, you should use a fresh wallet per sender, unless we go with Option C. #c672772" target="_blank" rel="nofollow noopener">libera.monerologs.net/monero-researc…

Five architects of the AI economy explain where the wheels are coming off techcrunch.com/2026/05/06/fiv…