Free Practice Questions for the WGU Courses and Certificates Introduction-to-Cryptography Exam (2026 Updated)

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.

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.

The expression 23 mod 6 asks for the remainder when 23 is divided by 6. Modular arithmetic is foundational in cryptography, especially in public-key systems (RSA, Diffie–Hellman, ECC) where operations occur in finite rings or fields. To compute 23 mod 6, identify the largest multiple of 6 that does not exceed 23. Multiples of 6 are 6, 12, 18, 24. Since 24 is greater than 23, the largest valid multiple is 18. Subtract: 23 − 18 = 5, so the remainder is 5. Therefore, 23 mod 6 = 5, which corresponds to option “05.” Modular reduction keeps numbers within a fixed range (0 to modulus−1), enabling stable arithmetic under wraparound behavior. In cryptographic protocols, this wraparound property is essential for defining groups and ensuring operations remain bounded and consistent.

For Bitcoin, transactions are confirmed by inclusion in blocks, and the network targets an average block interval of about 10 minutes. That means transactions are “added” to the Bitcoin blockchain approximately every 10 minutes in the sense that a new block containing a batch of transactions is appended at that cadence. The 10-minute target is achieved by a difficulty adjustment mechanism that recalibrates mining difficulty roughly every 2016 blocks, aiming to keep the average interval stable despite changes in total network hash power. It is important to note that this is an average: blocks can be found faster or slower in the short term due to the probabilistic nature of proof-of-work mining. Other blockchains have different block times (seconds to minutes), but the question’s options and typical curriculum context align with Bitcoin’s 10-minute design. Therefore, the correct choice is approximately every 10 minutes.

The Caesar cipher is the classic substitution cipher that encrypts by shifting letters of the alphabet by a fixed number of positions (e.g., shift by 3: A→D, B→E, etc.). It is a monoalphabetic cipher because a single shift value is applied uniformly across the entire message, making it simple and vulnerable to frequency analysis and brute force (only 25 meaningful shifts in the Latin alphabet). Vigenère also involves shifting, but it uses a repeating keyword to vary the shift per character (polyalphabetic), whereas the question’s phrasing typically points to the fundamental “shift cipher,” which is Caesar. SHA-1 is a cryptographic hash function, not a cipher. Bifid is a fractionation cipher combining Polybius square coordinates and transposition, not a direct shifting method. Therefore, the cipher that uses shifting letters of the alphabet for encryption is the Caesar cipher.

Lattice-based cryptography refers to cryptographic constructions whose security is based on the computational hardness of problems on mathematical lattices (regular grids of points in high-dimensional space). Examples of hard lattice problems include the Shortest Vector Problem (SVP) and Closest Vector Problem (CVP), and practical schemes often use related problems like Learning With Errors (LWE) or Ring-LWE. These problems are believed to remain hard even for quantum computers, making lattice-based cryptography a major candidate family for post-quantum cryptography. Lattice schemes can support encryption, digital signatures, and key exchange, often with strong security reductions (worst-case to average-case) and efficient implementations. The word “lattice” here is not about simple point encoding; it’s about relying on geometric/algebraic structures and noise-based hardness assumptions. It is also unrelated to blockchain “options.” While many lattice schemes do involve modular arithmetic internally, what defines the category is the underlying lattice hardness assumptions, not modular arithmetic alone. Therefore, the correct definition is a cryptographic scheme based on geometric lattices.

The NOBUS (Nobody But Us) principle is a controversial security notion suggesting that it is possible to introduce or maintain an access capability (often framed as a “backdoor” or exploitable weakness) that is effectively usable only by the party that designed it—typically a government or specific organization—while remaining infeasible for everyone else to exploit. In practice, NOBUS is invoked in debates about lawful access, surveillance, and exceptional access mechanisms: proponents claim that sophisticated entities can keep exploitation techniques secret and complex enough that adversaries cannot replicate them. Critics argue that this assumption is fragile because vulnerabilities can be independently discovered, reverse engineered, leaked, or eventually exploited as tools and knowledge spread. Moreover, once a weakness exists, it becomes a systemic risk: software and cryptographic systems are widely deployed and adversaries can invest heavily in finding and weaponizing the same flaw. Modern security engineering generally favors eliminating known weaknesses rather than relying on secrecy or assumed asymmetry of capability. Therefore, the best description of NOBUS is that a vulnerability is believed to be so difficult to exploit that only its creator can exploit it.

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.

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.

