Question

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

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

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

Answer 1

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