David, I'll try to explain what I'm trying to:
1. Generate some randomness openssl rand -base64 -out $FILE_PASS 2. Create MD5 checksum of that to use as password KEY=`openssl md5 <$FILE_PASS` 3. Create an encrypted tar, using the password from (2) tar -czvf - $WHAT 2>$FILE_LIST|openssl des3 -salt -k $KEY|dd of=$DEV 2>/dev/null $WHAT is the list of files to backup So now we have an encrypted tar on $DEV with the password from $KEY 4. Encrypt the randomness with customers public certificate openssl smime -encrypt -des3 $CUST_CERT <$FILE_PASS >$FILE_RAND (For some reason unknown this doesn't seem to work on my linux box. Windows is no problem) So now $FILE_RAND contains the $FILE_PASS encrypted with certificate $CUST_CERT 5. Sign $FILE_RAND with our company backup certificate openssl smime -sign -nodetach -signer $COMP_CERT $CUST_CERT <$FILE_RAND >$FILE_SIGN So now $FILE_SIGN contains $FILE_RAND signed with certificate $COMP_CERT Now I want to send the customer some mail containing the following: - Information about how long it took etc... (in the mail itself) - A complete filelist what was backupped ($FILE_LIST as zipped attachment) - The signed and encrypted randomness Now in case of system breakdown I need to be able to produce the reverse: 1. Check that my signature is correct (not required, but very handy) 2. Decrypt the randomness using customers private key 3. Use randomness' MD5 checksum to decrypt the backup. I must admit that I'd like to do the simple tar backup, but I'm contrained with legal matters of my customers (protected prefession), so I am REQUIRED to encrypt the backup itself. However, I don't want to make it very easy to restore. So I'm trying to devise a methos that ensures safety. Signing some file with our backup certificate is an important part of it, as it ensures it was our system that created the backup... I hope I explained it better this time :) Thanks again, Rory "Yep, > this is authentic, but meaningless" is rarely useful. > > A perfectly reasonable interpretation of your command > is to sign the plaintext and then encrypt it. This allows the > signature to remain even after the message is decrypted and > it can travel along with the plaintext. However, this makes > signature validation impossible without decryption. > > You should encrypt the message and then sign it, if > you're sure that's what you want. In that case, the signature > can be verified without decrypting the message, however, > nobody but the intended recipient can verify the signature in > any meaningful way. > > Think about it a bit and make sure that what you really > want is for people other than the intended recipient to be > able to verify the signature on a message they can make no > sense of whatsoever. It's hard to imagine many cases where > that's useful, and in most cases where it seems useful, there > are better ways to get at least the usefulness you get this way. > > DS > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List [email protected] > Automated List Manager [EMAIL PROTECTED] > > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
