Data Security Champion: Data Encryption

Table of Contents

• Module 1: Encryption Algorithms and Operations
  • Why Cryptography Matters
  • The Five Purposes of Modern Cryptography
  • How a Cryptosystem Works
  • Symmetric Encryption
  • Asymmetric (Public Key) Encryption
• Module 2: Hashing and Integrity
  • Hashing Algorithms
  • Digital Signatures
  • Certificates and Public Key Infrastructure
  • Module Summary
• Module 3: Using Cryptography for Data Protection
  • Encryption for Data in Transit
  • Encryption for Data at Rest
  • Password Storage with Hashing
  • Field- and Application-Level Encryption
  • Non-Cryptographic Data Obfuscation Techniques
• Module 4: Using Cryptography Securely and Protection from Attacks
  • Key Management: The Real Secret to Secure Cryptography
  • Standards and Regulatory Frameworks
  • Attacker Motivations and Techniques
  • Best Practices to Reduce Risk
  • The Evolving Threat Landscape
• Summary

Module 1: Encryption Algorithms and Operations

Why Cryptography Matters

As a data professional, you understand the value of data and the need to protect it. Encryption is one of the most effective and widely used methods for protecting sensitive data. This course covers four major areas:

1. Encryption algorithms and operations
2. Hashing and integrity
3. Using encryption for data protection
4. Using cryptography securely and protecting against attacks

Cryptography has existed for thousands of years, and its basic concepts have not fundamentally changed. The encryption operations used by the Babylonians, the Spartans, and the Romans to protect messages are still in use today:

• Substitution — replacing one character with another.
• Transposition — shuffling the order of characters to obscure the original message.

Modern computers simply perform these same operations far faster and more reliably. As the field continues to evolve, quantum cryptography may represent the next major step in this evolution.

Note on terminology: Throughout this document, “crypto” is used strictly as a short form for “cryptography” — not for cryptocurrency or blockchain.

The Five Purposes of Modern Cryptography

Historically, cryptography was used almost exclusively to protect secrets — preserving the confidentiality of data that should not be seen by unauthorized parties (financial, customer, and personal information, for example). Today, cryptography provides several additional benefits that were not achievable with early cryptosystems:

mindmap
  root((Purposes of Cryptography))
    Confidentiality
      Protect secrets
      Prevent disclosure
    Integrity
      Detect tampering
      Detect corruption
    Access Control
      Password hashing
      System/network access
    Nonrepudiation
      Digital signatures
      Contract signing
    Authenticity
      Certificates
      Server/device identity

How a Cryptosystem Works

Consider sensitive data contained in a message or file that must be kept secret and protected from improper disclosure:

1. The message starts in its natural, readable form — plain text (or clear text).
2. The message is fed into a cryptosystem — the tool (hardware or software) that performs encryption.
3. Inside the cryptosystem is a mathematical function called an algorithm, which converts the plain text into a format unreadable by anyone else.
4. That converted output is called ciphertext (or a cryptogram).
5. To perform the conversion, a key is supplied to the cryptosystem. Just as a car key prevents others from using your car, a cryptographic key allows only the holder of the correct key to use the cryptosystem in a meaningful way.
6. When the encrypted message is transmitted, or stored (e.g., via full-disk encryption), the receiver must run the ciphertext back through the same cryptosystem/algorithm using the correct key to recover the plain text. No other key will work.

flowchart LR
    A["Plain Text"] -->|"Encrypt with Key"| B["Cryptosystem / Algorithm"]
    B --> C["Ciphertext"]
    C -->|"Transmit or Store"| D["Ciphertext Received"]
    D -->|"Decrypt with Key"| E["Cryptosystem / Algorithm"]
    E --> F["Plain Text Recovered"]

Symmetric Encryption

With a symmetric algorithm, such as the Advanced Encryption Standard (AES), the same key is used to both encrypt and decrypt the message. This is why symmetric encryption is often called same-key or shared-key encryption.

Symmetric algorithms are used primarily for confidentiality. It is difficult for an unauthorized party to read an encrypted message without the correct key — even if that party knows the algorithm and the cryptosystem being used (many people may use the same algorithm and cryptosystem), it is the key that protects the message from disclosure. This is analogous to a password preventing unauthorized login: the key must be selected carefully and protected, just like a good password should be.

