Hashing and encryption do different jobs.

Start by naming the question

“Use encryption” is incomplete advice until the problem is clear. Do you want to keep a file confidential, detect a changed download, check whether a password has appeared in a breach corpus or verify a token’s signature? These questions need different operations and different trust assumptions.

A hash produces a fixed-length digest of input bytes. Encryption transforms data so that a suitable key can recover it. A digital signature or message authentication code provides integrity relative to a trusted key. A password-derivation function makes guessing a password more expensive when deriving or checking a key.

Confusing these jobs leads to common mistakes: expecting a checksum to prove a file is harmless, treating a readable JWT as verified, or storing account passwords with one fast general-purpose hash.

A checksum compares bytes

The file-integrity verifier calculates a digest and can compare it with an expected value. When both match, you have evidence that the file agrees with that digest. You still need a reason to trust the expected value. If the same attacker can replace the file and the unsigned checksum, both can match perfectly.

For software distribution, obtain checksums through a trusted release channel and consider verified release signatures where available. Confirm the exact version and file type. An archive and its extracted contents are different byte sequences, so their digests should not be compared as if they represent one interchangeable object.

A malicious program also has a valid SHA-256 digest. The hash identifies content for comparison; it does not analyse that content’s behaviour.

Authenticated encryption protects contents and detects changes

The file vault uses AES-GCM so that decryption also checks an authentication tag. A changed ciphertext, changed authenticated header or wrong password-derived key causes failure. That is more useful than returning unauthenticated garbage and hoping the user notices something is wrong.

Password-based encryption still depends on a strong passphrase. A derivation function with a salt and a meaningful work factor increases the cost of guesses; it cannot create unpredictability in a familiar quote or reused password. Keep the passphrase separate from the package and test a decryption round trip before removing any original.

Encryption also does not provide backup availability. You can lose an encrypted file, forget the passphrase or lose access to the software that understands its format. Plan recovery and retain appropriate implementation documentation for long-term storage.

A breach lookup is a corpus question

The password breach check uses a SHA-1 representation because that is how the provider’s lookup protocol is defined. The browser sends a partial hash and compares returned suffixes locally. SHA-1 in this protocol is a search key, not a recommendation for storing account passwords.

A positive match means the password value appears in the dataset. A negative result does not make the value strong or guarantee it was never leaked. Use independently generated unique passwords and multi-factor authentication regardless of the lookup result.

Keep the trust boundary visible

A correct cryptographic primitive can be embedded in a poor workflow. An untrusted verification key makes a signature result meaningless for your application. A compromised browser can read a file before encryption. A password stored beside its encrypted package can defeat the intended separation.

Choose established algorithms and implementations, then document where keys and expected values come from. Keep claims proportional to the operation performed. The Web Crypto documentation explains the available browser primitives, while OWASP’s password guidance explains why password handling needs more than a fast digest.

Work through a software handoff

Suppose a colleague sends an encrypted archive containing a software package and a checksum. Decrypting the archive successfully shows that it authenticated under the supplied key and format. It does not independently establish that the package is the publisher's intended release.

Compare the extracted package with a trusted release digest or verified signed manifest. Establish why the publisher key or release channel is trusted. A checksum placed inside the same archive can help detect accidental internal inconsistency, but it shares the sender's trust boundary.

Now decide whether the software is appropriate to run. Version support, known vulnerabilities and the intended source remain relevant after every cryptographic comparison passes. The sequence separates confidentiality during transfer, consistency with a release and the decision to execute code.

Record each result with its input and trust source. Avoid a single verified label that hides which step was performed. A recipient should be able to tell whether you checked the archive password, the package digest, a publisher signature or all three.

Agree on bytes before comparing cryptographic output

Text, files and parsed data are not interchangeable inputs. A UTF-8 string with a final newline differs from the same visible text without it. A reformatted JSON object can preserve application meaning while changing the exact bytes a signature covered.

When an integration disagrees, compare algorithm, encoding, input length and normalisation rules. For HMAC, also compare the key representation and message construction. A correct primitive supplied with different bytes should produce a different result; that is not a cryptographic failure.

Use published test vectors and small synthetic examples to isolate the boundary. Once the basic implementation agrees, test the actual application path, including middleware and file handling. A helper tested in isolation can still receive transformed input after a framework change.

Distinguish shared secrets from public verification keys

With HMAC, every party holding the shared key can create a valid code. That can fit a webhook integration, but it does not provide the same attribution model as a signature verified with a public key. Choose the mechanism according to who must be able to create and verify messages.

With a digital signature, trust in the public key must come from an independent process appropriate to the application. A token that supplies its own untrusted key cannot establish the issuer you intended merely because the mathematics verifies. Bind key selection to the expected issuer and allowed algorithms.

Keys also need lifecycle management. Rotation, expiry and revocation can change which outputs should be accepted. A previously valid signature or token may remain mathematically valid while the application should reject it because the key or authorisation has been retired.

Test recovery before depending on encryption

Encrypt a disposable file, save the output and decrypt the saved copy in a fresh operation. Compare the recovered bytes with the original digest. This checks both the cryptographic path and the practical download, storage and password-retrieval steps.

Keep a compatible decryptor and format documentation for long-lived data. Encryption algorithms alone do not define the file container, metadata or key derivation. Another application supporting AES may still be unable to read a tool-specific archive.

Plan device loss and account loss separately from confidentiality. An encrypted backup stored on the only device you own is still vulnerable to that device failing. A recovery password stored only inside the encrypted backup creates a circular dependency. Test the whole recovery route while the source remains available.

Frequently asked questions

Can I decrypt a SHA-256 hash?

A hash is not an encrypted copy of the original message. Converting its hexadecimal display back to bytes recovers only the digest. For predictable inputs, an attacker can try guesses and compare hashes, which is one reason a fast unsalted digest is unsuitable for password storage.

Does Base64 protect a password?

No. Base64 and hexadecimal are encodings that can be reversed without a secret. They help represent bytes in text formats. Confidentiality requires an appropriate encryption design, and account passwords require secure storage and verification practices beyond a reversible encoding.

Why does authenticated encryption reject a wrong password?

The wrong password derives a different key, so authentication of the ciphertext and associated data fails under the format's rules. The interface should report failure rather than return untrusted plaintext. The failure alone may not distinguish a wrong password from corrupted or incompatible encrypted data.

Is a passing JWT signature enough to accept the token?

The application also needs an expected issuer, audience, allowed algorithm, trusted key and appropriate time and claim checks. A valid signature under an arbitrary supplied key does not establish the authority your service requires. Keep decoding, verification and acceptance as distinct stages.

Why is SHA-1 used in a breach query if it is not recommended for password storage?

The service defines a hash-based lookup protocol using that representation. It is not storing your account verifier through this tool. Password storage is a separate problem requiring a suitable password-hashing scheme, salts and work factors. The same algorithm name can appear in different workflows with different purposes.

Can a hash detect who modified a file?

A mismatch shows inconsistency with the expected digest; it does not identify the person or process responsible. Attribution needs other evidence such as trusted signatures, access logs or a controlled chain of custody. Do not turn a byte difference into an unsupported claim about an actor.

What should I keep in a cryptographic verification record?

Record the exact artifact or message definition, algorithm, output representation, expected-value or key source, time and result. For encryption, include the format and recovery test without exposing the secret. These details make the conclusion reproducible and reveal its practical limits.