# Tag Info

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

9

A standard credit card number has limited entropy. Per ISO/IEC 7812 the first 6 digits are fixed for a given card issuer, and the simplest prudent assumption is they are known to attackers. The last digit is a public function of the others. For 16-digit credit card numbers, that leaves 9 digits (at best <30 bit of entropy). This can be increased only ...

8

Cryptographically secure hashes usually work on bitstrings of arbitrary length and output a fixed length bitstring. The secure part is being collision resistant and preimage resistant, so that you have a practical oneway function, and those are the properties you want for "scrambling". As fgrieu psted in the comments, one easy way to do this is to utilize ...

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

8

I cannot understand what is the difference with monoalphabetic substitution and what is the security offered. A monoalphabetic cipher applies to individual symbols of the plaintext. But an FPE scheme works on the whole message as a unit. In the set {0,...,N-1} that you mention, N is the size of the message space—the number of distinct messages, not the ...

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

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

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

7

any other considerations? Yes. In many common use cases the mapping table needs to be retained. That map changes each time a number is added; that's a backup / continuity of service headache. The map is security-sensitive: it contains all the clear phone numbers, and information which (combined with other information) allows getting back to users. The map ...

6

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

6

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

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

FF1, 2 and 3 are basically inspired by Luby-Rackoff constructions. At the core they differ in their round functions and key scheduling: FF1 supports greater range of lengths and a tweak; FF2 generates subkey for each iteration to thwart any side channel attacks; FF3 has tweaks is split and used in rounding function, also the reverse the sub-strings of ...

5

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

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

4

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

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

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 other answer correctly explains how we could make a modern stream cipher, with a public random IV at the beginning of ciphertext used (together with the key) in the setup of a keystream generator, restricted to the range $[0..35]$, and using addition modulo $36$ (Beaufort cipher) to encipher each character. Here is a more detailed description of such a ...

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

Is this true? Are block ciphers considered to be FPE? Well not exactly . Its something more than block ciphers. Of course block ciphers are integral to FPE. Some times we need to preserve the lengths but some times we need to preserve the lengths of encoded strings. Lets see some examples. Informally, In order to preserve the formats of input data types we ...

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

add noise to the cleartext to obfuscate the true text among a bunch of garbage .... I need an attacker to believe that the message is not encrypted So first of all, a small disclaimer. You realize that regular encryption standards would be much stronger and existing libraries are designed to handle data. On top of that it's generally not a good idea ...

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

While I haven't heard of previous work on this exact problem, splicing together some standard solutions to a few other problems almost solves this problem. There is a loophole in the pigeonhole principle: if the output file is bigger than the input image, it is possible to store "extra" information. Starting from the blurred image you want everyone to see, ...

3

The tweak is a service that the encryption method provides for you. What it allows you to do is provide context separation for various encryptions using the same key. Here's the problem that it is trying to help with: suppose you use the same key to encrypt a number of items; for example, suppose you're encrypting all the items in one column of a database ...

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