Encryption, hashing and signing

On November 5, 2026, Theo Marchand stopped by the security team's desks with a question from the StockLine project. The database team wanted to know whether the new Azure SQL database would be encrypted, and the auditor's checklist asked separately whether customer passwords for the Finch Rewards loyalty app were "encrypted or hashed". Theo had always used the two words as if they meant the same thing. Sunil Rao handed the question to Ama Boateng. "Explain the difference to Theo," he said, "and you'll know it well enough for the exam."

This lesson covers the three cryptographic tools that appear again and again in security work and in the SC-900 outline: encryption, which hides information; hashing, which fingerprints it; and digital signing, which proves who sent it and that it was not changed. Each one supports a different part of the CIA triad from lesson 1, and mixing them up leads to real mistakes.

Encryption: making data unreadable without a key

Encryption turns readable data, called plaintext, into scrambled data, called ciphertext, using a mathematical algorithm and a key. Anyone who obtains the ciphertext without the right key sees only meaningless bytes. With the key, the process can be reversed, which is called decryption, to get the original data back. Encryption mainly protects confidentiality: a stolen laptop, a copied backup tape or an intercepted network message is far less harmful if the data on it is encrypted and the attacker does not have the key.

There are two main kinds of encryption. In symmetric encryption, the same key encrypts and decrypts the data. It is fast and is used for most bulk encryption, such as encrypting a disk or a database. Its challenge is sharing the key safely: anyone who has the key can read the data, so the key itself must be protected. AES, the Advanced Encryption Standard, is the most widely used symmetric algorithm.

In asymmetric encryption, also called public-key encryption, each party has a pair of mathematically related keys: a public key that can be shared with anyone and a private key that is kept secret. Data encrypted with the public key can be decrypted only with the matching private key. That solves the key-sharing problem: a customer's browser can encrypt a message using the website's public key, and only the website, holding the private key, can read it. Asymmetric encryption is much slower than symmetric encryption, so in practice the two are combined: asymmetric methods are used to agree on or exchange a symmetric key, which then encrypts the actual data.

Encryption at rest, in transit and in use

Security teams describe encryption by the state the data is in. Encryption at rest protects stored data: files on disks, databases, backups and storage accounts. In Azure, data in storage accounts and managed disks is encrypted at rest by default, and Azure SQL Database uses transparent data encryption, which encrypts the database files without changes to the application. That answered the first half of Theo's question: the StockLine database would be encrypted at rest without any extra work, although the team could choose to manage its own keys.

Encryption in transit protects data while it moves across a network, for example between a browser and a website or between head office and Azure. The most common protocol is Transport Layer Security (TLS), the technology behind HTTPS. The site-to-site VPN to Azure that went live on October 13 also encrypts traffic between head office and the Skylight hub network. Without encryption in transit, anyone who can observe the network path could read or alter the data.

Encryption in use protects data while it is being processed in memory, which is the hardest state to protect because programs normally need plaintext to work. Azure confidential computing uses special hardware to create protected areas, sometimes called trusted execution environments, where data stays encrypted from the rest of the system even while it is processed. It is used for highly sensitive workloads and is worth recognizing by name for the exam.

Managing keys

Encryption is only as strong as the protection of its keys. A database encrypted with a key stored in a text file next to it is barely protected. In Azure, keys, secrets such as passwords and connection strings, and certificates can be stored in Azure Key Vault, a service that keeps them in a secured store, controls who and what can use them and records every use. By default, Azure services encrypt data with platform-managed keys that Microsoft creates and rotates. Organizations that need more control can use customer-managed keys held in Key Vault, so that they decide when keys rotate and can revoke access. Key Vault itself is part of the infrastructure security services covered in MSAZ-131.

Hashing: a fingerprint for data

Hashing is different from encryption in one essential way: it is designed to be one-way. A hash function takes any amount of data and produces a fixed-length value, called a hash or digest. The same input always produces the same hash, but even a tiny change to the input produces a completely different hash, and there is no key that turns the hash back into the original data. SHA-256, part of the SHA-2 family, is a widely used hash function that produces a 256-bit value, usually written as 64 hexadecimal characters.

Because of these properties, hashing mainly supports integrity. If a file's hash today matches the hash recorded when the file was created, the file has not changed. Software publishers list hashes so that downloads can be checked, and backup and forensic tools record hashes to prove that data was not altered. Ama ran a short example to show Theo how sensitive a hash is to change.

import hashlib

def sha256(text):
    return hashlib.sha256(text.encode()).hexdigest()

a = "Pay supplier 4417 the amount of 12500.00"
b = "Pay supplier 4417 the amount of 12600.00"
print(sha256(a))
print(sha256(b))
same = sum(1 for x, y in zip(sha256(a), sha256(b)) if x == y)
print("Matching hex characters:", same, "of 64")

