[openssl-dev] common factors in (p-1) and (q-1)
Hi there, I have looked at the RSA protocol a bit and have concluded that 1) common factors in (p-1) and (q-1) are also in the factorisation of (p*q-1). 2) by factoring (p*q-1) you can come up with candidates for squares in the totient. 3) you can also come up with d mod commonfactor^2 if there is a common factor. the math is shown in my wikipedia users page math blog at: https://en.wikipedia.org/wiki/User:Endo999#The_Bad_Stuff_That_Happens_When_There_Are_Common_Factors_Between_.28P-1.29_and_.28Q-1.29 I have looked at your latest source to see if you have a possible common factor for (p-1) and (q-1) in your RSA key generation code. I have concluded, after a quick look, that you may when you are not using SAFE mode to generate the keys. When keys are generated using SAFE mode then (p-1)/2 must be a prime. As the factorisation of p-1==2*prime and there are checks to make sure that p and q are not the same, then you cannot have a common factor in p-1 and q-1 besides 2. The code in rsa_builtin_keygen() does not use safe mode when generating keys using BN_generate_prime_ex(rsa->p, bitsp, 0, NULL, NULL, cb). There are tests for these primes, but there does not seem to be an explicit check that there are no common factors in (p-1) and (q-1) besides 2 or 3. The authors of the code may well correct me here since I have just quickly looked at it. A quick check for this condition with BN_GCD(p-1,q-1)>3 in rsa_builtin_keygen() would detect any problems and avoid the possible leaking of part of the totient. I admit that it is unlikely that a large enough part of the totient would be revealed (when a truely random generator is used) to endanger the RSA pair, but I think it is a bit of housekeeping that knowledge of even small factors (besides 2 and 3) are kept out of the attackers hands. Thank You Paul Cheffers ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
> If requested, I can still provide a patch with the alternative variant of > using a > X509_V_FLAG_NO_CHECK_TIME flag if that's considered better than using a > 'special' time of (time_t)-1 with X509_VERIFY_PARAM_set_time(). Yes, please. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
> If requested, I can still provide a patch with the alternative variant of > using a > X509_V_FLAG_NO_CHECK_TIME flag if that's considered better than using a > 'special' time of (time_t)-1 with X509_VERIFY_PARAM_set_time(). Yes, please. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
On Thu, 2015-07-30 at 22:08 +, Viktor Dukhovni wrote: > > > Obviously I agree, but life's too short to argue about it and I *do* > > have a viable alternative, with a verify_cb function that just ignores > > X509_V_ERR_CERT_NOT_YET_VALID and X509_V_ERR_CERT_HAS_EXPIRED. > > You have to be careful how you do that. The final error in the > X509_STORE_CTX is the *last* error reported, and other errors > may also have been detected earlier. > > If your callback always returns the "ok" input except for the two > above errors, you're fine. But if returns "1" in additional cases, > and then in the end you look at the store error status, you may be > in trouble. That's in issue in applications that don't immediately > terminate the handshake on authentication errors, and disconnect > more gracefully at the application layer when authentication fails. Thanks for the warning. I don't believe we're looking at the store error status at all; we only care about the return value from X509_verify_cert() — either directly, or when PKCS7_verify() calls it. (There's no SSL here; only crypto. It's for verifying certificate chains and checking signatures on boot images). So I think it's fine. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
On Thu, Jul 30, 2015 at 09:55:36PM +, Woodhouse, David via RT wrote: > On Tue, 2015-07-28 at 11:00 +, Salz, Rich via RT wrote: > > It seems that the simplest and most obvious thing is to indicate that > > you don't care about the dates, which is what this patch does. > > Obviously I agree, but life's too short to argue about it and I *do* > have a viable alternative, with a verify_cb function that just ignores > X509_V_ERR_CERT_NOT_YET_VALID and X509_V_ERR_CERT_HAS_EXPIRED. You have to be careful how you do that. The final error in the X509_STORE_CTX is the *last* error reported, and other errors may also have been detected earlier. If your callback always returns the "ok" input except for the two above errors, you're fine. But if returns "1" in additional cases, and then in the end you look at the store error status, you may be in trouble. That's in issue in applications that don't immediately terminate the handshake on authentication errors, and disconnect more gracefully at the application layer when authentication fails. -- Viktor. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
On Tue, 2015-07-28 at 11:00 +, Salz, Rich via RT wrote: > It seems that the simplest and most obvious thing is to indicate that > you don't care about the dates, which is what this patch does. Obviously I agree, but life's too short to argue about it and I *do* have a viable alternative, with a verify_cb function that just ignores X509_V_ERR_CERT_NOT_YET_VALID and X509_V_ERR_CERT_HAS_EXPIRED. So (for the record) I've submitted patches to EDKII which do precisely that, and I don't depend on this patch any more. Close the RT if you wish. Having said that, if OpenSSL *does* gain this functionality then I'll happily change the EDKII code to make use of it, because I think it's the better approach. If requested, I can still provide a patch with the alternative variant of using a X509_V_FLAG_NO_CHECK_TIME flag if that's considered better than using a 'special' time of (time_t)-1 with X509_VERIFY_PARAM_set_time(). -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3972] EVP documentation implicitly recommends the use of single-DES
See https://github.com/openssl/openssl/pull/348 I was looking for something else but then saw this text about "normally supplied by a function such as EVP_des_cbc()"; we should not be misleading our users in such a fashion. -Ben ___ openssl-bugs-mod mailing list openssl-bugs-...@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3971] Bug: install_sw target broken with no-engine
Hi there! The install_sw target of current master branch [1] is broken if no-engine is provided. Same works with 1.0.2d! Steps: $ ./Configure --prefix=/tmp/test no-engine shared linux-x86_64 [...] $ make depend [...] $ make [...] $ make install_sw making install in engines... make[1]: Entering directory '/XXX/openssl/engines' installing 4758cca cp: cannot stat 'lib4758cca.so': No such file or directory Makefile:96: recipe for target 'install' failed make[1]: *** [install] Error 1 make[1]: Leaving directory '/XXX/openssl/engines' Makefile:524: recipe for target 'install_sw' failed make: *** [install_sw] Error 1 Best regards André Klitzing [1] 3df16cc2e27f75eac2c0991248b0c294e2c847b5 ___ openssl-bugs-mod mailing list openssl-bugs-...@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #2464] TLS-RSA-PSK support
> Therefore, I would to propose that the 3DES and RC4 PSK ciphersuites not be > included. > > I am not even sure that adding Camellia is a net win, ideally AES and > (soonish) > ChaCha20 are enough. > > One might similarly question the longevity of the new CBC suites, TLS 1.3 is > moving to AEAD only (the PSK AEAD ciphers will IIRC be used for session > resumption in 1.3). What Viktor said. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3970] [openssl.org Bug Report] openssl win64 "smime -encrypt" can not handle big files
On Thu Jul 30 16:10:14 2015, hotgue...@hotmail.com wrote: > This affects only openssl windows 64-bit binary, not openssl windows > 32-bit binary. > > OS: Windows 64-bit > OpenSSL Version: 1.0.2d 64 bit ( > https://slproweb.com/products/Win32OpenSSL.html ) > > How to reproduce: > using command smime -encrypt with a big file, say 350 MB > > openssl smime -encrypt -binary -in file.bin -aes-256-cbc -outform DER > -out file.bin.encrypted cer.crt > > The output file is decreased in size and, of course, broken. > Changing algorithms results exactly the same decreased output size. > Can't reproduce it here with latest 1.0.2 stable branch and Win64. Tried it on a 600MB file and no problems. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3970] [openssl.org Bug Report] openssl win64 "smime -encrypt" can not handle big files
This affects only openssl windows 64-bit binary, not openssl windows 32-bit binary. OS: Windows 64-bit OpenSSL Version: 1.0.2d 64 bit ( https://slproweb.com/products/Win32OpenSSL.html ) How to reproduce: using command smime -encrypt with a big file, say 350 MB openssl smime -encrypt -binary -in file.bin -aes-256-cbc -outform DER -out file.bin.encrypted cer.crt The output file is decreased in size and, of course, broken. Changing algorithms results exactly the same decreased output size. Regards, Suchyan. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #2464] TLS-RSA-PSK support
On Sun, Jun 21, 2015 at 07:00:55PM +, Giuseppe D'Angelo via RT wrote: > diff --git a/doc/apps/ciphers.pod b/doc/apps/ciphers.pod > index c2d40ac..7fbe3a4 100644 > --- a/doc/apps/ciphers.pod > +++ b/doc/apps/ciphers.pod > @@ -585,10 +585,22 @@ Note: these ciphers can also be used in SSL v3. > > =head2 Pre shared keying (PSK) ciphersuites > > + TLS_RSA_PSK_WITH_RC4_128_SHA RSA-PSK-RC4-SHA > + TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA RSA-PSK-3DES-EDE-CBC-SHA > + TLS_RSA_PSK_WITH_AES_128_CBC_SHA RSA-PSK-AES128-CBC-SHA > + TLS_RSA_PSK_WITH_AES_256_CBC_SHA RSA-PSK-AES256-CBC-SHA > + TLS_RSA_PSK_WITH_AES_128_CBC_SHA256 RSA-PSK-AES128-CBC-SHA256 > + TLS_RSA_PSK_WITH_AES_256_CBC_SHA384 RSA-PSK-AES256-CBC-SHA384 > + TLS_RSA_PSK_WITH_AES_128_GCM_SHA256 RSA-PSK-AES128-GCM-SHA256 > + TLS_RSA_PSK_WITH_AES_256_GCM_SHA384 RSA-PSK-AES256-GCM-SHA384 > TLS_PSK_WITH_RC4_128_SHA PSK-RC4-SHA > TLS_PSK_WITH_3DES_EDE_CBC_SHA PSK-3DES-EDE-CBC-SHA > TLS_PSK_WITH_AES_128_CBC_SHA PSK-AES128-CBC-SHA > TLS_PSK_WITH_AES_256_CBC_SHA PSK-AES256-CBC-SHA > + TLS_PSK_WITH_AES_128_CBC_SHA256 PSK-AES128-CBC-SHA256 > + TLS_PSK_WITH_AES_256_CBC_SHA384 PSK-AES256-CBC-SHA384 > + TLS_PSK_WITH_AES_128_GCM_SHA256 PSK-AES128-GCM-SHA256 > + TLS_PSK_WITH_AES_256_GCM_SHA384 PSK-AES256-GCM-SHA384 Question, should we really be adding new RC4 or new 3DES ciphersuites? Both ciphers are rather obsolete now. And we even have an RFC that "bans" RC4. While I have been known to resist potentially premature removal of *existing* RC4 support, I am certainly not a fan of RC4 and see no reason to add more RC4 to OpenSSL. And while 3DES seems to be holding up moderately well for its age, I see no reason to add more 3DES ciphersuites. Therefore, I would to propose that the 3DES and RC4 PSK ciphersuites not be included. I am not even sure that adding Camellia is a net win, ideally AES and (soonish) ChaCha20 are enough. One might similarly question the longevity of the new CBC suites, TLS 1.3 is moving to AEAD only (the PSK AEAD ciphers will IIRC be used for session resumption in 1.3). How many of the new ciphersuites are used/needed in practice? Which are MTI for PSK? I think that when adding ciphersuites, we have the opportunity/responsibility to exercise good judgement and enable only the essential ones, and try to keep a lid on needless ciphersuite proliferation. -- Viktor. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #2299] [PATCH] Null cipher support PSK/PKI for 1.0.0
The official NULL PSK ciphersuites have now been added to the master branch. Closing ticket. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #2464] [PATCH] Experimental TLS-RSA-PSK support for OpenSSL
On Tue Jun 23 20:09:36 2015, giuseppe.dang...@kdab.com wrote: > Il 22/06/2015 23:14, Stephen Henson via RT ha scritto: > >> > > > > I'm currently looking at the OpenSSL PSK code. I'll look into > > incopoorating > > your changes (in a modified form) as part of that so there is no need > > to keep > > it up to date with the changing master branch. > > Great, thank you! I've just pushed the update PSK code to the master branch. Let me know of any problems. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3969] [PATCH] Add OPENSSL_SYS_UEFI
>From 22bb269a219147c9bba0debf652458796850cadc Mon Sep 17 00:00:00 2001
From: David Woodhouse
Date: Mon, 27 Jul 2015 11:05:14 +0100
Subject: [PATCH] Add OPENSSL_SYS_UEFI
This provides support for building in the EDK2 reference implementation
of UEFI. Most UEFI firmware in existence uses OpenSSL for implementing
the core cryptographic functionality needed for Secure Boot.
This has always previously been handled with external patches to OpenSSL
but we are now making a concerted effort to eliminate those.
In this mode, we don't actually use the OpenSSL makefiles; we process
the MINFO file generated by 'make files' and incorporate it into the
EDK2 build system.
Signed-off-by: David Woodhouse
---
Configurations/10-main.conf | 7 +++
crypto/rand/rand_egd.c | 2 +-
crypto/rand/rand_unix.c | 4 ++--
e_os.h | 2 +-
include/openssl/e_os2.h | 5 +
5 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/Configurations/10-main.conf b/Configurations/10-main.conf
index b5d32b6..2dcc82d 100644
--- a/Configurations/10-main.conf
+++ b/Configurations/10-main.conf
@@ -1207,6 +1207,13 @@
shared_extension => ".dll.a",
},
+ UEFI
+"UEFI" => {
+cc => "cc",
+cflags => "-DL_ENDIAN -O",
+sys_id => "UEFI",
+},
+
UWIN
"UWIN" => {
cc => "cc",
diff --git a/crypto/rand/rand_egd.c b/crypto/rand/rand_egd.c
index 44ed4bb..d062dd6 100644
--- a/crypto/rand/rand_egd.c
+++ b/crypto/rand/rand_egd.c
@@ -95,7 +95,7 @@
* RAND_egd() is a wrapper for RAND_egd_bytes() with numbytes=255.
*/
-#if defined(OPENSSL_SYS_WIN32) || defined(OPENSSL_SYS_VMS) ||
defined(OPENSSL_SYS_MSDOS) || defined(OPENSSL_SYS_VXWORKS) ||
defined(OPENSSL_SYS_NETWARE) || defined(OPENSSL_SYS_VOS)
+#if defined(OPENSSL_SYS_WIN32) || defined(OPENSSL_SYS_VMS) ||
defined(OPENSSL_SYS_MSDOS) || defined(OPENSSL_SYS_VXWORKS) ||
defined(OPENSSL_SYS_NETWARE) || defined(OPENSSL_SYS_VOS) ||
defined(OPENSSL_SYS_UEFI)
int RAND_query_egd_bytes(const char *path, unsigned char *buf, int bytes)
{
return (-1);
diff --git a/crypto/rand/rand_unix.c b/crypto/rand/rand_unix.c
index 72f8617..bb70a5b 100644
--- a/crypto/rand/rand_unix.c
+++ b/crypto/rand/rand_unix.c
@@ -116,7 +116,7 @@
#include
#include "rand_lcl.h"
-#if !(defined(OPENSSL_SYS_WINDOWS) || defined(OPENSSL_SYS_WIN32) ||
defined(OPENSSL_SYS_VMS) || defined(OPENSSL_SYS_OS2) ||
defined(OPENSSL_SYS_VXWORKS) || defined(OPENSSL_SYS_NETWARE))
+#if !(defined(OPENSSL_SYS_WINDOWS) || defined(OPENSSL_SYS_WIN32) ||
defined(OPENSSL_SYS_VMS) || defined(OPENSSL_SYS_OS2) ||
defined(OPENSSL_SYS_VXWORKS) || defined(OPENSSL_SYS_NETWARE) ||
defined(OPENSSL_SYS_UEFI))
# include
# include
@@ -419,7 +419,7 @@ int RAND_poll(void)
* defined(OPENSSL_SYS_VXWORKS) ||
* defined(OPENSSL_SYS_NETWARE)) */
-#if defined(OPENSSL_SYS_VXWORKS)
+#if defined(OPENSSL_SYS_VXWORKS) || defined(OPENSSL_SYS_UEFI)
int RAND_poll(void)
{
return 0;
diff --git a/e_os.h b/e_os.h
index 4c1b4aa..b3a3338 100644
--- a/e_os.h
+++ b/e_os.h
@@ -112,7 +112,7 @@ extern "C" {
# define MSDOS
# endif
-# if defined(MSDOS) && !defined(GETPID_IS_MEANINGLESS)
+# if (defined(MSDOS) || defined(OPENSSL_SYS_UEFI)) &&
!defined(GETPID_IS_MEANINGLESS)
# define GETPID_IS_MEANINGLESS
# endif
diff --git a/include/openssl/e_os2.h b/include/openssl/e_os2.h
index 177b098..6327a64 100644
--- a/include/openssl/e_os2.h
+++ b/include/openssl/e_os2.h
@@ -76,6 +76,11 @@ extern "C" {
# define OPENSSL_SYS_NETWARE
# endif
+/* UEFI -- */
+# if defined(OPENSSL_SYS_UEFI)
+# undef OPENSSL_SYS_UNIX
+# endif
+
/* - Microsoft operating systems -- */
/*
--
2.4.3
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3968] HOSENT: redefinition error
Hi, I'm trying to use the openssl library along with other libraries but the HOSENT in bio.h conflicts with winsock.h HOSENT, do you guys have a solution for this, or can I request that you change the name of HOSENT to avoid the redefinition error? Thanks in advance. Here is the error:openssl/bio.h(729) : error C2371: 'HOSTENT' : redefinition; different basic types winsock.h(1029) : see declaration of 'HOSTENT' ___ openssl-bugs-mod mailing list openssl-bugs-...@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3628] NDEBUG macro and redundant strings
On Mon, 2015-07-27 at 12:32 +0100, David Woodhouse wrote:
> Rather than littering the source with #ifdef NDEBUG, I had considered
> instead introducing OPENSSL_FILE and OPENSSL_LINE.
Here's a patch which implements that.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
From d84d7a5fcbd007770c7f157d8de426cd91a0708e Mon Sep 17 00:00:00 2001
From: David Woodhouse
Date: Thu, 30 Jul 2015 11:45:25 +0100
Subject: [PATCH] RT3628: Allow filenames to be eliminated from compiled
library
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Although I explicitly don't care about the tinfoil-hat reason given in
the initial opening of RT#3628, that "paths usually contain private
information", there *are* situations where it's useful to eliminate the
filenames from the compiled binary.
The two reasons we do care about in the context of firmware such as EDK2
are that it allows for a smaller footprint, and it is also a necessary
component of a binary-reproducible build.
To that end, introduce OPENSSL_FILE and OPENSSL_LINE macros, defining
them to __FILE__ and __LINE__ respectively in the normal case, but to
"" and 0 when OPENSSL_NO_FILENAMES is set.
This is mostly a naïve invocation of
$ sed 's/__\([FL]I[NL]E\)__/OPENSSL_\1/g' -i `git grep -l __LINE__`
but with a few instances change to just print the function name instead
(although those probably need to die anyway) and test cases left untouched.
---
crypto/engine/eng_int.h | 4 +-
crypto/lock.c| 6 +--
crypto/opensslconf.h.in | 10
demos/engines/cluster_labs/hw_cluster_labs_err.h | 2 +-
demos/engines/ibmca/hw_ibmca_err.h | 2 +-
demos/engines/rsaref/rsaref_err.h| 2 +-
demos/engines/zencod/hw_zencod_err.h | 2 +-
doc/crypto/threads.pod | 10 ++--
engines/ccgost/e_gost_err.h | 2 +-
engines/e_4758cca_err.h | 2 +-
engines/e_aep_err.h | 2 +-
engines/e_atalla_err.h | 2 +-
engines/e_capi_err.h | 2 +-
engines/e_chil_err.h | 2 +-
engines/e_cswift_err.h | 2 +-
engines/e_gmp_err.h | 2 +-
engines/e_nuron_err.h| 2 +-
engines/e_sureware_err.h | 2 +-
engines/e_ubsec_err.h| 2 +-
include/openssl/crypto.h | 28 +-
include/openssl/err.h| 66
ssl/d1_both.c| 2 +-
ssl/record/ssl3_record.c | 4 +-
util/mkerr.pl| 4 +-
24 files changed, 86 insertions(+), 78 deletions(-)
diff --git a/crypto/engine/eng_int.h b/crypto/engine/eng_int.h
index 42674e1..340b219 100644
--- a/crypto/engine/eng_int.h
+++ b/crypto/engine/eng_int.h
@@ -88,7 +88,7 @@ extern "C" {
(unsigned int)(e), (isfunct ? "funct" : "struct"), \
((isfunct) ? ((e)->funct_ref - (diff)) : ((e)->struct_ref - (diff))), \
((isfunct) ? (e)->funct_ref : (e)->struct_ref), \
-(__FILE__), (__LINE__));
+(OPENSSL_FILE), (OPENSSL_LINE));
# else
@@ -136,7 +136,7 @@ ENGINE *engine_table_select(ENGINE_TABLE **table, int nid);
# else
ENGINE *engine_table_select_tmp(ENGINE_TABLE **table, int nid, const char *f,
int l);
-# define engine_table_select(t,n) engine_table_select_tmp(t,n,__FILE__,__LINE__)
+# define engine_table_select(t,n) engine_table_select_tmp(t,n,OPENSSL_FILE,OPENSSL_LINE)
# endif
typedef void (engine_table_doall_cb) (int nid, STACK_OF(ENGINE) *sk,
ENGINE *def, void *arg);
diff --git a/crypto/lock.c b/crypto/lock.c
index d7d672d..98dc79a 100644
--- a/crypto/lock.c
+++ b/crypto/lock.c
@@ -257,7 +257,7 @@ int CRYPTO_get_new_dynlockid(void)
return (0);
}
pointer->references = 1;
-pointer->data = dynlock_create_callback(__FILE__, __LINE__);
+pointer->data = dynlock_create_callback(OPENSSL_FILE, OPENSSL_LINE);
if (pointer->data == NULL) {
OPENSSL_free(pointer);
CRYPTOerr(CRYPTO_F_CRYPTO_GET_NEW_DYNLOCKID, ERR_R_MALLOC_FAILURE);
@@ -283,7 +283,7 @@ int CRYPTO_get_new_dynlockid(void)
CRYPTO_w_unlock(CRYPTO_LOCK_DYNLOCK);
if (i == -1) {
-dynlock_destroy_callback(pointer->data, __FILE__, __LINE__);
+dynlock_destroy_callback(pointer->data, OPENSSL_FILE, OPENSSL_LINE);
OPENSSL_free(pointer);
} else
i += 1; /* to avoid 0 */
@@ -322,7 +322,7 @@ void CRYPTO_destroy_dynlockid(int
Re: [openssl-dev] TLS session ticket extension problem when using the ssl23_client_hello method
On 28/07/15 15:09, Jouni Malinen wrote:
> The remaining issue for EAP-FAST server is in the
> SSL_set_session_secret_cb() callback not having access to the correct
> server_random through SSL_get_server_random(). In earlier OpenSSL
> versions, I could fetch this from ssl->s3->server_random. However,
> SSL_get_server_random() seems to return some bogus data at this point in
> the sequence (_before_ the ServerHello has actually been written). The
> correct server_random becomes available later, but that's too late to be
> able to derive the correct master_secret in the session secret
> callback..
Is this still a problem? From looking at the code it seems to me that
the server random is set prior to calling the callback:
/*
* Check if we want to use external pre-shared secret for this handshake
* for not reused session only. We need to generate server_random before
* calling tls_session_secret_cb in order to allow SessionTicket
* processing to use it in key derivation.
*/
{
unsigned char *pos;
pos = s->s3->server_random;
if (ssl_fill_hello_random(s, 1, pos, SSL3_RANDOM_SIZE) <= 0) {
goto f_err;
}
}
if (!s->hit && s->version >= TLS1_VERSION && s->tls_session_secret_cb) {
SSL_CIPHER *pref_cipher = NULL;
s->session->master_key_length = sizeof(s->session->master_key);
if (s->tls_session_secret_cb(s, s->session->master_key,
&s->session->master_key_length,
ciphers,
&pref_cipher,
s->tls_session_secret_cb_arg)) {
Checking the commit logs this seems to have been put in by this commit
responding to one of your tickets!
commit 12bf56c017a34bd0d5fc6d817564ae49d0a9e861
Author: Dr. Stephen Henson
AuthorDate: Sat Nov 15 17:18:12 2008 +
Commit: Dr. Stephen Henson
CommitDate: Sat Nov 15 17:18:12 2008 +
PR: 1574
Submitted by: Jouni Malinen
Approved by: st...@openssl.org
Ticket override support for EAP-FAST.
You seem to imply that you can get the server_random through
ssl->s3->server_random but not through SSL_get_server_random(). Looking
at the code I can't see an obvious reason why that would be the case.
Here is SSL_get_server_random():
size_t SSL_get_server_random(const SSL *ssl, unsigned char *out, size_t
outlen)
{
if (outlen == 0)
return sizeof(ssl->s3->server_random);
if (outlen > sizeof(ssl->s3->server_random))
outlen = sizeof(ssl->s3->server_random);
memcpy(out, ssl->s3->server_random, outlen);
return outlen;
}
Matt
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
