DEV Community: Aditya R

🔐 End-to-End File Encryption with AES and Integrity Checks

Aditya R — Thu, 28 Aug 2025 12:00:00 +0000

🔑 Introduction

Imagine sealing a letter inside a locked safe before sending it — even if someone grabs it, they can’t read what’s inside.
That’s exactly what encryption brings to file transfers.

In the previous parts of this series, we’ve built a foundation for trustworthy file transfers:

✅ SHA-256 Checksums → detect accidental corruption.
✅ HMAC-SHA256 → ensure integrity + authenticity with a shared secret.
✅ Digital Signatures → verify authenticity using public/private keys. So far, we’ve made sure files can’t be tampered with or forged. But here’s the missing piece: what if someone intercepts the transfer and simply reads the file’s contents?

That’s where confidentiality comes in.

Think of it this way:

AES encryption is like putting your file inside a bank vault — only someone with the right key can open it.
Integrity checks act like a tamper-evident seal on that vault — if someone even tries to mess with it, you’ll know immediately.

In this part, we’ll explore AES (Advanced Encryption Standard) — a fast and secure encryption method — and show how to combine it with integrity checks so your files remain both private and trusted end-to-end.

What is AES? (The Friendly Version)

Think of AES (Advanced Encryption Standard) as a super-secure lockbox for your files.
When you put a file inside this lockbox, it scrambles everything into unreadable gibberish — so if someone intercepts it, all they see is nonsense.

The only way to open this lockbox is with the right secret key — just like a password. Without it, even the smartest hacker with the fastest computer would need billions of years to figure it out.

That’s why AES is trusted worldwide: it’s not only fast and efficient, but also virtually unbreakable for protecting sensitive information. From online banking to cloud storage to secure messaging apps, AES is everywhere behind the scenes keeping data safe.

In technical words

AES (Advanced Encryption Standard) is a symmetric-key algorithm, meaning the same key is used for encryption and decryption.
It’s fast, secure, and widely used in banking, cloud storage, and enterprise systems.
Key sizes: 128, 192, or 256 bits. Most systems use AES-256 for stronger security.

How AES Fits in File Transfers

Sender encrypts the file using AES with a secret key.
The encrypted file is transmitted.
Along with the encrypted file, the sender computes an integrity check (like HMAC-SHA256) of the ciphertext.
Receiver decrypts using the same AES key and verifies the integrity before trusting the file.

This ensures:

No one can read the file during transfer.
No one can tamper with it undetected.

Python Sample Code

Encrypting a File

from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
from cryptography.hazmat.backends import default_backend
from cryptography.hazmat.primitives import padding
import os

def encrypt_file(file_path, encrypted_file_path, key, iv):

    # Read File Data
    with open(file_path, 'rb') as fin:
        data = fin.read()

    # Pad the Data (AES needs data in blocks)
    padder = padding.PKCS7(128).padder()   # 128-bit AES Block Size
    padded_data = padder.update(data) + padder.finalize()

    # Create AES Cipher in CBC Mode
    cipher = Cipher(algorithms.AES(key), modes.CBC(iv), backend=default_backend())
    encryptor = cipher.encryptor()

    # Encrypt the data
    encrypted_data = encryptor.update(padded_data) + encryptor.finalize()

    # Write IV + Encrypted Data to the Output File
    with open(encrypted_file_path, 'wb') as fout:
        fout.write(iv + encrypted_data)

    print("Encrypted file saved to {}".format(encrypted_file_path))

if __name__ == '__main__':

    # Generate a random AES key (256-bit for strong encryption)
    key = os.urandom(32)  # 32 bytes = 256-bits

    # Generate a random Initialization Vector (IV) for CBC Mode
    iv = os.urandom(16)   # 16 bytes for AES Block Size

    # Provide the Input File and Output File Paths
    file_path = 'sample.txt'
    output_file_path = 'sample.txt.enc'

    encrypt_file(file_path, output_file_path, key, iv)

Key Notes:

We generate a random 256-bit AES key and a 16-byte IV.
The file data is padded so it fits into AES blocks.
The IV is written at the start of the encrypted file — you’ll need it for decryption.
The key must be stored securely (e.g., in a key vault, environment variable, or securely shared).

Decrypting a File

