encryption ciphers

[Jeff Massung]

On Thu, Jun 17, 2010 at 4:22 AM, jim sims <sims at ezpzapps.com> wrote:

A wide variety of encryption ciphers seem to be available when I do "put the
> cipherNames"
>
> I have little knowledge about the merits or availability of ciphers, can
> anyone provide recommendations for a particular cipher and perhaps some
> reason why that cipher might be preferred?
>
> sims
>
>

Oh, it's been a while, so some of this may be out of date or I may
accidentally attribute one property of a cipher to another - so I *highly*
recommend using Wikipedia to lookup the basics of each.

For most modern encryption ciphers, they will fall into one of two
categories: secret key or pubic key.

A secret key encryption is where you have to know the key to encrypt and you
have to know what key was used to encrypt the message in order to decrypt it
as well. Technically speaking, secret key encryptions can be 100% guaranteed
to be uncrackable, but they fail in that you actually have to somehow
transmit the key to the end-user.

A public key encryption is based on the properties of large primes and the
fact that very large numbers (and I mean *big* numbers) are ever
increasingly more difficult to factor. The core concept is that there are
two keys used: one is private, and used to decrypt a message and one is
public and used to encrypt the message. You give out your public key to the
world, they encrypt whatever they want to send to you, and you are the only
one who can read it with the private key. The problem with public key
encryption is the typical man-in-the-middle attacks and trying to
authenticate that a message came from who you think it came from.

Most SSH, SSL, and similar internet protocols are based on the public key
encryption method. For example, with SSL, you have a "certificate" which
contains your public and private keys, and the server machine you
communicate with has one as well. When you make the secure connection, you
give the machine your public key and they give you theirs. Then you can
easily pass messages back and forth securely using each others' public keys.

When picking a cipher to use, you generally want to make your decision based
on a couple things:

1. Time to encrypt/decrypt and CPU resources required
2. Whether it's possible to securely hand off secret keys or not
3. How long each piece of data will be "usable" for

That last point is pretty key. If - for example - you are encrypting state
secrets, the data needs to be "usable" for years, and I promise you that
nothing Rev supports will be good enough... don't even bother. If the usable
time frame is on the order of minutes (e.g. an IM message), then just use
the simplest encryption method available to you, because the odds of someone
actually cracking it within that timeframe is incredibly small. Likely your
data is somewhere in the middle.

That said, when I put the cipherNames, I generally get this list:

AES, DES, BF, BLOWFISH, RC, CAST

To my knowledge, all of these fall under the "secret key" algorithm. The
number next to the name typically indicates the size of the key being used.
Most good keys are now well above the 512-bit size, and anything < 256 has
been broken fast in competitions.

My understanding is that AES is the worst (oldest), DES is better, DES3 is
better, BLOWFISH is quick and simple and a good compromise between
performance and security. I know nothing about RC or CAST, but I'm pretty
sure RC is just a derivative of AES.

Look into RSA or SSL (which uses RSA) if you want public key encryption.
There are libraries and tools out there (like OpenSSL) that will help you in
your quest.

Hope this helps. Don't use this email as God-speek, though, as it's been a
while since I did research in this area and it could be out of date (or even
flat out wrong in some areas). Wikipedia will be your friend here.

Jeff M.