Monero Research Lab Meeting - Wed 01 January 2025, 17:00 UTC

[Rucknium]

Location: Libera.chat, #monero-research-lab | Matrix

Time: 17:00 UTC Check in your timezone

Main discussion topics:

1. Greetings

2. Updates. What is everyone working on?

3. Discussion: Post-quantum security and ethical considerations over elliptic curve cryptography

4. Any other business

5. Confirm next meeting agenda

Please comment on GitHub in advance of the meeting if you would like to propose an agenda item.

Logs will be posted here after the meeting.

Meeting chairperson: Rucknium

Previous meeting agenda/logs:

#1127

[Rucknium]

Log

< c​haser:monero.social > with the switch to Carrot, for new wallets, can we do away with the prefix difference between main and subaddresses (4... vs 8...)?

< c​haser:monero.social > also, am I correct assuming that...

< c​haser:monero.social > * ...for hardware wallets and wallets derived from 25-words mnemonics, the user will need to know the version of their wallet and choose it during the import flow?

< c​haser:monero.social > * ...for future Polyseeds (generated after the FCMP++ fork), this hell could be avoided if Polyseed and its implementations are updated in time to use one of the free feature bits to bump the wallet version?

< dukenukem > Reminder for enthusiasts! MoneroKon 5 conference still seeks your ground-breaking ideas on security, privacy, and decentralization. Share your insights and be part of the dialogue. Submit your talk proposal today! Apply: http://cfp.twed.org/mk5/cfp

< dukenukem > If not interested in applying at the moment, share with friends and privacy-adjacent communities!

< c​haser:monero.social > (cont.) assuming the latter point is correct, it would work reliably only for the bumped Polyseeds, since a user may not update the wallet they use for mnemonic generation by the fork date

< r​ucknium:monero.social > MRL meeting in this room in two hours.

< r​ucknium:monero.social > Meeting time! #1134

< r​ucknium:monero.social > 1) Greetings

< c​haser:monero.social > hello

< s​yntheticbird:monero.social > Hello

< rbrunner > Hello

< r​ucknium:monero.social > Happy New Year

< j​berman:monero.social > waves

< rbrunner > Likewise!

< r​ucknium:monero.social > 2) Updates. What is everyone working on?

< r​ucknium:monero.social > me: OSPEAD. Probably will be submitting milestone 2 next week.

< r​ucknium:monero.social > MoneroKon 2025 has posted its call for presentations. The submission deadline in March 25: https://cfp.twed.org/mk5/cfp

< dukenukem > OSPEAD!? Nice!

< dukenukem > Milestone 2 - Deliver initial probability density function to scientific review panel

< dukenukem > https://ccs.getmonero.org/proposals/Rucknium-OSPEAD-Fortifying-Monero-Against-Statistical-Attack.html

< r​ucknium:monero.social > These plots are beautiful, I tell you

< dukenukem > Looking forward. About time. :-P

< dukenukem > Almost in sync with FCMP++!

< r​ucknium:monero.social > 3) Discussion: Post-quantum security and ethical considerations over elliptic curve cryptography monero-project/research-lab#131

< r​ucknium:monero.social > In the last two meetings we discussed resistance to quantum counterfeiting attacks. Maybe we can discuss PQ privacy.

< s​yntheticbird:monero.social > I would like to ask a pretty dumb question. Under FCMP++, the breaking of a wallet with its public address by a QC, do not give adversary info on other public addresses used for its transactions?

< j​berman:monero.social > My update: testing my reimplementation of kayabanerve's faster torsion check impl in order to speed up building the merkle tree for FCMP++. Moving back over to FCMP++ tx construction next

< s​yntheticbird:monero.social > s/FCMP++/Carrot/Jamtis

< s​yntheticbird:monero.social > my bad

< r​ucknium:monero.social > SyntheticBird: I have had the same question in my mind

< s​yntheticbird:monero.social > cool. The perfect forward secrecy make me think it isn't the case, otherwise one public address compromise all the underlying tx graph, but i have a doubt.

< c​haser:monero.social > SyntheticBird: TBH I'm not sure I understand your question and would value a rephrasing

< s​yntheticbird:monero.social > Afaik, on chain data are immune to quantum computer, as in no quantum adversary could break the transaction graph solely based on on-chain data. One limitation that has been shared however is that if a quantum adversary obtain a wallet public address, it can break the public key up to the wallet primary private key, compromising its privacy. The question is, does breaking a wallet<clipped me

< s​yntheticbird:monero.social > private key and therefore history, give access to this quantum adversary to other public addresses of wallet which has been transacted to.

< s​yntheticbird:monero.social > first paragraph, assuming FCMP++

< r​ucknium:monero.social > With respect to PQ privacy, there are some PQ RingCT proposals, but the tx sizes would be huge. And that would require going back to rings instead of having a FCMP-like privacy. IIRC kayabaNerve suggested that there may be more size-efficient PQ FCMP-like proposals.

