<k​ayabanerve:matrix.org> > However, taking into account projected technological advances in quantum computing, ECDH will not be approved for use beyond 2030.

<k​ayabanerve:matrix.org> cyber.gov.au/resources-business-and…-guidelines/guidelines-cryptography

<k​ayabanerve:matrix.org> They deprecate 256-bit hashing functions yet still allow AES. That implies they believe there is a cbrt attack on hashing functions, but believe encryption limited to sqrt speedups.

<k​ayabanerve:matrix.org> *AES-256

<k​ayabanerve:matrix.org> If hashing functions do face a cbrt attack, a PQ migration isn't possible unless Monero moves to a larger elliptic curve capable of embedding 384-bit preimages (not great, not something I'd endorse even if a cbrt attack was confirmed).

<s​yntheticbird:monero.social> > Only SHA-2 hashing algorithms are approved for general purpose use. SHA-3 and XOF approval (i.e. SHA3-256, SHA3-512, SHAKE128 and SHAKE256) is restricted to use within internal steps of ML-DSA and ML-KEM.

<s​yntheticbird:monero.social> I

<s​yntheticbird:monero.social> don't get it, why prohibiting SHA-256 but allowing SHA3-256 and SHAKE256

<s​yntheticbird:monero.social> > Only SHA-2 hashing algorithms are approved for general purpose use. SHA-3 and XOF approval (i.e. SHA3-256, SHA3-512, SHAKE128 and SHAKE256) is restricted to use within internal steps of ML-DSA and ML-KEM.

<s​yntheticbird:monero.social> > don't get it, why prohibiting SHA-256 but allowing SHA3-256 and SHAKE256

<s​yntheticbird:monero.social> > Only SHA-2 hashing algorithms are approved for general purpose use. SHA-3 and XOF approval (i.e. SHA3-256, SHA3-512, SHAKE128 and SHAKE256) is restricted to use within internal steps of ML-DSA and ML-KEM.

<s​yntheticbird:monero.social> don't get it, why prohibiting SHA-256 but allowing SHA3-256 and SHAKE256

<s​yntheticbird:monero.social> sorry I just killed IRC

<k​ayabanerve:matrix.org> Interoperability.

<k​ayabanerve:matrix.org> The ML-DSA, ML-KEM specifications require those.

<k​ayabanerve:matrix.org> Which means the Australians can't be conservative without losing support for all hardware implementations of those algorithms.

<k​ayabanerve:matrix.org> With the more fundamental building blocks, they can be conservative as we can still expect SHA2-512 hardware. We just can't expect ML-KEM derivatives with SHA2-512. Even if someone wanted to, it'd violate the patent grant on it. Only the standardized algorithm is allowed access to the patent.

<s​yntheticbird:monero.social> I don't know exactly how patent works, are al ML based algorithm now under patent, or only NIST draft one (round 4) ?

<s​yntheticbird:monero.social> Like can I take round 3 and tweak it?

<k​ayabanerve:matrix.org> csrc.nist.gov/csrc/media/Projects/p…qc-license-summary-and-excerpts.pdf

<k​ayabanerve:matrix.org> > NIST has entered into two patent license agreements to facilitate adoption of NIST’s announced

<k​ayabanerve:matrix.org> selection of Public-Key Encryption PQC algorithm CRYSTALS-KYBER. NIST and the

<k​ayabanerve:matrix.org> licensing parties share a desire, in the public interest, the licensed patents be freely available to

<k​ayabanerve:matrix.org> be practiced by any implementer of the CRYSTALS-KYBER algorithm as published by NIST.

<k​ayabanerve:matrix.org> Hm. ML-DSA may be unencumbered? I though ML-KEM and ML-DSA were by these patents.

<k​ayabanerve:matrix.org> SyntheticBird: The Kyber submitted wasn't legally usable. Peoole already had patent rights over it. After Kyber was accepted, NIST obtained a license exclusively for the ML-KEM algorithm they standardize.

<k​ayabanerve:matrix.org> You can only derive from Kyber, and deploy, if you remove the infringing IP or obtain your own license.

<k​ayabanerve:matrix.org> (or if the patent expires or if you break American patent law)

<s​yntheticbird:monero.social> I see, I hate patents

<s​yntheticbird:monero.social> Now that I think of it, tevador draft of seraphis with PQ KEX didn't tested Streamlined NTRU

<s​yntheticbird:monero.social> Shouldn't this be explored as well

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

<r​ucknium:monero.social> Meeting yime! monero-project/meta #1127

