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

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.

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.

In a public key infrastructure, trust in a certificate ultimately depends on the relying party’s trust anchor set—typically the root CA certificates preinstalled in a customer’s browser/OS trust store. For customers to accept the company’s certificate as legitimate, the buyer (customer) must trust the root CA public key (or an intermediate chained to it) so they can validate the certificate chain and signatures. The seller (the company) also must trust and rely on the root CA public key to build and present a valid chain and to make operational decisions based on that CA’s issuance and revocation mechanisms; practically, the seller selects a CA whose root is widely trusted by customers. The cloud provider’s trust is not what makes the certificate valid to customers; the provider may terminate TLS or pass traffic through, but customer validation is based on the chain to a trusted root. Government agencies like the FTC are not part of the cryptographic trust path for TLS certificate validation. Therefore, among the given options, the correct pairing is the seller and the buyer, reflecting both the issuer selection/usage by the company and the relying-party validation by customers.

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.

OTP systems (such as HOTP and TOTP) generate a sequence of passwords using a shared secret and a moving factor (counter or time). The critical secret that underpins the ability to compute past or future OTP values is the seed (also called the shared secret key). In HOTP, the seed is used with an HMAC function and an incrementing counter; in TOTP, the seed is used with HMAC and a time-step value. If an attacker obtains the seed and knows the algorithm and moving factor, they can compute future OTPs. The “function” and “encryption algorithm” are typically standardized and public; security relies on keeping the seed secret. An initialization vector is not a standard OTP component in HOTP/TOTP generation. Therefore, the component needed to predict future OTP values is the seed. Protecting the seed is essential: it should be stored securely (e.g., hardware token secure storage) and transmitted only through controlled provisioning processes. If compromised, OTP becomes predictable and no longer serves as a strong second factor.

AES supports three standardized key sizes: 128, 192, and 256 bits, with a fixed block size of 128 bits. The maximum of these supported key sizes is 256 bits (AES-256). Key size affects resistance to brute-force key search: larger keys exponentially increase the search space. In practice, AES-128 is already considered strong against brute force with contemporary computing capabilities, while AES-256 is often chosen for compliance requirements, conservative security margins, or to hedge against future advances. AES-512 is not part of the AES standard; if 512-bit keys are desired, systems typically use different constructions (like using AES-256 in certain key-derivation or wrapping schemes) rather than changing AES itself. Therefore, the correct maximum supported AES key size is 256 bits.

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.

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.

WEP (Wired Equivalent Privacy) uses the RC4 stream cipher and combines a per-packet Initialization Vector (IV) with a shared secret key to form the RC4 seed for that packet’s keystream. The IV in WEP is 24 bits long and is transmitted in the clear as part of the 802.11 frame so the receiver can reconstruct the same per-packet RC4 key stream. The short IV space (2²⁴ possible values) is a major design weakness: on a busy network, IVs repeat frequently, causing keystream reuse. Because RC4 is a stream cipher, keystream reuse enables attackers to derive relationships between plaintexts and recover keys with statistical attacks (notably the Fluhrer, Mantin, and Shamir (FMS) family of attacks and related improvements). WEP also uses a CRC-32 integrity check (ICV) that is not cryptographically strong and is vulnerable to modification attacks. The 24-bit IV length is therefore a key reason WEP is considered insecure and has been replaced by WPA/WPA2 mechanisms that use stronger key mixing, larger nonces/IVs, and robust integrity protection.

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.

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.

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.

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.

IPsec’s initial key exchange is commonly performed using IKE (Internet Key Exchange), which negotiates Security Associations (SAs), authenticates peers, and establishes shared keys for ESP/AH protection. The traditional and default transport for IKEv1 and IKEv2 is UDP port 500. During negotiation, peers exchange proposals (crypto suites), perform Diffie–Hellman to derive key material, and authenticate using pre-shared keys, certificates, or EAP methods. If a firewall blocks UDP 500, the IKE negotiation cannot begin, preventing IPsec tunnels from forming. In many real deployments, NAT traversal is also used; in that case, traffic typically shifts to UDP 4500 (NAT-T) after detection of NAT, but UDP 500 is still required for the initial exchange and NAT detection in many configurations. TCP 500 is not standard for IKE. Port 443 is associated with HTTPS/TLS and some SSL VPNs, not IPsec IKE. Therefore, among the options provided, the firewall must allow UDP 500 for IPsec key exchange to succeed.

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.