This repo contains a port of the OQS/PQClean Falcon 512 Signature Verfication code from C to Solidity in the form of an Ethereum Smart Contract for deployment to a Besu Blockchain. The Ethereum smart contract is currently implemented in a single rather large file: contracts/Falcon.sol.
This solution also contains some associated mocha/truffle tests written in JavaScript. There are 120 tests in all:
- 20 tests against a single set of test data generated by IronBridge
- Tests #1..#18: Validation of the inbound data.
- Test #19 Unhappy Path - All format and type validation requirements are met, apart from the signature which is valid but incorrect.
- Test #20 Happy Path - All data is valid.
- Test the verification step of all 100 KAT tests parsed from the NIST Falcon-512 KAT test suite (falcon512-KAT.rsp).
References:
- https://falcon-sign.info/
- https://falcon-sign.info/falcon.pdf
- https://falcon-sign.info/falcon-round2.zip
- https://falcon-sign.info/falcon-round2.zip/Falcon-Round2/KAT/falcon512-KAT.rsp
This implementation of the Falcon Signature Verification algorithm is a Proof of Concept (PoC) only and, as it stands, is not in a state ready for production. It was done purely as a porting exercise in order to determine viability and to estimate gas requirements.
The Solidity/Smart Contract/EVM environment imposes strict rules and restrictions regarding memory and stack utilisation, and also some quite serious limitations regarding arrays of constants.
- In order to work around the former, many variables and function arguments which were originally intended to be stack based, and hence temporary, have been implemented in "storage", also known as the "Contract State". Apart from increasing gas cost, this also creates a serious vulnerability. In this PoC, no attempt has been made to secure, clear or destroy this data.
- Regarding the latter: there are several large arrays of constants in the original code, and a few more added by myself in the interest of performance. At the time of writing, Solidity does not support arrays of constants, hence these 'constants' are not immutable as intended and could, in theory, be altered in order to break, manipulate or compromise one or more steps in the algorithm.
This list does not intend to be exhaustive - i.e. it is quite possible that there are more vulnerabilities than the two stated above.
Lastly, regarding signature types: Falcon 512 supports a few signature formats. Although every effort has been made to retain all the necessary code for each of the formats, these have not yet been tested or verified.