<r​ucknium:monero.social> time*

<s​yntheticbird:monero.social> yreeting

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

<a​rticmine:monero.social> Hello

Hello

<c​haser:monero.social> hello

<j​effro256:monero.social> Howdy

<j​berman:monero.social> *waves*

<r​ucknium:monero.social> Like I said last meeting, I won't make a meta GitHub issue nor chair a meeting on December 25. People are free to meet then, of course. Next meeting I will make an agenda for will be January 1, 2025

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

<r​ucknium:monero.social> me: Discovered and report a critical privacy vulnerability in Wownero's decoy selection algorithm: codeberg.org/wownero/wownero/issues/488 . One lesson: Don't disable the wallet2 decoy sanity checks. Also working on OSPEAD.

<j​berman:monero.social> me: implementing this optimized torsion check for faster FCMP++ curve tree building: github.com/kayabaNerve/fcmp-plus-pl…divisors/src/tests/torsion_check.rs

<j​effro256:monero.social> Are you going to FFI it or remake it in the crypto ops code ?

<j​berman:monero.social> the latter, I'm implementing in C++

<j​berman:monero.social> / C

<v​tnerd:monero.social> hi

<v​tnerd:monero.social> been doing Boost 1.87 related things

<j​effro256:monero.social> Me: brainstorming with kayaba on carrot switch commitments, I think we've settled on an optimal scheme considering we use a 256 bit curve

<j​effro256:monero.social> Also drafting changes to the carrot doc

<j​effro256:monero.social> Also found the issue in the code with Wownero's DSA

I'm mostly done with the build system work for rust FFI (#9440). What remains is some doc improvements and finding a potential fix for aarch64 non-determinism.

Is there a bounty on that Wownero stuff? :)

<r​ucknium:monero.social> I was paid a WOW bounty

Nice

<j​effro256:monero.social> A wownty, if you will

<r​ucknium:monero.social> All operators of Wownero nodes, public and private, should update their nodes to the latest version: wownero-node-checker.redteam.cash

<r​ucknium:monero.social> 3) Discussion: preventing P2P proxy nodes. monero-project/research-lab #126

<r​ucknium:monero.social> The spy node ban list has been enabled on Cake Wallet's nodes. I think Stack Wallet's, too. PiNodeXMR implemented a feature to add ban lists. The MoneroNodo hardware node will enable it.

<r​ucknium:monero.social> Here is the issue that announces the ban list recommendation, and the ecosystem projects that are enabling it: monero-project/meta #1124

<r​ucknium:monero.social> The `@monero` Twitter/X account hasn't tweeted about it yet. That was a goal of the announcement campaign.

<s​yntheticbird:monero.social> I don't know if anything really evolved since last time but Bucket ASMap seems like the next step

<r​ucknium:monero.social> So anyone who has the capability to tweet from `2monero` about it, please do so. Use the meta GitHub link: monero-project/meta #1124

<s​yntheticbird:monero.social> and in mid-term/long-term PPoS

<r​ucknium:monero.social> Yes, I'll start researching ASmap soon.

<j​effro256:monero.social> Thanks

<r​ucknium:monero.social> Anything else on this?

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

<s​yntheticbird:monero.social> Will be honest, I don't get conceptually whats a turnstile

<r​ucknium:monero.social> For ZCash, it's that the total amount of coins in any of its shielded pools cannot go negative

<j​effro256:monero.social> For Carrot, we are skipping the el gamal commitment and binding the blinding factor straight to the amount and the address spend pubkey. Simplifies the design over a traditional switch commitment but keeps the security

<r​ucknium:monero.social> It the coin value in a shielded pool were to go negative, that would indicate that counterfeiting within the pool has occurred. For Monero, it's more complicated since everything is in the "shielded" pool. So you would have amounts cross a transparent barrier and count them up.

<s​yntheticbird:monero.social> Ok I see, so the danger of a turnstile is that if there has been counterfeiting, the first one would pass but the last one would not be able to pass their coins.

<j​effro256:monero.social> BTW, This would entail an LMDB migration where we keep track of total emission with a 128 bit integer instead of our truncated 64 bit integer

<r​ucknium:monero.social> jeffro256: "This" meaning the turnstile?

<j​effro256:monero.social> Yes

Don't know what to think about that graphic there: monero-project/research-lab #131#issuecomment-2547789303

Will this need heaps of complex code to implement?

With a lot of effort?