aed1ef9caff14857de2d7ea0d78496eb4d6758501a546eee9bb7326e0708866f
abef3c83fe9a89285ed0bf7eda2865f8caab60a0c606f51952ad1f9ffeffac6c
Matching hex characters: 5 of 64

Changing a single digit in the payment instruction produced a completely unrelated hash. Roughly as many characters match as would by chance. That is why hashes are useful for detecting tampering: there is no way to make a small, unnoticed change that keeps the same hash with a modern hash function.

Hashing passwords

Hashing also answers the second half of the auditor's question. A system that checks passwords does not need to store the passwords themselves. It can store a hash of each password and, when someone signs in, hash what they typed and compare the results. If the stored hashes are stolen, the attacker does not directly get the passwords. Passwords should be hashed, not encrypted: encrypted passwords could be decrypted by anyone who obtains the key, while properly hashed passwords cannot be reversed.

Plain hashing is not enough on its own, because attackers can hash millions of common passwords and look for matches. Two techniques defend against this. A salt is a random value stored with each password and mixed into its hash, so two users with the same password get different hashes and precomputed tables become useless. A slow, purpose-built password hashing function, such as PBKDF2, bcrypt, scrypt or Argon2, deliberately takes extra work for each guess, which makes guessing at scale expensive. The loyalty app's developers confirmed they would use a standard password hashing library rather than write their own.

import hashlib, os

def hash_password(password, salt=None, rounds=200_000):
    salt = salt or os.urandom(16)
    digest = hashlib.pbkdf2_hmac("sha256", password.encode(), salt, rounds)
    return salt, digest

salt1, h1 = hash_password("Spring2026!")
salt2, h2 = hash_password("Spring2026!")
print("Same password, different salts give different hashes:", h1 != h2)

# Checking a sign-in: hash the typed password with the stored salt and compare.
_, check = hash_password("Spring2026!", salt1)
print("Correct password accepted:", check == h1)
_, wrong = hash_password("spring2026!", salt1)
print("Wrong password accepted:", wrong == h1)

Same password, different salts give different hashes: True
Correct password accepted: True
Wrong password accepted: False

Digital signing: proving origin and integrity

A digital signature combines hashing and asymmetric cryptography to prove two things about a message or file: that it came from the holder of a particular private key, and that it has not been changed since it was signed. To sign, the sender hashes the data and then uses their private key to produce a signature from that hash. Anyone with the sender's public key can check the signature: they hash the data themselves and use the public key to confirm that the signature matches. If even one byte has changed, or the signature was made with a different key, verification fails.

Signing supports integrity and also non-repudiation, meaning the signer cannot easily deny having signed, because only they hold the private key. Signatures are everywhere: software updates are signed so devices install only genuine code, email can be signed to show it really came from the sender, and documents can be signed electronically. Note the reversed roles compared with encryption: for confidentiality you encrypt with the recipient's public key, but for a signature you sign with your own private key.

Ama demonstrated the idea with textbook-sized numbers. Real keys are thousands of bits long and real systems add padding and other safeguards, so this toy example is only for understanding the relationship between the two keys.

import hashlib
# Toy key pair (far too small to be secure; for illustration only).
p, q = 61, 53
n = p * q                # public modulus
e = 17                   # public exponent
d = pow(e, -1, (p - 1) * (q - 1))   # private exponent

def digest(msg):
    return divmod(int(hashlib.sha256(msg.encode()).hexdigest(), 16), n)[1]

msg = "Bank details unchanged. Dana Whitcombe, CFO"
signature = pow(digest(msg), d, n)            # sign with the private key
print("Valid signature:", pow(signature, e, n) == digest(msg))   # verify with the public key
forged = msg.replace("unchanged", "changed")
print("Forged message passes:", pow(signature, e, n) == digest(forged))

Valid signature: True
Forged message passes: False

Certificates: linking keys to identities

A public key is only useful if you know whose it is. A digital certificate binds a public key to an identity, such as a website's domain name or an organization, and is itself signed by a certificate authority (CA) that others trust. When a customer visits harrowfinch.com, the browser checks that the site's certificate was issued by a trusted CA, that it covers that domain name and that it has not expired or been revoked. This system of CAs, certificates and keys is called a public key infrastructure (PKI). Certificates can also identify users and devices; Microsoft Entra supports certificate-based authentication, covered in lesson 9.

Ama's final answer to Theo fitted on one sticky note. The StockLine database is encrypted at rest so a stolen copy is unreadable. Customer passwords are hashed with a salt so they cannot be recovered even by the company. Supplier payment instructions should be signed, or confirmed through a known channel, so a forged change like October's is detected. Sunil added a line to the finance team's procedure: any request to change bank details must be confirmed by phone using the number already on file.