< rbrunner > Is this equivalent to the question whether having the private key allows the QC to break the stealth addresses in the transactions out of that wallet as well?

< a​rticmine:monero.social > The ballpark figure of ~50000 bytes is huge but doable

< s​yntheticbird:monero.social > rbrunner yeah thats equivalent, assuming of course in the context Carrot/Jamtis/FCMP++

< a​rticmine:monero.social > Sorry 500000 bytes

< a​rticmine:monero.social > For a TX

< c​haser:monero.social > SyntheticBird: got it. I'm not sure, and would like to know as well

< rbrunner > Lacking details, I just assumed that they do continue to use something worth the name "stealth address" ...

< j​berman:monero.social > Pinging jeffro256. I may be wrong on this, but IIRC a break would compromise the wallet's seed, which an adversary could use to derive the wallet's other addresses

< rbrunner > Isn't that a different question altogether?

< s​yntheticbird:monero.social > ah. that wasn't the point.

< s​yntheticbird:monero.social > its not about the wallet A's other addresses, but the addresses of other wallet B, C that wallet A transacted to

< j​berman:monero.social > Ah, I'm not sure

< s​yntheticbird:monero.social > mhm ig its time to panic

< c​haser:monero.social > FWIW, I know this wasn't the question, but a QC can't "connect" addresses of a Carrot wallet, it would imply being able to break the Blake2b hashing algo: https://github.com/jeffro256/carrot/blob/master/carrot.md#613-subaddress-keys-new-hierarchy

< s​yntheticbird:monero.social > ig my question is over if we want to focus on economic stability of monero in the PQ era

< r​ucknium:monero.social > Here's one of the PQ RingCT papers by the way: Esgin, Steinfeld, and Zhao (2022). "MatRiCT+: More Efficient Post-Quantum Private Blockchain Payments" https://ieeexplore.ieee.org/document/9833655

< r​ucknium:monero.social > The use the "+" convention, too :D

< r​ucknium:monero.social > Double plus good.

< c​haser:monero.social > sorry jberman, just realized I restated the same thing you said

< c​haser:monero.social > but, to get back on topic, is it just me, or does a PQ migration with the current primitives and implementations mean putting up with very big, potentially impractical, addresses and tx sizes?

< s​yntheticbird:monero.social > chaser afaik yes, the current PQ primitives (Module lattices, Fourier transform based, Hash-based signature, NTRU) are all requiring much much bigger key or signature sizes

< s​yntheticbird:monero.social > maybe there is a way to cheat this from a UX perspective

< s​yntheticbird:monero.social > I don't think this represent a scalability challenge tho

< a​rticmine:monero.social > When Nielsen's Law of Bandwidth is factored in this is not that different from RingCT in 2017

< s​yntheticbird:monero.social > I'll note tho. tevador seraphis-pq draft didn't tested S-NTRU.

< c​haser:monero.social > I hope so. one thing that's hard to cheat on is address length. I've had doubts even about 244 characters in Jamtis-RCT

< r​ucknium:monero.social > Animated address QR codes will be embedded in a little movie so at least users are entertained while their device reads them.

< s​yntheticbird:monero.social > NTRU sizes for reference: https://ntruprime.cr.yp.to/security.html

< s​yntheticbird:monero.social > Ok now that i see that I might understand why it wasn't shared. It's KEM not DSA

< s​yntheticbird:monero.social > my bad

< c​haser:monero.social > this, or encoding over the UTF-8 character space. I'm personally undecided

< r​ucknium:monero.social > IIRC Brandon Goodell (surae) was working on PQ lattice cryptography before joining Cypher Stack.

< f​ede:xmr.mx > Maybe sharing a 32-byte hash of the actual address, which must be registered in a sort-of DHT.

< s​yntheticbird:monero.social > yeah i think we heard of that idea before.

< c​haser:monero.social > it would be good to have him on board for this topic.

< rbrunner > Before I worry too much about those lengths I will have a look what the quantum proofing research will bring in the next few years. Won't hardly stand still, I think.

< c​haser:monero.social > I really don't like those approaches, but if something really has to give, on-chain registration is an option too.

< c​haser:monero.social > Kayaba's Monerokon 2024 "unorthodox crypto for scaling" presentation may be adjacent related

< c​haser:monero.social > rbrunner: very much indeed. I expect many novelties and optimizations. I don't know though how much we can afford waiting for those to become realized.

< rbrunner > Agree

< rbrunner > At least Monero "knows how to hardfork" if something decidedly better comes around ...

< j​effro256:monero.social > Knowing address A does not reveal the sender of transactions that address A received XMR in. It also doesn't reveal which other addresses receive XMR to funded by those enotes. But if the QC knows of any public address of wallet A as well as wallet B, if can see that A sent B funds if there wasn't a churn in between to the "internal" view-balance secret

< j​effro256:monero.social > Sorry for being so darn late

