Penetration Test Report (QuarksLab): Report Quarkslab1

RandomX
Security Audit
Organized by the Open Source Technology Improvement Fund
Ref. 19-07-610-REP
Version 1.0
Date July 30th, 2019
Made for OSTIF & Monero Research Lab
Conducted by Quarkslab
Quarkslab SAS
13 rue Saint Ambroise
75011 Paris, France
Contents
1 Project Information 1
2 Executive summary 2
2.1 Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Issues and recommendations summary . . . . . . . . . . . . . . . . . . . . . . . . 3
3 Context 4
3.1 Description of the request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3 Chronology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4 Proof-of-work algorithm specifications 6
4.1 Audited versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3 Observations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3.1 Usage of hardcoded strings. . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3.2 Warnings against RandomX components reuse . . . . . . . . . . . . . . 9
5 Cryptographic primitives 10
5.1 BLAKE2b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2 Argon2d . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.3 AES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.3.1 AesGenerator1R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.3.2 AesGenerator4R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3.3 AesHash1R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6 Code review 14
6.1 Audited versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.2 Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.4 Code structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.4.1 JITted vs Interpreted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.4.2 Cryptographic primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.5 Observations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.5.1 Instruction semantics consistency . . . . . . . . . . . . . . . . . . . . . . 15
6.5.2 Program memory considerations. . . . . . . . . . . . . . . . . . . . . . . 15
6.5.3 Hard-coded constants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.5.4 CPU utilization in SuperscalarHash Programs . . . . . . . . . . . . . . . 17
6.5.5 JIT compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.5.6 Superscalar instruction creation . . . . . . . . . . . . . . . . . . . . . . . 19
6.5.7 datasetOffset computation . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.5.8 RandomX src == dst handling in instructions . . . . . . . . . . . . . . . 21
6.5.9 Check size of Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.5.10 Overall testing considerations . . . . . . . . . . . . . . . . . . . . . . . . 22
6.5.11 Code quality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7 Conclusion 23
Public
Bibliography 24
Ref.: 19-07-610-REP Quarkslab SAS 2
Public
1. Project Information
Document History
Version Date Details Authors
1.0 30/07/2019 Final version Laurent Grémy, Christian Heitman
and Philippe Teuwen
Quarkslab
Contact Position E-mail address
Frédéric Raynal Quarkslab CEO fraynal@quarkslab.com
Matthieu Duez Service Manager mduez@quarkslab.com
Laurent Grémy R&D Engineer lgremy@quarkslab.com
Christian Heitman R&D Engineer cheitman@quarkslab.com
Philippe Teuwen R&D Engineer pteuwen@quarkslab.com
Open Source Technology Improvement Fund
Contact E-mail address
Derek Zimmer derek@ostif.org
Monero Research Lab
Contact E-mail address
Howard Chu hyc@symas.com
Ref.: 19-07-610-REP Quarkslab SAS 1
Public
2. Executive summary
2.1 Synthesis
Quarkslab has studied the security of the Monero Research Lab’s new Proof-of-Work algorithm
called RandomX. The evaluation was spread over about three weeks for a total of 32 days with
three engineers. It took over from three other security audits, all four made possible thanks to
the Open Source Technology Improvement Fund.
Therefore, to maximize the value of a fourth review, Quarkslab focused part of its efforts on:
• the analysis of a few areas less covered by the previous reports,
• the analysis of the previous reports, the responses of Monero Research Lab, and the
subsequent changes in the code and in the specifications.
Despite a highly complex and radically new subject, the documentation and code of RandomX
were of very high quality. All the attack paths we could think of had already been taken into
account or at least studied in the previous audits. Then we reviewed the previous reports, the
Monero Research Lab replies and their subsequent code changes. We agree with them.
Moreover, we didn’t find any significant optimization of the proof-of-work algorithm, even with
approximations.
We only found minor inconsistencies and formulated a few recommendations. These recommen-
dations are mainly relevant when using alternative configurations but they are not so important
with the current configuration and usage of RandomX.
We chose the terms Medium, Low and None to define their priority in the following table. We
didn’t include some of our recommendations in this table as they had already been mentioned
in the previous reports, still we mention them in this report.
The provided tests could be enhanced by adapting them to work beyond the default RandomX
configuration and strengthening the tests of the more complex components such as the JIT
version of the VM.
Ref.: 19-07-610-REP Quarkslab SAS 2
Public
2.2 Issues and recommendations summary
ID Issue and recommendation Impact
To prevent the use of an abnormally short Argon2d salt, the docu-
RNDX-M1
mentation of the configuration should clarify the allowed values of Medium
(p 10)
RANDOMX_ARGON_SALT as being in the range going from 8 to
232−1(inclusive)andthecodeshouldchecktheArgon2d parameters,
e.g.,byusingapatchedversionofrxa2_validate_inputs (skippingthe
check on the length of the output as RandomX does not use the out-
put).
The specifications of the datasetOffset computation must be adapted
RNDX-M2
to reflect the use of the modulus. The risk exists for other currencies Medium
(p 20)
choosing customized RANDOMX_DATASET_EXTRA_SIZE and
implementing alternative clients based on the specifications to end
up with two types of clients giving different PoW hash results.
We recommend checking the size of the RandomX input key although
RNDX-M3
it may require some extra modification as API functions don’t return Medium
(p 22)
error codes. It can also be explicitly stated in the specifications what
happens when a longer key is used.
PermittedvaluesforRANDOMX_ARGON_LANES shouldbeupper
RNDX-L1 bounded in the configuration document to 224 − 1 (inclusive) and Low
(p 10)
RANDOMX_ARGON_ITERATIONS should be upper bounded to
232−1 (inclusive).
Permitted values for RANDOMX_ARGON_MEMORY should be
RNDX-L2
lower bounded in the configuration document to 8 (as AR- Low
(p 10)
GON2_SYNC_POINTS = 4) and not 1.
To avoid misunderstandings, we suggest to mention explicitly the 64-
RNDX-L3
byte alignment of mx in the specifications in 4.6.2.5 (loop). Similarly, Low
(p 20)
thealignmentofma shouldbeaddedin4.5.3(initialization)or4.6.2.7
(loop).
Provided that they diversify the other existing configuration param-
RNDX-N1
eters, RandomX alternatives can work with the various s