Cryptography and Authentication

Common key cryptography, represented by AES, uses the same key for encryption and decryption, so it is fast and is used to encrypt communications or the body of files. The second choice describes public key cryptography. The third choice describes a hash function, which uses no key and so is not encryption. The fourth choice is also the key count for public key cryptography; common key cryptography instead needs n(n-1)/2 keys.

The number of keys needed for common key cryptography is n(n-1)/2, so 50 × 49 ÷ 2 = 1,225. 100 is the value of 2n for the same 50 people using public key cryptography instead. 2,450 is 50 × 49 left un-halved by mistake. 4,950 is the value of n(n-1)/2 for 100 people; all of these are wrong.

In public key cryptography, each person holds two keys, a public key and a private key, so the total is 2n = 2 × 50 = 100. 1,225 is the n(n-1)/2 value for common key cryptography. 50 mistakenly assumes one key per person. 2,500 is n squared; all of these are wrong. The advantage of public key cryptography is that the number of keys grows more slowly than with the common key approach as the number of people increases.

Hybrid cryptography encrypts the data body with the faster common key cryptography and delivers only that common key (the session key) encrypted with the recipient's public key, solving both the speed problem and the key-distribution problem at once. TLS uses this scheme. The first choice concerns hash functions, which are not encryption. It is not double encryption as in the third choice, nor does it process the entire body with public key cryptography as in the fourth choice.

Encryption to protect confidentiality is done with the recipient B's public key. Only B holds the matching private key, so only B can decrypt it. Transforming the data with A's private key is a digital signature, not encryption. A's public key can be obtained by anyone, so encrypting with it would let no one decrypt it and would not protect confidentiality. B's private key belongs only to B, so A cannot use it.

Because the recipient's public key was used to encrypt it, only the matching recipient's private key can decrypt it. The recipient's public key is the very key used for encryption and cannot reverse it. The sender's private key belongs only to the sender. The sender's public key is used to verify a digital signature, not to decrypt a confidential document.

Because even a slight change in input causes a large change in output, hash functions can be used to detect file tampering. The first choice contradicts one-wayness — recovery is not possible (which is why it is not encryption). The second choice is also wrong: regardless of input length, the output is a fixed length (256 bits for SHA-256, for instance). The fourth choice is also wrong; collision resistance, meaning it is hard to find different data with the same value, is a required property.

A salt is a random string that differs per user, added to a password before hashing, so the stored value differs even for the same password, making a precomputed rainbow table useless. The third choice is the purpose of stretching, which repeats the computation many thousands of times, a separate measure from salting. The first choice contradicts the one-wayness of hashing. The fourth choice describes an effect a salt does not have.

Full-disk encryption means the contents cannot be read without passing authentication at startup, making it effective against information leaks from loss or theft. The second choice is wrong: once logged in legitimately, data is decrypted and readable, so it does not counter malware. The third choice is the role of encrypting communications or individual files. The fourth choice is achieved through access control.

Obsolescence refers to cryptography becoming unsafe as computing power improves or weaknesses in an algorithm are discovered. Periodically reviewing the algorithm and key length and keeping the ability to migrate is the preparation, and this includes considering a move to post-quantum cryptography with quantum computers in mind. The first choice is about password practices, a separate matter from cryptographic obsolescence. The third choice undermines confidentiality the moment a plaintext copy is kept. The fourth choice is a dangerous case of leaving the risk unaddressed.

A digital signature is created by transforming a document's hash value with the sender's private key. Because only the sender holds that private key, it can demonstrate both that the sender created it and that it has not been altered. Using the recipient's public key is encryption for confidentiality, not signing. The recipient's private key belongs only to the recipient. The sender's public key is used to verify the signature and cannot be used to create it.

Because the signature was created with the sender's private key, it is verified with the matching sender's public key. The sender's private key belongs only to the sender and cannot be used by the recipient. The recipient's public key is the key the sender would use to encrypt for confidentiality, and the recipient's private key is used to decrypt a message addressed to the recipient; neither is used to verify a signature.

