Talk:Format-preserving encryption

Comparison to common encryption

Proposing deletion of this section (Comparison to common encryption). This section does not accurately reflect current thought in FPE and misrepresents the underlying security of FPE. For example, the FFX mode (as well as other proposed FPE schemes) of AES recommends the use of a "tweak" value to introduce randomization which prevents attacks described in the section. --Absaroke (talk) 23:11, 28 April 2010 (UTC)

Deleted section Absaroke (talk) 21:47, 3 May 2010 (UTC)

FFSEM number of digits supported

Why does the article state "FFSEM is restricted to digits only and the field length must be between nine and nineteen digits", when the referenced ffsem-spec.pdf says that "We do not recommend the use of FFSEM on sets smaller than 2^32"? --Purplie (talk) 00:24, 24 March 2010 (UTC)

FCEM

FCEM Format Controlling Encryption Mode by U. Mattsson

FORMAT CONTROLLING ENCRYPTION USING DATATYPE PRESERVING ENCRYPTION Ulf T. Mattsson, Chief Technology Officer, Protegrity Corp. http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/fcem/fcem-spec.pdf

"approved mode"

I don't think the statement "FPE is NOT an approved MODE of the AES algorithm" makes any sense, since some particular constructions may be approved or considered secure while others are not. —Preceding unsigned comment added by Purplie (talk • contribs) 23:13, 23 March 2010 (UTC)

PCI DSS

I removed the "PCI DSS" section for two reasons. Reason the first - The section seemed largely out of place in an article that is otherwise fairly centered on a current type of cryptography being investigated. Including a section about PCI - which is not a cryptographic standard in and of itself and references other standards for support - was distracting and unnecessary IMO. And reason the second - the accepted use of a cryptographic method to satisfy a PCI requirement is entirely up to the discretion of the assessing entity (a QSA in PCI parlance). With information presented in this article and in other easily searchable locations (like the Rogaway, Black, Bellare, Ristenpart etc. papers) can lead a QSA to form an opinion one way or the other. Furthermore, given Visa's recent acceptance of the format preserving methods in its published DFE practices (http://corporate.visa.com/_media/best-practices.pdf), it looks like at least one card brand will allow the use of this method for the very purpose of meeting certain PCI requirements. Absaroke (talk) 21:20, 19 October 2009 (UTC)absaroke

Anyone else think the organization of this article is a bit schizophrenic? I think we might want to look at some of the other crypto articles and organize it a little more logically? The various FPE constructions and modes should be put into a sub-section, not as individual sections from the root of the article. Anyone else have thoughts? It might be nice to keep the intro, keep the motivation section, maybe add/consolidate a history or summary section of FPE research/methods, then go into the different constructions, and since all good crypto articles include cryptanalysis, we should add that...any thoughts? Absaroke (talk) 21:30, 19 October 2009 (UTC)absaroke

Topic name

Is "Format-preserving Encryption" really a widely-used name for this idea? It's misleading because it sounds like a special case, when really it's a more general case (with regular block ciphers being the special case). —Preceding unsigned comment added by Purplie (talk • contribs) 20:29, 25 March 2010 (UTC)

"As secure as AES"

They proved that each of these techniques is as secure as the block cipher that is used to construct it. This means that if the AES algorithm is used to create an FPE algorithm, then the resulting FPE algorithm is as secure as AES because an adversary capable of defeating the FPE algorithm can also defeat the AES algorithm.

I don't think this is really what the paper says. —Preceding unsigned comment added by 67.161.10.167 (talk) 03:35, 15 April 2010 (UTC)

Critical example with short credit card numbers

The credit card example used to explain the motivation for format-preserving encryption, seems dangerous to me. As far as i can judge, this is vulnerable to rainbow-table attacks, because a given number will always end up in the same encrypted number (there is no IV vector).

For short messages like credit card numbers (16 digits 0-9), building a rainbow-table should be a trifle. In this case a single rainbow-table is enought to get all stored numbers. Even with a block-cypher using an IV (CBC mode), brute-forcing could be a problem. Keep in mind that the first block of the credit card number is not random, it belongs to the card institution, this narrows down the possible combinations additionally.

The example is suggesting, that it is ok to encrypt credit card numbers with format-preserving encryption. In reality, storing them should be avoided completely if possible, otherwise one have to follow the PCI standard. I recommend to look for another example, maybe for obfuscating row ids in an url. — Preceding unsigned comment added by Martinstoeckli (talk • contribs) 09:24, 21 August 2013 (UTC)

In the case of the FFX FPE standardized by NIST, it includes an input called a 'tweak' which fulfils the same general principles as a salt. Choosing an appropriate tweak and managing it effectively is an important facet to use FPE safely. See: — Preceding unsigned comment added by 167.24.104.150 (talk) 21:57, 4 August 2016 (UTC)

References

ABBIE FPE

A funny show 2604:2D80:B400:E100:4820:8090:75CD:3096 (talk) 21:10, 11 May 2024 (UTC)

😒 2604:2D80:B400:E100:4820:8090:75CD:3096 (talk) 21:10, 11 May 2024 (UTC)