AP Cybersecurity Cryptography Commands Guide

This guide teaches you the cryptography command patterns the CED expects you to apply in AP Cybersecurity. You will learn how to encrypt and decrypt files with symmetric keys, generate and use asymmetric (RSA) key pairs, and verify file integrity using hashes. The focus is on what each command does, what input and output to expect, and when each is the right tool.

These skills come from Unit 5, Securing Applications and Data, specifically topics 5.3 (symmetric encryption), 5.4 (asymmetric cryptography), and 5.6.D (verifying a file hash). Concepts like how AES works internally or what RSA key length means are covered elsewhere. Here you build the command fluency to actually apply those concepts.

Where This Shows Up

The Write task verb on the free-response section asks you to express a proper command that has an indicated effect. That means you may need to produce a working OpenSSL or hashing command, not just describe it. The unit scenarios reinforce this: Scenario 5B has you generate an asymmetric key pair, share a public key, and encrypt and decrypt messages.

Skill Categories 2 (Mitigate Risk) and 3 (Detect Attacks) are the ones tied to these commands. Encryption is a protective control under 2.A and 2.D, while hash verification supports detecting whether a file was altered under 3.D and 5.6.D.

Symmetric Encryption with OpenSSL

Symmetric encryption uses one shared secret to both encrypt and decrypt. It is appropriate when you control both ends, such as protecting a stored file with a passphrase you already hold.

Use openssl enc for file encryption. A typical pattern looks like this:

</>Code
openssl enc -aes-256-cbc -salt -in secret.txt -out secret.enc
openssl enc -d -aes-256-cbc -in secret.enc -out secret_decrypted.txt

The first command encrypts secret.txt into secret.enc using AES-256 in CBC mode. The -salt flag adds randomness so identical files do not produce identical ciphertext. You will be prompted for a passphrase, which becomes the basis for the key.

The second command adds -d to decrypt. You must supply the same passphrase, the same algorithm, and point -in at the encrypted file. If any of those differ, decryption fails or produces garbage.

When to use it: protecting data at rest where the same party (or a pre-shared key) handles both encryption and decryption. The weakness is key distribution. If you need to send the key over an untrusted channel, symmetric encryption alone is not enough.

Asymmetric Encryption and RSA Key Generation

Asymmetric encryption uses a key pair: a public key that anyone can hold and a private key you keep secret. This solves the key distribution problem because you can share your public key openly. This is the model behind Scenario 5B and PGP-style secure messaging.

Generate an RSA private key, then extract the matching public key:

</>Code
openssl genrsa -out private_key.pem 2048
openssl rsa -in private_key.pem -pubout -out public_key.pem

The first command creates a 2048-bit RSA private key in private_key.pem. The number sets key length, and longer keys are harder to break. The second command reads that private key and writes out only the public portion to public_key.pem, which is the file you would share with a partner.

To encrypt a small message for someone, use their public key. To decrypt a message sent to you, use your private key:

</>Code
openssl pkeyutl -encrypt -pubin -inkey partner_public.pem -in message.txt -out message.enc
openssl pkeyutl -decrypt -inkey private_key.pem -in message.enc -out message.txt

Notice the direction: the sender encrypts with the recipient's public key, and the recipient decrypts with their own private key. That is the core rule for objective 5.4.A about choosing the correct key.

When to use it: establishing secure communication with someone you have not shared a secret with, or letting many senders encrypt to one recipient. Asymmetric encryption is slower and limited in message size, which is why real systems often use it to exchange a symmetric key and then switch to symmetric encryption for bulk data.

File Hashing and Integrity Verification

A hash is a fixed-length fingerprint of a file. Hashing does not hide data and is not encryption, so do not confuse the two. Its job is integrity: confirming a file has not been altered, which is exactly objective 5.6.D.

Compute a SHA-256 hash:

</>Code
sha256sum important.iso
openssl dgst -sha256 important.iso

Both produce a hash value plus the filename. To verify a download or a file you suspect was tampered with, compare the computed hash to a known-good reference value. If even one byte changed, the hash changes completely.

A practical verification workflow:

1. Obtain the trusted hash from the vendor or original source.
2. Run sha256sum yourfile on the file you have.
3. Compare the two strings character by character, or pipe a checksum file through sha256sum -c.
4. If they match, the file is intact. If they differ, treat the file as altered or corrupted.

</>Code
sha256sum -c checksums.txt

This reads expected hashes from checksums.txt and reports OK or FAILED for each listed file. A FAILED result is an indicator of compromise worth reporting.

Common Mistakes to Avoid

Mixing up which key to use is the classic asymmetric error. Remember: encrypt with the recipient's public key, decrypt with your own private key. Never share or transmit your private key.

Forgetting to match the algorithm and passphrase on symmetric decryption causes silent failures. The decrypt command must mirror the encrypt command's cipher and mode exactly.

Treating hashing as encryption is a conceptual trap. Hashing is one-way and produces no recoverable plaintext, so you cannot "decrypt" a hash. Use it only to verify integrity.

Confusing -in and -out will overwrite or fail to read the file you meant to protect. Read the flags carefully before running a command that writes output.

Using weak key lengths invites attack. The CED ties key length to security in 5.4.B, so default to at least 2048-bit RSA in your examples.

Quick Reference

Practice writing these from memory, since the Write task verb expects a syntactically correct command. Pay attention to flag order and the encrypt versus decrypt direction, because those small details are where points are won or lost.