Imagine that all my users have access to all the database of the product. I need to protect one field in the database for every row. I must save the value for later use (cannot be a one-way hash). Think for example that it can be a SSN

The user knows how the field looks before (the user knows his SSN), and the attacker knows how the field looks after encryption. I don't want the user to be able to find the key and decrypt all the SSN's.

The only things, that I'm sure is that my attacker will not find the source code. So I can hard code the key.

In other words:

  • I need access to the original value.
  • Only me have the key.
  • The attacker has access to all encrypted data
  • The attacker knows for one record, what was the original data (before encryption.

Which algorithm do you recommend me to use?

3 Answers 3


AES-128 (or higher) is the recommended symmetric encryption algorithm to use. As long as the key is generated using a Cryptographically Secure (Pseudo-)Random Number Generator then it will not be practical for the attacker to brute force.

If Detection of duplicates can be used as an attack vector, (see potential exploit described by @JohnDeters); Make sure you include an Initialization Vector. Otherwise the same SSN would always encrypt to the same result and the attacker would be able to detect (and verify randomly guessed) duplicates that way.

Do not hard code the key in the main source code, but rather, place it in a separate file, so that source code may be copied out to a test environment if necessary, and a separate (non-secret) key can be used for such environments.

  • Thanks. Two question: 1.Can I use the public row id as part of the key to solve the duplication error? 2. Just to validate. Is it true that: If I encrypt data using AES. and someone knows the decrypted values and the encrypted value, he will not have any way to find the key from that info? Commented Nov 16, 2016 at 16:03
  • 1
    1. Yes. The IV should be unique, but need not be secret. 2. Correct. The attacker would either have to either crack AES (which has not happened for many years), or brute-force all possible keys, which would take "a very long time". Commented Nov 16, 2016 at 16:04
  • 1
    Thank you. Very helpful. Thank's Vincent Rijmen, Joan Daemen for design the AES algorithm, and Thank's George Bailey for recommend it for this use case! Commented Nov 16, 2016 at 16:06
  • 1
    Thank's for all the info. I have new question, in continue to this subject. Your welcome to visit: security.stackexchange.com/questions/142876/… Commented Nov 17, 2016 at 13:03

Be very careful. Don't ignore the fact that an attacker can brute force the SSNs from your database without knowing the encryption key.

If your attacker can use your system to encrypt an SSN, (perhaps by signing up a user, changing the value of SSN, and watching for the changed encrypted SSN field in the database) he can learn encrypted SSNs simply by trial and error. Imagine him setting the SSN to 000-00-0000. Your system encrypts it, and he compares the encrypted value to all the other encrypted SSNs in your database. If his test value matches one of the other values, he has learned that person's SSN. He then changes his SSN to 000-00-0001, and tries again.

Given 999,999,999 tries, he will be able to build up a "rainbow table" that contains every possible SSN. But he certainly doesn't need to do that much work to make a profit.

Most attackers are opportunistic. They don't need every SSN in your database to commit identity fraud, they only need to guess one SSN to start stealing. (The more SSNs they steal, the richer they can get, so of course they want as many as they can.) So maybe they only have time to run their attack for a little while, and they will still be satisfied with guessing a few.

The more people in the database, the more likely the attacker will be successful quicker.

Additionally, it's much easier than random guessing. Many people are unaware that until just a few years ago, SSNs were issued by geographic region.

Consider an attacker from Utah that wants to commit identity fraud using a Utah address. His attack will guess only numbers in the range from 528-00-0000 through 529-99-9999. That only takes 2 million guesses, not 1 billion, and is likely to have a high rate of success on your customers that have Utah listed as the state on their address.

The search space for SSNs is so small it is easily searchable by an attacker with modest resources. You need to take extra steps to protect the data and the systems from this kind of attack.

  • 1
    Thanks for the detailed answer. Two notes: 1. I'm not talking about SSN's (it was just an example) so the example about Utah, no related. 2. If I'm using an IV of the user id. I believe that attacker will not be able to create rainbow-table. Commented Nov 17, 2016 at 0:17
  • 1
    With a cryptosystem that offers semantic security, this is impossible. Encrypting the same SSN twice will not result in the same ciphertext. Rainbow tables are a threat to unsalted hashes, but not to properly used symmetric cipher systems.
    – Xander
    Commented Nov 17, 2016 at 0:24
  • 1
    Thank's for all the info. I have a new question, in continue to this subject. Your welcome to visit: security.stackexchange.com/questions/142876/… Commented Nov 17, 2016 at 13:03
  • 2
    @Aminadav, SSN is just one example of a short ID number that's easily guessed and the search space can be restricted. Credit card numbers are similarly guessable: the first 6 digits are the Bank Identification Number (BIN), and you'll find that in many parts of the world a large fraction of cards in use are regional, and belong to one of about 10 regional banks. That reduces guessing to the remaining 10 digits; if you can find the last 4 digits (printed on receipts), and compute one remaining digit with the Luhn algorithm, you can get it down to guessing only 5 or 6 digits. Commented Nov 17, 2016 at 14:20
  • Also agree with John that the possibility of brute force cannot be under estimated for fast ciphers like AES. CPUs with AES-NI or similar hardware acceleration can run millions of AES encryption rounds per second. For inputs that have entropy far lower than AES's 128/256 bits, brute forcing is highly practical. Also, I am curious on how you plan to protect your key.
    – billc.cn
    Commented Nov 18, 2016 at 14:47

You are in over your head in this, and should not attempt to build this system without getting expert assistance.

First, you don't seem to understand the difference between a cryptographic key and a password. A cryptographic key (e.g., for AES) is binary data selected at random using a secure random number generator. A password is a human-chosen, memorable textual string. If you use a password instead of a key you may well have shot yourself in the foot—passwords are very easy to attack with brute force.

Second, the idea of hardcoding the key into the source code is terrible. Your confidence that you can keep this source code from the attacker's hands is foolhardy.

Third: encrypting an SSN does not necessarily prevent an attacker from finding out what it is. Research shows that using publicly available data and some statistical modeling, an attacker can guess a person's SSNs with high success if they have their date of birth and birth state. I have seen databases where encrypted SSNs appear side-by-side with date of birth and residence state (most people live in the state they were born). Or worse, with the last four SSN digits as well—the part of the SSN that's harder to guess!

Fourth: I second John Deters's response that you're focusing on what a passive attacker can do, and not giving thought to an active attacker—one who can submit plaintext SSNs for you to encrypt and observe the encrypted results. To his verification scenario I'd add the possibility of forgery. Depending on how precisely you misuse the cryptography, an attacker who knows one ciphertext/plaintext pair may be able to use that to forge a ciphertext that decrypts to a plaintext of their choice.

Other than that, given a good cipher an attacker in the conditions that you describe should not be able to find out any information about the other plaintexts given just one ciphertext/plaintext pair. So this is not where your problems lie.

  • Thanks. About Fouth (Active Attacker). How it possible that attacker who knows one ciphertext/plaintext pair may be able to use that to forge a ciphertext that decrypts to a plaintext of their choice? Commented Nov 17, 2016 at 22:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .