Re: Comparing certificates, with out rehashing (compare public keys - issuer and serial number)
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]
Re: Comparing certificates, with out rehashing (compare public keys - issuer and serial number)
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]
Re: Comparing certificates, with out rehashing (compare public keys - issuer and serial number)
> 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. /r$ -- SOA Appliance Group IBM Application Integration Middleware __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Comparing certificates, with out rehashing (compare public keys - issuer and serial number)
On Thu, Jan 26, 2006, Joe Gluck wrote: > That attack is interesting, how can that be done, (sorry for bothering you > :-) ) > If you don't check the parameters its is possible with some algorithms to generate a key pair with a given public key component using a carefully derived set of parameters. Basically it leaves security wide open. > But cutting down the X509_cmp will not work because the memcmp > compares the hash which if I will cut out the X509_check_purpose lines > will not make any sense. > Obviously you'd call X509_check_purpose() once when the certificate is loaded. > But I think the best idea is to compare the entire text of the entire > certificate (The text as I get in a PEM format before loading it into > the X509 object. it is faster than hashing the same size and comparing > the hash. > But slower than comparing a cached cache. The actual overhead of hashing the certificate once when it is initially loaded is pretty tiny compared to some of the other things that already happen. 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]
Re: Comparing certificates, with out rehashing (compare public keys - issuer and serial number)
Richard Salz wrote: So now the question is, are there times when you can avoid the memcmp? [...] compare some initial bytes. [...] only call memcmp if they match. [...] 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. You might want to consider an in-line implementation of memcmp to save the function call time. But seriously this is not what will make a performance difference. It's a fixed time that is negligible with regard to other incompressible processing operations required for each reception. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Comparing certificates, with out rehashing (compare public keys - issuer and serial number)
I was also concerned about some one messing with the headers or any other field, but those check I did only after the public key did not match, because if the public key matches to one in the cache and the one in the cache is fully verified, then I don't care for additional checks. And if it fails I can call additional functions to analyze the reason for the error. but the idea of comparing first just a few bytes I am not sure it will be so much faster, because the memcmp internally also does not compare the entire block at once, and if finds an unequal it will stop comparing on the spot and return. The only thing that might make it a bit slower is if it first loads the entire block into some other place in memory which I doubt because it can't compare the entire block at once anyway. Thanks, Joe On 1/26/06, Richard Salz <[EMAIL PROTECTED]> wrote: > You should probably also be concerned with someone messing with the > header and making you get "false" denials. For that reason, and because > it's generally safer, you want to use the DER, not any wrapped format; for > example, line endings might change. > > Doing memcmp() on the DER will be more efficient (time and space) than > X509_cmp, not the least of which is that it avoids creating an X509 from > the DER. > > So now the question is, are there times when you can avoid the memcmp? > Sure. Since you've done the base64 decode, you should have the length, so > compare lengths first. Second, compare some initial bytes. Any > certificate will start with the same few bytes, so something like > comparing bytes 4-8, or the *last* four bytes of each DER buffer, can be > done, and only call memcmp if they match. At start time, take the four > bytes from your known-correct DER, pack them into an int, and then when > you get a new cert coming in, do the same pack and then a single integer > compare. If they match, do memcmp. > > Hope this helps. > >/r$ > > -- > SOA Appliance Group > IBM Application Integration Middleware > > __ > 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]
Re: Comparing certificates, with out rehashing (compare public keys - issuer and serial number)
You should probably also be concerned with someone messing with the header and making you get "false" denials. For that reason, and because it's generally safer, you want to use the DER, not any wrapped format; for example, line endings might change. Doing memcmp() on the DER will be more efficient (time and space) than X509_cmp, not the least of which is that it avoids creating an X509 from the DER. So now the question is, are there times when you can avoid the memcmp? Sure. Since you've done the base64 decode, you should have the length, so compare lengths first. Second, compare some initial bytes. Any certificate will start with the same few bytes, so something like comparing bytes 4-8, or the *last* four bytes of each DER buffer, can be done, and only call memcmp if they match. At start time, take the four bytes from your known-correct DER, pack them into an int, and then when you get a new cert coming in, do the same pack and then a single integer compare. If they match, do memcmp. Hope this helps. /r$ -- SOA Appliance Group IBM Application Integration Middleware __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Comparing certificates, with out rehashing (compare public keys - issuer and serial number)
We first encode in a base64 then add it into a SMTP email header, so i don't think any mail system on the way would play with the value of the base64, because that can break any system that works over SMTP. What they might do is change the line length and add some \r\n and or white spaces but those we clear any way before decoding the base64, so after this process it is guaranteed to be the same exact PEM file. And there is only one system that will create the original PEM file so I don't think that is an issue. Joe On 1/26/06, Lev Walkin <[EMAIL PROTECTED]> wrote: > Joe Gluck wrote: > > That is correct but in my case I am getting the cert in PEM, and it is > > created by another application we develop so it should be an exact > > duplicate if it is actually the same one. > > This is only true if you can guarantee that the certificate in PEM > reaches your system only once. > > If you can transfer PEM from the application your team is developing > using different means (email, file transfer, web publishing), it is > practically guaranteed that the PEM contents would not match. If only > for different line ending conventions between different systems. > > Even if you can guarantee that the certificate reaches your certificate > storage only once, you can just as well compare a pointer to the > structure which keeps this certificate's PEM contens. > > > > On 1/26/06, Lev Walkin <[EMAIL PROTECTED]> wrote: > >> Joe Gluck wrote: > >>> That attack is interesting, how can that be done, (sorry for bothering > >>> you :-) ) > >>> > >>> But cutting down the X509_cmp will not work because the memcmp > >>> compares the hash which if I will cut out the X509_check_purpose lines > >>> will not make any sense. > >>> > >>> But I think the best idea is to compare the entire text of the entire > >>> certificate (The text as I get in a PEM format before loading it into > >>> the X509 object. it is faster than hashing the same size and comparing > >>> the hash. > >> You should then consider comparing DER encoding, not the PEM wrapper > >> around the DER certificate contents. > >> > >> PEM encoding of the same certificate can be different, due to relaxed > >> rules about whitespace characters. > >> > >>> Thanks > >>> > >>> On 1/26/06, Dr. Stephen Henson <[EMAIL PROTECTED]> wrote: > On Thu, Jan 26, 2006, Joe Gluck wrote: > > > Thank you. > > I still am not sure if it the best idea, > > > > Because i will be getting for example 1,000,000 a times in a day the > > same certificate, I don't want to do that even short process if not > > necessary, what I could do is compare the times between X509_cmp() and > > my code, or even to doing memcmp() on the original text of the X509. > > > > So I would like to know if any one thinks there is a problem with how > > i am doing it, or if it will be slower then using some other way to do > > it? > > > Your algorithm ends up accessing X509 structure internals which isn't a > good > idea if it can be avoided. It also doesn't compare the whole public key: > you'd > also need to compare the algorithm type and its parameters (if any). > There are > sound reasons as to why you should also check parameters. If you don't > there > are some interesting key substitution attacks that could spoil your > whole day... > > If structure internal access is considered acceptable you can cut the > whole > thing down to the memcmp() of X509_cmp(). > > 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] > >>> > >> __ > >> 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
Re: Comparing certificates, with out rehashing (compare public keys - issuer and serial number)
Joe Gluck wrote: That is correct but in my case I am getting the cert in PEM, and it is created by another application we develop so it should be an exact duplicate if it is actually the same one. This is only true if you can guarantee that the certificate in PEM reaches your system only once. If you can transfer PEM from the application your team is developing using different means (email, file transfer, web publishing), it is practically guaranteed that the PEM contents would not match. If only for different line ending conventions between different systems. Even if you can guarantee that the certificate reaches your certificate storage only once, you can just as well compare a pointer to the structure which keeps this certificate's PEM contens. On 1/26/06, Lev Walkin <[EMAIL PROTECTED]> wrote: Joe Gluck wrote: That attack is interesting, how can that be done, (sorry for bothering you :-) ) But cutting down the X509_cmp will not work because the memcmp compares the hash which if I will cut out the X509_check_purpose lines will not make any sense. But I think the best idea is to compare the entire text of the entire certificate (The text as I get in a PEM format before loading it into the X509 object. it is faster than hashing the same size and comparing the hash. You should then consider comparing DER encoding, not the PEM wrapper around the DER certificate contents. PEM encoding of the same certificate can be different, due to relaxed rules about whitespace characters. Thanks On 1/26/06, Dr. Stephen Henson <[EMAIL PROTECTED]> wrote: On Thu, Jan 26, 2006, Joe Gluck wrote: Thank you. I still am not sure if it the best idea, Because i will be getting for example 1,000,000 a times in a day the same certificate, I don't want to do that even short process if not necessary, what I could do is compare the times between X509_cmp() and my code, or even to doing memcmp() on the original text of the X509. So I would like to know if any one thinks there is a problem with how i am doing it, or if it will be slower then using some other way to do it? Your algorithm ends up accessing X509 structure internals which isn't a good idea if it can be avoided. It also doesn't compare the whole public key: you'd also need to compare the algorithm type and its parameters (if any). There are sound reasons as to why you should also check parameters. If you don't there are some interesting key substitution attacks that could spoil your whole day... If structure internal access is considered acceptable you can cut the whole thing down to the memcmp() of X509_cmp(). 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] __ 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] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Comparing certificates, with out rehashing (compare public keys - issuer and serial number)
That is correct but in my case I am getting the cert in PEM, and it is created by another application we develop so it should be an exact duplicate if it is actually the same one. On 1/26/06, Lev Walkin <[EMAIL PROTECTED]> wrote: > Joe Gluck wrote: > > That attack is interesting, how can that be done, (sorry for bothering you > > :-) ) > > > > But cutting down the X509_cmp will not work because the memcmp > > compares the hash which if I will cut out the X509_check_purpose lines > > will not make any sense. > > > > But I think the best idea is to compare the entire text of the entire > > certificate (The text as I get in a PEM format before loading it into > > the X509 object. it is faster than hashing the same size and comparing > > the hash. > > You should then consider comparing DER encoding, not the PEM wrapper > around the DER certificate contents. > > PEM encoding of the same certificate can be different, due to relaxed > rules about whitespace characters. > > > Thanks > > > > On 1/26/06, Dr. Stephen Henson <[EMAIL PROTECTED]> wrote: > >> On Thu, Jan 26, 2006, Joe Gluck wrote: > >> > >>> Thank you. > >>> I still am not sure if it the best idea, > >>> > >>> Because i will be getting for example 1,000,000 a times in a day the > >>> same certificate, I don't want to do that even short process if not > >>> necessary, what I could do is compare the times between X509_cmp() and > >>> my code, or even to doing memcmp() on the original text of the X509. > >>> > >>> So I would like to know if any one thinks there is a problem with how > >>> i am doing it, or if it will be slower then using some other way to do > >>> it? > >>> > >> Your algorithm ends up accessing X509 structure internals which isn't a > >> good > >> idea if it can be avoided. It also doesn't compare the whole public key: > >> you'd > >> also need to compare the algorithm type and its parameters (if any). There > >> are > >> sound reasons as to why you should also check parameters. If you don't > >> there > >> are some interesting key substitution attacks that could spoil your whole > >> day... > >> > >> If structure internal access is considered acceptable you can cut the whole > >> thing down to the memcmp() of X509_cmp(). > >> > >> 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] > > > > __ > 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]
Re: Comparing certificates, with out rehashing (compare public keys - issuer and serial number)
Joe Gluck wrote: That attack is interesting, how can that be done, (sorry for bothering you :-) ) But cutting down the X509_cmp will not work because the memcmp compares the hash which if I will cut out the X509_check_purpose lines will not make any sense. But I think the best idea is to compare the entire text of the entire certificate (The text as I get in a PEM format before loading it into the X509 object. it is faster than hashing the same size and comparing the hash. You should then consider comparing DER encoding, not the PEM wrapper around the DER certificate contents. PEM encoding of the same certificate can be different, due to relaxed rules about whitespace characters. Thanks On 1/26/06, Dr. Stephen Henson <[EMAIL PROTECTED]> wrote: On Thu, Jan 26, 2006, Joe Gluck wrote: Thank you. I still am not sure if it the best idea, Because i will be getting for example 1,000,000 a times in a day the same certificate, I don't want to do that even short process if not necessary, what I could do is compare the times between X509_cmp() and my code, or even to doing memcmp() on the original text of the X509. So I would like to know if any one thinks there is a problem with how i am doing it, or if it will be slower then using some other way to do it? Your algorithm ends up accessing X509 structure internals which isn't a good idea if it can be avoided. It also doesn't compare the whole public key: you'd also need to compare the algorithm type and its parameters (if any). There are sound reasons as to why you should also check parameters. If you don't there are some interesting key substitution attacks that could spoil your whole day... If structure internal access is considered acceptable you can cut the whole thing down to the memcmp() of X509_cmp(). 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] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Comparing certificates, with out rehashing (compare public keys - issuer and serial number)
If you run an SHA hash on the PEM-formatted certificate that you receive, then you can just use that as a primary key into a database of some form that stores the certificate, as well as the information that it authenticates. -Kyle H On 1/26/06, Joe Gluck <[EMAIL PROTECTED]> wrote: > That attack is interesting, how can that be done, (sorry for bothering you > :-) ) > > But cutting down the X509_cmp will not work because the memcmp > compares the hash which if I will cut out the X509_check_purpose lines > will not make any sense. > > But I think the best idea is to compare the entire text of the entire > certificate (The text as I get in a PEM format before loading it into > the X509 object. it is faster than hashing the same size and comparing > the hash. > > Thanks > > On 1/26/06, Dr. Stephen Henson <[EMAIL PROTECTED]> wrote: > > On Thu, Jan 26, 2006, Joe Gluck wrote: > > > > > Thank you. > > > I still am not sure if it the best idea, > > > > > > Because i will be getting for example 1,000,000 a times in a day the > > > same certificate, I don't want to do that even short process if not > > > necessary, what I could do is compare the times between X509_cmp() and > > > my code, or even to doing memcmp() on the original text of the X509. > > > > > > So I would like to know if any one thinks there is a problem with how > > > i am doing it, or if it will be slower then using some other way to do > > > it? > > > > > > > Your algorithm ends up accessing X509 structure internals which isn't a good > > idea if it can be avoided. It also doesn't compare the whole public key: > > you'd > > also need to compare the algorithm type and its parameters (if any). There > > are > > sound reasons as to why you should also check parameters. If you don't there > > are some interesting key substitution attacks that could spoil your whole > > day... > > > > If structure internal access is considered acceptable you can cut the whole > > thing down to the memcmp() of X509_cmp(). > > > > 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] > __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Comparing certificates, with out rehashing (compare public keys - issuer and serial number)
That attack is interesting, how can that be done, (sorry for bothering you :-) ) But cutting down the X509_cmp will not work because the memcmp compares the hash which if I will cut out the X509_check_purpose lines will not make any sense. But I think the best idea is to compare the entire text of the entire certificate (The text as I get in a PEM format before loading it into the X509 object. it is faster than hashing the same size and comparing the hash. Thanks On 1/26/06, Dr. Stephen Henson <[EMAIL PROTECTED]> wrote: > On Thu, Jan 26, 2006, Joe Gluck wrote: > > > Thank you. > > I still am not sure if it the best idea, > > > > Because i will be getting for example 1,000,000 a times in a day the > > same certificate, I don't want to do that even short process if not > > necessary, what I could do is compare the times between X509_cmp() and > > my code, or even to doing memcmp() on the original text of the X509. > > > > So I would like to know if any one thinks there is a problem with how > > i am doing it, or if it will be slower then using some other way to do > > it? > > > > Your algorithm ends up accessing X509 structure internals which isn't a good > idea if it can be avoided. It also doesn't compare the whole public key: you'd > also need to compare the algorithm type and its parameters (if any). There are > sound reasons as to why you should also check parameters. If you don't there > are some interesting key substitution attacks that could spoil your whole > day... > > If structure internal access is considered acceptable you can cut the whole > thing down to the memcmp() of X509_cmp(). > > 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]
Re: Comparing certificates, with out rehashing (compare public keys - issuer and serial number)
On Thu, Jan 26, 2006, Joe Gluck wrote: > Thank you. > I still am not sure if it the best idea, > > Because i will be getting for example 1,000,000 a times in a day the > same certificate, I don't want to do that even short process if not > necessary, what I could do is compare the times between X509_cmp() and > my code, or even to doing memcmp() on the original text of the X509. > > So I would like to know if any one thinks there is a problem with how > i am doing it, or if it will be slower then using some other way to do > it? > Your algorithm ends up accessing X509 structure internals which isn't a good idea if it can be avoided. It also doesn't compare the whole public key: you'd also need to compare the algorithm type and its parameters (if any). There are sound reasons as to why you should also check parameters. If you don't there are some interesting key substitution attacks that could spoil your whole day... If structure internal access is considered acceptable you can cut the whole thing down to the memcmp() of X509_cmp(). 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]
Re: Comparing certificates, with out rehashing (compare public keys - issuer and serial number)
memcmp in this case is reading 10 32-bit words into registers, and XORing the appropriate pairs. If any of them don't match, it fails. You can't exactly get much faster than that. Since the hash on each certificate is calculated once, and then is cached (the hash takes into account the entire certificate, not just the public key -- this can become important if the same public key occurs in two separate certificates, one valid and one invalid), the memcmp() route is the fastest option. (Note also that every time a certificate is initially presented, it must be fully hashed in order to verify the certificate chain.) -Kyle H On 1/26/06, Joe Gluck <[EMAIL PROTECTED]> wrote: > Thank you. > I still am not sure if it the best idea, > > Because i will be getting for example 1,000,000 a times in a day the > same certificate, I don't want to do that even short process if not > necessary, what I could do is compare the times between X509_cmp() and > my code, or even to doing memcmp() on the original text of the X509. > > So I would like to know if any one thinks there is a problem with how > i am doing it, or if it will be slower then using some other way to do > it? > > Thanks in advance (And thank you Dr. Stephen Henson) > > Joe > > On 1/26/06, Dr. Stephen Henson <[EMAIL PROTECTED]> wrote: > > On Thu, Jan 26, 2006, Joe Gluck wrote: > > > > > That is great to know because I did not know if while loading the > > > certiicate it parses the fields and hashes or just loads it. > > > > > > > It parses most fields. The public key and extension parts aren't parsed > > until > > a call is explicitly made to parse them. > > > > > > > But any way, if I call the X509_cmp() it will do the > > > X509_check_purpose() and I would like to avoid that by just getting > > > the public key part and doing memcmp on it with the one already in my > > > cache. > > > > > > > X509_check_purpose() with those parameters just checks to see if the hash > > (and > > other things) is valid, if not calculating it and then returns. So after > > that > > first call it is a no op. > > > > 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] > __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Comparing certificates, with out rehashing (compare public keys - issuer and serial number)
Thank you. I still am not sure if it the best idea, Because i will be getting for example 1,000,000 a times in a day the same certificate, I don't want to do that even short process if not necessary, what I could do is compare the times between X509_cmp() and my code, or even to doing memcmp() on the original text of the X509. So I would like to know if any one thinks there is a problem with how i am doing it, or if it will be slower then using some other way to do it? Thanks in advance (And thank you Dr. Stephen Henson) Joe On 1/26/06, Dr. Stephen Henson <[EMAIL PROTECTED]> wrote: > On Thu, Jan 26, 2006, Joe Gluck wrote: > > > That is great to know because I did not know if while loading the > > certiicate it parses the fields and hashes or just loads it. > > > > It parses most fields. The public key and extension parts aren't parsed until > a call is explicitly made to parse them. > > > > But any way, if I call the X509_cmp() it will do the > > X509_check_purpose() and I would like to avoid that by just getting > > the public key part and doing memcmp on it with the one already in my > > cache. > > > > X509_check_purpose() with those parameters just checks to see if the hash (and > other things) is valid, if not calculating it and then returns. So after that > first call it is a no op. > > 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]
Re: Comparing certificates, with out rehashing (compare public keys - issuer and serial number)
On Thu, Jan 26, 2006, Joe Gluck wrote: > That is great to know because I did not know if while loading the > certiicate it parses the fields and hashes or just loads it. > It parses most fields. The public key and extension parts aren't parsed until a call is explicitly made to parse them. > But any way, if I call the X509_cmp() it will do the > X509_check_purpose() and I would like to avoid that by just getting > the public key part and doing memcmp on it with the one already in my > cache. > X509_check_purpose() with those parameters just checks to see if the hash (and other things) is valid, if not calculating it and then returns. So after that first call it is a no op. 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]
Re: Comparing certificates, with out rehashing (compare public keys - issuer and serial number)
That is great to know because I did not know if while loading the certiicate it parses the fields and hashes or just loads it. But any way, if I call the X509_cmp() it will do the X509_check_purpose() and I would like to avoid that by just getting the public key part and doing memcmp on it with the one already in my cache. Thanks, Joe On 1/26/06, Dr. Stephen Henson <[EMAIL PROTECTED]> wrote: > On Thu, Jan 26, 2006, Joe Gluck wrote: > > > That is good to know, and I assumed it will hash only once, but I want > > to skip that one time as well, and have the verification done only > > once on the certificate, and then while my application may run for a > > year, I just want to compare the public key with memcpy even without > > that one time hash, (unless that hash also is done automaticly when > > loading the cert into the X509 before calling the compare function. > > > > It isn't currently always calculated when a certifcate is loaded into an X509 > structure but you can call X509_check_purpose(cert, -1, 0) once after it has > been loaded to calculate it. > > 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]
Re: Comparing certificates, with out rehashing (compare public keys - issuer and serial number)
On Thu, Jan 26, 2006, Joe Gluck wrote: > That is good to know, and I assumed it will hash only once, but I want > to skip that one time as well, and have the verification done only > once on the certificate, and then while my application may run for a > year, I just want to compare the public key with memcpy even without > that one time hash, (unless that hash also is done automaticly when > loading the cert into the X509 before calling the compare function. > It isn't currently always calculated when a certifcate is loaded into an X509 structure but you can call X509_check_purpose(cert, -1, 0) once after it has been loaded to calculate it. 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]
Re: Comparing certificates, with out rehashing (compare public keys - issuer and serial number)
That is good to know, and I assumed it will hash only once, but I want to skip that one time as well, and have the verification done only once on the certificate, and then while my application may run for a year, I just want to compare the public key with memcpy even without that one time hash, (unless that hash also is done automaticly when loading the cert into the X509 before calling the compare function. Thanks, Joe On 1/26/06, Dr. Stephen Henson <[EMAIL PROTECTED]> wrote: > On Thu, Jan 26, 2006, Joe Gluck wrote: > > > Hi, > > > > > > I am using OpenSSL and although they have the X509_cmp() function, I > > prefer not to use it because it rehashes the certificate (or at least > > it seems so to me) and I want to get the maximum performance I can > > get., so I built my own compare function and I would like to hear your > > opinion. > > > > It calculates the certificate hash once and caches the result. > > Various operations in OpenSSL automatically calculate the hash: for example > the standard certificate verification process. > > So after the first hash it simply does a memcmp() of two 20 byte buffers which > should be efficient enough for anyone... > > 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]
Re: Comparing certificates, with out rehashing (compare public keys - issuer and serial number)
On Thu, Jan 26, 2006, Joe Gluck wrote: > Hi, > > > I am using OpenSSL and although they have the X509_cmp() function, I > prefer not to use it because it rehashes the certificate (or at least > it seems so to me) and I want to get the maximum performance I can > get., so I built my own compare function and I would like to hear your > opinion. > It calculates the certificate hash once and caches the result. Various operations in OpenSSL automatically calculate the hash: for example the standard certificate verification process. So after the first hash it simply does a memcmp() of two 20 byte buffers which should be efficient enough for anyone... 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]