<r​ucknium:monero.social> There could also be a time-limited turnstile where users have to move to the post-quantum cryptography before a certain date. So users who don't move their coins for a long time would lose them permanently.

<j​effro256:monero.social> rbrunner: Carrot is already almost that complicated right now. I just added a couple edges and shuffled things around to get that proposed graph

Ah, ok. Can't make my mind up right know whether I find that comforting or not :)

<c​haser:monero.social> you could also have a turnstile that allows coins to pass beyond the legitimate supply, and is used only as an indicator/proof that counterfeiting occurred

<s​yntheticbird:monero.social> with the amount being counterfeited or only a boolean at the end ?

<j​effro256:monero.social> If we're detecting it already, why would we allow it to go over ? Ostensibly , once it hits the limit exactly, we already can guess that conterfeiting has alresdy occurred since no one ever spends 100% of coins in any system

<c​haser:monero.social> IMHO that would be really bad. it's essentially burning people's XMR.

<s​yntheticbird:monero.social> Wouldn't that pose a risk, if someone counterfeited lets say 50% over the actual total supply and passed it through the turnstile it would block 50% of the legitimate volume

<r​ucknium:monero.social> If quantum computers become a reality, with a turnstile you are already burning their XMR, and giving it to the quantum adversary

As a strategic decision, we could say living with the counterfeited coins is less bad than burning the XMR of a lot of people?

<a​rticmine:monero.social> It is more like: If you don't leave the sinking ship, you would sink

<s​yntheticbird:monero.social> I don't understand

