**The CREDITS platform security**

The use of advanced encryption technology and hashing gives maximum safety for our users’ data and funds.

**BLAKE2s algorithm**

This algorithm is used to embed a BFT consensus when checking a node functionality by the means of a checksum.

BLAKE2s algorithm is a version of the BLAKE2 algorithm optimized for 8 to 32 bit platforms. It is a lightweight, fast and reliable hash function. The algorithm, based on the HAIFA design, was developed by a team of Swiss cryptographers. The compression function is based on an improved scheme of Davis-Meyer.

The BLAKE2s algorithm offers several advantages:

- an improved compression function;
- a reduction in the number of constants;
- a parameter block which consists of initialization vectors;
- an accelerated data transmission with the number of rounds reduced from 14 to 10 (compared to BLAKE-256). As a result, the number of cycles per bit has decreased from 7.49 for BLAKE-256 to 5.34 for Blake2s. This changes the results in an acceleration of approximately 25% and 29% respectively for the transmission of large amounts of data. The transmission speed of lightweight data has also significantly improved.

*Improving the compression function*

*Improving the compression function*

If required, BLAKE2 fills the last block of data with null bytes. If the data length is a multiple of the block length, these are not added.

BLAKE2 introduces identifiers of completion as auxiliary inputs for the compression function, increasing its security.

BLAKE2s supports data hashing to a maximum of 2 64 - 1 bytes, i.e. almost 16 exbibyte (the amount of memory available for 64-bit processors).

Use "salt processing" which is a string of data that is passed to the hash function along with the password. It is used mainly to protect against dictionary attacks with rainbow tables, as well as for hiding similar passwords. It is simplified the compression function and removes a number of rules as well as several bytes in RAM. However, salt cannot protect from brute forcing of each individual password.

*Reduction in the number of constants*

*Reduction in the number of constants*

The BLAKE2 function uses a total of 8 word constants instead of 24. This saves 64 bytes of ROM and 64 of RAM. The excess BLAKE counter is missing.

**The parameter block**

The parameter block encodes parameters for a safe tree of hashes as well as key length (in keys mode) and reference table length.

This block contains only 32 bytes. The remaining bytes are reserved for future use and are set to NULL.

You can view the structure of BLAKE2s parameter block (offsets in bytes).

The parameter block supports random hash tree modes, including binary or ternary trees, random depth for upgrading a hash tree or fixed depth of parallel hashing, etc.

**A comprehensive review of the safe design of the hash trees**

Layouts of hash trees branching into 2 with a maximum depth of not less than 4.

Layouts of hash trees branching into 4 and a maximal depth of at least 3.

A hash tree with unlimited branching (0) and a random maximum depth (de facto, 2).

A hash tree with maximum depth 3, branching into 2, but with the root branching largely as it reaches maximum depth.

**Acceleration of data transmission**

**The use of a byte order from youngest to oldest accelerates and simplifies implementation.**

The use of a byte counter simplifies implementation and reduces the risk of error, since target applications measure data volumes in bytes rather than in bits. Thus, 8 times more data can be processed.

*Embedding BLAKE2s*

The library that embeds the blake2s encryption algorithm is:

```
int main()
{
KeyPair kp=generateKeyPair();
byte *data=(byte*)”somedata”;
Hash h=blake2s(data,8);
Signature sgntr=sign(h, kp);
bool vrf=verify(kp.publicKey, h, sgntr);
return 0;
}
```

This example describes the generation of a key pair within the parameters of the transaction. The encryption is performed according to the BLAKE2s Protocol with signature creation (BLAKE2s hash and key pair). Upon completion, we start the process of verification (public key, encrypted hash of the transaction and a signature line).

**Homomorphic encryption**

We use a fully homomorphic encryption for the platform.

*A fully homomorphic encryption (Fully Homomorphic Encryption Schemes, FHE schemes) is a type of encryption that permits everybody, not just the key holder, to obtain a ciphertext of any desired function f(*π1*,...*πt*,) for the ciphertext *π1*, ...,*πt *as long as this function can be computed efficiently.*

A NTRU scheme has been selected (Nth-degree TRUncated polynomial ring or Number Theorists who aRe U) - this was developed by Adriana L Opez-Alt, Eran Tromero and Vinod Vaikuntanathan (LTV). The platform implementation uses C++ and C# programming languages.

*The reasons for usage*

*The reasons for usage*