Auditing improves cryptographic practice by systematically evaluating whether cryptographic controls are correctly selected, implemented, configured, and maintained. Through audits, an organization can discover weak algorithms (e.g., deprecated hashes), improper key lengths, unsafe modes (e.g., unauthenticated CBC), missing integrity controls, poor certificate validation, and operational problems such as key reuse, weak randomness sources, inadequate rotation, or overly permissive access to key material. Audits also assess compliance with internal policy and external standards, ensuring crypto is used consistently across systems and that exceptions are documented and risk-managed. Importantly, auditing does not guarantee that incidents will never happen; it reduces risk by finding gaps before attackers do. It also does not eliminate the need for updates—audits often reveal that policies must evolve as threats and best practices change. Employee training can be recommended as an outcome of auditing, but audits do not automatically ensure training. Thus, the most accurate benefit is that auditing identifies weaknesses and drives corrective action, strengthening cryptographic posture over time.

3DES (Triple DES) applies the DES block cipher three times to increase effective security, and its commonly cited valid key sizes correspond to how many independent DES keys are used. Two-key 3DES uses two 56-bit DES keys (K1 and K2) in an EDE sequence (Encrypt with K1, Decrypt with K2, Encrypt with K1), yielding 112 bits of keying material (ignoring parity bits). Three-key 3DES uses three independent 56-bit keys for a total of 168 bits of keying material, but that option is not listed here. A 56-bit key corresponds to single DES, not 3DES. 128-bit is associated with AES, not 3DES. 2,048-bit is typical for RSA keys, not symmetric ciphers. Therefore, among the choices provided, 112-bit is a valid 3DES key size. While 3DES is now deprecated for many uses due to its 64-bit block size and performance limitations, understanding its keying options remains important for legacy system assessment.

Modular arithmetic is the mathematics of working with remainders after division by a fixed number called the modulus. In cryptography, it underpins many core constructions because it defines arithmetic in finite sets (rings and fields) where values “wrap around,” enabling stable, repeatable operations with bounded results. Public-key systems like RSA rely on modular exponentiation (raising integers to powers modulo a composite number), while Diffie–Hellman and many elliptic-curve schemes operate in groups defined by modular arithmetic properties. Encryption and key exchange use modular operations because they allow efficient computation forward (e.g., exponentiation modulo a large number) while making certain inverse problems computationally hard without secret information (e.g., factoring or discrete logarithms). Modular reduction also helps keep intermediate values manageable and supports group properties needed for proofs of security. Although modular arithmetic is not “encryption by itself,” it is a foundational method used inside encryption algorithms and protocols. Therefore, among the options, describing it as a method used for encryption via modular operations best matches cryptographic usage.

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.

Bitcoin’s supply is controlled by protocol rules enforced by consensus: new bitcoins enter circulation through the block subsidy awarded to miners for producing valid blocks. This subsidy is programmed to halve at fixed intervals (every 210,000 blocks), which steadily reduces the rate of new coin creation over time and asymptotically approaches a capped total supply (commonly cited as 21 million BTC). This mechanism is often called the halving schedule and is the primary way limits are managed. The number of participants is not fixed; anyone can run a node or mine. There is no per-country cap and no per-person maximum enforced by the protocol—addresses and ownership are not limited that way. The supply cap emerges from the decreasing issuance schedule combined with consensus validation rules that reject blocks creating coins beyond what the schedule allows. Therefore, the correct answer is that limits are managed because rewards for mining reduce over time.

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.

