Cyber Security Quiz: Digital Signatures And Integrity
10 questions · exam conditions
0:00
Digital Signatures And IntegrityQuestion 1 of 10

A vendor discovers on June 1 that its code-signing private key has been stolen and revokes the associated certificate. An archived update contains a valid signature and an internal date of March 15, but there is no trusted timestamp or other reliable evidence showing when the signature was created.

Which assessment of the archived update is most defensible?

Revocation makes the signature's mathematical verification fail, so the archived update must have been altered after June 1.
The March 15 date proves the update predates the compromise because changing that date would invalidate the existing signature.
The signature can still verify, but it cannot by itself establish that the update was signed legitimately before the compromise.
Successful verification proves the update is legitimate because private-key compromise affects only signatures created after certificate revocation.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Digital Signatures And Integrity

Practice Digital Signatures And Integrity in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Digital Signatures And Integrity, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A vendor discovers on June 1 that its code-signing private key has been stolen and revokes the associated certificate. An archived update contains a valid signature and an internal date of March 15, but there is no trusted timestamp or other reliable evidence showing when the signature was created.

Which assessment of the archived update is most defensible?

  1. Revocation makes the signature's mathematical verification fail, so the archived update must have been altered after June 1.
  2. The March 15 date proves the update predates the compromise because changing that date would invalidate the existing signature.
  3. The signature can still verify, but it cannot by itself establish that the update was signed legitimately before the compromise. (correct answer)
  4. Successful verification proves the update is legitimate because private-key compromise affects only signatures created after certificate revocation.
Explanation: When evaluating digital signatures after a key compromise, the critical question isn't whether the signature verifies mathematically — it's whether you can trust when it was created. These are two entirely different things, and exam questions in this space almost always hinge on that distinction. A valid digital signature proves that whoever held the private key signed that exact data — it does not prove when that signing occurred. Without a trusted timestamp (like an RFC 3161 timestamp from a trusted authority), there is no cryptographic evidence anchoring the signature to a specific point in time. This is why C is the most defensible answer: the signature still passes mathematical verification (the key was real, the data is unaltered), but it cannot establish that signing happened before June 1 rather than after the key was stolen. A is wrong because revocation does not break mathematical signature verification — it withdraws the certificate's trustworthiness going forward. A revoked certificate's signatures can still be cryptographically verified; revocation is a policy status, not a mathematical operation. D makes a nearly opposite error, claiming compromise only affects post-revocation signatures — in reality, a stolen key can be used to forge signatures backdated to any internal timestamp, so post-compromise signatures are suspect regardless of the date shown. B is the most tempting trap: the internal March 15 date is embedded in the signed data, so altering it would break the signature — but an attacker who stole the key could simply sign a fraudulent document with a March 15 date already embedded. The signature would verify perfectly. Your takeaway: whenever you see "valid signature + no trusted timestamp," the correct framing is verification ≠ legitimacy. Trusted timestamps are the mechanism that pins signatures to time; without them, you have authenticity of content but not authenticity of timing.

Question 2

A financial application digitally signs only the JSON body of a payment request. The destination account is supplied in a separate HTTP header that is not included in the signed data. A proxy changes that header but forwards the original body and signature unchanged.

Why can signature verification succeed even though the payment may be redirected?

  1. The proxy's change is protected by transport headers, which take precedence over the integrity provided by the digital signature.
  2. A valid signature authenticates every field transmitted in the same network request, even when some fields were excluded from hashing.
  3. The signature protects only the signed body, so an unsigned account header can change without affecting the verified body digest. (correct answer)
  4. The signature verifies because destination accounts affect confidentiality rather than integrity and therefore cannot be digitally signed.
