Hello,
Am 24.03.2007 um 14:39 schrieb Dr. Stephen Henson:
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.
This sounds very interesting to me. If I could help in testing or any
other non-deep development tasks, I would like to help as far as I
can (time is normally not the limiting factor for me). DER support is
exactly what I need, so if there is some code to test for DER-only
data handling feel free to contact me. Anything preventing to load
the whole data into memory helps me.
Regards,
Harald
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