def decrypt_file(encrypted_file_path, output_file_path, key):

    # Read IV + Encrypted Data
    with open(encrypted_file_path, 'rb') as fin:
        data = fin.read()

    iv = data[:16]  # First 16 bytes is IV
    encrypted_data = data[16:]

    # Create AES Cipher with the same Key and IV
    cipher = Cipher(algorithms.AES(key), modes.CBC(iv), backend=default_backend())
    decryptor = cipher.decryptor()

    # Decrypt Data
    decrypted_padded = decryptor.update(encrypted_data) + decryptor.finalize()

    # Remove Padding
    padder = padding.PKCS7(128).padder()
    decrypted_data = padder.update(decrypted_padded) + padder.finalize()

    # Write the Original File
    with open(output_file_path, 'wb') as fout:
        fout.write(decrypted_data)

    print("Successfully decrypted file")

How it works:

Encryption
- File → Pad → Encrypt (AES CBC) → Write [IV + Ciphertext].
Decryption
- Read IV (first 16 bytes).
- Use same AES key + IV.
- Decrypt → Remove padding → Write original file.

Once the file is decrypted, the next step is ensuring integrity. There are multiple ways to do this — from simple hashes to advanced digital signatures. Curious to learn how?

Check out my earlier blog posts in this series on SHA-256, HMAC, and Digital Signatures to see these approaches in action.

Pros and Cons of AES in File Transfers

Pros:

Strong confidentiality (keeps file content secret)
Fast and efficient (especially on large files)
Widely supported and trusted

Cons:

Requires secure key exchange between sender & receiver
Both systems must manage keys carefully (risk of compromise)
Symmetric — not ideal for multi-party distribution without extra layers

Where is this useful?

Think of AES encryption with integrity checks as sending a locked vault with a tamper-proof seal:

Internal file transfers within banks or enterprises → Just like how a bank moves money in armored trucks, files (like transaction records) need both protection (encryption) and proof that no one opened the truck on the way (integrity check).
Healthcare systems exchanging patient data → Similar to how hospitals use sealed envelopes for sensitive test results, AES ensures the content stays private, while integrity checks prove nothing was swapped inside.
Software distribution → Like buying a medicine bottle that’s shrink-wrapped: encryption protects the contents, while integrity ensures no one tampered with the medicine before it reached you.
Government or defense communications → Comparable to sending secret orders in a locked briefcase with a wax seal; AES locks it tight, and integrity checks are the seal that shows whether it was broken.

In short, AES with integrity checks is valuable anywhere you need to keep files private AND prove they haven’t been altered.

Conclusion

With AES, we’ve taken a major leap: not only do we lock files away with encryption, but we also seal them with integrity checks so that tampering can’t go unnoticed. It’s like sending a package in a vault that only the receiver can open — and if someone tries to meddle with it, the broken seal tells the story.

But here’s the exciting part: this is just the beginning.
So far, we’ve built our security journey step by step — from basic checksums to HMAC secrets, then into the realm of digital signatures, and now AES-powered encryption with integrity. Each step has been a new layer of defense.

In the next stage, we’ll go beyond theory and start stitching these building blocks together — exploring end-to-end secure file transfer pipelines, hybrid encryption models, and how these approaches scale in real-world enterprise systems.

Stay tuned — because the real magic happens when all these pieces come together.

The sample codes can be found in my Github.

From Hashes to Signatures: Securing File Transfers with RSA/ECDSA Digital Signatures

Aditya R — Fri, 22 Aug 2025 12:30:00 +0000

🔑 Introduction

In the first two parts of this series, I explored how to secure file transfers using SHA-256 checksums for integrity and then took it a step further with HMAC-SHA256, which added authenticity through a shared secret key. These approaches work well in trusted environments, especially for internal or on-prem systems.

But what happens when the systems are not in the same secure network, or when you need to ensure that even without a shared secret, the file’s integrity and the sender’s identity can be verified? That’s where Digital Signatures come into play.

Digital signatures, built on algorithms like RSA (Rivest–Shamir–Adleman) and ECDSA (Elliptic Curve Digital Signature Algorithm), bring two powerful guarantees:

Integrity — ensuring the file hasn’t been tampered with.
Authenticity — proving that the file truly came from the claimed sender.

In this part, I’ll explore how digital signatures fit into secure file transfers, compare RSA and ECDSA, and walk through generating and verifying signatures with code examples.

📌 What Are Digital Signatures?

