Technical description of the platform
The Waves Enterprise platform gives an opportunity to choose a cryptographic algorithm depending on peculiarities of a project.
Hash coding is performed consequently by the Blake2b256 and Keccak256 functions or the “Streebog” function in accordance with the GOST R 34.11-2012 Information Technology – Cryptographic Information Security – Hash Function. The size of an output data block is 256 bits.
Algorithms for key generation, producing and checking of electronic signatures are based on the Curve25519 elliptic curve (ED25519 with X25519 keys) or correspond with the GOST R 34.10-2012 Information Technology – Cryptographic Information Security – Signature and verification processes of electronic digital signature.
Learn more about generation and verification of electronic signatures with the use of the gRPC and REST API methods.
The platform supports data encryption with the use of the session keys based on the Diffie-Hellman protocol. This operation is used for encryption of any text information, for instance, smart contracts data that must not be accessible to other blockchain participants. Encryption can be performed individually for every recipient with generation of a unique cipher text, as well as with generation of a unified cipher text for a group of recipients.
The algorithms used for symmetric encryption correspond with the AES standard or the GOST R 34.12-2015 Information Technology – Cryptographic Information Security – Block ciphers.
Here you can see the scheme of the text data encryption procedure based on the Diffie-Hellman protocol:
Symmetric CEK and KEK keys are used for encryption and decryption.
CEK (Content Encryption Key) is used for text data encryption. KEK (Key Encryption Key) is used for encryption of a CEK.
A CEK is randomly generated by a blockchain node with the use of the corresponding hash coding algorithms. A KEK is used to encrypt a CEK and is generated by a node on the basis of the Diffie-Hellman algorithm with the use of public and private keys of a sender and recipients.
A symmetric CEK is unavailable for reading and is not demonstrated during the encryption process. It is transferred from a sender to a recipient in an encrypted format (wrappedKey) via insecure channels together with an encrypted message. An example of such insecure channel is a data transaction 112 for recording data into a blockchain, or a smart contract state. A KEK will not be transferred from a sender to a recipient: it is restored by the recipient on the basis of his closed key and a known public key of a sender (Diffie-Hellman key exchange algorithm).
Learn more about encryption with the use of gRPC methods.
WE blockchain platform protects confidential data during transmission. If TLS is not enabled on the network layer, the protection is implemented by the TLS-like protocol: an encrypted TLS-like connection is established. If TLS is enabled, the network channels are encrypted using TLS v. 1.2 (AES-256 CBC SHA); thus, the channel is already protected and requires no additional protection.