1

Using a format preserving encryption scheme that uses AES internally as its block cipher, for a plaintext that I encrypt I want to use that input plaintext as the key.

However using AES-128, my keysize is required to be 128 bit. But i cannot guarantee my plaintext to be exactly this length - they are words or numbers of variable length.

Is there a computationally efficient and acceptably secure way to convert the plaintext to exactly the keysize required by the AES algorithm? Does it even matter what algorithm I use?

EDIT: The FPE I'm using is BPS. I'm using it as a one way encryption on plaintext values such as SSN, names, dates, etc. (Note: not using this for any authentication purposes - merely trying to eliminate the need to store or reuse a single key - I also have no need to use a single key anyway because I have no need to decrypt the original plaintext)

Further context on the answer to “Is there a format preserving cryptographically secure hash?”

EDIT 2: Although it is convenient in the sense that this approach doesn't require storing a key anywhere I realize now that using the input plaintext as key is flawed especially for smaller plaintext which the attacker can brute force rather trivially. This is definitely not the way the FPE was designed to be used.

Community
  • 1
erotavlas
  • 507
  • 3
  • 14

1 Answers1

5

I'm using it as a one way encryption on plaintext values such as SSN, names, dates, etc.

I suggest rethinking your approach. None of these values have much entropy, so it would be straightforward to bruteforce the original plaintexts (just like cracking a password hashed with a fast hash function).

If you're planning to use these values for authentication, that doesn't sound like a great idea... but I know that, in some applications, it's the best you can do. A few suggestions:

  • Use a password hash instead of fancy encryption. Since there's likely not much entropy in the secret values, a password hash would be helpful in slowing down brute force attacks.
  • Combine the values before hashing. This will at least force attackers to crack them as a group, not one-at-a-time. Be sure to combine the values such that they are delimited unambiguously.

If you must process the fields separately (in order to perform comparisons between accounts, for example), I still think a password hash is better suited to this purpose -- just use a fixed salt to make the hashing deterministic. Don't expect too much security here though; thoroughly hashed dates can still be cracked quite easily.

Tim McLean
  • 2,914
  • 1
  • 16
  • 26