(An organization wants to digitally sign its software to guarantee the integrity of its source code. Which key should the customer use to decrypt the digest of the source code?)
Answer : B
When software is digitally signed, the organization computes a cryptographic hash (digest) of the software (or its manifest) and then signs that digest using the organization's private key. Verification works in the opposite direction: the customer (verifier) uses the organization's public key to validate the signature and recover/confirm the signed digest, then independently hashes the received software and compares the result. If the digests match and the signature validates under the public key, the customer has strong assurance that the software has not been altered since it was signed and that it was signed by the holder of the corresponding private key. The customer never needs the organization's private key---sharing it would destroy security and enable forgery. Likewise, the customer's own keys are irrelevant to verifying the publisher's signature. The organization's public key is typically delivered inside a certificate chain (code signing certificate) so the verifier can also validate publisher identity and trust. Therefore, the customer uses the organization's public key for signature verification (often described as ''decrypting'' the signed digest).
(What is the purpose of code-signing in current systems?)
Answer : B
Code-signing is used to provide verifiable assurance that software comes from a known publisher and has not been modified since it was signed. In a typical code-signing workflow, the publisher computes a cryptographic hash (digest) of the executable or package and then creates a digital signature over that digest using the publisher's private key. Operating systems, browsers, and application platforms verify the signature using the corresponding public key (usually delivered via a code-signing certificate chained to a trusted root). If verification succeeds, the system can trust that the code's contents match what the publisher signed (integrity) and that the signer identity is authenticated by the certificate chain (authenticity). This helps defend against tampering, malware injection, and supply-chain attacks where attackers alter binaries or updates in transit or at rest. Code-signing does not primarily generate randomness, compress data, or authenticate users; it authenticates the software publisher and validates the software artifact. Modern ecosystems also use timestamping and revocation checking to handle certificate expiration and compromised signing keys, reinforcing trust over time.
(What are the primary characteristics of Bitcoin proof of work?)
Answer : B
Bitcoin's proof of work (PoW) is designed so that finding a valid block is computationally difficult, but checking validity is computationally easy. Miners must repeatedly hash candidate block headers (double SHA-256) with different nonces until they find a hash value below a network-defined target. This trial-and-error search requires significant work and energy because the probability of success per attempt is extremely low at current difficulty levels. However, verification is straightforward: any node can hash the block header once (or a small number of times) and confirm the resulting hash meets the target threshold and that the block contents follow protocol rules. This ''hard to produce, easy to verify'' property is essential: it makes it expensive for attackers to rewrite history or outpace honest miners, while allowing all participants---even low-power devices---to validate blocks efficiently. Therefore, the primary characteristic of Bitcoin proof of work is that it is difficult to produce and easy to verify.
(Which type of exploit involves looking for different inputs that generate the same hash?)
Answer : A
A birthday attack targets hash functions by exploiting the birthday paradox: collisions (two different inputs producing the same hash output) can be found much faster than brute-forcing a specific preimage. For an n-bit hash, the expected work to find any collision is on the order of 2^(n/2), not 2^n. The attack is relevant because many security constructions rely on collision resistance---digital signatures, certificate fingerprints, integrity checks, and some commitment schemes. If an attacker can generate two different documents with the same hash, they may trick a signer into signing one version while later presenting the other as ''signed,'' depending on the protocol. Linear cryptanalysis and differential cryptanalysis are primarily techniques against block ciphers, analyzing relationships between plaintext/ciphertext differences or linear approximations across rounds. Algebraic attacks treat the cipher as a system of equations. The description ''looking for different inputs that generate the same hash'' is the hallmark of collision-finding, and the classic framing for that is the birthday attack.
(How is Public Key Infrastructure (PKI) commonly utilized in web browsers?)
Answer : C
Web browsers rely on PKI to establish trust in secure connections, primarily through X.509 certificates and a built-in set of trusted root Certificate Authorities (CAs). When a browser connects to an HTTPS site, the server presents a certificate chain. The browser validates that chain up to a trusted root, checks that the certificate is valid for the domain (SAN/CN matching), confirms validity dates, and may check revocation status. This PKI process allows browsers to authenticate the website's identity and negotiate encrypted session keys for TLS, enabling confidentiality and integrity for the connection. In practical terms, the browser's PKI components include certificate stores, validation logic, and mechanisms for handling intermediates, trust policies, and revocation. While PKI supports authentication as an outcome, the best description of how browsers utilize PKI is that they manage and validate digital certificates and associated keys to establish trust. PKI is not about compressing messages or encrypting data at rest; it is about identity binding and trust chains that make secure web communication possible.
(Two people want to communicate through secure email. The person creating the email wants to ensure only their friend can decrypt the email. Which key should the person creating the email use to encrypt the message?)
Answer : D
To ensure confidentiality so that only the intended recipient can decrypt an email, the sender must encrypt in a way that only the recipient can reverse. In public key cryptography, that means encrypting with the recipient's public key. The recipient is the only party who should possess the matching private key, so only they can decrypt the ciphertext. This pattern is fundamental to PKI-based secure email systems such as S/MIME and OpenPGP: the sender looks up or is provided the recipient's certificate/public key, encrypts the message (often by encrypting a randomly generated symmetric session key with the recipient's public key), and the recipient uses their private key to recover the session key and decrypt the content. Encrypting with the sender's private key would not provide confidentiality; it resembles signing because anyone with the sender's public key could ''decrypt'' it. Encrypting with a private key of the recipient is also incorrect because private keys are not shared and should never leave the recipient's control. Therefore, the correct key to encrypt the message so only the friend can decrypt it is the recipient's public key.
(Which is an example of asymmetric encryption?)
Answer : D
Asymmetric cryptography uses a public/private key pair where different keys are used for related operations (encryption/decryption or signature/verification). Elliptic-Curve Cryptography (ECC) is a family of asymmetric algorithms built on the mathematics of elliptic curves over finite fields. ECC supports key exchange (ECDH), digital signatures (ECDSA/EdDSA), and other primitives with smaller key sizes for comparable security to traditional discrete-log or RSA systems (e.g., a 256-bit ECC key is often comparable in security to a 3072-bit RSA key, depending on scheme and parameters). By contrast, SHA-256 is a cryptographic hash function (one-way digest), and HMAC is a keyed integrity/authentication construction built from a hash function---neither is encryption. DES is a symmetric block cipher (same key for encryption and decryption). Therefore, the example of asymmetric encryption among the options is ECC.