Explanation: When you see a question about digital signatures, anchor yourself to one core principle: a signature guarantees integrity only for what was actually signed — nothing more, nothing less. The scope of protection is defined entirely by what data was fed into the hashing and signing process. In this scenario, the application signs the JSON body and produces a valid signature over that specific byte sequence. The destination account lives in a separate HTTP header that was never included in that signed digest. When a proxy modifies the header and forwards the original body and signature, the verifier checks the signature against the body — and the body hasn't changed. Verification passes cleanly. The attack succeeds not because signatures are broken, but because the application designer drew the trust boundary too narrowly. This is why C is correct: the signature protects only the signed body, so the unsigned header can be altered without disturbing the verified digest. A is wrong because there is no such rule that "transport headers take precedence over digital signatures." This is a fabricated concept designed to sound plausible — no such hierarchy exists in cryptographic or HTTP standards. B inverts the truth entirely: a signature authenticates only what was hashed, not every field in the same request. Assuming otherwise is exactly the dangerous misconception this attack exploits. D is wrong because destination accounts absolutely can be digitally signed — confidentiality and integrity are separate properties, and signing data protects integrity regardless of whether it's sensitive. Your study tip: whenever a question involves digital signatures, immediately ask "what data was actually included in the signed hash?" Anything outside that boundary is unprotected, full stop.

Question 3

A signature system signs a cryptographic digest rather than an entire document. Researchers later demonstrate a practical method for constructing two different documents with the same digest under the system's hash algorithm. An attacker prepares one harmless document and one malicious document with that same digest, then obtains a signature on the harmless document.

What is the primary integrity consequence in this scenario?

  1. The attacker can calculate the signer's private key directly because any two documents sharing a digest reveal the signing secret.
  2. The harmless document's signature becomes invalid because signature verification rejects every digest associated with multiple documents.
  3. The malicious document remains unverifiable because signatures bind every original document byte independently of the selected hash algorithm.
  4. The signature may also verify for the malicious document because the signature binds the shared digest rather than uniquely binding either document. (correct answer)
Explanation: Whenever you see a question about digital signatures and hash functions, anchor your thinking to one core principle: a signature doesn't protect a document directly — it protects the document's digest. The verification process computes the digest of whatever document you present and checks whether the signature matches that digest. This is the architectural detail that makes collision attacks dangerous. Here's the attack chain in this scenario: the attacker finds two documents (one harmless, one malicious) that produce the same digest — this is precisely what a collision attack demonstrates. The signer signs the harmless document, which means they sign its digest. Since the malicious document shares that identical digest, presenting it to a verifier produces the same digest value, and the signature check passes. The malicious document is now "validly signed" without the signer ever touching it. That's exactly what D describes — the signature binds the shared digest, not the unique content of either document. A is wrong because a collision in the hash function reveals nothing about the signer's private key. Hash collisions and private key recovery are completely separate cryptographic problems. B inverts reality — verifiers don't automatically reject digests associated with multiple documents; they have no way of knowing a collision exists. Verification is a simple mathematical check, not a collision database lookup. C is wrong because signatures absolutely do not bind "every original byte independently" of the hash algorithm — the hash is the entire basis of what gets signed, which is the whole point of this vulnerability. Study tip: Remember the phrase "sign the hash, not the document." Any weakness in the hash function directly threatens the integrity guarantee of the entire signature scheme.

Question 4

An attacker replaces both a vendor's installer and the verification key linked from the vendor's compromised website. A user imports the replacement key without validating its fingerprint or certificate and then receives a successful signature-verification result for the malicious installer.

What is the strongest conclusion the user can draw from the successful verification?

  1. The installer is authentic because any successful signature verification establishes the vendor's identity independently of key distribution.
  2. The installer matches a signature produced by the private key corresponding to the imported key, but the vendor's identity remains unverified. (correct answer)
  3. The installer has integrity because a valid signature proves that its contents were never modified by any party at any time.
  4. The installer is confidential because only a holder of the corresponding private key could have prepared the signed package.
Explanation: When you see a question about digital signatures, always separate two distinct guarantees: integrity (did the content change?) and authenticity (does this really come from who I think?). Signature verification only delivers both guarantees when you can trust the key you're verifying against — and trusting that key requires a validated chain of custody. In this scenario, the attacker replaced both the installer and the verification key on the compromised website. The user imported the attacker's key and verified the attacker's installer — which produces a perfectly successful result. The signature is mathematically valid: the installer matches the signature made by the attacker's private key. But nothing in that verification process confirms the key belongs to the legitimate vendor. That's exactly what B captures — the installer matches a signature from the imported key's corresponding private key, but vendor identity remains unverified. A is wrong because successful signature verification does not establish vendor identity independently of key distribution. Verification only tells you the file matches the key you used — garbage in, garbage out. If the key is untrusted, the result is meaningless for authentication. C is wrong because "integrity" in cryptographic terms means the content wasn't altered relative to what was signed — here, the malicious file has perfect integrity relative to the attacker's signature, which is precisely the danger. Integrity doesn't mean "unmodified by any party ever." D is wrong because signatures provide authenticity and integrity, not confidentiality; confidentiality comes from encryption, not signing. A useful rule of thumb: a signature is only as trustworthy as the key used to verify it. Always validate key fingerprints through an out-of-band, trusted channel before importing them.

