Salted SHA-256 Pseudonymization

• Salted SHA-256 pseudonymization is a cryptographic method that uses a secret salt with HMAC-SHA256 to irreversibly transform sensitive identifiers into unique pseudonyms.
• It preserves data structure in formats like JSON and XML while supporting controlled reversibility and audit trails for compliance.
• The approach defends against brute-force, linkage, and quantum attacks, offering strong collision resistance and robust privacy protection.

Salted SHA-256 pseudonymization is a cryptographic technique for transforming sensitive digital identifiers, such as personally identifiable information (PII) or network artifacts, into irreversible pseudonyms for privacy-preserving data handling. By introducing a secret key (salt) into the SHA-256 hashing or HMAC process, this method offers strong security against brute-force, linkage, and preimage attacks, both in classical and quantum settings, while supporting practical workflows such as structure-preserving document conversion and controlled reversibility for authorized users.

1. Mathematical Formulation

Let $K \in \{0,1\}^*$ denote the secret key (salt) and $m \in \{0,1\}^*$ the input PII string. The pseudonymization function is defined as: $$\mathrm{Pseudonym}(m) = \mathrm{HMAC\_SHA256}(K, m)$$ with $\mathrm{HMAC\_SHA256}$ constructed as: $$\mathrm{HMAC\_SHA256}(K, m) = \mathrm{SHA256}\left[(K' \oplus \mathrm{opad}) \, \Vert\, \mathrm{SHA256}\bigl((K' \oplus \mathrm{ipad}) \Vert m \bigr)\right]$$ where $K'$ is $K$ padded to 512 bits (or $H(K)$ if $|K| > 512$), $\mathrm{ipad} = 0x36$ and $\mathrm{opad}= 0x5c$ repeated to 512 bits.

The output is a 256-bit value, hex-encoded as a 64-character lowercase string. The system allows truncation to a configurable slug length $L$ (in hex chars), leading to a pseudonym of $4L$ bits. Collisions are negligible for $L=64$ (collision probability $\ll 10^{-60}$), with higher risk at lower $L$ (e.g., $\sim 2^{-39}$ for $L=10$) (Kapelinski et al., 18 Nov 2025).

In salt-based hashing for specific fields, such as IP addresses and ports, a file-specific salt $\sigma$ is combined with position/index information:

• For the $j$-th octet of IP $\alpha = (o_1,o_2,o_3,o_4)$,

$$H_j(o_j) = \mathrm{SHA256}\bigl(\sigma \Vert \mathrm{enc}(o_j) \Vert \mathrm{enc}(j)\bigr),\qquad o_j' = \mathrm{bin2int}(H_j(o_j)) \bmod 256$$

