Moreover, what we (= provable security wonks) really don't understand is collision resistance, or, more generally, cryptographic security notions that are stronger than one-wayness (really UOWHF) and that do involve a secret key.
Trusting blockciphers over hashes based on this high-level argument is suspect, at least in principle. (To be clear, I'm not arguing with your practical recommendations as they seem pragmatically justified.) It could well be the case that the ways we build password hashes from blockciphers appear to be more secure simply because we haven't sufficiently cryptanalyzed blockciphers for the necessary collision-resistance-type properties. Perhaps collision resistance is just too much to hope from any highly-efficient function, and it is only a matter of investing the effort to find collisions in the functions derived from blockciphers. Adding to the suspicion is the fact that blockciphers give us good hashes by coincidence, not design (And formal evidence doesn't help explain the situation - although I see hand-wavy claims about related-key attack resistance being sufficient, in my work I've only found reverse connections).
So are you aware of any deeper reasoning behind the blockciphers-over-hashes argument? Could trusting blockciphers for collision-resistance just be a good usage of security-through-obscurity, because a tremendous amount of effort has been invested in finding collisions in the hash functions but not in the blockciphers?
a cryptographic hash of a phone number on their server should match a cryptographic hash of a phone number in a contact list on a phone. The app sends the hash to the server, the server looks up users via the hash and responds with user data for matches.
To be honest this should be a third party service, since it sounds like every major social networking app is doing the same exact thing.
In my opinion, giving out your number, along with the hash of each phone number in your address book to an authority with millions of such hashes isn't appreciably better than giving them in plaintext.
But you wouldn't give out your number. I haven't completely thought it through but the service provider would provide an api for common platforms. All it would do is 2-way encrypt contact numbers (SSL?). Then the service would do a basic lookup using the encrypted data as a key. If there is a hit for this particular platform it'll return the platform specific data (in this case, like a path specific user id).
Of course the other side would be maintaining users in this service, which again is pretty straight forward.
(Hi David?... I'm the OTHER DJB, probably not the one you are thinking of)
Trusting blockciphers over hashes based on this high-level argument is suspect, at least in principle. (To be clear, I'm not arguing with your practical recommendations as they seem pragmatically justified.) It could well be the case that the ways we build password hashes from blockciphers appear to be more secure simply because we haven't sufficiently cryptanalyzed blockciphers for the necessary collision-resistance-type properties. Perhaps collision resistance is just too much to hope from any highly-efficient function, and it is only a matter of investing the effort to find collisions in the functions derived from blockciphers. Adding to the suspicion is the fact that blockciphers give us good hashes by coincidence, not design (And formal evidence doesn't help explain the situation - although I see hand-wavy claims about related-key attack resistance being sufficient, in my work I've only found reverse connections).
So are you aware of any deeper reasoning behind the blockciphers-over-hashes argument? Could trusting blockciphers for collision-resistance just be a good usage of security-through-obscurity, because a tremendous amount of effort has been invested in finding collisions in the hash functions but not in the blockciphers?