Fix hashIdentifier normalization bug

[Just-Bamford]

Summary

The hashIdentifier function has a normalization bug. Input identifiers with different whitespace, case, or encoding produce different hashes, breaking the guarantee that the same identifier always hashes to the same value. This causes token validation failures when a voter's identifier is entered inconsistently.

This is a Milestone 1 bug. Token validation relies on consistent hashing.

Background

In js/src/crypto/hash.ts, the hashIdentifier function does not normalize the input before hashing. It currently does:

const hash = crypto.createHash('sha256').update(identifier).digest('hex');

If a voter enters their identifier with different whitespace (leading/trailing spaces), different case (uppercase vs lowercase), or different Unicode normalization (NFD vs NFC), the hash will be different and token validation will fail.

Scope

Crypto Library

• Add normalization to hashIdentifier:
  • Trim leading and trailing whitespace
  • Convert to lowercase
  • Normalize Unicode to NFC
  • Remove any non-alphanumeric characters except hyphens and underscores
• Document the normalization steps in comments and JSDoc
• Update tests to verify normalized and non-normalized inputs hash to the same value

Tests

• Leading/trailing spaces are trimmed
• Uppercase converted to lowercase
• Different Unicode representations hash to the same value
• Non-alphanumeric characters removed
• Example: " John Doe " and "john doe" hash to the same value

Relevant Files

• js/src/crypto/hash.ts
• js/src/tests/crypto.test.ts

Acceptance Criteria

• All normalization steps implemented
• Tests pass
• No breaking changes to existing hashes (verify with backend)

Out of Scope

• Custom normalization rules per ballot — use standard normalization only

Note for Contributors

Be careful with Unicode normalization. Use String.prototype.normalize('NFC') in Node.js. Test with international characters and emoji to ensure robustness. Do not change the hash format — keep it as hex string.

[pgreat123]

I'm a full-stack developer with experience working across JavaScript, backend systems, and cryptographic workflows. This issue stood out to me because inconsistent identifier hashing can directly break token validation, even when the user provides the same identifier in a slightly different format.

My approach: in "js/src/crypto/hash.ts", normalize identifiers before hashing by applying NFC Unicode normalization, trimming whitespace, converting to lowercase, and removing characters outside alphanumeric characters, hyphens, and underscores. I'll keep the existing SHA-256 algorithm and hex output unchanged to avoid unnecessary compatibility issues.

Tests: add coverage for leading/trailing whitespace, uppercase input, Unicode NFC/NFD representations, and removal of unsupported characters. I'll also test international characters and emoji to ensure normalization behaves as expected, then verify that existing hashes remain compatible with the backend.

I can submit within 4 days.

[grantfox-oss]

🦊 GrantFox — @pgreat123 has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #22)
2. Your PR will be reviewed by the AnonVote maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Official Campaign | FWC26 campaign!

@pgreat123's PR #43 was approved and merged by @Just-Bamford.

🏆 @pgreat123: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (363 total points). Track your full progress on GrantFox.

👏 Great work, @pgreat123! Keep contributing to AnonVote.