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.

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.

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.

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.

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.