🔄 Topic

Starting the encryption module of the Google Cybersecurity Certificate, I studied how public key infrastructure combines symmetric and asymmetric encryption with digital certificates to make online communication both fast and trustworthy — and why neither encryption type alone solves the whole problem.

🎯 Goal

Understand the practical trade-offs between symmetric and asymmetric encryption, how PKI uses both together, and which approved algorithms actually get used in practice today.

🛠 What I Did

I worked through the two-key mental model first, then connected it to real algorithms and a real historical vulnerability.

Main areas covered:

  • learned the box-with-two-keys analogy for asymmetric encryption: a public key can lock the box (encrypt) but not open it, so it can be freely shared; a private key opens it fully (decrypt) and stays with one owner only
  • learned symmetric encryption’s simpler but riskier model: one secret key both locks and unlocks the box, which is faster but means anyone who gets that one key gets full access
  • learned that PKI uses both, deliberately switching based on priority: mobile chat apps use asymmetric encryption to establish a connection securely, then switch to symmetric encryption for the faster back-and-forth once the connection is trusted
  • learned that both encryption types share the same underlying vulnerability — establishing trust between sender and receiver, since keys can be lost, stolen, or misused, and computers can’t use human judgment to just “sense” who to trust the way people do in person
  • learned how digital certificates solve that trust gap: a certificate authority (CA) verifies a company’s identity, encrypts that data with its own private key, and issues a digital certificate — essentially a digital ID badge — that other computers use to confirm authenticity
  • studied key length trade-offs: longer keys resist brute-force attacks better but take longer to compute, so systems balance security against speed rather than maximizing one at the expense of the other
  • learned the current approved algorithms: Triple DES (56-bit DES applied three times for an effective 168-bit key, being phased out but kept for backward compatibility), AES (128/192/256-bit, considered safe from brute force — an AES-128 key is estimated to take a modern computer billions of years to brute-force), RSA (1,024/2,048/4,096-bit asymmetric, used for highly sensitive data), and DSA (2,048-bit, commonly paired with RSA in PKI)
  • learned Kerckhoff’s principle: a cryptographic system should remain secure even if every detail except the private key is publicly known — “security through obscurity” is not real security, and a custom, secret encryption algorithm that’s never been publicly tested is a red flag, not a strength
  • studied the 2014 OpenSSL Heartbleed bug as a concrete case: a vulnerability that exposed sensitive memory data in websites and applications using OpenSSL, patched later that year, and still a live argument for why software has to be kept current even when it “already works”

🔗 Key Cybersecurity Connections

The reason PKI combines both encryption types instead of picking one is a direct security/performance trade-off made explicit: asymmetric encryption is safer for the trust-establishment moment (because the private key never has to be shared), while symmetric encryption is faster for the sustained exchange once trust exists. Understanding that trade-off matters because a system using asymmetric encryption everywhere would be needlessly slow, and a system using symmetric encryption everywhere would have no safe way to establish that first shared secret at all.

Kerckhoff’s principle is a direct rebuttal to “security through obscurity,” a pattern that shows up constantly in real incidents — a custom encryption scheme, an undocumented access path, a “nobody knows this exists” control are all fragile precisely because they’ve never been tested against public scrutiny. Heartbleed reinforces the same point from a different angle: even a widely-used, heavily-scrutinized, industry-standard tool can carry a serious vulnerability, which is why patching and version currency matter regardless of how trusted a tool is.

🔍 Investigation Questions

  • Does a system correctly use asymmetric encryption to establish trust and symmetric encryption for the ongoing exchange, or is it mismatched to the wrong priority?
  • Are key lengths appropriate for the sensitivity of the data being protected, balanced against acceptable performance cost?
  • Is any cryptographic system in use relying on secrecy of its algorithm rather than secrecy of its key — a Kerckhoff’s principle violation?
  • Is OpenSSL (or any cryptographic library in use) patched against known vulnerabilities like Heartbleed, and kept current going forward?
  • Does a digital certificate’s issuing CA and signature actually get verified, or is trust assumed without checking?

