Check our terms and conditions, privacy policies, and cookies policy.
Copyright 2024 © All rights Reserved. Designed by LACNet
Communication between nodes is made through the protocol established by the blockchain technology and varies depending on the network used. In the case of the LACChain Besu Network used for this pilot, nodes communicate via TCP and use the RLPx for data encryption (this is the same for the Ethereum mainnet, as Hyperledger Besu is an Ethereum client.) This protocol seals messages with a ECDSA signature on curve SECP251k1 to link the network message to a peer address. We decided not to modify this protocol because that would require maintenance of a new blockchain technology. Instead, our goal was to keep using the Hyperledger Besu technology and develop a layer on top to make it quantum-resistant.
With the aim of developing a layer-2 solution that could be used by any blockchain with any communication protocol and that would not be invasive to the protocol (i.e., does not require layer-1 modifications), our solution consist of adding a point-to-point TLS tunnel modified to support post-quantum keys where the post-quantum X.509 certificates are used for identification and authorization.
For the pilot, we used Falcon-512 asymmetric keys. As this is built on a TLS connection that is not sensitive to the key length, unlike blockchain transactions, it is possible to use other post-quantum algorithms. However, in order to be consistent with the use of a single post-quantum algorithm in the different phases of the pilot, we used Falcon-512.Â
Once this tunnel is established, each node must route the traffic aimed at its counterpart through the TLS tunnel, making it unfeasible for a quantum computer to intercept the traffic and impersonate a node. This protects the blockchain network from different types of attacks. For example, because we are not modifying the blockchain protocol in our permissionless network, the node producers that vote for the generation of new blocks are still materializing this vote in an ECDSA signature (the consensus protocol requires 2/3+1 of node producerâs signatures for a block to be considered valid) that is neither replaced not complemented with a post-quantum signature. However, if a hacker was to discover all the private ECDSA keys of the validator nodes and tried to tamper with the block production by changing the valid transactions and use the validator nodesâ signatures to sign them, it could not achieve it because it cannot intercept the communication between nodes where they could
provoke this type of man-in-the-middle attack. The hacker would need to hack and access each of the validator node servers,
for which quantum computers present no advantage.
In any case, despite the fact that we believe this threat is removed with our solution, it would be easier and more convenient to modify the Ethereum protocol so cryptographic algorithms different from ECDSA, such as Falcon-512, are recognized and can be used by validator nodes to sign blocks.
Check our terms and conditions, privacy policies, and cookies policy.
Copyright 2024 © All rights Reserved. Designed by LACNet