Free Practice Questions for WGU Introduction-to-Cryptography Exam

Symmetric cryptography generally provides the fastest encryption and decryption performance among common cryptographic operations. Algorithms like AES and ChaCha20 are designed for high throughput and efficient implementation in software and hardware (e.g., AES-NI acceleration). Symmetric decryption is computationally similar in cost to symmetric encryption, and both are far faster than asymmetric operations for equivalent security levels. Asymmetric cryptography (RSA, ECC) involves expensive mathematical operations (modular exponentiation or elliptic-curve scalar multiplication), making it much slower and unsuitable for bulk data decryption. That is why real-world secure protocols use asymmetric cryptography primarily to authenticate peers and establish keys, then switch to symmetric encryption for the actual data stream. Hashing is not decryption at all; it is one-way, and there is no “decrypt” operation for a hash. Padding is not a decryption mechanism; it is a formatting step used with block ciphers to align plaintext length. Therefore, the correct choice for the operation with the fastest decryption process is symmetric cryptography.

3DES (Triple DES) commonly uses an Encrypt–Decrypt–Encrypt (EDE) sequence. In the two-key form, it encrypts with key K1, decrypts with key K2, then encrypts again with K1. In the three-key form, it encrypts with K1, decrypts with K2, then encrypts with K3. The EDE construction was chosen partly for backward compatibility: if K1=K2=K3, the scheme reduces to single DES, allowing older systems to interoperate in constrained ways. AES and IDEA do not use an EDE triple-stage process as their defining structure; they are single-pass block ciphers with internal rounds. DES is a single-pass algorithm (one key) rather than a triple application with multiple keys. Therefore, the algorithm described—encrypt with one key, decrypt with another, encrypt with the first—is 3DES. Although now considered legacy, it remains a classic example of increasing effective security by applying a block cipher multiple times with independent keys.

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.

CTR (Counter) mode converts a block cipher into a stream-like encryption method by generating a keystream from encrypted counter blocks. The core idea is to construct a sequence of input blocks using a nonce (unique per message/session) plus an incrementing counter. Each nonce||counter block is encrypted with the block cipher under the shared key; the output is a pseudorandom block that is XORed with plaintext to produce ciphertext. Decryption repeats the same keystream generation and XORs with ciphertext to recover plaintext. CTR offers practical benefits: it is highly parallelizable, supports precomputation of keystream blocks, and allows random access to any block without needing previous blocks (unlike CBC). ECB and CBC are block modes that do not use nonce+counter keystream generation. CFB is a feedback mode that can behave stream-like, but it does not use the explicit counter/nonce construction characteristic of CTR. CTR’s security hinges on never reusing the same nonce/counter sequence with the same key, because that would reuse the keystream and enable XOR-based plaintext recovery. Therefore, the correct mode is Counter (CTR).

One-way server authentication is the standard model used by most TLS-enabled web services to prove the server’s identity to a client. In this model, the server presents an X.509 certificate during the TLS handshake. The client validates the certificate chain to a trusted root CA, checks hostname binding (CN/SAN), validates validity dates, and may check revocation status. If validation succeeds, the client gains cryptographic assurance that it is communicating with the holder of the private key corresponding to the server certificate’s public key, and that the certificate is issued to the expected domain/identity. This proves the server’s identity to the customer without requiring the customer to present a certificate. Mutual authentication would require both client and server to authenticate each other using certificates (commonly in certain enterprise APIs), but the question asks specifically about the web service proving its identity to the customer, which is satisfied by server-only authentication. One-way client authentication is the opposite direction (client proves identity to server). “End-to-end authentication” is a broader concept and not the specific TLS identity proof mechanism described here. Thus, one-way server authentication is the correct choice.

A cryptography framework provides a consistent, repeatable way to select, deploy, and manage cryptographic controls across an organization. Its key benefit is structure: it defines approved algorithms and key sizes, acceptable modes of operation, key management rules (generation, storage, rotation, revocation, backup), certificate handling, and secure protocol configurations (e.g., TLS settings). This reduces ad hoc implementations that often lead to vulnerabilities such as weak ciphers, key reuse, improper randomness, or missing integrity protections. A framework also clarifies roles and processes—who can access keys, how secrets are audited, and how exceptions are handled—improving governance and operational reliability. Importantly, it does not guarantee perfect security; no framework can eliminate all risk, and secure outcomes still depend on correct implementation, monitoring, and maintenance. It also does not eliminate the need for training; human error is a major source of crypto misconfiguration. While frameworks help with compliance, they are not solely about regulation; they are about sound security engineering and lifecycle management. Therefore, the primary benefit is providing a structured approach to implementing encryption practices.

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.