A digital signature is like a virtual fingerprint for a file.
It ensures that the file has not been tampered with (integrity).
It ensures that the file truly comes from the claimed sender (authenticity).
It works using a private key (to sign) and a public key (to verify).

⚙️ How It Works (Step-by-Step)

Sender generates a hash of the file (e.g., SHA-256).
Sender encrypts the hash with their private key → digital signature.
The file + signature are sent to the receiver.
Receiver generates their own hash of the received file.
Receiver decrypts the signature using sender’s public key to retrieve the original hash.
If both hashes match → the file is authentic and untampered.

🔐 How to Generate Key Pairs

To use digital signatures, you need a key pair:

Private Key (kept secret, used for signing).
Public Key (shared, used for verifying).

There are many ways to generate the key pairs. The common and straightforward way is to use the openssl library. Here I provide the Python way.

🔑 Generating RSA Key Pairs

# Generate RSA Public-Private Key
def generate_rsa_key(private_key_file, public_key_file):
    private_key = rsa.generate_private_key(public_exponent=65537, key_size=2048)

    # Save Private Key
    with open(private_key_file, "wb") as fout:
        fout.write(private_key.private_bytes(
            encoding=serialization.Encoding.PEM,             # Format = PEM
            format=serialization.PrivateFormat.TraditionalOpenSSL,  # Structure - OpenSSL style
            encryption_algorithm=serialization.NoEncryption()  # No password protection
        ))

    # Save Public Key
    public_key = private_key.public_key()
    with open(public_key_file, "wb") as fout:
        fout.write(public_key.public_bytes(
            encoding=serialization.Encoding.PEM,        # Format = PEM
            format=serialization.PublicFormat.SubjectPublicKeyInfo # Standard X.509 format
        ))

    print("RSA key generation complete")

🔑 Generating ECDSA Key Pairs

# Generate ECDSA Key Pair
def generate_ec_key(private_key_file, public_key_file):

    # Generate ECDSA Private Key
    private_key = ec.generate_private_key(ec.SECP256R1()) # Specifies which Elliptic Curve to use 
                          # Uses the curve known as prime256v1 or NIST P-256.

    # Save Private Key
    with open(private_key_file, "wb") as fout:
        fout.write(private_key.private_bytes(
            encoding=serialization.Encoding.PEM,
            format=serialization.PrivateFormat.TraditionalOpenSSL,
            encryption_algorithm=serialization.NoEncryption()
        ))

    # Save Public Key
    public_key = private_key.public_key()

    with open(public_key_file, "wb") as fout:
        fout.write(public_key.public_bytes(
            encoding=serialization.Encoding.PEM,
            format=serialization.PublicFormat.SubjectPublicKeyInfo
        ))

    print("EC key generation complete")

✅ RSA vs ECDSA Quick Note

RSA → Widely used, mature, simpler to understand, but keys/signatures are larger.
ECDSA → Faster, smaller keys, but more complex math. Popular in modern systems (TLS, blockchain).

A comparison table of RSA vs ECDSA is provided below for information.

Once the Key Pairs are generated and saved, the next step is to generate the Digital Signature.

🔑 Signing the File

def generate_digital_signature(private_key_file, file_path, signature_file_path):

    # Load File Content
    with open(file_path, "rb") as fin:
        data = fin.read()

    # Read the Private Key from pem file
    with open(private_key_file, "rb") as fout:
        private_key = serialization.load_pem_private_key(
            fout.read(),
            password=None
        )

    # Sign the Data
    signature = private_key.sign(
        data,
        padding.PSS(
            mgf=padding.MGF1(algorithm=hashes.SHA256()),
            salt_length=padding.PSS.MAX_LENGTH
        ),
        hashes.SHA256()
    )

    # Save the Signature
    with open(signature_file_path, "wb") as fout:
        fout.write(signature)

    print("Signature generation complete")

Let's understand how the signing works.

private_key.sign( …. ) :
- Uses the RSA private key to generate a digital signature.
- Input is the raw data (in bytes) you want to sign.
- The result (signature) is a unique cryptographic value tied to both the data and the private key.
padding.PSS(…) : Provides Padding Schemes for Security
- PSS (Probabilistic Signature Scheme) is used , which is the modern recommended padding for RSA signatures.
- It makes each signature different, even if the same data is signed multiple times (unlike older, deterministic schemes).
Inside PSS:
- mgf=padding.MGF1(hashes.SHA256()) → MGF1 is a mask generation function that adds randomness, using SHA-256 internally.
- salt_length=padding.PSS.MAX_LENGTH → Uses the largest possible salt (random value) to maximize security.
hashes.SHA256()
- Before signing, the file content is hashed using SHA-256.
- Instead of signing the entire raw file (which could be GBs in size), RSA signs this fixed-length hash digest.
- This ensures efficiency and security — even tiny changes in the file create a completely different hash, and thus a different signature.

