Um, no, the rainbow table is the secret database, which I will keep secret. A flat "table" isn't useful, since I need a way to take an arbitrary hash and return the related number. That's why the table needs to be a DB.
| [reply] |
Either I don't understand your problem...
or
you don't understand jethro's observation above.
If protecting the confidential, 10-digit numbers depends on your ability to "keep (a) secret" then the complexities of a rainbow table offer no advantage over a flat table of:
-------------------------------
|ID | 10-digit number|
-------------------------------
|Abel, A | 0123456789 |
-------------------------------
|etc, | ad nauseum... |
...
Either can be compromised, no matter how hard you try to "keep secret." In fact, discussions of the rainbow table often include a note that such entities are used to make recovering "secret" data easier:
- Wikipedia: "A common application is to make attacks against hashed passwords feasible."
- XXX (name deleted): "XXX is a Windows Password cracker based on Rainbow Tables"
- Random discussion of web security: "Statistically, half of the key is found on average as soon as half the chain length has been reached" (caveats re complexity omitted)
| [reply] |
What I am trying to prevent is to have a collection of "important" numbers in plaintext on a laptop, which will be moving around geographically and susceptible to theft.
A salted hash is a good way to make sure that these numbers are not stored in plaintext - and it is easy. The issue is that I will eventually, in a secured location without network access, need to reverse this hash (hence a rainbow table).
The laptops are already using full-disk encryption, but this provides only a single layer of defense against exposure - I am thinking about how to add another layer without doubling the number of passphrases to remember (or forget).
| [reply] |
I should have formulated that better, my previous post can be misunderstood quite easily. Luckily ww said it much better.
But you are right, my answer isn't really what you were looking for. You seem to need to collect the data over a long time on laptops and the secret database should not be connected while this is happening, right?
Your scheme is a really nice idea, but has problems. Let me elaborate:
Lets say you have chosen a salt. Nobody else can construct a rainbow table in a sensible timeframe without knowing the salt.
But an attacker needs to know only one of those unique numbers you want to keep secret and access to your data on the laptop to find out the salt. He just encrypts the number he knows combined with possible salt values until he finds a encrypted number where there is a corresponding data set
So you need to use a really big salt, more like a password
That salt/password could be stored on the laptop, but then an attacker could just look into your script to find out the password
So you and the data collectors have to type in the salt/password every time they want to collect data. If the attacker gets hold of the laptop he can change the script to store the salt and send it to him or he can collect it later. Granted that is difficult but you still need to secure the laptops more than you might want to. And you have to trust the data collectors
So Xilmans idea to use public-key encryption is really the solution you are looking for with none of the above disadvantages
| [reply] |
