Digest and security properties
A cryptographic hash function maps an arbitrary-length message to a fixed-length digest. Preimage resistance makes it hard to find a message for a chosen digest. Second-preimage resistance makes it hard to find another message with the digest of a given message. Collision resistance makes it hard to find any two different messages with the same digest.
These are computational properties with an assumed security strength. A digest is not encryption and cannot be reversed through a decryption key. It also does not prove who created the message.
Correct uses
Hashes support digital signatures, message authentication constructions, content addressing, integrity comparison, key derivation constructions, and protocol transcripts. The complete construction matters. Use a standard library and an approved algorithm for the intended protocol.
For password storage, use a password-hashing function with a salt and suitable work factor. A fast general-purpose hash is designed for speed and lets an attacker test guesses quickly. For message authenticity, use a MAC or digital signature. Publishing an unkeyed digest next to a file lets an attacker replace both.
Representation and domain
Hash the exact defined byte representation. Ambiguous serialization can let two components assign different meaning to the same bytes or different bytes to the same logical object. Include purpose, version, algorithm, and relevant context when one digest construction serves several domains.
Do not truncate a digest without accounting for the reduced security strength. Do not compare secret-derived values with a variable-time operation when timing can expose useful information.
Failure and residual risk
A deprecated or weak algorithm can lose collision resistance while retaining some other properties. A strong hash cannot detect malicious replacement when the expected digest is also attacker-controlled. Canonicalization, encoding, duplicate fields, and parser differences can invalidate an integrity claim. A digest reveals equality and can support guessing when the input space is small.
Pomerium boundary
Pomerium uses standard cryptographic constructions in its protocols and signed assertions. Applications must not treat an unkeyed hash of an identity header, policy value, or artifact as proof that it came from Pomerium. Verify the documented signature or authenticated channel and validate issuer, audience, purpose, and freshness.
Evaluation checklist
- Which exact hash property does the use require?
- Is the algorithm approved and strong enough for the expected lifetime?
- Is the hashed byte representation unambiguous and versioned?
- Does the design need authenticity, a password work factor, or encryption instead?
- Can an attacker replace the expected digest or guess a small input space?
- Does truncation, reuse across domains, or comparison behavior reduce the intended security?