⚡ Plain-English Analogy

Think of this like stamping a document with a unique wax seal:

The document = your file (data).
The stamp mold = your private key.
The wax pattern (randomized via PSS) = padding randomness.
The final wax seal impression = the signature.

Anyone with the public key can check the seal and confirm:

The file hasn’t been changed.
It really came from the holder of the private key.

🔑 Verifying the File

# Verify the File with the Signature
def verify_file(public_key_file, file_path, file_signature_path):

    # Load Public Key
    with open(public_key_file, "rb") as fin:
        public_key = serialization.load_pem_public_key(
            fin.read(),
            backend=default_backend()
        )

    # Load File Signature
    with open(file_signature_path, "rb") as fin:
        signature = fin.read()

    # Load File Content
    with open(file_path, "rb") as fin:
        data = fin.read()

    # Verify the Signature
    try:
        public_key.verify(
            signature=signature,
            data=data,
            padding=padding.PSS(
                mgf=padding.MGF1(hashes.SHA256()),
                salt_length=padding.PSS.MAX_LENGTH
            ),
            algorithm=hashes.SHA256()
        )

        print("Signature verified")
    except Exception as e:
        print("Signature verification failed")
        print(f"Exception: {e}")

✅ Pros and Cons

Let's understand the Pros and Cons of this approach.

Pros:

Strong authenticity (no shared secret needed).
Works across untrusted networks.
Non-repudiation: Sender cannot deny signing.

Cons:

Slower than checksum or HMAC.
Requires secure key management.
More complex setup compared to symmetric approaches.

📂 When to Use Digital Signatures?

When files are shared across different organizations.
When authenticity is critical (legal, financial, healthcare files).
When compliance demands non-repudiation (e.g., contracts, audit logs).

📝 Conclusion

Digital signatures add a powerful layer of security for file transfers — going beyond integrity to authenticity and trust. They are the go-to choice when sharing files in untrusted or external environments.

➡️ In the next part of this series, I’ll look at AES Encryption for File Transfers to ensure not just authenticity, but also confidentiality.

The code provided above can be found in Github.

Beyond Checksums: Securing File Transfers with HMAC-SHA256

Aditya R — Thu, 21 Aug 2025 12:30:00 +0000

In my previous blog, we explored how to verify file integrity during transfers using SHA-256 checksums.
That approach is effective in ensuring the file is intact — but it has a limitation: anyone who can get hold of the file can also generate the same SHA-256 hash.

So how do we make it tamper-proof and also be able to verify authenticity without jumping to heavy public key cryptography?
The answer: HMAC-SHA256.

🧠 What is HMAC-SHA256?

HMAC stands for Hash-based Message Authentication Code.
It’s a cryptographic technique where:

You take your file (or message),
Combine it with a secret key that is known only to sender and receiver
Run it through a hashing algorithm like SHA-256. The result is a hash that can only be reproduced if you have both the exact file and the shared secret key.

Why this matters:
If an attacker changes the file, or tries to generate a fake hash without the secret key, the verification will fail.

⚙️ High-Level Workflow

Sender side:

Generate HMAC-SHA256 hash of the file using the shared secret key.
Send both the file and the generated HMAC hash.

Receiver side:

Recompute HMAC-SHA256 hash of the received file using the same key.
Compare it with the sent hash.
Match ✅ → file is intact and authenticated. Mismatch ❌ → file is tampered or key mismatch.

🔑 How to Generate the Secret Key

The security of HMAC entirely depends on the strength and secrecy of the key. A good secret key should:

Be long enough (at least 32 bytes for SHA-256).
Be generated using a cryptographically secure random generator.
Never be hardcoded in source code.
Be stored securely (e.g., in environment variables, secrets manager, or secure vault).

📌 Example — Generate a Secret Key in Python

