{{Header}}
{{#seo:
|description=In ~10 years Quantum Computers will break todays common asymmetric public-key cryptography algorithms used for web encryption (https), e-mail encryption (gnupg...), ssh and others.
|image=Quantum-869533640.jpg
}}
{{Title|title=
Post-Quantum Cryptography (PQCrypto)
}}
[[image:Quantum-869533640.jpg|thumb]]
{{intro|
In ~10 years Quantum Computers will break todays common asymmetric public-key cryptography algorithms used for web encryption (https), e-mail encryption (gnupg...), ssh and others.
}}
= Introduction =

[https://en.wikipedia.org/wiki/Quantum_computer Quantum computers] are based on the phenomena of [https://en.wikipedia.org/wiki/Quantum_mechanics quantum mechanics], as opposed to familiar classical computers based on transistors which encode data into binary digits (bits). In traditional computing, this process always leads to one of two possible states (0 or 1). <ref>https://en.wikipedia.org/wiki/Quantum_computer</ref> However, quantum computation relies on [https://en.wikipedia.org/wiki/Qubit qubits] that can express many different states simultaneously ("superpositions"), meaning that when/if this technology is fully developed, it will be capable of solving some types of mathematical problems virtually instantaneously. <ref>The technology is still reported to be in its infancy and only capable of solving basic problems, but it is developing rapidly. No problems have ''yet'' been solved faster than with a classical computer.</ref> <ref>For instance, a single qubit can represent a 0, 1, or [https://en.wikipedia.org/wiki/Quantum_superposition quantum superposition] of those two qubit states. A qubit pair can be in a superposition of 4 states, three qubits can be in a superposition of 8 states and so on. Quantum computers with ''n'' qubits can be in a superposition of 2^{n} different states simultaneously.</ref>

Assembling a quantum computer is now an engineering problem rather than one impeded by laws of physics -- a theoretically imperfect machine can still yield useful results. Military and government agencies have invested heavily in this area because of the implications for today's widely used public-key cryptography. <ref>Also explaining why the NSA shifted to [https://web.archive.org/web/20160208201926/https://www.deepdotweb.com/2016/02/08/nsa-switches-to-quantum-resistant-cryptography/ quantum-resistant cryptography] in 2016.</ref> Ciphertext that is invulnerable to classical computing will be shredded into ribbons by a large-scale quantum computer. Similarly, all Tor traffic will be vulnerable until quantum-resistant cryptography is implemented.

The Snowden documents reveal that all encrypted data traversing the internet is intercepted and stored indefinitely for cryptanalysis should there be a scientific breakthrough. A global arms race has ensued between the United States, EU, Russia, China, Israel and other global powers due to the immense geo-political, economic, intelligence and military advantages this technology would confer.

The academic and corporate consensus is that a large quantum computer will be built in around 10-15 years. It is safe to assume that well-funded intelligence communities are capable of greatly reducing this development period.

As of July 2020, the [https://csrc.nist.gov/publications/detail/nistir/8309/final second round] of NIST PQ cipher standardization has concluded. The 26 candidates are grouped into [https://www.nist.gov/news-events/news/2020/07/pqc-standardization-process-third-round-candidate-announcement finalist and alternate] groups which will be reviewed for another 12-18 months. NIST plans to release the initial standard for quantum-resistant cryptography in [https://www.nist.gov/news-events/news/2020/07/nists-post-quantum-cryptography-program-enters-selection-round 2022]. The finalist group has better performance, but less  security confidence while alternate candidates have a stronger security rationale, but lack performance for all use cases. Only one cipher of each design type will be standardized, for example one lattice based asymmetric crypto and one lattice based signature scheme will be selected out of the group. A fourth round looking at alternates for standardization is planned.

= Broken and Impacted Cryptographic Algorithms =
The US National Institute of Standards and Technology has summarized the [https://nvlpubs.nist.gov/nistpubs/ir/2016/NIST.IR.8105.pdf impact of quantum computing] on common cryptographic algorithms.

'''Table:''' ''Cryptographic Impacts of Quantum Computing''

{| class="wikitable"
|-
! scope="col"| '''Cryptographic Algorithm'''
! scope="col"| '''Type'''
! scope="col"| '''Purpose'''
! scope="col"| '''Quantum Computer Impact'''
|-
! scope="row"| AES-256
| Symmetric Key
| Encryption
| Larger Key Sizes Needed
|-
! scope="row"| SHA-256. SHA-3
| -
| Hash Functions
| Larger Output Needed
|-
! scope="row" | RSA
| Public Key
| Signatures, Key Establishment
| No Longer Secure
|-
! scope="row" | ECDSA, ECDH <ref>Elliptic Curve Cryptography.</ref>
| Public Key
| Signatures, Key Exchange
| No Longer Secure
|-
! scope="row" | DSA <ref>Finite Field Cryptography.</ref>
| Public Key
| Signatures, Key Exchange
| No Longer Secure
|-
|}

The emergence of quantum computers would break all asymmetric public-key cryptography and signature algorithms used today -- the type of cryptography that protects communications over the internet. The size of symmetric keys is also halved, meaning the strength of 256-bit keys would be equivalent to 128-bit keys. This is the type of cryptography used for Full Disk Encryption, when data is encrypted with a passphrase.

All current generation symmetric cryptographic authenticated modes such as CBC-MAC, PMAC, GMAC, GCM, and OCB are completely broken. This also applies to many CAESAR competition candidates: CLOC, AEZ, COPA, OTR, POET, OMD, and Minalpher. <ref>[https://arxiv.org/pdf/1602.05973v3.pdf Breaking Symmetric Cryptosystems using Quantum Period Finding]</ref>

For more details visit https://pqcrypto.org/

= Post-quantum Cryptography =

The solution to this threat is Post-quantum Cryptography ("PQ Crypto"). This provides a drop-in replacement for cryptographic libraries already deployed, except different types of "quantum-hard" mathematical problems are used so cryptanalysis is difficult for ''both'' classical and quantum computers.

Competent cryptographers are gradually improving the performance of PQ Crypto and designing cipher-suites that are efficient for everyday use. For instance:

* [https://pqcrypto.eu.org/docs/initial-recommendations.pdf Initial recommendations] for PQ Crypto algorithms were published in September 2015.
* The Tor Project is planning to [https://gitlab.torproject.org/legacy/trac/-/issues/17286 migrate to quantum-resistant ciphers] in a future version. <ref>Progress has been slow and this feature now has an unspecified release date, after initially being planned for Tor v0.3.X.</ref> To follow Tor child tickets related to this transition, see [https://gitlab.torproject.org/legacy/trac/-/issues/24985 here]. Progress has [https://lists.torproject.org/pipermail/tor-talk/2020-May/045581.html stalled] until wider cell sizes are implemented.

== NIST PQ Competition ==
While Bruce Schneier has praised the NIST process for PQ cipher standardization as it nears its close <ref>
https://www.schneier.com/blog/archives/2022/08/nists-post-quantum-cryptography-standards.html
</ref>, Daniel Bernstein has pointed out the consistent non-transparency of the organization and its secrecy about input from outside entities like the NSA who have a vested interest in subverting cryptographic designs. NIST non-responsiveness to FOIA requests culminated in a lawsuit by DJB. Among many problems he pointed out, is the skewing of design guidelines that weaken security in the name of performance despite being illogical <ref>
https://blog.cr.yp.to/20220805-nsa.html
</ref>, choosing patent encumbered ciphers like KYBER when NTRU Prime would have sufficed <ref>
https://web.archive.org/web/20220926112906/https://twitter.com/hashbreaker/status/1544456469038645248
</ref> and refusing (under NSA influence) to accommodate hybrid key-encapsulation mechnism (KEM) designs where strong non-PQ ciphers are combined with experimental PQ ciphers to hedge against fatal weaknesses that these new, less studied ciphers may have against the mathematical attacks known today.

= Software =

The Free Software listed below is known to resist quantum computers, but this is not an endorsement for any particular tool. To mitigate potential exposure to unknown software implementation failures, it is recommended to set up arbitrary protocols over Tor [[Onion_Services|Onion Services]] once PQ Crypto is deployed. The exception is the use of one-time pads which are secure from an [https://en.wikipedia.org/wiki/Information_theoretic_security information-theoretic perspective].

* [https://github.com/exaexa/codecrypt Codecrypt]
* [https://github.com/aabmets/quantcrypt Quantcrypt]
* [https://github.com/rnpgp/rnp RNP (Build with ENABLE_PQC option)]
* [https://www.cyph.com/ Cyph]
* [https://red-bean.com/onetime/ OneTime]
* [https://tinyssh.org/ TinySSH (PQC planned)]
* [https://github.com/open-quantum-safe/liboqs liboqs] - is a FLOSS implementation of many NIST candidates by Douglas Stebila, an Associate Professor of cryptography at the University of Waterloo. It provides pq for OpenSSL and OpenSSH using software. <ref>https://www.douglas.stebila.ca/</ref>

Before adopting any software, first consider if: <ref>https://forums.whonix.org/t/post-quantum-cryptography-pqc/2011/17</ref>

* Cryptographic libraries were written by competent cryptographers and audited for correct implementation.
* Quantum-resistant algorithms have withstood substantial cryptanalytic efforts.
* The software has been widely adopted to help users blend in.

= Setup Guides =

== Codecrypt ==
{{verification_tools_mininav}}

This is a GnuPG-like Unix program for encryption and signing that only uses quantum-resistant algorithms: <ref>https://gitea.blesmrt.net/exa/codecrypt</ref> <ref>https://e-x-a.org/codecrypt/</ref>

* McEliece cryptosystem (compact QC-MDPC variant) for encryption.
* Hash-based Merkle tree algorithm (FMTSeq variant) for digital signatures.

Codecrypt is free software. The code is licensed under terms of LGPL3 in order to make combinations with other tools easier.

=== Use Instructions ===

{{project_name_long}} includes Codecrypt by default. <ref>Since {{project_name_long}} 14.</ref> See the [https://e-x-a.org/codecrypt/ccr.1.html Codecrypt manual page] for common use-cases.

==== Basic Commands ====

Generate a strong(er) asymmetric encryption key.

{{CodeSelect|code=
ccr -g ENC-256 -N [keyname]
}}

Generate a strong(er) signature key.

{{CodeSelect|code=
ccr -g SIG-256 -N [keyname]
}}

==== Key Management ====

'''Table:''' ''Codecrypt Key Management Commands''

{| class="wikitable"
|-

! scope="col"| '''Category'''
! scope="col"| '''Command'''
|-

! scope="row"| Back-up keys
| It is easier to backup the ccr folder in the home directory, changing its name from/to <code>.ccr</code> upon restore. Enable hidden file view in the file browser to see it.
|-

! scope="row"| Export specified public key for sharing with contacts
| If a signature key was also created, both types of keys will be exported for distribution in a single file if they share the same name.

{{CodeSelect|code=
ccr -F [keyname] -ap > [keyname]
}}
|-

! scope="row"| Export specified private key
| The <code>-F</code> parameter chooses the key to be used. To enumerate all keys in the keyring run <code>ccr -k</code> for public ones and <code>ccr -K</code> for private.

{{CodeSelect|code=
ccr -F [keyname] -aP > [keyname]
}}
|-

! scope="row"| Import a public key
| {{CodeSelect|code=
ccr -ai < [contactkey]
}}
|-

! scope="row"| Import a private key
| {{CodeSelect|code=
ccr -aI < [myprivatekey]
}}
|-

|}

==== Encryption/Decryption, Signing and Verification ====

'''Table:''' ''Codecrypt Encryption/Decryption, Signing and Verification Commands''

{| class="wikitable"
|-
! scope="col"| '''Category'''
! scope="col"| '''Command'''
|-
! scope="row"| Encrypt a plaintext message file only to an already imported contact key
| Note this will be inaccessible to you. Save a plaintext copy for archival purposes.

{{CodeSelect|code=
ccr -aer [contactkey] -R plaintext > ciphertext
}}
|-
! scope="row"| Encrypt and sign a plaintext message file only to an already imported contact key
| {{mbox
| image   = [[File:Ambox_warning_pn.svg.png|40px]]
| text    = Note: A FMTSeq master signature key has a limited number (65536) of subkeys each only used once to sign data. Reusing a subkey would break its security properties. Beware: Rolling back a VM snapshot or restoring a stale snapshot of the private key folder will result in key reuse. Codecrypt issues a warning after every time you sign "notice: 65535 signatures remaining". Backup/restore the private keys everytime after a signature is made. <ref>https://e-x-a.org/codecrypt/ccr.1.html</ref>
}}

{{CodeSelect|code=
ccr -sea -r [contactkey] -R plaintext > ciphertext
}}
|-
! scope="row"| Decrypt a ciphertext message creating plaintext output
| {{CodeSelect|code=
ccr -adR ciphertext > plaintext
}}
|-
! scope="row"| Decrypt and verify a signed ciphertext message creating plaintext output
| A contact's public signature key must be imported beforehand. <ref>https://archive.fosdem.org/2017/schedule/event/quantum/attachments/slides/1774/export/events/attachments/quantum/slides/1774/pqc.pdf</ref>

{{CodeSelect|code=
ccr -advR ciphertext > plaintext
}}
|-
! scope="row"| Create clearsigned text output
| {{CodeSelect|code=
ccr -s -C -R plaintext > clearsigned
}}

If multiple private signature keys have been created, a single one must be specified for clearsigning using <code>-u</code>.

{{CodeSelect|code=
ccr -u [keyname] -s -C -R plaintext > clearsigned
}}
|-
! scope="row"| Create a detached signature for a binary such as a code package
| {{CodeSelect|code=
ccr -sab package.ccr < package
}}
|-
! scope="row"| Verify detached signature
| {{CodeSelect|code=
ccr -vab package.ccr < package
}}
|-
! scope="row"| Create hashfile from a large file
| Contents are not signed asymmetrically in this case, but instead a file with cryptographic hashes that can later be used to verify if the contents of input was changed, is generated. The contents of the hashfile could then be clearsigned asymmetrically, making it act as a detached signature file. <ref>https://gitea.blesmrt.net/exa/codecrypt/src/branch/master/man/ccr.1</ref>

{{CodeSelect|code=
ccr -saS hashfile.ccr < big_data.iso
}}
|-
! scope="row"| Verify the hashfile
| {{CodeSelect|code=
ccr -vaS hashfile.ccr < the_same_big_data.iso
}}
|}

==== Message Formatting ====

Even without direct Thunderbird support, it is still possible to format messages to account for replies. However users should be careful to not mistakenly send unencrypted replies. It is advisable to disable the Internet connection temporarily to prevent the accidental sending of messages before they are encrypted with Codecrypt, and because TorBirdy is no longer available to automatically disable draft syncing on the host email server.

Steps:

# Disable the Internet connection.
# Click reply in Thunderbird and copy the string "John Doe:"
# Format the correspondent's text as a reply by pasting it: <code>Edit</code> &rarr; <code>Paste As Quotation</code>
# Copy the result to the text editor window. Continue composing the message with your replies interspersed between the quotes.
# Save and encrypt.
# Paste the ciphertext into the Thunderbird reply window and completely replace the existing text.
# Re-establish the Internet connection, then press send.

== OneTime ==

One-time pads are the only provably unbreakable encryption scheme ever invented, assuming a functional and non-backdoored random number generator (RNG). <ref>https://en.wikipedia.org/wiki/One-time_pad</ref> <ref>https://www.ciphermachinesandcryptology.com/en/onetimepad.htm</ref> [https://red-bean.com/onetime/ OneTime] <ref>https://code.librehq.com/kfogel/onetime</ref> is a program that sets up a one-time pad on a user's computer, and helps to protect from reuse of pads which breaks the overall security model.

OneTime can encrypt any kind of file -- it does not matter if the file's contents are Base64-encoded or not, because OneTime is not interpreting the contents. OneTime simply treats the file as a string of bits. Notably this is true for most encryption software; OneTime is not unique in this regard.

One-time pads should be completely secure against cryptographic attacks by quantum computers or other avenues. So long as the encryption key is truly random and the key is as long as the message, then all possible plaintexts are equally likely. Quantum computers are not telepathic, so messages properly encrypted with a one-time pad will remain impervious to cryptographic attacks. Of course, using the system is difficult in practice due to the logistics of key exchange, but quantum computing does not affect that reality. <ref>https://github.com/kfogel/OneTime/issues/14#issuecomment-218038898</ref>

One-time pads come with several limitations:

* The message and the key are identical in size; this issue is negated by the large size of contemporary HDD/SSDs.
* It is impossible to securely contact strangers because the pad file must be exchanged in person or by other trustworthy peers. Sending the pad online only makes it as strong as the asymmetric cryptography that is in use.
* Message integrity cannot be verified, meaning there is no way for the recipient to discover if the ciphertext was  tampered with during transit.
* The old pad material must never be reused to encrypt additional different messages. If this advice is ignored, the encryption is completely broken. <ref>https://en.wikipedia.org/wiki/Venona_project#Decryption</ref>

See also: [[One_Time_Pad|Physical One-time Pad]].

= Miscellaneous =
* [https://forums.whonix.org/t/post-quantum-cryptography-pqc/2011 Forum discussion: post-quantum cryptography - PQC]

= Footnotes =
{{reflist|close=1}}

{{Footer}}

[[Category:Documentation]]