Post-quantum cryptography

From Infogalactic: the planetary knowledge core
Jump to: navigation, search

Post-quantum cryptography refers to cryptographic algorithms (usually public-key algorithms) that are thought to be secure against an attack by a quantum computer. This is not true of the most popular public-key algorithms which can be efficiently broken by a sufficiently large quantum computer. The problem with the currently popular algorithms is that their security relies on one of three hard mathematical problems: the integer factorization problem, the discrete logarithm problem or the elliptic curve discrete logarithm problem. All of these problems can be easily solved on a sufficiently large quantum computer running Shor's algorithm.[1][2] Even though current, publicly known, experimental quantum computers are too small to attack any real cryptographic algorithm,[3] many cryptographers are designing new algorithms to prepare for a time when quantum computing becomes a threat. This work has gained greater attention from academics and industry through the PQCrypto conference series since 2006 and more recently by several European Telecommunications Standards Institute (ETSI) Workshops on Quantum Safe Cryptography.[4][5][6]

In contrast to the threat quantum computing poses to current public key algorithms, most current symmetric cryptographic algorithms (symmetric ciphers and hash functions) are considered to be relatively secure from attacks by quantum computers.[2][7] While the quantum Grover's algorithm does speed up attacks against symmetric ciphers, doubling the key size can effectively block these attacks.[8] Thus post-quantum symmetric cryptography does not need to differ significantly from current symmetric cryptography. See Section on Symmetric Key Approach below.

Post-quantum cryptography is distinct from quantum cryptography, which refers to using quantum phenomena to achieve secrecy.

Algorithms

Currently post-quantum cryptography research is mostly focused on six different approaches:[2][5]

Lattice-based cryptography

<templatestyles src="Module:Hatnote/styles.css"></templatestyles>

This approach includes cryptographic systems such as Learning with Errors, Ring-Learning with Errors (Ring-LWE),[9][10][11] the older NTRU or GGH encryption schemes, and the newer NTRU signature and BLISS signatures.[12] Some of these schemes like NTRU encryption have been studied for many years without anyone finding a feasible attack. Others like the Ring-LWE algorithms have proofs that their security reduces to a worst-case problem.[13] There are patents on the NTRU algorithms. The Post Quantum Cryptography Study Group sponsored by the European Commission suggested that the Stehle–Steinfeld variant of NTRU be studied for standardization rather than the patented NTRU algorithm.[14][15]

Multivariate cryptography

<templatestyles src="Module:Hatnote/styles.css"></templatestyles>

This includes cryptographic systems such as the Rainbow (Unbalanced Oil and Vinegar) scheme which is based on the difficulty of solving systems of multivariate equations. Various attempts to build secure multivariate equation encryption schemes have failed. However, multivariate signature schemes like Rainbow could provide the basis for a quantum secure digital signature.[16] There is a patent on the Rainbow Signature Scheme.

Hash-based cryptography

This includes cryptographic systems such as Lamport signatures and the Merkle signature scheme. Hash based digital signatures were invented in the late 1970s by Ralph Merkle and have been studied ever since as an interesting alternative to number theoretic digital signatures like RSA and DSA. Their primary drawback is that for any Hash based public key, there is a limit on the number of signatures that can be signed using the corresponding set of private keys. This fact had reduced interest in these signatures until interest was revived due to the desire for cryptography that was resistant to attack by quantum computers. There appear to be no patents on the Merkle signature scheme[citation needed] and there exist many non-patented hash functions that could be used with these schemes.

Code-based cryptography

This includes cryptographic systems which rely on error-correcting codes, such as the McEliece and Niederreiter encryption algorithms and the related Courtois, Finiasz and Sendrier Signature scheme. The original McEliece signature using random Goppa codes has withstood scrutiny for over 30 years. However, many variants of the McEliece scheme, that seek to introduce more structure into the code used in order to reduce the size of the keys, have been shown to be insecure.[17] The Post Quantum Cryptography Study Group sponsored by the European Commission has recommended the McEliece public key encryption system as a candidate for long term protection against attacks by quantum computers.[14]

Supersingular elliptic curve isogeny cryptography

<templatestyles src="Module:Hatnote/styles.css"></templatestyles>

