[openssl-dev] [openssl.org #3181] [PATCH] OCB
OCB support has been merged in. Closing my own ticket. Matt ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3623] faulting module ssleay32.dll, version 0.0.0.0, fault address 0x00010c8b.
Hi, The exact error which i faced in Event log are given below. Faulting application name: aeagent.exe, version:0.0.0.0, time stamp:0x53e1f20f Faulting module name: SSLEAY32.dll, version:0.0.0.0, time stamp: 0x405a2628 Exception code: 0xc005 Fault offset: 0x00010c8b Faulting process id : 0x1bc0 What is that mean?? I googled with this error, firefox faced the same error and they gave workaround was replace the latest version of dll. I did the same but no use.. Please tell what i want to do?? On 5 December 2014 at 22:01, Andy Polyakov via RT r...@openssl.org wrote: Am using openssl for my monitoring tools and i have facing *faulting module ssleay32.dll, version 0.0.0.0, fault address 0x00010c8b *in application log and its all type of windows OS May i know that it is known issue or new issue,if it is known issue please provide issue id. Kindly help ASP... Note : am using latest openssl (openssl-1.0.1j.tar.gz https://www.openssl.org/source/openssl-1.0.1j.tar.gz) Specific fault address does not provide sufficient information by itself and it's impossible to tell anything from it. You refer to source code, and if you compile it yourself, you'll have symbol information as .pdb files that you can use to identify failing function. You should be able to use it together with crash dump information in debugger to identify failing function and collect so called stack back-trace. Only then it would be possible to make some assessment about nature of the problem. [As for crash dump, I don't think meaningful crash dump generation is enabled by default nowadays, i.e. you would have to configure it, google should be your friend]. -- Thanks Regards vijendra boopathy.k ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3624] Unify SSL_CONF_* interface to be SSL_CONF_CTX_*, with patch against [master/33d5ba8]
Does:
- Fixes a typo in s_client.pod (2x in the).
- Changes .pod to reflect reality: it is SSL_CONF_CTX_finish(),
not SSL_CONF_finish().
- While here it seems best to change the remaining SSL_CONF_cmd(),
SSL_CONF_cmd_argv() and SSL_CONF_cmd_value_type() to have
a SSL_CONF_CTX_ prefix, too.
PODs renamed accordingly.
- Adjusts all places where git grep -i matches against the former.
It compiles etc.
It's ugly to have SSL_CONF_CTX_ as a prefix, but isn't it better
to have a unique interface instead of special-treating the _cmd*
stuff? Would be really nice like that.
-
--steffen
diff --git a/apps/s_cb.c b/apps/s_cb.c
index f3892f9..7b111fd 100644
--- a/apps/s_cb.c
+++ b/apps/s_cb.c
@@ -1553,7 +1553,7 @@ int args_ssl(char ***pargs, int *pargc, SSL_CONF_CTX *cctx,
int rv;
/* Attempt to run SSL configuration command */
- rv = SSL_CONF_cmd_argv(cctx, pargc, pargs);
+ rv = SSL_CONF_CTX_cmd_argv(cctx, pargc, pargs);
/* If parameter not recognised just return */
if (rv == 0)
return 0;
@@ -1613,7 +1613,7 @@ int args_ssl_call(SSL_CTX *ctx, BIO *err, SSL_CONF_CTX *cctx,
return 0;
}
#endif
- if (SSL_CONF_cmd(cctx, param, value) = 0)
+ if (SSL_CONF_CTX_cmd(cctx, param, value) = 0)
{
BIO_printf(err, Error with command: \%s %s\\n,
param, value ? value : );
@@ -1627,7 +1627,7 @@ int args_ssl_call(SSL_CTX *ctx, BIO *err, SSL_CONF_CTX *cctx,
*/
if (!no_ecdhe)
{
- if (SSL_CONF_cmd(cctx, -named_curve, P-256) = 0)
+ if (SSL_CONF_CTX_cmd(cctx, -named_curve, P-256) = 0)
{
BIO_puts(err, Error setting EC curve\n);
ERR_print_errors(err);
@@ -1637,7 +1637,7 @@ int args_ssl_call(SSL_CTX *ctx, BIO *err, SSL_CONF_CTX *cctx,
#ifndef OPENSSL_NO_JPAKE
if (!no_jpake)
{
- if (SSL_CONF_cmd(cctx, -cipher, PSK) = 0)
+ if (SSL_CONF_CTX_cmd(cctx, -cipher, PSK) = 0)
{
BIO_puts(err, Error setting cipher to PSK\n);
ERR_print_errors(err);
diff --git a/demos/bio/client-arg.c b/demos/bio/client-arg.c
index cca7a1e..34035f5 100644
--- a/demos/bio/client-arg.c
+++ b/demos/bio/client-arg.c
@@ -25,7 +25,7 @@ int main(int argc, char **argv)
{
int rv;
/* Parse standard arguments */
- rv = SSL_CONF_cmd_argv(cctx, nargs, args);
+ rv = SSL_CONF_CTX_cmd_argv(cctx, nargs, args);
if (rv == -3)
{
fprintf(stderr, Missing argument for %s\n, *args);
diff --git a/demos/bio/client-conf.c b/demos/bio/client-conf.c
index 191615a..aec3c7b 100644
--- a/demos/bio/client-conf.c
+++ b/demos/bio/client-conf.c
@@ -47,7 +47,7 @@ int main(int argc, char **argv)
for (i = 0; i sk_CONF_VALUE_num(sect); i++)
{
cnf = sk_CONF_VALUE_value(sect, i);
- rv = SSL_CONF_cmd(cctx, cnf-name, cnf-value);
+ rv = SSL_CONF_CTX_cmd(cctx, cnf-name, cnf-value);
if (rv 0)
continue;
if (rv != -2)
diff --git a/demos/bio/server-arg.c b/demos/bio/server-arg.c
index 0d432a4..6ba5cc4 100644
--- a/demos/bio/server-arg.c
+++ b/demos/bio/server-arg.c
@@ -41,7 +41,7 @@ int main(int argc, char *argv[])
{
int rv;
/* Parse standard arguments */
- rv = SSL_CONF_cmd_argv(cctx, nargs, args);
+ rv = SSL_CONF_CTX_cmd_argv(cctx, nargs, args);
if (rv == -3)
{
fprintf(stderr, Missing argument for %s\n, *args);
diff --git a/demos/bio/server-conf.c b/demos/bio/server-conf.c
index 0d940f0..f19b5b8 100644
--- a/demos/bio/server-conf.c
+++ b/demos/bio/server-conf.c
@@ -62,7 +62,7 @@ int main(int argc, char *argv[])
{
int rv;
cnf = sk_CONF_VALUE_value(sect, i);
- rv = SSL_CONF_cmd(cctx, cnf-name, cnf-value);
+ rv = SSL_CONF_CTX_cmd(cctx, cnf-name, cnf-value);
if (rv 0)
continue;
if (rv != -2)
diff --git a/doc/apps/s_client.pod b/doc/apps/s_client.pod
index 17308b4..ff61825 100644
--- a/doc/apps/s_client.pod
+++ b/doc/apps/s_client.pod
@@ -90,7 +90,7 @@ SSL servers.
In addition to the options below the Bs_client utility also supports the
common and client only options documented in the
-in the LSSL_CONF_cmd(3)|SSL_CONF_cmd(3)/SUPPORTED COMMAND LINE COMMANDS
+LSSL_CONF_CTX_cmd(3)|SSL_CONF_CTX_cmd(3)/SUPPORTED COMMAND LINE COMMANDS
manual page.
=over 4
diff --git a/doc/apps/s_server.pod b/doc/apps/s_server.pod
index 1cc965f..616de1d 100644
--- a/doc/apps/s_server.pod
+++ b/doc/apps/s_server.pod
@@ -98,8 +98,8 @@ for connections on a given port using SSL/TLS.
In addition to the options below the Bs_server utility also supports the
common and server only options documented in the
-LSSL_CONF_cmd(3)|SSL_CONF_cmd(3)/SUPPORTED COMMAND LINE COMMANDS manual
-page.
+LSSL_CONF_CTX_cmd(3)|SSL_CONF_CTX_cmd(3)/SUPPORTED COMMAND LINE COMMANDS
+manual page.
=over 4
diff --git a/doc/ssl/SSL_CONF_CTX_cmd.pod b/doc/ssl/SSL_CONF_CTX_cmd.pod
new file mode 100644
index 000..ccc3dd5
--- /dev/null
+++ b/doc/ssl/SSL_CONF_CTX_cmd.pod
@@ -0,0 +1,442 @@
+=pod
+
+=head1 NAME
+
+SSL_CONF_CTX_cmd - send configuration command
+
+=head1 SYNOPSIS
+
+ #include openssl/ssl.h
+
+ int SSL_CONF_CTX_cmd(SSL_CONF_CTX *cctx, const char *cmd, const char *value);
+ int
Re: [openssl-dev] [openssl.org #3624] Unify SSL_CONF_* interface to be SSL_CONF_CTX_*, with patch against [master/33d5ba8]
Oh yes: and on top of that former patch there really where also dangling SSL_CTX_cmd() use cases in .pod files, which are thus and finally changed to SSL_CONF_CTX_cmd via the attached patch, too. Thank you. --steffen diff --git a/doc/ssl/SSL_CONF_CTX_cmd.pod b/doc/ssl/SSL_CONF_CTX_cmd.pod index ccc3dd5..b6aa600 100644 --- a/doc/ssl/SSL_CONF_CTX_cmd.pod +++ b/doc/ssl/SSL_CONF_CTX_cmd.pod @@ -351,26 +351,26 @@ however the call sequence is: SSLv2 is Balways disabled and attempt to override this by the user are ignored. -By checking the return code of SSL_CTX_cmd() it is possible to query if a -given Bcmd is recognised, this is useful is SSL_CTX_cmd() values are +By checking the return code of SSL_CONF_CTX_cmd() it is possible to query if +a given Bcmd is recognised, this is useful is SSL_CONF_CTX_cmd() values are mixed with additional application specific operations. -For example an application might call SSL_CTX_cmd() and if it returns +For example an application might call SSL_CONF_CTX_cmd() and if it returns -2 (unrecognised command) continue with processing of application specific commands. -Applications can also use SSL_CTX_cmd() to process command lines though the -utility function SSL_CTX_cmd_argv() is normally used instead. One way -to do this is to set the prefix to an appropriate value using +Applications can also use SSL_CONF_CTX_cmd() to process command lines though +the utility function SSL_CONF_CTX_cmd_argv() is normally used instead. +One way to do this is to set the prefix to an appropriate value using SSL_CONF_CTX_set1_prefix(), pass the current argument to Bcmd and the following argument to Bvalue (which may be NULL). In this case if the return value is positive then it is used to skip that -number of arguments as they have been processed by SSL_CTX_cmd(). If -2 is -returned then Bcmd is not recognised and application specific arguments -can be checked instead. If -3 is returned a required argument is missing -and an error is indicated. If 0 is returned some other error occurred and -this can be reported back to the user. +number of arguments as they have been processed by SSL_CONF_CTX_cmd(). +If -2 is returned then Bcmd is not recognised and application specific +arguments can be checked instead. If -3 is returned a required argument is +missing and an error is indicated. If 0 is returned some other error occurred +and this can be reported back to the user. The function SSL_CONF_CTX_cmd_value_type() can be used by applications to check for the existence of a command or to perform additional syntax diff --git a/doc/ssl/SSL_CONF_CTX_set1_prefix.pod b/doc/ssl/SSL_CONF_CTX_set1_prefix.pod index cdd952e..2e9c728 100644 --- a/doc/ssl/SSL_CONF_CTX_set1_prefix.pod +++ b/doc/ssl/SSL_CONF_CTX_set1_prefix.pod @@ -17,7 +17,7 @@ to Bprefix. If Bprefix is BNULL it is restored to the default value. =head1 NOTES -Command prefixes alter the commands recognised by subsequent SSL_CTX_cmd() +Command prefixes alter the commands recognised by subsequent SSL_CONF_CTX_cmd() calls. For example for files, if the prefix SSL is set then command names such as SSLProtocol, SSLOptions etc. are recognised instead of Protocol and Options. Similarly for command lines if the prefix is --ssl- then ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3626] Entropy on Win discounts CryptGenRandom length
rand_win.c(361) RAND_add(buf, sizeof(buf), 0);This is inconsistent with line 375 which passes sizeof(buf) for the bytes of entropy. This means that the entropy from the OS pool is discounted; in normal circumstances this is insignificant because the rest of this function collects plenty of entropy from the rest of the system. In rare cases this leads to problems in md_rand.c -- line 403 ok = (entropy = ENTROPY_NEEDED); if (!ok) In the case that rand_win.c doesn't seed with enough entropy it goes on to stir the pool it but never sets 'ok' afterward and so ssleay_rand_bytes returns failure which seems a bit harsh. Locally we've changed rand_win.c to pass sizeof(buf) when adding the entropy from PROV_RSA_FULL which avoids the problems in md_rand.c -- I'm not sure what the intention is there, though. The rare case involved actually came about after we discovered that RAND_poll was locking heaps in our process and generally causing massive hitches in certain parts of our game; once we'd traced it back to this heap-crawling stuff we made two changes to RAND_poll: 1) We increased the size of buf to 10242) We changed line 45 to if (kernel !good) The idea is that if the OS entropy pool will feed us a good chunk of good random numbers we can avoid beating the hell out of the heap which required serialization. Initially we found this worked great until certain users started complaining about OpenSSL errors because of the bugs described above -- it turns out some of them had turned off the OS Workstation service which was contributing entropy in rand_win.c(269) which brought us below the required amount of entropy in md_rand.c and here we are. -g ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
Hello, and finally i propose three new values for the Protocol slot of SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. I included OLDEST for completeness sake, NEWEST is in effect what i've always forced for my thing whenever possible, and encouraged users to use themselve, but of course it was pretty inflexible before the advent of NEWEST. :) I think VULNERABLE is a good thing to have despite it's humiliating name, because it could be used to automatically secure users by simply updating the OpenSSL library, effectively giving the option to obsolete insecure protocols faster than what was possible in the past, and of course: only possibly so. But anyway: in my opinion it would be a real security improvement if users could either use -ALL,NEWEST, or, shall that not be possible, ALL,-VULNERABLE, rather in the spirit configure once and forget, but stay secure. Or something along these lines. Find attached a patch that does this and can be applied on top of the other two patches i've send regarding SSL_CONF_CTX. Notes: - Readds a dummy SSLv2 value (thus includes a patch for the other issue i've opened). - Fixes some whitespace-at-eol issues of the .pod. Thanks and ciao. P.S.: i plan to release a new minor of my thing before the christian christmas feast, it would be _really_ great to know what the OpenSSL thinks regarding the function renaming and these new values, since i'm switching over to the new SSL_CONF_CTX interface and am implementing a wrapper unless HAVE_OPENSSL_CONF_CTX becomes omnipresent. Thank you. --steffen diff --git a/doc/ssl/SSL_CONF_CTX_cmd.pod b/doc/ssl/SSL_CONF_CTX_cmd.pod index b6aa600..4e8b67c 100644 --- a/doc/ssl/SSL_CONF_CTX_cmd.pod +++ b/doc/ssl/SSL_CONF_CTX_cmd.pod @@ -74,7 +74,7 @@ Bprime256v1). Curve names are case sensitive. =item B-named_curve -This sets the temporary curve used for ephemeral ECDH modes. Only used by +This sets the temporary curve used for ephemeral ECDH modes. Only used by servers The Bvalue argument is a curve name or the special value Bauto which @@ -85,7 +85,7 @@ can be either the BNIST name (e.g. BP-256) or an OpenSSL OID name =item B-cipher Sets the cipher suite list to Bvalue. Note: syntax checking of Bvalue is -currently not performed unless a BSSL or BSSL_CTX structure is +currently not performed unless a BSSL or BSSL_CTX structure is associated with Bcctx. =item B-cert @@ -111,7 +111,7 @@ operations are permitted. =item B-no_ssl3, B-no_tls1, B-no_tls1_1, B-no_tls1_2 -Disables protocol support for SSLv3, TLS 1.0, TLS 1.1 or TLS 1.2 +Disables protocol support for SSLv3, TLS 1.0, TLS 1.1 or TLS 1.2 by setting the corresponding options BSSL_OP_NO_SSL3, BSSL_OP_NO_TLS1, BSSL_OP_NO_TLS1_1 and BSSL_OP_NO_TLS1_2 respectively. @@ -177,7 +177,7 @@ Note: the command prefix (if set) alters the recognised Bcmd values. =item BCipherString Sets the cipher suite list to Bvalue. Note: syntax checking of Bvalue is -currently not performed unless an BSSL or BSSL_CTX structure is +currently not performed unless an BSSL or BSSL_CTX structure is associated with Bcctx. =item BCertificate @@ -244,7 +244,7 @@ Bprime256v1). Curve names are case sensitive. =item BECDHParameters -This sets the temporary curve used for ephemeral ECDH modes. Only used by +This sets the temporary curve used for ephemeral ECDH modes. Only used by servers The Bvalue argument is a curve name or the special value BAutomatic which @@ -259,9 +259,17 @@ The supported versions of the SSL or TLS protocol. The Bvalue argument is a comma separated list of supported protocols to enable or disable. If an protocol is preceded by B- that version is disabled. All versions are enabled by default, though applications may choose to -explicitly disable some. Currently supported protocol values are -BSSLv3, BTLSv1, BTLSv1.1 and BTLSv1.2. The special value BALL refers -to all supported versions. +explicitly disable some. +Currently supported protocol values are +BSSLv3, BTLSv1, BTLSv1.1 and BTLSv1.2. + +Some special values are understood: +BALL refers to all supported versions, +BNEWEST will always refer to the newest of the supported protocols, +currently BTLSv1.2, +BOLDEST refers to the oldest supported protocol, currently BSSLv3, +and BVULNERABLE includes all protocols which have known vulnerabilities +(in the default configuration). =item BOptions @@ -339,16 +347,16 @@ The value is a directory name. The order of operations is significant. This can be used to set either defaults or values which cannot be overridden. For example if an application calls: - SSL_CONF_CTX_cmd(ctx, Protocol, -SSLv2); + SSL_CONF_CTX_cmd(ctx, Protocol, -SSLv3); SSL_CONF_CTX_cmd(ctx, userparam, uservalue); -it will disable SSLv2 support by default but the user can override it. If +it will disable SSLv3 support by default but the user can override it. If however the call sequence is: SSL_CONF_CTX_cmd(ctx, userparam, uservalue); - SSL_CONF_CTX_cmd(ctx,
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
I think magic names -- shorthands -- are a very bad idea. They are point-in-time statements whose meaning evolves, if not erodes, over time. ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
I think magic names -- shorthands -- are a very bad idea. They are point-in-time statements whose meaning evolves, if not erodes, over time. ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2
On Mon, Dec 08, 2014 at 07:58:31PM +0100, Steffen Nurpmeso via RT wrote:
set ssl-protocol=ALL,-SSLv2
This results in the obvious problem that when they (get)
upgrade(d) their OpenSSL library they will see a completely
intransparent error message that no normal user will understand:
It was actually my intention to keep supporting that, but I seem
to have removed that line. I think the following patch should fix
that:
--- a/ssl/ssl_conf.c
+++ b/ssl/ssl_conf.c
@@ -333,6 +333,7 @@ static int cmd_Protocol(SSL_CONF_CTX *cctx,
const char *value)
static const ssl_flag_tbl ssl_protocol_list[] =
{
SSL_FLAG_TBL_INV(ALL, SSL_OP_NO_SSL_MASK),
+ SSL_FLAG_TBL_INV(SSLv2, SSL_OP_NO_SSLv2),
SSL_FLAG_TBL_INV(SSLv3, SSL_OP_NO_SSLv3),
SSL_FLAG_TBL_INV(TLSv1, SSL_OP_NO_TLSv1),
SSL_FLAG_TBL_INV(TLSv1.1, SSL_OP_NO_TLSv1_1),
Kurt
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
On Mon, Dec 08, 2014 at 08:20:44PM +0100, Steffen Nurpmeso via RT wrote: Hello, and finally i propose three new values for the Protocol slot of SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. I actually find the option unfortunate and I think it should have been one that sets the minimum and maximum version. But I think we're too late 1.0.2 process to still change this. Kurt ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3181] [PATCH] OCB
OCB support has been merged in. Closing my own ticket. Following is not directly related to the case per se [which is why rt doesn't get this message]. It's just that it makes nice example on why one sometimes wants to implement encryption mode in assembly. If you compare performance on AES-NI-capable processor, you'll see significant differences depending on compiler used. Here is result for clang: type... 8192 bytes aes-128-ocb ... 909434.88k And here is for gcc aes-128-ocb ... 399447.38k Thing is that hardware-assisted crypto is so fast that surrounding code can start dominating execution time. I mean above is indication of such case. And it also likely to mean that even former above result is actually far from optimal, it's surely possible to improve it by several *times*. Indeed, OCB is parallelizeable mode, and it should be close to other parallelizeable ones. Here is CTR result from same processor: aes-128-ctr ... 4407367.00k Well, it's AEAD, so there would be some overhead, but it's minimal in OCB. But let's compare to GCM anyway: aes-128-gcm ... 2719591.59k Once again, this is *not* some kind of objection, only a note that *if* we decide to consider the mode in question important, it should be possible to improve it by factor of several times on contemporary CPUs. ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
On 8 December 2014 at 19:20, Steffen Nurpmeso via RT r...@openssl.org wrote: and finally i propose three new values for the Protocol slot of SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. In Qt we've added an enum value for TLS versions that is SecureProtocols so that we could remove versions as required without requiring apps to be updated. It's an open question which is more likely to get updated - Qt or the apps of course. For Qt 5.4 which is due out this week we've removed SSL3 from this enum so apps will silently get updated to drop support for it. Cheers Rich. ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3622] bug: crypto, valgrind reports improper memory access with AES128 cbc and longer plaintext
Thanks for the response, Andy, it's good to know that the demo program does actually work for someone. Sorry for the delay, I'm kinda busy with other things right now. Also, I realised the link was truncated, but it looks as though you found the demo anyway. https://github.com/saju/misc/blob/master/misc/openssl_aes.c The demo program actually allocates a whole extra block for the output, so there should always be extra space available. Switching to calloc instead of malloc does not hide the issue, which suggests that it's actually a problem somewhere in the bowels of OpenSSL, copying unassigned values into the output. Likewise, the demo program uses null-terminated strings because they're easy to see in operation. My real program uses manually padded, known-size binary packets but adding extra code to show that did not seem worth while. It would likely lead to a bunch of other questions about design decisions and other irrelevancies when the problem is that valgrind is unhappy about the way OpenSSL (appears to) work. I've just re-tested, pasting the code in to both C and C++ netbeans projects (since that's what my main project uses) and fixing the C++ convert-from-const errors as well as adding aes.h. Both give the same valgrind issues for me. I'm using gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) and valgrind-3.10.0.SVN if that might make a difference. Experimentation shows that the magic length is 96 bytes - strlen()=94 works fine on my machine, strlen()=95 produces the valgrind complaints. That means input length of 96, since the code uses strlen()+1. What's magic about a 96 byte input size? (other than being 6 AES128 blocks) Since I have a new Fedora 20 virtual machine handy I have also run on that with the same result:Using OpenSSL version OpenSSL 1.0.1e-fips 11 Feb 2013 ==2793== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ... ==2793== Conditional jump or move depends on uninitialised value(s) ==2793== at 0x4C2A79E: strncmp (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==2793== by 0x400FA1: main (in /home/digidev/test/a.out) ==2793== Uninitialised value was created by a stack allocation ==2793== at 0x4EC0DB7: aesni_cbc_encrypt (in /usr/lib64/libcrypto.so.1.0.1e) ... I hoped that the padding functions would mean that manually padding the inputs was not necessary. Admittedly in my real code I am doing manual padding to get control over the padding - the hardware I'm communicating with does not pad or accept padding on a plaintext that is an exact multiple of the block size where OpenSSL/PKCS does. But the demo uses auto padding, and I'd hoped that it would work. aes_encrypt function has this: /* update ciphertext with the final remaining bytes */ EVP_EncryptFinal_ex(e, ciphertext + encryptedLength, paddingLength); *len = encryptedLength + paddingLength; Surely this means that the output is padded and therefore the input does not need to be a multiple of the block size. The program claims to work without manual padding, anyway. As far as querying the block size, that has ramifications beyond my program so changing it would break compatibility with hardware we've already shipped (for example). All I could do if I queried was check against the hard-coded value and exit abruptly since my program will not work. ThanksChris From: Andy Polyakov via RT r...@openssl.org To: prwh...@yahoo.com.au Cc: openssl-dev@openssl.org Sent: Saturday, 6 December 2014, 3:27 Subject: Re: [openssl.org #3622] bug: crypto, valgrind reports improper memory access with AES128 cbc and longer plaintext I started with an AES256 demo I found at https://github.com/saju/misc and modified the initialisations to use AES128. The test strings that program uses are quite short - less than 100 characters. If I add a significantly longer string to those test values Valgrind reports a string of what I suspect are buffer overruns. Note that I discovered this in my real code and this is a simple test case that seems to demonstrate the same problem. I also print the library version that the program is using. I don't get any valgrind errors, not a single one. But then I had to add -DAES_BLOCK_SIZE=16 at compiler command line, as program in question failed to include openssl/aes.h. Well, I don't really want to say failed to include, because it implies that I'd suggest to do so, when I don't actually mean to. Correct solution in real life would be to query cipher block size with EVP_CIPHER_block_size, as opposite to relying on cipher-specific header. It's just that I see no point in fixing that program. As for alleged buffer overruns in your program. You have to recognize and remember that AES is a block cipher, which means that CBC encrypt output and decrypt input lengths has to be divisible by block size. [Ideally even encrypt input and decrypt output lengths should be divisible, but EVP gives you some help by padding
