1
$\begingroup$

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.

$\endgroup$
  • 1
    $\begingroup$ What's the point of using the plaintext as the key? Doesn't that mean that you can't decrypt it unless you already know the decryption? Or, are you just looking to find a noninvertable transform of the plaintext? $\endgroup$ – poncho Oct 21 '15 at 21:54
  • $\begingroup$ @poncho Yes that is what I am doing. I'm using my FPE as a non invertible transform of the plaintext. Therefore no decryption wanted. $\endgroup$ – erotavlas Oct 21 '15 at 23:03
  • $\begingroup$ It seems to me that you are aiming at a authentication tag of the same size as the output. I'm not sure that this is actually feasible. If you use different key and plaintext you are certain to run into collisions. You could use HKDF-expand or even a password hash to increase the plaintext to the given key size, but that would not necessarily make the scheme secure. $\endgroup$ – Maarten Bodewes Oct 22 '15 at 18:40
  • $\begingroup$ @MaartenBodewes I'm not sure what to do now. Is the problem because my output from the FPE will have collisions due to my changing the key for every plaintext? $\endgroup$ – erotavlas Oct 22 '15 at 20:47
  • $\begingroup$ Depends on the amount of plaintext and the size of the plaintext. But FPE is Format Preserving Encryption, I'm not sure but you could be stepping outside the boundaries here. $\endgroup$ – Maarten Bodewes Oct 22 '15 at 20:51
5
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ I totally understand now. I may just abandon my idea of using the input plaintext as the key particularly for small plaintext. If I do use the input plaintext, the best I can do is slow down the attacker using the password hash as you suggest. Thanks for your suggestions. $\endgroup$ – erotavlas Oct 23 '15 at 21:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.