Cryptography 101¶

crypto-chacho

Cryptography is designed to support key security objectives in cybersecurity:

Confidentiality,
Integrity,
Authentication, and
Non-repudiation.

Understanding these principles is crucial for implementing secure systems and communications. This is a walkthrough of implementing these goals with a classic example that demonstrates the use of asymmetric key exchange, symmetric encryption, and digital signatures.

Alice and Bob have been demoing cryptography for decades. No reason to retire them now.

Confidentiality¶

Confidentiality ensures that information is only accessible to those authorized to see it. This is achieved through encryption techniques, which transform readable data (plaintext) into unreadable data (ciphertext). We’ll illustrate this concept through an example involving two parties: Alice and Bob.

Step 1: Generating Asymmetric Keys¶

Before Alice can securely send data to Bob, they need to establish a secure channel for sharing a symmetric key. Bob first needs to generate an RSA key pair:

# Generate Bob's RSA private key (4096 bits)
openssl genpkey -algorithm RSA -out bob_private.pem -pkeyopt rsa_keygen_bits:4096

# Extract Bob's public key from the private key
openssl rsa -in bob_private.pem -pubout -out bob_public.pem

Now, Bob shares his bob_public.pem file with Alice. This public key will be used to encrypt a symmetric key, ensuring that only Bob can decrypt it using his private key.

Why doesn't Alice encrypt it with her private key and let Bob decrypt with Alice's public key?

In this confidentiality portion of the scenario, Alice is wanting to ensure only Bob can decrypt. If Alice signed with her own private key, anyone could use her public key to decrypt the message. Using Bob's public key to encrypt ensures that only Bob, who keeps his private key on lockdown, can decrypt. That said, her private key will be used to address the integrity portion of the cryptogrpahy objectives.

Alice generates a symmetric key and encrypts it using Bob’s public key:

# Generate a random 256-bit symmetric key and save it to a file
openssl rand -hex 32 -out symmetric.key

# Encrypt the symmetric key using Bob's public key
openssl rsautl -encrypt -inkey bob_public.pem -pubin -in symmetric.key -out encrypted_symmetric.key

Alice sends the encrypted_symmetric.key file to Bob. Since it was encrypted with Bob’s public key, only Bob’s private key can decrypt it.

Step 3: Decrypting the Symmetric Key¶

Bob uses his private key to decrypt the symmetric key, enabling secure communication:

# Decrypt the symmetric key using Bob's private key
openssl rsautl -decrypt -inkey bob_private.pem -in encrypted_symmetric.key -out decrypted_symmetric.key

At this point, both Alice and Bob have the same symmetric key. They can now use this key for symmetric encryption, which is more efficient for larger data transfers.

Step 4: Symmetric Encryption for Data Confidentiality¶

Alice can now encrypt any message or file using the symmetric key, ensuring confidentiality:

# Encrypt a file using the symmetric key
openssl enc -aes-256-cbc -salt -in secret_message.txt -out encrypted_message.enc -pass file:./symmetric.key

Bob can decrypt the file using the same symmetric key:

# Decrypt the file using the symmetric key
openssl enc -d -aes-256-cbc -in encrypted_message.enc -out decrypted_message.txt -pass file:./decrypted_symmetric.key

Summary: This key exchange ensures that Alice and Bob can communicate securely. Symmetric encryption is used to protect data confidentiality, while the initial asymmetric key exchange secures the key itself.

Integrity¶

Integrity ensures that data remains unchanged during transmission or storage. Cryptographic hash functions generate a unique fixed-length value for given data, making it easy to detect changes.

Hashing for Data Integrity¶

To verify the integrity of the secret_message.txt file, Alice creates a hash before sending it:

# Generate SHA-256 hash of the message
sha256sum secret_message.txt > message_hash.sha256

After Bob decrypts the message, he can check its integrity by comparing hashes:

# Generate SHA-256 hash of the decrypted message
sha256sum decrypted_message.txt

If the hash values match, Bob can be confident that the message wasn’t altered in transit.

Practical Applications¶

Hashing is widely used for:

Verifying file integrity.
Detecting unauthorized modifications in digital forensics.
Implementing digital signatures.

Authentication¶

Authentication confirms the identity of the sender or system, often using certificates or asymmetric key pairs.

Digital Signatures for Authentication¶

To prove her identity, Alice can create a digital signature using her own private key. This ensures that Bob knows the message truly came from her and hasn’t been altered.

# Alice generates her RSA key pair for signing
openssl genpkey -algorithm RSA -out alice_private.pem -pkeyopt rsa_keygen_bits:4096
openssl rsa -in alice_private.pem -pubout -out alice_public.pem

# Alice signs the hash of the original message
openssl dgst -sha256 -sign alice_private.pem -out message_signature.sha256 secret_message.txt

