Bulletproofs are a specific type of range proof based on new cryptography by Benedikt Bunz et al. Bulletproofs are a trustless proofs setup that are substantially smaller than the current Borromean style range proofs that were previously used, which reduces the size of Monero transactions by 80-90%.

Monero’s latest network update, which is now live, has enabled Bulletproofs and corrected all outstanding issues that were raised by the Kudelski and QuarksLab projects.

QuarksLab found:

8 Critical Vulnerabilities

2 Medium Vulnerabilities

20 Low or Informational Vulnerabilities / Concerns / Recommendations

One live-chain critical flaw identified and fixed:

QuarksLab found a denial of service vulnerability that could allow an attacker to arbitrarily crash Monero nodes remotely, creating a vulnerability for a large-scale denial of service campaign for the Monero network and further potentially leading to a 51% attack and forced chain split, ultimately leading to double-spends.

Because this flaw impacted live code, OSTIF, QuarksLab, and the Monero team agreed to a disclosure embargo on this report until after the latest network upgrade that forced users to upgrade their nodes to patched code. The Monero XMR network is now safe from this flaw.

Other serious bugs that were identified and fixed:

A lack of null value checks in the Bulletproofs proving algorithm. The bulletproofs code relies on values being passed to it not being null, but did not proactively ensure that null values cannot be passed or checked for.

The bulletproofs code relies on values being passed to it not being null, but did not proactively ensure that null values cannot be passed or checked for. Dependent Generators in original java version of Bulletproofs are not secure. The code had to be revised to improve number generation.

The code had to be revised to improve number generation. Overflow in double scalar multiplication. The code needed to be patched to prevent the overflow of data.

The code needed to be patched to prevent the overflow of data. Erroneous identity output in Bos-Coster multi-exponentiation. The structure of the code could select the wrong input and return incorrect values.

The structure of the code could select the wrong input and return incorrect values. Silently discarded element in Pippenger multi-exponentiation. An optimization designed to discard large numbers of leading zeros could return the identity if a value of x^0 was entered into the function, meaning that the operation can return the identity unmodified. The optimization also had the additional issue of possibly discarding critical values for exact powers of two as inputs.

An optimization designed to discard large numbers of leading zeros could return the identity if a value of x^0 was entered into the function, meaning that the operation can return the identity unmodified. The optimization also had the additional issue of possibly discarding critical values for exact powers of two as inputs. Invalid Verify input parameters. There are no checks that the points provided are indeed points of Ed25519 and that they are on the main subgroup.

There are no checks that the points provided are indeed points of Ed25519 and that they are on the main subgroup. Key compromise in Schnorr signature. In order to generate a valid Schnorr signature, the value k cannot be null or zero. If the value is null, an attacker can detect this and know the value of the key used to sign. If the value k is zero, then the value of the result is independent of the key and invalid. Checks needed to be added to the Schnorr signature to verify that the value k is not null or zero.

In order to generate a valid Schnorr signature, the value k cannot be null or zero. If the value is null, an attacker can detect this and know the value of the key used to sign. If the value k is zero, then the value of the result is independent of the key and invalid. Checks needed to be added to the Schnorr signature to verify that the value k is not null or zero. Failures in input size validation during (de)serialization. A serialization error could allow an attacker to allocate up to 4GB of memory by initializing a value of 0 for nbp. Consequently, this can lead to memory being allocated for partially completed containers.

A serialization error could allow an attacker to allocate up to 4GB of memory by initializing a value of 0 for nbp. Consequently, this can lead to memory being allocated for partially completed containers. Failures in input type validation during (de)serialization. A lack of robust checking for input type error from untrusted sources can lead to undesired behavior and error states.

A lack of robust checking for input type error from untrusted sources can lead to undesired behavior and error states. Twenty other recommendations to improve security, robustness, practices, and performance. The team also made a number of recommendations to code practices to improve the robustness of Monero code, to optimize performance, to improve error handling, and to reduce the attack surface of the software.

This is the second of two audits that were conducted for Monero Bulletproofs. The first audit of Bulletproofs was conducted by Kudelski Security and the results are here.

If you would like to review the full QuarksLab audit the direct link is below: (please do not hotlink directly to the PDF, we would like visitors to come to the OSTIF site, it helps us gain more support for the cause, thank you!)

https://ostif.org/wp-content/uploads/2018/10/OSTIF-QuarksLab-Monero-Bulletproofs-Final2.pdf

We are working hard to make open source software safer and easier to use. Follow our activity both on our website and through our Twitter.

The Open Source Technology Improvement Fund, Monero Research Lab, QuarksLab, and the Monero community have come together to sponsor in-depth research looking into Monero Bulletproofs. The audit was funded by Monero community donations, with coordination and exchange support from OSTIF. The audit was conducted by QuarksLab. We’d like to thank our OSTIF sponsors Private Internet Access, ExpressVPN, and DuckDuckGo, for making OSTIF possible and helping to make this opportunity happen.