[underscore]

I assume that your centralized repository of (email, id, provider) tuples wouldn't just spill out all of its contents to the world, preventing mass email harvesting. Instead, it would reply with the appropriate (email, id, provider) tuple when asked for an email (hashed or not) that it knows about, and return nothing or an error or whatever when asked about an email that it doesn't know about. In either case, as arethuza points about elsewhere in this thread, it is essentially an email address validity oracle for emails that it knows about -- hashed or not -- since a spammer can sit there all day and ask it about random email addresses and record its responses. If you hash an email address, the only thing you buy is to make the spammer add a line of code to their script. In short, I think that using a hash is functionally equivalent to not using a hash, at least for spam purposes. What do you think?

(note that a partial email validity oracle isn't necessarily a deal killer; PGP/GPG keyservers, for example, are partial email validity oracles, and have not only existed for years but have also gained acceptance amongst (some of) the security conscious and the paranoid)

(also note that a hash would be a safeguard (whose effectiveness is dependent on how resistant the hash function is to first preimage attacks and other factors) against disclosure following a compromise of the central database/authority, in addition to its questionable utility at fighting spam in normal situations)

[theli0nheart]

What if a dynamic salt were added to the hash, i.e. instead of just email, it were email+first_name? I think that would solve most of the email harvesting issues that have been brought up.