Alice sends both the encrypted_message.enc and message_signature.sha256 files to Bob. Bob can now verify the signature using Alice’s public key:

# Verify the digital signature using Alice's public key
openssl dgst -sha256 -verify alice_public.pem -signature message_signature.sha256 decrypted_message.txt

If the verification succeeds, Bob knows the message was indeed sent by Alice and that it hasn’t been tampered with.

Non-repudiation¶

Non-repudiation ensures that a sender cannot deny having sent a message. Digital signatures provide non-repudiation by linking the identity of the sender to the message itself.

Using Digital Signatures for Non-repudiation¶

In the example above, Alice’s digital signature also serves as non-repudiation proof. If Bob retains the signature and message, he can always prove that Alice signed the message, even if Alice later denies it.

Practical Use Case: Non-repudiation is crucial in e-commerce, legal documents, and secure software distribution, where the origin of the message or document must be provable.

What if my private key gets compromised?

If you discover that your private key has been compromised, immediate steps must be taken to minimize the impact:

Revoke the Key: If the key is associated with a certificate (e.g., a TLS certificate), revoke it with the Certificate Authority (CA). For GPG keys, generate a revocation certificate:

gpg --gen-revoke <key_id>

Generate a New Key Pair: Create a new key pair and distribute the new public key to your contacts or update it in your systems.

openssl genpkey -algorithm RSA -out new_private.pem -pkeyopt rsa_keygen_bits:4096

Update All Systems: Replace the compromised key with the new key in all systems, including servers, applications, and repositories.
Review Logs and Access: Check for unauthorized access that may have used the compromised key. This includes SSH logs, authentication attempts, and any suspicious activity.
Inform Relevant Parties: Notify stakeholders, clients, or colleagues that your key was compromised and that they should not trust signatures or communications from that key.

Additional Considerations¶

If your private key was stored on a YubiKey or another hardware token, assess whether the token itself was compromised or just the passphrase protecting it. Consider using multi-factor authentication (MFA) for an added layer of security to your key-based workflows.

Putting It All Together¶

Alice needs to send a sensitive legal document, contract.txt, to Bob. She must ensure that the message remains confidential, cannot be altered, and that Bob can verify she is indeed the sender. Let’s see how Alice addresses all four aspects of cryptography:

Confidentiality: Encrypt the document with a symmetric key, which is itself encrypted with Bob’s public key.
Integrity: Generate a hash of the document and send it alongside the encrypted message.
Authentication: Sign the document hash with her private key, enabling Bob to confirm she’s the sender.
Non-repudiation: Use a digital signature that links the document uniquely to Alice, preventing her from denying she sent it.

Step-by-Step Scenario¶

Step 1: Bob Shares His Public Key¶

Bob shares his public key (bob_public.pem) with Alice. This key is used to securely encrypt the symmetric key that will be used for the actual message encryption.

Step 2: Alice Generates a Symmetric Key and Encrypts the Document¶

Alice generates a symmetric key for encrypting the contract.txt file:

# Generate a 256-bit symmetric key
openssl rand -hex 32 -out symmetric.key

She then encrypts the document with the symmetric key using AES-256-CBC:

# Encrypt the document with the symmetric key
openssl enc -aes-256-cbc -salt -in contract.txt -out contract.enc -pass file:./symmetric.key

Step 3: Encrypt the Symmetric Key with Bob’s Public Key¶

To send the symmetric key securely, Alice encrypts it using Bob’s public key:

# Encrypt the symmetric key with Bob's public key
openssl rsautl -encrypt -inkey bob_public.pem -pubin -in symmetric.key -out encrypted_symmetric.key

Now, only Bob can decrypt encrypted_symmetric.key using his private key, ensuring that no one else can access the symmetric key.

Step 4: Create a Hash of the Encrypted Document for Integrity¶

Alice generates a hash of the contract.enc file to ensure its integrity:

# Generate a SHA-256 hash of the encrypted document
sha256sum contract.enc > contract_hash.sha256

The hash value will help Bob verify that the encrypted document has not been altered during transmission.

Step 5: Sign the Hash with Alice’s Private Key for Authentication and Non-repudiation¶

Alice signs the hash using her private key (alice_private.pem). This digital signature will help Bob confirm that Alice was the one who sent the message and that it hasn’t been tampered with:

# Sign the hash with Alice's private key
openssl dgst -sha256 -sign alice_private.pem -out signed_contract_hash.sha256 contract_hash.sha256

Why does Alice sign the hash rather than the contract.txt file?

Performance: Hashing the content significantly reduces the size of the data so instead of signing a large file, only the smaller, fixed-size hash is signed. This makes the signing process faster and more efficient.

Step 6: Alice Sends the Encrypted Message, Encrypted Symmetric Key, and Signed Hash¶

Alice sends the following files to Bob:

contract.enc (encrypted document)
encrypted_symmetric.key (encrypted symmetric key)
signed_contract_hash.sha256 (signed hash for verification)

Step 7: Bob Decrypts the Symmetric Key¶

Bob decrypts the symmetric key using his private key (bob_private.pem):

# Decrypt the symmetric key with Bob's private key
openssl rsautl -decrypt -inkey bob_private.pem -in encrypted_symmetric.key -out decrypted_symmetric.key

Step 8: Bob Decrypts the Document Using the Symmetric Key¶

With the decrypted symmetric key, Bob decrypts the document:

# Decrypt the document with the symmetric key
openssl enc -d -aes-256-cbc -in contract.enc -out contract_decrypted.txt -pass file:./decrypted_symmetric.key

Step 9: Bob Verifies the Integrity of the Decrypted Document¶

Bob generates a hash of the contract.enc file and compares it to the original hash sent by Alice:

# Generate a hash of the decrypted document
sha256sum contract.enc > received_contract_hash.sha256

# Compare hashes to ensure integrity
diff contract_hash.sha256 received_contract_hash.sha256

If the hashes match, Bob can be certain that the file wasn’t altered in transit.

Step 10: Verify Alice’s Digital Signature for Authentication and Non-repudiation¶

Finally, Bob verifies Alice’s digital signature using her public key (alice_public.pem):

# Verify the digital signature with Alice's public key
openssl dgst -sha256 -verify alice_public.pem -signature signed_contract_hash.sha256 contract_hash.sha256

If the verification is successful, Bob can confirm that the document came from Alice and she cannot deny having sent it.

Final Result: Achieving All Cryptography Goals¶

By following these steps, Alice has successfully addressed all four cryptographic goals:

Confidentiality: The document was encrypted with a symmetric key, which itself was secured using asymmetric encryption.
Integrity: A hash value verified that the document was not altered.
Authentication: Alice’s digital signature proves she sent the document.
Non-repudiation: The digital signature prevents Alice from denying her role in sending the document.

This illustrates how multiple cryptographic techniques work together to secure sensitive communications.

Software Examples¶

It's all well and good to understand what's happening behind the scenes, but when was the last time you sent your family or friend your public key so he/she could encrypt an email for you?

So how do we see this process in our everyday lives? As users of software and applications like encrypted messaging apps and secure email clients, we are less privy to the ways in which our information is secured. Here are some examples:

Signal (Secure Messaging Application)
Signal provides secure text, voice, and video communication. It uses end-to-end encryption to ensure confidentiality and integrity. Messages are authenticated with digital signatures, and the app uses protocols like the Signal Protocol to prevent repudiation of messages.
WhatsApp
Similar to Signal, WhatsApp implements end-to-end encryption for all communications, ensuring that only the sender and recipient can read the messages. It automatically signs and verifies messages in the background, ensuring authentication and non-repudiation.
PGP (Pretty Good Privacy) for Email
PGP is used in email clients like Mozilla Thunderbird to encrypt emails and sign them digitally. While it requires some user intervention, it handles all four cryptographic principles: encryption for confidentiality, hashes for integrity, digital signatures for authentication, and non-repudiation.

A Shallow Dive into ProtonMail, a Secure Mail Client

A secure email client like ProtonMail is an excellent example of software that integrates all four cryptographic principles (Confidentiality, Integrity, Authentication, and Non-repudiation) seamlessly in the background so that the user is less aware of these processes. Here's a break down how ProtonMail addresses each of these principles:

1. Confidentiality¶

ProtonMail uses end-to-end encryption for all email content, meaning that only the sender and recipient can read the message. When you send an email, ProtonMail automatically encrypts the content and attachments with a symmetric key. This symmetric key is then encrypted with the recipient’s public key. As a result, only the recipient’s private key can decrypt the symmetric key, allowing access to the email content.

The user simply composes and sends an email as usual. Encryption of the content and keys happens automatically in the background.

2. Integrity¶

Emails sent via ProtonMail include cryptographic hash values that help detect any tampering. When the recipient opens the email, the client verifies the hash of the email content to ensure it hasn't been altered during transmission.

The integrity check happens when the email is received, and if the hashes don’t match, the client can alert the user to potential tampering. Otherwise, the process is transparent to the user.

3. Authentication¶

ProtonMail uses digital signatures to authenticate the sender. When an email is sent, the sender’s client signs the email content with their private key. The recipient’s client can then use the sender’s public key to verify the signature, confirming the sender’s identity.

Users do not have to manually sign emails. The email client handles signing and verifying in the background, maintaining the ease of use of regular email clients.

4. Non-repudiation¶

The digital signature also serves as non-repudiation proof. Because only the sender has access to their private key, the sender cannot deny having sent a digitally signed email. This ensures that messages are linked to the sender’s identity.

The digital signature is attached to each email without user intervention, and the verification happens automatically when the email is opened by the recipient.