views:

105

answers:

2

Many of the encryption techniques I've seen can easily encrypt a simple 8 digit number like "12345678" but the result is often something like "8745b34097af8bc9de087e98deb8707aac8797d097f" (made up but you get the idea).

Is there a way to encrypt this 8 digit number but have the resulting encrypted value be the same or at least only a slightly longer number? An ideal target would be to end up with a 10 digit number or less. Is this possible while still maintaining a fairly strong encryption?

Update: I didn't make the output clear enough - I am wanting an 8-digit number to turn into an 8-digit number, not 8 bytes.

+2  A: 

Well you could look a stream cipher which encrypts bytes 1:1. With N bytes input, there are N bytes encrypted/decrypted output. Such ciphers are usually based on an algorithm that creates a stream of random numbers, with the encryption key/IV acting as seed.

For some stream ciphers, look at the eSTREAM candidates. I don't know of any relevant attacks on HC-128 and HC-256, for example.

AndiDog
The potential problem with a stream cipher in this context is that you have to somehow ensure that you never encrypt different values with the same part of the keystream - so you also may need to include some information saying where to seek to in the keystream.
caf
+4  A: 

A lot here is going to depend on how seriously you mean your "public-key-encryption" tag. Do you actually want public key encryption, or are you just taking that possibility into account?

If you're willing to use symmetric encryption, producing 8 bytes of output from 8 bytes of input is pretty easy: just run 3DES in ECB (Electronic Code Book) mode, and that's what you'll get. The main weakness of ECB is that a given input will always produce the same result, so if your inputs might repeat an attacker will be able to see that repetition, and may be able to notice a pattern of "encrypted value X leads to action Y", even if they can't/don't break the encryption itself at all. If you can live with that, 3DES/ECB is probably your answer.

If you can't live with that, 3DES in CFB mode is probably the next best. This will produce 16 bytes of output from 8 bytes of input (note that it's not normally doubling the input size, but adding 8 bytes to the input size).

3DES is hardly what anybody would call a cutting edge algorithm, but I'd say it still qualifies as "fairly strong encryption". Part of its weakness as an algorithm stems from its relatively small block size, but that also minimizes expansion of the output.

Edit: Sorry, I forgot to the public-key possibility. With most public-key cryptography, the smallest result is roughly equal to the key size. With RSA encryption, that'll typically mean a minimum of something like 1024 bits (and often considerably more than that). To keep the result smaller, I'd probably use Elliptical Curve Cryptography, for which a ~200 bit key is reasonably secure against known attacks. This will still be larger than 3DES/CFB, but not outrageously so.

Jerry Coffin
This is great guidance, thank you.
Marplesoft
By the way, that tag was probably a bad choice. It doesn't need to be an asymmetric key.
Marplesoft
Marplesoft
Ah, I didn't understand that. In that case, maintaining the size would be considerably harder. If you encode in hexadecimal, it'll double the size. If you use Base 64 encoding, it should (just) fit into 11 characters. Those will normally be readable, but *not* just digits -- you need 64 possible characters, so you typically use upper and lower case letters, digits, and 2 more characters of your choice ("+" and "/" are pretty common).
Jerry Coffin
@Marplesoft @Jerry I think he should be okay, you are looking at it the wrong way, assuming the number he provided was a decimal number it is 0xBC614E, that is 3 bytes. the largest 8 digit decimal number is 4 bytes. Assuming 4 bytes and an equal-size encryption method, the largest equivalent number is 4 294 967 295. exactly 10 digits.
jbcreix
@jbcreix: In theory you're right. In reality, however, the same problems arise: you can't do ECB on anything less than one block (8 bytes with DES/3DES). CFB requires an IV (itself 8 bytes). To take advantage of the smaller input size, you need switch to a real stream cipher -- which usually uses an vaguely IV-like block itself...
Jerry Coffin