10:42:04 > However, taking into account projected technological advances in quantum computing, ECDH will not be approved for use beyond 2030. 10:42:05 https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/ism/cyber-security-guidelines/guidelines-cryptography 11:17:33 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. 11:17:47 *AES-256 11:18:52 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). 11:19:59 > 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. 11:20:01 I 11:20:03 don't get it, why prohibiting SHA-256 but allowing SHA3-256 and SHAKE256 11:20:05 > 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. 11:20:07 > don't get it, why prohibiting SHA-256 but allowing SHA3-256 and SHAKE256 11:20:10 > 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. 11:20:11 don't get it, why prohibiting SHA-256 but allowing SHA3-256 and SHAKE256 11:20:14 sorry I just killed IRC 11:20:36 Interoperability. 11:20:50 The ML-DSA, ML-KEM specifications require those. 11:21:22 Which means the Australians can't be conservative without losing support for all hardware implementations of those algorithms. 11:22:44 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. 11:24:28 I don't know exactly how patent works, are al ML based algorithm now under patent, or only NIST draft one (round 4) ? 11:24:41 Like can I take round 3 and tweak it? 11:25:20 https://csrc.nist.gov/csrc/media/Projects/post-quantum-cryptography/documents/selected-algos-2022/nist-pqc-license-summary-and-excerpts.pdf 11:25:21 > NIST has entered into two patent license agreements to facilitate adoption of NIST’s announced 11:25:23 selection of Public-Key Encryption PQC algorithm CRYSTALS-KYBER. NIST and the 11:25:25 licensing parties share a desire, in the public interest, the licensed patents be freely available to 11:25:27 be practiced by any implementer of the CRYSTALS-KYBER algorithm as published by NIST. 11:26:06 Hm. ML-DSA may be unencumbered? I though ML-KEM and ML-DSA were by these patents. 11:27:32 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. 11:27:55 You can only derive from Kyber, and deploy, if you remove the infringing IP or obtain your own license. 11:28:09 (or if the patent expires or if you break American patent law) 11:28:25 I see, I hate patents 11:29:12 Now that I think of it, tevador draft of seraphis with PQ KEX didn't tested Streamlined NTRU 11:29:47 Shouldn't this be explored as well 14:59:58 MRL meeting in this room in two hours. 17:00:33 Meeting yime! https://github.com/monero-project/meta/issues/1127 17:00:37 time* 17:00:47 yreeting 17:00:50 1) Greetings 17:01:02 Hello 17:01:07 Hello 17:01:08 hello 17:01:45 Howdy 17:03:01 *waves* 17:04:26 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 17:04:39 2) Updates. What is everyone working on? 17:06:01 me: Discovered and report a critical privacy vulnerability in Wownero's decoy selection algorithm: https://codeberg.org/wownero/wownero/issues/488 . One lesson: Don't disable the wallet2 decoy sanity checks. Also working on OSPEAD. 17:06:31 me: implementing this optimized torsion check for faster FCMP++ curve tree building: https://github.com/kayabaNerve/fcmp-plus-plus/blob/torsion-check/crypto/divisors/src/tests/torsion_check.rs 17:07:13 Are you going to FFI it or remake it in the crypto ops code ? 17:07:28 the latter, I'm implementing in C++ 17:07:49 / C 17:08:05 hi 17:08:19 been doing Boost 1.87 related things 17:08:43 Me: brainstorming with kayaba on carrot switch commitments, I think we've settled on an optimal scheme considering we use a 256 bit curve 17:08:59 Also drafting changes to the carrot doc 17:09:34 Also found the issue in the code with Wownero's DSA 17:10:06 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. 17:10:17 Is there a bounty on that Wownero stuff? :) 17:10:44 I was paid a WOW bounty 17:10:51 Nice 17:11:21 A wownty, if you will 17:11:45 All operators of Wownero nodes, public and private, should update their nodes to the latest version: https://wownero-node-checker.redteam.cash/ 17:13:27 3) Discussion: preventing P2P proxy nodes. https://github.com/monero-project/research-lab/issues/126 17:15:27 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. 17:16:04 Here is the issue that announces the ban list recommendation, and the ecosystem projects that are enabling it: https://github.com/monero-project/meta/issues/1124 17:17:07 The `@monero` Twitter/X account hasn't tweeted about it yet. That was a goal of the announcement campaign. 17:17:21 I don't know if anything really evolved since last time but Bucket ASMap seems like the next step 17:17:40 So anyone who has the capability to tweet from `2monero` about it, please do so. Use the meta GitHub link: https://github.com/monero-project/meta/issues/1124 17:17:41 and in mid-term/long-term PPoS 17:18:17 Yes, I'll start researching ASmap soon. 17:18:40 Thanks 17:19:01 Anything else on this? 17:20:34 4) Discussion: Post-quantum security and ethical considerations over elliptic curve cryptography. https://github.com/monero-project/research-lab/issues/131 17:21:11 Will be honest, I don't get conceptually whats a turnstile 17:21:53 For ZCash, it's that the total amount of coins in any of its shielded pools cannot go negative 17:21:54 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 17:23:17 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. 17:24:41 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. 17:24:47 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 17:25:16 jeffro256: "This" meaning the turnstile? 17:26:31 Yes 17:26:45 Don't know what to think about that graphic there: https://github.com/monero-project/research-lab/issues/131#issuecomment-2547789303 17:26:58 Will this need heaps of complex code to implement? 17:27:05 With a lot of effort? 17:27:26 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. 17:28:07 rbrunner: Carrot is already almost that complicated right now. I just added a couple edges and shuffled things around to get that proposed graph 17:28:34 Ah, ok. Can't make my mind up right know whether I find that comforting or not :) 17:28:41 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 17:30:41 with the amount being counterfeited or only a boolean at the end ? 17:30:45 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 17:31:19 IMHO that would be really bad. it's essentially burning people's XMR. 17:31:52 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 17:32:08 If quantum computers become a reality, with a turnstile you are already burning their XMR, and giving it to the quantum adversary 17:32:13 As a strategic decision, we could say living with the counterfeited coins is less bad than burning the XMR of a lot of people? 17:32:39 It is more like: If you don't leave the sinking ship, you would sink 17:33:14 I don't understand 17:33:40 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) 17:33:42 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? 17:33:53 This presumes there is no time limit on the turnstile, only an amount limit 17:35:23 ... but if we can detect counterfeiting during the transition this avoids the whole issue 17:35:37 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. 17:35:58 is it certain that a QA can steal existing enotes? 17:36:16 Oh so there is definitely a need for a time limit then 17:36:38 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 17:36:56 Post-turnstile heaven , I like that term 17:36:59 Probably you need an amount limit _or_ an (amount and time) limit. 17:38:01 Saint Peter at the turnstile gate. 17:38:06 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 17:38:54 Just like we can't determine on-chain if someone spent XMR honestly , or "stole" someone else's seed phrase 17:39:16 If you can extract knowledge of the discrete log of output pubkeys, you "own" those coins 17:41:38 So after the FCMP++ hardfork everybody is free to send their coins to themselves to bring it into the "new world" 17:41:50 https://github.com/monero-project/research-lab/issues/131#issuecomment-2537588673 17:41:51 Is this a solution? 17:42:32 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 17:43:12 jeffro256: I agree. 17:43:48 We definitely need to incorporate something like kayaba's sketch in that comment in order to keep the integrity of key images 17:44:26 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. 17:44:35 But that doesn't inherently prevent QCs from stealing pre-Carrot coins 17:45:54 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. 17:46:38 So that's a potential blockchain security reason to have an amount _and_ time limit on a PQ turnstile 17:46:56 Actually we can't let any non-coinbase RingCT coins be spent without Carrot since they aren't statistically binding 17:50:27 Okay so maybe I need to layout the spending requirements somewhere 17:50:42 So effectively only post Carrot or coinbase coins cannot be forged by a QC 17:54:14 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 those with coins addressed to Carrot-migrated addresses, since their address composition gives them some degree of security against being opened by a QC 17:55:22 Coins in confidential amount RingCT txs NOW, before being spent when the turnstile is activated are lost forever 17:56:25 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 17:59:25 I'm not sure if this is ethical to let that happen... 17:59:54 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 18:01:00 But yea there's also the ethical consideration of monetizing theft of old coins 18:02:23 I think allowing a pathway for old owners to migrate, even if means potentially rewarding key breakers, is the lesser of two evils 18:02:57 Though that might wreak financial havoc on everyone else 18:03:48 I'll leave that analysis to a macroeconomicist 18:03:58 Is it easier for a QC to counterfeit XMR amounts or break an output's privkey? What would be the first target? 18:04:37 Outputs privkey 18:05:36 If we are making a turnstile, I think we should ban all spending of RingCT outputs which don't have statistically binding amount commitments 18:05:39 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 18:05:54 Unless they have some off-chain info 18:07:33 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 18:08:05 But if we ARE doing switch commitments and activate before a QC is working, then they can't attack amounts anymore 18:08:10 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. 18:08:22 And have to go for privkeys 18:09:27 Specifically of pre-Carrot addresses 18:09:36 I didn't made the link, but the turnstile will actually make individual outputs' amounts transparent? 18:09:49 Yes 18:10:02 That's bad for privacy but somehow very exciting 18:10:04 Then there is the quotation of knowledge of the public key 18:10:28 Question 18:10:38 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 18:11:50 jeffro256: Does MRL have to come to a "decision" about the switch commitments today, or is it still in development? 18:12:41 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 18:12:55 *decided 18:13:12 So in short, we don't need to make any decisions today AFAICT 18:13:47 Here's that paper that compares QC risk for a few blockchains: Kearney, & Perez-Delgado (2021). "Vulnerability of blockchain technologies to quantum attacks." https://moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=80 18:14:42 I've a question 18:15:41 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 ? 18:15:50 May I missed something 18:17:15 Is it something to worry about or not is my question 18:19:19 We can end the meeting here. Thanks everyone. 18:19:33 thanks 18:20:05 Thanks everyone ! 18:20:32 Thanks 18:21:07 thank you all 21:37:44 chaser @chaser:monero.social: Yes, a QC can burn existing outputs. They can't burn FCMP++ outputs. 21:37:45 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. 21:37:47 Outputs made today (including coinbase) cannot be migrated once a QC is live. Outputs made under CARROT cannot be migrated. 21:39:06 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. 21:39:35 *1T, not 1Y 21:39:53 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. 21:41:47 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. 21:43:07 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. 21:43:43 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. 22:00:32 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) ? 22:01:53 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 22:03:09 Sorry, it should be proof of equal discrete log between G->O and Hp(O)-> x*Hp(O), the linking tag 23:03:57 jeffro256: What? 23:04:13 Sorry, I don't follow 23:04:57 Are you proposing a dedicated coinbase TX type for all future coinbases, without privacy today, so that all future coinbases can be migrated? 23:05:24 *not alleging you endorse it, solely asking if that is the idea 23:46:51 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 . 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 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 23:48:53 That would let us spend all coinbase and pre-RingCT, but still prove unspentness in a post-quantum manner 23:49:42 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 23:51:03 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 23:51:31 Whereas with pre-FCMP++ outputs, there's exactly *one* opening of the output, which makes unspentness determinisitic