Day 53: Information Security Basics – From Encryption to Digital Certificates and PKI

Date: 2026‑08‑11<br/>Stage: Phase 3 – Database, Security & Reliability (second pass)<br/>Learning time: 45 minutes<br/>Goal: Distinguish symmetric encryption, asymmetric encryption, message digest, digital signature and digital certificate, and explain how they form a practical secure communication scheme.

1. Problem to Solve Today

Day 38 covered security architecture (what to protect, who can do what, and response when a defense line fails). Day 53 dives into the most confusing cryptographic techniques.

2. Reference Materials

Red Book 6.2 Data Encryption: symmetric vs. asymmetric algorithms, domestic commercial ciphers.

Red Book 6.3 Authentication: hash, digital signature, digital certificate and PKI.

Official tutorial 4.4 Information Encryption: cryptographic communication model and symmetric/asymmetric encryption.

Official tutorial 4.5 Public‑key certificates and key management: public‑key distribution, certificates and session keys.

Official tutorial 4.6.2 Digital signatures: signing conditions, public‑key signatures and message digests.

3. Security Goals

3.1 CIA Triad

Confidentiality : prevent unauthorized reading of data.

Integrity : prevent or detect unauthorized modification of data.

Availability : ensure authorized users can access data when needed.

Electronic prescription example:

Prescription viewed by a passerby → confidentiality failure.

Dosage altered → integrity failure.

Hospital system down, cannot issue prescription → availability failure.

3.2 Additional Goals

Authentication : confirm the identity of the communicator.

Non‑repudiation : after an action occurs, participants cannot easily deny it.

Digital signatures primarily support integrity, source authentication and non‑repudiation, but true non‑repudiation also requires a trustworthy private key, a valid certificate at signing time, no key leakage, and supporting audit evidence.

4. Four Basic Cryptographic Terms

Plaintext : original readable data.

Ciphertext : encrypted data that cannot be directly understood.

Algorithm : the rule that performs encryption, decryption or signing.

Key : the critical parameter that controls the algorithm’s output.

Basic process:

Plaintext + Encryption Algorithm + Encryption Key → Ciphertext
Ciphertext + Decryption Algorithm + Decryption Key → Plaintext

Algorithms may be public; the key must be strictly protected.

If the key leaks, even the strongest algorithm cannot save the system.

5. Symmetric Encryption – Same Secret Key for Locking and Unlocking

English term: Symmetric Encryption.

Basic structure:

Sender: Plaintext + shared key K → Ciphertext
Receiver: Ciphertext + same key K → Plaintext

5.1 Why “symmetric”?

Both parties use the same secret key or keys that can be directly derived from each other.

Analogy: the hospital and the pharmacy each hold the same safe‑box key; the hospital locks, the pharmacy unlocks.

5.2 Advantages

High computational speed.

Suitable for encrypting large amounts of data.

Relatively low resource consumption.

Ideal for files, disks, databases and network sessions.

5.3 The biggest challenge – key distribution

If the hospital sent the shared key together with the ciphertext, an eavesdropper could decrypt the prescription.

Solutions include:

Pre‑secure distribution.

Key Distribution Center (KDC).

Protect the session key with asymmetric encryption.

Secure protocol negotiation.

5.4 Scalability problem

For n users, each pair needs an independent shared key: n × (n‑1) ÷ 2.

Example: 100 users → 100 × 99 ÷ 2 = 4 950 shared keys.

This shows that while symmetric encryption is fast, maintaining shared keys for many participants becomes impractical.

5.5 Common Algorithms

AES – symmetric block cipher, internationally common, supports 128/192/256‑bit keys.

SM4 – domestic commercial block cipher, 128‑bit key and block.

DES – 56‑bit effective key, no longer suitable for modern security.

3DES – triple DES, slower, mainly a historical exam point.

Why DES/3DES still appear in exams but are not recommended for new systems:

DES key space is 2⁵⁶, vulnerable to exhaustive search; NIST revoked DES in 2005.

3DES improves security by multiple DES rounds but suffers from slower speed, 64‑bit block limitation, and gradual deprecation; NIST revoked 3DES/TDEA recommendations in 2024.

Conclusion for exam takers: know the structure and historical role of DES/3DES, but choose AES or SM4 for any new design.

