Lesson A14.3
Hashing is not a weaker form of encryption. It solves a different problem. A good integrity design asks what object should remain unchanged, who provides the trusted reference, when verification happens, and what the system does when evidence does not match.
Password-storage discussion remains conceptual and defensive. This lesson does not provide hash cracking, password guessing, credential attacks, or instructions for defeating stored verifiers.
Lesson Progress
High School Advanced • A14: Cryptography and Key Management Concepts • Lesson 3 of 10
Readiness Check
0/4 ready
Professional Hook
Computing a hash is easy. Building a trustworthy integrity process is harder. A release pipeline needs a trusted expected value, version context, an accountable owner, a decision point, and a response when the digest does not match. Without those pieces, a hash may exist without creating meaningful assurance.
Integrity is a relationship between an object, a trusted reference, a verification event, and a decision.
Learning Objectives
Explain hashing as a one-way transformation used for integrity and comparison purposes, and distinguish it clearly from reversible encryption.
Explain salting conceptually as a way to make stored password-verifier values less reusable across accounts, without teaching cracking or attack procedures.
Evaluate fictional integrity designs for files, software artifacts, configuration packages, records, exports, and stored password verifiers using purpose, owner, evidence, lifecycle, and trust context.
Identify limitations such as assuming a hash proves authorship, treating identical digests as identity proof, relying on stale integrity evidence, or confusing secrecy with integrity.
Build an Integrity Protection Review that becomes the third artifact in the A14 Key-Management Design Recommendation.
Core Concepts
Produces a fixed-size digest from input data using a one-way transformation.
Useful for
Integrity comparison, content identification within a trusted workflow, password-verifier construction, artifact checks, evidence correlation.
Not for
Recovering the original data or providing confidentiality.
Architecture question
What decision will this digest support, and who provides the trusted reference value?
Transforms readable data into protected data that authorized parties can reverse with the appropriate key relationship.
Useful for
Confidentiality for stored or transmitted information.
Not for
Proving authorship by itself or replacing access control.
Architecture question
Who is authorized to decrypt, and how is the key lifecycle governed?
Adds unique, non-secret random data to a password-verifier process so identical passwords do not produce identical stored verifier values across accounts.
Useful for
Reducing reuse of precomputed comparisons and preventing identical password choices from producing identical stored outputs.
Not for
Replacing a strong password-hashing design, authentication controls, or account protection.
Architecture question
Does each stored verifier have an appropriate unique salt and a governed password-storage method?
Provides integrity plus signer-authenticity evidence using an asymmetric signing relationship.
Useful for
Software artifacts, approved documents, release packages, signed records, trusted publishing workflows.
Not for
Keeping the signed data secret.
Architecture question
Who owns the signing key, who trusts the verifier, and what lifecycle governs the signing relationship?
Integrity Model
Examples: File, release artifact, configuration package, exported report, audit record, stored verifier, message, backup manifest.
Why it matters: Integrity design should start with the object whose unexpected change matters.
Examples: Release pipeline, approved publisher, data platform, backup system, configuration owner.
Why it matters: A digest is meaningful only when the comparison value itself comes from a trusted source.
Examples: Before deployment, during restore, during ingestion, during package validation, during account verification.
Why it matters: Integrity controls need a defined decision point, not just a stored hash nobody checks.
Examples: Block release, flag review, quarantine package, stop restore, mark evidence Unknown.
Why it matters: A control is incomplete when mismatches are detected but no action is defined.
Examples: Signed manifest, trusted inventory, controlled metadata store, verified release record.
Why it matters: An attacker-independent reference is necessary for trustworthy integrity conclusions.
Examples: Current artifact digest, stale package manifest, outdated inventory, expired review.
Why it matters: Integrity evidence that no longer matches the current object or version can create false confidence.
Password Storage
Password storage is one of the most important places to understand the difference between encryption and hashing. A verifier should allow the system to check a login without storing a plaintext or routinely recoverable copy of the user's password.
A strong password-storage architecture does not need to recover the original password. It stores a verifier derived through a one-way process.
Design note: The architecture should be able to verify a legitimate login without keeping a recoverable copy of the password.
A unique salt helps ensure that two accounts using the same password do not produce the same stored verifier value.
Design note: The salt is not a secret; its value is in making each verification input unique.
Password verification should use a dedicated password-hashing design rather than a general fast digest intended for file integrity.
Design note: The lesson stays conceptual and does not provide cracking, benchmarking, or attack instructions.
Authentication logs should record safe metadata about the decision, not the user's secret password.
Design note: Monitoring can show account, time, policy outcome, and source health without recording credentials.
If a user forgets a password, a secure architecture generally resets the credential through a governed identity process rather than recovering the original secret.
Design note: Recovery workflows should preserve identity assurance and accountability.
Password-verifier formats may need to evolve as policy and standards change.
Design note: The architecture should support safe migration without exposing user passwords.
Safety boundary
This lesson explains defensive password-storage architecture only. It does not provide password cracking, hash cracking, guessing strategies, wordlists, attack tooling, or methods for obtaining credentials.
Evidence Types
Strength: Useful when a trusted reference digest is available and the comparison point is well controlled.
Limitation: A matching digest supports content consistency but does not prove who created the content.
Strength: Adds signer-authenticity evidence to integrity when the signing key and trust chain are governed.
Limitation: Trust still depends on signer ownership, key lifecycle, and verifier trust.
Strength: Connects expected artifact names, versions, digests, and release state.
Limitation: The manifest itself must come from a trusted source.
Strength: Can support comparison between expected and observed package content.
Limitation: Repository ownership and update process remain part of the trust model.
Strength: Supports confidence that backup content is consistent before restore.
Limitation: Integrity alone does not prove the backup can be decrypted or restored successfully.
Strength: Can record when integrity checks occurred, which version was evaluated, and what decision followed.
Limitation: Audit evidence should avoid secrets and remain subject to source-health and retention controls.
Design Principles
Hashing is one-way and usually supports comparison or verification; encryption is reversible with the proper key.
Review: Can the team explain why the control needs comparison rather than secrecy?
A digest becomes useful only when the expected value comes from a source the architecture trusts.
Review: Who owns and protects the expected digest or manifest?
Two parties can compute the same digest for the same content.
Review: If signer identity matters, is a digital signature or another authenticated trust mechanism required?
A salt separates password-verifier inputs so identical passwords do not produce identical stored values.
Review: Does each verifier have a unique salt and a purpose-built password-hashing method?
File integrity values are often designed for efficient comparison, while password verification should use a dedicated password-hashing design.
Review: Is the chosen mechanism appropriate to the security problem?
Detecting a changed artifact is useful only if the architecture defines what happens next.
Review: Does a mismatch block, quarantine, alert, or require review?
A correct digest for version 4 does not verify version 5.
Review: Are object version, digest, timestamp, and owner connected in the evidence?
The same data may require encryption for secrecy and hashing/signatures for integrity or authenticity.
Review: Does the architecture separately identify each protection goal?
Vocabulary
A fixed-size digest produced by applying a one-way hash function to input data.
Another term for the output of a hash function.
A one-way mathematical function that maps input data to a fixed-size output used for comparison and related security goals.
Unique, non-secret random data combined with password input before deriving a stored verifier.
Stored one-way data used to check whether a supplied password is correct without storing a recoverable plaintext password.
Confidence that data or an artifact has not changed unexpectedly.
A trusted expected hash value used to compare against an observed object.
A structured record that may list artifacts, versions, digests, and other release or package metadata.
A conceptual condition where different inputs produce the same hash output.
The security property that makes it infeasible to recover an original input merely from its hash output.
A condition where the observed digest differs from the trusted expected digest.
Metadata showing what object was checked, against which trusted reference, when, by which system, and with what result.
Fictional Integrity Register
Purpose
Verify release artifact integrity before deployment
Method
Digest comparison against trusted release manifest
Reference owner
Release Engineering
Object owner
Application Team
Decision point
Before deployment
Mismatch action
Block deployment and open release review
Freshness
Current for release version 8.4
Evidence
Manifest ID + artifact version + verification event
Architecture concern
Digest match proves consistency with the trusted manifest, not signer identity by itself.
Purpose
Detect unexpected package changes
Method
Digest comparison against approved baseline record
Reference owner
Platform Security
Object owner
Infrastructure Team
Decision point
Before promotion between environments
Mismatch action
Hold promotion and require configuration-owner review
Freshness
Current
Evidence
Baseline version + digest + approval record
Architecture concern
The baseline repository itself is part of the trust boundary.
Purpose
Verify passwords without storing recoverable plaintext credentials
Method
Purpose-built password hashing with unique salt per account
Reference owner
Identity Platform
Object owner
Identity Security
Decision point
Authentication verification
Mismatch action
Authentication fails without logging the password
Freshness
Current policy
Evidence
Verifier format version + salt-present flag + migration state
Architecture concern
Authentication logs must never record plaintext passwords or reusable secrets.
Purpose
Verify backup content consistency before restoration
Method
Versioned digest manifest
Reference owner
Resilience Team
Object owner
Backup Platform
Decision point
Restore preparation
Mismatch action
Stop restore and review affected backup set
Freshness
Current for last tested backup
Evidence
Backup ID + manifest version + restore-check record
Architecture concern
Integrity evidence does not replace decryption-key availability or a full restore test.
Purpose
Detect unexpected changes before ingestion
Method
Digest comparison supplied through approved partner workflow
Reference owner
Integration Owner
Object owner
Partner Integration Service
Decision point
Before import
Mismatch action
Quarantine package and request partner review
Freshness
Partner reference process under review
Evidence
Package ID + digest + sponsor record
Architecture concern
The partner reference channel needs renewed trust documentation.
Purpose
Historical file consistency checking
Method
Old digest list stored beside archive
Reference owner
Unknown
Object owner
Reporting Operations
Decision point
Manual checks only
Mismatch action
Undefined
Freshness
Stale
Evidence
Partial digest list with no current owner
Architecture concern
A digest stored beside the data with Unknown ownership is not a strong trusted reference.
Purpose
Verify approved export content before transfer
Method
Versioned digest + approved export manifest
Reference owner
Analytics Product Owner
Object owner
Export Service
Decision point
After generation, before transfer
Mismatch action
Cancel transfer and rebuild from approved source
Freshness
Current
Evidence
Export job + manifest + digest + policy decision
Architecture concern
Confidentiality and authorization remain separate from the integrity check.
Fake Dashboard
Fictional hashing, password-verifier, manifest, and integrity evidence summary
Integrity records reviewed
7
Release, configuration, password verification, backups, partner imports, legacy archives, and exports
Confirmed
4
Modern release, configuration, password, and backup integrity controls have current evidence
Conditional
2
Partner reference trust and export workflow need continued review
Blocked
1
Legacy digest list lacks trusted ownership and defined mismatch handling
Fake SOC Alert
Source: Fictional Integrity Architecture Review • Time: 10:01
Hashing vs. Encryption
Use when the architecture needs a one-way comparison or verifier. The original input is not intended to be recovered from the digest.
Use when authorized parties need to recover protected data through a governed key relationship.
The same object can need both.
A backup package might be encrypted for confidentiality and also verified against an integrity manifest before restoration.
Fake Log Panel
[08:02] INT-01 release-package manifest=TRUSTED digest=MATCH version=8.4 state=CONFIRMED [08:25] INT-02 config-baseline reference=CURRENT digest=MATCH state=CONFIRMED [08:49] INT-03 password-verifier salt=UNIQUE format=CURRENT plaintext_logging=NO state=CONFIRMED [09:13] INT-04 backup-manifest digest=MATCH restore_test=CURRENT state=CONFIRMED [09:37] INT-05 partner-import reference_trust=REVIEW state=CONDITIONAL [10:01] INT-06 legacy-archive reference_owner=UNKNOWN mismatch_action=UNDEFINED state=BLOCKED [10:25] INT-07 export-package digest=MATCH authorization=SEPARATE state=CONDITIONAL
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Common Mistakes
Why it fails: A team assumes a hash can later be reversed to recover the original data.
Better approach: Use hashing for one-way verification and encryption for reversible confidentiality.
Why it fails: A matching digest is treated as proof of who created the content.
Better approach: Use authenticated publishing or digital signatures when signer identity matters.
Why it fails: An attacker or uncontrolled process could change both the object and the expected digest.
Better approach: Protect the reference through a separate trusted workflow or signed manifest.
Why it fails: No unique salt is used, so identical password inputs may produce identical stored outputs.
Better approach: Use unique salts with a purpose-built password-hashing design.
Why it fails: Authentication telemetry accidentally stores reusable credentials.
Better approach: Log only safe decision metadata and never record plaintext passwords.
Why it fails: The system computes integrity checks but deployment or ingestion continues even when they fail.
Better approach: Define an explicit block, quarantine, review, or remediation action.
Why it fails: A reference from an older artifact is reused for a different release.
Better approach: Bind integrity evidence to object version and lifecycle.
Why it fails: A team assumes hashing a file prevents unauthorized reading.
Better approach: Use encryption for confidentiality and integrity controls for change detection.
Scenario Decision Lab
A legacy archive has an old digest list stored in the same location. Nobody owns the list, and no process explains what to do when a digest differs.
Scenario Decision Lab
A fictional identity platform needs to verify passwords without keeping a recoverable copy of each user's password.
Safe Fictional Lab
Use fictional files, artifacts, manifests, password-verifier records, owners, and synthetic evidence only. Do not test or attack real hashes, accounts, or credentials.
Create at least fifteen fictional integrity-protection records.
Give every record a stable INT ID.
Record the object or data being verified.
State the integrity purpose.
Record the verification method conceptually.
Identify the trusted reference source.
Assign reference owner.
Assign object/application owner.
Record object version.
Record verification decision point.
Record mismatch action.
Record evidence freshness.
Record evidence source.
Classify status as Confirmed, Conditional, Unknown, Blocked, Accepted Risk, or Not Applicable.
Include at least four software or configuration artifacts.
Include at least two backup or restore examples.
Include at least two partner/import/export examples.
Include at least two password-verifier architecture records.
Include at least one signed-integrity example for comparison.
Include at least one untrusted legacy digest reference and keep it Blocked.
Add change triggers for object version, manifest owner, password-verifier format, application, repository, and recovery changes.
Lab boundary
Do not perform password guessing, hash cracking, credential testing, account access, or attempts to defeat real integrity controls. This lab is defensive architecture review only.
Analyze the Evidence
Advanced Challenge
A fictional organization computes hashes for software, backups, configuration packages, and exports, but the expected values are scattered across shared folders with unclear ownership and no version control. Redesign the integrity architecture conceptually.
Object inventory
Integrity purpose
Trusted reference owner
Protected reference source
Object version
Verification event
Mismatch action
Release blocking
Backup restore checks
Partner import quarantine
Signed-manifest use
Password-verifier governance
Salt uniqueness
Safe authentication logging
Evidence freshness
Lifecycle review
A strong redesign should make every integrity conclusion traceable to a trusted expected value, a current object version, a verification event, an accountable owner, and a defined response.
Defender Habits
Skill Check
Check Your Understanding
Choose your answers first. Explanations appear only after submission.
Portfolio Prompt
Create the third artifact for your A14 Key-Management Design Recommendation: a fictional Integrity Protection Review with at least fifteen records. Include INT ID, object/data, integrity purpose, verification method, trusted reference, reference owner, object/application owner, version, decision point, mismatch action, evidence source, freshness, status, concern, next action, and change trigger. Include password-verifier records using only safe architectural metadata.
Confidence / Readiness Reflection
A14.4 adds signer authenticity to integrity through digital signatures. Before continuing, make sure you can explain why a matching hash tells you that content matches a reference but does not, by itself, tell you who signed or published it.
I can distinguish hashing from encryption.
I can explain why integrity needs a trusted reference.
I can explain why a hash does not prove authorship.
I can explain unique salts conceptually in password-verifier storage.
I can evaluate integrity evidence using version, owner, freshness, and mismatch handling.
Portfolio Build Guide
Show exactly which file, package, verifier, backup, export, or record is being checked.
A digest is only useful when the expected value comes from a protected, accountable source.
Record artifact version, manifest version, or verifier-format version so stale evidence is obvious.
Block, quarantine, review, or remediation should be explicit.
Use signatures when the publisher or signer identity matters.
Use fields such as verifier format, salt-present flag, owner, and migration state—never plaintext credentials.
Current, Partial, Stale, Missing, and Unknown should change the decision state.
A14.4 will build on this integrity model by adding signer identity and digital-signature trust.
Key Takeaways
Lesson Safety Boundary
Do not attempt password guessing, hash cracking, credential attacks, account access, real verifier testing, or methods for defeating integrity checks. All password-verifier, digest, manifest, and integrity records in this lesson are fictional and defensive.
Lesson Complete
You now have an integrity model built around one-way hashing, trusted references, version-aware evidence, mismatch decisions, safe password-verifier concepts, salting, and integrity limits. Next, A14.4 focuses on Digital Signatures Conceptually.