What type of encryption to use for 48-bit to 48-bit?_问答_开发者

I've got a bunch of 48-bit (6 byte) values that I need to encrypt symmetrically. The two requirements are:

The resulting encrypted value needs to also be 48-bits (6 bytes) long. They key itself can be (and would preferably be) much longer to guard again brute force attacks.
The resulting encrypted value needs to be deterministic, i.e. value A using key B will always produce encrypted value C (we encrypt on the fly and show the encrypted data to the user so need to always show the same value)

All block ciphers I've found have used a minimum block size of 64 and appear to be fixed (you can't use an arbitrary block size). Should I be 开发者_运维百科thinking about a stream cipher?

I'm doing this in Java.

Note: I've seen this question and associated answers but wasn't clear on whether the suggestions would satisfy my 2nd requirement.

Consider format preserving encryption.

(Sorry, I originally misread the requirements thinking it was the INPUT data that needed to be 6 bytes.)

I don't think you can do exactly what you want with standard cryptographic algorithms:

the problem with stream ciphers is that standard ones effectively work by generating a stream of pseudorandom bits from the key and then XORing these bits with the plaintext; effectively this means that you should never use the same stream of bits twice (e.g. if you do, then XORing two ciphertexts gives you the same result as XORing the corresponding plaintexts; and in any case with 48 bits, there are only 2^48 possible bitstreams, so you can just test them all by brute force);
the problem with block ciphers is that there's no standard one as far as I'm aware that has a block size of 48 bits.

Now, that doesn't mean that a 48-bit block cipher couldn't be developed-- and indeed I dare say there are some out there-- just that none of the bog-standard ciphers that have undergone years of scrutiny from the cryptographic community have that block size.

So I would suggest options are:

relax the requirement of a 48-bit ciphertext; for example, TripleDES has a 64-bit block size and is "fairly" secure (equivalent to 112 bit security)[*];
in principle, you could implement your own block cipher with whatever block size you require, sticking as close as you can to a standard design, e.g. a Feistel network following some generally recommended design principles-- as a starting point, see Schneier, "Applied Cryptography", pp. 346ff, "Theory of Block Cipher Design".

The obvious problem with the latter option is that, whist standard block ciphers are generally based on common general principles, they adopt particular design decisions that have been subject to considerable scrutiny; yours presumably won't be.

I would also recommend standing back a bit from the problem (or perhaps explaining a bit more what you're trying to do), because it seems to be based on requirements that would normally go against good security practice (having the same plaintext always encrypt to the same ciphertext is something one would normally specifically avoid, for example). So you could have the best designed Feistel cipher in the world, but introduce some other vulnerability in how you're using it.

[*] TripleDES is generally not recommended because AES gives better security more efficiently (you might like to see some comparative timings of block ciphers that I took in Java to see just how bad it is). However, this might not matter in your particular application.

No, just "pad" your data out with some bytes you don't care about (but which are always the same if that's your requirement) so that you reach the size of a block. (If you're using an appropriate padding mode, then this will be done for you.)

I believe this is what you are looking for
http://web.cs.ucdavis.edu/~rogaway/papers/shuffle.html
This algorithm lets you construct PRP (i.e. arbitrary length block cipher) from secure PRF (e.g. sha256, blake2)

Block cipher in CTR mode has the same issue as a stream cipher.
Without a proper MAC (which require more bytes added) it will susceptible to bit flipping.
And without unique IV (which also require more bytes added) it will be just a broken implementation.

You can use a stream cipher only, if you have a unique salt for every encryption (don't even think about re-using the same salt, as that would be trivial to break).

When you have such unique values (e. g. a sequence number that's already associated with your values), you can use e.g. the stream cipher RC4-drop.

When you don't have such unique numbers already, you probably can't use a stream cipher, because you only have 48 bits for your result (so no space left for the salt.)

As for a block cipher with 48 bits - sorry, I don't know such a cipher, either. Maybe what you can do, is combining four 48 bit values into a 192 bit value, resulting in three 64 bit blocks, encode them, and then split them into four 48 bit values again. (I have no idea, if that would be possible in your situation or not?)

If you have a unique counter / sequence number associated with each plaintext value, then you can just use any block cipher in CTR (counter) mode.

To encrypt value V that is sequence number N under key K:

Expand N to the size of a block;
Encrypt N with the block cipher and key K;
Take the first 48 bits of the result and XOR them with V.

Decryption is the same. The most important thing to remember with this method is:

Never, ever use the same key and sequence number to encrypt two different values.

Sequence numbers must be unique. If your sequence restarts, you must use a new key.

There is a 48-bit block 80-bit key cipher designed in 2009 - KATAN48 (the family version of KTANTAN48 has some key scheduling issue. So far, it was not broken, and has quite high security margins, so it has passed the test of time.

Here's a proposed solution that meets both of your requirements.

What if you use a cipher with a 32-bit block size (such as Skip32) and run it twice, as described below.

You have a 48-bit value to encode, for example:

f2800af40110

Step 1:

Split this into a 32-bit value and a 16-bit value using some method. Here we'll just grab the left 4 bytes and the right 2 bytes (but in practice you could use a secret bitmask, see below).

32-bit value: f2800af4
16-bit value: 0110

Step 2:

Encrypt the first one with a secret key K1, using Skip32 and let's say we get:

Encrypted 32-bit value: b0daf2b9

Step 3:

Split this into two 16-bit values (again you could use a secret bitmask, but for this example we'll grab the left/right two bytes).

Value 1: b0da
Value 2: f2b9

Step 4:

Combine value 1 with the the 16-bit value from step 1 to get a new 32-bit value:

b0da0110

Step 5:

Encrypt the resulting 32-bit value with secret key K2, again using Skip32:

Encrypted 32-bit value: 6135d8f4

Step 6:

Combine this 32-bit value with value 2 from step 3 to get a 48-bit encrypted result.

6135d8f4f2b9

The result is both deterministic and reversible. No two inputs will produce the same output.

Note on splitting/combining values

Steps 1 and 3 above will split a value in a predictable way. I'm not sure if this introduces any weakness, but one alternative is to use a bitmask. If we want to split a 48-bit input number into 32-bits and 16-bits, we could come up with a bitmask, essentially a number with 16 1's that can dictate how we split bits of the input number to get two output numbers, as follows:

INPUT  : 111100101000000000001010111101000000000100010000
BITMASK: 001010111001110000100000010001100000011001100000
           | | |||  |||    |      |   ||      ||  ||     
VALUE 1:   1 0 101  000    0      1   10      00  00      => a860
VALUE 2: 11 1 0   00   0000 010101 110  000000  10  10000 => e015c050

Similarly for steps 4 and 6 you could combine two values by interleaving bits based on a bitmask.

If you use separate bitmasks for each step and separate keys for each step you end up with 2 keys and 4 bitmasks, all of which would be needed to encrypt/decrypt values.

Quick note on Skip32 and it's use cases

"The Skip32 has the uncommon properties of being fast, creating very dissimilar encrypted values for consecutive input values, and producing output of the same size as the input. These make this cipher particularly useful for obfuscating series of sequential integers (e.g. auto-incremented database ids)." - https://docs.rs/skip32/1.0.5/skip32/

Any thoughts about this approach from someone more experienced with cryptography than I am?