# Tag Info

15

What you're looking for can be done using existing schemes for format preserving encryption (FPE). In general, FPE schemes convert an existing strong algorithm like AES into a block cipher that operates on a set of any size. For instance, FPE can encrypt 15 digit integers to other 15 digit integers (eg for credit card numbers, one of the common reasons for ...

14

Both of the other answers tackle the question of encryption in a particular format, but I would argue that neither of them is necessarily a good fit for your use case. You want to be able to generate 20 character codes that a server will be able to verify. A symmetric MAC is sufficient for this use case, if you don't need the codes to contain any secret ...

11

There is a technique called "format preserving encryption", which could be called an "arbitrary-size block cipher". This would allow to map your set of 5-character strings onto itself. Of course, this can't really get too secure, as it has still the limitations of ECB mode: encrypting the same string with the same key always gives the same ciphertext. Your ...

10

The real security of Vigenère is difficult to quantify. A million character plaintext with a 10 character password is easy to break. But a 10 character plaintext with a 10 character randomly chosen password is essentially a one-time-pad and theoretically unbreakable. Given the data you've told us (plaintext: 100 to 5000 characters; password: 30 to 100 ...

10

The Vigenère cipher has many weaknesses, but perhaps the most obvious ones are: An attacker, who knows (or can guess) as many consecutive characters of any plaintext message as there are in the key, can trivially recover the key and thus decrypt all messages. (In fact, the characters need not even be consecutive, they just need to cover the entire key, or ...

8

A Feistel network is a way of constructing an invertible permutation from a (possibly non-invertible) function. If the function used is pseudorandom and has a large domain, then 3-4 rounds yields a pseudorandom permutation (3 rounds suffice if the adversary can only ask "compute" queries, and 4 rounds are needed if the adversary can ask "invert" queries). ...

7

If the data to protect has no built-in redundancy at all (for example, has each of its bit determined by fair coin toss), there is no way to protect integrity without expansion (Proof sketch: there are as many distinct possibilities for valid plaintext as there as possibilities for valid enciphered-and-protected data, hence every possible enciphered-and-...

7

You first need to consider your adversary and what are your goals for this mechanism. This kind of mechanism appears less effective than proper cryptographic means: having secure PRNG means that both ends of the message exchange have access to some proper cryptographic means Adding noise means that the information exchange is less efficient: there is much ...

7

Yes, this is possible (conditionally). It sounds like you want Format Preserving Encryption. FPE works by encrypting from an arbitrary domain $X$ onto $X$. Consequentially, if plaintext $M \in X$ is encrypted to ciphertext $C \in X$, any decryption of $C$ - even with the wrong key - will yield a decrypted message inside of $X$. Thus an attacker doesn't know ...

7

What you are asking is a straight application for Format Preserving Encryption, which builds ciphers which input and output are in a constrained format (generically: common to input and output, hence preserved). The FPE field has many articles with proven techniques; and proposed standards, including BPS and SP800-38G Draft. Specifically, it looks like ...

6

There is a generic construction, by Granboulan and myself, which shows that it can be done "perfectly": if you have a seekable pseudo-random stream (which you can get with a conventional block cipher in CTR mode), then you can have a pseudo-random permutation over a domain of arbitrary size $N$, such that evaluating that permutation over a given input uses ...

6

Use format-preserving encryption. The current NIST standards-track mode FFX should be sufficiently fast for your purposes. For your domain size, you might also want to try the swap-or-not shuffle, a new construction which is also pretty fast and dead simple to implement. To get the absolute best speed form these schemes you should use a single AES call as ...

5

For these parameters, and if speed is not an issue, it is reasonable to build a new cipher using a balanced Feistel construct, with the strong cipher used in the round function. With enough rounds, it is computationally indistinguishable from a perfect cipher, except for one detail: the permutation obtained is even. This is an issue if and only if the ...

5

Because CBC-MAC with inputs that are not prefix free is weak against existential forgery, meaning it is not a "secure" MAC. More precisely, CBC-MAC is easily distinguishable from a random function (i.e. not a PRF) when the input domain is not prefix-free. This is because an adversary can request the CBC-MAC of messages $M_0$ and $M_1$, and then xor the MAC ...

5

See “format-preserving encryption” at WikiPedia. Depending on the size of the message space, one can get such a scheme by: sorting pseudorandom values, see section 4.1 of “Format preserving encryption”, or using this arbitrary-size scheme described in “Perfect Block Ciphers With Small Blocks”, or using swap-or-not as described in “An Enciphering Scheme ...

5

I explain, criticize and try to improve the technique in the question (which asks for speed by using cryptographic techniques for arguably satisfactory functionality in a statistical simulation). Shuffling, and full-blown Format-Preserving Encryption aim at perfect or demonstrable cryptographic security, a different goal. Under the assumption that the (...

5

So, in the comments, you state that I'm using the original date as the key This is the reason for the duplicate dates. The encryption is entirely deterministic for a fixed key. When you change the key, however, it is not. So it is entirely plausible that encrypting the number 215 with the key 215 could result in the same ciphertext as encrypting the ...

5

The general construction to encrypt (inputs of less than 128 bits) with cycle-walking is: # IN, OUT are 128-bit unsigned integers in the range 0..MAX OUT = AES(K, IN) while OUT > MAX do OUT = AES(K, OUT) return OUT AES is going to permute your 128-bit input into a seemingly-random 128-bit output. About $1/2$ of the time the top bit of the output will ...

5

What you are asking is a straight application of Format Preserving Encryption, which builds ciphers which input and output are in a constrained format (generically: common to input and output, hence preserved). The FPE field has many articles with proven techniques; and proposed standards, including BPS and SP800-38G Draft. Note: the method tentatively ...

5

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 ...

4

Yes, it is possible to implement the primitive asked, with a 32-bit block cipher that is secure (indistinguishable from a random permutation) no matter how many input-output pairs are known, keyed with a fixed secret randomly-chosen key. That's a standard building block in Format Preserving Encryption. One such block cipher is: Louis Granboulan and Thomas ...

4

The formal definition of a block cipher is a function $$E_K(P) := E(K, P): \{0,1\}^k \times \{0,1\}^n \rightarrow \{0,1\}^n$$ The input and output spaces are by definition n-bit blocks, so the operation of the cipher in Electronic Code Book (ECB) mode is technically "format preserving". That is not however what "Format Preserving Encryption" (FPE) ...

3

Simplest is to use a stream cipher. You will not get authentication, but that would be impossible with format preserving encryption anyway. Does the encrypted string need have the same character set (e.g. hex or base 64)? In that case: Transform to binary. Encrypt with stream cipher. Transform back. AES CTR would work, as would any other stream cipher. ...

3

The answer depends on how you would layer the encryption on top of the existing protocol. If you implemented your own Skype client, you could deal with compression issues yourself. That might allow you to use format preserving encryption, perhaps on the compressed data stream and not the audio itself. However, you would need to be careful – speech ...

3

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: Ciphertext Stealing Tag splitting Note that you need at least either a nonce or authentication tag -- or better both -- to preserve data privacy,...

3

There are a couple of related concepts here: Tweakable blockciphers and format-preserving encryption (FPE). It turns out that tweakable blockciphers provide a very natural way of obtaining FPE, but they have other uses as well. As the blog discusses, sometimes we want, say, encrypted credit card numbers to themselves look like credit card numbers. That is, ...

3

Your problem, the way I read it, could be described as follows: You are currently using password encryption for protecting the confidentiality of files on a known format. You have concerns regarding the long term confidentiality of those files, given that you don't know what computers will be able to do in the future. Ideally, you want the confidentiality to ...

3

Typically, the output of format-preserving encryption is easily distinguishable from a random bitstream, precisely because the ciphertexts conform to some non-random format. Thus, you cannot use standard statistical tests on them, at least not directly. If the format of your FPE scheme is flexible enough, you may be able to test some aspects of it by ...

3

The obvious way to FPE strings of $N$ characters of [A-Za-z] is to treat the string as a base-52 value (with each character being a digit, say, A=0, B=1, ..., y=50, z=51); do a base conversion of that to an integer between 0 and $52^N-1$; use a standard FPE technique to encrypt that value into another integer between 0 and $52^N-1$, and do a base conversion ...

3

FFX is not malleable. It's a strong tweakable pseudo-random permutation, where the "strong" here indicates that both encryption and decryption look like random permutations from the attacker's perspective. In particular, there's no relationship between the plaintexts of closely related ciphertexts (aside from the trivial observation that different ...

Only top voted, non community-wiki answers of a minimum length are eligible