Peter Sylvester wrote:
> 
> > Yes thats something I'm considering for the ASN1 revision. Something
> > like saving the lengths when the length is calculated and then using
> > them when the stuff is written out.
> Maybe one could cache the length in the ASN1 object. As long as any object
> is only used once, this might work.
> 

I'm thinking more in terms of a CTX parameter passed to a different API. 
The problem with many caching ideas and the current ASN1 library is that
things could be modified and the cache have no way of determining that
it is now invalid. Some parts are modified using a structured API
whereas others by directly accessing structures.

> >
> > However that's currently tricky because you'd have to add something like
> > a 'ASN1_CTX' parameter with the cached lengths somewhere. Painful with
> > the current spaghetti ASN1. Much easier when it all goes through a
> > common routine.
> Yes, openssl was probably not thought as a general asn1 tool anyway,
> but it isn't that bad.
> 

Oh believe me it is bad. The deeper you look into it the worse it
gets...

> If one decides the object structure, it might be useful to add a flag to
> whether the data should be freed when free is called, this would also
> avoid copying larger string buffers in some cases, especially
> when they could be static somewhere.
> 

Yes something like that exists with ASN1_OBJECT. It could be added to
ASN1_STRING as well.

> >
> > > I also remember another encoder that encoding in an inverted way
> > > from the end of the buffer after estimation of the length. No
> > > performance figures here.
> > >
> >
> > Yes I believe SNACC does that? The only difficulty with that is it makes
> > in much harder to write the encoded ASN1 to a stream if you use
> > indefinite length encoding.
> If you write BER, you don't have exactly the same problems as with DER.
> 

Well something like PKCS#7 or CMS would ideally do a mixture of BER and
DER. BER being used for the content and DER for everything else.

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]

Reply via email to