This chapter covers hashing and digital signatures, two foundational cryptographic concepts that ensure data integrity, authenticity, and non-repudiation. For the SC-900 exam, understanding these mechanisms is critical because they underpin many security controls in Microsoft 365, Azure, and identity platforms. Approximately 10-15% of exam questions touch on cryptography or related security concepts, and knowing the difference between hashing and encryption, and how digital signatures work, is a common testing point. You will need to identify their purposes, key properties, and typical use cases.
Jump to a section
Imagine you send a confidential contract to a business partner via a courier. To ensure the contract isn't tampered with, you place it in a tamper-evident envelope with a unique seal. The seal is created by taking a fingerprint of the document (a hash) and then encrypting that fingerprint with your private key. The recipient knows your public key and can decrypt the encrypted fingerprint to retrieve the hash. Then they independently compute the hash of the received document. If the two hashes match, the document is authentic and unchanged. If the envelope is opened or the document altered, the hash changes, and the decrypted fingerprint won't match. This is exactly how digital signatures work: hashing ensures integrity, and asymmetric encryption ensures authenticity and non-repudiation. The courier is like the network, the seal is the digital signature, and the fingerprint is the hash.
What is Hashing?
Hashing is a one-way cryptographic function that takes an input (or 'message') and returns a fixed-size string of bytes, typically a digest. The output is called a hash value, hash code, digest, or simply hash. The process is deterministic: the same input always produces the same hash. However, it is computationally infeasible to reverse the process (i.e., find an input that produces a given hash) or to find two different inputs that produce the same hash (collision resistance).
Why Hashing Exists
Hashing is used to verify data integrity. When you download a file, the provider may publish the file's hash. After downloading, you compute the hash yourself; if they match, the file has not been corrupted or tampered with. In security, hashing is used for storing passwords (instead of plaintext), ensuring message integrity in protocols like TLS, and as a building block for digital signatures.
How Hashing Works Internally
A hash function processes data in blocks. For example, SHA-256 (Secure Hash Algorithm 256-bit) processes 512-bit (64-byte) blocks. The algorithm includes initializing internal state, processing each block with a compression function that mixes the block with the current state, and finally outputting the 256-bit digest. Common hash functions include:
MD5 (128-bit digest) – broken, not collision-resistant
SHA-1 (160-bit) – deprecated, collision attacks demonstrated
SHA-2 family (SHA-224, SHA-256, SHA-384, SHA-512) – currently secure
SHA-3 family – newest standard
Key Properties of Hash Functions
Deterministic: Same input always yields same hash.
Fast computation: The hash is quick to compute.
Preimage resistance: Given a hash, it is infeasible to find any input that hashes to that value.
Second preimage resistance: Given an input, it is infeasible to find another input with the same hash.
Collision resistance: It is infeasible to find any two different inputs with the same hash.
What is a Digital Signature?
A digital signature is a cryptographic mechanism that provides authentication, integrity, and non-repudiation. It is created by signing a hash of the message with the signer's private key. The signature can be verified by anyone with the signer's public key.
How Digital Signatures Work
The process involves two phases: signing and verification.
Signing: 1. The sender computes a hash of the message. 2. The sender encrypts the hash with their private key (using an asymmetric encryption algorithm like RSA or elliptic curve cryptography). The encrypted hash is the digital signature. 3. The sender attaches the signature to the message (or sends it separately).
Verification: 1. The recipient computes the hash of the received message. 2. The recipient decrypts the signature using the sender's public key to obtain the original hash. 3. The recipient compares the two hashes. If they match, the message is authentic and untampered; if not, the message or signature is invalid.
Important: A digital signature does NOT encrypt the message itself. It only signs the hash. The message may be sent in plaintext or encrypted separately.
Key Components
Private Key: Known only to the signer. Used to create the signature.
Public Key: Shared publicly. Used to verify the signature.
Hash Function: Produces a fixed-size digest of the message.
Signature Algorithm: E.g., RSA with SHA-256, ECDSA (Elliptic Curve Digital Signature Algorithm) with SHA-256.
Common Use Cases
Code Signing: Software publishers sign their code to prove authenticity and integrity.
Email Signing: S/MIME uses digital signatures to sign emails.
Document Signing: PDFs and other documents can be signed.
Authentication: TLS certificates use digital signatures to prove identity.
Hashing vs. Encryption
Hashing: One-way, irreversible. Output fixed size. No key needed.
Encryption: Two-way (reversible). Output size can vary. Requires a key.
Exam Trap: Many candidates confuse hashing with encryption. Remember: hashing is for integrity, encryption is for confidentiality.
Salting
When hashing passwords, a random value called a 'salt' is added to the password before hashing. This prevents attackers from using precomputed rainbow tables. The salt is stored alongside the hash. Each user gets a unique salt. Even if two users have the same password, their hashes will differ.
Digital Signature Algorithms
RSA: Based on integer factorization. Common key sizes: 2048, 4096 bits.
DSA: Digital Signature Algorithm, based on discrete logarithm.
ECDSA: Elliptic curve variant, more efficient for same security level.
EdDSA: Edwards-curve Digital Signature Algorithm (e.g., Ed25519).
Verification Commands
On Linux, you can compute SHA-256 hash:
sha256sum filenameTo create and verify a digital signature using OpenSSL:
Generate private key:
openssl genpkey -algorithm RSA -out private.pem -pkeyopt rsa_keygen_bits:2048Extract public key:
openssl pkey -in private.pem -pubout -out public.pemSign a file:
openssl dgst -sha256 -sign private.pem -out signature.bin file.txtVerify signature:
openssl dgst -sha256 -verify public.pem -signature signature.bin file.txtInteraction with Related Technologies
TLS: Digital signatures are used in certificate validation. The server presents a certificate signed by a Certificate Authority (CA). The client verifies the signature using the CA's public key.
Azure AD: Uses hashing for password sync (hash of password is synced, not plaintext).
Microsoft Authenticode: Code signing uses digital signatures.
Key Defaults and Values
SHA-256 produces a 256-bit (32-byte) hash.
RSA 2048-bit is the minimum recommended key size.
Salt length for password hashing is typically 16-32 bytes.
Common hash functions in Microsoft: SHA-256, SHA-384, SHA-512.
Trap Patterns
Trap 1: Thinking digital signatures encrypt the message. They do not; they only sign the hash.
Trap 2: Confusing hashing with encryption. Hashing is one-way; encryption is two-way.
Trap 3: Believing that a hash alone provides authentication. It does not; it only provides integrity. Authentication requires a digital signature or MAC.
Trap 4: Assuming MD5 is still secure. It is not collision-resistant and should not be used.
Summary
Hashing and digital signatures are distinct but complementary. Hashing ensures data integrity; digital signatures add authentication and non-repudiation. On the SC-900 exam, be prepared to identify their purposes, properties, and typical applications.
Hash the original message
The sender applies a cryptographic hash function, such as SHA-256, to the entire message. This produces a fixed-size digest (e.g., 256 bits) that uniquely represents the message. Even a single bit change in the message would produce a completely different hash. The hash is computed using a standard algorithm; no key is involved at this stage.
Encrypt hash with private key
The sender encrypts the hash using their private key with an asymmetric encryption algorithm like RSA. The encrypted hash becomes the digital signature. This step binds the signer's identity to the message because only the sender possesses the private key. The signature is typically stored as a separate file or appended to the message.
Send message and signature
The sender transmits the original message (which may be plaintext or encrypted) along with the digital signature to the recipient. The transmission can be over an insecure channel because the signature provides integrity and authentication, not confidentiality. The recipient receives both the message and the signature.
Recipient hashes received message
The recipient independently computes the hash of the received message using the same hash function that the sender used (e.g., SHA-256). This produces a hash value that reflects the exact content of the message as received. If the message was altered in transit, this hash will differ from the sender's original hash.
Decrypt signature with public key
The recipient decrypts the digital signature using the sender's public key. This yields the original hash that the sender computed and then encrypted. Decryption only works if the signature was created with the corresponding private key, confirming the sender's identity. The decrypted hash is a fixed-size value.
Compare the two hashes
The recipient compares the hash they computed from the received message with the hash obtained by decrypting the signature. If the two hashes match exactly, the message is authentic (signed by the claimed sender) and has not been tampered with. If they do not match, the signature verification fails, indicating either tampering or a different signer.
Enterprise Scenario 1: Code Signing in Microsoft Intune
Organizations use code signing to ensure that software deployed via Microsoft Intune or Group Policy is from a trusted publisher. Developers sign their application binaries using a code signing certificate issued by an internal PKI or a public CA. When Intune distributes the app to devices, Windows checks the digital signature. If the signature is invalid or the certificate is revoked, the installation is blocked. This prevents malware from masquerading as legitimate software. In production, code signing is integrated into build pipelines using tools like Azure DevOps, where the signing step runs after compilation. Performance considerations include the time to sign (a few seconds per binary) and the overhead of certificate management (key storage in HSMs). Common misconfigurations include using expired certificates, not timestamping signatures (so they expire when the certificate does), or allowing unsigned code execution via policy overrides.
Enterprise Scenario 2: Email Signing with S/MIME
In regulated industries (finance, healthcare), organizations require digital signatures on emails to ensure non-repudiation. S/MIME (Secure/Multipurpose Internet Mail Extensions) uses digital signatures based on X.509 certificates. When a user sends an email, their email client (Outlook, Exchange Online) computes a hash of the message body and attachments, then signs it with the user's private key. The recipient's client verifies the signature using the sender's public key, which is obtained from the sender's certificate. This assures the recipient that the email truly came from the claimed sender and was not altered. In Exchange Online, administrators can enforce S/MIME signing via transport rules. A common issue is certificate revocation: if a certificate is compromised, the administrator must revoke it and all signed emails after revocation become unverifiable. Also, if users do not have the sender's certificate in their trusted store, verification fails, leading to confusion.
Enterprise Scenario 3: Document Signing in Microsoft 365
Microsoft 365 supports digital signatures on documents via Azure Information Protection (AIP) and the Rights Management Service (RMS). When a user signs a document, the service creates a hash of the document content and signs it with the user's identity key. The signature is embedded in the document metadata. Verification occurs when the document is opened: the RMS client rehashes the content and compares it with the decrypted signature. This ensures that even if the document is saved elsewhere, its integrity and origin can be verified. In production, this is configured via sensitivity labels that apply signing automatically. Performance is minimal because hashing is fast. A common misconfiguration is failing to assign the correct label, so documents are not signed. Another issue is that signing does not encrypt the document; organizations that need confidentiality must also apply encryption, which is a separate label setting.
What SC-900 Tests
SC-900 objective 1.1 covers 'Describe the concepts of security, compliance, and identity.' Under this, you must understand the purpose of hashing and digital signatures. Specifically, the exam expects you to:
Differentiate between hashing and encryption.
Identify that hashing provides integrity, not confidentiality.
Recognize that digital signatures provide authentication, integrity, and non-repudiation.
Know that a digital signature is created by encrypting a hash with a private key.
Understand that hashing is one-way; encryption is reversible with a key.
Common Wrong Answers and Why
Wrong Answer 1: 'Hashing ensures confidentiality.' Candidates confuse hashing with encryption because both produce seemingly random output. Reality: Hashing is one-way and does not protect the original data from being derived; it only verifies integrity.
Wrong Answer 2: 'Digital signatures encrypt the entire message.' This is a classic trap. Candidates think signing equals encrypting. Reality: Only the hash is encrypted; the message itself may be sent in plaintext.
Wrong Answer 3: 'A hash can be used to verify the sender's identity.' A hash alone provides no authentication; anyone can compute the same hash if they have the same input. Authentication requires a digital signature or a MAC (Message Authentication Code).
Wrong Answer 4: 'MD5 is still acceptable for security.' Some older systems still use MD5, but the exam expects you to know it is broken. Always choose SHA-2 or SHA-3.
Specific Values and Terms
SHA-256: 256-bit hash (32 bytes).
RSA key sizes: 2048-bit minimum recommended.
Salt: random value added to password before hashing.
Non-repudiation: the signer cannot deny signing.
Edge Cases and Exceptions
Collision attacks: If a hash function is broken (like MD5, SHA-1), two different inputs can produce the same hash, breaking integrity. The exam may ask about deprecated algorithms.
Hash length extension attacks: Some hash functions (like SHA-1, SHA-256) are vulnerable to length extension, which can be exploited if used improperly. HMAC (Hash-based Message Authentication Code) mitigates this.
Quantum computing: The exam may mention that quantum computers threaten RSA and ECC but not hash functions (Grover's algorithm reduces security but does not break completely).
How to Eliminate Wrong Answers
If the question asks about 'confidentiality,' eliminate hashing; hashing does not provide confidentiality.
If the question asks about 'verifying the sender,' look for 'digital signature' or 'private key.'
If the question says 'one-way,' it is hashing.
If the question says 'reversible with a key,' it is encryption.
Always check the algorithm names: MD5 and SHA-1 are weak; SHA-256 and SHA-3 are strong.
Hashing is a one-way function that produces a fixed-size digest; it provides integrity, not confidentiality.
A digital signature is created by encrypting the hash of a message with the signer's private key.
Digital signatures provide authentication, integrity, and non-repudiation.
Common hash functions: SHA-256 (256-bit), SHA-384, SHA-512. MD5 and SHA-1 are deprecated.
Salting adds a random value to passwords before hashing to prevent rainbow table attacks.
The SC-900 exam tests the difference between hashing and encryption, and the purpose of digital signatures.
Verification of a digital signature involves decrypting the signature with the public key and comparing hashes.
These come up on the exam all the time. Here's how to tell them apart.
Hashing
One-way function; irreversible
Output is fixed size (e.g., 256 bits for SHA-256)
No key required
Provides integrity (data unchanged)
Used for password storage, file integrity, digital signatures
Encryption
Two-way function; reversible with key
Output size can vary (e.g., ciphertext same size as plaintext or larger)
Requires an encryption key (symmetric or asymmetric)
Provides confidentiality (data hidden)
Used for secure communication, data at rest protection
Mistake
Hashing is the same as encryption.
Correct
Hashing is a one-way function that produces a fixed-size output; encryption is a two-way function that requires a key to decrypt. Hashing provides integrity; encryption provides confidentiality.
Mistake
A digital signature encrypts the entire message.
Correct
A digital signature is created by encrypting only the hash of the message with the signer's private key. The message itself may be sent in plaintext or encrypted separately.
Mistake
MD5 is still secure for hashing passwords.
Correct
MD5 is cryptographically broken and vulnerable to collision attacks. It should not be used for any security purpose. Use SHA-256 or a dedicated password hashing function like bcrypt or Argon2.
Mistake
Hashing provides authentication.
Correct
Hashing alone does not authenticate the source. Anyone can compute the same hash if they have the same input. Authentication requires a digital signature (using asymmetric keys) or a MAC (using a shared secret).
Mistake
Salting is optional for password hashing.
Correct
Salting is essential to prevent rainbow table attacks. A unique random salt should be added to each password before hashing. Without a salt, attackers can precompute hashes for common passwords.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Hashing is a one-way function that produces a fixed-size digest; it is irreversible and used for integrity. Encryption is a two-way function that requires a key to decrypt; it is used for confidentiality. On the SC-900 exam, if a question asks about 'confidentiality,' choose encryption; if it asks about 'integrity,' choose hashing.
Non-repudiation means the signer cannot deny having signed the message. Since the signature is created with the signer's private key, which only they possess, and can be verified with their public key, the signer cannot plausibly deny signing. This is legally binding in many jurisdictions.
Salting prevents attackers from using precomputed rainbow tables (lists of hashes for common passwords). By adding a unique random salt to each password before hashing, even if two users have the same password, their hashes will differ. The salt is stored with the hash. Without salt, an attacker can quickly crack many passwords using a single table.
A hash (like SHA-256) uses no key; anyone can compute it. A MAC (Message Authentication Code) uses a shared secret key; only parties with the key can create or verify it. A MAC provides integrity and authentication (if the key is secret), while a hash alone provides only integrity.
No. A digital signature only signs the hash of the message; it does not encrypt the message itself. To achieve confidentiality, you must encrypt the message separately, for example using symmetric encryption. Digital signatures are often combined with encryption (e.g., in S/MIME) but they serve different purposes.
2048 bits. RSA 1024-bit is considered weak and should not be used. For higher security, 4096 bits is common. The SC-900 exam may test that 2048-bit is the minimum for compliance with standards like NIST.
A collision occurs when two different inputs produce the same hash. This breaks the integrity guarantee because an attacker could substitute a malicious file that hashes to the same value as a legitimate one. Collision-resistant hash functions (like SHA-256) are designed to make finding collisions computationally infeasible. MD5 and SHA-1 are known to have practical collision attacks.
You've just covered Hashing and Digital Signatures — now see how well it sticks with free SC-900 practice questions. Full explanations included, no account needed.
Done with this chapter?