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

AES by itself is a symmetric block cipher that provides confidentiality, but not guaranteed integrity unless used in an authenticated mode. To protect integrity of the plaintext (ensuring it has not been altered), a Message Authentication Code (MAC) can be applied. In the classic Encrypt-then-MAC pattern, the sender encrypts the plaintext with AES and then computes a MAC (often HMAC-SHA-256 or CMAC-AES) over the ciphertext (and relevant headers). The receiver verifies the MAC before attempting decryption, preventing tampering and many padding-oracle style vulnerabilities. Alternatively, AES can be used in an AEAD mode like AES-GCM, which produces an authentication tag serving a similar purpose, but among the listed options the general integrity mechanism is “MAC.” RC4 is an unrelated stream cipher and does not provide integrity. RSA is asymmetric and not the standard integrity add-on for AES-encrypted bulk data. Kerberos is an authentication protocol and key distribution system, not a message integrity primitive. Therefore, to protect plaintext integrity when using AES, the correct mechanism is a Message Authentication Code.

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.

Lightweight cryptography refers to cryptographic primitives and profiles engineered for environments where computational resources are constrained—limited CPU, memory, power, bandwidth, and code size—while still requiring robust security. Typical targets include IoT sensors, embedded controllers, smart cards, RFID, wearables, and many mobile or edge deployments. The design goals emphasize efficiency (low energy consumption, small silicon area for hardware, small firmware footprint) and practical performance under constraints, often while providing modern security properties like authenticated encryption (confidentiality + integrity) and secure hashing. Lightweight cryptography is not simply “stronger encryption”; it balances security with implementability in constrained systems. It is also not restricted to military settings and is not inherently outdated—many lightweight designs are modern and motivated by the rapid growth of IoT and pervasive computing. Because constrained devices are common entry points for attackers, having secure primitives that fit those devices is a critical part of contemporary security architecture. Therefore, the best description is cryptographic algorithms designed for resource-constrained environments.

ISO/IEC 27001 is an international standard for establishing, implementing, maintaining, and continually improving an Information Security Management System (ISMS). Its focus is not inventing cryptographic algorithms, but managing information security through a structured governance approach: identifying assets, assessing risks, selecting and implementing controls, measuring effectiveness, and continuously improving. The standard emphasizes a risk-based methodology—controls are chosen based on organizational context and threat landscape, and the ISMS is refined over time through audits, management reviews, and corrective actions. While cryptography can be part of the control set (e.g., encryption policies, key management, secure communications), ISO/IEC 27001 addresses a broad range of security domains beyond crypto, including physical security, access control, incident management, supplier relationships, and business continuity. It also does not enforce criminal penalties; it is a certification/management standard. And it is not limited to network security. Therefore, the correct focus is risk management and continuous improvement of information security.

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.

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.

HMAC (Hash-based Message Authentication Code) is a standard mechanism used to verify both integrity and authenticity of a message when two parties share a secret key. It combines a cryptographic hash function (such as SHA-256) with a secret key in a structured way that resists common attacks on naïve keyed-hash constructions. The sender computes an HMAC tag over the message and transmits the message plus tag. The receiver recomputes the HMAC using the same shared secret key and compares the result; if the tag matches, the receiver can be confident the message was not modified in transit and that it came from someone who knows the shared key. AES is an encryption algorithm primarily providing confidentiality; it can provide integrity only when used in authenticated modes (e.g., GCM) but “AES” alone is not the integrity component. An IV helps randomize encryption but does not validate integrity. TKIP is a legacy WLAN protocol component, not the general integrity verifier. Therefore, the correct component for verifying message integrity among the options is HMAC.

In the TLS handshake, the ClientHello message is the client’s opening negotiation message and includes the client’s supported cryptographic capabilities. A key part of ClientHello is the offered cipher suites list, which advertises combinations of key exchange, authentication, encryption, and integrity/AEAD algorithms the client is willing to use. The server responds with ServerHello, selecting one of the offered cipher suites (in TLS 1.2 and earlier) and confirming protocol parameters. Forward secrecy is a property achieved by using ephemeral key exchange (e.g., (EC)DHE), not a specific message that “sends a list.” “Integrity check” is a security goal/mechanism, not the negotiation step. While TLS 1.3 changes the structure of negotiation (cipher suite list still appears in ClientHello but only covers AEAD and hash; key exchange is negotiated via extensions), the fundamental idea remains: the client proposes supported cipher suites in ClientHello, and the server picks compatible parameters. Therefore, the process that sends the list of supported cipher suites is the ClientHello.

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.

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.

Asymmetric encryption (also called public key cryptography) uses a pair of mathematically related keys: a public key and a private key. One key is used to encrypt, and the other is used to decrypt, which is the defining “different keys” property asked in the question. In the common confidentiality use case, a sender encrypts a message using the recipient’s public key, and only the recipient can decrypt it using their private key. This solves the key distribution problem inherent in symmetric encryption, where both parties must securely share the same secret key in advance. Asymmetric systems also enable digital signatures: the private key signs (creates a signature) and the public key verifies it, providing authenticity and integrity. Symmetric encryption, by contrast, uses the same shared key for both encryption and decryption (even though internal round keys may exist, it is still one shared secret). “Private key” alone is not a full encryption type, and “secure” is a generic description rather than a cryptographic category. Therefore, the correct answer is D. Asymmetric.

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.

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.

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.

Skipjack is a symmetric block cipher historically associated with the Clipper chip initiative. Its defining parameters match the question: it operates on 64-bit blocks and uses an 80-bit key. The other options do not fit those exact sizes. Twofish is a 128-bit block cipher with key sizes up to 256 bits. Blowfish is a 64-bit block cipher, but its key size is variable from 32 up to 448 bits and is not fixed at 80 bits as a defining property. Camellia is a 128-bit block cipher with key sizes of 128, 192, or 256 bits. Skipjack’s smaller key size and legacy design make it unsuitable for modern security needs, but the question is purely about identifying the algorithm that matches an 80-bit key and 64-bit blocks. Therefore, the correct answer is Skipjack.

WPA with TKIP was designed as an interim improvement over WEP while still using the RC4 stream cipher for compatibility with legacy hardware. TKIP addresses WEP’s major weaknesses by introducing per-packet key mixing, a message integrity mechanism (“Michael”), and replay protection. In TKIP, the encryption key used with RC4 is 128 bits. Practically, TKIP derives a per-packet RC4 key from a 128-bit temporal key (TK), the transmitter’s MAC address, and a sequence counter (TKIP Sequence Counter, TSC) to avoid the simple IV reuse patterns that made WEP easy to break. Even with these improvements, TKIP has known weaknesses and is deprecated in favor of WPA2/WPA3 using AES-based CCMP/GCMP. But strictly for the question asked, TKIP’s RC4 keying material is based on a 128-bit key size, not 40/56-bit legacy sizes and not 256-bit.

Lightweight cryptography is designed for constrained environments—devices with limited CPU, memory, storage, bandwidth, and power (battery). Examples include IoT sensors, smart locks, RFID tags, embedded controllers, and industrial devices. Administrators choose lightweight algorithms and protocols to maintain reasonable security while fitting strict resource budgets and real-time constraints. The goal is not “weaker security because data is unimportant,” but rather efficient security that can still meet threat models under constraints. Option B captures this: embedded systems often cannot afford the computational cost of heavy cryptographic primitives (large key sizes, complex modes, frequent handshakes) or may struggle with latency and energy consumption. Option A is irrelevant because physical security of a desktop doesn’t remove the need for cryptography in communications or storage. Option C is the opposite of lightweight design. Option D is a poor justification; security design should be based on risk, and lightweight cryptography is not merely for “minimal protection,” but for practical deployability under constraints. Therefore, the correct reason is limited resources on embedded systems.

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.

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.

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.

For protecting credit card data, the primary compliance framework is PCI DSS (Payment Card Industry Data Security Standard). PCI DSS is an industry standard created by major card brands and administered through the PCI Security Standards Council. It sets requirements for organizations that store, process, or transmit cardholder data, including controls around network security, access control, monitoring, and cryptography. PCI DSS explicitly addresses encryption and protection of cardholder data (for example, protecting stored cardholder data and encrypting transmission over open, public networks, and using strong cryptography and secure protocols). CCPA and GDPR are privacy regulations focused on personal data rights and governance, and while they may encourage security measures, they are not specifically the card-industry security standard for payment data. HIPAA applies to protected health information, not payment card data. Therefore, the correct answer is PCI DSS.

Symmetric encryption alone typically provides confidentiality, but it does not automatically provide integrity. Many encryption modes (especially older ones like CBC without authentication) are malleable, meaning an attacker may be able to modify ciphertext and cause predictable changes in plaintext after decryption. To add integrity, systems commonly combine symmetric encryption with a cryptographic hash-based integrity mechanism, such as a hash function used in an HMAC (Hash-based Message Authentication Code) or a dedicated authenticated-encryption mode like GCM that internally uses authentication tags. Among the given options, a hash function is the fundamental additional element that enables integrity checks: it allows construction of a MAC (e.g., HMAC-SHA-256) that the receiver verifies to detect any tampering. An initialization vector and a nonce value are used to ensure uniqueness and randomness properties for encryption but do not, by themselves, guarantee integrity. An encoding algorithm changes representation, not security. Therefore, the correct additional input element for implementing integrity alongside symmetric encryption is a hash function, typically as part of an HMAC or similar MAC construction.

NIST’s lightweight cryptography effort targets environments like IoT and embedded systems where CPU, memory, energy, and bandwidth are constrained, yet strong security is still required. Ascon is an authenticated encryption with associated data (AEAD) family designed to be efficient in both hardware and software with small footprint, making it well-suited for constrained devices. NIST selected Ascon because it offers a strong security design with good performance and implementability under tight resource budgets, while providing modern protections (confidentiality + integrity) through AEAD. That aligns with option C: secure and efficient encryption for resource-constrained devices. The selection was not primarily about authenticating users (that is typically handled by protocols and identity systems, not an AEAD primitive). It was also not mainly about legacy compatibility; lightweight cryptography aims at new and constrained deployments rather than preserving outdated stacks. And while Ascon can certainly be used to protect data at rest, that is only one application; the core reason for the choice is its suitability for constrained environments and robust, efficient authenticated encryption.

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.