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 <[EMAIL PROTECTED]> wrote: > On Fri, Jan 27, 2006, Richard Salz wrote: > > > > I'd consider an implementation of memcmp that doesn't early stop as soon > > > > > as it sees a difference as completely broken, performance wise. Memcmp > > > returns an ordered comparison but that can be done as soon as the first > > > 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 your > > DER offset. That's why I suggested starting at the *end*. I should have > > left out the part about starting at the beginning. > > > > The first four octets will most likely be 0x30, 0x82, len_high, len_low so yes > that wont tell you much. Starting from the end will access the signature > which for valid (not maliciously constructed) certificates is likely to differ > 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 [EMAIL PROTECTED] > ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
