You may have already gotten this answer, but just in case you haven't... You're looking at two distinct problems. The first is protecting the data "in motion", and you basically need to look at the SSL routines and related authentication information (e.g., X.509 certificates). The data you put in the pipe is what you will get out on the other side. It could be plaintext or a previously encrypted file.
The other problem is protecting the data "at rest". This is where your AES encryption comes in, and all of the key management issues involved with symmetrical keys. HTH Bear > Folks, > > I apologize if this is a somewhat naïve or misinformed question, as I'm > new > to the OpenSSL APIs and not quite sure how things work yet. > > I'm developing an application in which we're using AES to encrypt files as > they're transferred from another system and saved to disk. We'd like to > provide the ability for the application to resume a transfer that was > interrupted mid-stream, but the encryption throws a bit of a wrench into > things because of the state associated with the encryption context. > > Is there a safe, supported way to stash the context somewhere on disk so > that encryption can be resumed where it left off when the file transfer > starts up again? We're currently looking at the EVP functions; would we > have to drop down to the lower-level, algorithm-specific routines to do > this > right? > > Thanks in advance for any guidance you can provide. > > -- > Jim Wong ([EMAIL PROTECTED]) > > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
