On Wed, Dec 08, 2004, prakash babu wrote:

> Hello all,
>  
>            There has been a tremendous performance during CRL check between 
> 0.9.7d and 0.9.7e
>            
>           I measured the time for checking the crl with 1,00,000 entries 
> using the following command
>           
>           time openssl verify -crl_check -CAfile $ssl_crl_dir/chain 
> $ssl_dir/bin/${demoCA}/newcerts/$serial
>           
>           The elapsed time is
>           
>           0.9.7d   0m1.14s
>           0.9.7e   0m0.69s
>           
>           1. What is the reason for the improvement in performance ?
>           
>           2. There has been an new encoding element added to the 
> X509_crl_info_st structure. What is it used for ?
>           
>           3. Are we caching the encoded CRL structure ?
>           
>           4. Why do we write lock while  sorting the crl ?
>        

Well I can answer all your questions at once by describing the change and why
it was necessary.

Before 0.9.7d the OpenSSL CRL handling of revoked entries had been unchanged
since the SSLeay days. Each CRL entry had a field which marked its position
from the original encoding.

Under this scheme searching a CRL would sort it into serial number order to
permit a binary search of its entries.

However verifying a CRL signature would require the restoration of the
original order to produce the correct encoding.

As a result verification followed by searching repeatedly would continuously
reorder the CRL entries.

The initial bug was that the two operations weren't thread safe and two
simultaneous reorderings could cause problems.

There were two possible fixes.

One was to lock the structure while a signature and serial search was under way:
this would retain the original logic but it is inefficient.

The second option, which I implemented, is to cache the original encoding and
use the cached form to verify signatures. This makes signature verification
much quicker since no reordering is necessary.  

This still requires lock when the revoked entries are sorted but they will stay
sorted: therefore no reordering is necessary after the first lookup.

There is a minor disadvantage to this method: if you call X509_CRL_print()
before a CRL entry search it will represent the original order whereas calling
it afterwards will print out in serial number order. There are ways to fix
that too but it would require some incompatible changes and will have to be
in 0.9.8.

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                    [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to