Is anyone seeing the following error when building 1.0.2 stable on Windows:
Creating library tmp32dll\junk.lib and object tmp32dll\junk.exp
IF EXIST out32dll\sslv2conftest.exe.manifest mt -nologo -manifest
out32dll\sslv2conftest.exe.manifest -outputresource:out32dll\sslv2conftest.exe;1
One of the challenges with this will be symbol collision (in a Linux
environment). I would think that doing this as a static engine would
not be possible. The reason is your new engine that's using the 2.0.11
canister would contain symbols that exist in OpenSSL. But maybe the
fipssyms.h trick
Thank you.
On 01/28/2016 12:20 PM, Matt Caswell wrote:
On 28/01/16 16:40, John Foley wrote:
I just cloned the OpenSSL git repo at
git://git.openssl.org/openssl.git. Looking at the OpenSSL_1_0_1-stable
branch, the fix for CVE-2015-3197 still isn't in the repo. The most
recent comm
I just cloned the OpenSSL git repo at
git://git.openssl.org/openssl.git. Looking at the OpenSSL_1_0_1-stable
branch, the fix for CVE-2015-3197 still isn't in the repo. The most
recent commit is:
foleyj@hobknob:~/gitsync/ossl/openssl$ git log
commit 126ac21c80967ec00f802d356462c1b83fa0f54c
Au
If anyone is interested, I've added a new build to the Jenkins workflow
to verify ABI compatibility on the 1.0.2-stable branch. This job will
run nightly and look for ABI differences between the current build and
the build from the previous night. If a commit goes into the branch
that changes
Take a look at the INSTALL.W32 file in the tarball. This details all
the requirements and steps to compile the code.
On 10/27/2015 01:15 PM, Tom Kacvinsky wrote:
> Hi,
>
> I've seen several messages float by about building OpenSSL on
> Windows. My understanding is that I'll need a Perl distribu
Is the "Async support" you have listed the same code that Intel
developed for Cave Creek? Or is the Intel contribution planned for a
follow-on release?
On 09/16/2015 10:54 AM, Matt Caswell wrote:
>
>
> On 16/09/15 15:38, Alessandro Ghedini wrote:
> > On Wed, Sep 16, 2015 at 11:16:18AM +0100, Mat
Here's another trivial example if that URL still isn't working for you:
johnsantic.com/comp/<http://johnsantic.com/comp/>state.html
On Sep 11, 2015, at 5:46 PM, Daniel Kahn Gillmor
mailto:d...@fifthhorseman.net>> wrote:
On Fri 2015-09-11 11:07:27 -0400, John Foley wro
We're seeing intermittent failures in the AES key wrap test cases in
test/evp_test in the 1.0.2d release. We believe the problem is due to
using memcpy() with overlapping src/dst memory regions. The following
thread provides some insight into this memcpy() issue:
https://bugzilla.redhat.com/show
+1
It's great to see improvements in the state machine along with
consolidated handlers for TLS/DTLS. Having said that, have you
considered using a state transition table instead of long switch
statements to enforce the state transition rules? This would improve
the maintainability of the code.
Is OpenSSL planning to implement side-channel resistance against the
following attack:
https://eprint.iacr.org/2014/161.pdf
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
e several cross-compile builds running on
> Cisco's
> > build farm. The more the merrier. I am sure ARM would be
> appreciated.
> >
> > >Are these linked from the website somewhere?
> >
> > No. John Foley @Cisco posted bout them, I thi
wrote:
> >>Thanks! We have several cross-compile builds running on Cisco's
> build farm. The more the merrier. I am sure ARM would be
> appreciated.
>
> >Are these linked from the website somewhere?
>
> No. John Foley @Cisco posted bo
It could be the gcc version is too old. Trying to recall, gcc needs to
be something like 4.4 or newer to support the Intel carry-less multiply
instruction.
On 06/11/2015 09:37 AM, Dimitrios Apostolou wrote:
> Hello list,
>
> I've been trying to build OpenSSL-1.0.2a on an outdated SLES11 system.
Is anyone having problems building 1.0.2-stable on FreeBSD? It appears
the following commit may have broken the build:
https://github.com/openssl/openssl/commit/f877da9cedb95df94105d7292f8e0963175e58dc
Here's the error we're seeing:
[jenkins@freebird ~/tmp/openssl-OpenSSL_1_0_2-stable]$ gmake d
rs to be due to the
movzwl reading past the end of the buffer by a byte. Given the data
allocated on the heap is likely surrounded by guard bytes, this is
likely a benign read outside the buffer. But it should still be fixed.
On 05/13/2015 10:46 AM, John Foley wrote:
> Sorry for misinterpret
e are quite a few changes. My guess is this was introduced
in ec9cc70f72454b8d4a84247c86159613cee83b81.
On 05/13/2015 10:13 AM, Henrik Grindal Bakken wrote:
> John Foley writes:
>
>> If you add the --show-reachable option to valgrind, you can see where
>> the leaks originate. T
Upon further investigation, it looks like the problem is in your sample
code. You need to invoke CRYPTO_cleanup_all_ex_data() before
terminating your program.
On 05/13/2015 07:25 AM, Henrik Grindal Bakken wrote:
> Hi. I have an application that generates Diffie-Hellman key pairs based
> on some
If you add the --show-reachable option to valgrind, you can see where
the leaks originate. They appear to be in the ex_data code (see
below). As a side note, I see 416 bytes lost when using OpenSSL 1.0.1f
as well as 1.0.2a.
==18173== HEAP SUMMARY:
==18173== in use at exit: 416 bytes in 6 blo
My bad, I overlooked the dereference operator. Thanks for correcting me.
On 05/04/2015 10:36 AM, Stephan Mühlstrasser wrote:
> Am 04.05.15 um 16:19 schrieb John Foley:
>> I think you're wrong about sizeof and pointers. It'll return 4 or 8
>> depending if it's a
AM, Stephan Mühlstrasser wrote:
> Am 04.05.15 um 14:51 schrieb John Foley:
>> Is anyone seeing a segmentation fault during the test_verify phase of
>> make test on 32-bit systems? I haven't done a full triage yet. But it
>> appears to have been introduced by
>> 5b
Is anyone seeing a segmentation fault during the test_verify phase of
make test on 32-bit systems? I haven't done a full triage yet. But it
appears to have been introduced by
5b38d54753acdabbf6b1d5e15d38ee81fb0612a2. The problem no longer occurs
when backing out this commit. This could be a fau
This may be considered a bug. When doing a FIPS build of OpenSSL
1.0.2a, some ciphers leverage the FIPS flavor of the cipher even when
FIPS mode is disabled. This impacts performance since the FIPS ciphers
incur additional overhead. The attached patch changes this behavior to
only invoke the FIP
sessions. Hence, tls_session_secret_cb() is always in play for
EAP-FAST.
On 03/26/2015 02:13 PM, Emilia Käsper wrote:
On Tue, Mar 24, 2015 at 2:01 PM, John Foley <mailto:fol...@cisco.com>> wrote:
Trying again w/o PGP... :-)
Thanks for taking a look at this problem. Rega
send the alert.
Therefore, maybe you would actually want to do something like:
SSLerr(SSL_F_SSL3_GET_SERVER_HELLO, ERR_R_INTERNAL_ERROR);
al = SSL_AD_INTERNAL_ERROR;
goto f_err;
On 03/23/2015 09:17 PM, Emilia Käsper wrote:
On Tue, Mar 24, 2015 at 1:20 AM, Joh
binBBeWr6TKqL.bin
Description: PGP/MIME version identification
encrypted.asc
Description: OpenPGP encrypted message
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
We've found a way to recreate the scenario using s_client/s_server. We're
using the -no_ticket option on the server. Therefore, the ServerHello doesn't
contain the session ticket extension. It also doesn't send the
NewSessionTicket message.
To summarize the problem, when the client side is
Something does seem suspect here. Maybe I'm misusing the API, but when
using the attached patch for s_server, the client side does reject the
NewSessionTicket message from the server. This only happens when using
SSL_set_session_secret_cb() on the server side. When using this
callback facility,
The following patch allows CRYPTO_thread_id() to be invoked from the
FIPS module. Without this patch the thread ID can not be retrieved
properly, leading to thread synchronization issues in the FIPS module.
Currently there's no way to exploit this problem since
CRYPTO_thread_id() isn't used withi
My mistake, it looks like my memory was wrong on two accounts. First,
it was AES, not SHA, where I observed the no-asm was faster. Second, it
was on the PowerPC cross-compiled target, not ARM. The results from
"openssl speed aes-128-cbc" are:
type 16 bytes 64 bytes256 bytes
I can't speak directly to your question on the iphone-cross target, but
can warn you that your mileage will vary when using the ARM assembly
modules. We observed that some algorithms actually run slower when
using the ARM assembly modules. It's been a couple of years and I don't
recall the detail
In addition to client authentication, another approach would be to use
TLS-SRP to protect against MITM. Without the SRP credentials, the
attacker would not be able to establish the two TLS connections required
for MITM.
On 03/11/2015 09:35 AM, Short, Todd via RT wrote:
> This is more of a request
There appears to be a problem when using s_server with ECDHE cipher
suites in OpenSSL_1_0_1-stable. Due to an uninitialized variable,
SSL_CTX_set_tmp_ecdh() is not always invoked within s_server. The
following patch resolves the issue. This bug appears to have been
introduced by 059907771b89549c
Sorry for responding late to this thread, but has anyone considered
consolidating the following three definitions:
OPENSSL_NO_EC
OPENSSL_NO_ECDH
OPENSSL_NO_EDDSA
Is there a valid case where all three of these wouldn't be used
together? Would the code even compile if only one (or two) of these
we
In the 1.0.2 stable branch, the following code in s3_srvr.c sets the
return value twice (line# 380). Should the return value be
SSL_TLSEXT_ERR_ALERT_FATAL, or -1?
if (ret != SSL_ERROR_NONE) {
ssl3_send_alert(s, SSL3_AL_FATAL, al);
/*
* This is not really an error but the only means
Which Cisco product are you using, the ASA? What version of software do
you have on the product? While I can't speak for all Cisco products, I
can confirm that many Cisco products are using OpenSSL 1.0.1, which
implies support for DTLS 1.0. If you care to share more details, I can
try to engage t
Yes, it's working now. Thanks.
Are you interested in receiving the build failure notification directly from
our Jenkins server? Or would you rather I continue to forward the failures to
Openssl-dev?
> On Feb 4, 2015, at 6:40 PM, "Matt Caswell" wrote:
>
>
>
Is anyone seeing the following error when building master on Windows?
ms\version32.rc(47) : fatal error RC1004: unexpected end of file found
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Windows
Kits\8.1\bin\x86\rc.EXE"' : return code '0x1'
Stop.
The full build log is located here:
htt
It looks like libeay.num and ssleay.num need updated too...
c:\nightly\workspace\master_windows>perl util\mkdef.pl 32 libeay
1>ms\libeay32.def
WARNING: mkdef.pl doesn't know the following algorithms:
APPLINK
RMD160
Warning: RSA_padding_chk_PKCS1_OAEP_mgf1 does not have a number
It appears the Windows build is broken on master with the recent commit to the
DES code. Please see the error message at the bottom of this message...
Begin forwarded message:
From: mailto:openssl.san...@gmail.com>>
Date: February 2, 2015 at 7:12:24 PM EST
To: mailto:fol...@cisco.com>>
Subject
Thanks for fixing this. Windows is now building on 1_0_1-stable.
Having said that, you inspired me to add another job on my jenkins
server to to a sanity build on master for Windows. I'm seeing the
following error when trying to build on master using the identical build
process. Should I dig de
Thanks for the update. I was curious why it was removed from 1.0.1. It
seemed to be beyond the scope of a bug fix. Given 1.0.2 has now been
released, should eng_rsax been removed there too?
On 01/27/2015 01:06 PM, Salz, Rich wrote:
> Oh, I thought it was in master!
>
> In 1.0.1 it was a mista
I'm sure this would resolve the issue. The problem exists in 1.0.1, but
not 1.0.2. Here's the entry in the 1.0.1 libeay.num:
ENGINE_load_rsax 4652 EXIST::FUNCTION:ENGINE
And here's the entry in the 1.0.2 flavor of libeay.num:
ENGINE_load_rsax 4652 NOEXIST::FUNCTION:
You just need to to "make
It looks like the Windows export symbols may need updating now that the
rsax engine has been removed (yesterday). Here's the error from the log...
link /nologo /subsystem:console /opt:ref /debug /dll /out:out32dll\libeay32.dll
/def:ms/LIBEAY32.def @C:\Users\ADMINI~1\AppData\Local\Temp\1\nm3A91.t
Is the Windows build broken on 1.0.2-stable, am I doing something wrong,
or is this a tool chain issue?
Assembling: tmp32\sha1-586.asm
tmp32\sha1-586.asm(1432) : error A2070:invalid instruction operands
tmp32\sha1-586.asm(1576) : error A2070:invalid instruction operands
NMAKE : fatal error U1077
Thanks for setting me straight. 1.0.2 works for me when using nasm.
On 01/13/2015 10:00 AM, Andy Polyakov wrote:
>> Thanks for responding. Which tool chain are you using? I'm using VS
>> 2013 with the ml compiler. Given this assembly is generated by a perl
>> script, maybe it's a perl issue.
Thanks for responding. Which tool chain are you using? I'm using VS
2013 with the ml compiler. Given this assembly is generated by a perl
script, maybe it's a perl issue. Which perl interpreter are you using?
On 01/13/2015 09:24 AM, Matt Caswell wrote:
>
> On 13/01/15 14:05,
chain requirement for building 1.0.2 on Windows?
Has the build procedure changed? Or is this simply a bug in sha1-586.pl?
On 01/08/2015 03:41 PM, John Foley wrote:
> Is the Windows build broken on 1.0.2-stable, am I doing something wrong,
> or is this a tool chain issue? I'm using VS
Is the Windows build broken on 1.0.2-stable, am I doing something wrong,
or is this a tool chain issue? I'm using VS 2013. Using the following
steps works on 1.0.1-stable:
perl Configure VC-WIN32
ms\do_ms.bat
nmake -f ms\nt.mak
Here's the log from the broken 1.0.2 build:
http://173.39.238.160
It appears there's another error num breakage in ssl/s3_clnt.c at line
1544. Please see the details at the bottom of the following log:
http://173.39.238.160:8080/job/1_0_1_make_errors/1/console
Please see my comment under commit
37580f43b5a39f5f4e920d17273fab9713d3a744 in github with the sugges
The following problem occurs when doing "make errors" on the 1.0.1
stable branch:
foleyj@foley-w520:/nobackup/tmp/x90/openssl$ make errors
/usr/bin/perl util/ck_errf.pl -strict */*.c */*/*.c
ssl/s3_clnt.c:1544:ssl3_get_key_exchange:ssl3_get_server_certificate
crypto/asn1/a_verify.c:157:asn1_item_
Thank you.
On 08/13/2014 01:39 PM, Kurt Roeckx via RT wrote:
> On Tue, Aug 12, 2014 at 08:36:06PM +0200, Kurt Roeckx wrote:
>> On Tue, Aug 12, 2014 at 08:22:38PM +0200, John Foley via RT wrote:
>>> The first chunk in the s3_lib.c patch doesn't apply. But the second
>
Thank you.
On 08/13/2014 01:39 PM, Kurt Roeckx via RT wrote:
> On Tue, Aug 12, 2014 at 08:36:06PM +0200, Kurt Roeckx wrote:
>> On Tue, Aug 12, 2014 at 08:22:38PM +0200, John Foley via RT wrote:
>>> The first chunk in the s3_lib.c patch doesn't apply. But the second
>
Roeckx via RT wrote:
> On Tue, Aug 12, 2014 at 01:26:30AM +0200, John Foley via RT wrote:
>> The commit into 1.0.1 didn't include the changes to s3_lib.c. SRP is still
>> broken on this branch. Are there any plans to fix this?
> Can you confirm that that commit from master fi
Roeckx via RT wrote:
> On Tue, Aug 12, 2014 at 01:26:30AM +0200, John Foley via RT wrote:
>> The commit into 1.0.1 didn't include the changes to s3_lib.c. SRP is still
>> broken on this branch. Are there any plans to fix this?
> Can you confirm that that commit from master fi
The commit into 1.0.1 didn't include the changes to s3_lib.c. SRP is still
broken on this branch. Are there any plans to fix this?
> On Aug 11, 2014, at 6:41 PM, "Kurt Roeckx via RT" wrote:
>
>> On Mon, Aug 11, 2014 at 11:09:51PM +0200, John Foley via RT wrote:
&
The commit into 1.0.1 didn't include the changes to s3_lib.c. SRP is still
broken on this branch. Are there any plans to fix this?
> On Aug 11, 2014, at 6:41 PM, "Kurt Roeckx via RT" wrote:
>
>> On Mon, Aug 11, 2014 at 11:09:51PM +0200, John Foley via RT wrote:
&
The fix discussed in this thread appears to be incomplete:
http://marc.info/?l=openssl-users&m=140752401023837&w=2
This fix works for SRP cipher suites that uses RSA for DSA, which
includes 6 of the 9 supported SRP cipher suites. But the three SRP
cipher suites that don't rely on a server-side c
The following error occurs using the 20140613 snapshot on the 1.0.2
trunk. The host is a 64-bit CentOS system. This problem does
not occur on 32-bit CentOS.
gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include
-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H
-Wa,--noexecs
The following error occurs using the 20140612 snapshot on the 1.0.2
trunk. The host is a 64-bit CentOS system. Is this a known issue?
gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include
-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H
-Wa,--noexecstack -m64 -DL_ENDIAN -DTE
Thanks for the guidance, much appreciated.
On 06/10/2014 10:31 AM, Dr. Stephen Henson wrote:
> On Tue, Jun 10, 2014, John Foley wrote:
>
>> Can we imply from this commit that the 1.0.2 release is imminent? If
>> not, can anyone provide a rough estimate on when 1.0.2 will be re
Can we imply from this commit that the 1.0.2 release is imminent? If
not, can anyone provide a rough estimate on when 1.0.2 will be released
(1 month, 3 months, 6 months from now)?
On 06/10/2014 10:17 AM, Dr. Stephen Henson wrote:
> This is an automated email from the git hooks/post-receive scri
Here's more information for those who are interested...
https://supportforums.cisco.com/announcement/12198406/heartbleed-patched-email-servers-fail-tls-connections-esas-80
On 05/06/2014 07:08 PM, Viktor Dukhovni wrote:
> On Tue, May 06, 2014 at 02:32:05PM -0400, John Foley wrote:
/docs/security/esa/esa8-0/release_notes/ESA_8-0-1_HP2_Release_Notes.pdf
On 05/06/2014 01:10 PM, Kurt Roeckx wrote:
> On Thu, May 01, 2014 at 01:23:51PM -0400, John Foley wrote:
>> I'm trying to get that information from the IronPort team. In the mean
>> time, this bug re
How prevalent is RC4 today? While web browsers still advertise RC4
cipher suites, how often do you see RC4 cipher suites advertised by the
client and no AES or 3DES suites advertised? Does Akamai have any data
on this? Maybe RC4 should now be disabled by default.
On 05/02/2014 09:49 AM, Salz,
I'm trying to get that information from the IronPort team. In the mean
time, this bug report appears to have some details:
https://tools.cisco.com/bugsearch/bug/CSCuo25329
On 05/01/2014 12:26 PM, Viktor Dukhovni wrote:
> On Thu, May 01, 2014 at 12:08:50PM -0400, John Foley wrote:
>
This is a known problem in the Ironport TLS stack. Ironport has
released a hot patch to address this problem.
On 05/01/2014 06:29 AM, Marcus Meissner via RT wrote:
> Hi,
>
> SUSE has received a bugreport from a user, that the "padding" extension
> change breaks IronPort SMTP appliances.
>
> Ther
Rather than dropping it from the list, another option would be to
re-prioritize the list. Given MD5 is weak, it should be at the end of
the ClientHello signature algorithms extensions. This would facilitate
backwards compatibility, while improving the security posture when
communicating with peer
Rather than dropping it from the list, another option would be to
re-prioritize the list. Given MD5 is weak, it should be at the end of
the ClientHello signature algorithms extensions. This would facilitate
backwards compatibility, while improving the security posture when
communicating with peer
Agreed, utilizing GCM mode is like solving a puzzle. Some documentation
would be helpful. The EVP API doesn't appear to be setup for AEAD
ciphers. The attached code shows one way to use the EVP API for AES-GCM
mode. Hopefully this helps.
On 03/01/2013 02:12 AM, Leon Brits wrote:
> I am tryin
Agreed.
This does raise an interesting design dilemma. The client has no way to
know in advance whether the server will be sending the
CertificateRequest message. If the server is not doing client auth,
then the client certificate will never be needed. Hence, offering all
the signature alg
Thanks for confirming and providing the work-around.
Do you see any problems with the proposed patch, which could still be
applied to the 1.0.1 trunk to avoid the work-around for non-FIPS users?
On 08/03/2012 09:10 AM, Stephen Henson via RT wrote:
>> [fol...@cisco.com - Fri Aug 03 10:51:37 201
Thanks for confirming and providing the work-around.
Do you see any problems with the proposed patch, which could still be
applied to the 1.0.1 trunk to avoid the work-around for non-FIPS users?
On 08/03/2012 09:10 AM, Stephen Henson via RT wrote:
[fol...@cisco.com - Fri Aug 03 10:51:37 201
This problem occurs in the FIPS 2.0 and 2.0.1 Object Modules. The
conditions for the test are:
Platform: Linux 32-bit
AAD length: greater than 16 bytes and not evenly divisible by 16 (e.g.
20 bytes of AAD)
Cipher text length: 0
Under these conditions, the remaining AAD bytes beyond the last
Looking at the 7/24 snapshot, is there a reason the AES CCM modes are
omitted from OpenSSL_add_all_ciphers()? Or is this simply an oversight?
Thank you.
<>
OK, thanks for clarifying this.
On 07/12/2012 02:53 PM, Steve Marquess wrote:
On 07/09/2012 03:55 PM, John Foley wrote:
According to the NIST web site, the 2.0 FIPS Object Module claims
compliance for FIPS 186-3 using the "Extra Random Bits" method for EC
public key genera
According to the NIST web site, the 2.0 FIPS Object Module claims
compliance for FIPS 186-3 using the "Extra Random Bits" method for EC
public key generation. This is taken from:
http://csrc.nist.gov/groups/STM/cavp/documents/dss/ecdsaval.html#270
The extra random bits method is defined in FI
Confirmed. The problem is resolved in the latest snapshot. Thank you.
On 07/06/2012 04:57 PM, Stephen Henson via RT wrote:
>> [fol...@cisco.com - Fri Jul 06 17:50:15 2012]:
>>
>> RFC 5246 allows a TLS 1.2 client to omit the Signature Algorithm
>> extension. See section 7.4.1.4.1 for details.
Confirmed. The problem is resolved in the latest snapshot. Thank you.
On 07/06/2012 04:57 PM, Stephen Henson via RT wrote:
[fol...@cisco.com - Fri Jul 06 17:50:15 2012]:
RFC 5246 allows a TLS 1.2 client to omit the Signature Algorithm
extension. See section 7.4.1.4.1 for details. This cre
RFC 5246 allows a TLS 1.2 client to omit the Signature Algorithm
extension. See section 7.4.1.4.1 for details. This creates a problem
for OpenSSL 1.0.1 when acting as a server and either a DSA or ECDSA
certificate is used. Because the ClientHello does not contain the
Signature Algorithm exte
Thanks for the information, that explains it. The vpaes-x86 module
isn't included in the FIPS module.
The CPU information is:
model name: Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz
On 05/11/2012 09:07 AM, Andy Polyakov wrote:
>> Is AES performance expected to be much lower when usi
Is AES performance expected to be much lower when using the FIPS 2.0
Object Module? Below are the speed results when using AES-128-CBC with
and w/o the FIPS module. The host system is 32-bit Linux using gcc
4.4.3. The host system does not have AES-NI support. No additional
config arguments were
In version 1.0.1, the TLS unit test script does not invoke any of the
TLS 1.2 methods.
The attached patch resolves this problem by adding support for the
-tls1_2 option to ssl/ssltest.c. The test/testssl script is also
modified to utilize this new option.
Index: ssl/ssltest.c
==
Based on the results, it looks like you're using AES-NI in both cases.
Try running this command to avoid using AES-NI:
openssl speed aes-128-cbc
On 02/24/2012 12:27 PM, no_spam...@yahoo.com wrote:
> Hello.
>
> I am running CentOS 6.2 (i386) under VMware vSphere Hypervisor 5 on a box
> with a
Is this Windows 7? Try adding the FIXED flag to the Microsoft linker.
Windows 7 will relocate DLLs (quite often). When this occurs, the FIPS
signature will fail.
On 09/06/2011 04:22 PM, Dr. Stephen Henson wrote:
> On Tue, Sep 06, 2011, Tyrel Haveman wrote:
>
>> It looks like there's a failure
David,
Would your ECDSA implementation be subject to the following timing attack?
Original Message
Subject:New Timing Attack on OpenSSL ECDSA
Date: Wed, 25 May 2011 15:59:58 +0200
From: Mounir IDRASSI
Reply-To: openssl-dev@openssl.org
Organization: IDRIX
To
It looks like TLS 1.2 is being implemented in recent commits. Is there
an anticipated completion date for when v1.2 will be fully implemented?
__
OpenSSL Project http://www.openssl.org
Development M
OK, I'm still a bit confused on the version labeling. Is it safe to
assume the next stable label pulled off HEAD (e.g. 1.0.2) will include
support for "make -f Makefile.fips dist". Or to put the question
another way, what stable label should be used to generate the FIPS
Object Model 2.0 source co
Steve,
It looks like the FIPS 2.0 code has been going into HEAD. When do you
plan to pull a branch for the FIPS Object Model 2.0?
On 05/13/2011 12:24 PM, Steve Marquess wrote:
> > What is happening?
>
> >
>
> > No Fips in the Openssl 1.0.1 STABLe.
>
> >
>
> >
>
> Correct, and you won't be seei
89 matches
Mail list logo