decent stream cipher of some kind needed..

Dr_Teeth

Hiya, I'm messing about with a project where I want to encrypt a small amount of plaintext (like a few words max) as securely as possible.

The only thing is that the resulting ciphertext has to be as small as possible, the same length as the plaintext if possible. Do any of you have any web links for this sort of thing, I've had a poke around google but haven't come up with anything useful.

I haven't used this kind of cipher before, block stuff like gpg gives me back huge chunks of ciphertext obviously.

Teeth.

ecksor

Language/environment? Is there a shared key?

The google directory has most of the main libraries listed methinks.

http://directory.google.com/Top/Science/Math/Applications/Communication_Theory/Cryptography/Programming_Libraries/?tc=1

OpenSSL has at least one stream cipher (RC4, don't know of any others that are commonly used), and there's bindings for most languages around.

tom-thebox

My billing software uses RC4 as a credit card encryption algorithm at the moment, you could also look out for 3DES I guess. If you where to go all out one time pad it would take a bit of work.

I think RC4 can use between 1 and 2048 bits could be wrong.

Regards

Gavin

Crypto++ and Miracl libraries are two that I know of that will do what you are looking for. A quick search on google will give urls for them.

AES or 3DES as above in CFB mode would be grand for a couple of words.

I even have some sample code knocking around from a project I did just last semester actually. Nothing great, but demonstrates using the miracl library with AES in CFB mode.
http://www.redbrick.dcu.ie/~gavin/crypto.zip

Done in VC++, and uses RSA as well, but you can just ignore that part..

Gav

Dr_Teeth

The system will be written in Java, I'd prefer asymmetric keys (pub/priv) but I guess symmetric is fine as both sides will be trusted and have a secure means of passing a key across.

The speed of the algorithm isn't too important, it can be as slow as it likes relatively speaking as the load won't be too high and the plain-text will be very small as mentioned. The main things I'd like would be small ciphertext and security - in particular strong resistence to known plaintext attacks.

Teeth.

ecksor

Isn't 3des a block cipher?

As Verb pointed out, most block ciphers can be used in CFB mode, but I think this will also result in ciphertext that is larger than the plaintext? The best explanation I know of these issues is Chapter 5 of Security Engineering.

I'm not sure that you can avoid increasing the size and maintain security though. Assymetric keys used to generate unique session keys for a stream cipher would seem to be what you want, but you'll still end up passing around a lot more information than the original plaintext due to the key exchange. Why is size at such a premium if you're trying to protect such small pieces of data? The CipherInputStream and CipherOutputStream classes in the java security API would appear to be your friends but I don't know anything about their implementation.

One technique I've seen referenced quite a bit is to use a block cipher to encrypt a counter which will in turn generate a keystream that you can ecksor your plaintext with. If you have shared keys then this is a plausible solution, but bear in mind that you always want to have a different keystream, or else your protection against plaintext attacks goes out the window, so you need some way of communicating the inital value of the counter (or whatever) between the two parties.

I was wondering why so few stream ciphers seemed to be in common usage, and came across this paper on my search which you might find interesting. http://csrc.ncsl.nist.gov/encryption/modes/comments/Bellovin_and_Blaze.pdf