The way to encrypt a single int

Question

How can you inexpensively understand the two-way encryption of a 32-bit int, so that each number displays some other int in this space and vice versa in a way that is difficult to predict?

And it does not require preliminary storage of 4.29 billion ints in the mapping table, of course.

Answer 1

What you want is a 32-bit block cipher. Unfortunately, most block ciphers are 64 bits or more due to the disadvantages of the small block size . If you can handle the encrypted int twice as much as the input, then you can just use Blowfish, TDES, or some other well-proven 64-bit block cipher.

If you really need 32 bits and you don't mind reduced security, then it’s easy enough to trim a Feistel network cipher, such as Blowfish, to any block length that is a multiple of 2 or less than the initial cipher. For Blowfish, simply divide the input number evenly between the two half blocks and crop the output of the F function and P values ​​down to 1/2 the size of your target block. All this can be done by executing the algorithm, as usual.

Answer 2

Obviously, you need some kind of random key to make it safe. In this case:

int original = 42; int key = give_me_a_random_int(); int encrypted = original ^ key; int unencrypted = encrypted ^ key; // now, unencrypted == original == 42 

This is just XOR. XORing will change this process again.

In addition, I should note that it is safe for one use only. It was called a disposable panel . If you use the same key twice on non-random data, the attacker can decrypt it.

Answer 3

Use a 32-bit block cipher, the only one of which I found skip32: http://www.qualcomm.com.au/PublicationsDocs/skip32.c

Answer 4

One way is XOR with a secret 32-bit number. When you again XOR with this secret number, it will return to the original number. It is fast, but not very safe. If a safe method is needed, I would also like to see other methods.

Answer 5

Use a standard algorithm and a random pad (provided that the ciphertext should not be the same length as the text of the plane).

So basically use a standard algorithm that uses a chain and connects four random 32-bit numbers to it. This should help hide any patterns / redundancy in your 32-bit message. Damn, come over at the end if you like it.

Basically, the less you write, the better. All this spin.

Answer 6

There are two simple and reversible operations that can be used to scramble an integer value. You can use the xor operation, and you can exchange bits in a number.

If you use both options, it will not be trivial to determine the method used. They will protect each other somewhat.

Answer 7

If all you need is something real simple that the average user will not notice, then use a series of XOR and shift statements.

The problem with not using an array to store 4 billion or so INTs is that you need a function that makes a one-on-one random card in a 4 billion INT domain. You can mix a series of XOR and shift statements to create your own, but they will be hard to crack. Even if there was a well-known one-on-one card, it would also fail. Without salt, someone could simply create a simple rainbow table to break it.

The problem with salt in two-way communication is that you must exchange data securely. Salts must be kept secret, and once you know what they are, they are meaningless.

If you want to configure a secure communication channel, see Protocol without protocol version 2 . This will give you an example of how complex communication encryption can be. I suggest you find something well known that someone else has already created and tested. Even if you use something created by someone else, if you use it incorrectly, it will not work.

Answer 8

Take the 32-bit input, divide it into two 16-bit halves L and R, then repeat the following steps: calculate the pseudo-random function R, x or the result of this pseudo-random function in L and replace L and R. This is the Luby-Rackoff construction. The pseudo-random function should not be reversible. Thus, you can, for example, take a block cipher, encrypt 16 bits and reduce the result to 16 bits. Make sure that not all rounds use the same pseudo-random function (rsp. Use different round keys).

Answer 9

Take a look at the github.com/msotoodeh/integer-encoder project. It supports 32 and 64 bit integers.

Answer 10

I used XOR + ADD with a 64-bit secret key. I also used to change the key every two minutes and tried to decrypt using the current or previous key. (In my domain, an integer should not be safe for more than four minutes.)