Inside Python's Cryptography: What Happens When You Hash or Encrypt

You've probably used hashlib.md5() or cryptography.fernet without thinking twice. But have you ever wondered what Python actually does under the hood when you encrypt a file or compute a hash? It's not magic—it's a carefully orchestrated dance between Python's interpreter and your operating system's low-level libraries.

Let me walk you through how Python manages cryptographic operations, from the moment you type that import statement to the final output.

The Foundation: Why Python Doesn't Reinvent the Wheel

First thing you should know: Python itself isn't doing the heavy mathematical lifting. When you call hashlib.sha256(b"hello"), Python doesn't calculate SHA-256 from scratch. Instead, it's a bridge to battle-tested C libraries like OpenSSL or LibreSSL.

This is by design. Writing cryptographic algorithms in pure Python would be:

• Incredibly slow — Python's interpreted nature would make even basic operations painfully slow compared to compiled C code.
• Dangerous — Cryptographic code needs to be immune to timing attacks and side-channel leaks. Python's memory management makes this tricky.
• Unnecessary — We have excellent, audited implementations already.

Python's hashlib and cryptography packages are essentially wrappers. Think of them like a courteous translator: you speak Python, the C library speaks its native tongue, and Python makes sure the conversation happens safely.

How hashlib Works Step by Step

Let's trace through what happens when you run:

import hashlib
hash_object = hashlib.sha256(b"hello")
result = hash_object.hexdigest()

Step 1: Import time magic

When you import hashlib, Python scans for available backends. On a typical Linux system, it looks for OpenSSL first. If found, it maps Python function calls directly to OpenSSL's C functions. No OpenSSL? It falls back to Python's own built-in implementations (which are slower but always available). Windows and macOS have their own system libraries that get checked.

Step 2: Creating the hash object

hashlib.sha256() triggers a call to OpenSSL's EVP_MD_CTX_new() and EVP_DigestInit_ex() — but you never see that. Python handles the memory allocation for the C context structure and wraps it in a Python object that knows how to feed data in and pull results out.

Step 3: Feeding data

When you update() the hash object (though we used a one-shot call above), Python passes the bytes directly to the C function. No copying, no Python loops over each byte. The C library processes 64-byte blocks at a time, maintaining internal state between calls.

Step 4: Getting the result

hexdigest() calls OpenSSL's EVP_DigestFinal_ex() to finalize the hash, then converts the raw bytes to a hex string in Python — this conversion is the only part that happens in Python space.

The Cryptography Package: A Higher Level

While hashlib is great for basic hashing, the cryptography package handles encryption, decryption, key derivation, and more. It's designed with safety in mind.

Here's what makes it unique:

Memory safety

When you create a Fernet encryption key, Python stores it in a buffer that the cryptography package manages carefully. If your program crashes, that key doesn't get written to a swap file or core dump. The package uses ctypes and careful memory handling to zero out sensitive data when it's no longer needed.

Padding and mode selection

Take AES encryption. AES only works with 16-byte blocks. If your data is 17 bytes, something has to pad it to 32 bytes. Python's cryptography package uses PKCS7 padding automatically — adding bytes with value 1 (if 1 byte needed) through 16 (if a full block needed). It also removes this padding correctly during decryption. Many security flaws come from doing this wrong; Python's implementation is thoroughly tested.

Key management

The cryptography package forces you to work with proper key sizes. If you try to pass a 7-character password to AES-256, it won't silently truncate or pad it like some libraries do. It tells you: "This isn't a valid key." You must use a proper key derivation function like PBKDF2 or Argon2 to turn passwords into keys.

A Real Example from PythonSkillset

At PythonSkillset, we once had a load balancing issue where encrypted session data was passed between servers. The team found that different servers had slightly different OpenSSL versions, and the padding behavior was inconsistent.

The solution wasn't to rewrite the encryption. Python's cryptography package handled cross-version compatibility automatically — it enforced the standard regardless of the underlying OpenSSL version. We just had to ensure all servers used the same key.

What About Performance?

You might wonder: "Is Python fast enough for encrypting large files?"

For a single file, yes. Python's overhead is in the function call boundary between Python and C. Each update() call on a hash object crosses that boundary. For best performance:

• Feed data in large chunks (64KB or more) rather than byte by byte.
• Use memoryview objects to avoid copying data.
• Consider the hmac module for authenticated hashing on streaming data.

But for high-throughput servers doing thousands of operations per second, Python isn't ideal. In those cases, you'd offload cryptographic work to a dedicated service written in Go or Rust, and let Python handle the orchestration.

The Quiet Heroes: Secure Randomness

Cryptographic operations need truly random numbers. Python's os.urandom() is the gateway, but what it actually calls depends on your OS:

• Linux: Reads from /dev/urandom, which gets entropy from hardware RNG (if available) and kernel interrupt timings.
• Windows: Uses CryptGenRandom() or BCryptGenRandom().
• macOS: Uses the CCRandomGenerateBytes() function from CommonCrypto.

Python doesn't generate randomness at all — it's a messenger asking the OS for high-quality random bytes. And importantly, Python will block waiting if the entropy pool is empty (this was more common on older systems without hardware RNG).

A Common Mistake I See

Developers often try to "speed up" cryptography by reusing objects or caching values that should be unique per operation. For example:

# DON'T DO THIS
cipher = Cipher(algorithms.AES(key), modes.CBC(iv))
encryptor = cipher.encryptor()
for block in data_chunks:
    ciphertext = encryptor.update(block)

This works correctly only if you're encrypting a continuous stream. If you reuse the same encryptor object for unrelated messages, you've broken the encryption — the IV is only applied once. Python won't warn you, but a security auditor will.

The right approach? Create a fresh Cipher object with a new random IV for each message.

The Bottom Line

Python's cryptographic operations are a careful handshake between the interpreter and your system's trusted C libraries. The Python layer handles memory safety, input validation, and ergonomic APIs, while the C layer does the actual mathematical work.

When you use hashlib or cryptography, you're getting decades of battle-tested C code wrapped in a friendly Python interface. The cryptography is solid — the real challenge is using it correctly, which is where Python's clear syntax and strict API design help immensely.

Next time you encrypt a file, you now know: Python didn't do the math. But it made sure the right library did, and that the result was delivered to you safely.