Question 5

An auditor reviews a document signed three years ago. The signer's certificate expired last year. The archive contains a trusted timestamp showing that the signature existed while the certificate was valid, and historical revocation information indicates that the certificate had not been revoked at that time.

How should the auditor interpret the expired certificate?

  1. The signature can remain acceptable if cryptographic verification succeeds and policy recognizes the timestamp and historical certificate status. (correct answer)
  2. The signature should be rejected because certificate expiration retroactively invalidates signatures created with the associated private key.
  3. The signature can be accepted without verifying the document digest or signature value, since the trusted timestamp is sufficient on its own.
  4. The signature can be accepted only after the signer renews the certificate and produces a new signature over the archived document.
Explanation: When evaluating the validity of a digital signature after a certificate has expired, you need to think about long-term signature validation (LTV) — the framework that determines whether a past signature remains trustworthy over time. The key insight is that certificate expiration is forward-looking, not retroactive: it means the certificate can no longer be used to create new signatures, but it says nothing about signatures that were legitimately created while the certificate was still valid. This is exactly why A is correct. The three ingredients for a durable, auditable signature are: (1) successful cryptographic verification of the signature value and document digest, (2) a trusted timestamp proving the signature existed during the certificate's validity period, and (3) historical revocation data confirming the certificate was not revoked at signing time. When all three are present and policy supports LTV, the expired certificate is not a problem — it's a non-issue. B reflects a common misconception. Expiration does not "unwind" past cryptographic events; it simply closes the door on future use. Retroactive invalidation is not how PKI works. C is dangerous because it skips the actual cryptographic verification step. A timestamp proves when something existed, but it doesn't prove the document hasn't been altered or that the signature value is mathematically valid. You still must verify the digest and signature. D is impractical and technically wrong. Requiring the signer to re-sign with a renewed certificate defeats the entire purpose of archival timestamps and ignores that the original signature was valid when made. Study tip: When you see "expired certificate + trusted timestamp," immediately think LTV. The timestamp is the key that preserves historical validity — but it never replaces cryptographic verification.

Question 6

Four system administrators share one private key used to sign emergency configuration packages. A disputed package has a valid signature under the corresponding trusted public key. Logs show that one administrator account submitted the package, but all four administrators could access both that account and the shared private key.

What does the valid signature establish most reliably?

  1. It establishes which administrator approved the package because a valid signature uniquely identifies the human who initiated signing.
  2. It establishes use of the shared signing key and package integrity, but it does not reliably identify which administrator used the key. (correct answer)
  3. It establishes only confidentiality of the package because sharing a private key prevents all integrity verification by the public key.
  4. It establishes that no administrator can repudiate the package because every authorized key holder is individually accountable for each signature.
Explanation: When a question involves digital signatures and accountability, train yourself to ask two separate questions: What does the signature prove about the data? and What does the signature prove about the person? These are not the same thing, and confusing them is exactly the trap this question sets. A digital signature created with a private key reliably proves two things: that the signing key was used, and that the signed data has not been altered since signing (integrity). This is what makes B correct. Because four administrators share the same private key, the signature tells you the key was used — nothing more. It cannot distinguish which of the four people held the key at that moment, so individual attribution is impossible. A is wrong because signatures identify keys, not humans. A valid signature only maps back to a person when that person is the sole custodian of the key. The moment a key is shared, that one-to-one mapping breaks down entirely. C is wrong on two counts: sharing a private key does not destroy integrity verification, and signatures provide integrity, not confidentiality. Confidentiality requires encryption, which is a completely separate mechanism. D misapplies the concept of non-repudiation. Non-repudiation is only meaningful when a key is held exclusively by one party. With four people sharing a key, any one of them can credibly say "it wasn't me" — so the shared key arrangement actually undermines individual non-repudiation rather than enforcing it. Your study tip: whenever you see "shared private key," immediately flag that non-repudiation and individual attribution are broken. Signatures still prove integrity, but they cannot prove who.

