# Securing a lookup table [closed]

I am looking for a secure approach to handing the following situation:

You're given a string that means something. It contains parts of something larger, each of which is clearly understood. For example imagine a string John_Smith where we can safely assume that an English speaking person will understand John to be a first name and Smith to be a last name.

Requirement: For the sake of argument lets say that you need to encrypt (i am using this term loosely) this String to a cypher of finite number of characters n.

Now .. in theory it is possible that encrypted version of John_Smith is in fact longer then n characters or .. less then it. In either way if we want to decrypt it (as i understand it) we need some kind of hash lookup table.

The lookup table will contain a translation between 0ffdd4377ca2944 -> John_Smith, which in turn must be made secure.

What approach would you recommend to make sure look up table and data in it is secure?

I realize that this is very basic and thank you for your patience.

-
What's wrong with just using a symmetric block cipher to translate the encrypted form to plaintext form and back, using the key to prevent unauthorized people from performing the translation? You wouldn't even need the lookup table. And what do you mean by "securing" a lookup-table? In what circumstances? From whom? For how long? – Thomas Dec 6 '12 at 6:55
I think we can sum up Thomas's questions by What security goal are you actually trying to achieve ? – Alexandre Yamajako Dec 6 '12 at 8:36
What do you mean "secure" what attack are you trying to prevent? – Rook Dec 6 '12 at 18:10
I've closed your question, as it is missing some key points to be answerable – see the previous comments. You are welcome to edit your question and fix this, then we can reopen it. – Paŭlo Ebermann Dec 12 '12 at 19:25

## closed as not a real question by fgrieu, Paŭlo Ebermann♦Dec 12 '12 at 19:24

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, see the FAQ.

You probably already know this, but for the benefit of future readers:

The "Cryptographic Right Answer" for encrypting and decrypting data is: Use AES in CTR (Counter) mode, and append an HMAC. Preferably by using some off-the-shelf, freely available encryption implementation, one that generates the self-authenticating ciphertext string by making a single function call with the plaintext string and the password.

Given a plaintext string of n characters, that produces encrypted ciphertext that is always longer than n.

The above approach works well in most real-world applications (except dealing with passwords, which have their own very different "Cryptographic Right Answer"). However, here at this Cryptography site we spend most of our time talking about "interesting" situations that allow us to use other clever techniques.

Do you need to convert a bunch of plaintext strings to some fixed-length "cyphertext" of 128 bits long (perhaps represented as 22 characters in standard base64url format), where some plaintext strings are much longer than 22 characters? With the hash lookup table you mentioned, I'm pretty sure that is doable. (With fixed-length "cyphertext" of 12 bits, it's probably not doable.) But it is highly unusual. That is one of those "interesting" situations -- ones where AES won't work -- that we love to talk about.

Could you give us some more motivation about why you are interested in such a unusual system? What would the people who use such a system use it for? Do you know of any pre-existing protocols that use such a system?

-
The better "right answer" is: use an existing high-level library, like DJB's NaCl or Google's KeyCzar. – Stephen Touset Dec 7 '12 at 2:10