0

I have old system with database that has table with column of type char(20) and the customer decided to encrypt that column for some business needs however for some system integration needs the length of the output column to be similar to input which is 20 and I have read about Format-Preserving encryption

My question is, Is format-preserving encryption is strong like AES methods and Are there any SQL Server implementations yet that can be used with large number of records millions?

Hossam Barakat
  • 1,399
  • 9
  • 19
  • 1
    problem with FPE is that you cant tell if the field has been crypted or not. It is usually used for credit card numbers but the FPE version if stolen even though it's not the original number it can still be a valid credit card number and thus be stolen. Is FPE as strong as AES the answer is yes and no. FPE on a 3 character string would be a very poor encryption as if you use a 300 character string then im pretty sure it would surpass AES 256. But that woul be slower to generate than AES. AES almost have steady speed and the output is not humanly readable/usuable. – Franck May 15 '15 at 11:53
  • Thanks a lot for your reply @Franck , My situation is having 20 characters for to be encrypted so I think it is small however I was interested if you can guide me about collision part, Instead of comment you can have the above comment posted as answer – Hossam Barakat May 15 '15 at 23:09

2 Answers2

0

You can build secure format-preserving encryption that is based on AES. Here is my answer for a different question, where I show code that implements format-preserving encryption using AES as a building block. See this lecture on format-preserving encryption from Professor Boneh of Stanford University for details on how it can be done.

Community
  • 1
  • 1
Jim Flood
  • 8,144
  • 3
  • 36
  • 48
0

Problem with FPE is that you cannot tell if the field has been crypted or not. It is usually used for credit card numbers but the FPE version of s credit card number if it is stolen even though it's not the original number it can still be a valid credit card number and be used by malicious people.

Is FPE as strong as AES the answer is yes and no. FPE on a 3 character string would be a very poor encryption as opposed to if you use it on a 300 character string then it could surpass AES 256. But that would be slower to generate than AES. AES almost have steady speed when encrypting and you can estimate the time it will take depending on the string length and the output will NOT be humanly readable/usuable.

example that are not run trough the encryption for real but just to illustrate the difference follows :

Name : Frank Stall

encrypted using FPE

Name : Steve Moore

Even though the name has been encrypted successfully it is still a valid value usable by people that want to steal identity (remember it's just to illustrate the difference). from the results you can visually tell the value is a name but yourself even if you know it you cannot tell if it's encrypted or not.

encrypted using AES

Name : WOa8+6KskFZ7IdNYgZ3+9BGDJrVfSVd61dDcX1JcVK8=

As you can see if you look at the result of a basic AES encryption the string length don't necessary match, the value is impossible to humanly guess what it is. How can you tell if it's not my birthday i just put there instead of the name.

Franck
  • 4,438
  • 1
  • 28
  • 55
  • 1
    "FPE version of s credit card number if it is stolen even though it's not the original number it can still be a valid credit card number and be used by malicious people" This is not true, after using fpe, it's like a random number that is not valid . In 16 integers is very hard that a collision happens by coincidence. A criminal could just try random number instead, which is still futile. – Sfp Mar 23 '21 at 17:14
  • @Samuel I did mentioned back then "it can still be a valid credit card". Why i said that is because we had a system for city wide bus pass that was encrypted on FPE and we got a handful of case where we were charging the wrong credit card because some systems were failing to decrypt and did use the raw value which were also valid credit card number just not the correct monthly user. – Franck Mar 23 '21 at 17:37