Question 7

A software publisher distributes an application package over an untrusted mirror. Customers already possess an authenticated copy of the publisher's public key. The publisher wants customers to detect unauthorized package changes and verify that the release was approved by the publisher.

Which process best meets both objectives?

  1. Encrypt the package with the publisher's private key, then have customers recover it using the authenticated public key.
  2. Hash the package and encrypt the resulting digest with each customer's public key before placing both files on the mirror.
  3. Hash the package and sign the digest with the publisher's private key; customers recompute the digest and verify the signature. (correct answer)
  4. Hash the package and publish the digest beside it; customers compare the published digest with a newly computed digest.
Explanation: When a question asks you to satisfy two goals simultaneously — integrity verification and publisher authentication — think immediately about digital signatures. A hash alone proves a file hasn't changed, but it can't tell you who approved it. A signature alone without hashing is computationally impractical for large files. The combination is what makes the solution complete. Option C is correct because it addresses both requirements elegantly. The publisher hashes the package (producing a fixed-length digest), then encrypts that digest with their private key — this is the signature. Customers recompute the hash from the downloaded package, then decrypt the signature using the publisher's authenticated public key. If the digests match, they know (1) the package is unaltered, and (2) only the publisher — the sole holder of that private key — could have created the signature. Option A is a conceptual trap. Encrypting an entire package with a private key isn't a standard signing operation — it's computationally expensive, doesn't scale, and conflates encryption with signing. Private keys sign; public keys verify. Option B reverses the key usage for the signature step. Encrypting the digest with each customer's public key means only that individual customer could decrypt it — it provides confidentiality to each customer, not a single verifiable publisher signature. It also doesn't scale. Option D publishes a hash digest in plaintext beside the package. Anyone who compromises the mirror can simply replace both the file and its hash, so this provides integrity checking only if the digest is hosted on a trusted, separate channel — not authentication. Study tip: Remember the asymmetric key rule — you sign with the private key and verify with the public key. Any answer that flips this relationship is almost certainly a distractor.

Question 8

An analyst digitally signs a confidential incident report and uploads the plaintext report and its signature to a publicly accessible server. An unauthorized visitor downloads both files but does not possess the analyst's private key.

Which outcome is most likely?

  1. The visitor cannot read the report because signing transforms the plaintext into content recoverable only with the analyst's public key.
  2. The visitor can read the report, but unauthorized changes can be detected by a verifier using the analyst's trusted public key. (correct answer)
  3. The visitor can alter the report without detection because public verification allows anyone to generate a replacement signature.
  4. The visitor cannot read the report unless the signature is first removed, because the signature encapsulates the report's contents.
Explanation: Whenever you see a question involving digital signatures, keep two distinct concepts separate in your mind: confidentiality (hiding content) and integrity/authenticity (detecting tampering). Digital signatures address only the second concern — they do nothing to encrypt or conceal the underlying data. Here's how a digital signature works: the analyst hashes the report, then encrypts that hash with their private key to produce the signature. Anyone with the analyst's public key can decrypt the signature, re-hash the report independently, and compare results. If the hashes match, the report is untampered and genuinely from the analyst. Crucially, the original report remains in plaintext throughout — signing it doesn't obscure it at all. This confirms B: the visitor can read the report freely, but any unauthorized modification will produce a mismatched hash during verification, making tampering detectable. A is wrong because signing never transforms plaintext into unreadable ciphertext. The report is uploaded as plaintext and remains fully readable — no private key is needed to read it, only to create the signature. C is wrong because public verification does not allow anyone to generate a valid replacement signature. Creating a signature requires the analyst's private key, which the visitor lacks — so a tampered report would fail signature verification. D is wrong for the same reason as A: the signature doesn't encapsulate or hide the report's contents; it's a separate file that proves authenticity. A quick study tip: on security exams, if a question involves signing (not encrypting), default to thinking about integrity and non-repudiation, not confidentiality — those require separate encryption mechanisms.

