Character for character encryption

Question

is there any available library/algorithm to have a character for character based encryption mechanism. what I basically mean is, that if say the input text is someText, then the encrypted text should have the same number of characters.

from our exploration of asymmetric encryption mechanisms, we feel character for character encryption can't be achieved through that.

it is preferable that the solution be a "key" based solution, since we need to encrypt the input text through different applications [one of them is actually an embedded application within a custom hardware - and the manufacturer would prefer a key based encryption logic]. the security threat of losing our key is not significant, and is an acceptable risk.

Answer 1

The trick is to convert your characters to and from characters in such a way that you don't need more characters to do it. Mathematically speaking, you are able to do that if you use a stream cipher (they performs 1:1 bit encryption). The only thing is that you are then left with a single "partial" bit that might not fit. I created such a program just for the fun of it. As it relied on huge multiplications and divisions, I quickly found out that this was undoable performance wise.

So basically, what you need is something that has a alphabet of N characters, where N = 2^x. In that case, you only need shifting and such. Alternatively, if you have some room to spare, you can look at the text and combine fields so they get nearer in size to N (any N).

What you do is that you map your fields to a range 0..N, put that in an X number of bits, concatenate that together and stream-encrypt it. You should still have the same number of bits now. Then you map the result back to the original alphabet and store/send that.

This is an idea I have been cycling in my head for some time now and I never explained it to anybody. So if there are any questions, please let me know.

Answer 2

For cyphertext the same length as the plaintext, you need either a stream cypher or a block cypher in CTR mode. For stream ciphers, RC4 is common but obsolescent. There are better stream cyphers in the eSTREAM Profile 1 portfolio. For a block cypher, use AES in CTR mode with no padding.

Answer 3

You want to use a stream cipher, or (if your use case justifies it) a one-time pad. One-time pads are a pain to use - you need to get the key to the receiving party somehow out-of-band, the key must be at least as long as the plaintext, and there are significant difficulties dealing with all the issues that occur if there is a transmission error - so stream ciphers are probably the way to go.

RC4 could be a suitable algorithm for you.

Is there a particular reason why you must have character-for-character encryption? Symmetric algorithms like AES tend to use small block sizes, typically 64 bits, so it's unlikely to add much space overhead. If you can use a symmetric block cipher then that may make things easier for you.

I'm not sure what you mean by a "key" based solution. All modern encryption algorithms are keyed, but the nature of the key changes depending on the algorithm. Symmetric ciphers typically have a shared secret key, asymmetric algorithms are the ones that use public/private keys. There are different stream ciphers that use either type of key, according to the Handbook of Applied Cryptography.

I'm also a little unsure what you mean by "the security threat of losing our key is not significant, and is an acceptable risk." If you lose your key then you have no encryption any more (at least, until you rotate your keys). If not having encryption is acceptable then why are you bothering with encryption in the first place? If it's enough to just obfuscate the data then that's a whole different problem.

Answer 4

Did you consider XOR encryption?

http://en.wikipedia.org/wiki/XOR_cipher

Here is Java example:

http://www.ecestudents.ul.ie/Course_Pages/Btech_ITT/Modules/ET4263/More%20Samples/CEncrypt.java.html