{
  "id": "encryption",
  "title": "Encryption",
  "lang": "en",
  "source_lang": "en",
  "summary": "Encryption transforms data with a key so that only authorized parties can recover its meaning, and it underpins modern digital security.",
  "category": "computer-science",
  "subcategory": "networks-security",
  "type": "concept",
  "aliases": [
    "Enciphering",
    "Ciphering"
  ],
  "generated_at": "2026-10-08",
  "model": "pro/claude-haiku-5-5",
  "url": "https://aiwiki.page/en/encryption/",
  "translations": {
    "zh-Hans": {
      "url": "https://aiwiki.page/zh/encryption/",
      "json": "https://aiwiki.page/zh/encryption.json"
    }
  },
  "sections": [
    {
      "heading": "",
      "text": "Encryption is the process of converting readable data (plaintext) into an unreadable form (ciphertext) using an algorithm and a key, so that only parties holding the right key can reverse the transformation. It is a central technique of cryptography and a main tool for protecting confidentiality in computing, communication, and data storage. Encryption by itself guarantees secrecy but not authenticity or integrity, so practical systems combine it with other mechanisms.\n\nIts importance has grown with digital life, since online banking, messaging, cloud storage, and web browsing all depend on it. The subject draws on mathematics (number theory, algebra, probability), computer-science (algorithm design, computational complexity, implementation engineering), and public policy (privacy rights, lawful access). Its history runs from hand-operated substitution ciphers of antiquity, through mechanical rotor machines such as Enigma, to the public-key methods of the 1970s, which made secure communication possible between parties who had never shared a secret.\n\nThe entry first defines the basic concepts and the historical ciphers, then treats the two main families, symmetric and public-key encryption, together with their modes, standards, and formal security definitions. It goes on to attacks, implementation risks, authenticated encryption, the post-quantum transition, advanced schemes, applications, and policy debates, and closes with open problems."
    },
    {
      "heading": "Basic concepts and terminology",
      "text": "Encryption is the process of transforming readable information so that only parties holding a particular secret can recover it. The original readable message is the plaintext, and the transformed result is the ciphertext. A key is the secret parameter that controls the transformation, and a cipher is the family of algorithms that defines how plaintext and key are combined. The encryption function \\(E\\) maps a plaintext \\(P\\) and a key \\(K\\) to a ciphertext, \\(C = E_K(P)\\), and the decryption function \\(D\\) inverts it, so that \\(P = D_K(C)\\) whenever the same key is used. Some systems use different keys for the two directions, as described in the public-key section, but the basic relationship between the two functions is the same: decryption must undo encryption for the legitimate key holder, and must be infeasible for everyone else.\n\nA central design rule is Kerckhoffs's principle, which Auguste Kerckhoffs set out in 1883 in an article on military cryptography. It holds that a system should remain secure even if everything about it except the key is publicly known. Claude Shannon later expressed the same idea more bluntly by assuming that the enemy knows the system. The principle has practical consequences. Secrecy rests on a value that can be replaced if it is compromised, and an algorithm that is published can be examined by many independent experts. Systems that depended on hidden algorithms (\"security through obscurity\") tended to fail once their designs leaked, whereas a public algorithm with a secret key can be reused safely by changing only the key.\n\nEncryption is often confused with two other transformations, encoding and hashing, and the distinction matters. Encoding converts data from one representation to another, for example text to Base64, ASCII, or Morse code. Encoding is designed for compatibility or transmission, uses no secret, and can be reversed by anyone who knows the public scheme, so it provides no confidentiality at all. Hashing maps input of any length to a fixed-size digest using a function that is designed to be hard to invert and to make collisions hard to find. A hash is not meant to be decrypted, and it needs no key; it is used for fingerprints, integrity checks, and password storage rather than for hiding data that must later be read. Encryption, by contrast, is keyed and reversible by anyone holding the correct key. Compression is another transformation that is often mistaken for protection, but it hides nothing by itself.\n\nConfidentiality, meaning that unauthorized parties cannot learn the content of a message, is the goal most people associate with encryption, but it is only one of several security goals. Integrity means that tampering can be detected. Authentication means that the recipient can verify who created or sent the data. Non-repudiation means that the sender cannot credibly deny having sent it, which is a stronger property usually achieved with digital signatures rather than encryption alone. Encryption by itself delivers confidentiality and does not automatically guarantee the other three. A ciphertext can often be altered in ways the recipient does not notice, which is why modern systems combine encryption with authentication. Security is also always defined relative to an adversary's capabilities, such as what the attacker can observe, what they can choose to send, and how much computation they can spend. These models are explored in later sections of this article."
    },
    {
      "heading": "Classical ciphers",
      "text": "The earliest known deliberate alteration of a text is a long way from a modern cipher. The earliest known deliberate transformation of a text is found in non-standard hieroglyphs carved into the wall of a tomb from the Old Kingdom of Egypt circa 1900 BC. The script was formed by replacing similar looking pictograms with each other and use of the rebus principle, so a sign could stand for a sound. Many accounts place the example in the Old Kingdom, but the tomb most often linked to it, that of the nobleman Khnumhotep II at Beni Hasan, is generally dated to the Middle Kingdom. Scholars read these inscriptions as displays of learning or amusement, not serious attempts at secret communications.\n\nThe Caesar shift is the simplest systematic substitution. With the alphabet numbered A = 0 to Z = 25, encryption with key \\(n\\) is \\(E(x) = (x + n) \\bmod 26\\), and decryption reverses the shift. A shift of 0 or 26 produces the original text, so the cipher has only 25 possible keys. That keyspace can be exhausted by hand. A general monoalphabetic substitution, in which each of the 26 letters is mapped to any other letter, has \\(26!\\) possible keys, roughly \\(4 \\times 10^{26}\\), which removes the brute-force problem. The structural weakness remains, however. Every occurrence of a plaintext letter becomes the same ciphertext symbol, so these frequencies are preserved in the ciphertext, just shifted. The size of the keyspace therefore matters less than whether the cipher hides statistical structure.\n\nPolyalphabetic systems were designed to hide that structure by using several substitution alphabets. The very first well-documented description of a polyalphabetic cipher was by Leon Battista Alberti around 1467, and used a metal cipher disk to switch between cipher alphabets. Johannes Trithemius later introduced the tabula recta, a grid of shifted alphabets. Giovan Battista Bellaso built upon that grid and added a repeating keyword, which selected a different alphabet for each letter. The scheme was later attributed to Blaise de Vigenère, whose 1586 book described a different and stronger autokey system. The Vigenère cipher took its name because it was misattributed to Vigenère in the 19th century. Because one plaintext letter can map to several ciphertext letters, it resisted straightforward frequency counting. Its reputation was such that French cryptographers called it \"le chiffre indéchiffrable,\" the unbreakable cipher. It was eventually broken, and Friedrich Kasiski published independently in 1863 a method for doing so.\n\nDiplomatic and military correspondence often relied on nomenclators, which combined a code with a cipher. Individual syllables were identified with code groups, and a cipher alphabet was added to encrypt words or names that were not in the code list. This half code list, half cipher alphabet structure remained the same from the Italian Renaissance until about 1850.\n\nTransposition ciphers keep every plaintext letter but change its position. In a simple columnar transposition, the message is written in rows under a keyword and read off column by column in the alphabetical order of the keyword's letters. Because letter frequencies remain unchanged, an analyst looks for rearrangement patterns rather than substitution patterns. Combining the two methods yields a product cipher. The German ADFGVX cipher of 1918, which paired a substitution step with a columnar transposition, was broken by the French cryptanalyst Georges Painvin.\n\nFrequency analysis was the attack that broke simple substitution. The frequency analysis technique for breaking monoalphabetic substitution ciphers was introduced by Al-Kindi, an Arab mathematician, sometime around AD 800, and proved to be the single most significant cryptanalytic advance until World War II. His treatise, Risalah fi Istikhraj al-Mu'amma (Manuscript for the Deciphering of Cryptographic Messages), also covered polyalphabetic ciphers. Sources differ on the date, with some placing the work around 850. Al-Kindi counted letter frequencies in a sample of 3667 letters of Arabic text. The method works because in any given language, certain letters appear more frequently than others. Once a solver has matched the most common ciphertext symbols to the most common letters of the language, the substitution can be reconstructed."
    },
    {
      "heading": "Rotor machines and wartime cryptanalysis",
      "text": "The Enigma machine began as a commercial product. The German engineer Arthur Scherbius filed a patent for a rotor-based cipher machine in 1918, and his company sold commercial models in the early 1920s. The German navy and army then adopted military versions in the later 1920s. Each key press passed an electrical current through a plugboard, a set of rotors, a reflector, and back through the same components in reverse, lighting one lamp to show the output letter. Because each rotor stepped like an odometer, the substitution changed with every letter. The army's early three-rotor machines were chosen from a set of five rotors, and the reflector made encryption self-inverse, so the same settings decrypted the message. That property also meant that no letter could ever encrypt to itself, a regularity that later analysts exploited.\n\nThe plugboard added a second layer. Up to ten cables swapped ten pairs of letters before and after the rotors, which yielded roughly \\(1.5 \\times 10^{14}\\) plugboard configurations. Multiplying this by the choice and order of rotors, their starting positions, and the ring settings produced a theoretical keyspace far beyond what any manual attack could search. The security of the machine, however, depended less on this raw number than on how operators used it.\n\nPolish cryptanalysis\n\nThe Polish Cipher Bureau took up the problem in the early 1930s, when it was facing a growing threat from Germany. In 1932 it recruited a group of young mathematicians from Poznań University, among them Marian Rejewski, Henryk Zygalski and Jerzy Różycki. Rejewski used permutation group theory, applied to the intercepted traffic, to reconstruct the internal wiring of the rotors. His success depended on a procedural weakness: operators enciphered the message key twice, and the resulting repetition exposed the permutation structure. In December 1932 the Bureau also received German documents and daily key sheets obtained through French military intelligence from a spy inside the German Cipher Office in Berlin. Rejewski's team then developed mechanical aids, including a cyclometer to catalogue permutation cycles and later a cryptologic bomb, an electromechanical device that searched for daily settings and foreshadowed the British Bombe.\n\nThe Polish methods depended on fixed procedures, and these eroded in the late 1930s. In 1938 the German forces changed operating procedures and added rotors, and by 1939 the Bureau could no longer read current traffic consistently. Shortly before the outbreak of war, the Poles shared their techniques, their rotor-wiring reconstructions and their machine designs with British and French representatives at a meeting in Warsaw. After Poland was overrun in September 1939, the Polish cryptologists continued working from France, and the French and British teams built on what they had received.\n\nBletchley Park\n\nAt Bletchley Park, British cryptanalysts received this knowledge in an environment where the German procedures had grown more complex. Alan Turing and Gordon Welchman developed a much improved Bombe, an electromechanical machine that tested candidate rotor settings against a suspected plaintext fragment known as a crib. Other techniques, such as Banburismus, narrowed the search further. The resulting intelligence, known as Ultra, supplied the Allies with a steady flow of German military and naval information. Captured materials, such as the codebooks and machine recovered from the submarine U-110 in 1941, helped the British attack the more demanding naval variant, which used additional rotors.\n\nOperational errors as a major cause of failure\n\nMathematics alone did not determine the outcome. The Enigma's failures were frequently procedural. Operators repeated message keys, reused settings for too long, and chose predictable openings, standard weather reports and stock phrases that gave codebreakers reliable cribs. Germany's own changes, such as the 1940 decision to encipher the message key only once, were partly attempts to remove the weaknesses created by earlier practices. The Enigma case is therefore often cited as a demonstration that a sound machine can be undermined by its operating doctrine, key-management habits and human discipline, and not solely by its underlying mathematics."
    },
    {
      "heading": "Symmetric-key encryption",
      "text": "In symmetric-key encryption, one secret key both encrypts the plaintext and decrypts the ciphertext. Its main practical advantage is speed. Symmetric primitives are much cheaper to compute than public-key operations, so they carry nearly all of the bulk data in real systems. The cost is the key distribution problem. Two parties must already hold the same key before they communicate over a channel an adversary can observe, and a group of \\(n\\) parties that want pairwise confidentiality needs \\(n(n-1)/2\\) distinct keys, each of which must be generated, delivered, and stored securely. Much of the later development of cryptography, including the public-key methods discussed in other sections, is a response to this problem.\n\nDesign patterns\n\nMost modern symmetric ciphers are block ciphers that transform fixed-size blocks, and they are usually built by repeating a simple round function many times. Two structural families dominate. A substitution-permutation network alternates nonlinear substitution layers (S-boxes) with permutation or linear mixing layers (P-boxes). This implements the confusion and diffusion principles that Claude Shannon described in 1949. Decryption runs the same steps in reverse with inverse S-boxes and the round keys in reverse order. AES belongs to this family.\n\nA Feistel network splits each block into two halves. In each round, a round function applied to one half is XORed into the other half, and the halves are then swapped. The round function does not need to be invertible, because the structure is invertible regardless. Encryption and decryption are nearly identical and differ only in the order of the subkeys, which roughly halves the code or circuitry required. DES is a Feistel cipher, as was Lucifer, the IBM design from which it descended.\n\nDES and the limits of a 56-bit key\n\nThe Data Encryption Standard emerged from a 1970s US federal call for a protection standard for unclassified data. IBM's Lucifer-derived design was selected, the National Security Agency reviewed it and changed the S-boxes and key length, and it was published as FIPS PUB 46 in January 1977. DES encrypts 64-bit blocks in 16 rounds. Its 64-bit key input contains 8 parity bits, leaving 56 bits of effective key. The reduction from 64 to 56 bits was controversial: the reason given was the parity bits, and many observers suspected the change would make brute-force attacks easier for well-resourced agencies. An exhaustive search over \\(2^{56}\\) keys, about \\(7.2 \\times 10^{16}\\) candidates, was feasible for dedicated hardware within a few years of the standard's adoption. In 1998 a machine built by the Electronic Frontier Foundation recovered a DES key in about 22 hours. Triple DES was adopted as a stopgap, NIST recommended retiring DES in 2001, and AES formally replaced it in 2002.\n\nAES and the cost of brute force\n\nThe Advanced Encryption Standard came out of a public competition held by NIST between 1997 and 2000. It selected Rijndael, a design by Joan Daemen and Vincent Rijmen, and FIPS 197 was published on 26 November 2001. AES fixes the block size at 128 bits and allows keys of 128, 192, or 256 bits, which correspond to 10, 12, or 14 rounds. Shorter block sizes were a weakness of earlier ciphers: with a 64-bit block, collisions between ciphertext blocks become likely after roughly \\(2^{32}\\) blocks, which is why the larger block matters for long-lived data streams.\n\nBrute-force cost grows exponentially with key length. Each additional key bit doubles the search space, so a \\(k\\)-bit key requires about \\(2^{k}\\) trials in the worst case. Moving from 56 bits to 128 bits multiplies the work by \\(2^{72}\\), roughly \\(4.7 \\times 10^{21}\\). The AES-128 keyspace contains about \\(3.4 \\times 10^{38}\\) keys. Faster hardware can shorten a search but cannot keep pace with that growth, which is why key length, rather than algorithm secrecy, is the main brute-force defence. No practical break of full-round AES is publicly known, though the cost of exhaustive search is only one dimension of security. The effect of quantum algorithms on symmetric key lengths is treated in a later section."
    },
    {
      "heading": "Block ciphers, modes of operation, and stream ciphers",
      "text": "Why a block cipher needs a mode\n\nA block cipher is a keyed transformation that works on one fixed-size block at a time. AES, for example, works on 128-bit blocks. A real message is usually longer than one block, so the sender must split it, pad the last piece to a full block, and decide how each block relates to the others. That decision is the mode of operation. The earliest modes, ECB, CBC, OFB and CFB, were specified in 1981 for DES in FIPS 81 and date back to 1981 and were specified in FIPS 81, DES Modes of Operation. Most of these modes give confidentiality only. They do not detect modification, so integrity has to come from a separate mechanism, which is covered in the authenticated encryption section.\n\nElectronic codebook mode and its leakage\n\nECB is the simplest mode. Each block is encrypted separately under the same key, so the same plaintext block always produces the same ciphertext block. If two plaintext blocks are identical, their ciphertext blocks will also be identical. The result is that structure in the plaintext survives encryption. A repeated field in a database, or a large area of uniform colour in an image, appears as repeated ciphertext, and an observer can use that repetition without knowing the key. ECB does allow parallel processing, but the leakage makes it unsuitable for most data.\n\nCipher block chaining and counter modes\n\nCBC removes the determinism of ECB by feeding information from one block into the next. Each plaintext block is combined with the previous ciphertext block before encryption, and the first block is combined with an initialization vector (IV) instead, so that \\(C_i = E_K(P_i \\oplus C_{i-1})\\) with \\(C_0 = \\mathrm{IV}\\). The IV randomizes the output so that identical messages do not produce identical ciphertexts. Because each block depends on the previous one, encryption must run sequentially. The IV has strict requirements: In CBC mode, the IV must be unpredictable (random or pseudorandom) at encryption time. Reusing an IV with CBC leaks information about the first block and about any common prefix shared by two messages reusing an IV leaks some information about the first block of plaintext, and about any common prefix shared by the two messages.\n\nCounter mode takes a different route. It encrypts a sequence of counter values, and the outputs serve as a keystream that is XORed with the plaintext, so \\(C_i = P_i \\oplus E_K(N \\,\\|\\, i)\\), where \\(N\\) is a nonce. Since each block can be computed independently, CTR allows parallel processing and random access to any part of the message. Its security depends on the nonce, which is incremented for each block; in the words of one patent description, a seed (referred to as a nonce) is used as the input to the cipher, with the output XORed with the block; the seed is incremented for each subsequent block. A nonce only needs to be unique for each key, whereas the CBC IV must also be unpredictable. Predictable counters or IVs are a known source of weakness in both modes.\n\nStream ciphers and keystreams\n\nA stream cipher encrypts data one bit or byte at a time by combining it with an effectively unlimited pseudorandom sequence. The combining operation is usually exclusive-or, written \\(C = P \\oplus K\\), and decryption applies the same operation again because \\((P \\oplus K) \\oplus K = P\\). This is the same principle as the one-time pad, except that the keystream is generated from a short key rather than being truly random and as long as the message. Counter mode turns a block cipher into a stream cipher in this sense, so AES in CTR or GCM mode also behaves like one. AES is a block cipher, but in CTR or GCM mode it behaves like a stream cipher.\n\nNonce reuse\n\nThe keystream is the entire security of a stream cipher, so the same keystream must never be used twice. If two messages are encrypted with the same key and nonce, an attacker who XORs the two ciphertexts cancels the keystream and obtains the XOR of the two plaintexts. If an adversary intercepts E(A) and E(B), they can compute E(A) xor E(B), and that value equals \\(A \\oplus B\\). From there, natural-language redundancy often allows both messages to be recovered, and a known plaintext fragment reveals the keystream directly and exposes any other message encrypted with it. This is why reuse is treated as a severe failure. Real systems have suffered from it: the Wi-Fi WPA2 KRACK attacks of 2017 caused devices to reinstall a key already in use, which reset the nonce and allowed keystream reuse. Because CTR-based and stream-cipher designs share this weakness, implementations generate a fresh nonce for every message under a given key, and the cipher's security analysis assumes that discipline."
    },
    {
      "heading": "Public-key encryption",
      "text": "Public-key encryption, also called asymmetric encryption, replaces the single shared secret of symmetric systems with a pair of mathematically linked keys. The public key can be published openly and used by anyone to encrypt, while only the holder of the matching private key can decrypt. The same pair also supports digital signatures in the opposite direction: the private key produces a signature that anyone holding the public key can verify. This arrangement removes the need to deliver a secret to a partner in advance, which is the distribution problem that symmetric designs struggle with.\n\nTrapdoor one-way functions\n\nEvery widely deployed public-key scheme depends on a trapdoor one-way function: a computation that is easy to carry out in the forward direction but infeasible to invert unless one knows a secret shortcut. Three families dominate practice. RSA relies on integer factorization, since multiplying two large primes is cheap while recovering them from the product exploits the difficulty of factoring large numbers. Diffie–Hellman-style schemes rely on the discrete logarithm problem in a group, and the elliptic-curve variants apply that problem to points on a curve. Other public-key cryptosystems are based, e.g., on the difficulty of the discrete logarithm problem in Abelian groups on elliptic curves or other finite groups. None of these hardness assumptions has been proven. No \"one-way function\" has been proved to be one-way; they are merely believed to be. Security is therefore computational rather than unconditional.\n\nRSA\n\nThe RSA cryptosystem was publicly described in 1977 by Ron Rivest, Adi Shamir and Leonard Adleman, whose surnames give the initialism. Key generation begins with two distinct large primes p and q, whose product n serves as the modulus. The public key consists of n together with an encryption exponent e, while the private exponent d, which must stay secret, is derived from the prime factors. The exponent is commonly fixed at a small value; for instance, a public exponent e is selected — typically 65537 — that is coprime with φ(n). Raw RSA is deterministic and therefore unsafe on its own, so practical systems wrap messages in randomized padding such as OAEP.\n\nKey length has repeatedly had to grow as computing power increased. In 1999, 95% of e-commerce on the Internet was protected by 512-bit keys, and a 512-bit number was factored in August 1999 by 292 machines. Today, 2048-bit RSA key lengths being the standard for most websites, and 3072-bit keys are often recommended for longer-lived protection. Larger moduli make private-key operations and key generation noticeably slower.\n\nElliptic-curve cryptography\n\nElliptic-curve cryptography (ECC) reaches comparable security with far smaller keys. Rough equivalences commonly cited are that a 256-bit ECC key offers approximately the same security as a 3072-bit RSA key. A 384-bit ECC key is comparable to a 7680-bit RSA key. A 521-bit ECC key is equivalent to a 15360-bit RSA key. The smaller size reduces storage and bandwidth/transmission time requirements, which matters for constrained hardware such as smart cards or the like having limited computing power and limited memory.\n\nThe trade-off lies in the arithmetic. RSA and Diffie–Hellman mostly operate on integer fields and primarily involve modular multiplication. By contrast, it is specified over both integer and binary polynomial fields and involves modular division in addition to modular multiplication. Implementers must also choose among curves and field representations, so ECC's efficiency is harder to realize correctly than RSA's simpler structure.\n\nHybrid encryption\n\nPublic-key operations are far too slow for large payloads. Asymmetric functions are fairly time-consuming and expensive for large amounts of data. For this reason, all practical implementations of public key cryptography today employ a hybrid system. In a typical design, the sender generates a random session key, encrypts the data under a fast symmetric cipher (such as AES-GCM or ChaCha20-Poly1305), and then encrypts only that short session key under the recipient's public key. The recipient uses the private key to recover the session key and then decrypts the bulk data. Formally, the public-key part is a key encapsulation mechanism and the symmetric part is a data encapsulation scheme. For very long messages the bulk of the work in encryption/decryption is done by the more efficient symmetric-key scheme, while the inefficient public-key scheme is used only to encrypt/decrypt a short key value.\n\nThe approach also limits exposure: because the session key is fresh, if one encrypted message is compromised, the attacker usually does not gain access to every other message or file protected with a different key. Standardized forms exist, such as the Hybrid Public Key Encryption scheme specified in RFC 9180. Protecting the private key remains the critical dependency, and forward secrecy and key-management issues are treated in the next section."
    },
    {
      "heading": "Key exchange and key management",
      "text": "Diffie–Hellman and agreeing on a secret in public\n\nBefore the 1970s, two correspondents had to solve the key problem before any ciphertext could travel. Secure encrypted communication typically required the parties to first exchange keys by a secure physical means, such as paper key lists carried by a trusted courier.\n\nWhitfield Diffie and Martin Hellman changed this in 1976. The Diffie–Hellman key exchange method lets two parties with no prior relationship jointly establish a shared secret over an insecure channel, and that secret can then key a symmetric cipher for later traffic. The protocol is public-key-era work in the sense that it made key agreement possible without a secret channel, though it does not itself encrypt anything or identify the parties.\n\nThe arithmetic is simple to state. The parties agree on a large prime \\(p\\) and a generator \\(g\\) of the multiplicative group modulo \\(p\\) (see modular-arithmetic and prime-number). Alice picks a private exponent \\(a\\) and publishes \\(A = g^{a} \\bmod p\\); Bob picks \\(b\\) and publishes \\(B = g^{b} \\bmod p\\). Each side then raises the other's public value to its own private exponent, so both obtain \\(g^{ab} \\bmod p\\). An eavesdropper sees \\(p\\), \\(g\\), \\(A\\) and \\(B\\), but recovering \\(a\\) or \\(b\\) requires solving the discrete logarithm problem, which is believed to be infeasible for well-chosen parameters.\n\nThe history is more tangled than the 1976 date suggests. The idea was separately invented a few years earlier within GCHQ, the British signals intelligence agency, by Malcolm J. Williamson, but was kept classified. Ralph Merkle's independent work on public-key protocols is also credited, and Hellman later proposed the name Diffie–Hellman–Merkle. The scheme was named as one of Ralph Merkle's original public key protocols in 1978.\n\nUnauthenticated Diffie–Hellman is open to a man-in-the-middle attack: an active attacker who intercepts both public values can agree separate keys with each side. Authenticating the exchange therefore requires some independent trust mechanism, which is the main reason certificates matter in practice (see below).\n\nForward secrecy and ephemeral keys\n\nIf a session key is derived from a server's long-term private key, anyone who records the traffic can decrypt it later after stealing that key. Forward secrecy means that even if an attacker later obtains a party's long-term private key, past encrypted sessions cannot be decrypted. The usual remedy is an ephemeral key exchange: each session uses freshly generated key pairs, and those values are discarded afterwards. TLS 1.3 uses the Ephemeral Diffie-Hellman protocol, which produces a one-time key for the current session, and the key is discarded when the session ends.\n\nForward secrecy does not remove the need for long-term keys. The server still signs the handshake with its certificate key so the client knows whom it is talking to, but that signature authenticates the exchange rather than protecting the session key. In TLS 1.3 this arrangement is mandatory, while TLS 1.2 made it optional. In TLS 1.3, only ephemeral key exchanges such as DHE and ECDHE are permitted.\n\nA key encapsulation mechanism (KEM) packages a similar idea in a different shape. Instead of both parties contributing a value, the sender uses the recipient's public key to encapsulate a random secret, producing a ciphertext and a shared key; the recipient decapsulates the ciphertext to recover the same key. KEMs can serve as ephemeral key exchange and are the form in which post-quantum key agreement is standardized (covered in a later section).\n\nPublic key infrastructure and trust\n\nPublic-key cryptography answers the question \"which key belongs to whom?\" only partially. Public key infrastructure (PKI) addresses this by binding identities to keys. It uses a combination of cryptography, trusted roles, systems and operating rules to bind a public key to an identity. The central object is the digital certificate, which a certificate authority (CA) signs after checking the applicant. A Certificate Authority validates the entity's identity and issues a digital certificate, binding the public key to that identity.\n\nTrust is usually organized as a chain. The root CA is the trust anchor, and its self-signed certificate is installed or otherwise trusted by operating systems, browsers, enterprises or applications. Root certificates are typically kept offline, and intermediate CAs issue day-to-day certificates on their behalf. Revocation is handled through a certificate revocation list (CRL) or an online status protocol (OCSP), which checks that a certificate has not been revoked.\n\nThe model has a structural weakness: every user must rely on the CA's procedures. In the case of PKI, a Certification Authority issues certificates containing public keys, and users have no choice but to trust the practices of the organisation running the CA. A compromised CA can issue convincing forged certificates, which is why root stores, certificate transparency logs and distributed CA designs exist.\n\nAlternative trust models exist. The web of trust used by PGP-style systems leaves trust decisions in the hands of individual users, rather than delegating them to a hierarchy. Enterprise deployments sometimes use bridge CAs, in which all other CAs must trust only the Bridge CA, or mesh arrangements where separate CA domains cross-certify one another. Decentralized variants replace the hierarchy with non-hierarchical records, though none of these models removes the need to decide whose statements to believe.\n\nKey generation, storage, rotation and hardware security modules\n\nKey lifecycle management is where many systems fail in practice, even when the algorithms are sound. Generating a key requires high-quality randomness, since a predictable generator yields predictable keys (see randomization). Storage is the next weak point: a key kept as a plain file on a general-purpose machine is exposed to any software that compromises that machine. A hardware security module (HSM) is a tamper-resistant device that generates keys and performs cryptographic operations internally, so that the private key never leaves it in usable form. PKI products commonly include HSMs among their components, and certificate authorities rely on them to protect their signing keys.\n\nRotation limits the damage from a key that is compromised without anyone noticing. Replacing keys on a schedule, and immediately after any suspected exposure, bounds how much data an attacker can read or forge. Organizations often use a hierarchy of keys, in which a small number of long-lived master keys protect shorter-lived data or session keys, so rotation at one level does not require re-encrypting everything. Revocation, backup, escrow and retirement of old keys complete the lifecycle, and each step adds operational risk of its own."
    },
    {
      "heading": "Provable security and formal definitions",
      "text": "Semantic security and indistinguishability games\n\nProvable security replaces informal claims of resistance to known attacks with a precise statement of what an adversary must be unable to learn. The standard formalization is the indistinguishability game. The cryptosystem is considered secure if no adversary can win the game with significantly greater probability than an adversary who must guess randomly. The adversary's advantage is its success probability above one half, and security requires this advantage to be a negligible function of the security parameter.\n\nThe weakest common version, IND-CPA, lets the adversary choose plaintexts and see their encryptions. The adversary then submits two messages of its choice, and a hidden random bit determines which one is encrypted. Because the encryption is probabilistic, one encrypted version of M_b is only one of many valid ciphertexts, so the adversary cannot gain a useful edge by encrypting the two candidates itself and comparing. This is why IND-CPA forces randomized encryption: a deterministic scheme would let the adversary recognize a repeated plaintext.\n\nStronger notions give the adversary decryption power. IND-CCA models an adversary that may adaptively request decryptions of chosen ciphertexts, except for the challenge ciphertext. IND-CCA2 extends this to decryption queries both before and after the challenge. The notions form a hierarchy: security under the stronger definitions implies security under the weaker ones, so IND-CCA2 is the strongest of the three. The same family of notions is also tied to other properties; indistinguishability can imply integrity, which is related to non-malleability.\n\nReductions and their limits\n\nMost schemes used in practice cannot be proven secure unconditionally. Instead, a reduction shows that any efficient attacker on the scheme could be converted into an algorithm that solves a problem assumed to be hard, such as factoring or the discrete logarithm. The strength of such a result depends on the assumption, on the quality of the reduction, and on the concrete parameters. A reduction can be loose: one analysis notes that the security reduction for one variant to the underlying primitives is looser than the earlier one in terms of concrete bounds. If a proof makes no formal demand that the underlying scheme be secure, the reduction could potentially be trivial.\n\nMany efficient constructions are proven only in the random oracle model, an idealization in which a hash function is replaced by a truly random function. This model is appealing as it allows simpler security proofs. Critics note that this idealization is not generally justified. Replacing the oracle with a concrete hash function can break a scheme even when the proof was valid in the idealized setting, and some reductions depend on a property, programmability, that hash functions with programmability capacities are not known to exist in the form such proofs require. Proofs in this model are therefore usually read as heuristic evidence rather than full guarantees. Post-quantum proofs face an additional requirement: post-quantum security proofs have to be in the quantum random oracle model.\n\nInformation-theoretic security\n\nClaude Shannon's 1949 work on secrecy systems gave a different standard. Shannon proved the perfect secrecy of the Vernam cryptographic system, also popularly known as the one-time pad. In Shannon's sense, the ciphertext gives absolutely no additional information about the plaintext. Formally, the a priori distribution of the plaintext equals its distribution conditioned on the ciphertext, which can be written as \\(H(M) = H(M \\mid C)\\), where \\(H\\) denotes entropy and \\(C\\) the ciphertext.\n\nPerfect secrecy comes at a high price. Perfect secrecy requires as many keys as possible messages, so with a key of the same length as the message, all keys must be possible. A one-time pad therefore needs keys as long as the total traffic, and the key must never be reused. Shannon also showed that the key material for any other perfectly secure cipher must have the same properties as one-time pad keys. This impracticality is the reason most deployed systems instead rely on computational security, where adversaries are limited to polynomial-time computation.\n\nSome commentators have challenged the reach of Shannon's result. One critique argues that any proof of perfect secrecy would require two incompatible definitions of randomness. This dispute concerns definitions and modeling, and it does not change the practical conclusion that perfect secrecy requires keys as large as the message."
    },
    {
      "heading": "Authenticated encryption and integrity",
      "text": "Why confidentiality alone is not enough\n\nEncryption hides the content of a message, but it does not by itself show whether the message has been changed. Many stream ciphers combine a keystream with the plaintext using XOR, so flipping a bit in the ciphertext flips the matching bit after decryption. An attacker who can guess the structure of a message can therefore make predictable edits without learning the key. Some block-cipher modes have similar weaknesses. A receiver that decrypts without checking integrity may act on forged or corrupted data, and the decryption step itself can become a channel through which an attacker learns about the plaintext.\n\nMessage authentication codes\n\nThe standard remedy is a message authentication code (MAC): a short tag computed from the message and a secret key, which the receiver recomputes and compares with the tag it received. Without the key, an attacker cannot produce a valid tag for an altered message. Combining a MAC with encryption requires care about order. The three possible arrangements are encrypt-then-MAC, MAC-then-encrypt, and encrypt-and-MAC. Encrypt-then-MAC, in which the tag covers the ciphertext, is generally regarded as the most robust, while the other two have produced documented flaws in protocols. The encryption key and the MAC key should be independent, and tag comparison should run in constant time so that response timing does not reveal how many bytes matched.\n\nAEAD constructions\n\nAuthenticated encryption with associated data (AEAD) packages encryption and integrity into a single primitive. It takes a key, a nonce, the plaintext, and optional associated data, such as packet headers, which are not encrypted but are covered by the tag. It outputs the ciphertext and a tag. Decryption checks the tag first and releases no plaintext if the check fails. Because separately composed schemes proved easy to misuse, cryptographers now generally advise using AEAD schemes and CCA-secure public-key encryption instead.\n\nAES-GCM pairs AES in counter mode with a polynomial hash over a Galois field to authenticate the ciphertext and the associated data. It is the most widely deployed AEAD and benefits from hardware acceleration on many processors. Its security depends on never reusing a nonce under the same key: a repeated nonce can expose the authentication key and allow forgeries.\n\nChaCha20-Poly1305 combines the ChaCha20 stream cipher with the Poly1305 MAC, both designed by Daniel J. Bernstein. It is specified in RFC 8439 and is one of the cipher options in TLS 1.3. It runs quickly in software on hardware without AES acceleration and is easier to implement in constant time. It is not nonce-misuse resistant either: reusing a nonce breaks it. The XChaCha20-Poly1305 variant uses 192-bit nonces, which allows nonces to be generated at random for large message volumes without a realistic collision risk.\n\nPadding oracle attacks\n\nPadding oracle attacks show what happens when encryption and integrity are composed poorly. In CBC mode, plaintext must be padded to whole blocks before encryption. If a decryptor reveals whether the padding was valid, through an explicit error, a distinguishable error message, or a timing difference, an attacker can alter ciphertext blocks and observe the responses. Each query leaks a small amount of information, and many queries can recover the plaintext byte by byte without the key. Vaudenay described this class of attack in 2002. Later attacks, including Lucky Thirteen (2013), which exploited timing differences in TLS, and POODLE (2014), which affected SSL 3.0, demonstrated that the weakness was exploitable in deployed protocols. Standard defences include verifying the MAC before removing padding, using AEAD modes that have no padding, and returning uniform error responses."
    },
    {
      "heading": "Cryptanalysis and attack models",
      "text": "Attack models\n\nCryptanalysis is usually classified by how much the attacker can see or do. In the weakest case, the attacker has access to a number of ciphertexts. A known-plaintext attack gives the attacker pairs of plaintext and ciphertext, and a chosen-plaintext attack lets the attacker pick the plaintexts and receive their encryptions. A chosen-plaintext attack can be batch, where all inputs are fixed in advance, or adaptive, where each query depends on earlier answers. The chosen-ciphertext model runs the other way: the attacker obtains decryptions of ciphertexts of its choice, in adaptive or indifferent form.\n\nThese models are ordered by strength. A scheme that withstands chosen-plaintext attacks is also guaranteed to be secure against known-plaintext and ciphertext-only attacks. Modern schemes are designed for semantic security, and they are therefore, by design, generally immune to chosen-plaintext attacks if correctly implemented. The model also matches practice. The Allies in the Second World War used a technique termed Gardening against Enigma traffic, which behaves like a chosen-plaintext attack. Public-key schemes give every adversary this power, because the adversaries have direct access to the public keys. A chosen-ciphertext attack is more damaging: a number of otherwise secure schemes can be defeated under chosen-ciphertext attack. This is why padding and encryption schemes are judged against adaptive chosen-ciphertext security (see the provable-security section).\n\nBrute force, time–memory trade-offs and weak keys\n\nThe baseline attack is exhaustive key search. For an n-bit key, this costs on the order of \\(2^n\\) trial decryptions, so each added key bit doubles the work. The 56-bit key of DES was therefore vulnerable to dedicated hardware by the late 1990s, with the EFF's machine recovering a key in about two days in 1998.\n\nTime–memory trade-offs reduce online work by spending effort in advance. Hellman's method (1980) precomputes chains of keys and stores endpoints; for a keyspace of size N, time T and memory M roughly satisfy \\(T \\cdot M^2 \\approx N^2\\). Rainbow tables apply the same idea to password hashes, and salting is the standard defence because it forces a separate precomputation for each salt.\n\nWeak or reused keys weaken security more directly. Some algorithms have known weak keys or equivalent keys, which shrink the effective search space. Reuse across messages is more dangerous: if two messages are encrypted with the same keystream, XOR-ing the ciphertexts cancels the keystream and leaks the XOR of the plaintexts, a failure related to the one-time pad requirement that a key never be reused.\n\nDifferential and linear cryptanalysis\n\nDifferential cryptanalysis was introduced by Biham and Shamir in 1990 as a chosen-plaintext attack for cryptanalyzing ciphers based on substitutions and permutations. It tracks how a difference between two inputs propagates through the S-boxes and is based on using the imbalances in the 'pairs XOR distribution table', for an S-box, to predict the output XOR from the input. By 1993 the authors had published a full cryptanalysis of all 16 rounds of DES. The DES designers had anticipated the technique. The DES S-boxes were deliberately designed to resist differential cryptanalysis, as confirmed by Don Coppersmith, and the criteria were published in 1994 after the public rediscovery of the attack. Biham and Shamir also showed that even small modifications to an S-box could significantly weaken DES.\n\nThe attack motivated a set of design criteria. These include the strict avalanche criterion, in which complementing a single input bit results in each output bit changing with a probability of one half, and nonlinearity. Nyberg's perfect nonlinear S-boxes, for example, are immune to this attack because the attack depends on nonbalanced direction derivatives.\n\nLinear cryptanalysis was introduced by Matsui at Eurocrypt 1993. It is a known plaintext attack in which the attacker studies probabilistic linear relations between parity bits of the plaintext, the ciphertext, and the secret key. Its strength is measured by the bias \\(\\varepsilon = |p - \\tfrac{1}{2}|\\) of such a relation. Matsui's attack on full 16-round DES required 243 known plaintext-ciphertext pairs. The method can sometimes be used in a ciphertext-only setting: if plaintexts are natural English sentences represented by ASCII codes, 8-round DES cipher is breakable with 2^29 ciphertexts only. Linear attacks also constrain S-box design, because constraints on the size of S boxes follow from them.\n\nRetirement of weakened algorithms\n\nAttacks like these have repeatedly forced algorithms out of service. DES was withdrawn as a federal standard in 2005 and superseded by AES. NIST later restricted Triple DES to legacy use. RC4 was prohibited for TLS in 2015 after a series of biases in its keystream. SHA-1 was shown to have practical collisions in 2017, which led to its retirement from certificate signing and other uses.\n\nRetirement is difficult in practice. Protocols often negotiate algorithms, so servers that keep old options for compatibility expose clients to downgrade attacks; FREAK and Logjam (both 2015) exploited export-grade ciphers that remained in use. Birthday-bound weaknesses, such as the SWEET32 attack on 64-bit block ciphers in 2016, show that a block size can become a limit even when the key is strong. Replacing a primitive therefore requires cryptographic agility, meaning that deployed software can switch algorithms without redesign."
    },
    {
      "heading": "Implementation security and side channels",
      "text": "Most of the cryptographic schemes in use are not broken mathematically. Attackers more often exploit the way a scheme is implemented on a physical device, in software, or in an operating environment. Such attacks are usually called side-channel attacks when they use information that leaks as a by-product of computation, and fault attacks when they deliberately disturb a computation. Both show that a secure algorithm can still fail when its execution is observable.\n\nTiming and cache leakage\n\nThe first widely studied side channel was timing. In 1996, Kocher was the first to design a timing attack against cryptosystems based on modular exponentiation, such as RSA. The key observation was that the running time of an implementation can depend on the secret data it processes. Common sources of such variation include branching and conditional statements, RAM cache hits, and processor instructions that run in non-fixed time. Kocher showed that an eavesdropper who can measure how long a target takes on several chosen inputs can recover the secret exponent. The same class of problem later reached software libraries: Brumley and Boneh applied a related attack to OpenSSL, and this attack was extended to OpenSSL (RSA, CRT, sliding window exponentiation algorithm, Montgomery's multiplication algorithm). Cache-based attacks extended the idea further, since an attacker sharing a processor with a victim can infer which memory lines were accessed. Cache attacks on table-driven AES implementations and on shared hardware have been a recurring theme in later research.\n\nPower analysis and electromagnetic emanation\n\nPhysical measurements provide even richer leakage. In 1998, Kocher and colleagues reported that the secret key of an executing cryptographic algorithm could be extracted by monitoring the power consumption of a smart card. Simple power analysis reads secrets directly from a single trace, for example by identifying which instructions ran in a given clock cycle. Differential power analysis is statistical: the attacker studies multiple power consumption curves recorded from different executions with different inputs, and looks for statistical differences between particular subsets of executions which are correlated with particular key bits. Such attacks can be carried out without leaving any trace on the card, which made them especially troubling for payment and identity cards. Electromagnetic emanations offer a similar channel that does not require physical contact with the circuit; Quisquater and Samyde's early work on ElectroMagnetic Analysis (EMA) for smart cards is an example. Countermeasures include masking intermediate values with random numbers and blinding the exponent or the message, as in Kocher's own proposals.\n\nFault injection\n\nFault attacks deliberately induce errors, using voltage glitches, clock manipulation, laser pulses, or radiation. The most famous example is the Bellcore attack, announced in 1997 by Boneh, DeMillo, and Lipton, which targets RSA implemented with the Chinese Remainder Theorem for speed. If one half of the computation is corrupted, the attacker gets an erroneous signature and can recover a prime factor as gcd(N, S − Ŝ) with overwhelming probability. A single faulty signature suffices for the attack, which is why a well-timed fault can expose the secret key of an otherwise correct algorithm. Ironically, some protections can create new weaknesses: research on OpenSSL found that one of the faults found is made possible because of the existence of such protection. Countermeasures include verifying the result before output, avoiding the CRT shortcut, and formally analysing defenses against random, zeroing, and skipping faults.\n\nConstant-time programming and hardware\n\nThe main defence against timing leakage is constant-time programming: code is written so that its control flow and memory access pattern do not depend on secret values. Examples include replacing secret-dependent branches with bitwise selection, avoiding table lookups indexed by secret bytes, and using constant-time comparisons for authentication tags. Some deployments accept a performance penalty to achieve this. This is a simple fix but it does degrade performance. Hardware acceleration has been a partial remedy. Dedicated instructions for AES and carry-less multiplication in mainstream processors execute in fixed time and avoid many table-based leaks, although they do not eliminate side channels in general, and hardware support can itself leak through power or fault effects.\n\nRandomness, software errors, and operational failures\n\nRandom numbers underpin key generation, nonces, and blinding, so weak randomness is among the most damaging failures. The Debian OpenSSL incident of 2006–2008, in which a code change left the random pool with almost no entropy, caused SSH and TLS keys generated on affected systems to come from a space of only about 32,000 possible values. Other failures have arisen from entropy shortages on embedded devices and virtual machines at boot. Software errors are another frequent cause of compromise: the Heartbleed bug of 2014 in OpenSSL allowed remote memory reads that could expose private keys, and cold-boot research showed that key material can persist in DRAM after power loss. Misconfiguration, such as reusing keys across devices, leaving debugging interfaces enabled, or storing keys in plain text next to encrypted data, often matters more than any theoretical weakness. In practice, the gap between a verified algorithm and a secure deployment is usually closed by careful engineering, testing, and key-management discipline, which is also why open review of implementations is valued."
    },
    {
      "heading": "Standardization and public competitions",
      "text": "The cryptographic algorithms that protect most modern data are chosen through public standardization rather than by secret design, and the US National Institute of Standards and Technology (NIST) has been the most influential body in this process. Its choices for the Data Encryption Standard (DES) and the Advanced Encryption Standard (AES) show both the benefits of open evaluation and the problems that arise when a standard's weaknesses are discovered late.\n\nDES and the limits of a 56-bit key\n\nDES was adopted as a federal standard in 1977, and the US government encouraged its use for all non-classified data. Its key length was criticized from the start: at 56 bits, the key space is about \\(2^{56} \\approx 7.2 \\times 10^{16}\\) possible keys, which was considered small even in the 1970s. The weakness was demonstrated in public. In 1997 and 1998, RSA Data Security ran a series of DES challenges with cash prizes. In 1998 the Electronic Frontier Foundation (EFF) built Deep Crack, a special-purpose machine that cost roughly $250,000, and recovered a DES key in about 56 hours. In January 1999, working with the distributed.net volunteer network, the same approach found a key in roughly 22 hours. Sources differ slightly on the exact figure, but the conclusion is the same: a 56-bit key could be exhausted by a determined attacker with modest resources. Triple DES, which applies DES three times, was kept as a transitional measure, but DES itself was later declared obsolete and superseded by AES in 2002. Some legacy systems, such as certain Kerberos deployments, continued to rely on DES because older products did not support newer ciphers.\n\nThe AES competition, 1997–2001\n\nNIST opened the AES process in 1997 by calling for candidate block ciphers from the public. The first round, from August 1998 to April 1999, drew fifteen submissions, and NIST narrowed them to five finalists: MARS, RC6, Rijndael, Serpent and Twofish. A second round of analysis followed, with public comments accepted until May 15, 2000. NIST also held an open conference in April 2000, at which the submitters could respond to cryptanalytic results in front of the community. On October 2, 2000, NIST announced that it had chosen Rijndael, a design by the Belgian cryptographers Joan Daemen and Vincent Rijmen. NIST stated that all five finalists offered a high degree of security, and it selected Rijndael for the best combination of security, performance, efficiency and flexibility. The algorithm was published as Federal Information Processing Standard 197 on November 26, 2001, and became effective as a federal standard in May 2002.\n\nWhat AES specifies\n\nFIPS 197 defines three members of the Rijndael family, AES-128, AES-192 and AES-256. Each encrypts 128-bit blocks, and the number in the name gives the key length in bits. Each extra key bit doubles the work of an exhaustive search, so moving from a 56-bit to a 128-bit key multiplies the brute-force effort by \\(2^{72} \\approx 4.7 \\times 10^{21}\\). Even the 128-bit variant has about \\(3.4 \\times 10^{38}\\) keys, and no practical attack on the full cipher has been found. Unlike DES, which uses a Feistel structure, AES is built as a substitution–permutation network. AES was also incorporated into the international standard ISO/IEC 18033-3, which extended its reach beyond the United States.\n\nOther standards bodies and protocol standards\n\nNIST standards govern algorithms, but how encryption is used in practice is determined largely by other bodies. The Internet Engineering Task Force (IETF) publishes protocol specifications, such as those for Transport Layer Security, through a public document process; the ISO/IEC joint committee standardizes algorithms and modes internationally; and national agencies in several countries maintain their own recommendations. These bodies do not always agree, and an algorithm that is acceptable in one jurisdiction may be restricted or unnecessary in another.\n\nAgility, deprecation and open review\n\nStandards must be able to change. Cryptographic agility refers to designs in which protocols can negotiate or replace algorithms, so that a broken primitive can be retired without redesigning the whole system. Deprecation cycles define when old algorithms are withdrawn, and these cycles are often slow because deployed devices and software remain in use for years. A clear example of the risk of trusting a standard without scrutiny is Dual_EC_DRBG, a random bit generator included in NIST SP 800-90A. Cryptographers raised concerns in 2007 that its design could allow a party with secret constants to predict its output. After leaked documents in 2013 linked the algorithm to the NSA, NIST advised against using it, and in 2014 it removed the algorithm from the standard. NIST also reviewed its standards development process as a result. The episode shows why open public review, published analysis and the ability to replace algorithms are as important as the mathematics itself."
    },
    {
      "heading": "Post-quantum encryption",
      "text": "The quantum threat to existing schemes\n\nWidely used public-key systems such as RSA and elliptic-curve cryptography rely on problems that are hard for classical computers: factoring large integers and computing discrete logarithms. Shor's algorithm, published by Peter Shor in 1994, shows that a sufficiently large, fault-tolerant quantum computer could solve both problems in polynomial time. This would break these schemes outright rather than merely weakening them. Symmetric ciphers and hash functions are affected far less. Grover's algorithm gives only a quadratic speedup for unstructured search, so an exhaustive search over \\(2^{k}\\) keys needs on the order of \\(2^{k/2}\\) quantum operations. Doubling the key length, for example moving from AES-128 to AES-256, therefore restores a comfortable margin.\n\nThe NIST standards\n\nNIST published its first three post-quantum standards on 13 August 2024. FIPS 203 specifies ML-KEM, a key-encapsulation mechanism derived from CRYSTALS-Kyber and intended to establish shared secrets and protect symmetric keys. FIPS 204 specifies ML-DSA, derived from CRYSTALS-Dilithium, for general digital signatures. FIPS 205 specifies SLH-DSA, derived from SPHINCS+, a stateless hash-based signature scheme whose security depends only on the properties of hash functions. ML-KEM comes in three parameter sets, ML-KEM-512, -768 and -1024, which NIST aligns roughly with the security levels of AES-128, AES-192 and AES-256.\n\nA fourth signature standard, FN-DSA (FIPS 206), based on FALCON, was still unfinished in the sources reviewed, with final publication expected around late 2026 or early 2027. In March 2025 NIST also selected HQC as a backup key-encapsulation mechanism. The choice is deliberately redundant: HQC rests on decoding error-correcting codes rather than on lattices, so a weakness discovered in lattice problems would not automatically compromise every deployed key exchange. HQC is not a replacement for ML-KEM, and its formal standard is expected only after a draft and public comment period.\n\nMigration timelines and hybrid deployment\n\nNIST IR 8547, released as an initial public draft in November 2024, proposes deprecating quantum-vulnerable public-key algorithms at the 112-bit security level after 2030 and disallowing all quantum-vulnerable public-key algorithms after 2035. The 2035 horizon matches the broader goal in US federal policy for moving government systems to quantum-resistant cryptography, while the NSA's CNSA 2.0 suite sets earlier deadlines for national security systems. Because IR 8547 is still a draft in the sources reviewed, its dates are best read as planning baselines rather than settled law.\n\nMost near-term deployments are hybrid. In TLS, ML-KEM is commonly combined with a classical elliptic-curve exchange such as X25519, so the session remains protected if either component holds. The IETF has standardized one such combination, X25519MLKEM768, for TLS 1.3. The cost is larger handshakes and more complicated implementations, which is why migration is often staged rather than done in one step.\n\nLattice-, code- and hash-based trade-offs\n\nPost-quantum schemes rest on different hard problems, and these differences show up in key size and speed. Lattice-based schemes such as ML-KEM and ML-DSA are comparatively fast and are the default choice for most applications, but their keys and signatures are much larger than classical elliptic-curve values. For ML-KEM-768 the public key is roughly 1,184 bytes and the ciphertext roughly 1,088 bytes. The ML-DSA-65 signature is roughly 3,309 bytes. Code-based schemes such as HQC are more resource-intensive than ML-KEM, which is why NIST treats them as a contingency. Hash-based SLH-DSA has the most conservative security assumptions and very small public keys, for example about 32 bytes for SLH-DSA-SHA2-128s, but its signatures are far larger, around 7,856 bytes for the same parameter set, and signing is slower."
    },
    {
      "heading": "Advanced encryption schemes",
      "text": "Homomorphic encryption\n\nA homomorphic encryption scheme lets a party compute on ciphertexts without decrypting them, so that decrypting the result gives the same outcome as performing the corresponding operation on the plaintexts. Early schemes were only partially homomorphic. Unpadded RSA and ElGamal are multiplicative, meaning the product of two ciphertexts decrypts to the product of the plaintexts, and Paillier's 1999 scheme is additive. Somewhat homomorphic schemes support both addition and multiplication, but only for a limited number of operations, because each ciphertext carries noise that grows with every computation until decryption fails.\n\nCraig Gentry's 2009 doctoral thesis at Stanford introduced the first fully homomorphic encryption (FHE) scheme, built on ideal lattices. Its key device, bootstrapping, evaluates the scheme's own decryption circuit homomorphically, producing a fresh ciphertext with reduced noise and allowing unlimited computation in principle. The original construction was far too slow for practical use. Later schemes, such as BGV, BFV, CKKS and TFHE, are built on ring-based lattice problems and work on polynomials over rings, and they are much faster, though computation on encrypted data still costs far more than on plaintext. CKKS handles approximate arithmetic on real numbers, which makes it relevant to machine learning. A typical application is outsourcing computation over sensitive data, such as medical or financial records, to a cloud provider that never sees the inputs or outputs in clear form.\n\nAttribute-based and functional encryption\n\nOrdinary public-key encryption requires the sender to know which specific recipient will decrypt. Attribute-based encryption (ABE) instead ties decryption to properties of the user. Amit Sahai and Brent Waters introduced the underlying idea in 2005 as fuzzy identity-based encryption. In key-policy ABE, ciphertexts are labelled with attributes and user keys embed an access policy. In ciphertext-policy ABE, developed by Bethencourt, Sahai and Waters in 2007, the policy is attached to the ciphertext and the user's key carries the attributes. A user can decrypt only if the attributes satisfy the policy, and users should not be able to pool partial attributes to gain access they lack individually. This suits fine-grained access control in enterprise data sharing and cloud storage.\n\nFunctional encryption generalizes this idea. A secret key corresponds to a function \\(f\\), and decrypting an encryption of a message \\(m\\) reveals \\(f(m)\\) and nothing else about \\(m\\). Boneh, Sahai and Waters formalized the notion in 2011. General constructions remain costly, and practical schemes are limited to restricted classes of functions.\n\nSearchable and format-preserving encryption\n\nSearchable encryption allows a server to locate records matching a query without learning their contents. Song, Wagner and Perrig published an early symmetric-key scheme in 2000 that let a server test encrypted words for matches. Practical designs inevitably leak information, such as which records match a query and whether the same query was repeated. Research has shown that such access-pattern leakage can enable inference attacks on encrypted databases, so the efficiency of these schemes is traded against the leakage they permit.\n\nFormat-preserving encryption (FPE) produces a ciphertext in the same format as the plaintext, for example a sixteen-digit string for a payment card number. This allows encrypted values to fit into legacy databases and forms without schema changes. Constructions are usually based on Feistel networks or small-domain techniques such as cycle walking. NIST's SP 800-38G standardizes the FF1 mode and the revised FF3-1 mode, the latter replacing an earlier FF3 mode after cryptanalytic concerns.\n\nZero-knowledge proofs and encryption\n\nA zero-knowledge proof lets a prover convince a verifier that a statement is true without revealing anything beyond that truth. Goldwasser, Micali and Rackoff introduced the concept in 1985. It is often confused with encryption, but the two serve different purposes. Encryption hides data so that an authorized party can later recover it, whereas a zero-knowledge proof hides a secret witness while demonstrating a property of it and has no decryption step. Zero-knowledge proofs can, however, be combined with encryption, for example to prove that a ciphertext contains a valid value without revealing the value. Succinct variants such as zk-SNARKs are used in privacy-preserving and scalable blockchain systems."
    },
    {
      "heading": "Applications in networks, storage, and devices",
      "text": "Network traffic\n\nMost encryption that people encounter daily sits underneath other software, inside network protocols. Transport Layer Security (TLS) protects web traffic: client and server run a handshake to agree on keys, after which the session is encrypted and checked for tampering, and the server's identity is vouched for by a certificate (see the key management section). TLS 1.3 is the current version. It shortens the handshake to one round trip in the usual case and drops legacy algorithms, while TLS 1.0 and 1.1 have been formally deprecated. Adoption figures depend on how they are measured. Qualys SSL Pulse reported that 75.3% of surveyed top sites supported TLS 1.3 in June 2025, whereas traffic-weighted measurements from 2026 put TLS 1.3's share of live HTTPS requests at roughly 72%, and the share of human web requests carried over HTTPS at about 98.8%. These numbers measure different things, so they should not be compared directly.\n\nVirtual private networks (VPNs) extend this protection to whole network paths. A VPN creates an encrypted tunnel between a device and a gateway, or between two sites, so that traffic crossing an untrusted network is unreadable to observers along the way. IPsec, a suite standardized in the IETF, works at the IP layer: the Internet Key Exchange protocol negotiates keys and security associations, and the resulting packets are authenticated and encrypted. It is common in site-to-site corporate links. Other VPNs run over TLS or use newer designs such as WireGuard. A VPN protects the path between endpoints, not the endpoints themselves, and the VPN provider becomes a party that must be trusted.\n\nMessaging\n\nEnd-to-end encrypted (E2EE) messaging encrypts a message on the sender's device and decrypts it only on the recipient's device, so the service in the middle relays ciphertext. The Signal Protocol is the most widely deployed design: an extended triple Diffie–Hellman exchange establishes a session, and the Double Ratchet algorithm then replaces keys continuously, which gives forward secrecy and recovery after a key compromise. Signal and WhatsApp both use it, and Facebook Messenger, iMessage and Telegram offer forms of E2EE as well.\n\nE2EE is not the same as full privacy. Most such systems still expose metadata: who communicates with whom, when, and how often. Signal's \"sealed sender\" feature reduces this exposure, but it does not eliminate it. Key control is also a trade-off. Because the provider holds no keys, it cannot read content, but users must verify keys, for example by comparing safety numbers, to detect a substituted key, and losing every device can mean losing history. Providers that hold or can access keys can offer account recovery, server-side search, and moderation, but they can also be compelled to disclose data. Backups are often the weak point: a message protected end to end can be exposed if an unencrypted cloud backup holds a copy. Apple's Advanced Data Protection (2022) allowed iCloud backups to be encrypted end to end, and WhatsApp offers optional end-to-end encrypted backups that many users leave disabled.\n\nStorage and devices\n\nFull-disk encryption protects the entire contents of a drive. BitLocker on Windows, FileVault on macOS, LUKS on Linux, and the built-in encryption of Android and iOS all bind the data key to the user's passcode and, where available, to a hardware element such as a trusted platform module or secure enclave. This makes a stolen device with a strong passcode difficult to read offline. It does not protect against someone who already has the unlocked device, against malware running in a logged-in session, or against weak passcodes, and short numeric codes are easy to guess. File-level encryption works on individual files or folders, which makes selective sharing and separate keys for different data possible.\n\nEncrypted cloud storage has two main models. In provider-managed encryption, the service encrypts data at rest and holds the keys, which supports recovery, search and previews but means the provider can read the data. In client-side encryption, the user holds the keys, which protects against a provider breach or a legal demand for plaintext, but at the cost of lost-key recovery and of features that need server access to content.\n\nPayments, digital identity, and cryptocurrency\n\nPublic-key signatures are used wherever a party must prove authorship without sharing a secret. Payment cards and mobile payment systems use keys held in secure elements to authenticate transactions, and payment APIs rely on TLS. In digital identity, passkeys based on the FIDO2 and WebAuthn standards use challenge–response signatures: the device signs a server's challenge with a private key that never leaves it, and the server stores only the matching public key, so a server breach does not expose reusable credentials.\n\nCryptocurrency wallets make the key relationship explicit. Ownership of funds is tied to a private key, and a transaction is valid when signed by it. Anyone who holds the key can spend the funds, and a lost key generally cannot be recovered. Many wallets derive keys from a human-readable seed phrase, which then becomes the single point of failure. Custodial exchanges reverse this arrangement by holding keys on users' behalf, which trades self-custody risk for reliance on the custodian."
    },
    {
      "heading": "Law, policy, and the debate over lawful access",
      "text": "For most of history, governments treated cryptography as an instrument of state power, and its export and use were tightly controlled. In the United States, strong encryption was for decades regulated as a munition under export law. The 1990s \"Crypto Wars\" moved this dispute into public view. Developers argued that licensing rules restricted both commercial security products and published research. In 1999, a federal appeals court accepted that source code could receive First Amendment protection, and the government subsequently relaxed its rules. In 1993, the Clinton administration proposed the Clipper chip, a telephone encryption device built around the classified Skipjack algorithm. Under the key escrow design, a copy of each device's key would be held by government-approved agencies so that authorized wiretaps could be decrypted. Critics objected that Skipjack could not be independently reviewed and that the escrowed keys would become a prime target. Within a few years, a flaw in the escrow protocol had been demonstrated publicly, and the proposal was effectively abandoned by the late 1990s.\n\nThe current debate follows the same basic structure. Law enforcement agencies argue that end-to-end encryption, which they sometimes call \"warrant-proof\", prevents them from obtaining data even when a court has authorized access. Telecommunications law offers a precedent for the opposite approach: the 1994 Communications Assistance for Law Enforcement Act requires carriers to build interception capabilities into their networks. Technologists respond that the same logic does not transfer to encryption. A mechanism designed for one authority, whether an escrow key, a master decryption capability, or a client-side scanning system, creates a single point of failure that foreign governments, criminals, and insiders can also attempt to exploit. The 2016 dispute between Apple and the FBI over a locked iPhone from the San Bernardino case illustrated this tension, and the government ultimately gained access to that device through a third party rather than through a court-ordered change to Apple's software. Many security researchers have made the same argument in more general terms: once a decryption capability exists, its security depends on every person who can reach it.\n\nRecent proposals reflect these long-running tensions. In the United Kingdom, the Investigatory Powers Act 2016 allows authorities to require technical capabilities from providers, and Apple has responded by withdrawing its end-to-end encrypted iCloud Advanced Data Protection feature in the UK. The European Commission's ProtectEU strategy calls for a technology roadmap to explore ways of unlocking encrypted data, and the EU's proposed regulation known as \"Chat Control\" has repeatedly been contested in the Council and Parliament. In Canada, Bill C-22, introduced in March 2026, has drawn sharp opposition. Its government sponsors argue that it does not require decryption of end-to-end encrypted content or permit systemic vulnerabilities, while industry groups contend that it would force firms to weaken encryption or build intercept capabilities, and the messaging app Signal has said it will leave the country regardless of recent amendments. In the United States, legislative proposals framed largely around child sexual abuse material had not been enacted as of 2026.\n\nEncryption also has a substantial place in data-protection law. The EU General Data Protection Regulation lists encryption among the appropriate technical measures for securing personal data, and it exempts controllers from notifying individuals of a breach when the affected data is rendered unintelligible by encryption. Privacy and freedom of expression are closely linked in this context: UN human rights bodies have described strong encryption and anonymity as enabling conditions for the exercise of these rights, especially for journalists, activists, and dissidents. Other states take the opposite approach. China's Cryptography Law of 2019 places commercial cryptographic products under state rules and certification requirements, and Russia's 2016 surveillance legislation obliged messaging services to provide the authorities with the means to decrypt traffic.\n\nThese national differences sit within an international framework that is not uniform in its application. The Universal Declaration of Human Rights protects privacy and freedom of opinion and expression, and the International Covenant on Civil and Political Rights makes these rights subject to restrictions that must be lawful and necessary. Human rights bodies generally assess surveillance measures against the principles of legality, necessity, and proportionality, and they disagree about whether mandated weakening of encryption can ever satisfy those tests. Consequently, the same technical design may be treated as a legitimate investigative tool in one jurisdiction and as an unacceptable intrusion in another, which makes the legal status of encryption a question of both security engineering and state policy."
    },
    {
      "heading": "Open problems and future directions",
      "text": "Security proofs that rest on assumptions not yet well understood\n\nMany deployed schemes are trusted because no efficient attack is known, not because their security has been reduced to a well-studied problem. Some proofs are carried out in idealized models, such as the random oracle or ideal cipher model, so they guarantee security only if the idealized component behaves as assumed. Newer assumptions, including those behind lattice-based schemes, have received far less cryptanalytic scrutiny than factoring or discrete logarithms, which makes it harder to predict how long they will hold. A central open task is therefore to find proofs that are both tight and based on assumptions the research community can test against many years of attack.\n\nFormal verification of implementations and protocols\n\nA proof about an algorithm does not automatically cover the code that runs it. Projects such as HACL* have built a C library in the F* language in which each primitive is verified for memory safety, functional correctness, and secret independence, and this library has been used as a cryptographic provider for the miTLS verified TLS implementation. The approach has clear limits, however. Verifying an implementation says nothing by itself about the cryptographic security of the construction it implements, so that must be proven separately. Coverage is also uneven: the miTLS handshake proof was left incomplete in the Everest project, and the 2017 HACL* paper noted that RSA and ECDSA signatures, which X.509 certificates require, were not yet implemented. Verified compilers add their own gap, since the cost of compiling verified code has not always been analyzed and side-channel leakage may fall outside what the verification guarantees.\n\nQuantum key distribution versus post-quantum cryptography\n\nPost-quantum cryptography (PQC) rests on computational hardness assumptions, so it is not unconditionally secure, and future algorithmic advances could weaken it. Quantum key distribution (QKD) is often presented as an alternative whose security rests on physical principles rather than on computational assumptions. Recent analyses, however, stress its practical limits: it is point-to-point and limited in distance until quantum repeaters are mature, it needs specialized optical hardware at each endpoint, and its solutions have not gone through a formal standardization process. Views on the right role for QKD differ. Some sources treat the two approaches as complementary, while others argue that PQC should be the default migration path and that QKD suits only selected, fixed, high-value links. Open questions include whether QKD networks can scale and how to integrate them with classical authentication, which QKD alone does not provide.\n\nEfficiency of homomorphic computation\n\nFully homomorphic encryption (FHE) allows computation on ciphertexts, but its overhead remains large. Its basic bootstrapping operation, which refreshes ciphertexts so that unlimited computation is possible, is expensive, and reported slowdowns depend heavily on the scheme, parameters, and hardware. One 2026 benchmark puts unoptimized CPU-only FHE at roughly 10,000 times slower than plaintext computation, narrowing to roughly 10 to 100 times for throughput-oriented workloads once batching, optimized CKKS parameters, and GPU acceleration are used. Other analysts argue that no universal multiplier is meaningful and that each workload should be benchmarked end to end. Research therefore concentrates on hardware acceleration, better compilers, and reducing bootstrapping frequency, while deployments so far are concentrated in narrow areas such as private lookups and small-model inference.\n\nUsability of key management\n\nEven when the mathematics is sound, many failures arise from how people generate, store, share, back up, and rotate keys. Lost keys make data unrecoverable, while convenient recovery mechanisms create new points of attack, so secrecy and availability pull in opposite directions. Systems that rely on users to manage keys correctly have repeatedly failed, and the historical record of operational errors in wartime machines points the same way. Designing key management that ordinary users can operate safely, without weakening the guarantees that the cryptography provides, remains one of the field's most practical unsolved problems."
    }
  ],
  "links": [
    "cryptography",
    "mathematics",
    "computer-science",
    "computational-complexity",
    "claude-shannon",
    "exclusive-or",
    "modular-arithmetic",
    "prime-number",
    "randomization",
    "entropy",
    "quantum-computer",
    "algorithm"
  ],
  "sources": [
    {
      "title": "History of cryptography",
      "url": "https://en.wikipedia.org/wiki/History_of_cryptography"
    },
    {
      "title": "Caesar Cipher Decoder, Encoder & Translator",
      "url": "https://inventivehq.com/tools/security/caesar-cipher"
    },
    {
      "title": "Caesar Cipher — The Cipher Museum",
      "url": "https://ciphermuseum.com/ciphers/caesar.html"
    },
    {
      "title": "Vigen%C3%A8re cipher",
      "url": "https://en.wikipedia.org/wiki/Vigen%C3%A8re_cipher"
    },
    {
      "title": "Vigenère cipher",
      "url": "https://cryptography.fandom.com/wiki/Vigen%C3%A8re_cipher"
    },
    {
      "title": "Blaise de Vigenère Describes What is Later Known as the ...",
      "url": "https://www.historyofinformation.com/detail.php?id=1678"
    },
    {
      "title": "Vigenère Cipher — The Cipher Museum",
      "url": "https://ciphermuseum.com/ciphers/vigenere.html"
    },
    {
      "title": "(PDF) The rise of cryptology in the European Renaissance",
      "url": "https://www.researchgate.net/publication/279608179_The_rise_of_cryptology_in_the_European_Renaissance"
    },
    {
      "title": "Arabic Origins of Cryptology (The discovery of Ancient Manuscripts)",
      "url": "https://muslimheritage.com/wp-content/uploads/2018/05/cryptology01.pdf"
    },
    {
      "title": "The History of Cryptography - Compact Histories",
      "url": "https://compacthistories.com/history/the-history-of-cryptography/"
    },
    {
      "title": "The Evolution of Cryptography",
      "url": "https://chain.com/blog/the-evolution-of-cryptography"
    },
    {
      "title": "Cryptanalysis of the Enigma",
      "url": "https://military-history.fandom.com/wiki/Cryptanalysis_of_the_Enigma"
    },
    {
      "title": "The Enigma of Alan Turing - CIA",
      "url": "https://www.cia.gov/stories/story/the-enigma-of-alan-turing/"
    },
    {
      "title": "Bletchley Park, Where the Allies Broke Enigma and Other Ciphers",
      "url": "https://cromwell-intl.com/travel/uk/bletchley-park/"
    },
    {
      "title": "Polish mathematicians and cracking the Enigma",
      "url": "https://www.bl.uk/stories/blogs/posts/polish-mathematicians-and-cracking-the-enigma"
    },
    {
      "title": "Cyclometer",
      "url": "https://en.wikipedia.org/wiki/Cyclometer"
    },
    {
      "title": "Milestones:Code-breaking at Bletchley Park during World War II, 1939-1945 - Engineering and Technology History Wiki",
      "url": "https://ethw.org/Milestones:Code-breaking_at_Bletchley_Park_during_World_War_II,_1939-1945"
    },
    {
      "title": "Polish mathematicians were the first to decipher the German Enigma Machine - Katrina Shawver",
      "url": "https://katrinashawver.com/polish-mathematicians-german-enigma-machine/"
    },
    {
      "title": "Data Encryption Standard",
      "url": "https://en.wikipedia.org/wiki/Data_Encryption_Standard"
    },
    {
      "title": "Data Encryption Standard",
      "url": "https://dlab.epfl.ch/wikispeedia/wpcd/wp/d/Data_Encryption_Standard.htm"
    },
    {
      "title": "The Cornerstone of Cybersecurity",
      "url": "https://www.nccoe.nist.gov/news-insights/cornerstone-cybersecurity-cryptographic-standards-and-50-year-evolution"
    },
    {
      "title": "Data Encryption Standard (Cryptography) - Overview",
      "url": "https://studyguides.com/study-methods/overview/cmj6ypt7q785l01aagd4k1gx1"
    },
    {
      "title": "Exploring the Data Encryption Standard - Kobalt.io",
      "url": "https://kobalt.io/exploring-the-data-encryption-standard/"
    },
    {
      "title": "Appendix A. Encryption Standards",
      "url": "https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/security_guide/chap-encryption_standards"
    },
    {
      "title": "What Was the DES Encryption Standard?",
      "url": "https://www.upistudy.com/blog/ethics-in-technology/what-was-the-des-encryption-standard-and-why-did-it-matter"
    },
    {
      "title": "Advanced Encryption Standard",
      "url": "https://en.wikipedia.org/wiki/Advanced_Encryption_Standard"
    },
    {
      "title": "FIPS 197, Advanced Encryption Standard (AES)",
      "url": "https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.197.pdf"
    },
    {
      "title": "Federal Information Processing Standards Publication 197 November 26, 2001",
      "url": "https://www.space.commerce.gov/wp-content/uploads/AES-fips-197.pdf"
    },
    {
      "title": "HHEML: Hybrid Homomorphic Encryption for Privacy-Preserving Machine Learning on Edge",
      "url": "https://arxiv.org/pdf/2510.20243"
    },
    {
      "title": "AES Implementation and Performance Evaluation on 8-bit Microcontrollers",
      "url": "https://arxiv.org/pdf/0911.0482"
    },
    {
      "title": "Provable Security of Substitution-Permutation Networks",
      "url": "https://www.cs.umd.edu/~jkatz/papers/SPNs.pdf"
    },
    {
      "title": "Feistel cipher",
      "url": "https://en.wikipedia.org/wiki/Feistel_cipher"
    },
    {
      "title": "Block Cipher Lec(3) (1 - 8) Feistel Mode",
      "url": "https://uomosul.edu.iq/computerscience/wp-content/uploads/sites/13/2025/05/BC_03-Ahmed-Sami.pdf"
    },
    {
      "title": "Lucifer (cipher)",
      "url": "https://en.wikipedia.org/wiki/Lucifer_(cipher)"
    },
    {
      "title": "Substitution-Permutation Network - an overview",
      "url": "https://www.sciencedirect.com/topics/computer-science/substitution-permutation-network"
    },
    {
      "title": "Block cipher mode of operation",
      "url": "https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation"
    },
    {
      "title": "Block Cipher modes of Operation - GeeksforGeeks",
      "url": "https://www.geeksforgeeks.org/ethical-hacking/block-cipher-modes-of-operation/"
    },
    {
      "title": "Multi-block cryptographic operation",
      "url": "https://image-ppubs.uspto.gov/dirsearch-public/print/downloadPdf/9515818"
    },
    {
      "title": "Block cipher vs stream cipher: differences - Upclass.ai",
      "url": "https://upclass.ai/blog/block-cipher-vs-stream-cipher/"
    },
    {
      "title": "Stream cipher attacks",
      "url": "https://en.wikipedia.org/wiki/Stream_cipher_attacks"
    },
    {
      "title": "Quantum Cryptography",
      "url": "https://arxiv.org/pdf/quant-ph/0601207"
    },
    {
      "title": "RSA cryptosystem",
      "url": "https://en.wikipedia.org/wiki/RSA_cryptosystem"
    },
    {
      "title": "RSA Encryption: How the RSA Algorithm Works and Why It Matters",
      "url": "https://securew2.com/blog/what-is-rsa-asymmetric-encryption"
    },
    {
      "title": "ECC vs RSA vs DSA - Encryption Differences",
      "url": "https://www.sectigo.com/blog/rsa-vs-dsa-vs-ecc-encryption"
    },
    {
      "title": "ECC vs RSA Comparison: What's the Technical Difference?",
      "url": "https://sslinsights.com/ecc-vs-rsa/"
    },
    {
      "title": "Marshall Hall's Conjecture and Gaps Between Integer Points on Mordell Elliptic Curves",
      "url": "https://arxiv.org/pdf/1410.0078"
    },
    {
      "title": "Finite-field division operator, elliptic curve cryptosystem having finite-field division operator and method for operating elliptic curve cryptosystem",
      "url": "https://image-ppubs.uspto.gov/dirsearch-public/print/downloadPdf/11431499"
    },
    {
      "title": "Hardware accelerator for elliptic curve cryptography",
      "url": "https://image-ppubs.uspto.gov/dirsearch-public/print/downloadPdf/7508936"
    },
    {
      "title": "What Is Hybrid Cryptography? [The Practical Path to PQC] - Security Boulevard",
      "url": "https://securityboulevard.com/2026/05/what-is-hybrid-cryptography-the-practical-path-to-pqc/"
    },
    {
      "title": "Hybrid cryptosystem",
      "url": "https://en.wikipedia.org/wiki/Hybrid_cryptosystem"
    },
    {
      "title": "What Is a Hybrid Cryptosystem?",
      "url": "https://www.ituonline.com/tech-definitions/what-is-a-hybrid-cryptosystem/"
    },
    {
      "title": "Hybrid Encryption",
      "url": "https://developers.google.com/tink/hybrid"
    },
    {
      "title": "Elliptic Curve Cryptography",
      "url": "https://help.ivanti.com/ps/help/en_US/ICS/21.9R1/ag/elliptic_curve_cryptography.htm"
    },
    {
      "title": "Generic implementations of elliptic curve cryptography using partial reduction",
      "url": "https://image-ppubs.uspto.gov/dirsearch-public/print/downloadPdf/7930335"
    },
    {
      "title": "Secret Private Key - an overview",
      "url": "https://www.sciencedirect.com/topics/computer-science/secret-private-key"
    },
    {
      "title": "Diffie%E2%80%93Hellman key exchange",
      "url": "https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange"
    },
    {
      "title": "Diffie–Hellman key exchange",
      "url": "https://cryptography.fandom.com/wiki/Diffie%E2%80%93Hellman_key_exchange"
    },
    {
      "title": "Extended Key Update for Transport Layer Security (TLS) 1.3",
      "url": "https://www.ietf.org/archive/id/draft-ietf-tls-extended-key-update-04.html"
    },
    {
      "title": "TLS 1.3 and Forward Secrecy: Count Us In, and Here's Why - Cisco Blogs",
      "url": "https://blogs.cisco.com/security/tls-1-3-and-forward-secrecy-count-us-in-and-heres-why"
    },
    {
      "title": "TLS (Transport Layer Security) Explained: Why TLS 1.3 is the New Standard",
      "url": "https://securew2.com/blog/tls-explained"
    },
    {
      "title": "What is Public Key Infrastructure (PKI)?",
      "url": "https://www.ibm.com/think/topics/public-key-infrastructure"
    },
    {
      "title": "Public Key Infrastructure (PKI): What It Is and How It Works",
      "url": "https://www.entrust.com/resources/learn/what-is-pki"
    },
    {
      "title": "Cryptographic method and system",
      "url": "https://image-ppubs.uspto.gov/dirsearch-public/print/downloadPdf/8842841"
    },
    {
      "title": "Web of trust",
      "url": "https://en.wikipedia.org/wiki/Web_of_trust"
    },
    {
      "title": "comptia Security+ : Implementing Public Key Infrastructure",
      "url": "https://www.examguides.com/security+/security+33.htm"
    },
    {
      "title": "Extended Key Update for Transport Layer Security (TLS) 1.3",
      "url": "https://datatracker.ietf.org/doc/html/draft-ietf-tls-extended-key-update-10"
    },
    {
      "title": "TLS 1.3: Busting myths and dispelling fear-uncertainty-doubt",
      "url": "https://www.zscaler.com/blogs/product-insights/tls-13-busting-myths-and-debunking-fear-uncertainty-doubt"
    },
    {
      "title": "What is PKI? Public Key Infrastructure Explained",
      "url": "https://rublon.com/blog/public-key-infrastructure/"
    },
    {
      "title": "Ciphertext indistinguishability",
      "url": "https://en.wikipedia.org/wiki/Ciphertext_indistinguishability"
    },
    {
      "title": "Ciphertext indistinguishability",
      "url": "https://cryptography.fandom.com/wiki/Ciphertext_indistinguishability"
    },
    {
      "title": "A Comprehensive Framework for Building Highly Secure, Network-Connected Devices: Chip to App",
      "url": "https://arxiv.org/pdf/2501.13716"
    },
    {
      "title": "Security Protocols in a Nutshell",
      "url": "https://arxiv.org/pdf/1605.09771"
    },
    {
      "title": "Random Oracle Reducibility Paul Baecher Marc Fischlin",
      "url": "https://www.cryptoplexity.informatik.tu-darmstadt.de/media/crypt/publications_1/BF11.pdf"
    },
    {
      "title": "A tight security reduction in the quantum random oracle model for code-based signature schemes",
      "url": "https://arxiv.org/pdf/1709.06870"
    },
    {
      "title": "Lower Bounds on Signatures from Symmetric Primitives",
      "url": "https://arxiv.org/pdf/0801.3680"
    },
    {
      "title": "Reduction-Centric Non-programmable Security Proof for the Full Domain Hash in the Random Oracle Model",
      "url": "https://link.springer.com/chapter/10.1007/978-3-642-35416-8_10"
    },
    {
      "title": "Encryption Schemes using Random Oracles: from Classical to ...",
      "url": "https://eprint.iacr.org/2020/129.pdf"
    },
    {
      "title": "(PDF) Re-visiting the One-Time Pad",
      "url": "https://www.researchgate.net/publication/220284469_Re-visiting_the_One-Time_Pad"
    },
    {
      "title": "Digital information infrastructure and method for security designated data and with granular data stores",
      "url": "https://image-ppubs.uspto.gov/dirsearch-public/print/downloadPdf/8468244"
    },
    {
      "title": "An (Important) Disproof Of The One-Time Pad",
      "url": "https://techcrunch.com/?p=1196311"
    },
    {
      "title": "Perfect Secrecy - an overview",
      "url": "https://www.sciencedirect.com/topics/computer-science/perfect-secrecy"
    },
    {
      "title": "Quantum readiness: Introduction to Modern Cryptography",
      "url": "https://www.synacktiv.com/en/publications/quantum-readiness-introduction-to-modern-cryptography"
    },
    {
      "title": "Provably Secure Integration Cryptosystem on Non-Commutative Group",
      "url": "https://arxiv.org/pdf/1806.03075"
    },
    {
      "title": "Random Oracles With(out) Programmability⋆",
      "url": "https://www.iacr.org/archive/asiacrypt2010/6477305/6477305.pdf"
    },
    {
      "title": "The random oracle model: a twenty-year retrospective",
      "url": "https://link.springer.com/article/10.1007/s10623-015-0094-2"
    },
    {
      "title": "ChaCha20-Poly1305",
      "url": "https://en.wikipedia.org/wiki/ChaCha20-Poly1305"
    },
    {
      "title": "Partitioning Oracle Attacks",
      "url": "https://eprint.iacr.org/2020/1491.pdf"
    },
    {
      "title": "A Robust Variant of ChaCha20-Poly1305",
      "url": "https://eprint.iacr.org/2025/222.pdf"
    },
    {
      "title": "VPN Encryption Explained: AES-256-GCM, ChaCha20 & AEAD",
      "url": "https://encapsulated.network/vpn-encryption/"
    },
    {
      "title": "Plaintext Attack - an overview",
      "url": "https://www.sciencedirect.com/topics/computer-science/plaintext-attack"
    },
    {
      "title": "Chosen-Ciphertext Attack (CCA)",
      "url": "https://www.linkedin.com/pulse/20141201173411-1571978-chosen-ciphertext-attack-cca"
    },
    {
      "title": "graphsearch.epfl.ch",
      "url": "https://graphsearch.epfl.ch/en/publication/183360/concepts"
    },
    {
      "title": "Security of Networks 2011- 2012 Dr. S.B. Sadkhan Page 1 (9)",
      "url": "https://www.uobabylon.edu.iq/eprints/paper_5_7264_649.pdf"
    },
    {
      "title": "graphsearch.epfl.ch",
      "url": "https://graphsearch.epfl.ch/en/publication/270353/concepts"
    },
    {
      "title": "Differential Cryptanalysis - an overview",
      "url": "https://www.sciencedirect.com/topics/computer-science/differential-cryptanalysis"
    },
    {
      "title": "An Expanded Set of S-box Design Criteria Based on ...",
      "url": "https://link.springer.com/content/pdf/10.1007/3-540-46416-6_30.pdf"
    },
    {
      "title": "S-box",
      "url": "https://en.wikipedia.org/wiki/S-box"
    },
    {
      "title": "Differential Cryptanalysis: A Literature Survey",
      "url": "http://www.ciphersbyritter.com/RES/DIFFANA.HTM"
    },
    {
      "title": "Linear Cryptanalysis for Block Ciphers",
      "url": "https://link.springer.com/rwe/10.1007/0-387-23483-7_233"
    },
    {
      "title": "(PDF) Linear Cryptanalysis of DES",
      "url": "https://www.researchgate.net/publication/37442994_Linear_Cryptanalysis_of_DES"
    },
    {
      "title": "(PDF) Linear cryptanalysis method for DES cipher (1994)",
      "url": "https://scispace.com/papers/linear-cryptanalysis-method-for-des-cipher-1r1986c2ma"
    },
    {
      "title": "On Matsui's linear cryptanalysis",
      "url": "https://link.springer.com/chapter/10.1007/BFb0053449"
    },
    {
      "title": "Fast S-box security mechanism research based on the polymorphic cipher - ScienceDirect",
      "url": "https://www.sciencedirect.com/science/article/abs/pii/S0020025507005270"
    },
    {
      "title": "Iterative symmetric key ciphers with keyed S-boxes using modular exponentiation",
      "url": "https://image-ppubs.uspto.gov/dirsearch-public/print/downloadPdf/8130946"
    },
    {
      "title": "Linear Cryptanalysis Method for DES Cipher Mitsuru Matsui",
      "url": "https://link.springer.com/content/pdf/10.1007/3-540-48285-7_33.pdf"
    },
    {
      "title": "Enhancement of Secrecy of Block Ciphered Systems by Deliberate Noise",
      "url": "https://arxiv.org/pdf/1204.0153"
    },
    {
      "title": "GitHub - lorenzopalloni/timing-attacks: Implementation of two timing attacks against RSA: one published by Kocher (1996), and another one by Brumley and Boneh (2005). · GitHub",
      "url": "https://github.com/lorenzopalloni/timing-attacks"
    },
    {
      "title": "Strength of Two Data Encryption Standard Implementations Under Timing Attacks",
      "url": "https://dl.acm.org/doi/pdf/10.1145/330382.330390"
    },
    {
      "title": "Exclusive Exponent Blinding May Not Suffice to Prevent Timing Attacks on RSA",
      "url": "https://link.springer.com/chapter/10.1007/978-3-662-48324-4_12"
    },
    {
      "title": "(PDF) Examining Smartcard Security under the Threat of Power Analysis Attacks",
      "url": "https://www.researchgate.net/publication/3044470_Examining_Smartcard_Security_under_the_Threat_of_Power_Analysis_Attacks"
    },
    {
      "title": "Protecting smart cards from power analysis with detachable power supplies",
      "url": "https://image-ppubs.uspto.gov/dirsearch-public/print/downloadPdf/6507913"
    },
    {
      "title": "Physical Time-Varying Transfer Functions as Generic Low-Overhead Power-SCA Countermeasure",
      "url": "https://arxiv.org/pdf/2003.07440"
    },
    {
      "title": "A Formal Proof of Countermeasures against Fault Injection Attacks on CRT-RSA",
      "url": "https://arxiv.org/pdf/1401.8170"
    },
    {
      "title": "OpenSSL Bellcore's Protection Helps Fault Attack",
      "url": "https://ieeexplore.ieee.org/document/8491860/"
    },
    {
      "title": "Timing Attacks on Software Implementation of RSA Project Report Harshman Singh",
      "url": "https://ir.library.oregonstate.edu/downloads/fn106z04s"
    },
    {
      "title": "Examining Smart-Card Security under the Threat of Power Analysis Attacks",
      "url": "https://dl.acm.org/doi/10.1109/tc.2002.1004593"
    },
    {
      "title": "Algorithmic Countermeasures Against Fault Attacks and ...",
      "url": "https://eprint.iacr.org/2016/238.pdf"
    },
    {
      "title": "JackHammer: Efficient Rowhammer on Heterogeneous FPGA-CPU Platforms",
      "url": "https://arxiv.org/pdf/1912.11523"
    },
    {
      "title": "Federal Information Processing Standard (FIPS) 197, Advanced Encryption Standard (AES)",
      "url": "https://csrc.nist.gov/pubs/fips/197/final"
    },
    {
      "title": "Commerce Secretary Announces New Standard for Global Information Security",
      "url": "https://www.nist.gov/news-events/news/2001/12/commerce-secretary-announces-new-standard-global-information-security"
    },
    {
      "title": "Milestones:Rijndael and the Advanced Encryption Standard (AES), 1995 - 1998 - Engineering and Technology History Wiki",
      "url": "https://ethw.org/Milestones:Rijndael_and_the_Advanced_Encryption_Standard_(AES),_1995_-_1998"
    },
    {
      "title": "Advanced Encryption Standard (AES) Development Effort",
      "url": "https://csrc.nist.rip/archive/aes/index2.html"
    },
    {
      "title": "Official websites use .gov",
      "url": "https://csrc.nist.gov/projects/cryptographic-standards-and-guidelines/archived-crypto-projects/aes-development"
    },
    {
      "title": "graphsearch.epfl.ch",
      "url": "https://graphsearch.epfl.ch/concept/1260"
    },
    {
      "title": "DES Challenges",
      "url": "https://en.wikipedia.org/wiki/DES_Challenges"
    },
    {
      "title": "EFF DES cracker",
      "url": "https://en.wikipedia.org/wiki/EFF_DES_cracker"
    },
    {
      "title": "DES CRACKED IN 22 HOURS AND FIFTEEN MINUTES - Tech Monitor",
      "url": "https://www.techmonitor.ai/technology/des_cracked_in_22_hours_and_fifteen_minutes"
    },
    {
      "title": "56-bit crypto code cracked in a day • The Register",
      "url": "https://www.theregister.com/1999/01/20/56bit_crypto_code_cracked/"
    },
    {
      "title": "Story: EFF Cracks 56-Bit DES in Three Days, 7/20/98.",
      "url": "http://techlawjournal.com/encrypt/80720eff.htm"
    },
    {
      "title": "56-bit encryption",
      "url": "https://en.wikipedia.org/wiki/56-bit_encryption"
    },
    {
      "title": "Symmetric Algorithm Survey: A Comparative Analysis",
      "url": "https://arxiv.org/pdf/1405.0398"
    },
    {
      "title": "NIST SP 800-90 Historical Information - Random Bit Generation",
      "url": "https://csrc.nist.gov/projects/random-bit-generation/rbg-archive/nist-sp-800-90-historical-information"
    },
    {
      "title": "NIST Removes Cryptography Algorithm from Random Number Generator Recommendations",
      "url": "https://www.nist.gov/news-events/news/2014/04/nist-removes-cryptography-algorithm-random-number-generator-recommendations"
    },
    {
      "title": "Dual EC DRBG: How a Standard Got a Backdoor",
      "url": "https://quantumsequrity.com/blog/dual-ec-drbg-backdoor"
    },
    {
      "title": "NIST Post-Quantum Cryptography Standards: Complete Guide to FIPS 203, 204, 205",
      "url": "https://qramm.org/learn/nist-pqc-standards.html"
    },
    {
      "title": "Which NIST Post-Quantum Cryptography Standards Are Final",
      "url": "https://securecontrolsframework.com/faqs/what-nist-pqc-standards-have-been-finalized"
    },
    {
      "title": "Tracking the progress toward post-quantum cryptography",
      "url": "https://www.digicert.com/blog/the-progress-toward-post-quantum-cryptography"
    },
    {
      "title": "Study of Post Quantum status of Widely Used Protocols",
      "url": "https://arxiv.org/pdf/2603.28728"
    },
    {
      "title": "A Non-Invasive Cloud-Based Migration Strategy for Post-Quantum Cybersecurity in Smart HVAC Systems: Architecture, Implementation, and Empirical Evaluation",
      "url": "https://arxiv.org/pdf/2609.27828"
    },
    {
      "title": "Post-Quantum Cryptography Migration in Australian Real-Time Payment Infrastructure: A Monte Carlo Simulation Study of the New Payments Platform",
      "url": "https://arxiv.org/pdf/2605.02276"
    },
    {
      "title": "HQC: NIST's Backup to ML-KEM Explained",
      "url": "https://www.encryptionconsulting.com/hqc-nist-backup-ml-kem-explained/"
    },
    {
      "title": "NIST Selects HQC as Fifth Algorithm for Post-Quantum Encryption: What It Means For You",
      "url": "https://www.encryptionconsulting.com/nist-selects-hqc-as-fifth-algorithm-for-post-quantum-encryption/"
    },
    {
      "title": "Decoding NIST PQC Standards: What They Are, What’s Final, and What’s Next",
      "url": "https://www.encryptionconsulting.com/decoding-nist-pqc-standards/"
    },
    {
      "title": "Aquaman: A Transparent Proxy Architecture for Quantum Resilient Key Establishment",
      "url": "https://arxiv.org/pdf/2605.06932"
    },
    {
      "title": "A Survey on Quantum-Safe Cryptographic Mechanisms: Building Blocks and Applications",
      "url": "https://arxiv.org/pdf/2609.11991"
    },
    {
      "title": "NIST PQC Standards Guide: FIPS 203, 204, 205",
      "url": "https://www.arcqubit.ai/blog/nist-pqc-standards-guide"
    },
    {
      "title": "NIST IR 8547 and SP 800-131A Timeline",
      "url": "https://www.encryptionconsulting.com/education-center/nist-ir-8547-sp-800-131a-algorithm-transitions/"
    },
    {
      "title": "Post-quantum cryptography migration is already behind schedule",
      "url": "https://tech.yahoo.com/cybersecurity/articles/post-quantum-cryptography-migration-already-153928703.html"
    },
    {
      "title": "NIST IR 8547 Explained: 2030 and 2035 PQC Deadlines",
      "url": "https://www.encryptionconsulting.com/nist-ir-8547-2030-2035-action-plan/"
    },
    {
      "title": "Hybrid Horizons: Policy for Post-Quantum Security",
      "url": "https://arxiv.org/pdf/2510.02317"
    },
    {
      "title": "An Assessment Framework for Application-Level Cryptographic Agility",
      "url": "https://arxiv.org/pdf/2606.13425"
    },
    {
      "title": "Post-Quantum Cryptography Standards and Audit Index: algorithms, dates, standards bodies, auditors",
      "url": "https://pqaudit.org/"
    },
    {
      "title": "NIST IR 8547: Transition to Post-Quantum Cryptography Standards",
      "url": "https://pqcmandates.com/mandate/nist-ir-8547"
    },
    {
      "title": "NIST IR 8547: the post-quantum transition timeline",
      "url": "https://quantakrypto.com/standards/nist-pqc-migration-timeline-ir-8547"
    },
    {
      "title": "2026 State of PQC on the Web",
      "url": "https://www.f5.com/labs/articles/2026-state-of-pqc-on-the-web"
    },
    {
      "title": "TLS 1.3 Adoption in 2026: Stats, Benefits & Migration",
      "url": "https://sslinsights.com/tls-1-3-adoption/"
    },
    {
      "title": "Technologychecker",
      "url": "https://technologychecker.io/blog/https-adoption"
    },
    {
      "title": "We analyzed HTTP protocol adoption in 2026: 28.6% of the ...",
      "url": "https://technologychecker.io/blog/http-protocol-adoption"
    },
    {
      "title": "SSL vs TLS: TLS 1.3 Hits 72% Share, SSL at 0% [2026]",
      "url": "https://shattered.io/ssl-vs-tls-2026/"
    },
    {
      "title": "SoK: Web Authentication in the Age of End-to-End Encryption",
      "url": "https://arxiv.org/pdf/2406.18226"
    },
    {
      "title": "DKVE: Decentralized Key Validation for End-to-End Encrypted Messaging",
      "url": "https://arxiv.org/pdf/2606.26486"
    },
    {
      "title": "End-to-end encryption",
      "url": "https://en.wikipedia.org/wiki/End-to-end_encryption"
    },
    {
      "title": "Signal vs WhatsApp: What End-to-End Encryption Actually Protects (And What It Doesn't) - DEV Community",
      "url": "https://dev.to/tiamatenity/signal-vs-whatsapp-what-end-to-end-encryption-actually-protects-and-what-it-doesnt-20f4"
    },
    {
      "title": "WhatsApp vs Signal: Key Privacy Insights for Businesses",
      "url": "https://www.leapxpert.com/whatsapp-vs-signal-privacy-features-compared/"
    },
    {
      "title": "End-To-End Encryption In Whatsapp/Signal/iMessage : What Is Not Protected? - Newsoftwares.net Blog",
      "url": "https://www.newsoftwares.net/blog/end-to-end-encryption-whatsapp-signal-imessage-not-protected/"
    },
    {
      "title": "Law Enforcement and Technology: The “Lawful Access” Debate",
      "url": "https://www.congress.gov/crs-product/IF11769"
    },
    {
      "title": "Encryption and Globalization 15 Years Later: End-to-End Encryption and the Third Round of the \"Going Dark\" Debate",
      "url": "https://isoclive.substack.com/p/encryption-and-globalization"
    },
    {
      "title": "EU Pushes for Backdoors in End-to-End Encryption",
      "url": "https://www.bankinfosecurity.com/eu-pushes-for-backdoors-in-end-to-end-encryption-a-27920"
    },
    {
      "title": "From 'encryption backdoor' to 'lawful access' — is a compromise between privacy, security, and law enforcement needs actually possible?",
      "url": "https://www.techradar.com/vpn/vpn-privacy-security/from-encryption-backdoor-to-lawful-access-is-a-compromise-between-privacy-security-and-law-enforcement-needs-actually-possible"
    },
    {
      "title": "Governments Are Trying to Break Encryption in 2026 — Here's What Developers Must Do",
      "url": "https://abhs.in/blog/governments-vs-encryption-2026-what-developers-need-to-know"
    },
    {
      "title": "Toronto-based VPN provider plans to quit Canada over lawful-access bill - The Globe and Mail",
      "url": "https://theglobeandmail.com/politics/article-psiphon-vpn-provider-plans-to-quit-canada-over-lawful-access-bill"
    },
    {
      "title": "Signal tells Ottawa it will leave Canada rather than comply with Liberal lawful access bill - Rebel News",
      "url": "https://rebelnews.com/ezra_levant_show_october_7_2026"
    },
    {
      "title": "Messaging service Signal says minister’s changes to lawful access bill will not persuade it to stay in Canada - The Globe and Mail",
      "url": "https://theglobeandmail.com/politics/article-messaging-service-signal-says-ministers-changes-to-lawful-access-bill"
    },
    {
      "title": "Comparison of Post-Quantum Cryptography and Quantum Key Distribution",
      "url": "https://staff.science.uva.nl/c.schaffner/projects/reports/Emiel_Wiedijk_BScThesis.pdf"
    },
    {
      "title": "A critical analysis of deployed use cases for quantum key distribution and comparison with post-quantum cryptography",
      "url": "https://www.ncbi.nlm.nih.gov/pmc/articles/PMC12055627/"
    },
    {
      "title": "Quantum Key Distribution vs. Post Quantum Cryptography",
      "url": "https://www.qnulabs.com/blog/quantum-key-distribution-vs-post-quantum-cryptography"
    },
    {
      "title": "Quantum Key Distribution Meets Post-Quantum Cryptography: QKD vs PQC",
      "url": "https://www.itechguides.com/quantum-key-distribution-meets-post-quantum-cryptography-which-one-should-you-use/"
    },
    {
      "title": "Quantum Key Distribution VS Post Quantum Cryptography",
      "url": "https://utimaco.com/news/blog-posts/quantum-key-distribution-vs-post-quantum-cryptography"
    },
    {
      "title": "Project Everest",
      "url": "https://project-everest.github.io/"
    },
    {
      "title": "HACL*: A Verified Modern Cryptographic Library",
      "url": "https://eprint.iacr.org/2017/536"
    },
    {
      "title": "HACL∗: A Verified Modern Cryptographic Library Jean Karim Zinzindohoué INRIA",
      "url": "https://www.wireguard.com/papers/zinzindohoue-bhargavan-protzenko-beurdouche-hacl-2017.pdf"
    },
    {
      "title": "The Last Mile: High-Assurance and High-Speed Cryptographic Implementations",
      "url": "https://arxiv.org/pdf/1904.04606"
    },
    {
      "title": "Is FHE Still Too Slow? Homomorphic Encryption Benchmarks 2026",
      "url": "https://dualitytech.com/blog/homomorphic-encryption-performance-2026/"
    },
    {
      "title": "Fully Homomorphic Encryption in 2026: What Ships and What Is Still Hype",
      "url": "https://wavect.io/blog/fully-homomorphic-encryption-practical-2026/"
    }
  ],
  "license": "https://creativecommons.org/licenses/by/4.0/"
}