Some examples of FPE are:
- Encrypting a 16-digit credit card number so that that encrypted output is a 16-digit number
- Encrypting a date so that the encrypted output is still in date format
- Encrypting a document so that the encrypted output is a document in the same format
FPE is especially valuable when encryption is being done at lower layers (such as the data access layer) and applications where it is being used are not aware that the data values have been encrypted. In these scenarios, if the encryption that is being used is not preserving the format of the data, there is the potential for the encrypted data to break application functionality.
It is important to note that in some situations the meaning of FPE can be more nuanced. If an application performs validation on data when it is used or updated, FPE must also ensure that the encrypted data is considered valid. In the examples above, this could mean that an encrypted credit card number still passes credit card number validation, an encrypted date is within the valid range, or an encrypted document can still be opened by a reader for that document type.
When implemented correctly, FPE can allow data to be encrypted at a lower level without requiring any customization or code changes to applications. This can make such encryption cheaper and easier as well as be more secure since the data is encrypted at a lower level and can not be compromised at higher layers.
For more information on how NextLabs’ products incorporate FPE as part of our dynamic data masking functionality, see our Data Access Security product line, DAE.
To comment on this post
Login to NextLabs Community
NextLabs seeks to provide helpful resources and easy to digest information on data-centric security related topics. To discuss and share insights on this resource with peers in the data security field, join the NextLabs community.
Don't have a NextLabs ID? Create an account.