Thank you guys for all those great points.

I think I am getting to a conclusion, although some of you were not
concerned about the hashing of the X509_check_purpose() because it
happens only once, I am because yes indeed the one in the cache after
the first time will not need to rehash but the others are not going to
stay for the second time, I get a new one every time with the
signature, and I need to check it, so I still think that memcmp on the
original DER or PEM is the best.

Now about the inline implementations, and making that faster for a non
equal cert, a. I hope my system will deal more with equal certs then
non equal, in that case it is better to compare the entire cert right
away instead of starting with parts and the comparing all of it.

One available solution might be to keep track on those checks and if
you see you are starting to get more negative then positive comparison
then start from that last 4 byte. But this might cost an additional
incremental operation and additional compare every time, to check
those values.

However I am really not concerned about the difference between a
memcmp on the entire cert to the more advanced options of first
checking specific bytes, because after all although I need some thing
with great performance, I am not building a crypto hardware module
that has to be the best. so I think memcmp on the entire cert is
keeping it simple and fast and safe.

Thanks once again.

Joe

On 1/27/06, Dr. Stephen Henson wrote:
> On Fri, Jan 27, 2006, Richard Salz wrote:
>
> > > I'd consider an implementation of memcmp that doesn't early stop as s=

oon
> >
> > > as it sees a difference as completely broken, performance wise. Memcm=

p
> > > returns an ordered comparison but that can be done as soon as the fir=

st
> > > bit difference is seen.

> >
> > Me too. But look at the ASN1 for a certificate. Given two certs, how =

far
> > down the chain are you first likely to see a difference? Use that as y=

our
> > DER offset. That's why I suggested starting at the *end*. I should ha=

ve
> > left out the part about starting at the beginning.
> >

>
> The first four octets will most likely be 0x30, 0x82, len_high, len_low s=

o yes
> that wont tell you much. Starting from the end will access the signature
> which for valid (not maliciously constructed) certificates is likely to d=

iffer
> pretty quickly.
>
> For a valid match you still need to compare the whole thing of course.
>
> 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
> Development Mailing List openssl-dev@openssl.org
> Automated List Manager majordomo@openssl.org
>

__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org