The selected scheme answers the following question: is it possible to use approaches described in the other research (i.e. a perfect lattice and Ring Learning With Errors - RLWE) effectively, so that the advantages of both approaches can be achieved simultaneously? Effectively the functional strength of the first (a perfect lattice approach) and the simplicity and efficiency of the second (RLWE). The authors have introduced a new key shifting technology called relinearization. If used with switching modules, the scheme can alleviate noise increase and maintain a linear increase compared to levels. It inherits the simplicity and efficiency of ideal lattices. In addition, this scheme has a key dependent message security (a KDM security, also known as a circular security), which can securely encrypt the polynomial functions of its secret key. The authors clearly explain the significance of these features in the context of homomorphic encryption. They also showed how to transform the proposed scheme into a fully homomorphic encryption scheme, as it follows from the Gentry project on scribing and bootstrapping. The proposed scheme also has an additive holomorphic key, and this property is used to secure it from key attacks (Applebaum et al., 2011).

**Electronic digital signature Ed25519**

The CREDITS Platform uses ECDSA (Elliptic Curve Digital Signature Algorithm) to create digital signatures. This is a public key algorithm. The encryption strength is based on the problem of a discrete logarithm in a cluster of elliptic curve points.

Private and public keys use a modern key generation algorithm. This is an encryption function based on elliptic curves ecdsa25519.

**Elliptic Curve Digital Signature Algorithm (ECDSA)**

The format of the Ed25519 key is associated with Daniel J. Bernstein, who has an outstanding reputation in modern cryptography. Ed25519 was developed to give a high-speed, reliable signature.

Ed25519 is EdDSA signature scheme that uses SHA-512/256 and Curve25519, where:

q=2255-19

E/Fq* are twisted elliptic curves of Edwards*

-x2+y2=1-121665121666x2y2

B is the unique point in E/Fqwhose-ycoordinate is 45 and whose-xcoordinate is a positive number

H is SHA-512, b = 256

Curve E/Fq is birationally equivalent to the Montgomery curve known as Curve25519. The equivalence:

x=uv-486664, y=u-1u+1

The Ed25519 is a public key algorithm with the following attractive features:

- A quick signature check. The software takes only 273364 cycles to verify a signature on the commonly used CPU lines of Intel Nehalem / Westmere. (This performance measurement is for short messages, verification time for very long messages depends on the hashing time.) Nehalem and Westmere include all Core i7, i5 and i3, produced in the period from 2008 to 2010, and most Xeon CPUs released in the same period
- An even quicker check of packages. The software performs a series of 64 individual signature checks (verifying 64 signatures of 64 messages under 64 public keys) in only 8.55 million cycles, i.e., under 134000 cycles per signature. The software easily fits into an L1 hash, so the rivalry between the nuclei is not significant: A quad-core 2.4 GHz Westmere verifies 71000 signatures per second while keeping the maximum check delay below 4 milliseconds
- Very fast signing. The software takes only 87548 cycles to sign a message. A quad-core 2.4 GHz Westmere signs 109000 messages per second
- Rapid generation of keys. Key generation is almost as fast as signing. There is a small downside in key generation: it takes about 6000 cycles to get secure random numbers from the operating system / dev / urandom in Linux.
- A high level of security. This system has a safety factor of 2 ^ 128; its disruption has a complexity similar with violations of the NIST P-256, RSA with ~ 3000-bit keys, strong 128-bit block ciphers, etc.
- Secure session keys.
- Collision resistance. Collisions of a hash function do not violate this system. This is an additional level of protection against possible issue with the selected hash functions
- There is no secret array index. The software never reads and records data from secret addresses in RAM; the pattern of addresses is completely predictable. Thus, while hashing, the software is immune to hyperthread attacks and other third-party attacks that rely on the leakage of addresses through the CPU cache.
- No secret branching conditions. The software never performs conditional branches based on secret data; the pattern of jerks is quite predictable. Therefore, the software is not vulnerable to side attacks that rely on the leakage of information through the branching prediction block.
- Small signature. Signatures are 64 bytes. These signatures are actually compressed versions of longer signatures; the time periods for compression and decompression are included in the number of cycles reported above.
- Small keys. Public keys use only 32 bytes. Compression / decompression time is taken into consideration in the figures above.

*Diffie-Hellman function*

*Diffie-Hellman function*

Curve25519 is a modern function of Diffie-Hellman which is suitable for a wide range of applications.

Curve25519 has:

- an extremely high speed
- no change in time
- short secret keys
- short public keys
- a check of the available key;
- a short code.

*Practical implementation of Ed25519*

*Practical implementation of Ed25519*

{

PublicKey publicKey;

PriivateKey privateKey;

Context& context=getContext();

{

ScopedLock lock(context.mutex);

ed25519_create_seed(context.seed);

ed25519_create_keypair(publicKey.data(), privateKey.data(), context.seed);

{

return {publicKey, privateKey};

}

This example shows the algorithm of a key pair generation. We generate a random value for the current time, and then encrypt this value under the ed25519Protocol. We generate private and public keys within the scope of the value obtained after cyphering. Public and private keys are returned on completion.