HMAC_copy() or HMAC_dup() function ?
I have an application that pre-initialises a HMAC with some computed data, then at high throughput it is copied for different requests into a unique context and used from there. The main reasons were to save calling HMAC_Init() and HMAC_update() with the same data before I could start a verify. Also a side effect that it maybe more secure than storing the exact key in the process address space, since there is no need for it anymore if I prime a HMAC context and the data within the HMAC is marginally safer. Sometime ago I did evaluate the HMAC context structure in OpenSSL and a public domain MD5 impl and concluded it was just storage (i.e. it has no pointers to allocated storage that needed to be duplicated) so I was using a simple: memcpy(hmac_context_this_packet, hmac_const_global_initilized, sizeof(foo)); but this is a big assumption I don't really want to make. I was thinking it would make sense to add this to the API, to be able to initialize one HMAC structure from another so that both have their own lifecycles, rather than presuming I can memcpy() it. Does this make any sense to add this into the HMAC APIs, even if thats still a memcpy() inside OpenSSL this then obligates OpenSSL to provide that in the future. Would a patch be accepted ? -- Darryl L. Miles __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1346] Re: SSL_accept concurrency in 0.9.7j and 0.9.8b
On Fri, Jun 09, 2006 at 07:02:36PM +0200, Kurt Roeckx wrote: On Fri, Jun 09, 2006 at 12:58:56PM +0200, Howard Chu via RT wrote: Howard Chu wrote: I'm seeing a lot of bad record mac errors when receiving a lot of connection requests at once. It sounds the same as this email http://www.redhat.com/archives/rhl-list/2005-May/msg01506.html which unfortunately was never replied to. Surrounding the SSL_accept call with its own mutex seems to resolve the problem. Is that supposed to be necessary? Given the lack of response here, we're tracking this now as http://www.openldap.org/its/index.cgi/Software%20Bugs?id=4583 The same problem occurs with 0.9.8b. There are various bugs open in Debian that might also be related to this: http://bugs.debian.org/198746 http://bugs.debian.org/212410 Please try verifying the bugs using the latest snapshot of your preferred version branch (0.9.7, 0.9.8, or 0.9.9-dev) from ftp://ftp.openssl.org/source and make sure that the affected multi-threaded applications do provide a locking callback by calling CRYPTO_set_locking_callback(). There are some recent changes in OpenSSL that may help avoid the bugs you are observing. Applications are also expected to provide a thread ID callback by calling CRYPTO_set_id_callback(), although the failure to do so should not be a problem on Linux where different threads run with different PIDs, since OpenSSL uses the PID as a default for the thread ID. (OpenSSL requires the thread ID that is an unsigned long. Not all systems may provide this, but in practice, you can work around this problem by casting a pointer of any per-thread object in shared memory space into an unsigned long; e.g., do foo=malloc(1); and then use (unsigned long)(void *)foo as the thread ID. You might want to add assert(sizeof(void *) = sizeof(long)); to the program if you use this approach.) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1346] Re: SSL_accept concurrency in 0.9.7j and 0.9.8b
Current snapshots use a more thorough locking approach that takes into account inconsistent cache views on multi-processor or multi-core systems (where consistency can be reached by obtaining locks). The application has to call CRYPTO_set_id_callback() for OpenSSL to work properly. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] STARTTLS support in s_client for IMAP
Jan Kundrát wrote: Hi folks, my attempt to implement IMAP4rev1's STARTTLS command in s_client. Tested against openssl-0.9.7i. Hi folks, I've found another patch [1] on the net and it seems to be nicer and adds FTP support as well. Is it possible to apply it? [1] http://outflux.net/software/patches/openssl-starttls.patch Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: rfc 4279 support - what's the plan?
On Mon, 2006-06-19 at 10:26 -0700, ext Scott Kelly wrote: Last August some folks from Nokia posted a patch for 0.9.8a that implements a portion of tls-psk. I applied this patch, and also extended it to allow preshared keys with dtls. I was hoping to see rfc4279 support in 0.9.8b, but it's not there. What's the plan for preshared key support in openssl (or is there no plan as of yet)? As the person who wrote the first PSK patches, I am also interested in those plans. At least the CVS sources (http://cvs.openssl.org/dir? d=openssl/ssl) seem to have the PSK code, so maybe we can assume that the support will be in the next release, 0.9.9. But because I am not an OpenSSL developer I can not say this for sure, but let's at least hope so. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] DTLS version + 2 bytes length rsa key exchange
hi,
this little patch to correct version problem and add the 2 bytes
before rsa key exchange...
I am searching how I can add replay in this implementation, if someone
have an idea I will thank him and I will follow advices to create the
patch (I don't know well openssl implem)
regards,
--
++
+ Authesserre Samuel+
+ 12 rue de la défense passive+
+ 14000 CAEN +
+ FRANCE +
+ 06-27-28-13-32 +
+ [EMAIL PROTECTED] +
++
diff -ru openssl-0.9.8b/include/openssl/dtls1.h openssl-0.9.8b_patched/include/openssl/dtls1.h
--- openssl-0.9.8b/include/openssl/dtls1.h 2005-05-31 00:34:27.0 +0200
+++ openssl-0.9.8b_patched/include/openssl/dtls1.h 2006-06-16 08:53:48.033483744 +0200
@@ -67,9 +67,9 @@
extern C {
#endif
-#define DTLS1_VERSION 0x0100
-#define DTLS1_VERSION_MAJOR 0x01
-#define DTLS1_VERSION_MINOR 0x00
+#define DTLS1_VERSION 0xFEFF
+#define DTLS1_VERSION_MAJOR 0xFE
+#define DTLS1_VERSION_MINOR 0xFF
#define DTLS1_AD_MISSING_HANDSHAKE_MESSAGE110
diff -ru openssl-0.9.8b/ssl/d1_clnt.c openssl-0.9.8b_patched/ssl/d1_clnt.c
--- openssl-0.9.8b/ssl/d1_clnt.c 2005-12-05 18:32:19.0 +0100
+++ openssl-0.9.8b_patched/ssl/d1_clnt.c 2006-06-16 08:55:27.044431792 +0200
@@ -733,7 +733,7 @@
q=p;
/* Fix buf for TLS and beyond */
- if (s-version SSL3_VERSION)
+
p+=2;
n=RSA_public_encrypt(sizeof tmp_buf,
tmp_buf,p,rsa,RSA_PKCS1_PADDING);
@@ -748,12 +748,9 @@
}
/* Fix buf for TLS and beyond */
- if (s-version SSL3_VERSION)
-{
-s2n(n,q);
-n+=2;
-}
-
+ s2n(n,q);
+ n+=2;
+
s-session-master_key_length=
s-method-ssl3_enc-generate_master_secret(s,
s-session-master_key,
Seulement dans openssl-0.9.8b_patched/ssl: d1_clnt.c~
diff -ru openssl-0.9.8b/ssl/d1_pkt.c openssl-0.9.8b_patched/ssl/d1_pkt.c
--- openssl-0.9.8b/ssl/d1_pkt.c 2006-02-08 20:16:32.0 +0100
+++ openssl-0.9.8b_patched/ssl/d1_pkt.c 2006-06-16 08:55:55.442114688 +0200
@@ -486,9 +486,9 @@
SSL3_RECORD *rr;
SSL_SESSION *sess;
unsigned char *p;
- short version;
+ unsigned short version;
DTLS1_BITMAP *bitmap;
-unsigned int is_next_epoch;
+ unsigned int is_next_epoch;
rr= (s-s3-rrec);
sess=s-session;
Seulement dans openssl-0.9.8b_patched/ssl: d1_pkt.c~
diff -ru openssl-0.9.8b/ssl/dtls1.h openssl-0.9.8b_patched/ssl/dtls1.h
--- openssl-0.9.8b/ssl/dtls1.h 2005-05-31 00:34:27.0 +0200
+++ openssl-0.9.8b_patched/ssl/dtls1.h 2006-06-16 08:53:48.033483744 +0200
@@ -67,9 +67,9 @@
extern C {
#endif
-#define DTLS1_VERSION 0x0100
-#define DTLS1_VERSION_MAJOR 0x01
-#define DTLS1_VERSION_MINOR 0x00
+#define DTLS1_VERSION 0xFEFF
+#define DTLS1_VERSION_MAJOR 0xFE
+#define DTLS1_VERSION_MINOR 0xFF
#define DTLS1_AD_MISSING_HANDSHAKE_MESSAGE110
Seulement dans openssl-0.9.8b_patched/ssl: dtls1.h~
[openssl.org #843] EBCDIC patches for 0.9.7c
I've updated this patch for compatibility with openssl-0.9.7j. These requests for EBCDIC support do, indeed, occur regularly and I too urge that these patches be incorporated into the main source. These were tested on a z/OS 1.5 release for a custom web server as well as the Novell Remote Loader service (port 8090). Thanks, -Jeremy Grieshop jeremy__at__omnibond__dot__com [EMAIL PROTECTED] - Thu Mar 18 12:08:16 2004]: Because Evan Jennings asked in openssl-users for EBCDIC patches for the 0.9.7 branch, i post here my collection of EBCDIC patches for 0.9.7c. This collection comprises also the (slightly extended) patches from Howard Chu posted here some months ago. Because requests for the EBCDIC patches occur regularly, i would appreciate their incorporation into the official OpenSSL sources. We tested them in conjunction with an Apache web server and FTP/Telnet client and server. Ciao, Richard __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1346] Re: SSL_accept concurrency in 0.9.7j and 0.9.8b
On Tue, Jun 20, 2006 at 02:06:25PM +0200, Bodo Moeller wrote: On Fri, Jun 09, 2006 at 07:02:36PM +0200, Kurt Roeckx wrote: On Fri, Jun 09, 2006 at 12:58:56PM +0200, Howard Chu via RT wrote: Given the lack of response here, we're tracking this now as http://www.openldap.org/its/index.cgi/Software%20Bugs?id=4583 The same problem occurs with 0.9.8b. There are various bugs open in Debian that might also be related to this: http://bugs.debian.org/198746 http://bugs.debian.org/212410 Please try verifying the bugs using the latest snapshot of your preferred version branch (0.9.7, 0.9.8, or 0.9.9-dev) from ftp://ftp.openssl.org/source and make sure that the affected multi-threaded applications do provide a locking callback by calling CRYPTO_set_locking_callback(). There are some recent changes in OpenSSL that may help avoid the bugs you are observing. That is alteast good to know. Applications are also expected to provide a thread ID callback by calling CRYPTO_set_id_callback(), although the failure to do so should not be a problem on Linux where different threads run with different PIDs, since OpenSSL uses the PID as a default for the thread ID. I believe this is the only LinuxThreads implementation that you're talking about. Since kernel 2.6 there is also support for the Native POSIX Thread Library (NPTL). Afaik, that doesn't change PID for each process anymore. I guess in that case one must use pthread_self(), which returns a pthread_t. On my system both a long and pthread_t appear to be a unsigned long int, so I guess it should work in most cases without problems. Anyway, this is all explained in the documentation anyway, and I knew about it. I've also mentioned that in one of the bug reports. (OpenSSL requires the thread ID that is an unsigned long. Not all systems may provide this, but in practice, you can work around this problem by casting a pointer of any per-thread object in shared memory space into an unsigned long; e.g., do foo=malloc(1); and then use (unsigned long)(void *)foo as the thread ID. You might want to add assert(sizeof(void *) = sizeof(long)); to the program if you use this approach.) This would a problem on platforms like windows x64 which are LLP64, where a long is still 32 bit and a pointer is 64 bit. Fortuantly, we don't need that on windows. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: rfc 4279 support - what's the plan?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Scott Kelly Sent: Monday, June 19, 2006 10:26 AM To: openssl-dev@openssl.org Subject: rfc 4279 support - what's the plan? Last August some folks from Nokia posted a patch for 0.9.8a that implements a portion of tls-psk. I applied this patch, and also extended it to allow preshared keys with dtls. I was hoping to see rfc4279 support in 0.9.8b, but it's not there. What's the plan for preshared key support in openssl (or is there no plan as of yet)? Gee Scott, we thought you volunteered to write it! Ted __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