sequenceDiagram
    participant Sender
    participant Receiver
    Note over Sender,Receiver: Both parties share the same secret key (K)
    Sender->>Sender: Encrypt(PlainText, K) = Ciphertext
    Sender->>Receiver: Send Ciphertext
    Receiver->>Receiver: Decrypt(Ciphertext, K) = PlainText

Benefits of symmetric algorithms:

• The most commonly used form of encryption algorithm.
• Fast and computationally inexpensive compared to other algorithm types.
• Provide excellent confidentiality.
• Freely available and installed by default in many devices, operating systems, and browsers.

Common use cases:

• Transmitting messages securely.
• Encrypting files and hard drives.
• Encrypting fields in a database.
• Generating one-time codes to support access controls.

Symmetric algorithms, however, do not provide all of the benefits that modern encryption use cases require — for those, asymmetric algorithms are needed.

Asymmetric (Public Key) Encryption

In the 1970s, a new form of encryption algorithm emerged through the work of Whitfield Diffie and Martin Hellman, who pioneered asymmetric algorithms in their paper “New Directions in Cryptography.” This led to the development of the public key algorithms in use today, including Diffie-Hellman, RSA, and Elliptic Curve Cryptography (ECC).

Asymmetric algorithms are based on a key pair — two mathematically related keys generated using a one-way function. A one-way function is easy to compute in one direction but very difficult to compute in reverse. For example: it is trivial to compute $3 \times 8 = 24$, but much harder to factor 24 back into the two numbers that produced it — was it $4 \times 6$, $3 \times 8$, $2 \times 12$, $1 \times 24$, or even $\frac{1}{2} \times 48$? This is a deliberately simplified illustration of the underlying principle; real public key cryptography uses much larger prime numbers and logarithmic values.

If a secret number is chosen — the private key — and a formula is used to compute a related number from it — the public key — these two numbers are mathematically linked, yet it is computationally infeasible to derive the private key from the public key alone. The pair only works together: encryption/decryption operations fail if either key is incorrect.

How asymmetric encryption works (example):

1. Mike wants to send Jane a secret message that no one else can read.
2. Jane has previously sent Mike her public key (e.g., via email or a certificate).
3. Mike encrypts the message using Jane’s public key, producing ciphertext that can be sent over an insecure channel.
4. Jane decrypts the message using her own private key, which she never shares with anyone.
5. A hacker intercepting the message cannot decrypt it, because doing so would require Jane’s private key.

sequenceDiagram
    participant Mike
    participant Jane
    Jane->>Mike: Send Jane's Public Key
    Mike->>Mike: Encrypt(Message, Jane_PublicKey) = Ciphertext
    Mike->>Jane: Send Ciphertext (insecure channel)
    Jane->>Jane: Decrypt(Ciphertext, Jane_PrivateKey) = Message
    Note over Jane: Only Jane's private key can decrypt

Symmetric vs. asymmetric encryption comparison:

The major drawback of asymmetric algorithms is that they are far more computationally intensive and slower than symmetric algorithms. However, they unlock additional capabilities — such as digital signatures and certificate-based authentication — that symmetric algorithms alone cannot provide, covered in the next module.

Module 2: Hashing and Integrity

Hashing Algorithms

Beyond symmetric and asymmetric encryption lies a third type of cryptographic function: hashing. Hashing is used to ensure integrity — confirming that a received message is an exact copy of the message that was sent.

In the early days of transmitting data over noisy telephone lines, parity bits and check digits were used to detect improper modifications, but these tools were weak and error-prone. Today, a hashing algorithm performs this integrity check mathematically.

Example workflow:

1. Mike wants to send a message (a file or email) to Jane and wants assurance the data is complete and error-free.
2. Mike runs the message through a hashing algorithm such as MD5 (Message-Digest 5) or SHA-1 (part of the Secure Hashing Algorithm family).
3. The algorithm reads the message and produces a fixed-length output called a hash or digest — effectively a unique fingerprint of the message.
4. The hash is extremely sensitive to any change in the underlying data: flipping even a single bit in the message changes the resulting hash by at least 40%.
5. Mike appends the calculated hash to the message and sends both to Jane.
6. Jane receives the message, runs it through the same hashing algorithm, and compares her calculated hash to the one Mike sent — confirming the message is an exact copy of what Mike sent.

flowchart LR
    A["Original Message"] --> B["Hash Algorithm (e.g., SHA-1, MD5)"]
    B --> C["Digest / Hash Value"]
    A --> D["Message + Appended Hash Sent"]
    C --> D
    D --> E["Receiver Recomputes Hash"]
    E --> F{"Hashes Match?"}
    F -->|Yes| G["Integrity Confirmed"]
    F -->|No| H["Data Altered / Corrupted"]

