[deleted]
Building Searchable Encrypted Databases with PHP and SQL
11–20 of 33 posts
Re: Building Searchable Encrypted Databases with PHP and SQL
#12Can someone explain why it's not simple to brute force the hash in the blind index? Since SSNs only have 9 digits, that's a billion possibilities. Is this just a hash that's too slow to iterate over the billion? Is each row salted differently?
Edit: I'm asking because I don't know, not because I'm saying it's possible.
Edit2: Also, it appears there was a pattern to SSN issuance prior to 2011, so the problem space may be far short of a billion. No numbers start with 00 for example. Also, there's a listing of numbers not ever issued[1], and a table of "highest assigned"[2]. Since SSN's issued after 2011 are children now, they can be safely skipped, as they aren't as interesting for fraud. Also, if the State of residence is cleartext, you can search that space first if you assume a large number of people live in their birth state.
Re: Building Searchable Encrypted Databases with PHP and SQL
#13yay PHP/SQL (stack I work with, well MySQL)
Re: Building Searchable Encrypted Databases with PHP and SQL
#14Can someone explain why it's not simple to brute force the hash in the blind index? Since SSNs only have 9 digits, that's a billion possibilities. Is this just a hash that's too slow to iterate over the billion? Is each row salted differently? Edit: I'm asking because I don't know, not because I'm saying it's possible. Edit2: Also, it appears there was a pattern to SSN issuance prior to 2011, so the problem space may…
> Can someone explain why it's not simple to brute force the hash in the blind index?
You're not bruteforcing H(m) here. You're trying to bruteforce H(m, k) without knowing k. To make matters worse, k is a random string of 128+ bits, generated by a CSPRNG.
Re: Building Searchable Encrypted Databases with PHP and SQL
#15How is this different than CryptDB? https://css.csail.mit.edu/cryptdb/
From what /r/crypto says, they leak metadata to the database server.
https://www.reddit.com/r/crypto/comments/6e5jjz/building_sea...
Re: Building Searchable Encrypted Databases with PHP and SQL
#16Can someone explain why it's not simple to brute force the hash in the blind index? Since SSNs only have 9 digits, that's a billion possibilities. Is this just a hash that's too slow to iterate over the billion? Is each row salted differently? Edit: I'm asking because I don't know, not because I'm saying it's possible. Edit2: Also, it appears there was a pattern to SSN issuance prior to 2011, so the problem space may…
> Can someone explain why it's not simple to brute force the hash in the blind index? You're not bruteforcing H(m) here. You're trying to bruteforce H(m, k) without knowing k. To make matters worse, k is a random string of 128+ bits, generated by a CSPRNG.
Hrm. Ok. This is assuming I've compromised the database client side, right? Doesn't the client have to know 'k' to do the query? k is $indexKey, right?
Edit: Thanks, got it now. A database dump on it's own gives nothing useful. The client side is vulnerable, but has to be since it's ultimately serving up plaintext SSNs anyway.
Re: Building Searchable Encrypted Databases with PHP and SQL
#17Earlier quoted context omitted.
> Can someone explain why it's not simple to brute force the hash in the blind index? You're not bruteforcing H(m) here. You're trying to bruteforce H(m, k) without knowing k. To make matters worse, k is a random string of 128+ bits, generated by a CSPRNG.
Hrm. Ok. This is assuming I've compromised the database client side, right? Doesn't the client have to know 'k' to do the query? k is $indexKey, right? Edit: Thanks, got it now. A database dump on it's own gives nothing useful. The client side is vulnerable, but has to be since it's ultimately serving up plaintext SSNs anyway.
This is assuming that:
- The webserver and database server are on separate bare-metal
- The database gets compromised, not the webserverRe: Building Searchable Encrypted Databases with PHP and SQL
#18If I understand this correctly, you basically store HMAC or password hash as a separate field and index on it? That may work for SSNs (which are unique), but it won't work for other things you commonly need to encrypt, such as personally identifiable data (in healthcare scenarios). If you (for example) encrypt first names of people (or any other data point that is not unique per entry) using this scheme, then HMAC wi…
> If you (for example) encrypt first names of people (or any other data point that is not unique per entry) using this scheme, then HMAC will reveal all the rows that have the same first name. You can then use frequency analysis to determine with high probablity what the encrypted names are.
This is where things get difficult to explain, because most health care programs are going to care about compliance first and foremost. So with that in mind:
1. You probably don't need to encrypt their first name to be e.g. HIPAA compliant, but...
2. Using a very short Bloom filter increases the odds of false positive collisions. Combine this with Argon2 and aggressive rate limiting, and now you've frustrated frequency analysis and chosen plaintext attacks greatly.
Given the threat model that we've given (database is not the same machine as the webserver, and the database server is what gets compromised), I can't see a better solution.
Re: Building Searchable Encrypted Databases with PHP and SQL
#19If I understand this correctly, you basically store HMAC or password hash as a separate field and index on it? That may work for SSNs (which are unique), but it won't work for other things you commonly need to encrypt, such as personally identifiable data (in healthcare scenarios). If you (for example) encrypt first names of people (or any other data point that is not unique per entry) using this scheme, then HMAC wi…
This would depend on how large the database was. If the names in the database were non-representative of the general population then frequency analysis is not going to help much.
Re: Building Searchable Encrypted Databases with PHP and SQL
#20Earlier quoted context omitted.
Hrm. Ok. This is assuming I've compromised the database client side, right? Doesn't the client have to know 'k' to do the query? k is $indexKey, right? Edit: Thanks, got it now. A database dump on it's own gives nothing useful. The client side is vulnerable, but has to be since it's ultimately serving up plaintext SSNs anyway.
This is assuming that: - The webserver and database server are on separate bare-metal - The database gets compromised, not the webserver
Very big assumptions, vector of attacks tend to begin at the webserver more so than the DB. Sometimes, these DB dumps we hear off occurred over HTTP!