CBC mode introduces chaining between blocks to prevent the pattern leakage inherent in ECB. In CBC, each plaintext block is XORed with the previous ciphertext block before being encrypted with the block cipher. For the first block, CBC uses an Initialization Vector (IV) to serve as the “previous ciphertext” input. This makes encryption of each block dependent on the previous block’s ciphertext, which is exactly the defining characteristic described in option A. CBC does not generate a continuous stream of key material—that describes stream ciphers or stream-like modes such as CTR/OFB. CBC also does not require a different key per operation; the same symmetric key is reused, while the IV must be fresh/unpredictable to ensure semantic security. The block size is determined by the underlying block cipher (e.g., AES is 128-bit blocks, DES/3DES are 64-bit blocks), not a fixed 32-bit size for CBC itself. Because CBC is not inherently authenticated, best practice is to pair it with a MAC (Encrypt-then-MAC) or use an AEAD mode instead.

802.1X is a port-based network access control framework that enables centralized authentication using an authentication server (commonly RADIUS). EAP (Extensible Authentication Protocol) runs within 802.1X to support many credential types (password-based methods like PEAP, certificate-based methods like EAP-TLS, and others). WPA-Enterprise is the wireless security mode that explicitly uses 802.1X + EAP with an authentication server to perform per-user/per-device authentication and to derive dynamic session keys. By contrast, WPA-PSK uses a pre-shared key without an external authentication server; all users share the same PSK, which is weaker for enterprise identity management. WEP is an older mechanism using static keys and does not provide modern 802.1X/EAP enterprise authentication in the WPA-Enterprise sense. TKIP is an encryption/integrity protocol used under WPA, not the full authentication “standard” involving an authentication server. Therefore, the correct choice is WPA-Enterprise.

ECB is the simplest block cipher mode: each plaintext block is encrypted independently using the same key and the block cipher primitive. There is no IV and no chaining, so identical plaintext blocks produce identical ciphertext blocks. This property leaks patterns and structure in the plaintext, which is why ECB is generally considered insecure for most real-world data beyond tiny, random-looking inputs. For example, images encrypted with ECB often reveal outlines because repeated pixel blocks map to repeated ciphertext blocks. Option A describes CTR mode, option C describes CBC mode, and option B resembles feedback-based modes. ECB’s independence also means it can be parallelized, but the pattern leakage is a severe weakness. Modern practice prefers authenticated encryption modes (like GCM) or, at minimum, modes with IVs and chaining (like CBC with proper padding and MAC). Therefore, the correct statement is that ECB encrypts each block with the same key and each block is independent of the others.

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 string format $2a$08$... is a well-known identifier for the bcrypt password hashing scheme. In common password-hash notation, the prefix indicates the algorithm and parameters: “$2a$” denotes bcrypt (version 2a), and “08” indicates the cost factor (work factor) controlling how computationally expensive hashing is. bcrypt is designed specifically for password storage: it includes a built-in salt and is intentionally slow and adaptive, making brute-force and GPU attacks far more expensive than fast general-purpose hashes like MD5 or SHA-512. NTLM and MD5 are obsolete for secure password storage due to speed and known weaknesses. SHA-512, while cryptographically strong as a hash, is still too fast for password hashing unless used in a dedicated password-hashing construction (e.g., PBKDF2, scrypt, Argon2) with appropriate parameters and salts. Since the given hash clearly matches bcrypt’s encoding, the correct algorithm is bcrypt, which incorporates salting and cost-based key stretching as part of its design.

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.

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

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.

Nonrepudiation aims to prevent a party from later denying having performed an action, such as sending a message, approving a transaction, or signing a document. In cryptographic systems, nonrepudiation is typically supported by digital signatures, audit logs, and trusted time-stamping: if a message is signed with a private key and verified with the corresponding public key (often bound to an identity via a certificate), the signer can be held accountable for that signed content. This creates evidence that can be used for dispute resolution, compliance, and legal or contractual enforcement. Nonrepudiation is distinct from confidentiality (keeping data secret) and from access control (preventing unauthorized use). While authentication (verifying identity) is related and often a prerequisite, the defining goal is accountability—ensuring that actions can be attributed to entities in a way that is difficult to dispute later. Effective nonrepudiation also depends on secure private key management, certificate validation, and procedures that show the key was under the signer’s control at the time. Therefore, the correct answer is holding parties accountable for their actions and transactions.