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)

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).

What I am trying to prevent is to have a collection of "important" numbers in plaintext on a laptop

Noone suggested that. We said specifically said to put that information in the secret database, the one "that's under lock and key (of course)".

You're ok with haveing a secret table that maps public ids to real ids. You were thinking of implementing that table as a rainbow table. All we're suggesting is that you implement that table in a much more straightforward manner:

 work db             secret db
 (laptop)            (under lock and key)
+-----------+---     +-----------+---------+
| public id | ...    | public id | real id |
+-----------+---     +-----------+---------+
[download]

The public id would simply be a unique random number. (Safer than a hash, and avoids the problem of collisions.)

Now, this assumes the database is created before being placed on the laptop, but that's consistent with everything you've told us so far. You can still use the above method if you collect the numbers in the field, but only if the field has access to the a remote service that provides the following function:

$public_id = get_new_public_for($real_id);
[download]

Do all the laptops have all the important numbers?

Or just each have one (or a few), and any reversal done (and the DB stored), in your secure location?

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"I'd rather go naked than blow up my ass"

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