Introduction-to-Cryptography WGU Introduction to Cryptography HNO1 Questions and Answers

A brute-force attack exhaustively tries every possible key or password candidate until the correct one is found. Because it explores the full search space (or a very large portion of it), brute force is often the slowest method, especially when strong keys, long passwords, rate limits, and slow password hashing (bcrypt/Argon2) are used. By contrast, a dictionary attack reduces work by trying only common or likely passwords, often succeeding quickly against weak human-chosen secrets. Rainbow table attacks shift work into precomputation; once a table exists, lookup can be faster than brute-force—though salt and modern hashing defeat them. Birthday attacks are about finding collisions, not necessarily recovering a specific secret, and their expected work is about 2^(n/2) for an n-bit hash, which can be less than brute-force key search in many contexts. Therefore, among the listed options, brute-force generally takes the longest to succeed because it makes the fewest assumptions and does the most total work.

OCSP is the primary online alternative to CRLs for checking whether a certificate has been revoked. With a CRL, a relying party periodically downloads a list of revoked certificate serial numbers published by the issuing CA (or CRL distribution point). That approach can be bandwidth-heavy, introduces latency between revocation and client awareness, and can result in clients using stale revocation data if updates are infrequent. OCSP improves this by allowing a client (or a server on the client’s behalf) to query an OCSP responder in near real time about the status of a specific certificate (good, revoked, or unknown). In practice, many TLS deployments use OCSP stapling, where the server periodically fetches a signed OCSP response from the CA’s responder and “staples” it to the TLS handshake, reducing client-side network calls and improving privacy (the CA doesn’t learn which site the client is visiting). Thus, OCSP provides a more timely, certificate-specific revocation status mechanism than CRLs while preserving the CA’s signed assurance.

Bit-flipping exploits target encryption modes or protocols that do not provide strong integrity, allowing attackers to modify ciphertext so that predictable changes occur in plaintext after decryption. To defend against this, protocols add an integrity mechanism that detects tampering. In WPA (including enterprise deployments), TKIP introduced a Message Integrity Check (MIC) called “Michael.” The MIC is computed over the frame contents (with additional fields) and verified by the receiver; if an attacker flips bits in transit, the MIC verification fails, and the frame is rejected. While AES (used by WPA2’s CCMP) also provides integrity via authenticated encryption, the option presented that directly names the tamper-detection mechanism associated with guarding against bit-flipping is MIC. A pre-shared key is an authentication/keying method (and not enterprise-mode anyway), and a “global encryption key” would be the opposite of what you want—global/static keys worsen security. Therefore, the intended mechanism that mitigates bit-flipping by detecting unauthorized modifications is the Message Integrity Check.

Ethical concerns about encryption commonly arise from the tension between individual privacy/security and societal needs such as law enforcement, national security, and public safety. Strong end-to-end encryption can prevent unauthorized parties from accessing data, including criminals and foreign adversaries, but it can also limit legitimate government access to communications and evidence—even with warrants—because providers may not possess the keys needed to decrypt. This has fueled debates around “going dark,” lawful access, and proposals for exceptional access mechanisms or backdoors. Critics argue that weakening encryption for access would create systemic risk, since any intentional vulnerability can be exploited by malicious actors, while proponents emphasize investigative needs in serious cases. Regardless of the stance, the primary ethical concern reflected in policy debates is that encryption complicates government access to information that may be crucial for preventing or investigating crime. The other options do not capture the main ethical controversy: encryption is widely beneficial beyond corporations, and it is not primarily about speed or storage reduction. Therefore, the correct answer is B.

When securely distributing a symmetric key over an untrusted network, a common approach is hybrid cryptography: use asymmetric cryptography to protect the symmetric key, then use the symmetric key for bulk encryption. To ensure only Employee B can recover the symmetric key, Employee A encrypts (wraps) that symmetric key using Employee B’s public key. Because only Employee B should possess the matching private key, only B can decrypt the wrapped symmetric key. This is the same principle used in TLS key exchange (in older RSA key transport) and in secure email: encrypt the session key to the recipient’s public key. Encrypting the symmetric key with Employee A’s private key would not provide confidentiality—anyone with A’s public key could reverse it, and it functions more like a signature than encryption. Employee B’s private key should never be shared and is used only by B to decrypt. Therefore, for confidentiality of the shared symmetric key, the correct encryption key is Employee B’s public key.

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.