<c​haser:monero.social> so that honest users have the opportunity to recoup some value (a value most probably diminished, but I'm not sure we can predict that)

<r​ucknium:monero.social> jeffro256: Is it true that with the switch commitment design, if people use a Carrot address after the FCMP++ hard fork, they most likely would be able to get into post-turnstile heaven?

<a​rticmine:monero.social> This presumes there is no time limit on the turnstile, only an amount limit

<a​rticmine:monero.social> ... but if we can detect counterfeiting during the transition this avoids the whole issue

<r​ucknium:monero.social> SyntheticBird: A quantum counterfeiter would get through an amount-only turnstile before the laggard honest users get through. Then, they cannot spend their XMR after the turnstile hits its limit.

<c​haser:monero.social> is it certain that a QA can steal existing enotes?

<s​yntheticbird:monero.social> Oh so there is definitely a need for a time limit then

<j​effro256:monero.social> Lmao yes. The output pubkeys for carrot address can be constructed in such a way that it allows for PoKs that are hard for QCs. This isn't the case for existing addresses

<j​effro256:monero.social> Post-turnstile heaven , I like that term

<r​ucknium:monero.social> Probably you need an amount limit _or_ an (amount and time) limit.

<r​ucknium:monero.social> Saint Peter at the turnstile gate.

<j​effro256:monero.social> In general, we can't detect counterfeiting for specific spends of single outputs, just if it has happened overall because the amount of XMR sent over the turnstile is too great

<j​effro256:monero.social> Just like we can't determine on-chain if someone spent XMR honestly , or "stole" someone else's seed phrase

<j​effro256:monero.social> If you can extract knowledge of the discrete log of output pubkeys, you "own" those coins

So after the FCMP++ hardfork everybody is free to send their coins to themselves to bring it into the "new world"

<a​rticmine:monero.social> monero-project/research-lab #131#issuecomment-2537588673

<a​rticmine:monero.social> Is this a solution?

<j​effro256:monero.social> If we have an amount limit, and we enforce post-QC secure composition , then the only purpose of a time limit would be if we value restricting counterfeiters over allowing potentially honest old wallets to come online

<r​ucknium:monero.social> jeffro256: I agree.

<j​effro256:monero.social> We definitely need to incorporate something like kayaba's sketch in that comment in order to keep the integrity of key images

<r​ucknium:monero.social> Well, kayabanerve 's potential Proof-of-Stake discussion comes in here, too. If an adversary has a large or majority share of coins by QC cracking.

<j​effro256:monero.social> But that doesn't inherently prevent QCs from stealing pre-Carrot coins

<r​ucknium:monero.social> Or, I think in a PoS design, the adversary only needs a majority or 2/3rds of the _staked_ coins to re-org the blockchain, etc., so does not need so much of the total supply.

<r​ucknium:monero.social> So that's a potential blockchain security reason to have an amount _and_ time limit on a PQ turnstile

<j​effro256:monero.social> Actually we can't let any non-coinbase RingCT coins be spent without Carrot since they aren't statistically binding

<j​effro256:monero.social> Okay so maybe I need to layout the spending requirements somewhere

<a​rticmine:monero.social> So effectively only post Carrot or coinbase coins cannot be forged by a QC

<j​effro256:monero.social> We can allow spending pre-RingCT coins as well as coinbase RingCT, because the amount is in cleartext. However, the owners of these would be in a race to spend their coins before a QC cracks their privkey. We can also spend coins made with the Carrot wallet protocol but with legacy addresses, but they're in the same boat where they're racing QCs. The only ones who get to relax are<clipped messag

<j​effro256:monero.social> those with coins addressed to Carrot-migrated addresses, since their address composition gives them some degree of security against being opened by a QC

<j​effro256:monero.social> Coins in confidential amount RingCT txs NOW, before being spent when the turnstile is activated are lost forever

<j​effro256:monero.social> Coinbase coins now can be stolen since a QC can crack the privkey. However, we can still allow spending of them at a protocol level since it wouldn't cause inflation

<s​yntheticbird:monero.social> I'm not sure if this is ethical to let that happen...

<j​effro256:monero.social> At a practical level, depending on the speed of initial QCs, The honest holder might be able to construct a proof of ownership before a QC can. That's why we would allow it

<j​effro256:monero.social> But yea there's also the ethical consideration of monetizing theft of old coins

<j​effro256:monero.social> I think allowing a pathway for old owners to migrate, even if means potentially rewarding key breakers, is the lesser of two evils

<j​effro256:monero.social> Though that might wreak financial havoc on everyone else

<j​effro256:monero.social> I'll leave that analysis to a macroeconomicist

<r​ucknium:monero.social> Is it easier for a QC to counterfeit XMR amounts or break an output's privkey? What would be the first target?

<j​effro256:monero.social> Outputs privkey

<j​effro256:monero.social> If we are making a turnstile, I think we should ban all spending of RingCT outputs which don't have statistically binding amount commitments

<r​ucknium:monero.social> By how much? IIRC, at least one paper about this has said that Monero's outputs are safer than transparent coins' outputs since an attacker doesn't know where the big XMR is. They could be breaking outputs with dust amounts

<r​ucknium:monero.social> Unless they have some off-chain info

<j​effro256:monero.social> Well that's assuming we aren't doing switch commitments. If I had a working quantum computer at this exact moment, I would first go for finding the discrete log between the G and H generators. That would let me mint infinite XMR in perpetuity without ever needing the QC again

<j​effro256:monero.social> But if we ARE doing switch commitments and activate before a QC is working, then they can't attack amounts anymore

<r​ucknium:monero.social> The adversary's intentions would determine the effect on XMR purchasing power. If they don't spend or exchange it, then there may be little effect. Except, there may be an expectation effect because the huge XMR amount could be visible in the turnstile counter.

<j​effro256:monero.social> And have to go for privkeys

<j​effro256:monero.social> Specifically of pre-Carrot addresses

<s​yntheticbird:monero.social> I didn't made the link, but the turnstile will actually make individual outputs' amounts transparent?

<j​effro256:monero.social> Yes

<s​yntheticbird:monero.social> That's bad for privacy but somehow very exciting

<a​rticmine:monero.social> Then there is the quotation of knowledge of the public key

<a​rticmine:monero.social> Question

<r​ucknium:monero.social> It will make the transparent for the turnstile crossover transaction unless some kind of zK proof of turnstile amounts is developed I guess. The blockchain protocol has to count up the amounts somehow

<r​ucknium:monero.social> jeffro256: Does MRL have to come to a "decision" about the switch commitments today, or is it still in development?

<j​effro256:monero.social> It's mostly sorted out how to move forward with Carrot, but there's decisions about how to structure the rules of the turnstile that can be decides later

<j​effro256:monero.social> *decided

<j​effro256:monero.social> So in short, we don't need to make any decisions today AFAICT

<r​ucknium:monero.social> Here's that paper that compares QC risk for a few blockchains: Kearney, & Perez-Delgado (2021). "Vulnerability of blockchain technologies to quantum attacks." moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=80

<s​yntheticbird:monero.social> I've a question

<s​yntheticbird:monero.social> Kayabanerve linked NIST latest recommendations regarding hash security parameters, recommending 384 bit. Kayabanerve is actually against switching to a 384 bit elliptic curve despite a potential risk on 256 bit hash functions ?

<s​yntheticbird:monero.social> May I missed something

<s​yntheticbird:monero.social> Is it something to worry about or not is my question

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

<s​yntheticbird:monero.social> thanks

<j​effro256:monero.social> Thanks everyone !

<a​rticmine:monero.social> Thanks

<c​haser:monero.social> thank you all

<k​ayabanerve:matrix.org> chaser @chaser:monero.social: Yes, a QC can burn existing outputs. They can't burn FCMP++ outputs.

<k​ayabanerve:matrix.org> Rucknium: jeffro256: rbrunner There's two migrations: When we have PQ and no one has a QC, when we have PQ and someone has a QC. The former lets anyone migrate. The latter requires a strongly bound wallet, not just the usage of Carrot.

<k​ayabanerve:matrix.org> Outputs made today (including coinbase) cannot be migrated once a QC is live. Outputs made under CARROT cannot be migrated.

<k​ayabanerve:matrix.org> jeffro256: Coinbase outputs can't be migrated as you can make 1G+1Y keys today. They'd spend with key image 1H(1G+1Y) after FCMP++ activates but if you assume they're xG, a QC can double spend.

<k​ayabanerve:matrix.org> *1T, not 1Y

<k​ayabanerve:matrix.org> You at least need a cut-off date where you assume T was unknown and couldn't already be used which isn't worth it IMO.

<k​ayabanerve:matrix.org> The goal should be to give users five years to make and move to a new wallet, which is internally binding, and allows them to migrate indefinitely. Old outputs, RCT or not, I'd not bother with at all when we disable the legacy crypto except for the defined long-term migration process. I definitely wouldn't support enabling theft.

<k​ayabanerve:matrix.org> SyntheticBird: We could redo the Seraphis migration discussions so we can embed 384-bit hashes into our EC's scalar field. Considering 256-bit hashes shouldn't actually be broken, I don't see it worth the effort when it'll only be done for a few years.

<k​ayabanerve:matrix.org> But if hashes do ever resolve with a cbrt attack, yeah, it'd require turning off on long-term migration scheme at some point as it'd only have 84 bits of security.

<j​effro256:monero.social> Couldn't we do the following for migrating coinbase inputs before FCMP++: 1) do trivial membership where we index the coinbase output directly 2) Calculate Hp(O) 3) Make the signer do a Schnorr-esque signature with proof of equal discrete log between G->O and O->Hp(O) ?

<j​effro256:monero.social> This would burn people's funds if they preemptively formed their coinbase outputs or pre-RingCT outputs by scaling by T before FCMP++, but idk of anyone doing that, it's probably a minority

<j​effro256:monero.social> Sorry, it should be proof of equal discrete log between G->O and Hp(O)-> x*Hp(O), the linking tag

<k​ayabanerve:matrix.org> jeffro256: What?

<k​ayabanerve:matrix.org> Sorry, I don't follow

<k​ayabanerve:matrix.org> Are you proposing a dedicated coinbase TX type for all future coinbases, without privacy today, so that all future coinbases can be migrated?

<k​ayabanerve:matrix.org> *not alleging you endorse it, solely asking if that is the idea

<j​effro256:monero.social> No this would be the input proof for already-existing coinbase and pre-RingCT outputs posted inside a migration tx. The amount obv isn't a problem since it's already in cleartext. Then to prove unspentness, all we need to do is make the signer make an equality-of-disrcrete-log proof between G->O and Hp(O)->L, where G is the generator, O is the output pubkey, and L is the key image<clipped messag

<j​effro256:monero.social> . Let's say that we can write O = x G. The key image L for output O must be in the form L = x Hp(O). Anyone can calculate Hp(O) from public data. The signer needs to provide L, and then make an equality of discrete log proof that proves that for the same x', O = x' G and L = x' Hp(O). I don't know if there is already a proof for this, but theoretically, it should be possible becau<clipped messag

<j​effro256:monero.social> se for a given O, there is *exactly* one `x` and one `L` such that O = x G and L = x Hp(O). A trivial proof would reveal x in plaintext, but that obviously leaks the private key

<j​effro256:monero.social> That would let us spend all coinbase and pre-RingCT, but still prove unspentness in a post-quantum manner

<j​effro256:monero.social> We can't take this approach for FCMP++ outputs because the honest holder won't know the discrete log x such that O = x G

<j​effro256:monero.social> And the reason we have to do weird hash stacking inside the addresses is because there's `l` openings `(x', y')` for every single `O`, which makes unspentness a bit trickier

<j​effro256:monero.social> Whereas with pre-FCMP++ outputs, there's exactly *one* opening of the output, which makes unspentness determinisitic