Once the LACChain nodes have access to quantum entropy on demand, this entropy is consumed by OpenSSL as illustrated in Figure 2. Permanent quantum-safe cryptographic solutions such as QKD are not scalable today and require substantial investments in infrastructure. Feasible and practical solutions that provide quantum-resistance today involve PQC. Instead of replacing current Internet and blockchain protocols with new ones that incorporate PQC, we tried to introduce PQC in existing frameworks.
Based on the analysis presented above, we decided to use the traditional X.509 standard, which defines an internationally accepted format for digital documents that securely associates cryptographic key pairs with identities such as websites, individuals, and organizations.
By using a modified version of libSSL, the X.509 specification was extended to incorporate post-quantum and Ethereum (ECDSA) public keys, allowing blockchain nodes to use the modified libSSL to establish peer-to-peer quantum-safe channels that leverage those keys. Libssl is the portion of OpenSSL that supports TLS (SSL and TLS Protocols) and depends on libcrypto.
The nodes use the post-quantum keys to encapsulate communication with other nodes and sign transactions broadcasted to the blockchain. We decided to use the same algorithm for the generation of both types of keys (i.e., encryption keys and signing keys). Given the versatility of OpenSSL to incorporate any post-quantum algorithm, the election of the post-quantum algorithm was based on the restrictions inherent in executing blockchain transactions -essentially execution time and payload size- as different algorithms present substantial differences that condition the feasibility of on-chain verifications and storage.
We evaluated the two finalists of the NIST competition in the signature category in round 3 submissions, Crystals-Dilithium and Falcon (after round 4 submissions, NIST selected these two algorithms as recommendations in the digital signature category.). Figure 3 presents some of the differences between these two algorithms in terms of public key size, private key size, and signature size.
Both algorithms are very demanding regarding processing, memory, and amount of random material required to compute keys and signatures. However, Falcon has been acknowledged as the most compact and contains a built-in SHA3 compliant Extendable Output Function (XOF Shake256). The Ethereum VM natively supports the Keccak hashing algorithm upon which SHA 3 NIST FIPS202 is based, but it does not provide the extendable output functions (XOF) required. Further, implementing the shake XOF functionality is not straightforward.
We evaluated the other signing algorithms but speed, complexity, and the fact that we would have to implement a SHA3 compliant ecosystem for the qRNG source to feed those schemes proved Falcon to be the best option. Our solution allows for the incorporation of new post-quantum algorithms, such as those that can be standardized by organizations such as NIST in the upcoming months and years.
To use Falcon, we needed to add a new object identifier (OID), the 1.3.9999.3.1, to libSSL in order to recognize the post quantum Falcon-512 algorithm. The process for the generation of post-quantum certificates is summarized in Figs. (4,5) and broken down into the following seven steps:
The process for the generation of post-quantum certificates is summarized in Figs. (4,5) and broken down into the following seven steps:
Each of these steps is essential and additional useful clarifications are listed below: