WGU Introduction-to-Cryptography - WGU Introduction to Cryptography HNO1

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.

HIPAA is a U.S. regulation focused on protecting the privacy and security of protected health information (PHI). In relation to encryption, HIPAA’s Security Rule requires covered entities and business associates to implement appropriate administrative, physical, and technical safeguards to ensure the confidentiality, integrity, and availability of electronic PHI. Encryption is widely recognized as a key technical safeguard for confidentiality—protecting PHI in transit (e.g., over networks) and at rest (e.g., on storage devices) by making data unreadable without the proper keys. HIPAA does not standardize encryption across all industries, nor does it prohibit electronic health records; it regulates how they must be protected. While HIPAA often uses the term “addressable” for encryption controls (meaning organizations must implement it if reasonable and appropriate, or document an equivalent alternative), the overarching purpose remains protection of patient information through secure measures, with encryption as a central mechanism. Therefore, the best answer is ensuring confidentiality of patient information through secure measures like encryption.

CTR mode turns a block cipher (like AES) into a stream-like construction by generating a keystream from successive encryptions of a changing input block. Specifically, CTR forms input blocks using a nonce (unique per message) combined with an increasing counter. Each nonce||counter block is encrypted with the block cipher under the shared key, producing a pseudorandom output block. That output is then XORed with plaintext to yield ciphertext (and XORed with ciphertext to recover plaintext). This design enables parallelization (blocks can be generated independently), efficient random access decryption, and avoids chaining dependencies seen in modes like CBC. Option B describes CFB-like behavior; option C describes ECB; option D describes CBC. CTR’s security critically depends on never reusing the same nonce/counter sequence with the same key, because reuse would repeat keystream blocks and expose plaintext relationships. Therefore, the correct description is that CTR converts the block cipher into a stream cipher using a counter value and a nonce.

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.

Lightweight cryptography is important because many modern systems operate in constrained environments—IoT sensors, embedded controllers, wearables, and mobile devices—where CPU, memory, storage, bandwidth, and battery power are limited. Traditional “heavy” cryptographic suites may be too slow, too energy-intensive, or too large in code footprint for these platforms, leading to insecure workarounds or disabling security entirely. Lightweight cryptographic primitives and profiles are designed to deliver strong security properties (confidentiality and integrity, often via AEAD) while fitting within tight resource budgets and real-time constraints. This is essential as IoT and mobile ecosystems expand, increasing the attack surface and the consequences of compromised devices (botnets, surveillance, physical safety risks). Lightweight cryptography is not meant to “limit encryption tools” or complicate protection; it enables practical, deployable security where otherwise implementations might be weak or absent. High-speed network communication can benefit from efficient crypto too, but the defining modern driver is constrained-device security. Therefore, the correct reason is addressing the security needs of IoT devices and mobile applications.

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.

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.

Data integrity means ensuring that information has not been modified without authorization. Digital signatures are a core cryptographic technique that provides integrity by binding a message (typically its hash) to the signer’s private key. The signer creates a signature over the message digest; the verifier checks it with the signer’s public key and recomputes the digest. Any change to the message alters the digest and causes verification to fail, revealing tampering. Digital signatures also support authenticity (verifying the signer) and can contribute to nonrepudiation under proper key-management and policy controls, but integrity is a primary guarantee they deliver. “Authentication” is broader and can be achieved by other means, but it is not as directly tied to integrity as signatures in this option set. “Non-repudiation” is an outcome/goal rather than a standalone integrity technique. “Steganography” hides the existence of data and does not inherently protect integrity. Therefore, among these options, digital signatures are the best cryptographic technique for ensuring data integrity.

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.

Large-scale quantum computers threaten many widely deployed public-key algorithms because quantum algorithms can solve their underlying hard math problems efficiently. In particular, Shor’s algorithm can factor large integers and compute discrete logarithms in polynomial time, which directly breaks the security assumptions of RSA (factoring) and traditional Diffie–Hellman/ECC (discrete log). That makes RSA the clearest target among the options. By comparison, symmetric algorithms like AES are affected mainly by Grover’s algorithm, which provides a quadratic speedup for brute force; this can be mitigated by using larger keys (e.g., AES-256). Hash functions like SHA-256 also face Grover-style speedups for preimage search, again mitigated by output length/security margin, and collision resistance is impacted differently. ECB is a mode of operation, not a standalone algorithm, and its issues are classical (pattern leakage), not specifically quantum. Therefore, the algorithm most directly threatened by quantum computing among the choices is RSA.