# ⚡Post quantum cryptography

A large section dedicated to post quantum algorithms on KLYNTAR

**Introduction**

**Introduction**

Thanks to cryptography, we live in a secure world. This, at first glance, invisible to the layman, component of the Internet allows us to safely surf the sites, use cryptocurrency, conduct transactions, sign various kinds of agreements, and so on. Behind all this is the reliability of various mathematical schemes, elliptic curves, discrete logarithm, modular arithmetic, key exchange protocols, hashing algorithms, and much more. Yes, yes - not just beautiful buttons and smooth menus.

Generally speaking, the most popular and used algorithms can be counted on the fingers literally in every category:

Hashes - SHA families, old MD, BLAKE hashes

Signatures - RSA, ECDSA, EdDSA, Ed25519

Symmetric encryption - AES, CAST, ChaCha20

Key exchange - ECDH, DH, X25519

They have worked well for a long time, are open source (consistency with the * Kerckhoffs principle*), and have been subjected to research and attacks for many years. However, nothing lasts forever and gradually the security of these algorithms will fall due to the advent of quantum computers.

As mentioned earlier, quantum computers are not some magical black box that "calculates something quickly". These are very specific mathematical algorithms, but their difference from the standard mathematical hacking paths is that they use another fundamental science - physics.

In mathematics, it can't happen that zero suddenly becomes one if you don't like the answer. In quantum mechanics, it is possible.

If earlier, within the framework of classical attacks on algorithms, a mathematical approach was used (not taking into account attacks through third-party channels such as signal interception, van Eyck interception, etc.), now physics and the nature of fundamental particles of the Standard Model come into play

Taking advantage of such benefits of quantum mechanical properties as interference, wave-particle duality, entanglement, nondeterminism, we eventually get the opportunity to build schemes that allow us to perform fast factorization (and thus threaten RSA and similar algorithms), search with quadratic acceleration (threatening symmetric algorithms and hashes) and much more.

## Problems of quantum algorithms

Mathematical attacks on algorithms were previously limited to mathematics. These are various meet-in-the-middle attacks, hijacking and oracle attacks (CPA/CCA), reuse, rainbow tables and other ways.

Since the quantum threat relies on both mathematics and physics, then the problems here are both mathematical (create an algorithm, building gates and selecting matrices) and physical (difficulty of maintaining entanglement, environmental influences, natural restrictions through energy loss).

These two types of problems do not allow for the time being to create a wunderwaffe in the world of cryptography. However, one should not treat this negligently - one must be prepared for anything.

## KLYNTAR and that's all of the above. Types of Algorithms

Therefore, we have a very specific need for the use of post-quantum security mechanisms at KLYNTAR. We need to secure everything from signatures to architectural concepts due to the fact that we rely on the security of other chains, so if they are vulnerable, then this could threaten us (it could, because it does not threaten now).

We have identified several areas that need to be secured

**Key Pairs / Signatures**

**Key Pairs / Signatures**

At the initial stages, we decided to use Dilithium and BLISS signatures. Among other algorithms, their ratio of security and sizes of public keys + signatures seemed to be optimal. They show good speed and can take part in various events on KLYNTAR. We recommend using them as an advanced security address. For example, you can store large amounts on them and use them infrequently or even through a cold wallet.

**Dilithium**

This algorithm is a NIST candidate and provides the ability to generate key pairs and signatures. Widely popular, studied at the highest levels. It is included in the post-quantum implementation of * OpenSSL*, is being studied by CloudFlare, and is included in their CIRCL repository.

We just use this implementation from CloudFlare by providing a standard set of functions like generate, sign and verify.

There are several implementations depending on the NIST security levels. Here are their characteristics

The creators themselves recommend using the Dilithium3 parameter set, but we use Dilithium5 due to greater security. However, to change the security level, it is enough to simply change one line so that such changes can be made if necessary. Here is a comparison table of security levels according to NIST

NIST security level | Hack is so difficult as... |
---|---|

1 | Bruteforcing AES-128 key |

2 | Find a collision for SHA-256 |

3 | Bruteforcing AES-192 key |

4 | Find a collision for SHA-384 |

5 | Bruteforcing AES-256 key |

We also leave you a link to the implementation of the API for Node.js in the Cryptoland repository

Link to official research website

**BLISS**

The second and priority post-quantum signature algorithm will be BLISS. It is also based on lattice cryptography, more specifically RLWE (Ring Learning With Errors). Although it creates a small signature and has good security, it has not been listed as a candidate for standardization by NIST. It uses the Fiat-Shamir trellis signature scheme and its improved sample selection method for parameters. It also uses Huffman encoding to compress the signature.

You can already generate a BLISS key pair and an address. The address is the BLAKE3 hash of the public key

**Comparison**

**Comparison**

Some of our algorithms are missing from the table

It would seem strange - well, where in the blockchain can this be needed? Everything falls into place when it comes to off-chain interaction of nodes - as part of the exchange of data between services or communication with the outside world.

Due to the fact that symmetric encryption is faster than asymmetric encryption, in the ordinary world, for example, in TLS or SSH protocols, a symmetric key is negotiated. This provides a secure communication channel.

Since we are talking about post-quantum mechanisms, here we have chosen several candidates. So, Kyber, SIKE, SIDH and CSIDH will be available on KLYNTAR.

According to the latest reports, the NIST candidate SIKE has * been hacked*. We recommend that you refrain from using it. Closer to the launch of KLYNTAR Services, we will release more meaningful recommendations on general security and on the use of post-quantum algorithms when interacting between services.

Each of them is either a current NIST candidate (Kyber) or alternatives (super isogeny algorithms).

We use the CloufFlare CIRCL implementation. Also, since the full path is **Go ****=>**** WASM ****=>**** Node.js**, you can use our repository with a simple API in any language

Here are some comparison tables

## Asymmetric encryption

We will also provide you with asymmetric encryption. Asymmetric encryption allows one party to have a pair of keys $(PubKey,PrivateKey)$ and receive messages encrypted with a public key from other parties and decrypt them using private ones.

In this regard, we decided not to add much and limited ourselves to Kyber PKE. KLYNTAR provides CloudFlare's implementation of Kyber1024 PKE, although again this is a variant and is solved by changing one line of code.

## Alternatives

In view of the principle of mutations, we allow the usage of alternative methods of post-quantum cryptography. Such, for example, can be used by DApps 2.0. You are free to choose different kinds of algorithms, but in any case, test and do not use untested implementations

## Links

Last updated