Digital signature 2026-10-05
A public-verification message authentication scheme with key generation, signing using a private key, and verification using the corresponding public key. Signing an appropriate digest binds the signature to the message; encryption alone does not provide this authenticity.
Dolev-Yao model 2026-10-31
A symbolic adversarial model of Danny Dolev and Andrew Yao granting control of the network while treating cryptographic operations as ideal constructors and destructors. An adversary may split unprotected tuples, replay messages and encrypt with known public keys, but cannot decrypt without the required key. Separate encrypted components are not automatically bound to adjacent clear fields.
ElGamal signature scheme Created 2026-10-05 Updated 2026-10-31
For a prime number , primitive root and public key , choose a fresh secret coprime to , set and , and verify . Reusing the cryptographic nonce can reveal secret information. The unhashed historical construction allows existential forgery of specially chosen message exponents, so authentication claims require suitable hashing and protocol assumptions.
Information integrity 2026-11-05
Information integrity concerns preserving information against unauthorized alteration or destruction under a stated policy, and detecting violations when they occur. It is distinct from confidentiality: a public record can require strong integrity even though everyone may read it.[ref]
For example, a downloaded scientific dataset can be checked against a trusted checksum to detect accidental corruption. If an attacker can replace both the dataset and its published unprotected hash, that check does not establish authenticity. A message authentication code uses a secret key, while a digital signature permits verification with a public key. These mechanisms protect particular data and contexts; an authorized but mistaken measurement can retain its cryptographic integrity while still being scientifically incorrect.
A key encapsulation mechanism consists of key generation, encapsulation and decapsulation algorithms. Given a public encapsulation key , encapsulation produces : a shared secret and an encapsulation ciphertext . Given the secret key and , decapsulation produces the same , except for any explicitly bounded correctness failure.[ref]
For example, a sender can encapsulate , derive a session encryption key from and agreed context, then use authenticated encryption for a long message. The ciphertext carries the encapsulated secret, while the separate encrypted payload carries the message. Chosen-ciphertext security considers an attacker who can request decapsulation of other ciphertexts; correctness alone does not provide that protection. Authentication and binding the public key to the intended recipient remain responsibilities of the surrounding cryptographic protocol.
Key-only signature attack 2026-10-31
A digital signature attack using the public scheme and verification public key, without supplied signed-message examples or a signing oracle.
ML-DSA 2026-11-05
ML-DSA is the module-lattice digital signature scheme standardized in FIPS204 in2024, derived from CRYSTALS-Dilithium. Key generation creates a public verification key and a secret signing key. Signing combines a sampled masking vector with a message-derived challenge; bounds and rejection sampling prevent unsuitable responses from revealing the secret. Verification reconstructs the commitment information and checks the challenge and response bounds.[ref]
A valid signature authenticates a message under a particular public key; it does not hide the message or independently establish whose public key was supplied. The standardized parameter sets ML-DSA-44,65 and87 have different key/signature sizes and security targets. Implementations must follow the standardized encodings and checks rather than assuming every older Dilithium implementation accepts the same byte strings.
In the Dolev-Yao model, an adversary controls the network: it can intercept, suppress, delay, replay and redirect messages, impersonate network senders, and construct messages from values it knows. In particular, it can concatenate or split unprotected tuples, and can apply encryption using any known public key or known symmetric key.
Cryptography is idealised. Without the required private key or symmetric key, the adversary cannot recover a protected plaintext or construct an otherwise unavailable protected value. It cannot invent an unknown long-term secret merely because the containing ciphertext is visible. Protocol failures arise from the arrangement of messages even when these cryptographic primitives behave perfectly.
A trusted third party is an additional participant whose correct behaviour and protection of its secret state are assumptions on which the other parties rely. Here Alice and Bob rely on Tim to associate identities with the right public keys, generate fresh session keys, and keep the long-term shared secrets confidential.
Tim is allowed to know , so the intended cryptographic confidentiality claim excludes the network adversary, rather than excluding Tim. Correct behaviour by Tim does not make every message purportedly sent by Tim authentic: the recipients must still verify the relevant evidence.
Alice can still authenticate Bob when she accepts a genuine fresh ticket and successfully checks . The session key inside her ticket is Tim's genuine key, protected by her public key together with . Tim gives that same key only to Alice and to the holder of Bob's private key. The adversary cannot derive it, and honest Tim does not send the greeting. Alice has not sent that greeting either. Thus the matching greeting is evidence that Bob obtained the key and participated. The different final greetings prevent simply reflecting Alice's own confirmation back at her.
Bob's intended freshness test is that was hidden in his request encrypted for Tim, so a matching answer must follow Tim's processing of that request. This establishes that Tim revealed that cryptographic nonce; it does not authenticate the adjacent ticket. The substitution attack in solution may use an old adversary-known instead of a fresh one. Bob accepts it even though its freshness is false.
The defect is the absence of a cryptographic binding between Bob's cryptographic nonce and his key ticket. A repair must bind the identities, both cryptographic nonces and the session key under message authentication verifiable as Tim's, for example a digital signature by Tim over the response, checked before Bob accepts. Merely moving the nonce inside a public-key-encrypted ticket is insufficient once an attacker knows or predicts it: anyone can create such an encryption.
Alice's own freshness evidence is the ticket
After decryption, she checks her pending cryptographic nonce, the long-term shared secret and both identities. Only Alice and Tim know ; with honest Tim and an unpredictable new , a valid matching ticket establishes that Tim generated this session key after that challenge was issued. A merely unused but predictable challenge does not establish that temporal ordering.
The claimed authentication of Alice to Bob, however, is false for the printed protocol. To exhibit the failure, let initiate message 1 using Alice's name while Alice is absent. Bob and Tim carry out messages 2 and 3 normally. Write the genuine message 3 as , where and . The adversary intercepts it, learns the unencrypted , and chooses a symmetric key of its own.
The adversary sends Bob
Bob's checks of and the ticket identities pass, because anyone can encrypt using his public key. Bob sends message 4 using ; the adversary suppresses that message and returns as message 5. Bob accepts Alice, although Alice has done nothing. No encryption has been broken.
The tempting intended argument is that only Alice, Bob and Tim could know the transported key, so message 5 proves Alice's participation. The substituted ticket invalidates its premise: Bob's accepted key is , which the adversary knows.
Bob especially needs unpredictability, because is intended to be secret until Tim processes the request. A predictable counter destroys even that limited assurance.
If the adversary knows Bob's next value , it initiates a run with Alice's name and intercepts Bob's request. Without consulting Tim, it chooses a key , constructs , and sends as message 3, with any suitably shaped opaque ticket for Alice. Bob cannot inspect that ticket. He accepts , sends message 4, and accepts the adversary's . Alice and Tim need not participate.
This preplay attack requires a correct prediction of Bob's outstanding value, knowledge of his public key, and the ability to intercept or race the genuine response. Observing an earlier unencrypted response may expose a counter value from which to predict the next. With an independent uniformly random hidden -bit value, blind prediction succeeds with probability per attempt.
In particular, random cryptographic nonces do not make the printed protocol sound. After the genuine message 3 reveals , the adversary can use exactly the substitution in solution. Predictability allows an earlier attack without Tim; lack of response binding allows an attack even with perfect unpredictability.
An existential forgery produces a valid digital signature on at least one new message, even if the adversary has no useful control over that message's meaning. A universal forgery gives a way to forge a digital signature on an arbitrary specified message. Recovering the private key suffices for a universal forgery, but is not required if another general signing method exists.
In a key-only signature attack, the adversary knows the verification public key and the public scheme. In a known-message signature attack, it additionally obtains valid message–digital signature pairs whose messages it did not choose. In a chosen-message signature attack, it can ask for digital signatures on messages it chooses, possibly adaptively. Its final forged message must not be one of the messages already submitted for signing; otherwise simply returning a supplied pair would count as a forgery.
The Internet still reflects the original principles strongly in its common communication substrate, while many applications concentrate decisions and essential services in fewer hands. It is therefore necessary to distinguish the location of machines, the authority to control a service, and the placement of the checks that establish its correctness. A geographically extensive service can remain centrally controlled; a service with independently operated participants still needs to establish its promised result at the relevant endpoints.
The end-to-end principle is a test of function placement. If an application's required property depends on what happens at its endpoints, placing a partial implementation in the intervening network cannot establish the whole property. A receiver can accept bytes and then fail before storing the requested file correctly. The sender therefore needs the appropriate application-layer acknowledgement, rather than treating a transport acknowledgement as proof of durable storage. In this sense, application correctness is not determined by a network trace. Local recovery can still improve performance; it complements the application check rather than replacing it.[ref]
This principle does not imply that routers must be devoid of useful functions, nor that every mechanism belongs at precisely one layer. Its benefit is a clear account of which component supplies a promised result. Internet Protocol offers a common interface across different underlying networks. The IP hourglass permits different applications above that interface and different transmission technologies below it. New application behaviour need not require every intermediate network to be redesigned.[ref]
There is nevertheless a real departure from a simple picture of directly communicating hosts. Middleboxes can inspect, alter or constrain traffic in ways that ordinary packet forwarding does not. A firewall makes a decision about permitted communication; a proxy server can become a separate application participant. Such mechanisms may address legitimate local needs, but an application's assumptions about what the path will carry now require additional justification. A new transport protocol cannot infer successful deployment merely from the existence of compatible host implementations.[ref]
Network address translation gives a concrete state-management example. With network address and port translation, several private hosts can share an externally visible address through mappings in an intermediary. A particular active connection can depend on the continued presence of its mapping, not just on the two host implementations. Loss of that mapping can interrupt the connection even when those hosts remain operational. This qualifies the fate-sharing goal of keeping indispensable communication state with the participants that depend on it. It does not mean every translation failure is permanent or that a service cannot establish a new connection; the interrupted operation and its recovery behaviour must be specified.[ref]
Concentration at the application layer is a separate issue. A content delivery network can place copies close to demand and direct requests to suitable delivery endpoints. This can reduce network latency and avoid repeatedly transferring the same content from its origin. Those are useful engineering results. However, geographical replication does not imply decentralised control: many delivery sites can still answer to one authority or depend on the same origin. Interconnection between delivery networks also requires explicit arrangements for request routing and metadata, rather than arising automatically from their physical distribution.[ref]
Users consequently need to ask which operations remain possible when a provider or shared component is unavailable. Two service replicas might hold the same data in different regions yet both require one identity provider for each new authentication. That provider is then a mandatory service dependency for the new-user operation. More replicas of the data do not remove the dependency. Already admitted users might continue to work under a different design, so the conclusion concerns the declared operation rather than every possible use of the service. This is why failure domains and service availability must be analysed through dependencies as well as geography.
Figure 1.
Two service replicas with one mandatory identity dependency
. Original schematic for an operation that requires a fresh identity check. An arrow points from a replica to a component whose response it requires. Loss of the shared identity provider can block that operation at both replicas even while their data remains intact; the diagram makes no claim about operations that do not require a new authentication response. Details.
The endpoint boundary also determines what a security promise means. Transport Layer Security protects communication to the actual TLS peer. Version 1.3 had been standardised in August 2018, before this sitting. If an authorised CDN edge terminates that connection, it is a participant in the protected communication and can obtain the application plaintext. That can be an intentional delegation, but it cannot simultaneously promise secrecy from that same participant merely because the connection carries an encryption label. A promise of secrecy from the intermediary requires suitable end-to-end encryption with the relevant decryption capability at the intended application endpoints.[ref]
Not every delegated function requires that stronger secrecy promise. A client might instead need to check that an object came from an identified publisher while permitting any suitable cache to deliver it. A digital signature, verified against the intended publisher's authenticated public key, can separate the delivery source from the authority for the content. It does not establish that the publisher's statements are true or make the object reachable. The useful design step is to state the promised property before deciding which component must be trusted to establish it.
For future services, one option is internet service federation: independently operated services exchange requests through compatible communication protocols.[ref] This can permit a choice of provider, but it does not by itself eliminate shared naming dependencies or guarantee that all participants apply compatible policies. Data portability is a distinct requirement: users may need to take their state to another provider. A nominally open protocol is insufficient if the application's useful state cannot move with them.
The engineering response is therefore selective. Retain endpoint checks for the promised application result, identify every mandatory service dependency, and decide explicitly where control and state should reside. Use caching, data replication and authorised intermediaries when they improve the intended service, while testing whether common dependencies defeat the expected fault tolerance. Where independent operation is a requirement, test that requirement directly rather than counting machines. This preserves the adaptable part of the original architecture without pretending that every application must have the same trust boundary or administrative arrangement.[ref]
A digital signature lets the holder of a private key authenticate a message so that anyone with the corresponding trusted public key can verify its origin and integrity. The signature does not conceal the message. Public-key certification, a suitable message hash and protection of the signing key are needed for that interpretation.
For the ElGamal signature scheme, choose a large prime and a primitive root modulo . The secret key is , and the public key is with . Represent the message by a hash modulo . Choose a fresh secret nonce coprime to and set
The signature is . After checking the prescribed ranges, the verifier accepts when
A genuine signature passes because . The security aim is that someone without cannot efficiently produce a valid signature on a new authenticated message. Nonce secrecy and freshness matter: reuse gives linear congruences relating two message hashes, the nonce and the secret key. Signing unhashed arbitrary messages also permits algebraic forgeries, so the hash is part of the practical scheme.
Public key 2026-10-05
The published member of a public-key cryptographic key pair. Its association with a particular identity must itself be authenticated; mere knowledge of a purported public key does not establish that identity.
Public-key cryptography 2026-10-05
Cryptography using a public key and a corresponding private key. Public-key encryption lets others encrypt for the private-key holder; a digital signature instead lets the holder authenticate messages for public verification.
RSA cryptosystem Created 2026-09-24 Updated 2026-11-05
In the two-prime RSA cryptosystem, choose distinct odd prime numbers , set , and choose an integer coprime to . A private exponent satisfies . The public key is ; the private key permits the inverse modular exponentiation. For a message representative ,
Correctness holds even when is not coprime to : modulo each prime the zero case is immediate, while the nonzero case follows from Fermat's little theorem; the Chinese remainder theorem recombines the two congruences.
For example, , , and give ; encrypts to and decrypts back to . These tiny parameters only illustrate the arithmetic. The raw deterministic exponentiation is textbook RSA; practical encryption uses an encoding scheme rather than encrypting an unencoded message directly.[ref]
RSA inversion problem 2026-10-31
Recover a plaintext from an RSA cryptosystem ciphertext and the public key, without a supplied private key. Integer factorization of the modulus suffices; the existence of an efficient general reduction in the reverse direction is not known.