The Ethereum Foundation mandated Quarkslab to perform an audit of the herumi libraries. They provide an API to perform BLS signatures, one of the core components of the new iteration of the Ethereum blockchain, named Ethereum 2.0. While reviewing the architecture of these libraries, their back ends and the adherence with the ongoing RFCs to standardize BLS signature usage, we found some issues primarily regarding their design. Although these are not considered critical, they impact the overall reliability of the libraries. We provide recommendations to improve the design of the libraries, the readability of the code and the usability of both projects.

This post is a noob-friendly introduction to whiteboxes along with the presentation and explanation of a (not-new) collision-based attack. The attack is demonstrated against a public whitebox, using QBDI to instrument and analyze the target in order to produce traces of execution.

The Tari Labs mandated Quarkslab to perform a cryptographic and security assessment of the dalek libraries. One of the Tari Labs' projects is to implement the Tari protocol, a decentralised assets protocol. It relies on some of the dalek libraries, especially the cryptographic primitives, provided by subtle and curve25519-dalek. Moreover, the use of Bulletproofs [6], and its implementation by the authors of the dalek libraries, will allow them to enable efficient confidential transactions on the blockchain in a near future.

We only found some minor issues. We also provided recommendations on the usage of the libraries and third-party libraries.

Quarkslab's team performed a cryptographic and security assessment of both the Bulletproof and MLSAG protocols in Particl. Bulletproof is a non-interactive zero-knowledge proof protocol, while MLSAG is a new ring signature protocol. Both are to be used in cryptocurrency transactions to ensure that they do not leak the amount exchanged or the exact identity of the buyers. Both implementations were found sound and conform to their respective reference papers [BBBPWM18] [SN15]. The full report of the assessment can be found at the following address: [2]

On how we used LIEF to lift an Android x86_64 library to Linux to perform our usual white-box attacks on it.

Quarkslab was hired by OSTIF to perform a security assessment of OpenVPN 2.4.0. We focused on code and cryptography assessment. Results are briefly described in this blog post, and full report is available at its end.

In recent weeks, Confide, a secure instant messaging application, has gained popularity in some circles. This article presents a quick assessment of the security of this application. The official website boasts the confidentiality provided by the product through three qualifiers: encrypted, ephemeral and screenshot protected. Each of these aspects will be studied.

The encryption protocol will be particularly detailed because it is tagged as battle tested, military grade cryptography. We already knew about military grade cryptography, which seems to be a synonym of put AES-256 somewhere, no matter how you use it in many applications, but we had never heard of battle tested cryptography. This article is an opportunity to present this technology.

Developing properly end-to-end communication systems is complex. As we have seen in the past with iMessage, even if cryptographic primitives are correctly implemented and encryption keys are correctly generated and protected, the design is critical to forbid the service operator from being able to eavesdrop messages.

With the Differential Computation Analysis (DCA) presented at CHES 2016, we have shown that side-channel techniques developed to break hardware cryptographic implementations can be adapted successfully to break white-box implementations. In this post, we will explore another class of hardware attacks: fault injections and how to apply them on white-box implementations.

Quarkslab made a security assessment of VeraCrypt 1.18. The audit was funded by OSTIF and was performed by two Quarkslab engineers between Aug. 16 and Sep. 14, 2016 for a total of 32 man-days of study. A critical vulnerability, related to cryptography, has been identified. It has been introduced in version 1.18, and will be fixed in version 1.19.

When appointing computation of private data to a third party, privacy is an issue. How can one delegate computation without giving up one's secrets? This gets trickier when multiple parties are involved. Several works on Multi-Party Computation (MPC) addressed this issue, but a new approach has started to emerge: Fully Homomorphic Encryption (FHE).