Merge pull request #22 from lacchain/update-image

Update PostQuantum image version of Besu
lacchain · Feb 27, 2024 · b8c79a6 · b8c79a6
2 parents 9c76030 + b5d02df
commit b8c79a6
Show file tree

Hide file tree

Showing 3 changed files with 4 additions and 4 deletions.
diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml
@@ -13,7 +13,7 @@ jobs:
     runs-on: ubuntu-latest
     services:
       besu:
-        image: ghcr.io/lacchain/lacchain-besu:23.7.3.0-rc2-amd64
+        image: ghcr.io/lacchain/lacchain-besu:23.7.3.0-amd64
         env:
           BESU_NETWORK: dev
           BESU_MIN_GAS_PRICE: 0

diff --git a/README.md b/README.md
@@ -1,6 +1,6 @@
 # Falcon512 Signature Verification in Solidity
 
-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 repo contains a port of the OQS/PQClean Falcon 512 Signature Verification 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
@@ -19,7 +19,7 @@ References:
 
 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.
+The Solidity/Smart Contract/EVM environment imposes strict rules and restrictions regarding memory and stack utilization, 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.
 

diff --git a/test/falcon_constants.js b/test/falcon_constants.js
@@ -42,7 +42,7 @@ const FALCON_SIG_3_CT         = 3; // Fixed-size format amenable to constant-tim
                                    // the 'CT' format also prevents information about the signature value and the signed data hash to leak through timing-based side channels (this feature is rarely needed).
 const FALCON_SIG_4_INVALID    = 4;
 
-const FALCON_PRECOMPILED_ADDRESS = "0x0000000000000000000000000000000000000014";
+const FALCON_PRECOMPILED_ADDRESS = "0x0000000000000000000000000000000000000065";
 
 module.exports = {
     FALCON_ERR_SUCCESS,