Digital Signatures

Combining hashing with asymmetric cryptography produces a digital signature — proof of who sent a message and proof that the message has not been altered. This is especially important for electronic contracts and for distributing software patches from a vendor to a customer.

Example workflow — a vendor (Jane) sending a signed patch to a customer (Mike):

1. Jane runs the software patch through a hashing algorithm to generate a digest of the patch.
2. Jane encrypts that hash using her private key. The hash provides integrity; encrypting with the private key provides proof of origin. Together, this creates a digital signature.
   • A digital signature is not a digitized signature (a scanned image of a handwritten signature) — it is the encrypted hash of a message.
3. Jane appends the digital signature to the patch and distributes it to Mike and her other clients.
4. Each recipient decrypts the digital signature using Jane’s public key, revealing the original hash Jane signed.
5. The recipient independently hashes the received patch using the same hashing algorithm.
6. If the newly computed hash matches the hash recovered from the digital signature, two things are proven:
   • The patch was not altered in transit (integrity).
   • The patch genuinely came from Jane, not an impersonator (nonrepudiation).

sequenceDiagram
    participant Jane as Jane (Sender)
    participant Mike as Mike (Recipient)

    Jane->>Jane: Hash(Patch) = Digest
    Jane->>Jane: Encrypt(Digest, Jane_PrivateKey) = Digital Signature
    Jane->>Mike: Send Patch + Digital Signature
    Mike->>Mike: Decrypt(Digital Signature, Jane_PublicKey) = Original Digest
    Mike->>Mike: Hash(Received Patch) = New Digest
    Mike->>Mike: Compare Original Digest vs New Digest
    Note over Mike: Match confirms integrity + nonrepudiation

Certificates and Public Key Infrastructure

Asymmetric cryptography relies on the sharing of public keys — but how can a recipient be certain a given public key truly belongs to the claimed owner? This is solved through certificates, typically implemented via Public Key Infrastructure (PKI) — a formalized implementation of asymmetric/public key cryptography.

A certificate validates the link between a public key and its owner. It is issued by a trusted third party known as a Certificate Authority (CA), which may be internal to an organization or an external, publicly trusted CA.

Certificate issuance and validation workflow:

1. The CA verifies who is the rightful owner of a given public key. This is critical for use cases such as online banking, where a client must be confident they are communicating with the bank’s legitimate website and not an impersonator.
2. The CA issues a certificate confirming, e.g., “this is Jane’s public key,” and returns it to Jane.
3. Jane distributes this certificate for others to use.
4. When Mike receives the certificate, he can validate it against the certificate authority to confirm it genuinely came from the CA and has not been altered.
5. Mike now has verified proof that he holds Jane’s authentic public key — providing the authentication benefit discussed earlier.

flowchart TD
    A["Jane generates key pair"] --> B["Jane requests certificate from CA"]
    B --> C["CA verifies Jane's identity/ownership"]
    C --> D["CA issues signed certificate binding Jane's identity to her public key"]
    D --> E["Jane distributes certificate"]
    E --> F["Mike receives certificate"]
    F --> G["Mike validates certificate against CA"]
    G --> H["Mike trusts Jane's public key"]

Module Summary

This module reviewed the basic concepts of cryptography and how it is used to protect data in transit and at rest. Security professionals use encryption to support:

• Confidentiality
• Integrity
• Nonrepudiation
• Access control
• Authentication

Hashing specifically provides assurance of message integrity, while digital signatures and PKI combine hashing and asymmetric cryptography to provide proof of origin and authenticity.

Module 3: Using Cryptography for Data Protection

As a data professional, you encounter and benefit from cryptography in nearly every aspect of your work. This module surveys the many practical implementations of cryptography for protecting data.

Encryption for Data in Transit

Communications are conducted over a variety of physical media — cable, fiber, radio, wireless, optical, and more. Different technologies protect data across these media:

A man-in-the-middle attack occurs when an attacker inserts themselves into a communications channel and intercepts data, either reading or altering it in transit. Protocols like IPsec and TLS are specifically designed to defend against this class of attack.

flowchart LR
    subgraph Secure Communication Stack
    A["Application Layer: S/MIME, PGP, SFTP"] --> B["Transport Layer: TLS / SSL"]
    B --> C["Network Layer: IPsec"]
    C --> D["Physical/Link Layer: WPA (Wi-Fi), Satellite HW Encryption + TPM"]
    end

