HashUtil (Identity Leak)

1. Overview

The HashUtil module provides a minimal cryptographic utility used across BastionGuard for generating deterministic hashes. Its primary use within the codebase is to derive a stable, non-reversible identifier (e.g., for email identities in the Identity Leak subsystem) without storing or exposing raw sensitive values.

The module currently implements:

  • SHA-256 hashing of arbitrary input strings
  • Hexadecimal string encoding of the resulting digest

2. Dependencies

  • OpenSSL – cryptographic hashing (SHA256())
  • C++ standard library – string handling and stream formatting

3. sha256(input)

3.1 Function Signature

std::string HashUtil::sha256(const std::string& input)

Computes the SHA-256 digest of the provided input string and returns it as a lowercase hexadecimal string.

3.2 Hash Computation

The function uses OpenSSL’s SHA-256 implementation:

SHA256(
  reinterpret_cast<const unsigned char*>(input.c_str()),
  input.size(),
  hash
);

Characteristics:

  • Digest size: 256 bits (32 bytes)
  • Binary digest stored in a fixed-size local buffer
  • No intermediate heap allocations

3.3 Hexadecimal Encoding

The raw digest bytes are converted into a hexadecimal string:

  • Each byte is rendered as two hexadecimal characters
  • Leading zero padding is enforced via std::setw(2) and std::setfill('0')
  • Output uses lowercase hexadecimal digits

The final output string length is always:

64 characters

(2 characters × 32 bytes).

4. Return Semantics

The function always returns a string of fixed length (64 characters). There is no error path or exception handling in the current implementation.

Behavioral notes:

  • Empty input yields the SHA-256 hash of the empty string
  • The same input always produces the same output
  • No salt or keying is applied

5. Usage Context

Within BastionGuard, HashUtil::sha256() is typically used for:

  • Hashing email addresses before persistence in local databases
  • Generating stable identifiers for privacy-preserving lookups
  • Avoiding storage of plaintext personally identifiable information (PII)

The function is not intended for password hashing or authentication workflows.

6. Security Considerations

  • One-way hash: SHA-256 is cryptographically one-way but not resistant to dictionary attacks without salting
  • No salt: identical inputs across users or systems will produce identical hashes
  • Not for passwords: this function must not be used for password storage or verification
  • PII protection: hashing reduces direct exposure but does not fully anonymize low-entropy inputs (e.g., common email addresses)

If stronger privacy guarantees are required, consider:

  • Adding a per-installation or per-user salt
  • Using keyed hashing (HMAC) for internal identifiers

7. Performance Characteristics

  • Time complexity: O(n) over input size
  • Memory usage: constant
  • Suitable for frequent use in UI and background threads

The implementation is lightweight and safe for high-frequency calls.

Published on:
Last updated on: