- Feb 21, 2018
-
-
EasySec authored
Reviewed-by:
Tim Hudson <tjh@openssl.org> Reviewed-by:
Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2083)
-
Pavel Kopyl authored
The memory pointed to by the 'push' is freed by the X509_NAME_ENTRY_free() in do_body(). The second time it is referenced to (indirectly) in certify_cert:X509_REQ_free(). Reviewed-by:
Rich Salz <rsalz@openssl.org> Reviewed-by:
-
Pavel Kopyl authored
X509v3_add_ext: free 'sk' if the memory pointed to by it was malloc-ed inside this function. X509V3_EXT_add_nconf_sk: return an error if X509v3_add_ext() fails. This prevents use of a freed memory in do_body:sk_X509_EXTENSION_num(). Reviewed-by:
-
Samuel Weiser authored
Replaced variable-time GCD with consttime inversion to avoid side-channel attacks on RSA key generation Reviewed-by:
Kurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/5161)
-
Matt Caswell authored
This could in theory result in an overread - but due to the over allocation of the underlying buffer does not represent a security issue. Thanks to Fedor Indutny for reporting this issue. Reviewed-by:
Ben Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/5414)
-
Matt Caswell authored
[extended tests] Reviewed-by:
-
Matt Caswell authored
We can't add NULL data into a hash Reviewed-by:
-
Matt Caswell authored
When the proxy re-encrypted a TLSv1.3 record it was adding a spurious byte onto the end. This commit removes that. The "extra" byte was intended to be the inner content type of the record. However, TLSProxy was actually adding the original encrypted data into the record (which already has the inner content type in it) and then adding the spurious additional content type byte on the end (and adjusting the record length accordingly). It is interesting to look at why this didn't cause a failure: The receiving peer first attempts to decrypt the data. Because this is TLSProxy we always use a GCM based ciphersuite with a 16 byte tag. When we decrypt this it actually gets diverted to the ossltest engine. All this does is go through the motions of encrypting/decrypting but just passes back the original data. Crucially it will never fail because of a bad tag! The receiving party thinks the spurious additional byte is part of the tag and the ossltest engine ignores it. This means the data that gets passed back to the record layer still has an additional spurious byte on it - but because the 16 byte tag has been removed, this is actually the first byte of the original tag. Again because we are using ossltest engine we aren't actually creating "real" tags - we only ever emit 16, 0 bytes for the tag. So the spurious additional byte always has the value 0. The TLSv1.3 spec says that records can have additional 0 bytes on the end of them - this is "padding". So the record layer interprets this 0 byte as padding and strips it off to end up with the originally transmitted record data - which it can now process successfully. Reviewed-by:
Bernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/5370)
-
Richard Levitte authored
The internals test programs access header files that aren't guarded by the public __DECC_INCLUDE_PROLOGUE.H and __DECC_INCLUDE_EPILOGUE.H files, and therefore have no idea what the naming convention is. Therefore, we need to specify that explicitely in the internals test programs, since they aren't built with the same naming convention as the library they belong with. Reviewed-by:
-
Andy Polyakov authored
So far check for availability of Win32::API served as implicit check for $^O being MSWin32. Reportedly it's not safe assumption, and check for MSWin32 has to be explicit. Reviewed-by:
-
Andy Polyakov authored
Reviewed-by:
Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/5408)
-
Andy Polyakov authored
Currently it's limited to 64-bit platforms only as minimum radix expected in assembly is 2^51. Reviewed-by:
-
Andy Polyakov authored
Reviewed-by:
-
Andy Polyakov authored
3 least significant bits of the input scalar are explicitly cleared, hence swap variable has fixed value [of zero] upon exit from the loop. Reviewed-by:
-
- Feb 20, 2018
-
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
The original curve448 code was templated to allow for a 25519 implementation. We've just imported the 448 stuff - but a remnant of the original templated approach remained. This just simplifies that. Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
We removed various platform specific optimisation files in an earlier commit. The vector code was related to that and therefore is no longer required. It may be resurrected at a later point if we reintroduce the opimtisations. Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Instead we should use the standard OpenSSL constant time routines. Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
We already have a constant_time_select() function so, to avoid confusion/clashing we shouldn't have a second one. Reviewed-by:
-
Matt Caswell authored
Remove all architecture specific files except for the reference arch_32 version. These files provide archicture specific performance optimisation. However they have not been integrated yet. In order to avoid review issues they are removed for now. They may be reintroduced at a later time. Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