< f​ede:xmr.mx > On-chain registration has UX issues: you must either pay a transaction fee for registering an address, which means it's impossible for newcomers to register it, or solve a PoW puzzle, which can frustrate users with long wait time. I'd rather use a non-permanent off-chain DHT which is less subject to scalability issues.

< s​yntheticbird:monero.social > Thanks, that confirm that we can use disposable wallets for receiving funds and then send them an internal wallet and have QC protection

< j​effro256:monero.social > But if wallet A receives some XMR, then churns it back to itself using the new Carrot key hierarchy, then sends it to wallet B, even though a QC could know the private view-incoming key for both wallet A and B, it can't say for certain that the funds moved from A->B. It could perform probabilistic timing and amount analysis, but there isn't a deterministic link

< c​haser:monero.social > fede: that's true.

< j​effro256:monero.social > Yeah at that point the privacy becomes similar to a cleartext amount BTC mixer under a quantum adversary. If a QC can see that wallet A received 398737693740037 pXMR, and then wallet B shortly thereafter received 398737693740037 - fee pXMR, then they can say with high probability that the funds were likely transferred A->B

< j​effro256:monero.social > So transferred amount quantization as well as fee quantization is something we would likely want to look at in the future for posterity's sake

< r​ucknium:monero.social > Having really high XMR precision must have seemed so clever at the time ;)

< r​ucknium:monero.social > at the time it was decided, I mean. I guess that was Bytecoin that decided that

< j​effro256:monero.social > Also you don't need a disposable wallet the way that Carrot key hierarchy is written, there is a symmetric secret used solely in hash functions that shouldn't ever leak due to ECC arithmetic. All change enotes are sent to this secret, which automatically makes change/selfsend forward secret unconditionally

< j​effro256:monero.social > Existing wallets don't get this feature, and must migrate, but once migrated, this feature is completely opaque to the user

< a​rticmine:monero.social > A caution here is that probabilistic guessing can still be used to falsely accuse the innocent

< j​effro256:monero.social > Yes, of course, but we can give them ammo to try if we're not careful

< a​rticmine:monero.social > I agree we must eliminate the illusion of surveillance

< s​yntheticbird:monero.social > jeffro256 would you happen to know a bit more about PQ primitives? we were talking size and practicality, do you know if there are ways to avoid this in the future

< r​ucknium:monero.social > We can end the meeting here. Thanks everyone.

< s​yntheticbird:monero.social > thanks

< a​rticmine:monero.social > Thanks

< j​effro256:monero.social > Thanks !

< j​effro256:monero.social > Well basically the one thorn in the side of FCMP++ forward secrecy at the moment is the Diffie-Helman key exchange against the public addresses. All Carrot/Jamtis/legacy addresses easily reveal the private view key to a quantum computer, so getting rid of discrete log based key exchanges would more or less solve all on-chain privacy issues. There's multiple different ways to get r<clipped messag

< j​effro256:monero.social > id of discrete log based key exchanges, but they mostly fall under two categories: 1) use a PQ key exchange, or 2) don't do an on-chain key exchange at all

< s​yntheticbird:monero.social > Oh the second option was tevador proposal iirc

< j​effro256:monero.social > I recommend reading the discussion in monero-project/research-lab#106 for discussion of the latter

< j​effro256:monero.social > That's something that is doable in the very near future without a lot of cryptography research needed

< j​effro256:monero.social > It changes UX for sure though, don't get me wrong

< j​effro256:monero.social > I think that people should start looking at and getting familiar with off-chain key exchanges, since it's an option much more accessible to developers who aren't familiar with PQ cryptography

< j​effro256:monero.social > And it doesn't involve any changes to the transaction format, and as such, doesn't require widespread consensus

< j​effro256:monero.social > So good for experimentation and getting PQ privacy sooner rather than later

< c​haser:monero.social > since a SPHINCS+ pub key that targets 128-bit security is 32 bytes long (https://sphincs.org/data/sphincs+-r3.1-specification.pdf#page=58, Table 8), isn't that conducive to a PQ addressing scheme with the same base58 address lengths as we have today?

< s​yntheticbird:monero.social > Yes but SPHINCS+ signature are HUGE

< s​yntheticbird:monero.social > Last time i tested asurar0 PQ tool, the signature was like 40kB or smth

< j​effro256:monero.social > You wouldn't need signatures for a key exchange AFAIK

< s​yntheticbird:monero.social > jeffro256 KEM based KEX ?

< s​yntheticbird:monero.social > S-NTRU might return into play if its the case

< c​haser:monero.social > SyntheticBird: yeah, for now I'm just brainstrorming and handwaving every other problem away by e.g. hoping Nielsen's Law will hold. compute/bandwidth/storage/power can get cheaper over time, human attention and human willingness is much less likely to do so.

< s​yntheticbird:monero.social > SNIPPERRR!!!

< s​yntheticbird:monero.social > everyone take cover