Encryption performance problem

[John Stark <jas@xxxxxxxxxxxx>]

Hello,

I am attempting to port an application from SFL 2.1 to 2.3.  In SFL 2.1
there was a serious memory management flaw in the class CSM_Buffer. 
When encrypting a message, however large, it realloc'ed the buffer to
add 8 bytes at a time.  Hence it took several minutes to encrypt a 10MB
content.  I fixed CSM_Buffer to do fewer reallocs and gained acceptable
performance.  I submitted my fix to this list at the time.

The SFL 2.1 code containing my fix will encrypt a 10MB message using
3DES in around 3.4 seconds, using a release build on a 3000MHz P4. 
However, I have just written a test program using SFL 2.3 and found that
3DES encryption of a 10MB content takes around 24 seconds, about 2/3 of
which is in system calls, on the same system.  So it would appear that
the memory management in SFL 2.3, whilst not as broken as in 2.1, still
has severe deficiencies.  As it stands it cannot be deployed in our
application, which is often run on systems much slower than my PC.

RC2 encryption yields similar results.  AES encryption takes 19 seconds,
but very little is system CPU time, which suggests that the memory
management is better but the implementation of the algorithm is slow. 
The AES encryption in SFL 2.1 was faulty anyway.

SFL 2.1 also had another problem which emerged during stress testing
(initially attempted with a 1GB message).  Even if I supplied the
content to encrypt or sign in a file-based CSM_Buffer (which worked
fine), the SFL classes internally allocated memory-based rather than
file-based CSM_Buffers.  Memory usage peaked at around 4x the content
size during encryption or 6x the content size when signing.  I have not
so far tested SFL 2.3 to see whether this has been remedied.

Could you please let me know when a release of SFL will be available
that has had these memory management issues addressed.

Thank you,
John Stark
-- 
John Stark
Tel: +44 1223 566732
Mobile: +44 7968 110628
E-mail: jas@xxxxxxxxxxxx
Web: http://www.metanate.com