AES is a symmetric-key block cipher, meaning the same shared secret key is used for both encryption and decryption. It operates on fixed-size 128-bit blocks and supports key sizes of 128, 192, and 256 bits. Being symmetric, AES is efficient and well-suited for encrypting large volumes of data—files, disk encryption, VPN payloads, and bulk traffic in protocols like TLS once a session key is established. AES is not “hybrid” by itself; hybrid encryption refers to combining asymmetric cryptography (for key exchange or key wrapping) with symmetric cryptography (for bulk data encryption), and AES often plays the symmetric part of that hybrid design. It is not “quantum encryption,” which is a separate, loosely used term sometimes referring to quantum key distribution or quantum-resistant algorithms. AES is also not asymmetric; it does not use public/private key pairs. Therefore, AES is correctly classified as symmetric encryption, matching option D.

Digital signing of software typically works by hashing the application (or its manifest) and then using the publisher’s private key to create a digital signature over that digest. The private key is used because it is secret and uniquely controlled by the publisher; only the publisher should be able to produce a valid signature. Verifiers (customers) use the publisher’s public key to validate the signature and confirm that the digest matches the software they received. This yields two key properties: integrity (the software hasn’t been altered; any modification changes the digest and breaks verification) and authenticity (the signature proves it came from the private-key holder). Option A incorrectly describes symmetric stream encryption. Option C incorrectly generalizes private-key behavior as “block encryption.” Option D is wrong because verification uses the public key, not a private key; also, “encrypting with private key” in this context is better understood as signing, not confidentiality encryption. Therefore, the correct rationale is that the asymmetric private key is used to sign the file’s digest so the corresponding public key can verify integrity and authenticity.

A salt is a unique, random value stored alongside a password hash and combined with the password during hashing. Its main security benefit is that it ensures identical passwords do not produce identical hashes across different accounts or systems. If two users choose the same password, their stored hashes will differ because their salts differ, which directly prevents attackers from spotting shared passwords by comparing hashes. Salts also defeat precomputation attacks such as rainbow tables, because an attacker would need to regenerate tables for each possible salt value—a task that becomes infeasible when salts are large and unique per password. Salt does not enforce password complexity rules (that’s a policy/validation function), does not guarantee users choose different passwords, and does not prevent password reuse across sites. The correct statement is that salt makes the resulting hash different even for the same password, improving resistance to offline cracking at scale and eliminating the “same hash = same password” shortcut attackers rely on.

Asymmetric encryption (also called public key cryptography) uses a pair of mathematically related keys: a public key and a private key. One key is used to encrypt, and the other is used to decrypt, which is the defining “different keys” property asked in the question. In the common confidentiality use case, a sender encrypts a message using the recipient’s public key, and only the recipient can decrypt it using their private key. This solves the key distribution problem inherent in symmetric encryption, where both parties must securely share the same secret key in advance. Asymmetric systems also enable digital signatures: the private key signs (creates a signature) and the public key verifies it, providing authenticity and integrity. Symmetric encryption, by contrast, uses the same shared key for both encryption and decryption (even though internal round keys may exist, it is still one shared secret). “Private key” alone is not a full encryption type, and “secure” is a generic description rather than a cryptographic category. Therefore, the correct answer is D. Asymmetric.

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).

AES by itself is a symmetric block cipher that provides confidentiality, but not guaranteed integrity unless used in an authenticated mode. To protect integrity of the plaintext (ensuring it has not been altered), a Message Authentication Code (MAC) can be applied. In the classic Encrypt-then-MAC pattern, the sender encrypts the plaintext with AES and then computes a MAC (often HMAC-SHA-256 or CMAC-AES) over the ciphertext (and relevant headers). The receiver verifies the MAC before attempting decryption, preventing tampering and many padding-oracle style vulnerabilities. Alternatively, AES can be used in an AEAD mode like AES-GCM, which produces an authentication tag serving a similar purpose, but among the listed options the general integrity mechanism is “MAC.” RC4 is an unrelated stream cipher and does not provide integrity. RSA is asymmetric and not the standard integrity add-on for AES-encrypted bulk data. Kerberos is an authentication protocol and key distribution system, not a message integrity primitive. Therefore, to protect plaintext integrity when using AES, the correct mechanism is a Message Authentication Code.

SHA-1 (Secure Hash Algorithm 1) produces a fixed-size output of 160 bits (20 bytes). Hash output size matters in cryptography because it influences collision resistance and the effort required for various attacks. For an ideal n-bit hash, finding a collision by generic means is expected around 2^(n/2) operations (birthday bound). With SHA-1’s 160-bit output, that generic bound would be about 2^80, which was once considered strong; however, SHA-1 has been broken in practice with significantly less work due to cryptanalytic advances, and it is now deprecated for most security uses. Still, the question is strictly about output length, not current suitability. The other options do not match SHA-1: 40 bits would be far too small for a modern hash, 80 bits is not SHA-1’s output, and 320 bits would imply a much larger digest (closer to SHA-256’s 256 bits or SHA-384’s 384 bits). Therefore, the correct SHA-1 output length is 160 bits.

