AP Subject A 19: Symmetric Keys, Public Keys, Hashes, Digital Signatures, and PKI

2026 exam basis · Revised/source-checked 2026-10-21

Learning index

1. Official scope 2. Security goals 3. Key-use matrix 4. Hash/MAC/signature 5. Hybrid encryption 6. PKI validation 7. Envelope trace 8. Exam traps 9. Quick sheet and review 10. Questions

1. Official scope and terms

This installment maps exactly to IPA Ver.7.2, Major Category 3 / Middle Category 11 Security. 1. 情報セキュリティ > (1) 情報セキュリティの目的と考え方 is on PDF 53 / printed 49. 1 > (8) 情報セキュリティに関する技術 > ① 暗号技術 begins on PDF 54 / printed 50 and continues on PDF 55 / printed 51; ② 認証技術 and ⑤ 公開鍵基盤 are on PDF 55 / printed 51. Detailed user authentication, MFA/biometrics, authorization, and access control are deferred to AP20.

KO	JA	EN
기밀성	機密性	confidentiality
무결성	完全性	integrity
진정성	真正性	authenticity
대칭키(공통키) 암호	共通鍵暗号	symmetric-key cryptography
공개 키 / 개인 키	公開鍵／秘密鍵	public key / private key
해시 / 메시지 인증 코드	ハッシュ／メッセージ認証コード	hash / MAC
전자서명(디지털 서명)	デジタル署名	digital signature
인증 기관 / 신뢰 앵커	認証局／トラストアンカー	CA / trust anchor

2. Security goals

• Confidentiality prevents unauthorized reading. Integrity detects unauthorized alteration. Authenticity supports a claim that data or an entity has the stated origin/identity.
• Availability means usable when needed. It belongs to the broader security goals, but cryptography alone does not provide it.
• Encryption alone does not necessarily provide integrity or authenticity. Authenticated encryption can provide confidentiality plus integrity and data-origin assurance under shared-key assumptions.

3. Choose the right key

All identities are synthetic.

Goal	Sender/creator operation	Recipient/verifier operation	Key fact
Symmetric confidentiality, Alice→Bob	encrypt with shared secret K	decrypt with the same secret K	both share one secret
Public-key confidentiality, Alice→Bob	encrypt/wrap for Bob with Bob’s public key	decrypt/unwrap with Bob’s private key	recipient’s key pair
Alice’s digital signature	sign with Alice’s private/signing key	verify with Alice’s public/verification key	signer’s key pair
CA certificate signature	CA signs with CA private key	relying party verifies with issuer CA public key	issuer’s key pair

Never turn the last two rows into “private-key encryption.” Modern signature schemes define signature-generation and verification algorithms, often over a digest, with required encoding and/or randomization rules. A signature does not encrypt the message.

4. Hash, MAC, and digital signature

Mechanism	Key	What it supports	Important limit
Cryptographic hash	none	fixed-length digest; change detection when a trusted digest exists	anyone can recompute it, so a bare hash cannot authenticate the source
MAC/HMAC	shared secret	integrity and shared-key data-origin authentication	every key holder can generate it; it cannot distinguish which holder created it and does not provide non-repudiation
Digital signature	private signing key; public verification key	integrity and authenticity	non-repudiation needs evidence about identity, exclusive key control, time, and policy; the signature itself does not encrypt

Hash properties in scope include one-way/preimage resistance, second-preimage resistance, and collision resistance. SHA-256/SHA-3 are hash examples; HMAC combines a cryptographic hash with a secret key. AES is a symmetric block cipher, not a hash or signature algorithm.

5. Hybrid encryption

For a large file, Alice generates a random symmetric content-encryption key CEK, uses an appropriate authenticated-encryption construction to protect the bulk data efficiently, and—under a simple key-transport design—wraps the CEK with Bob’s public key. Bob uses Bob’s private key to recover the CEK, then decrypts and authenticates the data. Public-key processing protects the small key; symmetric cryptography handles the bulk.

This is an exam-level key-transport example, not a claim that every protocol literally encrypts a session key. Real protocols may use authenticated key agreement to derive shared secrets.

6. Certificate and PKI validation

A certificate is a public object that binds a subject/name to a public key under an issuer’s claims and policy. It is neither secret nor the payload cipher.

For service.example, trace the presented leaf/server certificate → intermediate CA certificate(s) → configured trusted root/trust anchor. A relying party must, as applicable:

1. build a candidate certification path and verify each issuer signature;
2. match the requested name/identity, such as service.example;
3. check each certificate’s validity period at the validation time;
4. enforce basic constraints and path-length constraints;
5. enforce key usage and extended key usage for the intended purpose;
6. apply revocation policy using CRL and/or OCSP.

The trust anchor is trusted by local configuration or policy. It is not trustworthy merely because its root certificate is self-signed, and path validation does not treat the anchor as an ordinary certificate proved by its own signature. Failure to obtain revocation information is not proof of good status; policy decides whether the result is soft-fail, hard-fail, or otherwise handled.

7. Worked envelope and PKI trace

Alice sends Bob a signed, confidential package:

