Monero Germany

Trail of Bits audit of the FCMP++ crypto was released and discussed; the sole unresolved finding is the “fragile” Rust-C++ Foreign Function Interface (risk if upstream types change or are written on the C++ side), mitigated by static asserts and existing version pinning. Vendoring of critical dependencies received broad support. xmrack identified a detectable double-spend vulnerability in the consensus integration code (github.com/seraphis-migratio…) with LLM assistance. Participants endorsed using all top-tier LLMs repeatedly for audits, alongside classical review, formal verification, fuzzing (including an active fundraiser), and complexity reduction. Concerns were raised about post-HF discoveries by future LLMs or cryptographers, binary-size growth from Rust, and the need for safety-critical hardening. jeffro256 presented a Gantt chart proposing that the 6-month wait before HF activation depend on the first HF-enabled merge to master (not completion of audit parts 2/3), with a 1-month node/p2p/consensus freeze and a 2-month wallet/audit-follow-up freeze. This targets activation in early February if the schedule holds and requires heavy merging over the next month. The plan was accepted as reasonable; no objections were raised. rucknium: Last meeting, some participants wanted to wait for the Trail of Bits audit before making decisions on some FCMP timeline items. It's here now: github.com/trailofbits/publi… rucknium: Is right now a good time to discuss it? jberman: Here's the latest FCMP++ integration PR with github.com/monero-project/mo… jberman: Sure rucknium: Does anyone want to elaborate on what Trail of Bits means by the Rust-C++ Foreign Function Interface (FFI) being "fragile"? rucknium: And that was the only issue they found that was not completely resolved by a fix. jberman: They mean that if the upstream type changes and/or is written to on the C/C++ side, it may be rendered incorrect. Since the upstream type comes from another lib (a fork of crypto-bigint), we'd have to be careful of that occurring. The static asserts included are a strong defense in the event of such a scenario rucknium: I will ping jeffro256 too syntheticbird: I like their concerns but serialization would kill performance DataHoarder: unsafe{ performance } rucknium: So we need version pinning on the external library. I think you already do that anyway. jpk68: It would be nice if the code could be vendored into a separate repo (not src/fcmp_pp/fcmp_pp_rust, I mean the dependencies) DataHoarder: jpk68: Given that even this recent PR had mismatching versions of several core packages, vendoring critical dependencies would be a plus jberman: rucknium: Yes, we do pin versions. We'll probably need to update to a more recent version of the upstream lib at some point (I think we need to already), and so we'd want to double check it with that latest version we update to DataHoarder: Changes to these would be more obvious in reviews and allow dev copies in other platforms to not depend on crates.io or the specific git/forge they are stored, but have code local rucknium: IIRC, tobtoht is keen on vendoring external libraries. syntheticbird: rightfully rucknium: More comments about the ToB audit? jberman: Vendoring sounds fine to me. kayabanerve may have thoughts there too rbrunner: So watching the original libs for importing changes to "vendor in" again is the lesser evil? DataHoarder: About the uninitialized receiver/output, that's a kind of scary find. I found similar issues on other languages/code while implementing parts of Monero (which caused some fun aftermath words.filippo.io/dependabot ) DataHoarder: ToB recommends additional steps to prevent issues like this in the future/more static tooling. Would that sort of hardening be sought for? jpk68: I would also like to bring up the impact of FCMP++ Rust code on binary sizes. I seem to remember tobtoht suggesting we remove the 'utility' binaries from release archives on the site to save space because of the increase. DataHoarder: Specially as a lot of the Monero crypto code, while sounds, comes from the legacy times where it was all uncommented single-letter variables, which took time to untangle (see biased hash / elligator 2 for the hash to point / key image) jpk68: IMO, we should reconsider applying the strip option to the release profile, and maybe fat LTO jberman: Imo more relevant than the ToB audit as it relates to FCMP++ audit work generally: jberman: xmrack identified a detectable double spend vuln in the consensus integration code, highlighted here: github.com/seraphis-migratio… jberman: This (consensus integration) would have fallen under the scope of "Phase 3" in the integration audit plan rucknium: If I may ask, did an LLM assist with finding ack-j 's bug? DataHoarder: 👍️ > jberman: xmrack identified a detectable double spend vuln in the consensus integration code, highlighted here: github.com/seraphis-migratio… rucknium: Trying to understand the role of LLMs in finding these types of bugs. jberman: rucknium: Yes syntheticbird: what LLM ? jeffro256: He mentioned using Opus on a different FCMP report jeffro256: So maybe Opus? sech1: It doesn't matter, all of the available top-tier LLMs should be used to check this code for vulnerabilities. And multiple times. syntheticbird: alr syntheticbird: sech1, i agree on that and i am not trying to frame one model to be better than another, it's just curiosity. jberman: sech1: I'm in favor of this as well syntheticbird: speaking of LLM audit I came across github.com/evilsocket/audit recently syntheticbird: for those who have the tokens probably worth a try DataHoarder: that looks neat for a more automated setup rucknium: Just thinking out loud: If today's LLM catches critical bugs now, and tomorrow's LLM is even better, then what happens when tomorrow's LLM finds a critical bug after the hard fork occurs? rucknium: I don't like this new reality :( DataHoarder: There should not be just LLM review, it's in addition to any other normal reviews syntheticbird: Continuing on thinking loud: useless to recall how blueteam and other malicious actors caused a surge in critical vulnerability exploits on many DeFi projects when Opus started coming out syntheticbird: blueteam = v12 = zellic DataHoarder: rucknium: This can be changed to "If today's cryptographers catches critical bugs now, and tomorrow's cryptographers learn new research then what happens when tomorrow's cryptographers finds a critical bug after the hard fork occurs?" and still has the same meaning, use all available way to audit and protect/cover. gingeropolous: difference is, joe shmoe can run an llm ... but joe shmoe isn't a cryptographer rucknium: Does Monero code need to do what aerospace code does and over-engineer all the code and code-writing processes in safety-critical areas? DataHoarder: ☝️ > rucknium: Does Monero code need to do what aerospace code does and over-engineer all the code and code-writing processes in safety-critical areas? vtnerd: I would also expect diminishing returns on the llm advancement, but that's just a fut feeling vtnerd: *gut DataHoarder: There's areas that can be upgraded/covered and others that cannot without consensus-breaking changes (or tightening that need to be hidden) boog900: You would be asking for like a full rewrite :) jeffro256: We could have said the same thing about cryptographic research by humans, albeit on a slower timeline. If cryptographic knowledge gets better and better, what hppens when people figure out ways to break current cryptography? The answer has to be vigilance and the constant cat-and-mouse game, like it always has been syntheticbird: boog900: yeah this lmao DataHoarder: Specially if you cannot "hide" such changes in patches like done in the past (for example, the double-spend bug related to twisted outputs) rbrunner: This boomer would advice, in addition to everything already said, to take each and every chance to avoid complexity rucknium: We are at a specific inflection point in time. Like when old-style crypto was being broken. selsta: not sure if this was linked yet but ack-j also has a fundraiser for fuzzing, including fcmp++ (though afaik this won't include LLMs, just regular fuzzing) donate.magicgrants.org/moner… syntheticbird: DataHoarder: well there was an instance of hiding failure syntheticbird: in the past rucknium: I don't mean to throw a wrench in the gears, but there have been at least 3 privacy coin counterfeiting bugs revealed this year (Litecoin MWEB, Zcash Orchard, Beam). DataHoarder: And with today's automation flows you can even review binary changes and recover original flow/intent to do even tighter analysis/diffing across releases to catch not mentioned changelog items. syntheticbird: rucknium, I agree with you that crypto out of all other domains are the ones being hit the hardest on AI vulnerability findings because of the extreme investment to reward ratio. We can't just ignore it DataHoarder: rucknium: Then I'd repeat my above concern with the uninitialized output, which could have caused "fun" issues, and work on ways that such issues could have been captured early on syntheticbird: i sounds like an AI bro and I hate it DataHoarder: Some process that can run concurrently, or within PRs as well in a lighter form, and generally review incoming areas or overall integration using classical methods or anything needed. Even pointing out general "Smell" should be a cause of concern if we are talking about safety-critical areas. rucknium: Full disclosure: I sort of predicted this problem and my old mindset is coming back. I'm not a cryptographer nor a real programmer, so what do I know? :D syntheticbird: DataHoarder: generally my philosophy is that if safety is critical, your must increase formal verification coverage jpk68: Sorry for bringing this up for the hundredth time, but as others have stated, it's extremely important to reduce unnecessary code complexity (which can shelter exploits). I think introducing Rust with FCMP++ is doing exactly the opposite of this; potentially investing in the code being rewritten to avoid such complexity would maybe be worthwhile. boog900: No that would take too long jpk68: FCMP++ already brings a huge number of changes in critical pathways; the FFI stuff is not helping the matter DataHoarder: syntheticbird: then such formal verification should be in PR, I agree. And that should be included along jpk68: boog900: Not before the hardfork per se, I just mean eventually boog900: eventually I agree boog900: I want multiple impls jpk68: I would totally be against delaying the hardfork for that syntheticbird: boog900: I want variable time for nodes DataHoarder: > jpk68: Sorry for bringing this up for the hundredth time, but as others have stated, it's extremely important to reduce unnecessary code complexity (which can shelter exploits). I think introducing Rust with FCMP++ is doing exactly the opposite of this; potentially investing in the code being rewritten to avoid such complexity would maybe be worthwhile. DataHoarder: I generally agree that the Rust monero-oxide/Cuprate rewrite is vastly easier to read/follow than C++ specially when using undocumented load-bearing crypto operations from cryptonote era :) jpk68: selsta: And fuzzing as well, of course ^ syntheticbird: its 44 shouldn't we move to another topic ? syntheticbird: rucknium: boog900: On the list of big C++ work that needs to be done I wouldn't put an FCMP rewrite high though rucknium: IIRC, jeffro256 wanted to get input on timeline for integration audit parts 2 and 3 rucknium: So we should get that input in this agenda item unless jeffro256 does not want it at this meeting. jeffro256: Yes, I asked the question last MRL IIRC, whether the 6-month wait period should depend on the completition of audit parts 2 and 3. I don't think it should, but I think we should plan for audits 2 and 3 to completelt at least 3 months before the HF activation date, and plan for a period of follow-up development where we fix issues, if any, from those audits parts. rucknium: And we were promised a Gantt chart :) jeffro256: ;) jeffro256: html-preview.github.io/?url=… syntheticbird: lmao jberman: jeffro256: I have the same view jeffro256: Some people wanted to see the first audit report findings before making the decision. I think that link has already been shared, correct? syntheticbird: Yes > rucknium: Agenda item 3 ^ syntheticbird: below i miss click rucknium: jeffro256: Yes jeffro256: With that current Gannt chart I shared, according to discussions in NWLB yesterday, I have the 6-month wait period before HF activation depend on the first HF-enabled merge to master. I have a 1 month node/p2p/consensus code freeze dependent on that merge too. I have a 2 month code freeze on wallet features and any audit-related follow-up development before the HF activation jeffro256: Does all of that sound reasonable? rucknium: jeffro256: Thanks for the detailed chart rucknium: jeffro256: Sounds ok to me jeffro256: That puts FCMP++ HF activation at the beginning of February if we stay on this schedule rucknium: Anyone else want to comment on jeffro256 's proposed plan? jeffro256: Which means locking in for a lot of code merging for the next month rucknium: And if not, anything else to discuss during this agenda item? kayabanerve: Vendoring Rust crates sounds fine to me, in a repository or under Monero. There's support for that in cargo and I've done it before. I think aggressively pruning unused libs with patch files may really drop the LoC to just the libs we actually use. For example, we have 150k lines of Rust's bindings to libc, and I don't believe we use any of them and it's just a overzealous inclusion in the graph of what _could_ be a dependency that we can manually kick out. For the libraries we do actually use, I'd recommend a solution such as cargo vet, as that will have us still use the libraries and make updating feasible. We can discuss forking libs on a case-by-case basis from there. libera.monerologs.net/monero…