Lightweight cryptography is important because many modern systems operate in constrained environments—IoT sensors, embedded controllers, wearables, and mobile devices—where CPU, memory, storage, bandwidth, and battery power are limited. Traditional “heavy” cryptographic suites may be too slow, too energy-intensive, or too large in code footprint for these platforms, leading to insecure workarounds or disabling security entirely. Lightweight cryptographic primitives and profiles are designed to deliver strong security properties (confidentiality and integrity, often via AEAD) while fitting within tight resource budgets and real-time constraints. This is essential as IoT and mobile ecosystems expand, increasing the attack surface and the consequences of compromised devices (botnets, surveillance, physical safety risks). Lightweight cryptography is not meant to “limit encryption tools” or complicate protection; it enables practical, deployable security where otherwise implementations might be weak or absent. High-speed network communication can benefit from efficient crypto too, but the defining modern driver is constrained-device security. Therefore, the correct reason is addressing the security needs of IoT devices and mobile applications.

A VPN (Virtual Private Network) is designed to create a secure, private communication channel over an otherwise untrusted or shared infrastructure. Historically and conceptually, VPNs were built to allow organizations and users to transmit sensitive traffic across the public Internet while maintaining confidentiality, integrity, and authenticity. The “virtual” aspect means the network behaves like a private link, but the underlying transport is typically a public network where attackers could potentially observe or tamper with traffic. VPN technologies such as IPsec and SSL/TLS-based VPNs encapsulate packets and apply encryption and authentication so that the payload and session metadata are protected even when traversing public routing domains. Options like “encrypted” and “protected” describe properties of the VPN tunnel itself rather than the underlying network it traverses; the VPN provides encryption/protection precisely because the medium is not inherently secure. “Private” would describe a dedicated internal network, which generally does not require a VPN to achieve basic confidentiality. Therefore, VPNs were originally designed to tunnel through public networks.

A true random number generator (TRNG) draws randomness from physical phenomena that are inherently unpredictable and not algorithmically reproducible. Because of this, it is nondeterministic: you cannot feed it the same “input” and expect the same output stream. TRNGs are often slower than PRNGs because they depend on collecting entropy from hardware sources and may require conditioning to remove bias. This aligns with option B: slow and nondeterministic, producing different results even under similar or repeated conditions. Option A describes a deterministic PRNG, where identical seeds yield identical sequences. Option C is unrelated; factorization is a hard math problem used in cryptography (e.g., RSA security assumptions), not a randomness generator definition. Option D describes a counter, which is deterministic and not random. In secure systems, TRNG output may seed a cryptographically secure PRNG to provide both unpredictability and high throughput; but the defining characteristic of a TRNG is nondeterminism from physical entropy. Therefore, option B is correct.

DER (Distinguished Encoding Rules) is a binary encoding format used to represent ASN.1 structures in a canonical, unambiguous way. X.509 certificates are defined using ASN.1, and DER provides a strict subset of BER (Basic Encoding Rules) that guarantees a single, unique encoding for any given data structure. That “unique encoding” property is important for cryptographic operations such as hashing and digital signatures, because different encodings of the same abstract data could otherwise produce different hashes and break signature verification. In contrast, PEM is not a binary encoding; it is essentially a Base64-encoded text wrapper around DER data, bounded by header/footer lines (e.g., “BEGIN CERTIFICATE”). PKI is an overall framework for certificate issuance, trust, and lifecycle management—not an encoding. RSA is an asymmetric algorithm used for encryption/signing, not a certificate encoding format. Therefore, the binary-based certificate encoding process among the options is DER.

