Pass the WGU Courses and Certificates Introduction-to-Cryptography Questions and answers with CertsForce

The Enigma machine is historically known as an electro-mechanical cipher device used primarily by Nazi Germany to secure military and diplomatic communications during World War II. It implemented a polyalphabetic substitution through a system of rotors, a reflector, and a plugboard, producing a large number of possible daily key settings. Operators would configure rotor order, ring settings, initial positions, and plugboard swaps, then type messages to generate ciphertext. Enigma’s operational security depended heavily on correct procedures and secrecy of keys; weaknesses in procedures and design properties, combined with brilliant cryptanalysis and engineering efforts by Allied codebreakers (notably at Bletchley Park), enabled large-scale decryption of Enigma-encrypted traffic. In cryptography history, Enigma represents the transition from manual ciphers to machine-assisted encryption and demonstrates how both mathematics and operational practices determine real-world security. It is not simply an “algorithm” in the modern software sense, and it is not a decryption method or email encryption tool. Therefore, the correct description is that it was a device used for secure communication during WWII.

In a PKI environment, a digital certificate is the standard credential used to bind an identity (user, device, service) to a public key, with that binding vouched for by a Certificate Authority. For device authentication, the device typically proves possession of the private key corresponding to the certificate’s public key (for example, during a TLS handshake). As a second factor in a two-factor model, a certificate (often stored in a TPM, smart card, or secure enclave) represents “something you have”—a cryptographic credential anchored to hardware or a managed endpoint. The other listed options (symmetric encryption, asymmetric encryption, digital signature) are cryptographic operations or algorithm classes, not stand-alone authentication factors. A digital signature is a mechanism used within authentication flows, but it is not itself the credential that establishes an enrolled device identity within PKI. In practice, a certificate-based device factor is commonly paired with a knowledge factor (password/PIN) or a biometric factor to achieve true 2FA, but among these choices, the appropriate second form of authentication in PKI terms is the digital certificate.

A polyalphabetic substitution cipher uses multiple substitution alphabets rather than a single fixed mapping. The classic cipher that uses a keyword to select shifting alphabets across the message is the Vigenère cipher. In Vigenère, each plaintext letter is shifted by an amount determined by the corresponding key letter (repeating the keyword as needed). For example, a keyword like “YELLOW” is aligned under the plaintext; each key character defines a Caesar shift (A=0, B=1, …) applied to the plaintext character, producing ciphertext. This rotation of alphabets across positions makes Vigenère more resistant to simple frequency analysis than monoalphabetic substitution, because the same plaintext letter may encrypt to different ciphertext letters depending on its position relative to the key. The Pigpen cipher is a symbol substitution cipher, Caesar is monoalphabetic with a single shift, and Playfair is a digraph substitution cipher using a 5×5 key square, not the repeating-key polyalphabetic method described. Therefore, the correct cipher is Vigenère.

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.

A cryptographic policy defines how encryption, keys, certificates, and integrity mechanisms are used and managed across an organization. During incident response, that policy becomes a playbook for making safe, consistent decisions under pressure. It can specify how to rotate or revoke compromised keys, how to validate and reissue certificates, how to preserve evidence integrity with hashing, and how to securely communicate sensitive incident details (e.g., using approved encrypted channels). It can also define backup encryption requirements and key escrow or recovery procedures, enabling secure data recovery without exposing protected data. Policies typically outline roles and responsibilities (who can access keys, who can approve rekeying), logging requirements, and escalation steps—reducing confusion and preventing ad hoc crypto changes that might worsen exposure. The goal is not to limit encryption; it is to ensure cryptography is used correctly to contain and remediate incidents. Therefore, providing guidelines for secure recovery and communication is the correct contribution of cryptographic policy to incident response.

RC4 is unique among the RC family listed because it is a stream cipher. It generates a pseudorandom keystream and encrypts data by XORing that keystream with plaintext bytes (and decryption is the same XOR operation). This differs from RC5 and RC6, which are block ciphers: they encrypt fixed-size blocks of data through multiple rounds of operations (such as modular addition, XOR, and rotations) using a secret key. The stream-cipher design means RC4 historically fit protocols where data arrives continuously (e.g., early wireless and web encryption) and where simple, fast software implementation was desired. However, stream ciphers demand careful handling of nonces/IVs to avoid keystream reuse; reuse can catastrophically leak plaintext relationships. RC4 also has well-documented statistical biases in its keystream, leading to practical attacks in protocols like WEP and later concerns in TLS, which is why RC4 has been deprecated in modern security standards. Still, from a classification standpoint, “stream” is the distinguishing characteristic versus RC5/RC6 being block ciphers.

In classic WEP deployments, RC4 was used with what is commonly called “40-bit WEP” (also labeled “64-bit WEP” because it combines a 40-bit secret key with a 24-bit IV to form a 64-bit RC4 seed). The key attribute emphasized in many foundational descriptions of WEP is this 40-bit shared secret length, which was originally chosen due to export restrictions and legacy constraints. Although “104-bit WEP” (sometimes called “128-bit WEP,” again counting the 24-bit IV) also existed, the option set here points to the historically standard and widely referenced attribute: a 40-bit key when RC4 is used in WEP. Importantly, WEP’s security failure is not only about key size; the 24-bit IV is too small and repeats frequently, and WEP’s key scheduling vulnerabilities combined with IV reuse allow attackers to recover the secret key with enough captured frames. Still, among the given options, the correct attribute is the 40-bit key.

TLS is the modern successor to SSL. SSL (notably SSL 2.0 and SSL 3.0) was an early protocol family for securing network communications, providing encryption, integrity, and endpoint authentication for applications like HTTPS. Over time, weaknesses were discovered in SSL’s design and in the cryptographic mechanisms commonly used with it. TLS was introduced as an improved, standardized evolution (starting with TLS 1.0, based on SSL 3.0 but with important fixes), and later versions (TLS 1.2 and TLS 1.3) significantly strengthened security by removing weak ciphers, improving key exchange, and tightening handshake and record protections. In practice, when people say “SSL” today, they often mean “TLS,” but true SSL is deprecated and should not be used. SSL is not a replacement of TLS, and the two are not identical in security—TLS versions incorporate substantial improvements and modern cryptographic best practices. SSL is also not limited to email; it was widely used for web traffic and other protocols. Therefore, the correct relationship is that TLS replaced SSL to provide improved security.

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.

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.