Introduction-to-Cryptography Exam Dumps - WGU Courses and Certificates Questions and Answers

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.

Digital signatures provide integrity, authenticity, and typically non-repudiation by using an asymmetric key pair. The signer uses the private key to create a signature over a message (usually over a hash/digest of the message). Because the private key is kept secret, only the legitimate signer should be able to produce a valid signature. Anyone who has the corresponding public key can then validate the signature: they verify that the signature matches the message digest under the public key and that the signed data has not been altered. This is why the public key can be widely distributed (often inside an X.509 certificate) while the private key must be protected by the signer. If a public key were used to sign, anyone could forge signatures; if a private key were required for validation, only the signer could validate, defeating the purpose of public verifiability. Therefore, the correct key roles are private key for signing and public key for signature validation.

The value 51 mod 11 is the remainder after dividing 51 by 11. Modular arithmetic is widely used in cryptography to keep computations within a finite set of residues, such as in RSA where values are taken modulo n, or in Diffie–Hellman where exponents and group elements are reduced modulo a prime. To compute 51 mod 11, find the largest multiple of 11 less than or equal to 51. Multiples of 11 are 11, 22, 33, 44, 55. The closest without exceeding 51 is 44. Subtracting gives 51 − 44 = 7, so the remainder is 7. Therefore, 51 mod 11 = 7, matching option “07.” This remainder is always in the range 0 through 10 because the modulus is 11. Such residue computations underpin the “wraparound” behavior that makes modular exponentiation and inverse computations well-defined in cryptographic groups.

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.

The “Issued” stage in a certificate lifecycle indicates that the certificate has been generated and signed by the issuing CA and is now valid for use (subject to validity dates, policy constraints, and revocation status). At this point, the operational focus shifts from creating the certificate to making it available to the subject and relying parties. “Distribution” is the lifecycle activity most directly associated with an issued certificate: installing it on servers or endpoints, provisioning it into keystores, publishing it to directories if required, and ensuring the chain (intermediates) is accessible for validation. By contrast, “Creation” is earlier in the process (key generation, CSR creation, identity validation, issuance/signing). “Key recovery” and “key archiving” relate to private key management and escrow policies (often for encryption keys, not signing keys), and are governed by organizational policy and key management systems rather than the certificate’s issued state itself. A certificate can be distributed after issuance regardless of whether any key escrow features exist. Therefore, the operation that fits the certificate’s “Issued” stage best is distribution of the issued credential for operational use.

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

In AES, the number of rounds is explicitly tied to the key length. AES-128 uses 10 rounds, AES-192 uses 12 rounds, and AES-256 uses 14 rounds. The purpose of additional rounds is to increase diffusion and confusion, strengthening resistance against cryptanalysis as the key schedule and state transformations iterate more times. Although key length primarily affects brute-force resistance, AES’s designers and standardization parameters link longer keys with more rounds to maintain security margins across variants, especially considering differences in the key schedule structure. Thus, as key length increases from 128 to 192 to 256 bits, the number of rounds increases correspondingly from 10 to 12 to 14. This relationship is fixed by the AES specification and does not vary dynamically at runtime. Therefore, the correct correlation is that the number of rounds increases as the key length increases.

3DES (Triple DES) is a symmetric block cipher that retains DES’s 64-bit block size while increasing effective security by applying DES multiple times. The common “two-key 3DES” variant uses two independent 56-bit DES keys (K1 and K2) in an Encrypt–Decrypt–Encrypt (EDE) sequence: Encrypt with K1, Decrypt with K2, then Encrypt again with K1. Because each DES key is 56 bits (ignoring parity bits), the total keying material is 112 bits. This matches the question’s “112-bit key size and 64-bit block size.” Plain DES uses only a 56-bit effective key and a 64-bit block size, so it does not match the 112-bit key size. AES has a 128-bit block size and key sizes of 128/192/256. IDEA uses a 64-bit block size but has a 128-bit key. Therefore, the correct algorithm is 3DES. Although 3DES improved on DES, it is now considered legacy due to its small 64-bit block size (birthday-bound issues for large data volumes) and performance overhead compared to AES.

AES (Advanced Encryption Standard) is a symmetric block cipher standardized to operate on a fixed 128-bit block size and supports key sizes of 128, 192, and 256 bits. When the key size is 256 bits, the cipher is commonly referred to as AES-256, but the block size remains 128 bits regardless of key length. This combination (256-bit key, 128-bit block) matches the question precisely. By comparison, DES uses a 64-bit block size with a 56-bit effective key. 3DES also uses a 64-bit block size and effectively applies DES three times, yielding an effective key length typically cited as 112 bits (two-key 3DES) or 168 bits (three-key 3DES), depending on how keys are configured. IDEA uses a 64-bit block size with a 128-bit key. Therefore, the only listed algorithm that supports a 256-bit key while maintaining a 128-bit block size is AES. This is one reason AES is widely adopted for modern symmetric encryption: strong key sizes with efficient implementation and broad standardization.

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.