Re: VIA Padlock Hashing Engine [Was: Fix VIA Padlock RNG support ?]
BTW, my memory is vague here, is this Padlock block only able to do one-shot hashing? Yes, but a technique bypassing this limitation was proposed and proven to work (as per end of SHA1 thread mentioned earlier). Technique involved crashing of hashing instruction into non-accessible page. And that was what I wanted to pursue, but never got time to. Which is why there was no real follow-up:-( For reference, the plan was to setup intermediate buffer followed by non-accessible page upon engine setup, i.e. once, and then serialize access to it with thread synchronizing primitives. I reckon that serializing threads is OK, because system is more likely to starve for data than for hashing compute power (1Gbps NIC vs. ~2Gbps hashing rate). Strangely enough, I've got uncommitted code to add support for thread-local-storage ... :-) (It's one of the components in the work I'm doing for async-crypto.) So if you take the approach you suggesting above, it should be relatively simple to generalise it later, to avoid locking/serialisation. Setting up the intermediate buffer followed by guard page is quite expensive operation, so you don't want to do it too often. You definitely don't want to do it upon -init, and I personally would be reluctant to do it even on per-thread basis. Being library provider we don't know how short-lived threads are, and better assume the worst. Then it might be problematic to clean-up upon thread termination, not to mention that such buffer is expensive resource by itself. Basically one has to figure out what impact would serialization have and weigh it against costs caused by per-thread initialization. But as mentioned, I think serialization on per-process buffer would be appropriate in this case. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Fix VIA Padlock RNG support ?
I don't think there's any taboo or a strong opposition against the patch. It's just that Andy hasn't followed up, I sort of given up and moved to other projects and the whole thing has gone forgotten. Ok. I hope after my re-merge and testing we can get it integrated this time. BTW, my memory is vague here, is this Padlock block only able to do one-shot hashing? Yes, in all current CPU's (up to the C7), it is. There's a beatiful workaround by Michal and Andy which they have implemented in phe_sum by making the process page fault every time they need to copy in a new buffer (since the PHE is context-switch safe). I'd call it a clever hack rather than a beautiful workaround. IMO playing with SEGV handlers inside a library like libcrypto is begging to be bitten by unintended consequences. But should it prevent us from trying? I mean if we will be bitten, we'll then actually know, which is better than speculating about it:-) But what's worst that can happen? Another signal delivered asynchronously and handler causing SEGV? One can mask all maskable signals upon sigaction(SIGSEGV)... A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1741] failed in testing BN_sqr openssl in aix 5.2 of 64 bit mode
I am having problem to pass test, BN_sqr in AIX 5.2 for version openssl-0.9.7g. ... test BN_sqr Square test failed! This is in FAQ, 11. Why does the OpenSSL test suite fail in BN_sqr test [on a 64-bit platform]? 64-bit AIX is *not* supported by 0.9.7, use 0.9.8* instead. It is compiled with 64 mode in AIX 5.2. Here is the configuration: CONFIGURE_ARGS=aix-gcc -maix64 --prefix=/usr/local/ssl64 --openssldir=/usr/local It should be noted though that you can't just mix-n-match config lines and 64-bit compiler flags like that, and such attempt to mix aix-gcc and -maix64 would cause exactly same error even in 0.9.8*. Instead you'd configure explicitly for aix64-gcc. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1743] crasher due to lack of threadsafety on names_lh
diff -ru openssl-0.9.8h/crypto/cryptlib.c
openssl-0.9.8h-patched/crypto/cryptlib.c
--- openssl-0.9.8h/crypto/cryptlib.c2007-09-06 12:43:46.0 +
+++ openssl-0.9.8h-patched/crypto/cryptlib.c2008-09-11 18:21:33.0
+
@@ -166,7 +166,8 @@
ec_pre_comp,
store,
comp,
-#if CRYPTO_NUM_LOCKS != 39
+ names_lh,
+#if CRYPTO_NUM_LOCKS != 40
# error Inconsistency between crypto.h and cryptlib.c
#endif
};
diff -ru openssl-0.9.8h/crypto/crypto.h openssl-0.9.8h-patched/crypto/crypto.h
--- openssl-0.9.8h/crypto/crypto.h 2005-05-08 19:54:33.0 +
+++ openssl-0.9.8h-patched/crypto/crypto.h 2008-09-11 18:20:59.0
+
@@ -219,7 +219,8 @@
#define CRYPTO_LOCK_EC_PRE_COMP36
#define CRYPTO_LOCK_STORE 37
#define CRYPTO_LOCK_COMP 38
-#define CRYPTO_NUM_LOCKS 39
+#define CRYPTO_LOCK_NAMES_LH 39
+#define CRYPTO_NUM_LOCKS 40
#define CRYPTO_LOCK1
#define CRYPTO_UNLOCK 2
diff -ru openssl-0.9.8h/crypto/objects/o_names.c
openssl-0.9.8h-patched/crypto/objects/o_names.c
--- openssl-0.9.8h/crypto/objects/o_names.c 2005-04-05 10:29:42.0
+
+++ openssl-0.9.8h-patched/crypto/objects/o_names.c 2008-09-11
18:35:12.0 +
@@ -48,11 +48,19 @@
int OBJ_NAME_init(void)
{
- if (names_lh != NULL) return(1);
+ int ret;
+ CRYPTO_w_lock(CRYPTO_LOCK_NAMES_LH);
+ if (names_lh != NULL)
+ {
+ CRYPTO_w_unlock(CRYPTO_LOCK_NAMES_LH);
+ return(1);
+ }
MemCheck_off();
names_lh=lh_new(obj_name_hash, obj_name_cmp);
MemCheck_on();
- return(names_lh != NULL);
+ ret = (names_lh != NULL);
+ CRYPTO_w_unlock(CRYPTO_LOCK_NAMES_LH);
+ return(ret);
}
int OBJ_NAME_new_index(unsigned long (*hash_func)(const char *),
@@ -164,7 +172,9 @@
for (;;)
{
+ CRYPTO_r_lock(CRYPTO_LOCK_NAMES_LH);
ret=(OBJ_NAME *)lh_retrieve(names_lh,on);
+ CRYPTO_r_unlock(CRYPTO_LOCK_NAMES_LH);
if (ret == NULL) return(NULL);
if ((ret-alias) !alias)
{
@@ -200,7 +210,9 @@
onp-type=type;
onp-data=data;
+ CRYPTO_w_lock(CRYPTO_LOCK_NAMES_LH);
ret=(OBJ_NAME *)lh_insert(names_lh,onp);
+ CRYPTO_w_unlock(CRYPTO_LOCK_NAMES_LH);
if (ret != NULL)
{
/* free things */
@@ -217,7 +229,11 @@
}
else
{
- if (lh_error(names_lh))
+ int names_lh_error;
+ CRYPTO_r_lock(CRYPTO_LOCK_NAMES_LH);
+ names_lh_error = lh_error(names_lh);
+ CRYPTO_r_unlock(CRYPTO_LOCK_NAMES_LH);
+ if (names_lh_error)
{
/* ERROR */
return(0);
@@ -235,7 +251,9 @@
type= ~OBJ_NAME_ALIAS;
on.name=name;
on.type=type;
+ CRYPTO_w_lock(CRYPTO_LOCK_NAMES_LH);
ret=(OBJ_NAME *)lh_delete(names_lh,on);
+ CRYPTO_w_unlock(CRYPTO_LOCK_NAMES_LH);
if (ret != NULL)
{
/* free things */
@@ -278,7 +296,9 @@
d.fn=fn;
d.arg=arg;
+ CRYPTO_w_lock(CRYPTO_LOCK_NAMES_LH);
lh_doall_arg(names_lh,LHASH_DOALL_ARG_FN(do_all_fn),d);
+ CRYPTO_w_unlock(CRYPTO_LOCK_NAMES_LH);
}
struct doall_sorted
@@ -313,7 +333,9 @@
int n;
d.type=type;
+ CRYPTO_w_lock(CRYPTO_LOCK_NAMES_LH);
d.names=OPENSSL_malloc(lh_num_items(names_lh)*sizeof *d.names);
+ CRYPTO_w_unlock(CRYPTO_LOCK_NAMES_LH);
d.n=0;
OBJ_NAME_do_all(type,do_all_sorted_fn,d);
@@ -352,6 +374,9 @@
if (names_lh == NULL) return;
free_type=type;
+
+ CRYPTO_w_lock(CRYPTO_LOCK_NAMES_LH);
+
down_load=names_lh-down_load;
names_lh-down_load=0;
@@ -365,5 +390,6 @@
}
else
names_lh-down_load=down_load;
- }
+ CRYPTO_w_unlock(CRYPTO_LOCK_NAMES_LH);
+ }
OpenSSL version: openssl-0.9.8h
To reproduce more than one thread must call SSL_library_init or other
functions that modify names_lh at approximiately the same time.
The stack traces will look something like:
#0 0x0097aa52 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x001503ae in *__GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:67
#2 0x001518f8 in *__GI_abort () at ../sysdeps/generic/abort.c:88
#3 0x0017ecf9 in __libc_message (do_abort=2, fmt=0x220da0 *** glibc
detected *** %s: 0x%s ***\n) at
../sysdeps/unix/sysv/linux/libc_fatal.c:145
#4 0x00183e1a in malloc_printerr (action=2, str=0x220e0c double free
or corruption (fasttop), ptr=0xb7401fb8) at malloc.c:5525
#5 0x001857d5 in _int_realloc (av=0xb7400010, oldmem=0xb7401fb8,
bytes=0) at malloc.c:4668
#6 0x00186684
RE: [openssl.org #1741] failed in testing BN_sqr openssl in aix 5.2 of 64 bit mode
Hi Andy, Thanks so much for the response. I am now using 0.9.8g and try to configure it with aix64-gcc, such as: ./config aix64-gcc --prefix=/usr/local/ssl64 --openssldir=/usr/local/ssl64 no-shared no-asm I got configure error: Operating system: 0002423F4C00-ibm-aix Configuring for aix-gcc target already defined - aix-gcc (offending arg: aix64-gcc) Maybe there is some kind of environmental parameter I forgot to set? Could you please provide hint? Thanks again. Jack -Original Message- From: Andy Polyakov via RT [mailto:[EMAIL PROTECTED] Sent: Friday, September 12, 2008 2:44 AM To: [EMAIL PROTECTED] Cc: openssl-dev@openssl.org Subject: Re: [openssl.org #1741] failed in testing BN_sqr openssl in aix 5.2 of 64 bit mode I am having problem to pass test, BN_sqr in AIX 5.2 for version openssl-0.9.7g. ... test BN_sqr Square test failed! This is in FAQ, 11. Why does the OpenSSL test suite fail in BN_sqr test [on a 64-bit platform]? 64-bit AIX is *not* supported by 0.9.7, use 0.9.8* instead. It is compiled with 64 mode in AIX 5.2. Here is the configuration: CONFIGURE_ARGS=aix-gcc -maix64 --prefix=/usr/local/ssl64 --openssldir=/usr/local It should be noted though that you can't just mix-n-match config lines and 64-bit compiler flags like that, and such attempt to mix aix-gcc and -maix64 would cause exactly same error even in 0.9.8*. Instead you'd configure explicitly for aix64-gcc. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
EVP_Cipher with Engine
Hi all, I am trying to override the AES with my own algorithm in an engine. I have made the necessary initialized the EVP_CIPHER structure with my functions. However, while testing, I see that the EVP_EncryptFinal_ex() (and EVP_DecryptFinal_ex() )is required. But there is no hook provided in EVP_CIPHER structure for xxxFinal_ex(). Can someone please provide me more details on this? Did I miss something? Thanks in advance. Best Regards, -Sitanshu
Re: [openssl.org #1741] failed in testing BN_sqr openssl in aix 5.2 of 64 bit mode
We did manage to get 0.9.7 building on AIX 64. The necessary patches will be on the request tracker (somewhere). Peter From: Andy Polyakov via RT [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: openssl-dev@openssl.org Date: 09/12/2008 06:41 PM Subject:Re: [openssl.org #1741] failed in testing BN_sqr openssl in aix 5.2 of 64 bit mode I am having problem to pass test, BN_sqr in AIX 5.2 for version openssl-0.9.7g. ... test BN_sqr Square test failed! This is in FAQ, 11. Why does the OpenSSL test suite fail in BN_sqr test [on a 64-bit platform]? 64-bit AIX is *not* supported by 0.9.7, use 0.9.8* instead. It is compiled with 64 mode in AIX 5.2. Here is the configuration: CONFIGURE_ARGS=aix-gcc -maix64 --prefix=/usr/local/ssl64 --openssldir=/usr/local It should be noted though that you can't just mix-n-match config lines and 64-bit compiler flags like that, and such attempt to mix aix-gcc and -maix64 would cause exactly same error even in 0.9.8*. Instead you'd configure explicitly for aix64-gcc. A. __ 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: [openssl.org #1741] failed in testing BN_sqr openssl in aix 5.2 of 64 bit mode
Thanks so much for the response. I am now using 0.9.8g and try to configure it with aix64-gcc, such as: ./config aix64-gcc --prefix=/usr/local/ssl64 --openssldir=/usr/local/ssl64 no-shared no-asm I got configure error: When using config lines you're expected to call ./Configure, not ./config, i.e. './Configuire aix64-gcc ...'. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1741] failed in testing BN_sqr openssl in aix 5.2 of 64 bit mode
We did manage to get 0.9.7 building on AIX 64. The necessary patches will be on the request tracker (somewhere). Relevant question is if we want to keep maintaining 0.9.7? The answer is no and therefore I didn't want to encourage user. Of course it's possible to get 0.9.7 building on AIX64, but I didn't want him even try:-) A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: a question about CRL distribution points extension in a certificate.
On September 12, 2008 12:35:10 am JeanYiYi wrote: Dear openssl guru: I am new in openssl. I have some questions regarding to 'CRL Distribution Points extension'. I did read the RFC. but I am still confused about some details. :-(. a) a certificate has a 'CRL Distribution Points extension'. What's configured in this extension is one and only one CRL or maybe multiple CRL(s)? It is a pointer to the CRL where this certificates revocation entry will appear in the event that it is revoked. This is usually the CRL signed by the CA that issued the certificate that contains the CRLDP. The only time that you could have multiple CRLs, is if you have some sort of strange delegated revocation model in your PKI. In practice, that is very, very rarely done. b) the extension may have multiple CDP(s). Can each CDP have multiple URI(s), such as a LDAP and a HTTP? I'm not sure what you mean - a certificate may have a single instance of the CRLDP extension. Within this extension, there may be multiple URIs that contain pointers to the CRL, as you hinted, usually an LDAP or HTTP url. c) If the extension has multiple CDP(s), do those CDP(s) point to the same CRL or different CRL? Usually the same CRL, just published in different formats. d) Let's say I have a certificate which only have a DirName in its 'CRL distribution points extension'. If I reserve the setting and replace slash with comma, I can get an DN for ldap query, right? Depends on your LDAP client, but usually yes. However, this is probably a bad practice, because you would have to have all of your relying parties configured somehow to know which server to ask for that DN. It is a FAR better solution to include a LDAP URL, instead of a DirName. Have fun. -- Patrick Patterson President and Chief PKI Architect, Carillon Information Security Inc. http://www.carillon.ca __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1741] failed in testing BN_sqr openssl in aix 5.2 of 64 bit mode
Hi Andy, It worked with the recent version using Configure script as you suggested. Thanks a lot! Jack -Original Message- From: Andy Polyakov via RT [mailto:[EMAIL PROTECTED] Sent: Friday, September 12, 2008 7:17 AM To: [EMAIL PROTECTED] Cc: openssl-dev@openssl.org Subject: Re: [openssl.org #1741] failed in testing BN_sqr openssl in aix 5.2 of 64 bit mode Thanks so much for the response. I am now using 0.9.8g and try to configure it with aix64-gcc, such as: ./config aix64-gcc --prefix=/usr/local/ssl64 --openssldir=/usr/local/ssl64 no-shared no-asm I got configure error: When using config lines you're expected to call ./Configure, not ./config, i.e. './Configuire aix64-gcc ...'. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: a question about CRL distribution points extension in a certificate.
Many many thanks for Patrick. Now, I am clear about this extension. Best Regards Jean Patrick Patterson-3 wrote: On September 12, 2008 12:35:10 am JeanYiYi wrote: Dear openssl guru: I am new in openssl. I have some questions regarding to 'CRL Distribution Points extension'. I did read the RFC. but I am still confused about some details. :-(. a) a certificate has a 'CRL Distribution Points extension'. What's configured in this extension is one and only one CRL or maybe multiple CRL(s)? It is a pointer to the CRL where this certificates revocation entry will appear in the event that it is revoked. This is usually the CRL signed by the CA that issued the certificate that contains the CRLDP. The only time that you could have multiple CRLs, is if you have some sort of strange delegated revocation model in your PKI. In practice, that is very, very rarely done. b) the extension may have multiple CDP(s). Can each CDP have multiple URI(s), such as a LDAP and a HTTP? I'm not sure what you mean - a certificate may have a single instance of the CRLDP extension. Within this extension, there may be multiple URIs that contain pointers to the CRL, as you hinted, usually an LDAP or HTTP url. c) If the extension has multiple CDP(s), do those CDP(s) point to the same CRL or different CRL? Usually the same CRL, just published in different formats. d) Let's say I have a certificate which only have a DirName in its 'CRL distribution points extension'. If I reserve the setting and replace slash with comma, I can get an DN for ldap query, right? Depends on your LDAP client, but usually yes. However, this is probably a bad practice, because you would have to have all of your relying parties configured somehow to know which server to ask for that DN. It is a FAR better solution to include a LDAP URL, instead of a DirName. Have fun. -- Patrick Patterson President and Chief PKI Architect, Carillon Information Security Inc. http://www.carillon.ca __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/a-question-about-CRL-distribution-points-extension-in-a-certificate.-tp19448232p19457916.html Sent from the OpenSSL - Dev mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] openssl-0.9.8h in AIX 5.3 do not build shared libraries
2) entry point And you could use -binitfini to specify routines, as IBM satys: Optional shared object initialization and termination routines can be specified when creating the shared object. And what I meant was that there should be some code that invokes the routines specified with -binitfini and this code might have to be at entry point. But apparently AIX register them in .loader segment, which is evaluated by run-time linker itself, so my comment has turned to be irrelevant. Anyway, http://cvs.openssl.org/chngview?cn=17390 should do it. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1694] OpenSSL 0.9.8h bug: Configure has illegal -X 64, should be -X64
addressed in http://cvs.openssl.org/chngview?cn=17390 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
OpenSSL Web Server Certificate renewed
Hi! I have just installed a new (2048bit) certificate and key to the OpenSSL Project webserver. It is a wildcard certifcate for *.openssl.org catching both www.openssl.org and rt.openssl.org. Many thanks go to Steve Roylance from Globalsign for donating a 3 year wildcard SSL certificate!! Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
