Security, Math & Transparency
Hashing, Determinism, and Verifiable Giveaways
A good giveaway draw must be fair, auditable, and private. PickSafely stores hashed participant identifiers and performs the draw on the server. Hashes make the inputs look random while staying deterministic: the same input always yields the same hash. That lets us “commit” to an entry set and prove later that the draw was derived from that set without exposing raw emails.
Provable integrity
We compute a salted hash “commitment” to the finalized entry set. Anyone can check that the published winners match the committed set.
Privacy by default
Hashes are one-way: from a hash alone, guessing the original email is computationally hard, especially with salting and rate limits.
Random-looking, yet deterministic
A cryptographic hash (like SHA-256) maps any input to a fixed-length output. Two key properties matter here:
- Determinism: same input → same output. We can re-compute and verify later.
- Pseudorandomness: outputs are uniformly distributed over the output space, so they look random and resist pattern guessing.
Try it yourself
Paste a few emails, choose a salt, and see how the hashes distribute into buckets. Reuse the same inputs to observe determinism. Change the salt to see how a new commitment re-randomizes appearance without exposing identities.
Changing the salt re-randomizes appearance, while the process remains deterministic for a given input + salt.
We map hash prefixes into N buckets to show uniformity (random-looking spread).
| Input (normalized) | Hash (SHA-256 hex) | Bucket |
|---|---|---|
| Enter a few emails and click “Compute hashes”. | ||
Demo only. In production, PickSafely stores hashed identifiers server-side with additional access controls, rate limits, and audit trails. This widget never sends your inputs to a server.
Collisions and the “birthday” effect (intuition)
With a 256-bit hash, the space of outputs is astronomically large. Even with many thousands of participants, practical collision risk is negligible. The “birthday bound” says collisions become likely only when the number of items approaches the square root of the output space, which is far beyond real-world giveaway sizes.
Why we salt commitments
A salt is a random secret blended into the commitment. It prevents offline guessing (“rainbow table”) attacks against predictable inputs and ensures that even if two campaigns have identical participants, their commitments differ. During auditing, we can reveal just enough (method, commit, count) to validate fairness without leaking personal data.
Takeaways
- Hashes make inputs verifiable without revealing them.
- Determinism enables post-draw auditing and reproducibility.
- Salts defeat bulk guessing and linkability across campaigns.
- Uniformity means “looks random” while staying mathematically consistent.