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