A signature is created with sender A's private key and verified with A's public key. Encryption is done with recipient B's public key and decrypted with B's private key. Only the third choice satisfies both of these directions. The other three either use the other party's private key (impossible, since only that person holds it) or encrypt with one's own public key (which no one could then decrypt) — in each case one of the directions is reversed, so it does not work.

What a digital signature reveals is tampering (integrity), that the sender is genuine, and non-repudiation. The body is still sent in plaintext, so it cannot prevent interception (confidentiality); hiding the content as well would require encrypting it with the recipient's public key. If the recipient altered the body, verification would fail, so they could not pass it off as the sender's. The signature, if anything, closes off the possibility of denial.

Because a MAC is produced from a private key shared between sender and recipient, the recipient could also produce the same value, so it cannot demonstrate to a third party that only the sender could have made it. It therefore cannot provide non-repudiation. It can detect tampering and confirm the other party shares the key, and it is lightweight to process. When non-repudiation is also needed, a digital signature, which uses a private key that only one person holds, is used instead.

A digital certificate is an electronic form of identification in which a certificate authority (CA) signs, with its own private key, a public key together with information about its owner, letting the recipient confirm that the public key really belongs to that party. A private key is something only its owner keeps under tight control, not something entrusted to a CA. Encrypting the communication itself is done by something like TLS, with the certificate used to confirm the other party's legitimacy. It offers no guarantee about the presence or absence of malware.

A root certificate sits at the top of the certificate chain: it is a self-signed certificate the CA issues to itself, pre-installed in an OS or browser, and it serves as the root of trust. This is exactly why installing a root certificate of unknown origin is dangerous — it can make a fake site be trusted as genuine. A certificate that identifies an individual is a user certificate. What might sound like a list of certificates is closer to a certificate revocation list (CRL), but a CRL lists certificates revoked before their expiry, not ones that have expired. No common key is involved.

A certificate can be revoked before its expiry date, for example due to a leaked private key or an employee leaving. A list of revoked certificates is the CRL (certificate revocation list), and a method for querying the status of one certificate at a time online is OCSP. SPF and DKIM verify an email's sending source, SAML and OAuth are standards for single sign-on or delegated authorization, and AES and RSA are cryptographic algorithms themselves; none of these is used to check revocation.

HTTPS encrypts communication with TLS, and the server certificate confirms the connection is to the server named in the certificate, making it more resistant to eavesdropping and tampering in transit. However, what the certificate shows is the other party's identity, not the adequacy of its information management, the safety of distributed files, or its financial standing. It is worth noting that phishing sites can use HTTPS too.

The difference among DV, OV, and EV lies in how strict the certificate authority's identity verification is. DV verifies only control over the domain name, OV also verifies that the organization genuinely exists, and EV involves an even more rigorous review. The type does not change the cryptographic algorithm or key length used, nor does it determine the validity period. Any fee difference is a result of the review effort involved; the essence of the difference is the review itself.

