Is there a length-preserving encryption scheme, that preserves the lengths of input sizes such that the length of the input plain text is same as length of the output cipher text ?
-
2It's possible to do that, but there are downsides. You should describe your additional requirements and say how you plan to use it. For example CTR mode encrypts to the same size, but it's quite likely that it'll be totally insecure in your scenario. – CodesInChaos Jan 24 '13 at 12:00
-
Can you really not afford around 16 to 32 bytes of overhead? That makes things much easier and much more secure. – CodesInChaos Jan 24 '13 at 12:01
-
Why does same-size cryptos so insecure? What if there is no way to get data revers back without the token? Thank you!! – Digerkam Jan 24 '13 at 12:15
-
1Your question is very vague. Same length encryption can't offer semantic security, but that doesn't mean its insecure for every situation. There are different approaches, with different downsides. So you need to describe your scenario so we can find one that fits for your situation. – CodesInChaos Jan 24 '13 at 12:22
-
I needed to know, because I developed a same size algorithm. I am not familiar cryptography so much, I searched it on wikipedia, but I didnt find any algorithm for same size. I am trying to understand it was already developed or not. – Digerkam Jan 24 '13 at 12:26
-
3Search for format preserving encryption. I'd guess the correct security model for length preserving encryption is that it's a variable length pseudo-random permutation (PRP). – CodesInChaos Jan 24 '13 at 12:30
-
1To 100% clarify, you are looking for an encryption algorithm that maps every possible binary input with an integral number of bytes to a encrypted output of the same length. Is that correct? And you understand the inherent security problems with such an algorithm? (No defense against corruption, replay attacks, and so on.) – David Schwartz Jan 29 '13 at 01:10
-
@DavidSchwartz Yes, my algorithm encrypting anysize of data with a token. The data become irreversible. Everything became noizy. I am sure it is secure. – Digerkam Jan 29 '13 at 10:24
-
2That's Format Preserving Encryption. See e.g. this and this – fgrieu Feb 22 '13 at 14:07
-
3-1, this question is so vague and poorly written that, even with the "clarifying" comments, it's hard for me to tell what's really being asked. Sorry, but it really is. Considering voting to close as "not a real question". – Ilmari Karonen Feb 27 '13 at 11:37
-
I see. Thank you anyway for those comments, and the answer that trying to understand my question that I asked somehow with my poor crypto terminology. – Digerkam Feb 27 '13 at 14:31
-
i have edited the question with more better terminology – sashank Jun 08 '14 at 13:32
3 Answers
As @fgrieu mentioned, what you're after is FPE. The papers he linked deal with FPE on a very small domain, but it looks like you're interested in encrypting longer strings.
For that, you need a wide block cipher. Unlike traditional blockciphers, these typically allow different input lengths, which is a plus. They meet your criterion of not revealing shared prefixes/suffixes. Examples (any of which will be secure): EME, EME2, HCTR, HEH, TET, PEP. Tracking down a good implementation might be problematic; I don't know any off-hand. Some, including EME/EME2, are patented (but can be licenced under "reasonable, non-discriminatory" terms). Depending on the mode, they operate at roughly half the speed of standard encryption algorithms.
In terms of providing confidentiality, a result by Bellare and Rogaway ("Encode-then-encipher encryption: How to exploit nonces or redundancy in plaintexts for efficient cryptography") shows that you get it for free as long as you can guarantee that all plantexts are distinct (e.g., they already have distinct sequence numbers encoded into them somehow). The only information these ciphers leak is plaintext length, and whether or not a plaintext is repeated.
You said authenticity was not a concern, but perhaps it's worth noting that you can get this fairly cheaply if the plaintext contains some type of redundancy that you check upon decryption.
Finally, these algorithms are tweakable ciphers, which means the take an additional input, called the tweak. You can use (meta)data from any accompanying headers as the tweak (or just used a fixed string). Again, if the tweak is distinct each time, then you have confidentiality even if a plaintext is repeated. But at that point it might be easier to, e.g., take a 64-bit nonce from the headers and use that as the high-order bits of a counter-mode IV.
One could design length (and format) preserving encryption schemes using Luby Rackoff Constructions (which are based on Feistel Networks)
While there are variety of variants to achieve (especially , the FFX modes of encryption ) one more notable work is done by Naor and Reigold [1]. They introduce another layer to classic Feistel networks by using Pair-wise Independent Functions ( PWIP), which they prove to be more secure than classic version.
We have very recently re-designed their work and proposed a new, FNR mode of encryption [2] which is practical arbitrary length block cipher algorithm to do the same . One could build format-preserving-encryption using such scheme. Which is variant of Naor and Reingold's work .
[1] Naor, Moni, and Omer Reingold. "On the Construction of Pseudorandom Permutations: Luby—Rackoff Revisited." Journal of Cryptology 12.1 (1999): 29-66.
[2] http://eprint.iacr.org/2014/421
Your are looking for a encryption scheme that supports length preserving encryption. I recommend to use an authenticated encryption scheme like OCB or McOE. There are two common techniques to achieve this goal:
Note that you need at least either a nonce or authentication tag -- or better both -- to preserve data privacy, i.e., security against chosen plaintext attacks (CPA).
Maybe I got you wrong. Maybe you are looking for format-preserving encryption or something else. Hence, a more detailed problem description would be great.

- 199
- 4
-
7I see no way for authenticated encryption to be length preserving. Length preserving encryption is obviously a bit weaker than what we can achieve by adding a nonce/IV and authentication tag, but it's still useful sometimes. – CodesInChaos Jan 28 '13 at 10:27
-
@CodesInChaos I am not familiar with cryptography dictionary, however I am a porgrammer somehow. I am not in a needing of a length preserving algorithm, I am trying to understand the situation of my algorithm in real world of cryptography with your precious assists with your understanding, thank you! – Digerkam Jan 29 '13 at 10:33