This chapter covers the fundamentals of cryptography, a core component of the Security+ SY0-701 exam. Cryptography underpins confidentiality, integrity, authentication, and non-repudiation in modern IT systems. This content maps directly to Objective 1.4: Explain the importance of using appropriate cryptographic solutions. You will learn about symmetric and asymmetric encryption, hashing, digital signatures, key management, and common cryptographic attacks. Mastering these concepts is essential for passing the exam and for implementing secure systems in practice.
Jump to a section
Imagine you need to send a confidential document from New York to London. You seal it in a briefcase with a combination lock (symmetric key) and hand it to a courier. Both you and the recipient must know the same combination—if anyone else learns it, they can open the briefcase. This is symmetric encryption: one key locks and unlocks. But how do you securely share the combination? You could use a second briefcase with a different lock (asymmetric encryption). You put the combination inside a smaller box, lock it with a padlock that only the recipient can open (their public key), and send it. The recipient uses their private key to open the padlock, retrieve the combination, and then open the main briefcase. This is hybrid encryption: asymmetric key exchange to share a symmetric key, then symmetric encryption for bulk data. In the digital world, the briefcase is the ciphertext, the combination is the symmetric session key, and the padlock is the recipient's public key. An attacker (eavesdropper) cannot open the padlock without the private key, and cannot brute-force the combination within a reasonable time if the symmetric algorithm is strong (e.g., AES-256). This mirrors TLS handshake: asymmetric (RSA or ECDHE) establishes a shared secret, then symmetric (AES) encrypts the session.
What is Cryptography?
Cryptography is the practice and study of techniques for secure communication in the presence of adversaries. It provides four core security services: confidentiality (keeping data secret), integrity (ensuring data has not been altered), authentication (verifying the identity of the sender), and non-repudiation (preventing the sender from denying they sent a message). For the Security+ exam, you must understand the differences between encryption types, hashing algorithms, and digital signatures, as well as how they are applied in protocols like TLS, SSH, and IPsec.
Symmetric encryption uses the same key for both encryption and decryption. The sender and receiver must share this key securely. Common symmetric algorithms include: - AES (Advanced Encryption Standard): Block cipher with key sizes of 128, 192, or 256 bits. AES is the current standard for symmetric encryption, used in TLS, Wi-Fi (WPA2/3), and disk encryption (BitLocker, FileVault). - DES (Data Encryption Standard): 56-bit key, now considered insecure due to brute-force attacks. Triple DES (3DES) applies DES three times but is deprecated in favor of AES. - RC4 (Rivest Cipher 4): Stream cipher, historically used in WEP and early TLS, but now broken and prohibited. - Blowfish/Twofish: Older block ciphers, still used in some legacy systems.
Symmetric encryption is fast and suitable for bulk data encryption. The main challenge is key distribution: how to securely share the key between parties. This is often solved using asymmetric encryption or key exchange protocols.
Asymmetric Encryption
Asymmetric encryption uses a pair of keys: a public key (shared openly) and a private key (kept secret). Data encrypted with the public key can only be decrypted with the corresponding private key, and vice versa. Common asymmetric algorithms include: - RSA (Rivest-Shamir-Adleman): Based on the difficulty of factoring large prime numbers. Key sizes typically 2048 or 4096 bits. Used for digital signatures and key exchange. - ECC (Elliptic Curve Cryptography): Based on elliptic curve discrete logarithm problem. Offers equivalent security to RSA with smaller key sizes (e.g., 256-bit ECC ≈ 3072-bit RSA). Used in modern TLS (ECDHE) and cryptocurrency wallets. - Diffie-Hellman (DH): Key exchange algorithm that allows two parties to establish a shared secret over an insecure channel. Ephemeral Diffie-Hellman (DHE/ECDHE) provides perfect forward secrecy. - DSA (Digital Signature Algorithm): Used for digital signatures, based on discrete logarithm. Often replaced by ECDSA.
Asymmetric encryption is slower than symmetric and is typically used for key exchange, digital signatures, and encrypting small amounts of data (e.g., symmetric keys).
Hashing and Digital Signatures
A hash function takes an input (message) and produces a fixed-size string of bytes (hash value). It is a one-way function: you cannot reverse the hash to get the original input. Hashing provides integrity: any change to the input results in a completely different hash. Common hash algorithms: - MD5 (Message Digest 5): 128-bit hash, broken (collision attacks possible). Not recommended. - SHA-1 (Secure Hash Algorithm 1): 160-bit hash, also broken (SHAttered attack). Deprecated. - SHA-2 (SHA-256, SHA-384, SHA-512): Current standard. SHA-256 produces a 256-bit hash. - SHA-3: Newest family, based on Keccak, not yet widely adopted.
A digital signature combines hashing with asymmetric encryption: the sender hashes the message and encrypts the hash with their private key. The receiver decrypts the hash with the sender's public key and compares it to their own hash of the message. If they match, integrity and authentication are verified, and non-repudiation is achieved.
Key Management
Key management involves the generation, storage, distribution, rotation, and destruction of cryptographic keys. Poor key management undermines even the strongest algorithms. Key concepts: - Key length: Longer keys increase security but also computational cost. For symmetric, 128-bit is minimum; 256-bit recommended. For RSA, 2048-bit minimum; 4096-bit recommended. - Key rotation: Regularly changing keys limits the impact of a compromised key. NIST SP 800-57 provides guidelines. - Key escrow: Storing keys with a trusted third party for recovery purposes, but introduces a single point of failure and privacy concerns. - Hardware Security Module (HSM): Dedicated hardware for secure key storage and cryptographic operations. - Trusted Platform Module (TPM): Chip on motherboard that stores keys for full-disk encryption and platform integrity.
Cryptographic Attacks
Attackers attempt to break cryptography through various methods: - Brute-force: Trying all possible keys. Mitigated by using sufficiently long keys (e.g., AES-256 has 2^256 keys). - Known-plaintext attack: Attacker has both plaintext and ciphertext. Modern algorithms are resistant. - Chosen-plaintext attack: Attacker can encrypt arbitrary plaintexts. Used against deterministic encryption (e.g., ECB mode). - Birthday attack: Exploits collisions in hash functions. SHA-256 has a 2^128 collision resistance. - Downgrade attack: Force the system to use weaker encryption (e.g., POODLE attack on SSL 3.0). - Side-channel attack: Exploit physical characteristics (timing, power consumption).
Real-World Tools and Commands
OpenSSL: Swiss-army knife for cryptography. Example: openssl enc -aes-256-cbc -in plain.txt -out cipher.bin -K <key> -iv <iv>
GnuPG (GPG): Implements OpenPGP standard. Example: gpg --encrypt --recipient alice@example.com doc.txt
HashCalc: GUI tool for computing hashes.
certutil: Windows tool for certificate management. Example: certutil -hashfile file.txt SHA256
ssh-keygen: Generate SSH key pairs. Example: ssh-keygen -t rsa -b 4096
For the exam, focus on understanding which algorithm provides which service: AES for confidentiality, SHA-2 for integrity, RSA/ECC for authentication and non-repudiation.
Symmetric Encryption Process
1. Both parties agree on a shared secret key via a secure out-of-band method (e.g., in person) or using asymmetric key exchange. 2. The sender encrypts the plaintext using a symmetric algorithm (e.g., AES-256) and a mode of operation (e.g., CBC, GCM). The output is ciphertext. 3. The sender transmits the ciphertext over an insecure channel. 4. The receiver uses the same shared key to decrypt the ciphertext back to plaintext. Tools: OpenSSL command `openssl enc -aes-256-cbc -in plain.txt -out cipher.bin -pass pass:secret`. Logs: no logs generated by encryption itself, but key exchange events might be logged (e.g., TLS handshake).
Asymmetric Key Exchange
1. The receiver generates a key pair (public and private) and distributes the public key (e.g., via a certificate). 2. The sender obtains the receiver's public key. 3. The sender generates a random symmetric session key (e.g., 256-bit AES key). 4. The sender encrypts the session key with the receiver's public key using RSA or ECC. 5. The sender transmits the encrypted session key along with data encrypted with that session key. 6. The receiver uses their private key to decrypt the session key, then uses it to decrypt the data. This is the basis of hybrid encryption used in TLS. Tools: `openssl pkeyutl -encrypt -pubin -inkey pub.pem -in sessionkey.bin -out enc_sessionkey.bin`.
Digital Signature Creation
1. The sender hashes the message using a strong hash algorithm (e.g., SHA-256). 2. The sender encrypts the hash with their private key (using RSA or ECDSA). This encrypted hash is the digital signature. 3. The sender sends the message and the signature to the receiver. 4. The receiver decrypts the signature using the sender's public key to obtain the hash. 5. The receiver independently hashes the message. 6. If the two hashes match, the signature is valid, confirming integrity and authentication. Tools: `openssl dgst -sha256 -sign private.pem -out signature.bin message.txt`.
TLS Handshake (Simplified)
1. Client sends a ClientHello with supported cipher suites and TLS version. 2. Server responds with ServerHello, its digital certificate (containing public key), and chooses cipher suite. 3. Client validates the certificate (checks signature, expiration, revocation). 4. Client generates a pre-master secret (random symmetric key), encrypts it with server's public key, and sends it. 5. Both client and server derive the same session keys from the pre-master secret. 6. They exchange Finished messages encrypted with session keys to confirm. 7. Subsequent data is encrypted with symmetric session keys (e.g., AES-GCM). Tools: `openssl s_client -connect example.com:443 -tls1_2` shows handshake details. Logs: server logs may show TLS version and cipher suite negotiated.
Password Hashing and Verification
1. User creates a password. 2. System generates a random salt and appends it to the password. 3. System hashes the salted password using a slow hash function (e.g., bcrypt, PBKDF2, Argon2). 4. System stores the salt and the resulting hash. 5. During login, user provides password. 6. System retrieves the salt, appends it to the provided password, hashes it, and compares to stored hash. 7. If match, authentication succeeds. Tools: `mkpasswd -m sha-512` on Linux. Logs: authentication logs (e.g., /var/log/auth.log) show success/failure but not the hash. Common mistake: using fast hashes like MD5 or SHA-1 without salt, making brute-force easier.
Scenario 1: TLS Certificate Validation Failure A SOC analyst receives an alert that a user's browser displayed a certificate warning when visiting https://www.bank.com. The analyst checks the certificate and finds it is self-signed, not issued by a trusted CA. The correct response is to determine if the user was redirected to a phishing site. The analyst should examine proxy logs for the destination IP, check DNS for possible spoofing, and verify the certificate chain. A common mistake is ignoring the warning because the site still loaded; the warning indicates a potential man-in-the-middle attack. Tools: Wireshark to capture TLS handshake, openssl s_client to view certificate details, and a certificate transparency log (e.g., crt.sh) to verify legitimate certificates.
Scenario 2: Weak Encryption in Legacy Application An engineer discovers a legacy application still using DES for encrypting sensitive customer data. The correct response is to upgrade to AES-256 or at least 3DES (though deprecated). The engineer should inventory all systems using the application, plan a migration to a modern algorithm, and implement key rotation. A common mistake is assuming DES is acceptable because it is 'encrypted' — DES can be brute-forced in hours with modern hardware. Tools: Nessus or OpenVAS vulnerability scanners can detect weak cipher suites. Compliance frameworks (PCI DSS, HIPAA) require strong encryption.
Scenario 3: Hash Collision Attack on Digital Signatures
A forensics analyst investigates a malware sample signed with a certificate that appears valid. The analyst discovers the malware's hash matches a legitimate signed binary (collision attack). The correct response is to revoke the certificate and investigate the CA's issuance process. The analyst should check if the signature uses SHA-1 (vulnerable) and recommend migration to SHA-256. A common mistake is trusting the signature without verifying the hash algorithm used. Tools: sha1collisiondetector or hashclash to test for collisions. The SHAttered attack (CVE-2017-9791) demonstrated SHA-1 collisions.
What SY0-701 Tests
Objective 1.4 requires you to explain the importance of using appropriate cryptographic solutions. Sub-objectives include: symmetric vs asymmetric, hashing, digital signatures, key exchange, and key management. You must know which algorithm provides which service: AES for confidentiality, SHA-2 for integrity, RSA/ECC for non-repudiation. Be able to identify the correct algorithm for a given scenario (e.g., encrypting data at rest → AES; verifying integrity → SHA-256; secure email → S/MIME or PGP).
Common Wrong Answers
Choosing DES or 3DES for new implementations: Candidates pick these because they sound familiar. Reality: DES is broken; 3DES is deprecated. AES is the correct choice.
Confusing hashing with encryption: Hashing is one-way; encryption is reversible. If a question asks for confidentiality, hashing is wrong.
Selecting MD5 for integrity: MD5 is fast but broken. SHA-256 is the minimum acceptable.
Thinking public key is used for decryption: The public key encrypts; private key decrypts. For signatures, private key signs; public key verifies.
Specific Terms and Values
AES key sizes: 128, 192, 256 bits.
RSA minimum key size: 2048 bits.
SHA-256 output: 256 bits (32 bytes).
Diffie-Hellman (DH) and ECDHE provide perfect forward secrecy.
Common cipher suites: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.
Ports: HTTPS (443), SSH (22), IPsec (500/4500).
Trick Questions
'Which algorithm provides non-repudiation?' → Digital signature (RSA or ECDSA), not hashing alone.
'Which is used for key exchange?' → Diffie-Hellman or RSA encryption of session key.
'Which is faster?' → Symmetric (AES) vs asymmetric (RSA).
Decision Rule for Eliminating Wrong Answers
On scenario questions, identify the required security service first (confidentiality, integrity, authentication, non-repudiation). Then choose the algorithm that directly provides that service. Eliminate any algorithm that is broken (DES, MD5, SHA-1) or provides a different service (e.g., hashing for confidentiality). If the scenario involves key exchange, look for DH, ECDHE, or RSA encryption of a session key.
Symmetric encryption (AES) is used for confidentiality; asymmetric (RSA/ECC) for key exchange and digital signatures.
Hashing (SHA-256) provides integrity; digital signatures provide authentication and non-repudiation.
Key management is critical: use strong keys, rotate them, and store them securely (HSM, TPM).
Avoid deprecated algorithms: DES, 3DES, RC4, MD5, SHA-1.
TLS uses hybrid encryption: asymmetric key exchange to share a symmetric session key.
Perfect forward secrecy (PFS) is achieved with ephemeral Diffie-Hellman (DHE/ECDHE).
Common ports: HTTPS (443), SSH (22), IPsec (500/4500).
These come up on the exam all the time. Here's how to tell them apart.
Symmetric Encryption (AES)
Same key for encryption and decryption
Fast, suitable for bulk data
Key size: 128-256 bits
Key distribution problem
Provides confidentiality
Asymmetric Encryption (RSA)
Key pair: public and private
Slow, used for key exchange/signatures
Key size: 2048-4096 bits
No key distribution problem (public key shared openly)
Provides authentication and non-repudiation
Mistake
Hashing and encryption are the same thing.
Correct
Hashing is a one-way function that produces a fixed-size digest; encryption is reversible with a key. Hashing provides integrity, not confidentiality. Encryption provides confidentiality.
Mistake
Longer keys always mean more secure.
Correct
Key length is only one factor. Algorithm strength, implementation, and key management matter. A 256-bit AES key is secure, but a 4096-bit RSA key is not necessarily 'better' than a 256-bit ECC key — they offer equivalent security.
Mistake
Public key encryption is used for all data encryption.
Correct
Asymmetric encryption is slow and impractical for large data. It is used for key exchange and small data (e.g., session keys). Bulk data is encrypted with symmetric algorithms.
Mistake
MD5 and SHA-1 are still safe to use.
Correct
Both are cryptographically broken. MD5 has practical collision attacks; SHA-1 has demonstrated collisions (SHAttered). Use SHA-2 or SHA-3 instead.
Mistake
If a website uses HTTPS, it is completely secure.
Correct
HTTPS encrypts data in transit, but does not protect against server-side vulnerabilities, malware, or phishing. Also, weak cipher suites or expired certificates can reduce security.
Symmetric encryption uses one key for both encryption and decryption; it is fast and used for bulk data. Asymmetric uses a key pair (public and private); it is slower and used for key exchange and digital signatures. For the exam, remember that symmetric provides confidentiality, asymmetric provides authentication and non-repudiation.
Use AES with a key size of at least 256 bits. AES is the standard for disk encryption (BitLocker, FileVault) and file encryption. Avoid DES, 3DES, and RC4. For database encryption, use AES in GCM mode for authenticated encryption.
A digital signature is an encrypted hash of a message, created with the sender's private key. The receiver uses the sender's public key to decrypt the hash and compares it to a freshly computed hash. If they match, the message is authentic and unaltered. This provides integrity, authentication, and non-repudiation.
PFS ensures that if a server's long-term private key is compromised, past session keys cannot be derived. It is achieved by using ephemeral Diffie-Hellman (DHE or ECDHE) key exchange, where each session uses a temporary key. Without PFS, an attacker can decrypt past sessions if they obtain the private key.
MD5 is vulnerable to collision attacks, where two different inputs produce the same hash. This allows attackers to create malicious files that have the same hash as legitimate ones. For example, the Flame malware used an MD5 collision to forge a Microsoft certificate. Use SHA-256 or stronger.
A CA is a trusted entity that issues digital certificates, binding a public key to an identity (e.g., domain name). CAs are critical for PKI; without them, you cannot trust that a public key belongs to who it claims. Browsers trust a list of root CAs. If a CA is compromised, all certificates it issued become untrusted.
During the TLS handshake, asymmetric encryption (or Diffie-Hellman) is used to securely exchange a symmetric session key. Once both sides have the session key, all subsequent data is encrypted with symmetric encryption (e.g., AES) for performance. This is called hybrid encryption.
You've just covered Cryptography Fundamentals — now see how well it sticks with free SY0-701 practice questions. Full explanations included, no account needed.
Done with this chapter?