What You'll Learn
How symmetric single-key encryption works and when to use AES
How public/private key pairs solve the key exchange problem
Why ECC beats RSA on mobile and IoT devices
How TLS hybridizes both in every HTTPS handshake
AES-256 is the global standard for data-at-rest encryption. RSA solves the key exchange problem. TLS uses both together — and that's the secret to the secure internet.
Symmetric Encryption: The Speed Demon
Symmetric cryptography uses a single shared secret key to both encrypt and decrypt data. Think of it as a padlock with one key — whoever has it can both lock and unlock. The computational math is simple, making it blazingly fast.
Symmetric Encryption
- One shared secret key for encryption AND decryption
- Extremely fast — ideal for bulk data (full disk, video streams)
- Low computational overhead — works on constrained hardware
- Key exchange problem: how do you securely share the key first?
- Algorithms: AES-128, AES-256, ChaCha20, 3DES (legacy)
Asymmetric Encryption
- Two mathematically-linked keys: Public Key + Private Key
- Whatever one key does, only the other key can undo
- Solves the key exchange problem — share your public key freely
- Very slow and CPU-intensive — never for bulk data encryption
- Algorithms: RSA-2048, RSA-4096, ECC (P-256), Diffie-Hellman
The most critical exam rule: whatever one key does, ONLY the other key can undo. Encrypt with the Public Key → only the Private Key decrypts. Sign with the Private Key → only the Public Key verifies. This rule underlies digital signatures, certificates, and TLS.
ECC vs. RSA: Why Size Matters
Elliptic Curve Cryptography (ECC) uses algebraic curved equations that create the same mathematical hardness as RSA but with dramatically smaller key sizes. This makes ECC the preferred choice for mobile devices, IoT sensors, and TLS certificates.
| Security Level | RSA Key Size | ECC Key Size | Performance |
|---|---|---|---|
| 80-bit | 1024 bits | 160 bits | ECC ~10x faster |
| 128-bit | 3072 bits | 256 bits | ECC ~20x faster |
| 256-bit | 15360 bits | 512 bits | ECC ~40x faster |
Digital Signatures: Asymmetric in Reverse
Digital signatures prove authenticity and non-repudiation. The process uses asymmetric keys but in the reverse direction from encryption:
The sender creates a cryptographic hash of the message (e.g., SHA-256). They then encrypt that hash with their Private Key. This encrypted hash is the digital signature. It is attached to the message. Anyone with the sender's public key can verify it.
The receiver receives the message + signature. They decrypt the signature using the sender's Public Key — this gives them the original hash. They independently hash the received message. If both hashes match, the signature is valid: the message came from the sender and was not tampered with.
Because only the sender holds their Private Key, only they could have created a valid signature. This means they cannot later deny sending the message — this is non-repudiation. On the SY0-701, if you see the word non-repudiation, think asymmetric encryption + digital signatures.
TLS Hybrid Encryption: Using Both
Every HTTPS connection uses both symmetric and asymmetric encryption in a sequence. This hybrid approach gets the benefits of both: security from asymmetric for setup, speed from symmetric for actual data transfer.
1
Client Hello
Browser connects to web server. Sends list of supported cipher suites and a random number (Client Random).
2
Server Certificate
Server sends its RSA or ECC certificate (contains server's Public Key), signed by a trusted Certificate Authority.
3
Key Exchange
Browser verifies certificate via PKI chain. Both sides use asymmetric crypto (RSA or ECDHE) to securely agree on a session key — the shared symmetric secret.
4
Symmetric Data Transfer
From this point, all actual HTTP data is encrypted/decrypted using AES-256 (or ChaCha20) with the shared session key. This is fast, efficient, and secure.
5
Session Termination
When the session ends, the symmetric session key is discarded. A new TLS handshake generates a fresh key — this is Perfect Forward Secrecy (PFS).
terminal
# View a server's TLS certificate and key exchange details
openssl s_client -connect securityplus.studio:443 -showcerts 2>/dev/null | openssl x509 -noout -text | grep -E 'Issuer|Subject|Not After|Public Key'| Feature | Symmetric | Asymmetric |
|---|---|---|
| Number of Keys | 1 (Shared Secret) | 2 (Public & Private) |
| Speed | Exceptionally Fast | Very Slow (10-100x slower) |
| Primary Use Case | Data at rest (disk), Bulk data transfer | Key exchange, Digital Signatures |
| Key Exchange Problem | Yes — must share key securely first | No — public key is shared freely |
| Non-repudiation | No | Yes (Private Key signing) |
| Algorithm Examples | AES-256, ChaCha20, 3DES | RSA-2048, ECC P-256, ECDHE |
If an exam question asks to encrypt a high volume of data securely and quickly, pick AES (symmetric). If it needs to ensure non-repudiation or prove exactly who sent a message, use asymmetric (Private Key signing). If it asks about TLS / HTTPS: both, with asymmetric for setup and symmetric for data transfer.
Key Takeaways
- Symmetric = one key, fast, used for disk/file/bulk encryption (AES-256 is the gold standard).
- Asymmetric = key pair, slow, used for key exchange and digital signatures (RSA, ECC).
- ECC provides equivalent security to RSA with dramatically smaller key sizes — preferred for mobile/IoT.
- TLS hybrid: asymmetric for the handshake key exchange, symmetric (AES) for actual data.
- Non-repudiation requires asymmetric encryption with Private Key signing — this is always testable.
Next Steps
Ready to test your knowledge?
Take a free full-length practice exam with 90 questions and instant feedback.
Start Practice Exam