The three authentication factors are knowledge (something only the person knows), possession (something only the person has), and inherence (a characteristic of the person's own body). Possession corresponds to methods using a smartphone app, an IC card, or a hardware token. A password and a secret question are both knowledge, and fingerprint matching is inherence. Combining different factors makes it multi-factor authentication.

Multi-factor authentication combines two or more different factors among knowledge, possession, and inherence, and a password (knowledge) combined with an IC card (possession) fits this. A secret question, a second password, and a date of birth or employee number are all knowledge; splitting the check into two steps makes it two-step verification, but since it remains a single factor, it is not multi-factor authentication. This distinction is a frequent exam point.

Setting a stricter threshold makes it harder to accept an impostor, but it also makes it more likely to reject the genuine user. In other words, the false acceptance rate (FAR) falls while the false rejection rate (FRR) rises. Because the two sit in a trade-off relationship across the threshold, they never both fall or both rise together. In situations that prioritize safety, such as entry to a restricted area, the threshold is set to lower FAR even at the cost of inconveniencing the genuine user.

The EER is the error rate at the point where the false rejection rate (FRR) and false acceptance rate (FAR) become equal, and it serves as a benchmark for comparing devices' overall accuracy — a smaller value means higher accuracy. However, this does not mean the error rate reaches zero, so it cannot be said that the genuine user is never rejected or that the false acceptance rate is always zero. The EER is a measure of accuracy and has nothing to do with processing speed. In actual operation, the threshold is shifted depending on the intended use.

A one-time password is disposable and usable only once, so even if the value becomes known through eavesdropping or peeking, it cannot be reused. It is not meant to reduce the number of characters to memorize, and in most cases a dedicated app or token generates the value. It is also not a mechanism that prevents a device from becoming infected with malware or prevents an information leak from the authentication server itself. A similarly aimed approach is challenge-response authentication, which never sends the password itself over the communication path.

Ensuring sufficient length has the biggest effect on making a password hard to break, and stopping reuse is the countermeasure against credential-stuffing attacks. What cannot be memorized should be managed with a password manager. Reuse means a leak in one place spreads to every service, and displaying it on a sticky note invites someone to simply look at it. Sharing an ID makes it impossible to trace whose action something was, violating the basic principle of account management.

Risk-based authentication judges the level of danger from circumstances such as device, region, and time of access, and requests additional verification only when the situation is judged risky, curbing unauthorized login while keeping normal use convenient. Single sign-on is a mechanism that lets a single authentication grant access to multiple systems. Challenge-response authentication uses a different random value each time so the password itself is never sent over the network. CAPTCHA is a mechanism to distinguish a human from an automated program.

FIDO2 and passkeys work by returning a signature made with a private key kept on the user's own device. Because no shared secret is stored on the server side, a leak from the server cannot be abused, and because a signature is returned only to the legitimate site by design, it also resists phishing. It is not that the password is encrypted before being sent — a password is not used at all. The private key is held by the device, not centrally managed by the server.

Authentication confirms whether the party claiming an identity really is that person, and authorization decides what that confirmed person is permitted to do; authentication comes first and authorization follows. The first choice reverses the two, which is wrong. Being able to log in is not the same as being allowed to view every piece of information — drawing a line such as “HR information is for HR staff only” is the role of authorization. It is not a distinction determined by where something is implemented.

RBAC bundles the permissions needed for each job duty into a role and assigns people to roles, so a personnel transfer only requires reassigning the role, and a permissions review can also be done role by role. The first choice describes discretionary access control (DAC), and the second describes mandatory access control (MAC). The individual, file-by-file setup in the fourth choice does not use the concept of a role at all, so it is not RBAC, and it becomes unmanageable as the number of people grows.

The principle of least privilege means granting only the minimum rights necessary for the job and promptly removing them once no longer needed. The broader the rights, the greater the potential damage from an operating mistake or from internal fraud. Granting broader rights just in case, giving an entire department the same rights as a senior staff member, or defaulting to administrator rights when unsure are all cases of over-granted privilege and go against the principle.

Segregation of duties separates the person who applies for something from the person who approves it, so that splitting roles and permissions prevents fraud from being completed by one person alone and lets a mistake be caught by a second pair of eyes. In the situation described, this mutual check does not function. Workload, system response speed, and the burden of managing IDs are all matters of efficiency and do not explain the control problem.

A privileged account can do almost anything, so the principle is to use it only when needed and to record its checkout, return, and the work performed. Sharing the account makes it impossible to trace whose action something was. Working under it at all times means an operating mistake or a malware infection can cause damage on a much larger scale at once. Operation logs only function as a check when reviewed by someone other than the person who did the work, so the person's own review alone is not sufficient.

At the time of a transfer, the rights for the new department must always be granted at the same time the rights from the previous department are removed. Granting without removing lets rights pile up (residual privilege), a state that violates the principle of least privilege. Deferring the review or waiting for the employee to report a problem leaves unnecessary rights in place the entire time. In the same way, when an employee leaves, the account must be disabled without delay.

Zero trust does not assume “safe because it's internal”; it verifies every access, combining checks on the user and device, least privilege, encrypted communication, and continuous monitoring. The first choice is exactly the traditional assumption of trusting the inside of the perimeter. The third choice is a misunderstanding — it does not mean abandoning perimeter defense, but adding the assumption that the inside should not be trusted either. The fourth choice bans all external access entirely, a different idea from zero trust.