This cryptographic system relies on the properties of supersingular elliptic curves to create a Diffie-Hellman replacement with forward secrecy.[18] This cryptographic system uses the well studied mathematics of supersingular elliptic curves to create a Diffie-Hellman like key exchange that can serve as a straightforward quantum computing resistant replacement for the Diffie-Hellman and elliptic curve Diffie–Hellman key exchange methods that are in widespread use today. Because it works much like existing Diffie-Hellman implementations, it offers forward secrecy which is viewed as important both to prevent mass surveillance by governments but also to protect against the compromise of long term keys through failures.[19] In 2012, researchers Sun, Tian and Wang of the Chinese State Key Lab for Integrated Service Networks and Xidian University, extended the work of De Feo, Jao, and Plut to create quantum secure digital signatures based on supersingular elliptic curve isogenies.[20] There are no patents covering this cryptographic system.

Symmetric key quantum resistance

Provided one uses sufficiently large key sizes, the symmetric key cryptographic systems like AES and SNOW 3G are already resistant to attack by a quantum computer.[21] Further, key management systems and protocols that use symmetric key cryptography instead of public key cryptography like Kerberos and the 3GPP Mobile Network Authentication Structure are also inherently secure against attack by a quantum computer. Given its widespread deployment in the world already, some researchers recommend expanded use of Kerberos-like symmetric key management as an efficient and effective way to get Post Quantum cryptography today.[22]

Security reductions

In cryptography research the provable equivalence of the security of a cryptographic algorithm to some known hard mathematical problem is viewed as an important fact in support of using a given cryptographic systems. These proofs are often called "security reductions." In other words, the security of a given cryptographic algorithm is reduced to the security of a known hard problem. Researchers are actively looking for security reductions in the prospects for post quantum cryptography. Current results are given here:

Lattice based cryptography – Ring-LWE key exchange and signature

In some versions of Ring-LWE there is a security reduction to the Shortest Vector Problem (SVP) in a Lattice as a lower bound on the security. The SVP is known to be NP-hard.[23] Two specific Ring-LWE systems which have provable security reductions are the key exchange defined by Peikert[9] and one variant of Lyubashevsky's Ring-LWE signatures defined in a paper by Guneysu, Lyubashevsky, and Poppelmann.[10]

Lattice-based cryptography – NTRU, BLISS

The security of the NTRU encryption scheme and the BLISS[12] signature is believed to be related to but not provably reducible to the Closest Vector Problem (CVP) in a Lattice. The CVP is known to be NP-hard. The Post Quantum Cryptography Study Group sponsored by the European Commission suggested that the Stehle–Steinfeld variant of NTRU which does have a security reduction be studied for long term use instead of the original NTRU algorithm.[14]

Multivariate cryptography – Rainbow

The Rainbow Multivariate Equation Signature Scheme is a member of a class of multivariate quadratic equation cryptosystems called "Unbalanced Oil and Vinegar Cryptosystems" (UOV Cryptosystems) Bulygin, Petzoldt and Buchmann have shown a reduction of generic multivariate quadratic UOV systems to the NP-Hard Multivariate Quadratic Equation Solving problem.[24]

Hash-based cryptography – Merkle signature scheme

In 2005, Garcia proved that there was a security reduction of Merkle Hash Tree signatures to the security of the underlying hash function. He showed that if computationally one-way hash functions exist then the Merkle Hash Tree signature is provably secure. Thus if one used a hash function with a provable reduction of security to a known hard problem one would have a provable security reduction of the Merkle tree signature to a known hard problem.[25] The Post Quantum Cryptography Study Group sponsored by the European Commission has recommended use of this cryptography for long term protection against quantum computers.[14]

Code-based cryptography – McEliece

The McEliece Encryption System has a security reduction to the Syndrome Decoding Problem (SDP).[26] The SDP is known to be NP-hard[27] The Post Quantum Cryptography Study Group sponsored by the European Commission has recommended the use of this cryptography for long term protection against attack by a quantum computer.[14]

Supersingular elliptic curve isogeny cryptography

Security is related to the problem of constructing an isogeny between two supersingular curves with the same number of points. The most recent investigation of the difficulty of this problem is by Delfs and Galbraith indicates that this problem is as hard as the inventors of the key exchange suggest that it is.[28] There is no security reduction to a known NP-hard problem.

Key sizes

One common characteristic of many post-quantum cryptography algorithms is that they require larger key sizes than commonly used "pre-quantum" public key algorithms. There are often tradeoffs to be made in key size, computational efficiency and ciphertext or signature size. It is therefore difficult to compare one scheme against another in only one dimension like key size. However the following paragraphs provide some publicized key sizes for a fixed level of security.

Lattice-based cryptography – LWE key exchange and Ring-LWE key exchange