1. Alice hashes document M and runs the signature-generation algorithm with Alice’s signing private key, producing S. Alice packages M and S.
2. Alice generates random CEK and authenticated-encrypts that package, producing ciphertext plus authentication data.
3. In this simple key-transport example, Alice wraps CEK with Bob’s public key and sends the wrapped key plus protected package.
4. Bob uses Bob’s private key to unwrap CEK, then authenticated-decrypts the package. A failed authentication check means reject it.
5. Bob obtains Alice’s certificate and validates its chain to a locally configured trust anchor: signatures, Alice’s claimed identity, time, constraints, usages, and policy-required CRL/OCSP status.
6. Bob uses the validated Alice public key to verify S over M. This checks signature integrity/authenticity; a non-repudiation conclusion additionally needs key-control, identity, time, and policy evidence.

Key separation is visible: Bob’s pair serves recipient confidentiality, Alice’s pair serves signing, and CA keys certify public-key bindings.

8. Exam traps

• For confidentiality use the recipient’s public key; for a signature use the signer’s private key.
• A bare hash is not source authentication; encryption is not automatically integrity protection.
• A MAC is not publicly verifiable and does not identify one holder among parties sharing the key.
• A signature authenticates signed data; it does not hide it and is not generically “private-key encryption.”
• A certificate binds identity/name and public key; it does not encrypt application payloads.
• Self-signature alone does not create trust. Revocation lookup failure does not mean “good.”

9. Quick sheet, self-check, and 1/3/7-day review

• Quick sheet: symmetric: K/K; confidentiality: Bob public → Bob private; signature: Alice private → Alice public; certificate: CA private → CA public; hash=no key, MAC=shared key, signature=private/public.
• Self-check: Can you reproduce the four-row key table, explain why encryption and integrity differ, compare hash/MAC/signature, describe hybrid encryption, and list every path-validation check?
• Day 1: redraw the key matrix and envelope. Day 3: reproduce the PKI chain and six checks without notes. Day 7: retake all questions and explain every distractor.

10. Five original four-choice questions

Q1

Alice must send confidential data so only Bob can recover it using public-key encryption. Which key direction is correct? A. Alice’s public → Alice’s private. B. Bob’s public → Bob’s private. C. Alice’s private → Bob’s public. D. CA private → root public.

Answer: B (2, イ). A targets Alice, not Bob. B uses the recipient Bob’s public key for encryption and Bob’s private key for recovery. C confuses signing and unrelated keys. D describes neither payload confidentiality nor Bob’s pair.

Q2

Which comparison is correct? A. A bare hash authenticates its creator. B. HMAC lets a verifier prove which one of several shared-key holders generated it. C. A signature uses a signing private key and public verification key; HMAC uses a shared secret, while a bare hash is unkeyed. D. A digital signature encrypts the message for secrecy.

Answer: C (3, ウ). A ignores that anyone can hash. B ignores that every shared-key holder can generate the MAC. C correctly separates all three. D confuses authenticity/integrity with confidentiality.

Q3

Which hybrid-encryption description is correct? A. Use a random symmetric content key for bulk data and, in a simple key-transport design, protect that key with the recipient’s public key. B. Hashing the content alone makes it secret. C. Encrypt all bulk data with a CA private key. D. Every real protocol must literally encrypt a session key.

Answer: A (1, ア). A gives the efficient hybrid pattern. B provides no confidentiality. C confuses CA signing with content encryption. D ignores authenticated key-agreement designs that derive secrets.

Q4

Which is the sound validation procedure for service.example? A. Trust the leaf whenever it is unexpired. B. Trust a root solely because it self-signs. C. If OCSP cannot be reached, treat the certificate as proven good. D. Build leaf→intermediate(s)→configured trust anchor; check issuer signatures, name, time, constraints, usages, and policy-required revocation status.

Answer: D (4, エ). A omits identity, chain, constraints, usages, and revocation policy. B confuses self-signing with configured trust. C turns unknown into good. D states the necessary validation trace.

Q5

Which statement best describes a signature and non-repudiation? A. A valid signature always proves the human personally acted, regardless of key theft or policy. B. It supports integrity/authenticity, but non-repudiation also requires evidence about identity, key control, time, and policy. C. It necessarily hides the message. D. Any shared-key MAC uniquely proves which key holder generated it.

Answer: B (2, イ). A overclaims what key use proves. B states the conditional evidentiary requirement. C confuses signature with encryption. D ignores that all shared-key holders can generate the MAC.

Answer key: [2, 3, 1, 4, 2] = [イ, ウ, ア, エ, イ]

Official sources and notices

First-party sources, checked 2026-10-21: IPA syllabus Ver.7.2, NIST FIPS 197 AES, FIPS 180-4 SHS, FIPS 198-1 HMAC, FIPS 186-5 DSS, SP 800-57 Part 1 Rev.5, SP 800-56B Rev.2, RFC 5280, and RFC 6960, RFC 9525, and NIST SP 800-38D.

This independently written study guide is not affiliated with IPA, NIST, or IETF. It uses no past questions or third-party commentary and gives no pass guarantee.