def generate_secret_key(key_outfile):
    # Generate a 32 byte(256-bit) random key
    key = secrets.token_bytes(32)
    encoded_key = base64.urlsafe_b64encode(key).decode()

    # Store the Key in a txt file for sharing it across 
    with open(key_outfile, "w") as fout:
        fout.write(encoded_key)

    print("Secret file generated")

# key_outfile is the file path to where the secret key is stored.

The above code generates a random base64-encoded key and stores it in a file, which can then be shared securely between systems.

💡 Pro Tip:
Use a Secrets Manager (like AWS Secrets Manager, HashiCorp Vault, Azure Key Vault) to store and retrieve the key securely.
Rotate keys periodically to minimize risk.

📌 Example — Generating HMAC-SHA256 Hash in Python

# Function to generate the HMAC SHA-256 Hash 
def generate_hash(file_path, secret_key):
    with open(file_path, 'rb') as fin:
        file_data = fin.read()

    hash = hmac.new(secret_key.encode(), file_data, hashlib.sha256).hexdigest()
    return hash

# file_path : Path to the file for which hash is to be generated 
# secret_key : Secret Key to be used

📌 Example — Verifying HMAC-SHA256 Hash in Python

# Function to verify the hash of the given file 
def verify_hash(file_path, secret_key, file_hash):

    # Compute the Hash of the File 
    calculated_hash = generate_hash(file_path=file_path, secret_key=secret_key)

    # Match the hash with the received hash 
    is_hash_valid = hmac.compare_digest(calculated_hash, file_hash)
    return is_hash_valid

# generate_hash Function as provided earlier

✅ Pros

Adds authentication: Ensures that only systems with the shared secret can generate the correct hash.
Simple to implement: Works with most programming languages and libraries.
Lightweight: No heavy cryptographic key pairs required.

❌ Cons

Key management: Both parties must securely store and protect the shared key.
Not for untrusted distribution: If the key is leaked, security is compromised.
Still no confidentiality: File content is not encrypted.

📌 Ideal Use Cases

Internal file transfers between trusted systems that share a secure key.
Batch jobs or ETL processes where both ends are controlled environments.
Verifying sensitive configuration files or scripts within DevOps pipelines.
Ensuring authenticity of firmware updates within closed networks.

🧭 Final Thoughts

HMAC-SHA256 is a powerful upgrade from plain SHA-256 checksums, giving you both integrity and authenticity without overcomplicating the setup.
It’s a great fit for controlled environments where a shared secret can be securely managed.

Given that the secret needs to be securely shared and managed, in my next post, I will explore a way where the secret no longer needs to be shared.

I have posted the code in Github.

Securing File Transfers with SHA-256: A Simple Yet Effective Approach

Aditya R — Wed, 20 Aug 2025 10:30:00 +0000

Introduction

In an era where data breaches and file tampering incidents make headlines, securing file transfers between systems has become a fundamental requirement in system design. While there are many mechanisms available to protect data in transit - such as encryption, digital signatures, and mutual authentication - these typically focus on who is sending or receiving the data.

But what about what is being sent? How can you ensure that a file received at the destination is exactly the same as the one sent from the source system, with zero modifications - accidental or malicious?

This is where checksums and hashes play a powerful role.

🧩 The Integrity Challenge

Even if the transport is secure (like over HTTPS, SFTP, or a VPN tunnel), file tampering can occur:
During staging or transit through intermediate systems.
Due to network glitches or disk write issues.
Because of insider threats or misconfigured scripts.

So, we need a mechanism to verify the integrity of the file, regardless of the identity or origin of the sender.

✅ Enter Checksums and Hashing

A checksum is a digital fingerprint of your file. It's generated using a mathematical algorithm (called a hash function) that takes in a file and outputs a fixed-length string. If even a single bit of the file changes, the resulting checksum will also change - making it a reliable method for detecting tampering.
Historically, algorithms like CRC32 and MD5 were popular for checksum generation. However:

CRC32 is fast but prone to collisions and not cryptographically secure.
MD5 has been broken and is vulnerable to collision attacks, making it unsuitable for security-sensitive applications.

🔐 SHA-256 - A Modern, Secure Approach

Today, SHA-256 (part of the SHA-2 family) is the industry standard for cryptographic hashing:

It generates a 256-bit (32-byte) hash value.
It's collision-resistant and widely used in SSL, blockchain, and file integrity systems.
It's ideal for internal systems where encryption or digital signatures might be overkill.

