Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Privacy Theater of Hashed PII

matthodges.com

Post reply on HN
Print view View original

21–28 of 28 posts

Re: The Privacy Theater of Hashed PII

#21

Post by iamacyborg »

panstromek wrote: post #19
iamacyborg wrote: post #17

Earlier quoted context omitted.

They’re heavily incentivised to not get it, both internally with company KPI’s that’ve not kept pace with the reality of GDPR and externally through ad platforms that continue to demand excessive amounts of data without providing suitable alternatives.

Yea, companies are probably abusing this (as I have noted in the sibling comment), but I think marketers themselves truly don't get it. I've been on the implementation side of this and it's always frustrating debate. It's pretty clear that they just think this is about just picking a different vendor with "GDPR" on list of features, not realizing that the law fundamentaly targets metrics they want to use, and they ju…

I don’t think this is a problem limited to marketers to be fair. How many developers are still also building all these data collection and delivery pipelines? They should know better too, no?

Re: The Privacy Theater of Hashed PII

#22

Post by fmajid »

Serious private set intersection uses full homomorphic encryption or equivalent mechanisms. Microsoft Edge's compromised password detection uses FHE, for instance:

https://www.microsoft.com/en-us/research/blog/password-monit...

If anything, this article understates the problem. A single Nvidia RTX4090 can calculate 164 billion MD5 hashes per second running hashcat software:

https://gist.github.com/Chick3nman/32e662a5bb63bc4f51b847bb4...

That said, surprisingly few people are aware of this fact, even senior technical leadership at Big Tech companies, so I'm not surprised dodgy Ad-Tech companies are not either, and it might be an illustration of Hanlon's Razor: do not ascribe to malice what can be better explained by incompetence (even if ad-tech companies long ago forfeited the benefit of doubt).

Re: The Privacy Theater of Hashed PII

#23

Post by OutOfHere »

chrisandchris wrote: post #10
FooBarBizBazz wrote: post #2

Isn't this solved with salt?

A salt is very good if the input varies. If the input stays within a pre-defined range (e.g. phone numbers), salt does not work very well.

I do not agree that it doesn't work very well. How will you reverse a salt with sufficient entropy? Imagine the salt is a 512 bit hex, the data is a nine decimal digit SSN, the generated hash is 512 bits of which the first 160 bits are used as the value. Now exactly how is the salt not good enough?

Re: The Privacy Theater of Hashed PII

#24

Post by OutOfHere »

jstanley wrote: post #6
FooBarBizBazz wrote: post #2

Isn't this solved with salt?

> A 2020 MacBook Air can hash every North American phone number in four hours If you added a salt, this would still allow you to reverse some particular hashed phone number in about 4 hours, it just wouldn't allow you to do all of them at the same time.

I do not agree. How will you reverse a salt with sufficient entropy? Imagine the salt is a 512 bit hex, the data is a ten decimal digit phone number, the generated hash is 512 bits of which the first 160 bits are used as the value. Now exactly how will you get the phone number back? Do you really think you can iterate over half of the possibilities of 512 bits in four hours?

Re: The Privacy Theater of Hashed PII

#25

Post by OutOfHere »

hlieberman wrote: post #3
FooBarBizBazz wrote: post #2

Isn't this solved with salt?

If it's salted, you can't share it with a third-party and determine who your customers in common are. (That's the point of the salt; to mean that my_hash(X) != your_hash(X)).

You actually can join it when the salt provider is a dedication shared entity. The entity rehashes the data of both organizations to use a shared salt. That is how different organizations join hashed data.

Re: The Privacy Theater of Hashed PII

#26

Post by jstanley »

OutOfHere wrote: post #24
jstanley wrote: post #6

Earlier quoted context omitted.

> A 2020 MacBook Air can hash every North American phone number in four hours If you added a salt, this would still allow you to reverse some particular hashed phone number in about 4 hours, it just wouldn't allow you to do all of them at the same time.

I do not agree. How will you reverse a salt with sufficient entropy? Imagine the salt is a 512 bit hex, the data is a ten decimal digit phone number, the generated hash is 512 bits of which the first 160 bits are used as the value. Now exactly how will you get the phone number back? Do you really think you can iterate over half of the possibilities of 512 bits in four hours?

You know the salt because it's stored alongside the hash. You're only iterating over the space of phone numbers.

If it's not stored alongside the hash it's not a salt, it's something else.

https://en.wikipedia.org/wiki/Salt_(cryptography)

Re: The Privacy Theater of Hashed PII

#27

Post by OutOfHere »

jstanley wrote: post #26
OutOfHere wrote: post #24

Earlier quoted context omitted.

I do not agree. How will you reverse a salt with sufficient entropy? Imagine the salt is a 512 bit hex, the data is a ten decimal digit phone number, the generated hash is 512 bits of which the first 160 bits are used as the value. Now exactly how will you get the phone number back? Do you really think you can iterate over half of the possibilities of 512 bits in four hours?

You know the salt because it's stored alongside the hash. You're only iterating over the space of phone numbers. If it's not stored alongside the hash it's not a salt, it's something else. https://en.wikipedia.org/wiki/Salt_(cryptography)

> If it's not stored alongside the hash it's not a salt, it's something else.

That is not even true. The definition in the article does not substantiate it. There is no requirement for the salt to be stored alongside the hash.

The definition in the article is sufficiently clear. This is all that a salt is:

> a salt is random data fed as an additional input to a one-way function that hashes data

With regard to effective anonymization, the salt is stored by the generator, but not in the exported dataset.

Re: The Privacy Theater of Hashed PII

#28

Post by jstanley »

OutOfHere wrote: post #27
jstanley wrote: post #26

Earlier quoted context omitted.

You know the salt because it's stored alongside the hash. You're only iterating over the space of phone numbers. If it's not stored alongside the hash it's not a salt, it's something else. https://en.wikipedia.org/wiki/Salt_(cryptography)

> If it's not stored alongside the hash it's not a salt, it's something else. That is not even true. The definition in the article does not substantiate it. There is no requirement for the salt to be stored alongside the hash. The definition in the article is sufficiently clear. This is all that a salt is: > a salt is random data fed as an additional input to a one-way function that hashes data With regard to effecti…

If the "salt" is kept secret then I agree you can't brute force all the phone numbers so easily. But I don't agree that "salt" is the correct term for that technique.
Post reply on HN