in reply to Re: Encrypting Largish Files
in thread Encrypting Largish Files

I don't know if I'm clear on the concept. If you let the program choose a randomly large key (eg '23klsd9fjlsd09u3asdljf0' plus a few non-keyboard entries...) and then encrypt the file and send it off site to another location, how do you obtain that automatically generated key for decryption when needed in the future.

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

Replies are listed 'Best First'.
Re: Re: Re: Encrypting Largish Files
by projekt21 (Friar) on Sep 26, 2001 at 21:02 UTC

    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 <>
    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.


Re: Re: Re: Encrypting Largish Files
by IndyZ (Friar) on Sep 26, 2001 at 21:39 UTC
    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.