tags:

views:

57

answers:

2

Our client wants to give us a database. The original database has a phone number column. He doesn't want to give us a phone number. Somehow i'm not sure why - it is decided that client will give us encrypted phone numbers with encrypted with 128bit AES key.

We will tell the client which phone number is to be shortlisted for some purpose but we will never know what is the actual phone number .. we'll just know the encrypted numbers.

Here are things I don't understand:

  1. is using 128bit AES key encryption suitable for this purpose ?
  2. should the client preserve the AES key used to convert the numbers or should the client instead of preserving the key create a database mapping the orignal numbers with encrypted numbers
  3. should the same key be used to convert all numbers or different
  4. if randomly generated keys are used to encrypt numbers isn't it possible that for two phone numbers the encrypted text may be same ?
+1  A: 

Addressing your concerns in order:

  1. It may be, it may not be. You haven't really mentioned what the purpose is at all, in fact:

    • Why the need for encryption?
    • Who is it being protected from?
    • What's the value (or liability to you, if lost) of the data?
    • How motivated are the hypothetical attackers assumed to be?
    • What performance loss is acceptable for the security gain?
    • What hardware do you have available?
    • Who has what physical/logical access to various parts of the system?

    And so on, and so forth. Without knowing the situation, it's not possible to say whether this is an appropriate encryption scheme. (Though it is likely to be a solid choice).

  2. Surely that's for the client to decide? I will say, though, that the latter case seems to defeat the purpose of encryption entirely.
  3. The same key ought to be used to convert all numbers, unless you fancy juggling keys around to try and remember which one to use to decrypt which phone numbers. If the security system is well designed, this wouldn't give any extra security and would just be a bizarre headache.
  4. By definitiong of encryption, no. It's always a reversable mapping which means there's no loss of information such as you would get with a hash. And consequently, every instance of ciphertext has a single unique plaintext that will encrypt to it (with a given key).

Though all in all this doesn't sound like it's needed. It sounds to me like someone's been making decisions based on appearances rather than technical merit - "We encrypt your phone numbers with the same 128-bit encryption used in browsers" sounds good but is it actually needed?

Andrzej Doyle
+5  A: 

IMO this is the wrong approach. Instead of encrypting the phone number, which still leaves a chance of you decrypting it (e.g. because someone leaks the key), the client should just replace them with an ID that points to a table with the real telephone numbers; of course, this lookup table stays with him, you never get it.

I.E.

Original table:

Name   | Phone
-------+---------
Erich  | 555-4245
Max    | 1234-567

You get:

Name   | Phone
-------+---------
Erich  | 1
Max    | 2

Only your client has:

ID | Phone
---+---------
1  | 555-4245
2  | 1234-567
ammoQ