The fundamental idea of using LWE and Ring LWE for key exchange was proposed and filed at the University of Cincinnati in 2011 by Jintai Ding. The basic idea comes from the associativity of matrix multiplications, and the errors are used to provide the security. The paper [29] appeared in 2012 after a provisional patent application was filed in 2012.

In 2014, Peikert [30] presented a key transport scheme following the same basic idea of Ding's, where the new idea of sending additional 1 bit signal for rounding in Ding's construction is also utilized. For somewhat greater than 128 bits of security, Singh presents a set of parameters which have 6956-bit public keys for the Peikert's scheme.[31] The corresponding private key would be roughly 14000 bits.

In 2015, an authenticated key exchange with provable forward security following the same basic idea of Ding's was presented at Eurocrypt 2015,[32] which is an extension of the HMQV [33] construction in Crypto2005.

Lattice-based Cryptography – NTRU encryption

For 128 bits of security in NTRU, Hirschhorn, Hoffstein, Howgrave-Graham and Whyte, recommend using a public key represented as a degree 613 polynomial with coefficients \bmod{\left(2^{10}\right)}. This results in a public key of 6130 bits. The corresponding private key would be 6743 bits.[34]

Multivariate cryptography – Rainbow signature

For 128 bits of security and the smallest signature size in a Rainbow multivariate quadratic equation signature scheme, Petzoldt, Bulygin and Buchmann, recommend using equations in \mathbb{F}_{31} with a public key size of just over 991,000 bits, a private key of just over 740,000 bits and digital signatures which are 424 bits in length.[35]

Hash-based cryptography – Merkle signature scheme

In order to get 128 bits of security for hash based signatures to sign 1 million messages using the fractal Merkle tree method of Naor Shenhav and Wool the public and private key sizes are roughly 36,000 bits in length.[36]

Code-based cryptography – McEliece

For 128 bits of security in a McEliece scheme, The European Commissions Post Quantum Cryptography Study group recommends using a binary Goppa code of length at least n=6960 and dimension at least k=5413, and capable of correcting t=119 errors. With these parameters the public key for the McEliece system will be a systematic generator matrix whose non-identity part takes k \times (n-k) = 8373911 bits. The corresponding private key, which consists of the code support with n=6960 elements from GF(2^{13}) and a generator polynomial of with t=119 coefficients from GF(2^{13}), will be 92027 bits in length[14]

The group is also investigating the use of Quasi-cyclic MDPC codes of length at least n=2^{16}+6 = 65542 and dimension at least k=2^{15}+3=32771, and capable of correcting t=264 errors. With these parameters the public key for the McEliece system will be the first row of a systematic generator matrix whose non-identity part takes k=32771 bits. The private key, a quasi-cyclic parity-check matrix with d=274 nonzero entries on a column (or twice as much on a row), takes no more than d\times 16 = 4384 bits when represented as the coordinates of the nonzero entries on the first row.

Barreto et al. recommend using a binary Goppa code of length at least n=3307 and dimension at least k=2515, and capable of correcting t=66 errors. With these parameters the public key for the McEliece system will be a systematic generator matrix whose non-identity part takes k \times (n-k) = 1991880 bits.[37] The corresponding private key, which consists of the code support with n=3307 elements from GF(2^{12}) and a generator polynomial of with t=66 coefficients from GF(2^{12}), will be 40476 bits in length.

Supersingular elliptic curve isogeny cryptography

For 128 bits of security in the supersingular isogeny Diffie-Hellman (SIDH) method, De Feo, Jao and Plut recommend using a supersingular curve modulo a 768-bit prime. If one uses elliptic curve point compression the public key will need to be no more than 4x768 or 3072 bits in length.[38] This is the same as the conventional public key sizes that many groups recommend for RSA and Diffie Hellman. Hence the SIDH fits well into existing public key systems.

Symmetric–key-based cryptography

As a general rule, for 128-bits of security in a symmetric key based system one can safely use key sizes of 256-bits. The best quantum attack against generic symmetric key systems is an application of Grover's algorithm which requires work proportional to the square root of the size of the key space. To transmit an encrypted key to a device which possesses the symmetric key necessary to decrypt that key requires roughly 256 bits as well. It is clear that symmetric key systems offer the smallest key sizes for post quantum cryptography.

Key size table

The following table is a summary of the information in this section giving the key sizes in bytes:

Algorithm Public key size (in bits) Private key size (in bits)
Ring-LWE[31] 6595 14000
NTRU[34] 6130 6743
Rainbow[35] 991,000 740,000
Hash signature[36] 36,000 36,000
Goppa-based McEliece[14] 8,373,911 92,027
Quasi-cyclic MDPC-based McEliece[14] 65542 4384
SIDH[18] 3,071 3072