🚨 Detection Opportunities

Checks for encryption implementation review:

  • a custom or undocumented encryption algorithm in use instead of a public, vetted standard
  • key lengths shorter than current recommendations (e.g., DES-only, or RSA under 2,048 bits) for sensitive data
  • outdated or unpatched cryptographic libraries still in production
  • a system using asymmetric encryption for high-volume ongoing communication where symmetric would be more appropriate, or vice versa for initial trust establishment
  • a digital certificate accepted without verifying its issuing CA and signature

Example:

project=encryption-review
signal=custom_undocumented_crypto_algorithm_in_use
risk_area=security_through_obscurity
triage=replace_with_public_vetted_standard_algorithm

🧭 MITRE ATT&CK Techniques

No direct mapping claimed. This is foundational cryptography and PKI knowledge rather than an adversary technique, though weak or custom encryption is a common enabling condition for techniques like credential theft or data exfiltration.

🗺 Visual Investigation Diagram

Connection starts
    ↓
Asymmetric encryption establishes trust (public/private key pair)
    ↓
Digital certificate confirms identity via CA signature
    ↓
Switch to symmetric encryption for speed
    ↓
Ongoing exchange protected by single shared secret key
    ↓
Kerckhoff's principle: security holds even if algorithm is public
    ↓
Currency check: is the crypto library itself patched (e.g. post-Heartbleed)?

⚠ Challenges

Keeping symmetric and asymmetric straight in my head took a few passes — the box-with-two-keys analogy helped, but the real test was correctly predicting which one a given real-world scenario (a chat app’s initial handshake versus its ongoing messages) would use, and understanding why rather than just naming the two types.

📚 What I Learned

I learned that encryption strength isn’t just about key length — it’s about matching the right encryption type to the right moment in a communication, verifying identity through a trusted third party rather than assuming it, and never trusting a cryptographic system’s security to the secrecy of how it works rather than the secrecy of its key.

➡ Next Steps

  • Practice identifying which encryption type (symmetric or asymmetric) fits a given communication scenario before checking the answer
  • Look up whether any tools I currently use rely on outdated algorithms like unpatched Triple DES or short RSA keys
  • Move on to hashing and non-repudiation, and connect it back to how PKI’s trust model differs from hashing’s integrity model
  • Revisit Heartbleed’s technical details to understand exactly how a memory-exposure bug undermines encryption that’s otherwise correctly implemented

🧠 Reflection

The most useful shift today was realizing that “which encryption type is more secure” is the wrong question — the right question is “which encryption type fits this specific moment’s priority,” since PKI’s whole design is built on using each type for what it’s actually good at rather than picking a single winner.

🧩 Lessons Learned

What worked

Learning symmetric and asymmetric encryption through their shared vulnerability (key trust) rather than treating them as unrelated topics, and grounding key-length trade-offs in a concrete example (AES-128’s brute-force timeline).

What broke

Nothing broke — this was concept study, reinforced by a real historical case (Heartbleed) rather than a hands-on incident.

Why it mattered

Misunderstanding when to use symmetric versus asymmetric encryption, or trusting an unvetted custom algorithm, are both real-world sources of avoidable cryptographic weakness.

Fix / takeaway

Match encryption type to its actual strength (asymmetric for trust establishment, symmetric for speed), rely only on publicly vetted algorithms per Kerckhoff’s principle, and keep cryptographic libraries patched regardless of how trusted they are.

📈 Skill Progression Context

This supports my cybersecurity progression because understanding PKI, encryption trade-offs, and the Kerckhoff’s-principle argument against security through obscurity are foundational knowledge for any later work in secure system design, credential protection, or incident analysis involving compromised keys or certificates.

😄 TL;DR

PKI doesn’t pick a favorite between symmetric and asymmetric encryption — it uses asymmetric to shake hands securely, then switches to symmetric because talking fast matters once you actually trust who you’re talking to.