Symmetric cryptography uses a single shared secret key for both encryption and decryption. This contrasts with asymmetric cryptography, which uses a key pair (public/private). Symmetric algorithms (like AES, ChaCha20) are efficient and well-suited for bulk data encryption, but they require a secure method for key distribution because both parties must possess the same secret. Hashing is not a keyed operation by default (though HMAC is keyed); it maps arbitrary data to a fixed-size digest and is primarily used for integrity checking, fingerprints, and password hashing constructions. Padding is a data formatting technique (e.g., PKCS#7) used to align plaintext to a block size; it is not a cryptographic “operation” that uses a key. Therefore, the cryptographic operation characterized by using one key shared between parties is symmetric encryption. In real systems, symmetric encryption is frequently combined with asymmetric methods for key exchange and with MACs/AEAD for integrity, producing the standard hybrid approach used in protocols like TLS and IPsec.

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.

A cryptographic hash function maps input data of arbitrary length to a fixed-length digest and is designed to be one-way: given a digest, it should be computationally infeasible to recover the original input (preimage resistance). This one-way property enables many security applications: file integrity checking (any change alters the digest), password storage (combined with salt and slow hashing), digital signatures (signing a digest rather than large data), and commitment schemes. Hash functions are not encryption because they do not support decryption; they intentionally discard information about the input. They also do not use public/private key pairs; those are features of asymmetric cryptography. “Reversible” is the opposite of the intended design goal. A well-designed hash also aims for collision resistance (hard to find two different inputs with the same digest) and second-preimage resistance. Among the answer choices, the defining characteristic that best captures what makes a hash function distinct is that it is one-way.

Large prime numbers are crucial because they enable cryptosystems where certain operations are easy to perform, but reversing them is computationally hard without secret information. In RSA, security is based on the difficulty of factoring a large composite number that is the product of two large primes; multiplying primes is easy, but factoring the product is believed to be hard at sufficient sizes. In Diffie–Hellman and related systems, primes define finite groups (often modulo a large prime) where exponentiation is efficient but the discrete logarithm problem is hard. Primes also help ensure desirable group properties—such as having a large cyclic subgroup—reducing vulnerabilities from small subgroups or weak structure. The value of “large” is that it makes brute-force and known algorithmic attacks infeasible with current computing resources. Large primes do not primarily make encryption faster, nor do they make decryption easier; they are chosen to maximize security margins. While primes can be involved in encoding steps, their importance is security: they form the mathematical foundation for hardness assumptions used by major public-key algorithms. Therefore, the best answer is that they provide security in encryption algorithms.

ISO/IEC 27001 is an international standard for establishing, implementing, maintaining, and continually improving an Information Security Management System (ISMS). Its focus is not inventing cryptographic algorithms, but managing information security through a structured governance approach: identifying assets, assessing risks, selecting and implementing controls, measuring effectiveness, and continuously improving. The standard emphasizes a risk-based methodology—controls are chosen based on organizational context and threat landscape, and the ISMS is refined over time through audits, management reviews, and corrective actions. While cryptography can be part of the control set (e.g., encryption policies, key management, secure communications), ISO/IEC 27001 addresses a broad range of security domains beyond crypto, including physical security, access control, incident management, supplier relationships, and business continuity. It also does not enforce criminal penalties; it is a certification/management standard. And it is not limited to network security. Therefore, the correct focus is risk management and continuous improvement of information security.

One-way client authentication is the method where the client (customer) proves its identity to the server (web service). In cryptographic terms, this is commonly implemented through client credentials such as client TLS certificates (mTLS from the server’s perspective) or through authentication protocols layered over TLS (for example, signed tokens), but the defining direction is that the client is the party being authenticated. In a strict TLS certificate-authentication framing, client authentication occurs when the server requests a client certificate during the handshake and the client demonstrates possession of the corresponding private key (via signature in handshake messages). The server then validates the client certificate chain and authorization policy. One-way server authentication, by contrast, authenticates only the server to the client and does not identify the customer. Mutual authentication authenticates both sides simultaneously; while it includes client authentication, it is broader than what the question asks. “End-to-end authentication” describes assurance between endpoints across intermediaries, but it is not the specific “customer authenticates to service” method in certificate-based terminology. Therefore, the best answer is one-way client authentication.

Large-scale quantum computers threaten many widely deployed public-key algorithms because quantum algorithms can solve their underlying hard math problems efficiently. In particular, Shor’s algorithm can factor large integers and compute discrete logarithms in polynomial time, which directly breaks the security assumptions of RSA (factoring) and traditional Diffie–Hellman/ECC (discrete log). That makes RSA the clearest target among the options. By comparison, symmetric algorithms like AES are affected mainly by Grover’s algorithm, which provides a quadratic speedup for brute force; this can be mitigated by using larger keys (e.g., AES-256). Hash functions like SHA-256 also face Grover-style speedups for preimage search, again mitigated by output length/security margin, and collision resistance is impacted differently. ECB is a mode of operation, not a standalone algorithm, and its issues are classical (pattern leakage), not specifically quantum. Therefore, the algorithm most directly threatened by quantum computing among the choices is RSA.