6. Asymmetric Encryption – A Pair of Different but Related Keys

English terms: Asymmetric Encryption, Public‑Key Cryptography.

Each entity owns a key pair:

Public Key : can be published.

Private Key : must be kept secret by its owner.

6.1 Confidential communication

Hospital wants to send a session key to the pharmacy securely:

Hospital obtains pharmacy’s public key → encrypts session key with that public key → pharmacy decrypts with its private key.

This protects confidentiality but does not prove who created the session key.

6.2 Digital signatures

Hospital proves the prescription originates from itself:

Hospital signs the hash of the prescription with its private key → pharmacy verifies the signature with the hospital’s public key.

6.3 Comparison of purposes

Confidential transmission: encrypt with receiver’s public key, decrypt with receiver’s private key.

Digital signature: sign with sender’s private key, verify with sender’s public key.

6.4 Advantages and costs

Public key can be freely distributed, simplifying key delivery.

Enables digital signatures.

Allows secure exchange of symmetric session keys.

Computation is generally slower than symmetric encryption.

Not suitable for directly encrypting large business data.

Requires management of public‑key ownership (certificates) and secure private‑key storage.

6.5 Common Algorithms

RSA – supports encryption, key exchange and digital signatures.

ECC – elliptic‑curve public‑key cryptography, provides high security with short keys.

6.6 SM2, SM3, SM4 Relationship

SM2, SM3 and SM4 belong to China’s commercial cryptography suite but are different algorithm families:

SM2 – asymmetric public‑key algorithm (similar role to RSA/ECC).

SM3 – hash (message‑digest) algorithm.

SM4 – symmetric block cipher.

7. Message Digest (Hash)

Common names: Hash, Message Digest.

Basic process:

Arbitrary‑length data → Hash function → Fixed‑length digest

Example with the electronic prescription:

Prescription plaintext → Hash → Digest A
Received prescription → Hash → Digest B

If the digests differ, the content must have changed.

7.1 Four Core Properties

Fixed length – output size is determined by the algorithm.

One‑way – easy to compute from input, hard to reverse.

Avalanche effect – a tiny change in input causes a large change in output.

Collision resistance – it should be difficult to find two different inputs that produce the same digest.

7.2 Hash is not encryption

Encryption: Plaintext → Ciphertext → use key to recover plaintext. Hash: Plaintext → Digest; the digest cannot be “decrypted” back to the original data.

Encryption emphasizes reversible confidentiality; hash emphasizes one‑way fingerprinting.

7.3 Why a plain hash alone cannot stop intentional forgery

An attacker could replace both the file and its hash; the receiver would recompute the hash and still see a match. To prevent deliberate tampering, a digital signature or a keyed MAC (e.g., HMAC) is required.

7.4 Common Algorithms

SHA‑256, SHA‑384, … (SHA‑2 family).

SM3 – domestic hash algorithm.

MD5, SHA‑1 – historical, no longer suitable for security‑sensitive designs.

8. Password Storage – Why Not Just a Plain Hash

Storing a raw hash of a password allows attackers to use pre‑computed tables (rainbow tables) and to crack many accounts with the same password.

Secure approach adds a random salt and a computationally expensive Key‑Derivation Function (KDF) with a cost factor.

8.1 Salt

Random data generated per password. Example:

User A: password=123456, salt=A8F2 → result=KDF(123456, A8F2, cost)=xxxxx
User B: password=123456, salt=K9M1 → result=KDF(123456, K9M1, cost)=yyyyy

Even though the passwords are identical, the stored results differ.

8.2 KDF (Key‑Derivation Function)

KDF = Key Derivation Function. It transforms the password, salt and cost factor into a secure verification value.

Typical KDFs: PBKDF2, scrypt, bcrypt, Argon2id.

8.3 Registration flow

User enters password → system generates random salt → KDF(password, salt, cost) → store salt, cost, and derived result.

8.4 Login flow

User enters password → system reads stored salt & cost → KDF(password, salt, cost) → constant‑time compare with stored result.

If they match, the password is correct.

8.5 Security rationale

Salt prevents identical passwords from yielding identical stored values and defeats pre‑computed hash attacks.

