<ofrnxmr:xmr.mx> @jeffro256: Yeah. I thought i was remembering wrong. When running out of inputs, it would do random numbers. Thanks for correction

specific implementation Bulletproofs bug in Beam beam.mw/blog/news/hardfork-six

Not applicable to Monero?

no

<rucknium> Thanks DataHoarder . This section caught my eye:

<rucknium> > This was a very difficult vulnerability to discover, and it is worth noting that before the release of its mainnet in 2019, Beam code underwent security audits by several companies, which did not identify it:

<rucknium> > Kudelski

<rucknium> > Least Authority[... more lines follow, see mrelay.p2pool.observer/e/wd7J25QLYXhVXzdV ]

<rucknium> I don't know if the bulletproofs part would have been in-scope for any or all of those audits.

(AI review did find a similar bug on my original BP implementation)

<rucknium> In Go?

yes

not BP+, it was in some untested part for generating proofs

In this case the transcription being done at the wrong time with wrong parts requires in-depth knowledge about how BP works, plus what could go wrong, plus novel ways of attacking it

which The AI (TM) doesn't do as well, it's good at finding more samples of know issues or documented methods, but not novel ways or approaches

<rucknium> IIRC, a few years ago Sarang (IIRC) caught a bulletproofs implementation bug that affected several codebases. I wonder how that bug compares to this one.

<rucknium> Back then, the write-up said "only someone intimately familiar with bulletproofs would have seen this" or something like that. I think.

I used the BP+ proof generation in Go (and CLSAG) the other day to make the sweep tx that the normal wallet couldn't do, so at least that's good and accepted :)

Hmm, I only find the other audit results

blog.quarkslab.com/security-audit-of-monero-bulletproofs.html this also lists a few specific issues on areas that got used by BP, not BP itself

<rucknium> This one: blog.trailofbits.com/2022/04/13/par…ting-girault-bulletproofs-and-plonk

<rucknium> Maybe Sarang didn't initially discover it.

that link describes the issue that affects beam too :)

<rucknium> Is it really the same issue?

but it's also wide/generic, it just mentions the class of vulnerabilities

maybe blog.trailofbits.com/2022/04/15/the…heart-vulnerability-in-bulletproofs ?

as the original paper had a mistake

(this is one of the later parts mentioned on your link)

they define "Frozen Heart vulnerability" as any vulnerability that allows forging of proofs due to bad inclusion of values on the transcript/challenge

so the "general process to forge" is out there, but not the specifics.

<ofrnxmr:xmr.mx> didnt he find it when implementing monero bps, meaning our version never had the issue due to his design choice > <@rucknium> IIRC, a few years ago Sarang (IIRC) caught a bulletproofs implementation bug that affected several codebases. I wonder how that bug compares to this one.

<sgp_> "hold my beer" > <@rucknium> Thanks DataHoarder . This section caught my eye:

<sgp_> I provided the prompt as simply:

<sgp_> > Perform an audit of the bulletproofs implementation in this Beam branch: github.com/BeamMW/beam/tree/beam-7.5.13882

<sgp_> it found the issue in about 1 minute and has spent the rest of the time writing and testing PoCs to fully test the scope

<rucknium> It found the issue after the issue was published on the internet :D

but before it was trained with

<sgp_> nah it didn't know of this one. It found this one but missed the Bisq one from this week (the test was run after it was paused)

<sgp_> fwiw this is after a month of carefully curating resources for it to efficiently have on-hand, including for bulletproofs

<sgp_> - **[CRITICAL] BEAM-BP-01 — Inner-product Fiat-Shamir challenges derived before the round L/R messages → range-proof soundness break → coin inflation.** In `InnerProduct::Challenges::Init` (`core/ecc_bulletproof.cpp:476-485`) and the matching prover loop, each reduction-round challenge `x_i` is squeezed from the `Oracle [... too long, see mrelay.p2pool.observer/e/x7mV3ZQLOUdVb1Zp ]