Case insensitive alphanumeric is 36 (26+10) case sensitive alphanumeric is 62 (26 + 26 +10). Second you don't need to store all the data.
Your solution to just stores the hashes and uses their position to calculate the key. Saving 10 bytes out of (10byte key+16byte hash.) However, you would then need to check every hash in order which is slow at look up time.
Next thought is sorting the hashes so lookups are fast. Notice that the first byte is repeated frequently so break the list up into 256 lists and you don't need to save the first byte. Continuing this idea you end up a tree data structure: http://en.wikipedia.org/wiki/Radix_tree. Problem is it's still a lot of data.
However, look up is now so fast you don't need to full key any more store say 8 bytes and test the next 2. Wait, do we really need ASCII key values or just a number to reduce the search space 2 bytes cuts things from 1 day to (1/256^2) or ~1second. But wait, we don't need to store the full hash just enough that false positives are low. A 4 byte hash + 3 bytes in a radix tree gives means ~1 in 256^4th hashes match and you spend 1/200th of a second looking at each match, which seems vary reasonable. Unfortunately even at ~1/4 the storage it's still to much space.
Your solution to just stores the hashes and uses their position to calculate the key. Saving 10 bytes out of (10byte key+16byte hash.) However, you would then need to check every hash in order which is slow at look up time.
Next thought is sorting the hashes so lookups are fast. Notice that the first byte is repeated frequently so break the list up into 256 lists and you don't need to save the first byte. Continuing this idea you end up a tree data structure: http://en.wikipedia.org/wiki/Radix_tree. Problem is it's still a lot of data.
However, look up is now so fast you don't need to full key any more store say 8 bytes and test the next 2. Wait, do we really need ASCII key values or just a number to reduce the search space 2 bytes cuts things from 1 day to (1/256^2) or ~1second. But wait, we don't need to store the full hash just enough that false positives are low. A 4 byte hash + 3 bytes in a radix tree gives means ~1 in 256^4th hashes match and you spend 1/200th of a second looking at each match, which seems vary reasonable. Unfortunately even at ~1/4 the storage it's still to much space.
Continuing this idea of the trade off between storage and speed, you might end up with a rainbow table. http://en.wikipedia.org/wiki/Rainbow_table