Question

When we store only the resultant data for a key in a hashtable, how do I perform hashtable resizing? One example I can think of is to store username & password combinations. For the sake of privacy, we’d only store passwords (there can be many other use cases too). Here, the table just stores the data but not the key. Given this, if I want to copy entries from the old table to the new during resizing, I don’t have the key to hash upon.

How is resizing done here?

Answer 1

In a case like this, you’re not really using a hash table at all — or at least the hash you’re talking about isn’t being used as the hash for the table.

In other words, the hash (e.g., SHA-256) of the password is just another piece of data, being stored in the table (hash table or otherwise). It’s only modified if/when the password changes.

It might be stored in a hash table keyed by, say, the username — but if so, you’re going to have the user name here so you can re-hash when needed.

If, for whatever reason, you decided to use the secure hash of the password as a key into the table, the complete hash would be the key, and what you’d use to index into the table would be some hash of that hash (e.g., two-byte chunks all XORed together).

Edit: As far as table resizing (by itself) goes, no, storing the key is not an absolute necessity. You can get by with just storing the remainder of the original hash code. In other words, you’ll typically start by generating, say, a 32-bit hash. You then use part (but only part) of that to index into your table (e.g., 16 bits). When it comes time to resize the table, you will take the position in the table for 16 bits, and the stored remainder of the hash for the other 16 bits to recover the original 32-bit hash. Assuming you’re doubling the size of your table, you’ll then use 17 bits for the index, and store the remaining 15 bits in the table.

If you didn’t mind going a bit insane with the hash itself, you could also use this to eliminate any real need to store the key at all. For example, if you started by creating a 256-bit hash (e.g., SHA-256), you could use N bits as the index into the hash table, and the remaining bits as if it were the key. If your actual keys were longer than 256 bits, this would lead to the possibility of collisions — but collisions with SHA-256 are sufficiently rare that the odds of encountering one by chance are almost certainly lower than the chances of a computer error during a key comparison, so it said two keys were identical when they really weren’t.