Introduction-to-Cryptography Exam Questions & Answers

When software is digitally signed, the organization computes a cryptographic hash (digest) of the software (or its manifest) and then signs that digest using the organization's private key. Verification works in the opposite direction: the customer (verifier) uses the organization's public key to validate the signature and recover/confirm the signed digest, then independently hashes the received software and compares the result. If the digests match and the signature validates under the public key, the customer has strong assurance that the software has not been altered since it was signed and that it was signed by the holder of the corresponding private key. The customer never needs the organization's private key---sharing it would destroy security and enable forgery. Likewise, the customer's own keys are irrelevant to verifying the publisher's signature. The organization's public key is typically delivered inside a certificate chain (code signing certificate) so the verifier can also validate publisher identity and trust. Therefore, the customer uses the organization's public key for signature verification (often described as ''decrypting'' the signed digest).

Symmetric cryptography generally provides the fastest encryption and decryption performance among common cryptographic operations. Algorithms like AES and ChaCha20 are designed for high throughput and efficient implementation in software and hardware (e.g., AES-NI acceleration). Symmetric decryption is computationally similar in cost to symmetric encryption, and both are far faster than asymmetric operations for equivalent security levels. Asymmetric cryptography (RSA, ECC) involves expensive mathematical operations (modular exponentiation or elliptic-curve scalar multiplication), making it much slower and unsuitable for bulk data decryption. That is why real-world secure protocols use asymmetric cryptography primarily to authenticate peers and establish keys, then switch to symmetric encryption for the actual data stream. Hashing is not decryption at all; it is one-way, and there is no ''decrypt'' operation for a hash. Padding is not a decryption mechanism; it is a formatting step used with block ciphers to align plaintext length. Therefore, the correct choice for the operation with the fastest decryption process is symmetric cryptography.

SHA-1 (Secure Hash Algorithm 1) produces a fixed-size output of 160 bits (20 bytes). Hash output size matters in cryptography because it influences collision resistance and the effort required for various attacks. For an ideal n-bit hash, finding a collision by generic means is expected around 2^(n/2) operations (birthday bound). With SHA-1's 160-bit output, that generic bound would be about 2^80, which was once considered strong; however, SHA-1 has been broken in practice with significantly less work due to cryptanalytic advances, and it is now deprecated for most security uses. Still, the question is strictly about output length, not current suitability. The other options do not match SHA-1: 40 bits would be far too small for a modern hash, 80 bits is not SHA-1's output, and 320 bits would imply a much larger digest (closer to SHA-256's 256 bits or SHA-384's 384 bits). Therefore, the correct SHA-1 output length is 160 bits.

Bit-flipping exploits target encryption modes or protocols that do not provide strong integrity, allowing attackers to modify ciphertext so that predictable changes occur in plaintext after decryption. To defend against this, protocols add an integrity mechanism that detects tampering. In WPA (including enterprise deployments), TKIP introduced a Message Integrity Check (MIC) called ''Michael.'' The MIC is computed over the frame contents (with additional fields) and verified by the receiver; if an attacker flips bits in transit, the MIC verification fails, and the frame is rejected. While AES (used by WPA2's CCMP) also provides integrity via authenticated encryption, the option presented that directly names the tamper-detection mechanism associated with guarding against bit-flipping is MIC. A pre-shared key is an authentication/keying method (and not enterprise-mode anyway), and a ''global encryption key'' would be the opposite of what you want---global/static keys worsen security. Therefore, the intended mechanism that mitigates bit-flipping by detecting unauthorized modifications is the Message Integrity Check.

One-way client authentication is the method where the client (customer) proves its identity to the server (web service). In cryptographic terms, this is commonly implemented through client credentials such as client TLS certificates (mTLS from the server's perspective) or through authentication protocols layered over TLS (for example, signed tokens), but the defining direction is that the client is the party being authenticated. In a strict TLS certificate-authentication framing, client authentication occurs when the server requests a client certificate during the handshake and the client demonstrates possession of the corresponding private key (via signature in handshake messages). The server then validates the client certificate chain and authorization policy. One-way server authentication, by contrast, authenticates only the server to the client and does not identify the customer. Mutual authentication authenticates both sides simultaneously; while it includes client authentication, it is broader than what the question asks. ''End-to-end authentication'' describes assurance between endpoints across intermediaries, but it is not the specific ''customer authenticates to service'' method in certificate-based terminology. Therefore, the best answer is one-way client authentication.