In our scenario, we'll explore using SHA-256 for securing file transfers between two on-prem or internal systems that are already within a trusted network.

🏗️ High-Level Flow:

Source system computes the SHA-256 hash of the file.
It sends both the file and its hash to the destination system.
The destination system recomputes the SHA-256 hash of the received file.
It compares the new hash with the original.
If they match ✅: File is intact.
If they differ ❌: File is tampered or corrupted.

🧪 Example: Generating SHA-256 Hash

You can use a variety of tools - Python, PowerShell, Linux utilities, or even C# - to generate the hash. For my use case, I had to develop PowerShell scripts

#Save the code to a file : generate_hash.ps1

param (
    [Parameter(Mandatory = $true)]
    [string]$File,
    [string]$HashFile
)

#Check if the input file exists
if (-not (Test-Path $File)) {
    Write-Error "Input file '$File' not found."
    exit 1
}

#Set default hash file if not provided
if (-not $HashFile) {
    $HashFile = "$File.sha256"
}

try {
    # Compute SHA256 hash
    $hash = Get-FileHash -Path $File -Algorithm SHA256
    $hash.Hash | Out-File -FilePath $HashFile -Encoding ascii -Force
    Write-Output "SHA256 hash written to '$HashFile'"
    exit 0
}
catch {
    Write-Error "Failed to generate hash: $_"
    exit 2
}

# Sample Usage 
PS D:\GithubRepo\blog_posts\file_hashing> .\generate_hash.ps1 -File .\sample.txt
SHA256 hash written to '.\sample.txt.sha256'

PS D:\GithubRepo\blog_posts\file_hashing> cat .\sample.txt.sha256
C8447B1EC04E6D24B5B07D40126F30D7F6295B1F95E450EF64E4DEB627CADBC6`

🔍 Verifying SHA-256 Hash on the Destination

Once the file is received, verification is straightforward.

# Save the code to a file : verify_hash.ps1

param (
    [string]$File,
    [string]$HashFile
)

if (-not $File -or -not $HashFile) {
    Write-Output "Usage: .\verify_hash.ps1 -File <input_file> -HashFile <hash_file>"
    exit 1
}

if (-not (Test-Path $File)) {
    Write-Output "File '$File' not found."
    exit 1
}

if (-not (Test-Path $HashFile)) {
    Write-Output "Hash file '$HashFile' not found."
    exit 1
}

# Compute current hash
$computedHash = (Get-FileHash -Path $File -Algorithm SHA256).Hash.Trim()

# Read expected hash
$expectedHash = Get-Content $HashFile | Select-Object -First 1
$expectedHash = $expectedHash.Trim()

# Compare
if ($computedHash.ToUpper() -eq $expectedHash.ToUpper()) {
    Write-Output "Hash verified successfully."
} else {
    Write-Output "Hash mismatch!"
    Write-Output "Expected: $expectedHash"
    Write-Output "Actual:   $computedHash"
}

# Sample Usage
PS D:\GithubRepo\blog_posts\file_hashing> .\verify_hash.ps1 -File .\sample.txt -HashFile .\sample.txt.sha256
Hash verified successfully.

🔒 What About Security?

While this approach ensures integrity, it does not provide:
Confidentiality - File content is still in plaintext unless encrypted separately.
Authentication - Anyone can generate a hash if they get the file.

If your systems operate in an untrusted network or involve external parties, consider:
Using HMAC-SHA256 (hash-based message authentication code with a secret key)
Digitally signing the hash using a private key
Encrypting the entire payload with TLS or PGP

⚙️ When Is This Approach Ideal?

Use SHA-256 checksum validation when:
Systems are internal, trusted, and firewalled.
You only care about integrity, not identity or secrecy.
Lightweight and fast verification is a priority.

This can be especially useful in:
Automated data pipelines
ETL jobs transferring CSV/JSON/XML files
Batch file movement between microservices or legacy systems

📦 Bonus Tip: Automate the Workflow

Generate hash on the source during export
Transmit both .data and .data.sha256
Use scheduled jobs or file watchers to verify and move files to staging or quarantine based on checksum match.

🧭 Final Thoughts

SHA-256-based file integrity verification offers a simple, reliable, and effective way to secure file transfers in controlled environments. It doesn't replace encryption or authentication but serves as a complementary measure that gives you confidence your files haven't been tampered with.