Technical Assessment of the herumi Libraries

Introduction

The new iteration of Ethereum 2.0 comes with a lot of new features. With these new features also comes the use of new cryptographic schemes, especially the BLS signatures [5]. Indeed, one feature of the BLS signatures is their ability to be short: by using the minimal-signature-size variant on BLS12-381 [8] , the signatures are 48-byte long compared to 96-byte long using the classical ECDSA signatures on the secp256k1 curve, for the same level of security [6].

There exist multiple implementations of the core operations to perform BLS signatures, for example Algorand, blst, Milagro, MIRACL, RELIC and herumi libraries [1]. The differences between all these libraries are the efficiency of the computations, the adherence with the last RFCs [6] [7] and the Ethereum 2.0 specifications, the security considerations and the different bindings from a C or assembly level to mainly Go and Rust.

Among the herumi libraries, we especially reviewed the bls [2] and mcl [3] libraries. The mcl library provides all the underlying arithmetic operations through different back ends to the bls library. These different back ends allow the user to select the optimal one depending on the purpose of the applications built upon the bls and mcl libraries.

The Ethereum Foundation ordered a technical and security review of both libraries. The Quarkslab assessment was spread over one month and a half for a total of 68 days with two engineers. The full report of the assessment can be found here.

Scope

The primary goals of this audit were to verify that:

• the implementation follows the specifications;

• the implementation can be used in a security-sensitive context;

• the documentation allows a user to use the libraries in the safest possible way.

The audit had been divided into three main stages, which were:

• Stage 1: focused on the architecture of the code, the interaction between the bls and the mcl libraries, the different back ends.

• Stage 2: focused on identifying the different relevant parts in the specifications, especially the RFCs.

• Stage 3: focused on the code itself, its design, its adherence with the specifications.

Results

We provide in the Chapter 6 of the full report [4] a list of findings and recommendations. It is important to keep in mind that, although the findings are not classified as critical, they do represent a potential risk to the libraries. The current design choices, the complex nature of the implementation of the back ends and the multiple parametrizations of the libraries make it prone to subtle bugs that might be present in the code base. Here we point out some of the most concerning issues:

• Lack of documentation. There is very little documentation on both projects. This turns into an important issue since it may prevent the user from building the libraries in the correct and safe way as well as using the libraries in the intended manner.

• Inconsistent back end interface. Each back end implements and initializes the key operations in its own way. This makes quite difficult to properly assess the implementation, given its complex nature and the many employed optimizations. Moreover, comparison between different back ends is complex as well.

• Ambiguous interaction between back ends. The design of the mcl library allows the many back ends to co-exist. That is, when an operation is not available in one back end, the implementation of another back end is used, in a sort of fall back mechanism. Most probably this approach was taken to ease the implementation and subsequent optimization process. However, it makes difficult to determine with accuracy which implementation is being used under any given parametrization. This turns into a disadvantage from a security and correctness perspective given the sensitivity of the two libraries. This issue is closely related to the previous one.

• Ambiguous libraries parametrization. The main parameters are related to the selection of the back end; however, there are other ones that have an impact on the behavior of the libraries and are not properly documented. Some of them are from external libraries, which are not documented as well. We consider there is a risk the user could build the libraries in an inconsistent way without noticing.

Conclusion

As mentioned, most of the main issues are related to the design choices, which allow great flexibility to try and benchmark different optimizations during the development phase. However, they turn into an issue from the correctness and security perspective.

Tackling theses issues will improve the library in a significant way. It will bring clarity, consistency and robustness to the library, therefore increasing its reliability.

Considering our findings, we recommend addressing the remarks made throughout the report before going forward with the integration of the library into a production-like context.

The full report of the assessment can be found here.

We would like to thank the Ethereum Foundation for making this assessment possible.