Nick

@nick.mcmanus.tech

134 Followers 311 Following

👨🏻‍💻 IT professional | 🎮 Gamer | 📍NJ, USA All views are of my own and do not reflect or represent the opinions of the State of New Jersey, NJOIT, or for anyone whom I work for or with. 🌐 https://nick.mcmanus.tech

Giraffe in an open field

Man pouring powder in his elongated mouth from a box that says "Powder that makes you say 'Jeppy'", with a speech bubble above him saying "Jeppy"

Screenshot of Paul's earlier post on pdsls showing post lexicon

An extremely buff Snorlax flexing it's massive biceps

Screenshot on Bluesky documentation:

Securing against database leaks
The “obvious” approach is to store the cryptographic hash of each phone number, similarly to password-handling best practices. The problem here is that there are simply not very many possible phone numbers, somewhere on the order of 8 billion. A modern GPU could crack a SHA-256-hashed phone number in under a second.

Brute-force-resistant hash algorithms like Argon2 are a big improvement on that, but 8 billion phone numbers is still a small search space (
2
33
), and attackers could construct a Rainbow Table, i.e., a reverse lookup table for every possible phone number. Unlike with password hashing, we cannot use a random salt for each phone number because then we wouldn’t be able to find matches between two users (because mismatched salts would produce different hash outputs).

Since we’re only trying to discover mutual contacts, we can store phone numbers in hashed unordered pairs, such that hash(x, y) == hash(y, x). This order-independence can be achieved by sorting the pair of inputs before hashing them. Assuming there are
2
33
possible phone numbers, then there are
2
65
possible pairs of phone numbers. This makes brute-force attacks much more difficult, and makes Rainbow Tables much less feasible.

A small kitten sitting upright with its tail curled around its front paws