Rather, the internal state is an array of 256 bytes, one holding each value, that is shuffled into some permutation. The input letters of the passphrase control the shuffling details.

So, the actual "strength" of the cipher is that it has 256! possible states. So, the "key" is approximatly 1683 bits, since there are 2**1683 possible states for the cipher to be set-up into.

If you know something about how the passphrase is chosen, then an attacker can search far less than that many possibilities. E.g. with 96 ASCII chars and 8 char length, only 96**8 or 2**52 of the possible keys will ever be used. In order to say the system has an effective key size of 52 bits, the attacker would have to know that, and know which 2**52 keys are available. That's the case with "40 bit" SSL.

—John

Just for clarification, could you explain your math. How do you get from 256 states to to 1683 bits as 256 * 8 = 2048?

Also, when you say "only 96^8 or 2^52" how are these two equivalent as 96^8 = 7.21e15 and 2^52 = 4.5e15 or did you mean something different?

I'm only asking because I'm just starting to learn about cryptography..

As a side note, how long does it currently take to brute force your way through 4.5e15 keys using non-military strength computers. (assumes that hackers have only consumer to academic calibur machines.)?
--
Filmo the Klown

256! (factorial), not 256*8. Start with the list 0..255 and shuffle it. That list is 2048 bits long, but you will never have, for example, two bytes both containing 42. So the number of legal states is smaller than the number of states that this much memory can represent.

7.21e15 vs 4.5e15 : within a factor of 2 (1 bit). Fractional bits don't count, so round down. 2^52 is a little small, but 2^53 is too large.

—John

You're probably fooling youself a bit... The first stage in almost any cgi exploit is to find a way to read the source code. There are lots of ways to do this, but a classic one is to use one insecure CGI to read the source of another. I frequently get entries in my access_log that look like this:

GET http://whatever.com/cgi-bin/some.cgi?file=../cgi-bin/someother.cgi
[download]

If the author of some.cgi wasn't careful, its possible that some.cgi will spit back the source to someother.cgi.

-Blake

Remember, the original purpose of this was to encyrpt mySQL dumps on a daily basis and send them offsite for backup purposes.

If it involves sending the key to the backup site, then I'd need a secondary encryption system such as PGP to send the keys securly, in addition to a way to tie each unqiue key with each unique data file. Murphy's Law says that when you try to decrypt one of 365 daily files in a year, its going to be that days key that you've misplaced.

It seems to me for this to be practical, you would want to avoid having to track randomly generated keys to try and decrypt your files at some future date. My limited understanding is that Public key encryption is much more processor intensive than private key encryption so this is also a concern given the large size of mySQL dumps and the possiblility of simply PGPing the mySQL dump.
--
Filmo the Klown

Partially right. PGP uses private (symetric) key encryption for the data and public (asymetric) key encryption for the secret (symetric) key. Clever guy that Phil, eh?

alex pleiner <alex@zeitform.de>
zeitform Internet Dienste

Zimmerman deserves his plaudits, though this one might be a bit misguided... It was actually Whitfield Diffie and Martin Hellman that came up with the concept of asymetric keys... Ron Rivest, Adi Shamir and Len Adleman (RSA) get credit for finding a mathematical algorithm that is suitable for this purpose. And Phil Zimmerman deserves credit for implementing the algorithm in code, and for the balls to release it openly in spite of the government and RSA breathing down his neck.

For further information I'd recommend Simon Singh's The Code Book.

-Blake

If you want to use the same key every day, you can randomly generate the key, and then move it via a physical medium between locations, or just move the key with PGP (once). With some algorithms, this will make you more vulnerable to an attack. Using a different key everyday is similar to a onetime pad system. It will probably be the most secure option because if the attacker breaks one days key, he will have to start over from scratch for every other day. If they break the PGP key that you are using the transfer the daily key, however, they will be able to read all of your one time keys. Asymetric (public/private) keypairs probably aren't necessary, since you shouldn't have to give out either key. It could be a good idea though, since if your server (with only copy of the public key) is compromised, the archives will still be safely encrypted.

Cryptography is a complicated science that I don't personally feel qualified to make a specific recommendation about. For a good overview of different cryptographic techniques and algorithms, go get a copy of Applied Cryptography by Bruce Schneier. It's quite good, especially if you like books with source code included.

Now, let's think simpler: The real question here is how secure does your data have to be? If absolute security is a must, the don't send your data over the internet at all. Put it onto DATs and hire a courier to transport it for you. You might also want to consider a VPN, which will automatically encrypt all traffic over a network link. Your server must be secure also. If the attacker can get into the server and steal the unencrypted data, there is no point in encrypting it first.

Wrap up: Sorry that was so long a rambling. Remember, your server must be secure first. Think simple, but secure. Physically moving the medium is more secure than emailing or ftp'ing it. If your data is that important to you (credit card numbers, social security numbers, bank transactions), hire a professional who has experience in this field.

--
IndyZ