Cryptography | Symmetric and Asymmetric Cryptography | Digital Signatures | Digital Certificates

Summary of technological concepts, features, and step-by-step explanations

1) What cryptography is (core idea)

Cryptography is the science/practice of securing communication and data by transforming readable data (plain text) into unreadable, meaningless data (cipher text) using:

• Mathematical algorithms
• Keys

To recover the message, the receiver uses the correct key to decrypt cipher text back into plain text.

2) Why cryptography is used

Cryptography protects key security properties:

• Confidentiality (nobody can read the message)
• Integrity (data can’t be altered undetected)
• Authenticity (verifying identity/source)
• Non-repudiation (signer can’t deny involvement)

3) Encryption/decryption workflow (high-level steps)

1. Select an encryption algorithm Examples mentioned later: AES (symmetric), RSA (asymmetric)

2. Generate keys

   • Symmetric: one shared key (“secret key”)
   • Asymmetric: a public/private key pair

3. Encrypt Produces cipher text that looks random/unreadable

4. Decrypt Uses the correct key to recover the original plain text

---

Symmetric cryptography (secret-key / single-key)

Definition and mechanism

• Same key is used for both encryption and decryption
• Sender and receiver share a secret key in advance

Example scenario

• Alice encrypts a message (e.g., “meet me at 6:00 p.m.”) with the shared symmetric key and sends cipher text over the internet.
• Bob decrypts with the same key to recover the original plain text.
• An eavesdropper monitoring the channel can’t decipher the message without the secret key.

Pros (advantages)

• Efficiency / speed: faster and typically more suitable for large data and real-time communication
• Simplicity: fewer computational requirements, easier to implement
• Key management is simpler (only one shared key), assuming distribution is manageable

Cons (disadvantages)

• Key distribution problem: securely sharing the secret key over insecure networks is difficult
• Key management still matters at scale (rotation, secure storage)
• Key exchange challenge (mentioned Diffie–Hellman as an approach)
• No built-in authentication / non-repudiation: symmetric encryption alone doesn’t prove who sent the message; additional mechanisms like MACs or digital signatures are needed

Algorithms listed (symmetric)

• DES: legacy; short key size (56-bit) makes it vulnerable; largely replaced
• AES: “de facto standard”; 128-bit blocks; 128/192/256-bit keys; used in TLS/SSL, storage, libraries
• 3DES: DES applied three times with longer effective strength; less efficient than AES
• Blowfish: fast, supports various block/key sizes, but “no longer recommended” for new use
• RC4: lightweight, but deprecated due to security weaknesses (key scheduling issues)

---

Asymmetric cryptography (public-key / two-key)

Definition and mechanism

• Uses a key pair:
  • Public key (shared openly; used to encrypt)
  • Private key (kept secret; used to decrypt)
• It’s computationally infeasible to derive the private key from the public key.

Example scenario

• Alice encrypts using Bob’s public key
• Bob decrypts using his private key

Additional concept: digital signatures preview

• Asymmetric crypto supports digital signatures (authenticity/non-repudiation), discussed later.

Pros (advantages)

• Secure key exchange: public keys can be shared without an existing shared secret
• Digital signature support: enables authentication and non-repudiation
• Stronger security properties against brute-force/cryptanalysis due to mathematical complexity
• Simpler key distribution: only private keys must be guarded

Cons (disadvantages)

• Performance: typically slower than symmetric encryption
• Larger keys: longer key lengths are required for comparable security → overhead and bandwidth/ciphertext size impacts
• Private-key storage risks: must securely protect private keys, especially on constrained devices

Algorithms listed (asymmetric)

• RSA: based on prime factorization; used in TLS/SSL and digital signatures
• DSA: based on discrete logarithms; often combined with SHA-256
• ECDSA: like DSA but more efficient with smaller keys; common for constrained environments and crypto transactions
• Diffie–Hellman: key exchange over insecure channels; negotiates shared keys for many protocols (TLS/SSL, IPsec, SSH mentioned)

---

Side-by-side comparison (symmetric vs asymmetric)

• Key types
  • Symmetric: one shared secret key
  • Asymmetric: public/private key pair
• Key distribution
  • Symmetric: hard (must share secret safely)
  • Asymmetric: public key is freely shareable
• Speed
  • Symmetric: faster
  • Asymmetric: slower, especially for bulk encryption
• Security model
  • Symmetric: relies heavily on strict key protection
  • Asymmetric: private key secrecy enables stronger authentication and resistance to unauthorized decryption
• Use cases
  • Symmetric: data encryption (at rest/in transit), e.g., AES and TLS components (mentioned broadly)
  • Asymmetric: HTTPS, SSH, PGP/GPG, digital signatures
• Authentication
  • Symmetric: mostly confidentiality; not strong identity/authentication alone
  • Asymmetric: supports authentication/non-repudiation via signatures
• Key sizes & device constraints
  • Symmetric keys shorter (e.g., 128–256 bits)
  • Asymmetric keys longer (e.g., 2048+ bits typical; “248 bits or more” stated)
  • Asymmetric can be heavy for embedded/mobile/IoT

