Hi Jakob, Thanks, this is exactly the help I was looking for.
Cheers! Sean On Thu, Jan 23, 2014 at 2:05 PM, Jakob Bohm <jb-open...@wisemo.com> wrote: > On 1/23/2014 4:55 PM, Sean Langley wrote: > >> Hi All, >> >> I have been using AES 256, CTR mode to encrypt the contents of a file on >> disk. The IV for the file is written to the first 16 bytes followed by >> the encrypted file data. Up to now, this encrypted data is created with >> a single encryption session. This is all on a mobile device, using FIPS >> mode with relatively limited resources, compared with a desktop. >> >> I'd like to be able to append to this encrypted file. In order to do >> this, I need to decrypt the final block (in the event there is a partial >> block that has been written to the encrypted stream), start the >> plaintext portion with this last block, and continue the encryption of >> additional data in the file, using a new encryption session. >> >> I've gone through the AES code, and the only way I've found is to set >> the state of the initial decryption/encryption based on the number of >> blocks, and creating a working IV for the start of the decryption and >> encryption process. This has not been successful for me yet, for some >> reason. >> >> Is there a better way to do this with the current OpenSSL API's (EVP, or >> lower level)? >> >> Any help would be greatly appreciated. >> >> >> > CTR mode doesn't really use an IV like CBC, just a block counter and a > fixed value. So for CTR mode you never decrypt the last block to set > up continuation and there is little point in using the first block as > an "IV". > > So basically, you just need to set it up with the same fixed value as > the first time, but with a counter corresponding to the block offset > where you will start. Next, if the previous contents ended in the > middle of a block, just put some unused bytes (0 to block size - 1) > in front of the new data and throw that many bytes of the result away. > > Another key trick for CTR mode is to run it in the background before > you even have the data (you may need to pass zeroes as input), and then > just XOR the resulting stream onto the data when you get it. This can > be a real benefit on embedded devices that run AES slowly and get the > data to encrypt or decrypt from something other than its own > calculations. > > With a little tweaking, these tricks also work for GCM mode, since it > is mostly CTR mode with a checksum computed in parallel and then > encrypted. > > > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com > Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org >
