Since there's about 32 million leaked US numbers, but there potentially exist up to 10 billion, any hash function that would take a day to process the leak would still require over 300 days to bruteforce the whole space.
Granted, any number in the leaked set could still be trivially reversed when submitted -- but those were known already anyway, they are just associated with more metadata now.
That is very likely quite an overestimation. But if I'm not mistaken, the limitations you describe only reduce the search space by 19% (since it's two 90%-steps).
100 * 0.1 = 10 // First 90% Reduction
10 * 0.1 = 1 // Second 90% ReductionI checked the math so many times because I was starting to suspect my mind was glitching, lol.
You're right about that!
If I was to make a HN-friendly version, I'd probably make static JSON files that list all the numbers, indexed by the first four or so digits. When you enter a number, the first digits are sent to the server, and the appropriate JSON file is returned. That list is then searched client-side for the full number and the result displayed. The code should be simple and easy to verify that the full number doesn't leave the client, while maintaining the same simple user interface I already have. Variations of this idea could be more secure (i.e., only enter the start of the number and search for your number yourself in a long list) but less user-friendly.
I don't actually have any plans on implementing this though. I feel satisfied enough with what I have.
(I don't think hashing would work because the address space is too small and reversing is too easy. There aren't any email addresses.)
And you're right, the only way to build a HN-friendly version would probably be to basically do the checking client-side, since any additional information you send to the server could be directly used to narrow the search space.
I think I read that there are some email addresses in the leak though; wasn't HaveIBeenPwned searching only for those, but not for numbers?
;)