Bo Sehlberg wrote:
>
> Hi Andy,
>
> You where right about the version 0.9.3(a).
> I made the following relevant modifications:
>
> - modified the 'envelopedData' handling as it didn't comply with
> the S/MIME specification.
This was a bug. Seems like most S/MIME clients ignore the type of the
encapsulated content so it didn't get noticed. Its fixed in the latest
snapshot.
> - tested to change (bigger) the read buffer size in 'dec' to see if this
> would decrease the time, but without luck (it's 100K in the example).
You'll see a big performance improvement the way things are currently
handled if you have a read buffer that is a significant fraction of the
data to be read, that is several Mb. Though I wouldn't advise it.
> - Finally I also changed the input/output format from PEM to DER, as this
> is what we want in the calling application.
>
There may be some PEM performance issues as well... which you've neatly
avoided :-)
> I also tried to dig down in the decryption code but gave up, )its really
> magic). So if you have any idea where to look I would be very greatful.
>
Andy described the problem pretty accurately in the previous post. There
are several ways to fix it, all a bit tricky.
One way is to enhance the way memory BIOs work so you don't always get
the "copy on read" behaviour.
Another way is to reorder the BIOs in the decode functions so it writes
through a chain ending in the output BIO of interest.
My preferred solution is to fix memory BIOs. I'm currently looking into
it.
There is a related problem in sign/encrypt which isn't as bad but it
still means that the whole file is kept in two separate memory buffers,
whereas one is only required.
Unfortunately the problem of it reading the whole structure into memory
is much harder to fix. It is theoretically possible for the code to be
able to read and write large files on the fly without having them
completely in memory. This involves "single pass processing" and would
involve major surgery on the OpenSSL ASN1 code because this largely
assumes ASN1 structures are completely in memory. Maybe some day...
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
