RE: Very Slow Encrypt?

William:

You are correct.  I have been fixing these time-specific limitations as I
find them.  I have been targeting the ASN.1 encode/decode operations in
SNACC, but the encrypt/decrypt are also of interest.  Thank you for pointing
this out, I have investigated the memory allocation in the Write function,
and I believe I can incorporate some other memory allocation improvements
that were added for decoding to the Write(...) method.  This will require
some testing, but it will be ready for our next release.

Bob Colestock
VDA.

-----Original Message-----
From: William Adams [mailto:[email protected]]
Sent: Friday, July 27, 2001 3:12 AM
To: SFL List (E-mail)
Subject: Very Slow Encrypt?



I am using the SFL libraries to encrypt some data. Currently I have been
using the RC2-CBC encryption algorithm and I have found it to be very very
slow (approx. 360seconds for 400K of data). So I stepped through the code
and the reason was this;

The RC2-CBC algorithm uses a block size of 8 bytes and whenever the buffer
it is holding the encrypted data in is full it will expand it by 8 bytes.
This means calloc-ing some memory and copying it into the new buffer. Now
for a large file (say 2Meg) this means it has to do about 250,000 calloc's
and memcpy's. By changing this and forcing it to increase the buffer by
1024bytes each time I found a speed increase of about 3000% ( 1 Meg would
now be encrypted in 31seconds as opposed to the 24+ minutes it took
before ).

The code which I noticed this in focused on the

void CSM_Free3::RawEncrypt(CSM_Buffer *pbufInput, CSM_Buffer *pbufOutput,
         Filter *pCBCEncryption, int iINBlockLen)

function, which is in sm_free3.cpp. This adds the encrypted data to the
CSM_Buffer using the Write function;

SME(pbufOutput->Write(&achOut[0], getLength));

The getLength variable passed in is the length of the new data to add
(always 8 for RC2-CBC). Now if you look at the Write function,
sm_buffer.cpp, you will see that the amount of extra memory allocated is
based on the length passed in, hence only 8 bytes.

Am I missing something here?
Is there a reason why it is done this way?
Has anyone else noticed this speed issue and found a different way to speed
the process up?

Regards

William Adams
Software Engineer
Nexor.
================
Tel:  +44 115 9535536
Fax: +44 115 9520519