One practical consideration on a choice for Post Quantum Cryptography concerns how efficiently public keys can be transmitted over the internet. From this point of view, the Ring-LWE, NTRU, and SIDH algorithms seem best suited for general use. Hash signatures come close to being practical from a transmission standpoint. The McEliece and Rainbow schemes seem poorly suited to environments which require transmission of keys.

Forward secrecy

A public-key system demonstrates a property referred to as perfect forward secrecy when it generates random public keys per session for the purposes of key agreement. This means that the compromise of one message cannot lead to the compromise of others, and also that there is not a single secret value which can lead to the compromise of multiple messages. Security experts recommend using cryptographic algorithms that support forward secrecy over those that do not.[39] The reason for this is that forward secrecy can protect against the compromise of long term private keys associated with public/private key pairs. This is viewed as a means of preventing mass surveillance by intelligence agencies.

Both the Ring-LWE key exchange and supersingular isogeny Diffie-Hellman (SIDH) key exchange can support forward secrecy in one exchange with the other party. Both the Ring-LWE and SIDH can also be used without forward secrecy by creating a variant of the classic ElGamal encryption variant of Diffie-Hellman.

The other algorithms in this article, such as NTRU, do not support forward secrecy in one exchange. These other algorithms could be configured with forward secrecy by generating a new random public key for each key exchange and exchanging random public keys with the other party as a first exchange and then encrypting random numbers with the other party's public key and transmitting the result as a second exchange.

See also

References

  1. Lua error in package.lua at line 80: module 'strict' not found.
  2. 2.0 2.1 2.2 Lua error in package.lua at line 80: module 'strict' not found.
  3. Lua error in package.lua at line 80: module 'strict' not found.
  4. Lua error in package.lua at line 80: module 'strict' not found.
  5. 5.0 5.1 Lua error in package.lua at line 80: module 'strict' not found.
  6. Lua error in package.lua at line 80: module 'strict' not found.
  7. Lua error in package.lua at line 80: module 'strict' not found.
  8. Lua error in package.lua at line 80: module 'strict' not found.
  9. 9.0 9.1 Lua error in package.lua at line 80: module 'strict' not found.
  10. 10.0 10.1 Lua error in package.lua at line 80: module 'strict' not found.
  11. Lua error in package.lua at line 80: module 'strict' not found.
  12. 12.0 12.1 Lua error in package.lua at line 80: module 'strict' not found.
  13. Lua error in package.lua at line 80: module 'strict' not found.
  14. 14.0 14.1 14.2 14.3 14.4 14.5 14.6 14.7 Lua error in package.lua at line 80: module 'strict' not found.
  15. Lua error in package.lua at line 80: module 'strict' not found.
  16. Lua error in package.lua at line 80: module 'strict' not found.
  17. Lua error in package.lua at line 80: module 'strict' not found.
  18. 18.0 18.1 Lua error in package.lua at line 80: module 'strict' not found.
  19. Lua error in package.lua at line 80: module 'strict' not found.
  20. Lua error in package.lua at line 80: module 'strict' not found.
  21. Lua error in package.lua at line 80: module 'strict' not found.
  22. Lua error in package.lua at line 80: module 'strict' not found.
  23. Lua error in package.lua at line 80: module 'strict' not found.
  24. Lua error in package.lua at line 80: module 'strict' not found.
  25. Lua error in package.lua at line 80: module 'strict' not found.
  26. Lua error in package.lua at line 80: module 'strict' not found.
  27. Lua error in package.lua at line 80: module 'strict' not found.
  28. Lua error in package.lua at line 80: module 'strict' not found.
  29. Lua error in package.lua at line 80: module 'strict' not found.
  30. Lua error in package.lua at line 80: module 'strict' not found.
  31. 31.0 31.1 Lua error in package.lua at line 80: module 'strict' not found.
  32. Lua error in package.lua at line 80: module 'strict' not found.
  33. Lua error in package.lua at line 80: module 'strict' not found.
  34. 34.0 34.1 Lua error in package.lua at line 80: module 'strict' not found.
  35. 35.0 35.1 Lua error in package.lua at line 80: module 'strict' not found.
  36. 36.0 36.1 Lua error in package.lua at line 80: module 'strict' not found.
  37. Lua error in package.lua at line 80: module 'strict' not found.
  38. Lua error in package.lua at line 80: module 'strict' not found.
  39. Lua error in package.lua at line 80: module 'strict' not found.

Further reading

External links