Encryption for Data at Rest

Protecting stored data from disclosure to unauthorized personnel is typically done using symmetric algorithms, which are relatively fast compared to asymmetric algorithms. Symmetric encryption can be applied at multiple levels:

• File level — encrypting an entire file.
• Drive level — full-disk encryption.
• Backup level — encrypting data during the write process to backup tapes/media.

This protects data on mobile devices such as laptops or flash drives — even if the device is stolen or lost, the data remains inaccessible to unauthorized parties.

flowchart TD
    A["Data at Rest"] --> B{Encryption Level}
    B --> C["File-Level Encryption"]
    B --> D["Full-Disk Encryption"]
    B --> E["Backup/Tape Encryption"]
    C --> F["Protects individual files"]
    D --> G["Protects entire storage volume"]
    E --> H["Protects data written to backup media"]

Password Storage with Hashing

Passwords are typically stored as a hash value: the password is run through a hashing algorithm, and only the resulting hash is stored — never the plain-text password.

• Since hash generation is a one-way function, it is not possible to simply reverse a hash to recover the original password, even if the password (hash) file is stolen.
• Because a hash value is a very precise calculation, a user must enter the exact correct password to generate a matching hash and gain access.

sequenceDiagram
    participant User
    participant System

    Note over User,System: Account Creation
    User->>System: Submit password
    System->>System: Hash(password) = StoredHash
    System->>System: Store StoredHash (never store plain-text password)

    Note over User,System: Login Attempt
    User->>System: Submit password attempt
    System->>System: Hash(attempt) = AttemptHash
    System->>System: Compare AttemptHash to StoredHash
    System-->>User: Grant or deny access

Field- and Application-Level Encryption

Many applications protect sensitive data by encrypting individual fields. For example, an application storing credit card numbers may encrypt the credit card number and store the encrypted value in a database field, preventing unauthorized viewers from seeing the credit card number even if they gain access to the database record. Because encryption is a two-way function (unlike hashing), the application can decrypt the credit card number whenever it is legitimately required.

Non-Cryptographic Data Obfuscation Techniques

Not all data protection relies on encryption. Several complementary obfuscation techniques hide sensitive data without cryptographic transformation:

flowchart LR
    A["Sensitive Data Protection Techniques"] --> B["Encryption (reversible via key)"]
    A --> C["Hashing (one-way, integrity/passwords)"]
    A --> D["Masking (display-only hiding)"]
    A --> E["Tokenization (substitute + cross-reference table)"]
    A --> F["Steganography (hidden within another medium)"]

Cryptography benefits organizations in many ways — securing data storage, secure data display, and secure transmission — protecting both the integrity and confidentiality of data with minimal computational effort in most cases.

Module 4: Using Cryptography Securely and Protection from Attacks

Key Management: The Real Secret to Secure Cryptography

Most breaches or failures related to cryptography stem from improper implementation, not weak algorithms. The algorithms in use today are strong, the tools are easy to use and readily available, and in many cases cryptography operates transparently so the end user isn’t even aware it’s happening in the background.

The real secret to secure implementation is key management — it is the cryptographic key that locks and unlocks the secrets of cryptography:

• Loss of a key generally means loss of access to the encrypted data.
• Compromise of a key allows unauthorized parties to gain access.

Key management best practices:

• Choose good keys — random and unpredictable.
• Store keys securely.
• Do not share or reuse keys across multiple applications.
• Do not lose your keys.
• Keep a history of old keys to enable recovery of old data and files.
• Use secure methods to distribute keys.
• Ensure that decommissioned equipment which may have held keys in memory is properly destroyed to prevent key recovery.

mindmap
  root((Key Management Best Practices))
    Selection
      Random
      Unpredictable
    Storage
      Secure at rest
      No reuse across apps
    Lifecycle
      Keep key history
      Secure distribution
    Decommissioning
      Destroy old equipment
      Prevent key recovery

Standards and Regulatory Frameworks

Numerous standards and good practices help ensure cryptography is implemented correctly:

Attacker Motivations and Techniques

In most cases, an attacker’s goal is to learn the cryptographic key, which unlocks the protected data. Once obtained, attackers can:

• Read and alter encrypted messages.
• Impersonate legitimate users or organizations.
• Gain access to sensitive data, which they may threaten to sell or disclose.
• Disable an organization by breaking into its systems, encrypting all of its data, and holding it for ransom — a very common and costly attack (ransomware).

