> 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? Maybe you're locked into an implementation that isn't logical for your problem set, but if not, change to a rational implementation. If you are encrypting/decrypting during the transfer, that means the encryption is to protect the transport. Since the resumption is over a new transport, there is no rational reason to resume the previous encryption. Use a new encryption context for the new transport. If the encryption is for storage, then resume sending the already-encrypted data. The only case where you even have the problem you are describing is where the data has to be encrypted differently from its normal state for storage on the receiver. (Perhaps to be decrypted later.) Unless you're in this very unusual situation, this shouldn't be an issue. If you really are in this very unusual situation, I recommend one of the following solutions: 1) Have a resync protocol that runs on both ends, re-encrypting the data and sending block checksums. Let the other side verify the checksum until you have a mismatch, then continue. You don't need to store the context because this process recovers it. 2) Encrypt the file as a group of separate blocks. Simply discard any incomplete blocks. Each block can have its own encryption context, so there is no need to resume. 3) Use an encryption scheme that has negligible context. For example, if you XOR each block of data with its block number and then encrypt it, all you need to pick back up where you left off is the block number, which you should already know. Give us more details and tell us what you can and can't change. Your proposed solution may not be the best one to your actual outer problem. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
