On Sat, Mar 24, 2007, Marco Roeland wrote: > On Saturday March 24th 2007 at 12:58 Harald Latzko wrote: > > > I compiled the 0.9.9 snapshot, resulting in a binary that has the > > same behaviour (growing in RAM very much). Do you know how to enable > > this experimental code and if this feature is included in the openssl > > command line tool? > > No, sorry I do not know how to enable the streaming encryption support > and it very probably will not be in the command line tool. > > I only know beginnings of streaming encryption support exist from posts > by Dr. Stephen Henson on this list. > > In the "CHANGES" file in the snapshot the following entries are relevant > to this feature I think: > > *) Very *very* experimental PKCS#7 streaming encoder support. Nothing uses > it yet and it is largely untested. > [Steve Henson] > > *) Support for single pass processing for S/MIME signing. This now > means that S/MIME signing can be done from a pipe, in addition > cleartext signing (multipart/signed type) is effectively streaming > and the signed data does not need to be all held in memory. > > This is done with a new flag PKCS7_STREAM. When this flag is set > PKCS7_sign() only initializes the PKCS7 structure and the actual signing > is done after the data is output (and digests calculated) in > SMIME_write_PKCS7(). > [Steve Henson] > > *) Extend ASN1 encoder to support indefinite length constructed > encoding. This can output sequences tags and octet strings in > this form. Modify pk7_asn1.c to support indefinite length > encoding. This is experimental and needs additional code to > be useful, such as an ASN1 bio and some enhanced streaming > PKCS#7 code. > > Extend template encode functionality so that tagging is passed > down to the template encoder. > [Steve Henson] > > So unless you can look at the code itself (start with the PKCS7_STREAM > flag probably, and the PKCS7_encrypt() function) and adapt from there it > is probably not useful yet. > > Sorry to have given you false hopes. The issue that all the data has to > be in working memory to be encrypted is indeed starting to become a real > annoyance in some practical circumstances. So perhaps if Stephen Henson > should develop the feature further one day we can volunteer as testers? ;-)
It still needs quite a bit of work to integrate it into the smime.c utility because by necessity the technique used is completely different. In essence it turns S/MIME into a filtering BIO where the content it pushed in one end and the PKCS#7 structure comes out the other. It is possible to chain the BIOs together and get signed+encrypted+signed data for example all streamed. Non-blocking I/O is also supported. What's there with support from smime.c could be made to work in pure DER format but the PEM encoders and the S/MIME encoder aren't fully streaming aware. As such there isn't much point streaming the DER stuff only to have the PEM for S/MIME code store the lot in memory. The companion operation of streaming decoding (decrypt, verify) for anything other than S/MIME cleartext verify is much harder to do and there is no support at all at present. I'm not sure when I'll get time to look at this again. That stuff was added over Christmas when things were quiet and it had been sitting on my hard drive for a couple of years. Like many people I have to concentrate on things that pay the bills and so far no one has offered to fund the streaming S/MIME development. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