flowchart TD
    A["Attacker Goal: Obtain the Cryptographic Key"] --> B["Read/Alter Encrypted Messages"]
    A --> C["Impersonate Legitimate Users/Orgs"]
    A --> D["Exfiltrate & Threaten to Disclose Data"]
    A --> E["Ransomware: Encrypt Org Data & Extort Payment"]

Best Practices to Reduce Risk

Preventing successful attacks entirely is difficult — attackers are often highly skilled and have many possible avenues of attack. The focus, therefore, should be on best practices and guidance that minimize risk:

• Educate and encourage the use of encryption and data protection through security awareness training, so everyone understands good data protection practices and helps minimize the risk of falling victim to phishing and social engineering attacks.
• Ensure every project focuses on data protection from the outset.
• Ensure data is regularly backed up, and keep backups offline to protect against hardware failures or ransomware.
• Choose encryption keys carefully when generating and distributing them.
• Implement monitoring and incident response plans to detect and react quickly to any type of attack.

The Evolving Threat Landscape

Cryptography continues to evolve — new algorithms and techniques are developed, and systems become faster, enabling stronger cryptographic implementations. However, these same increases in computational power also give attackers greater ability to attack and compromise systems, passwords, and people:

• The use of artificial intelligence to refine attacks will make data protection even more challenging in the future.
• The development of quantum computing may significantly erode the effectiveness of current cryptographic algorithms and implementations.

Despite these growing challenges, well-established tools, standards, and practices continue to support the ongoing effort to protect data.

Summary

Cryptography is a mature discipline built on ancient principles — substitution and transposition — now executed at massive scale and speed by modern computers. It underpins five essential security properties: confidentiality, integrity, access control, nonrepudiation, and authenticity.

Three foundational cryptographic mechanisms work together to deliver these properties:

• Symmetric encryption (e.g., AES) — fast, efficient, ideal for bulk confidentiality of data in transit and at rest, but relies on a single shared key.
• Asymmetric encryption (e.g., RSA, Diffie-Hellman, ECC) — slower and more computationally expensive, but enables secure key exchange, authentication, and doesn’t require a pre-shared secret.
• Hashing (e.g., SHA-1, MD5) — a one-way function used to verify integrity and to securely store passwords.

Combining hashing with asymmetric encryption produces digital signatures, which provide both integrity and nonrepudiation. Certificates, issued through Public Key Infrastructure (PKI) and validated by trusted Certificate Authorities, bind public keys to verified identities, enabling authentication across insecure networks.

In practice, cryptography protects data both in transit (WPA, IPsec, TLS/SSL, VPNs, SFTP, S/MIME, PGP) and at rest (file-level, full-disk, and backup encryption), and complements non-cryptographic obfuscation techniques such as masking, tokenization, and steganography.

Ultimately, the strength of a cryptographic implementation depends far less on the algorithm and far more on key management — key generation, storage, distribution, rotation, and destruction — supported by standards such as FIPS 140-2/140-3, PCI DSS, ISO 27000, and NIST guidance.

Quick-Reference Table

Security Champion Checklist

• Use strong, industry-standard symmetric algorithms (e.g., AES) for bulk data and disk/file encryption.
• Use asymmetric cryptography and certificates for secure key exchange and identity verification.
• Hash passwords — never store them in plain text or using reversible encryption.
• Apply digital signatures to verify integrity and origin of software patches, contracts, and critical communications.
• Validate certificates against a trusted Certificate Authority before trusting a public key.
• Encrypt data in transit using TLS/SSL, IPsec/VPN, SFTP, S/MIME, or PGP as appropriate.
• Encrypt data at rest at the file, disk, and backup levels.
• Apply masking, tokenization, or steganography where appropriate as complementary, non-cryptographic protections.
• Generate keys randomly, store them securely, avoid reuse, and maintain a secure key history.
• Securely destroy old equipment that may retain keys in memory.
• Align implementations with FIPS 140-2/140-3, PCI standards, ISO 27000, and NIST guidance as applicable.
• Maintain offline backups, security awareness training, and incident response plans to reduce the impact of ransomware and other cryptography-targeted attacks.
• Track the evolving threat landscape, including AI-assisted attacks and the long-term impact of quantum computing on current algorithms.

Search Terms

data · security · champion · encryption · cybersecurity · fundamentals · networking · systems · cryptography · hashing · algorithms · protection · public · techniques