---

Hashing (one-way function)

What hashing does

• Hash functions take input of any size and produce a fixed-length output called a hash value/hash code.

Properties:

• Deterministic: same input → same hash
• Fixed output size: hash length doesn’t change with input length
• One-way: cannot reverse the hash back to original data (unlike encryption with keys)
• Collision-resistant: small input change → drastically different hash (minimized collisions)

Applications of hashing

• Data integrity verification: compare stored/received hash vs newly computed hash
• Password storage: store hashes instead of plaintext passwords
• Digital signatures: hashes act as message digests that are then signed

---

Digital signatures (detailed tutorial)

Definition

A digital signature verifies:

• Authenticity (who signed)
• Integrity (not altered)
• Origin
• Non-repudiation (signer can’t deny signing)

It’s described as a digital equivalent of handwritten signatures.

Primary purposes (explicitly enumerated)

1. Authentication (sender identity)
2. Integrity (content not changed since signing)
3. Non-repudiation (legal evidence of intent/commitment)
4. Security (prevents tampering/fraud)
5. Efficiency/convenience (remote signing; reduces paperwork)
6. Building trust in digital interactions

Step-by-step “how it works” (sign + verify)

Signing (by signer)

1. Signer needs a private key
2. Signer uses a hash function (examples: SHA-256, SHA3) to compute a hash/message digest of the document
3. Signer signs the hash using the private key (described as “encrypting the hash with the private key”)
4. Attach the digital signature to the document (embedded metadata or separate signature file)
5. Send the signed document

Verification (by verifier)

1. Verifier obtains the signer’s public key, typically from the signer’s digital certificate
2. Verifier re-hashes the received document using the same hash algorithm
3. Verifier decrypts/validates the signature using the signer’s public key to recover the original hash value
4. If the recomputed hash equals the decrypted hash → signature valid and document not tampered
5. Optionally verify certificate trust (not expired, issued by a trusted CA)

Identity + trust

Digital signatures rely on the fact that only someone with the corresponding private key could have produced the signature.

---

Digital certificates (digital IDs + trust)

What a digital certificate is

A digital certificate is a cryptographic “digital identity” used to establish trust—presented as an “online ID card” containing:

1. Identity information (name/email/org, etc.)
2. Public key
3. CA stamp/signature (signature from a trusted Certificate Authority, CA)

Why certificates are needed (key reasons)

• Authentication (verify you’re talking to the legitimate entity)
• Privacy/confidentiality (enable encrypted communication)
• Integrity (used with signatures)
• Trust basis for secure systems like HTTPS
• Mitigates man-in-the-middle attacks
• Used in secure transactions (e-commerce, banking), secure email, software signing, and compliance
• Government and critical infrastructure uses noted

Key components (explicit)

• Public key: used for decrypting incoming data (only private key can decrypt) and verifying signatures
• Identity info: validated by CA
• CA digital signature: proves the certificate hasn’t been tampered with and was issued by a trusted CA

Certificate lifecycle: obtain + use + renew

1. Generate key pair (public/private)
2. Create CSR (Certificate Signing Request) containing public key + identity + desired attributes
3. Submit CSR to a CA (CA verifies identity/domain/business records)
4. Receive issued certificate
5. Install certificate on server/client system
6. Use:
   • encryption/decryption via private key
   • signatures via private key
7. Monitor expiration and renew
8. Revoke when needed

Certificate revocation (how validity is checked)

Common reasons:

• Private key compromise
• Certificate no longer needed
• Changed details (domain/org)
• Misuse/suspicion
• CA breach (revoking all issued certs)

Revocation methods:

• CRL (Certificate Revocation List): periodically updated list checked by serial number
• OCSP (Online Certificate Status Protocol): real-time status query
• Delta CRL: smaller updates since last full CRL
• AIA extension: metadata pointing to CRL/OCSP info
• Automatic revocation checking: software checks before each use

Certificate types listed

• SSL/TLS certificates (HTTPS)
• Code signing certificates
• Email certificates
• Client authentication certificates (e.g., VPNs, 2FA)
• Server authentication certificates
• Document signing certificates (PDFs)
• Qualified certificates (high trust, legally significant, EU context)
• IoT certificates
• Government-issued certificates
• Object signing certificates
• DV/OV/EV TLS certificates
  • DV: domain validation only
  • OV: domain + organization validation
  • EV: strongest checks; “green address bar” mentioned

How a browser verifies an HTTPS certificate

Process described:

1. User connects to HTTPS site
2. Server sends certificate
3. Browser checks certificate validity period
4. Browser verifies CA signature
5. Browser checks revocation via CRL/OCSP
6. If trusted and not revoked, browser trusts CA
7. Browser extracts public key for secure key exchange
8. Encrypted transmission starts; UI shows padlock/secure indicator

---

Main speakers/sources (as stated in subtitles)

• No named individual speaker appears in the subtitles.
• Content is presented as a single instructional narrator/teacher (no identifiable external source).