On Mon, Aug 4, 2014 at 4:50 AM, David Li <dlipub...@gmail.com> wrote:
> Hi Thulasi/Rich, > > Thanks! This prompted me to uncover another bug in the code. I did encrypt > an extra block of zeros! Now everything makes sense. > > Can't help to dig a little deeper into this: In AES-CBC mode, the > decryption can be paralleled. Is this what the EVP_DecryptUpdate is doing > behind the scene? > CBC decryption could be parallelised, but EVP_DecryptUpdate doesn't do it as it uses a single context. IV will be maintained in the context and would be updated only after decryption of each block. If you strictly want to parallelise, you can do it with considerable changes to your app by maintaining a separate context for each block and initializing all those contexts with corresponding IVs. Though I haven't quantified, I believe, the performance advantage that you try to get by parallelising would be lost in maintaining too many contexts. Parallelisation would be adavantageous for hardware multi-core crypto accelerators. > > For example, I need to break a long string into blocks to use > EVP_EncryptUpdate but I only need to feed the ciphertext into > EVP_DecryptUpdate once. > You don't have to break your input into blocks. EVP_EncryptUpdate can take input of any length. EVP_EncryptUpdate can(not must) be called multiple times when all the input to be encrypted is not available at once. i.e if you have a big file to be encrypted and you have only 4k byte read buffer, you can encrypt it in 4K byte chunks using EncryptUpdate. > > David > > > On Fri, Aug 1, 2014 at 8:36 PM, Salz, Rich <rs...@akamai.com> wrote: > >> Just wanted to say that Thulasi’s explanations and advice are exactly >> correct; thanks! >> >> >> >> -- >> >> Principal Security Engineer >> >> Akamai Technologies, Cambridge MA >> >> IM: rs...@jabber.me Twitter: RichSalz >> >> >> > >