Question 9

A company signs the exact bytes of a text-based purchase order. During transfer, an email gateway changes line endings from one standard format to another but does not alter any words, quantities, or prices. The recipient verifies the signature against the received bytes.

Assuming no canonicalization was performed before signing or verification, what should the recipient expect?

  1. Verification should succeed because digital signatures compare the document's semantic meaning rather than its byte representation.
  2. Verification should succeed because line-ending changes are automatically excluded when a cryptographic digest is calculated.
  3. Verification should fail only if the gateway also modified the public key or the signature's certificate chain.
  4. Verification should fail because the received byte sequence produces a different digest even though the visible meaning is unchanged. (correct answer)
Explanation: When you see a question involving digital signatures and document transfer, your first instinct should be to think about what a cryptographic hash actually measures: exact bytes, not meaning. A hash function like SHA-256 treats a document as a raw sequence of bits. Even a single changed byte produces a completely different digest — this is called the avalanche effect and is a foundational property of cryptographic hashing. Here's the chain of logic for this scenario: the sender hashes the original bytes and encrypts that hash with their private key to create the signature. The email gateway then converts line endings (e.g., \r\n → \n), silently changing the byte sequence. When the recipient hashes the received bytes, they get a different digest than what was originally signed. Comparing the two digests reveals a mismatch, so verification fails — even though no words, prices, or quantities changed. That makes D the correct answer. A is wrong because digital signatures absolutely do operate on byte representations, not semantic meaning. There is no "meaning layer" in cryptographic verification — that concept doesn't exist in this context. B is wrong because hash functions have no built-in awareness of what constitutes a "trivial" change; they treat every byte equally. Line-ending differences are not automatically ignored. C confuses the failure condition — verification fails due to digest mismatch, not because of changes to the public key or certificate chain, which weren't touched at all. The study tip here: canonicalization exists precisely to solve this problem. Protocols like XML-DSig and S/MIME normalize documents into a standard byte format before signing. When you see "no canonicalization," expect byte-level fragility.

Question 10

A payment service accepts digitally signed transfer instructions. An attacker records a valid instruction and submits the identical signed message again the following day. The signature still verifies because neither the instruction nor its signature was changed.

Which control most directly allows the service to reject this replay while retaining signature-based integrity verification?

  1. Include a transaction identifier and freshness value in the signed data, then enforce uniqueness and an acceptable time window. (correct answer)
  2. Apply the same cryptographic hash twice before signing, then reject instructions whose two calculated digests differ.
  3. Attach an unsigned receipt time at the gateway, then accept the instruction whenever its digital signature remains valid.
  4. Encrypt the signature with the service's public key, then accept every instruction that the service can decrypt successfully.
Explanation: When you see a question about replay attacks, the core issue is this: a digital signature only proves authenticity and integrity — it confirms who signed the message and that it wasn't altered. It says nothing about whether you've seen that exact message before. Attackers exploit this by resubmitting a legitimately signed message without modification. The solution is to bind freshness and uniqueness inside the signed data itself. Option A does exactly this: by including a transaction ID and a timestamp (or nonce) within the signed payload, the service can (1) reject any instruction outside an acceptable time window and (2) track seen transaction IDs to prevent duplicates. Because these values are part of the signed data, an attacker cannot strip or alter them without invalidating the signature — giving you replay protection without sacrificing integrity verification. Option B is a distractor about double-hashing, which adds no replay protection whatsoever. Two identical messages will always produce identical digests regardless of how many times you hash them — this detects corruption, not replays. Option C is a critical trap: attaching an unsigned receipt timestamp at the gateway means the timestamp is outside the cryptographic protection. An attacker or malicious gateway could manipulate it freely, so it provides no reliable defense. Option D describes decrypting with the service's public key, which is cryptographically backwards — you encrypt with a public key and decrypt with a private key. This option is functionally nonsensical and would not verify or protect anything meaningful. Your study tip: whenever replay attacks appear on the exam, ask yourself whether freshness and uniqueness controls are inside the signed data. If they're outside, they can be tampered with and offer no real protection.