Introduction-to-Cryptography Exam Dumps - WGU Courses and Certificates Questions and Answers

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.

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.

A cryptography framework provides a consistent, repeatable way to select, deploy, and manage cryptographic controls across an organization. Its key benefit is structure: it defines approved algorithms and key sizes, acceptable modes of operation, key management rules (generation, storage, rotation, revocation, backup), certificate handling, and secure protocol configurations (e.g., TLS settings). This reduces ad hoc implementations that often lead to vulnerabilities such as weak ciphers, key reuse, improper randomness, or missing integrity protections. A framework also clarifies roles and processes—who can access keys, how secrets are audited, and how exceptions are handled—improving governance and operational reliability. Importantly, it does not guarantee perfect security; no framework can eliminate all risk, and secure outcomes still depend on correct implementation, monitoring, and maintenance. It also does not eliminate the need for training; human error is a major source of crypto misconfiguration. While frameworks help with compliance, they are not solely about regulation; they are about sound security engineering and lifecycle management. Therefore, the primary benefit is providing a structured approach to implementing encryption practices.

Asymmetric encryption is defined by using a key pair: a public key that can be shared widely and a private key that remains secret to its owner. The keys are mathematically related so that data encrypted with one key can be decrypted with the other (in confidentiality use cases, encryption with the recipient’s public key and decryption with the recipient’s private key). This design solves key distribution challenges: anyone can encrypt to a recipient without first sharing a secret key securely. It also enables digital signatures, where the private key signs and the public key verifies—supporting authenticity and integrity. Option B describes symmetric cryptography, not asymmetric. Option C is not a defining property; both symmetric and asymmetric algorithms can involve rounds or repeated operations. Option D is incorrect because asymmetric encryption is reversible for the intended holder of the private key; “irreversible” describes hashing, not encryption. Therefore, the characteristic feature of asymmetric encryption is the use of both a public and private key.

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.

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.

In the classical definition, a stream cipher encrypts data in very small units—often described as one bit at a time—by combining plaintext with a keystream (commonly via XOR). While many practical stream ciphers operate on bytes or words for efficiency, the conceptual distinction compared to block ciphers is that stream encryption processes data as a continuous stream rather than fixed-size blocks. This is why the standard teaching answer is “1 bit” per application of the keystream. Block ciphers, by contrast, encrypt blocks like 64 bits (DES/3DES) or 128 bits (AES) in each invocation of the block primitive. Options like 40, 192, and 256 are not typical stream cipher “per-step” processing sizes; 40 and 256 are often associated with key sizes, and 192 could be a key size for AES, not an encryption granularity. The essential security requirement for stream ciphers is that the keystream must be unpredictable and never reused with the same key/nonce combination; otherwise XOR properties allow attackers to recover relationships between plaintexts. Thus, the best answer is 1.