x509_NAME_cmp bug?
Hi, I've recently found a rather peculiar bug in x509_cmp.c:x509_NAME_cmp . In essence the function is non-transitive on certain names, that is given 3 certificates a,b and c, it can happen (as demonstrated in the attached test) that ab, bc yet ac (where the comparisons are done using x509_NAME_cmp on the certificate name). The attached patch fixes this issue, although I think it may be too simplistic. Cheers, Shmul Index: x509_cmp.c === --- x509_cmp.c(revision 7331) +++ x509_cmp.c(revision 7332) @@ -288,7 +288,7 @@ if (!(nabit STR_TYPE_CMP) || !(nbbit STR_TYPE_CMP)) return j; -j = asn1_string_memcmp(na-value, nb-value); +j = nocase_spacenorm_cmp(na-value, nb-value); } else if (na-value-type == V_ASN1_PRINTABLESTRING) j=nocase_spacenorm_cmp(na-value, nb-value); #include stdio.h #include openssl/ssl.h #include openssl/err.h static const char* pem = -BEGIN CERTIFICATE-\n MIIEHTCCAwWgAwIBAgIQToEtioJl4AsC7j41AkblPTANBgkqhkiG9w0BAQUFADCB\n gTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G\n A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxJzAlBgNV\n BAMTHkNPTU9ETyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNjEyMDEwMDAw\n MDBaFw0yOTEyMzEyMzU5NTlaMIGBMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl\n YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P\n RE8gQ0EgTGltaXRlZDEnMCUGA1UEAxMeQ09NT0RPIENlcnRpZmljYXRpb24gQXV0\n aG9yaXR5MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0ECLi3LjkRv3\n UcEbVASY06m/weaKXTuH+7uIzg3jLz8GlvCiKVCZrts7oVewdFFxze1CkU1B/qnI\n 2GqGd0S7WWaXUF601CxwRM/aN5VCaTwwxHGzUvAhTaHYujl8HJ6jJJ3ygxaYqhZ8\n Q5sVW7euNJH+1GImGEaaP+vB+fGQV+useg2L23IwambV4EajcNxo2f8ESIl33rXp\n +2dtQem8Ob0y2WIC8bGoPW43nOIv4tOiJovGuFVDiOEjPqXSJDlqR6sA1KGzqSX+\n DT+nHbrTUcELpNqsOO9VUCQFZUaTNE8tja3G1CEZ0o7KBWFxB3NH5YoZEr0ETc5O\n nKVIrLsm9wIDAQABo4GOMIGLMB0GA1UdDgQWBBQLWOWLxkwVN6RAqTCpIb5HNlpW\n /zAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zBJBgNVHR8EQjBAMD6g\n PKA6hjhodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DZXJ0aWZpY2F0aW9u\n QXV0aG9yaXR5LmNybDANBgkqhkiG9w0BAQUFAAOCAQEAPpiem/Yb6dc5t3iuHXIY\n SdOH5EOC6z/JqvWote9VfCFSZfnVDeFs9D6Mk3ORLgLETgdxb8CPOGEIqB6BCsAv\n IC9Bi5HcSEW88cbeunZrM8gALTFGTO3nnc+IlP8zwFboJIYmuNg4ON8qa90SzMc/\n RxdMosIGlgnW2/4/PEZB31jiVg88O8EckzXZOFKs7sjsLjBOlDW0JB9LeGna8gI4\n zJVSk/BwJVmcIGfE7vmLV2H0knZ9P4SNVbfo5azV8fUZVqZa+5Acr5Pr5RzUZ5dd\n BA6+C4OmF4O5MBKgxTMVBbkN+8cFduPYSo38NBejxiEovjBFMR7HeL5YYTisO+IB\n ZQ==\n -END CERTIFICATE-\n -BEGIN CERTIFICATE-\n MIIDAjCCAmsCEDnKVIn+UCIy/jLZ2/sbhBkwDQYJKoZIhvcNAQEFBQAwgcExCzAJ\n BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xh\n c3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcy\n MTowOAYDVQQLEzEoYykgMTk5OCBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3Jp\n emVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMB4X\n DTk4MDUxODAwMDAwMFoXDTE4MDUxODIzNTk1OVowgcExCzAJBgNVBAYTAlVTMRcw\n FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMSBQdWJsaWMg\n UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEo\n YykgMTk5OCBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5\n MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMIGfMA0GCSqGSIb3DQEB\n AQUAA4GNADCBiQKBgQCq0Lq+Fi24g9TK0g+8djHKlNgdk4xWArzZbxpvUjZudVYK\n VdPfQ4chEWWKfo+9Id5rMj8bhDSVBZ1BNeuS65bdqlk/AVNtmU/t5eIqWpDBucSm\n Fc/IReumXY6cPvBkJHalzasab7bYe1FhbqZ/h8jit+U03EGI6glAvnOSPWvndQID\n AQABMA0GCSqGSIb3DQEBBQUAA4GBAIv3GhDOdlwHq4OZ3BeAbzQ5XZg+a3Is4cei\n e0ApuXiIukzFo2penm574/ICQQxmvq37rqIUzpLzojSLtLK2JPLl1eDI5WJthHvL\n vrsDi3xXyvA3qZCviu4Dvh0onNkmdqDNxJ1O8K4HFtW+r1cIatCgQkJCHvQgzKV4\n gpUmOIpH\n -END CERTIFICATE-\n -BEGIN CERTIFICATE-\n MIIEQzCCAyugAwIBAgIBATANBgkqhkiG9w0BAQUFADB/MQswCQYDVQQGEwJHQjEb\n MBkGA1UECAwSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHDAdTYWxmb3JkMRow\n GAYDVQQKDBFDb21vZG8gQ0EgTGltaXRlZDElMCMGA1UEAwwcVHJ1c3RlZCBDZXJ0\n aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTla\n MH8xCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO\n BgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSUwIwYD\n VQQDDBxUcnVzdGVkIENlcnRpZmljYXRlIFNlcnZpY2VzMIIBIjANBgkqhkiG9w0B\n AQEFAAOCAQ8AMIIBCgKCAQEA33FvNlhTWvI2VFeAxHQIIO0Yfyod5jWaHiWsnOWW\n fnJSoBVC21ndZHoa0Lh73TkVvFVIxO06AOoxEbrycXQaZ7jPM8yoMa+j49d/vzMt\n TGo87IvDktJTdyR0nAducPy9C1t2ul/y/9c3S0pgePfw+spwtOpZqqPOSC+pw7IL\n fhdyFgymBwwbOM/JYrc/oJOlh0Hyt3BAd9i+FHzjqMB6juljatEPmsbS9Is6FARW\n 1O24zG71++IsWL1/T2sr92AkWCTOJu80kTrV44HQsvAEAtdbtz6SrGsSivnkBbA7\n kUlcsutT6vifR4buv5XAwAaf0lteERv0xwQ1KdJVXOTt6wIDAQABo4HJMIHGMB0G\n A1UdDgQWBBTFe1i97doladL3WRaoszLAeydb9DAOBgNVHQ8BAf8EBAMCAQYwDwYD\n VR0TAQH/BAUwAwEB/zCBgwYDVR0fBHwwejA8oDqgOIY2aHR0cDovL2NybC5jb21v\n ZG9jYS5jb20vVHJ1c3RlZENlcnRpZmljYXRlU2VydmljZXMuY3JsMDqgOKA2hjRo\n dHRwOi8vY3JsLmNvbW9kby5uZXQvVHJ1c3RlZENlcnRpZmljYXRlU2VydmljZXMu\n Y3JsMA0GCSqGSIb3DQEBBQUAA4IBAQDIk4E7ibSvuIQSTI3S8NtwuleGFTQQuS9/\n
Re: Fix VIA Padlock RNG support ?
Hi again, On Thursday 11 September 2008 09:32:14 Geoff Thorpe wrote: On Thursday 11 September 2008 09:06:39 Harald Welte wrote: On Thu, Sep 11, 2008 at 10:22:38PM +1200, Michal Ludvig wrote: Have a look here: http://marc.info/?l=openssl-devm=109113625526391w=2 and in the corresponding thread for the discussion. FWIW even in the Linux kernel the hardware RNGs (incl. VIA PadLock) are not used directly for RNG output but instead to feed the entropy pool. I quite agree with the reasons why OpenSSL shouldn't use whatever it gets from PadLock RNG *directly* as a stream of random numbers. Unfortunately as soon as PadLock engine registers as a RNG provider OpenSSL won't do any post-processing of the random data and therefore the best bet at that time was not to use PadLock's RNG. Yes, after reviewing the discussion and documentation I tend to agree. So the best option really is to make OpenSSL use the userspace interface for the kernel random number generator, and feed that kernel RNG's entropy pool from the hardware RNG. O, right, I see know. Yes this is a bit crap. The problem IMHO is that RAND_METHOD is the wholesale replacement interface. Ie. the entire software PRNG sits behind that interface, no matter how it obtains its entropy, and using an alternative RAND_METHOD will completely bypass the software PRNG. This makes sense for the other ***_METHOD interfaces, because they're alternatives to the s/w implementations - they can be used simultaneously, but work on completely separated contexts. In the case of the PRNG, there are no separated contexts nor point to having s/w and replacement PRNGs working independently. I think the sensible thing would be to stick with the s/w PRNG implementation and have it expose an inner interface for its entropy sources and let engines plug themselves into *that*, rather than acting as alternatives/replacements for the entire PRNG. Looking at this in more detail, the current s/w PRNG implementation keeps a running 'entropy' count and when that reaches a certain threshold, it stops maintaining an entropy counter because the PRNG is considered sufficiently seeded. Each platform (roughly speaking) has its own implementation of RAND_poll() which does some canonical seeding, which may be enough to get the PRNG off the ground, or if not, the application will need to RAND_add() (or RAND_seed()) some more entropy before the PRNG is ready. In any case, this doesn't adapt so well to a model where entropy sources live as callbacks and get called by the PRNG when required. It's more a model where an entropy source should just stuff its entropy into the PRNG as soon as it gets a chance, and preferably as much of the stuff as it has handy. It can always add more later and no harm will be done, but there's no obvious way to add a hook to ask for entropy automatically. With this in mind, I'm wondering if the simplest thing to do isn't just to have the padlock (or any other) engine call RAND_add() with some entropy during the init() handler of the ENGINE itself (rather than in a RAND_METHOD). That doesn't solve the problem of adding more entropy as time goes by, but it's better than the current situation (only having a RAND_METHOD mechanism you can't use at all), and moreover it requires no interface changes, just implementation... Thoughts? Cheers, Geoff -- Un terrien, c'est un singe avec des clefs de char... __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