producing a format- and structure-preserving pseudonym ($\alpha' = o_1'.o_2'.o_3'.o_4'$) (Bargale et al., 29 Jul 2025).

Port numbers $p$ are pseudonymized as: $$p' = \left( \mathrm{bin2int} \left[ \mathrm{SHA256}(\sigma \Vert \mathrm{enc}(p)) \right] \mod 65536 \right)$$

2. Security Properties and Evaluation Metrics

The security of salted SHA-256 pseudonymization derives from the preimage, collision, and second preimage resistance of SHA-256, as well as the cryptographic binding provided by HMAC. Salting prevents rainbow-table and offline dictionary attacks. Evaluations rely on:

• Collision Rate: Proportion of pseudonym collisions after mapping, typically negligible for full-length outputs;
• Shannon Entropy: Entropy before and after anonymization, empirically showing $H_\mathrm{anon} \approx H_\mathrm{orig}$ with minimal loss (Bargale et al., 29 Jul 2025);
• Hamming Distance: For IP pseudonyms, an average $16$-bit difference in 32-bit representations demonstrates strong diffusion;
• Residual Leakage: Aggregate-level semantic information (e.g., subnet grouping, port popularity) is preserved, but individual linkage is infeasible without the salt/key.

The IND-CPA sketch holds: keyed SHA-256 as a PRF is indistinguishable from random in the random oracle model. Inversion or cross-corpus correlation is infeasible without access to the salt/secret (Bargale et al., 29 Jul 2025).

3. Reversibility, Workflow, and Implementation Patterns

Pseudonymization is reversible for authorized users through a controlled mapping between the original and pseudonymized values, mediated by audit-logging:

1. On pseudonymization, for every $m$:
   • Compute $p = \mathrm{HMAC\_SHA256}(K, m)$.
   • Store $$(p, m, \text{timestamp}, \text{file\_id}, \text{entity\_type}, \text{audit\_metadata})$$ in a SQLite database.
   • Replace $m$ in outputs with $p$ (or $p[0:L]$).
2. To de-pseudonymize, users invoke a tool with the same $K$, lookup by $p'$ in the database, and recover $m$. The process logs every re-identification for compliance (Kapelinski et al., 18 Nov 2025).

The secret key $K$ is never persisted to disk, provided at runtime from OS environment or a KMS/HSM, with access strictly controlled.

For log anonymization, salt generation occurs per file or batch. Salts are kept in memory or securely persisted to support reproducibility or authorized recovery (Bargale et al., 29 Jul 2025).

4. Structural and Format-Preserving Integration

JSON and XML document pseudonymization preserves the native structure:

• Tree-processing traverses leaf nodes only, pseudonymizing textual values, while retaining tag, attribute, and non-PII content.
• When truncation is used, slugs are valid tokens in both XML and JSON schemas.
• Examples:

  { "user": "[email protected]", "ip": "192.168.0.1" }

  pseudonymized with $L=64$:

  { "user": "a1b2c3d4e5f6... (64 hex chars) ...", "ip": "4f9d0e2f3a1b... (64 hex chars) ..." }

  This approach ensures compatibility with data-processing pipelines while anonymizing sensitive elements (Kapelinski et al., 18 Nov 2025).

5. Collision Resistance and Uniqueness

The collision probability for a full-length (256-bit) HMAC-SHA256 pseudonym is negligible ($\ll 10^{-38}$). With truncation to $L$ hex characters, the collision probability increases to $\approx 2^{-4L + 1}$ (e.g., $4\cdot 10^{-12}$ for $L=10$). The backing database enforces uniqueness: any collision (in practice, extremely unlikely) will be flagged. A strict 1:1 mapping is maintained between input and pseudonym by the database mechanism, preventing accidental re-use or aliasing even under truncated outputs (Kapelinski et al., 18 Nov 2025).

In per-octet IP hashing and port mapping, empirical results demonstrate low collision rates and minimal information loss as assessed by entropy-based metrics. Hamming distance statistics support robust mixing and resistance to structural pattern leakage (Bargale et al., 29 Jul 2025).

6. Post-Quantum Security Analysis

The presence of a secret salt greatly increases resistance to quantum preimage attacks. Against a quantum adversary using Grover's algorithm, the cost to invert a salted SHA-256 pseudonym is: $$\mathcal C(s) = N_{\mathrm{salt}}(s) \times \sigma(k+s) \approx 2^{166.4 + s/2 + \log_2(1+s/256)}$$ where $s$ is the salt length in bits, and $k=256$ is the hash output length. For $s=64$, the cost is $\sim 2^{198.7}$ logical-qubit cycles; for $s=128$, $\sim 2^{231.0}$; and for $s=256$, $\sim 2^{295.4}$ (Amy et al., 2016). These costs are well beyond foreseeable quantum capabilities. Typical salts of 64 bits or more provide post-quantum security levels exceeding 128 bits. Increasing salt length linearly increases the quantum work exponent by $s/2$ (Amy et al., 2016).

7. Limitations and Best Practices

Strengths:

• High throughput (≈200–300 MiB/s per core) for practical deployment.
• Reversible pseudonymization for authorized users, supporting audit-compliance workflows (e.g., GDPR, LGPD).
• Structure-preserving transformation for JSON/XML and file-oriented data (Kapelinski et al., 18 Nov 2025).
• Configurable truncation and field inclusion allow fine-tuned privacy-utility trade-offs.

Limitations:

• Single-iteration HMAC does not offer CPU-hardening; if $K$ is compromised, all pseudonyms can be recomputed rapidly.
• System only supports one $K$ per run; operational key-rotation strategies require external orchestration.
• Multilingual PII spanning boundary tokens may require customized allow-lists.
• OCR-inaccuracy for extracted PII reduces the effectiveness of audit or recovery workflows.
• For per-octet IP hashing and port mapping, some aggregate semantic features—such as port popularity or subnetting trends—may persist, but direct re-identification remains infeasible (Bargale et al., 29 Jul 2025).

Best practices dictate: strict controls on $K$, periodic rotation, maximum feasible slug length, and strong file-system protection for the mapping database (Kapelinski et al., 18 Nov 2025). With these controls, the method achieves resilient, auditable, and privacy-preserving transformation of sensitive identifiers in a range of applied cybersecurity and data science contexts.