KDF raises the computational cost of each guess, slowing brute‑force attacks.

NIST SP 800‑63B mandates salted, high‑cost password hashing for credential storage.

9. Digital Signature – Sign the Digest, Not the Whole File

Process:

Prescription plaintext → Hash → Digest → Hospital private‑key signs Digest → Digital signature.

Hospital sends: encrypted prescription, digital signature, and its digital certificate.

9.1 Why the certificate is needed

The certificate is a CA‑signed digital identity that binds the hospital’s public key to its name. It contains:

Hospital name / domain.

Hospital public key.

Serial number, validity period, usage constraints.

Issuer CA and CA’s signature.

The private key never appears in the certificate.

9.2 Verification steps at the pharmacy

1. Verify CA signature and certificate chain.
2. Check certificate validity period and revocation status (CRL/OCSP).
3. Ensure certificate subject matches the expected hospital.
4. Extract hospital public key.
5. Compute hash of received prescription.
6. Verify digital signature with hospital public key.
7. If all checks pass, the prescription is authentic, unmodified, and the hospital cannot later deny having signed it.

9.3 What a signature does NOT provide

Confidentiality – the prescription may still be readable.

Therefore encryption is still required for secrecy.

9.4 Clarifying the “private‑key encrypts digest” simplification

That wording is a pedagogical shortcut for RSA‑based signatures. Modern schemes (RSA‑PSS, ECDSA, SM2) use dedicated signing algorithms; verification does not simply “decrypt” the signature to obtain the digest.

10. Digital Certificate – Proving Which Public Key Belongs to Whom

Certificate fields include identity, public key, issuer, serial number, validity period, usage extensions, and the issuer’s signature.

CA (Certificate Authority) validates the applicant’s identity, writes the data into a certificate, and signs it with its own private key.

Relying parties use the CA’s public key to verify the signature, confirming that the certificate is authentic and untampered.

Certificate chains (root → intermediate → entity) allow trust to be anchored in pre‑installed root CAs.

Beyond signature verification, parties must also check expiration, revocation (CRL or OCSP), intended usage, and hostname/subject matching.

11. PKI – Public‑Key Infrastructure

PKI is not a single algorithm or a single server; it is a set of components that together manage public‑key trust over time.

CA : issues and revokes certificates.

RA (Registration Authority): validates applicant identity before CA issuance.

Certificate Repository : stores and publishes certificates and CRLs.

CRL/OCSP : provides revocation status.

Certificate Holders : entities that own and use certificates.

Relying Parties : systems that verify certificates (browsers, pharmacy systems, etc.).

Policies & Audits : define identity verification, key protection, issuance, revocation, and accountability procedures.

Certificate lifecycle:

Key‑pair generation → CSR submission → RA identity verification → CA issues certificate → Publication & use → Renewal/rotation → Expiration or revocation → Archival & destruction.

PKI solves the problem of binding public keys to identities at scale and maintaining that trust over the long term.

12. Hybrid Encryption (Digital Envelope)

Typical workflow:

1. Hospital generates a random symmetric session key Kₛ.
2. Encrypt prescription with Kₛ using AES/SM4 → ciphertext.
3. Encrypt Kₛ with pharmacy’s public key → encrypted Kₛ.
4. Send: ciphertext + encrypted Kₛ.
5. Pharmacy decrypts Kₛ with its private key, then decrypts the prescription with Kₛ.

This combines the speed of symmetric encryption for bulk data with the secure key distribution of asymmetric encryption.

Hybrid encryption provides confidentiality; digital signatures (added separately) provide integrity, authentication and non‑repudiation.

HTTPS/TLS follows the same principle: certificates authenticate the server, asymmetric mechanisms establish a shared secret, and symmetric ciphers protect the bulk of HTTP traffic.

13. End‑to‑End E‑Prescription Case Study

Requirements:

Confidentiality → symmetric encryption + protected session key.

Integrity → hash + digital signature.

Source authentication & non‑repudiation → hospital’s private‑key signature and certificate.

Certificate status verification → chain validation, expiration, CRL/OCSP.

Performance for large files → hybrid encryption.

Full workflow (nine steps):

1. Hospital generates random symmetric key Kₛ.
2. Encrypts the prescription with Kₛ (AES/SM4) → ciphertext.
3. Encrypts Kₛ with pharmacy’s public key.
4. Computes hash of the original prescription and signs it with hospital’s private key.
5. Sends ciphertext, encrypted Kₛ, digital signature, and hospital’s certificate.
6. Pharmacy validates the certificate chain, expiration and revocation, obtaining a trusted hospital public key.
7. Pharmacy decrypts Kₛ with its private key, then decrypts the prescription.
8. Pharmacy recomputes the hash of the decrypted prescription and verifies the digital signature.
9. Pharmacy records timestamp, certificate serial number, verification result and audit log.

14. Key Management – The Real Difficulty

Key lifecycle stages:

Secure generation.

Distribution or negotiation.

Isolated storage.

Authorized use.

Periodic rotation.

Backup and recovery.

Revocation after leakage.

Expiration and destruction.

Full‑trace audit.

Common measures:

Use cryptographically secure random generators.

Never embed private keys in source code or plain configuration files.

Leverage KMS (Key Management Service) or HSM (Hardware Security Module) for centralized protection.

Apply least‑privilege access controls to key‑using accounts.

Separate key storage from business data.

Define rotation, renewal, and emergency response procedures.

Regularly audit unused, soon‑to‑expire or over‑privileged keys.

Key leakage, weak randomness, expired or revoked certificates, or uncontrolled permissions can render even the strongest algorithms ineffective.

15. Common Exam Traps

Hash can be decrypted – false; hash is one‑way.

Digital signature provides confidentiality – false; it only guarantees integrity and origin.

Certificate stores the private key – false; it stores only the public key and identity information.

Use receiver’s private key to encrypt – false; receiver’s public key encrypts, private key decrypts.

Sender signs with receiver’s private key – false; sender signs with its own private key.

Public key alone proves identity – false; a trusted certificate is required.

Valid CA signature means no further checks – false; still need chain, subject, validity, usage and revocation checks.

All‑asymmetric encryption is safest – false; it is computationally expensive for large data, so hybrid encryption is preferred.

MD5 and SHA‑1 are safe for new systems – false; they are deprecated, replace with SHA‑2, SHA‑3 or SM3.

16. Three‑Minute Recap for Others

Symmetric vs. asymmetric: same secret key vs. public‑/private‑key pair.

Confidential transmission uses the receiver’s public key for encryption, receiver’s private key for decryption.

Digital signatures use the sender’s private key for signing, sender’s public key for verification.

Hash functions produce fixed‑length, one‑way fingerprints; they are not encryption.

Signatures sign only the hash to keep the operation efficient.

Signatures do not hide content; encryption is still needed for secrecy.

Certificates bind a public key to an identity, issued and signed by a CA.

CA, certificate chain and revocation mechanisms (CRL/OCSP) ensure trust.

PKI is the whole ecosystem (CA, RA, repository, policies, audits) that manages certificates over time.

Secure e‑prescription combines symmetric encryption, asymmetric key exchange, digital signature and certificate validation.

17. Self‑Test Questions and Answers

Symmetric encryption uses a shared secret key, is fast, and is suited for bulk data; asymmetric uses a public/private pair, is slower, and enables key exchange and signatures.

Encrypt with the pharmacy’s public key; the pharmacy decrypts with its private key.

Hospital signs with its private key; pharmacy verifies with the hospital’s public key.

Hash properties: fixed length, one‑way, avalanche effect, collision resistance. It is not encryption because it cannot be reversed to recover the original data.

Because an attacker can replace both the file and its plain hash, the receiver would still see matching digests. A digital signature or keyed MAC is needed for authentic verification.

Digital signatures provide integrity, source authentication and non‑repudiation, but not confidentiality.

Certificates do not contain the private key; they store identity, public key, validity period, issuer and CA signature, solving the problem of trustworthy public‑key binding.

CA issues and revokes certificates; RA verifies applicant identity; CRL/OCSP publish or query revocation status.

Hybrid encryption (digital envelope) encrypts data with a random symmetric key and then encrypts that key with the receiver’s public key. Pure asymmetric encryption of large files is computationally expensive.

SM2 – asymmetric public‑key algorithm; SM3 – hash algorithm; SM4 – symmetric block cipher.