TL;DR: Is there such a thing as a hashmap whose contents cannot be read unless you have the right encryption key, and where each encryption key only works for a specific key value pair?
More context:
Say you're building an offline first web application and want to save the client from having to do a bunch of round trips to the server to ask for data. Within such constraints you may decide to, say, provide a whole dump of the database when the client first loads the site, and then the client can query its own copy of the database without needing to talk to the server.
You wouldn't want sensitive data to be part of the database dump, so you're not going to include user emails and passwords in the dump. But here you run into a problem: part of the website relies on user data (perhaps a user wants to view another user's profile) and would then need to query the server.
Given that we want to avoid any additional requests from the client to the server beyond the initial request for the db dump, how could this be achieved? Let's assume you wouldn't include emails and passwords in the dump, but user data that is publicly available, such as user handles and full names.
In such a case, you could simply include user handles and full names in the db dump in plain text. But you don't want to do that because it would give away all users' names at once, as well as metadata such as how many users your site has, etc. If a user reads some other user's handle and name by browsing your site, that's one thing - but if he can read all users at once, that's a problem.
So I'm wondering if part of the dump that contains user data could be made of a sort of "secure hashmap". What I mean is that its contents are not readable unless you have the right key; and even then only those contents that correspond to the key can be read.
If there isn't, I would imagine its implementation to go something like the following:
It works like a regular hashmap, with the exception that all its keys are hashed, and its values are encrypted. That way, even though the consumer could iterate over all keys and values, he wouldn't be able to do anything with them. When a piece of privileged information that acts as a key into the hashmap is made available to the consumer - say, a user handle - the lookup mechanism could first hash the user handle, use the result as a key to the hashmap, and then the user handle would allow him to decrypt the corresponding value (e.g. the full name corresponding to that user handle). The producer creates the hashmap by hashing its keys and encrypting its values by partly using their keys.
So in short, if the producer has a hashmap that contains:
"foo" => "bar"
He then turns it into
"1234" => "6%!*3"
where "1234" is the result of hashing "foo", and "6%!*3" is the encryption of "bar" using "foo" as encryption key (or something along those lines, I'm afraid I don't know much about encryption - what I mean is that it should be possible to use the string "foo" to decrypt "6%!*3").
Am I trying to reinvent the wheel here? If not, is the implementation I'm proposing secure?
Edit: I just realized that doing it the way I proposed above would still divulge the number of entries in the hashmap. Ideally, that could be avoided, too.
