I just cross compile the OpenSSL 0.9.7 under linux by mipsel-linux-gcc for
MIPS R3000, no error occur during the compiling process.
But, when I put the result lib to the hard platform, the openssl routines
can not be carried out and “segment fault” occurs.
Why? Does the OpenSSL not support
杨成 wrote:
Hi, everyone,
An urgent problem:
I just cross compile the OpenSSL 0.9.7 under linux by mipsel-linux-gcc for
MIPS R3000, no error occur during the compiling process.
But, when I put the result lib to the hard platform, the openssl routines
can not be carried out and ¡°segment fault¡±
Andrews, Rick wrote:
I'm sorry to bother the whole list with this, but how do I submit a bug
against OpenSSL? All I can find on the web page is The README file
describes how to submit bug reports and patches to OpenSSL. But I don't
see a README anywhere on the website or in the source code I
I'm aware that this question has been asked before, but is anyone
working on adding SHA256 support to the existing ciphersuites? I'm
developing an application that requires these, so I'd appreciate it if
anyone could give me an update on when this support will be implemented,
or if it is planned
I am new to Application development using OpenSSL. Currently I have
installed 0.9.7b (the version I need to use) would like to write a
small application using the OpenSSL function calls would like to know
if I can find some example source code.
Also would like to know if I can find some
I am getting this error and am trying to find any info that could help
me get past it.
Relevant code snippet:
if(!(d-ssl_ctx=SSL_CTX_new(SSLv23_server_method(
{
perror(SSL_CTX_new:);
}
Error I get:
SSL_CTX_new:: No such file or directory
You should
So, my question is, is there any reason why Daniel Brahneborg's patch
from 2003 wasn't applied? For reference, the patch (against 0.9.8c) is
below.
I assume you didn't forget to compile OpenSSL with
-DPURIFY before testing it with Valgrind, right? That
typically resolves most issues with
Hello,
I am new to openssl and I have tried to use the bignumber library
like below,
--
unsigned char* hex = 00;
BIGNUM* bn;
unsigned char* bytes;
int i;
bn = BN_new();
BN_hex2bn(bn, hex);
bytes = (unsigned char*) malloc(16);
char* hex = ;
BN_hex2bn(bignum, hex);
buffer = (char*)malloc(2);
BN_bn2bin(bignum, buffer);
wont' do the same thing as
buffer = (char*) malloc(2);
memset(buffer, 0, 2);
No, how would it? How does BN_bn2bin() know that
buffer is 2 bytes? There's no way for the function
to know
This is a preliminary report, I've not yet completed the research
into why this issue is occurring
I appear to have found a pretty significant regression between
OpenSSL 0.9.7l and OpenSSL 0.9.7m, at least on win32. Within
an SSL_connect(), I'm getting a crash, but it tends to be
after an
Well that didnt fly either. Has anybody built an
openssl app using VS2005 and ported it to a XP machine
that does not have openssl installed? If they be so
kind and shed some light onto this dark area that
would be appreciated because I thought this would be
easy which it is providing you do
Following the Windows build instructions in the OpenSSL FIPS Users Guide
(using MinGW and MSYS) results in OpenSSL libraries that may crash if
used in a multithreaded program.
Are you then using VC++ to generate the final DLL which you use
with your multithreaded application?
If so, do you
Anyone got a better idea?
Use the Microsoft compiler?
If you really want to be FIPS compliant why are you using mingw?
Some auditor might ask the same question.
Umm, if you've never built the FIPS binary on windows, it _requires_
you use MSYS/MinGW to generate the fipscanister, then you can
If you really want to be FIPS compliant why are you using mingw?
Some auditor might ask the same question.
In which way is using a closed source compiler where nobody knows
which backdoors it might add to the validated code better than
to use a wrapper executable for gcc? AFAIK it's the source
Joel Christner wrote:
Anyone?
Please excuse the newbie question, I was wondering if anyone had any
links or recommendations on reference material for using
blowfish.h? I've gone through the man pages which don't provide a
lot of detail, I was hoping for something that was more of a
Ideally (in my view anyway), we'd have some sort of announcement as to
where the FIPS code is being evaluated, then have a couple of weeks to
a month to hammer at it before it's sent off to the (much more costly,
and much more involved) CMVP validation.
I like the idea of a peer review
Brad, sorry, I didn't mean to come across as negative. The point I was
trying to make is that once a validation starts I can't afford to delay
it to deal with problems that are discovered in the already frozen
baseline, unless those problems are critical to the requirements of the
paying
Ok, guys, let me point out a harsh reality here. As noted in an earlier
comment, FIPS 140-2 validation doesn't mesh all that well with the open
source world.
Validation testing is expensive. The direct costs alone -- to pay the
test lab, for CMVP fees, for hardware and/or test lab travel
However, I
am honestly annoyed that there have been two validation cycles past
without (still!) a working FIPS-validated module for the Intel Mac.
What is this statement based on? Intel Mac support was added and tested
prior second submission. Though it's limited to 32 bits... Because
$ cvs -d/Users/kylehamilton/workspace/openssl-repo co openssl
$ cd openssl
$ cvs update -t FIPS_098_TEST_8
I'm going to assume that I need to follow the CONFIG.FIPS file, and use:
$ ./config fipscanisterbuild
'make' completes (Mac OS X 10.4.11 Intel).
'make test' completes. It
I have dowloaded Openssl 9.8g. I want compile the code in Microsoft
VisualC++ (VC6 or VS2005).
I am not able to find the project workspace in the downloaded files.
Please help me how to get it and also steps to follow in compiling.
Can we get ssleay32.lib and libeay32.lib directly without
void foo(void)
{
static int *my_errno=NULL;
if(my_errno==NULL) my_errno=errno;
// code that uses 'my_errno' as if it were 'errno'
}
No, this is not legal code under the POSIX standard at all.
Since this code is single-threaded only, what POSIX standard are you talking
about? The pthreads
and is written in C++.
I doubt that will happen. You'd alienate a lot of developers
out there and lose support of some systems, especially embedded
systems, which may not even have a C++ compiler. I don't think
there is any justification for C++.
-Brad
This is a duplicate of #1629
You might want to look at that tracker for an explanation.
I've personally duplicated this with OpenSSL 0.9.8g (w/tls tickets)
connecting to OpenSSL 0.9.7d (the current 0.9.7 release is
fine).
-Brad
Kurt Roeckx via RT wrote:
Hi,
In Debian we've enabled the TLS
I'd have to look at the context of what is actually happening
here but it looks like by intention, filespec1 should be allowed
to be NULL as it can be retrieved from dso, but I see no additional
sanity checks for filespec2, most likely, I would assume, the
filespec1 reference on line 397 should
My question is, is this something we can get fixed ourselves, I doubt it, as
changing anything will invalidate the FIPS validation. Or is this something
that has not been 'done' by the FIPS development team.
I'm afraid I have to convince my management that if it can't be done, why
that is.
I know
We’re implementing our own web-server intended to run on Win32
platform and using OpenSSL for TLS/SSL support. We’re obliged
to be FIPS-certified and we’re using OpenSSL 0.9.7 with FIPS
module for these purposes. Recently, we were requested to support
amd64 platform. I’ve tried to build
Version: OpenSSL FIPS 1.1.2 (from openssl-fips-1.1.2.tar.gz)
System: Intel Mac (OS version 10.4.11, dual processors)
Synopsis: build failed creating openssl file, fingerprint mismatch.
This is a known issue. You should be testing the 1.2.0 FIPS snapshot
as it is the next release and is based
2) If I've to add crypto accelerator support in openssl for linux then which is better approach
a) I directly write an engine
b) I use engine written for OCF and I just write my module for OCF in
kernel
From my limited experience with OCF I remember a _significant_
performance
I've played around with various
AES_cfb*_encrypt calls (with a loop that does 16 bytes at a time).
I can't get it to work...is there a way to a simple way to put the above
command line in C code (where I can supply input/output arrays?)
You should be on openssl-users, this is not an
Are there any plans to get OpenSSL building on the PS3?
I've considered trying to hand edit the makefiles, and figured I'd send
an email out first.
Can I ask what is _not_ working? There are quite a few
linux distros which support PS3 and they all include OpenSSL
already, so it is known to
Second, it doesn't describe which version of the OpenSSL API that the
newly-validated module supports. (in this case, it supports v0.9.8
(and requires 0.9.8i onward), but I dunno about 0.9.7?) Providing
compatibility with a version bump in the API is significant enough
that it should be called
Finally, I'm getting X509_V_ERR_CERT_SIGNATURE_FAILURE errors when in
fips mode during SSL negotiation, but the same binary, simply telling
it via a config setting not to enter fips mode, works fine. This
is to ssl3.vitalps.net:5003, specifically, but I don't have any reason
to believe other
The problem is the root CA uses MD2WithRSAEncryption as a
signature algorithm
and that is prohibited in FIPS mode.
I'm pretty ignorant when it comes to FIPS, is this a limitation of the
FIPS requirements itself or a limitation of OpenSSL's FIPS validation?
The former. FIPS does not allow the
fips/Makefile:126 : fips_standalone_sha1 needs to be built
with $(EX_LIBS) otherwise may give an error about missing
socket/nsl calls on some systems (Solaris, SCO)
Diff is against :
ftp://openssl.org/snapshot/openssl-0.9.8-stable-SNAP-20081123.tar.gz
# fips/Makefile:126 : fips_standalone_sha1
Looks like the LIBEAY32.def file got updated for the exports but the
JPAKE stuff isn't being compiled in. I didn't specify JPAKE to be
specifically built so maybe it's just an error with the def generation.
I'm not familiar enough with the OpenSSL build system to really know
where to look...
I
When running the tx509 test (with no args), it ends up generating
a SIGILL. GDB says the instruction is 'ud2a' which I believe is the
guaranteed illegal opcode on ia32. Not sure why it's being generated
though. This occurs on both FreeBSD 7 x86 and x64. FreeBSD 5 and 6
do not exhibit this
release, then try to
use the 20081123 snapshot and link the fips canister to that and
see if the tests pass.
-Brad
Brad House wrote:
When running the tx509 test (with no args), it ends up generating
a SIGILL. GDB says the instruction is 'ud2a' which I believe is the
guaranteed illegal opcode on ia32
Ok, the tests passed when linking the fipscanister
against the 0.9.8-stable snap 20081123 ...
-Brad
Brad House wrote:
I might have jumped the gun here. I'm getting that failure
on OpenSSL 0.9.8e (no fips), which I think was the branch
point for the FIPS v1.2, but not OpenSSL 0.9.8f (no fips
Well, it's still not as finished as I'd like but since I'll be out of
town and offline until next week I'm releasing the OpenSSL FIPS Object
Module v1.2 User Guide document:
http://www.openssl.org/docs/fips/UserGuide-1.2-RC1.pdf. It's still
labeled as a draft as I anticipate revisions over
Section 5.3.1, I'd probably mention that you can pass 'fipsld' as the
CC env for configure scripts as well, since many projects use
autoconf/automake.
I'm not sure that CC is the appropriate place for fipsld. Maybe LD,
but CC has other uses.
Well, that's an arguable point (not that I'm
Jeffrey Altman wrote:
Steve Marquess wrote:
Well, it's still not as finished as I'd like but since I'll be out of
town and offline until next week I'm releasing the OpenSSL FIPS Object
Module v1.2 User Guide document:
http://www.openssl.org/docs/fips/UserGuide-1.2-RC1.pdf. It's still
labeled
I Compiled the openssl-0.9.8d with the following options..
$ ./config shared no-threads -fPIC no-sse2
on FreeBSD 7.0
When I try to generate private key using,
$ ./openssl genrsa -des3 -out mykey.pem
It is saying Illegal Instruction.
But FreeBSD 7.0 came with default openssl version
Does the release of 0.9.8j also include the FIPS module support?
(i.e., is this a bug-fix only release, or does this include what you
have been working on for the past few months as well?)
The actual 0.9.8j release announcement stated:
This is the first full release of OpenSSL that can link
What I've narrowed it down to is this ...
Command run:
./openssl s_client -no_ssl2 -connect igusprodb.globalpay.com:443
Tested versions:
OpenSSL 0.9.8h - good
OpenSSL 0.9.8i - good
OpenSSL 0.9.8j-stable-SNAP-20081123 - good
OpenSSL 0.9.8j release - bad
Without the -no_ssl2, the release 0.9.8j
What I've narrowed it down to is this ...
Command run:
./openssl s_client -no_ssl2 -connect igusprodb.globalpay.com:443
Tested versions:
OpenSSL 0.9.8h - good
OpenSSL 0.9.8i - good
OpenSSL 0.9.8j-stable-SNAP-20081123 - good
OpenSSL 0.9.8j release - bad
Without the -no_ssl2, the release 0.9.8j
On Wednesday, 14. January 2009 11:29:07 Dr. Stephen Henson wrote:
# openssl s_client -ssl3 -connect update.intranator.com:443
CONNECTED(0003)
31738:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake
failure:s3_pkt.c:1060:SSL alert number 40 31738:error:1409E0E5:SSL
On Wednesday, 14. January 2009 11:29:07 Dr. Stephen Henson wrote:
# openssl s_client -ssl3 -connect update.intranator.com:443
CONNECTED(0003)
31738:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake
failure:s3_pkt.c:1060:SSL alert number 40 31738:error:1409E0E5:SSL
Commenting below.
For better clarification, I have attached the trace of Valgrind on the
Pastebin:
http://pastebin.com/f1e222abd
Here is the last lines
1. ==3290== LEAK SUMMARY:
2. ==3290==definitely lost: 268 bytes in 1 blocks.
3. ==3290==indirectly lost: 66,807
I was trying to Generate DLL for SocketCommunication with Open SSL.
For This I downloaded OpenSSL0.9.8k and tried to install in my system.
I followed the steps in Readme File and found that we need to install
1) need Perl for Win32.
2) and one of the following C compilers:
* Visual C++
*
Adkins, Allan (Cont, ARL/CISD) wrote:
Classification: _* UNCLASSIFIED*_**
Caveats: NONE
Will there be a fips version that addresses recent vulnerabilities soon?
Please re-read section 4.2.3 of the OpenSSL FIPS 1.2 User Guide.
Here's a direct link if you need it:
I think it was asked that we report successful builds as well as
failures. Here's my list of successful builds so far. I do have
some failures, but I'll provide those in another e-mail after I
figure out some work-arounds or patches.
--
Linux (Gentoo) i386 glibc 2.3, gcc 3.4.6, binutils 2.18,
I've attached a trivial patch to correct the build of OpenSSL
on SCO OpenServer 5. SCO 5 doesn't define socklen_t, this
patch works around that.
Here's some basic system info:
SCO OpenServer 5.0.6, gcc 3.3.1, gas 2.14, native linker, gnu make 3.81:
OpenSSL 1.0.0-beta2 21 Apr 2009
built on: Wed
Tim Rice wrote:
On Wed, 22 Apr 2009, Brad House wrote:
I've attached a trivial patch to correct the build of OpenSSL
on SCO OpenServer 5. SCO 5 doesn't define socklen_t, this
patch works around that.
---
diff -ruN openssl-1.0.0-beta2.orig/crypto/bio/b_sock.c
openssl-1.0.0-beta2/crypto
I have been using libjingle (http://code.google.com/p/libjingle/) with
openssl on linux. I recently upgraded my openssl from 0.9.8g to 0.9.8j,
and suddenly my TLS negotiation stopped working. I reverted back to
0.9.8g, and it started working again.
Is there a particular change that might
For those of us who haven't bought xlc, here's a quick patch
for Configure to compile OpenSSL for 64bit using GCC on AIX5 ...
Passed 'make test' results fine ...
(attached patch)
-Brad
--- Configure 2005-08-02 06:59:42.0 -0400
+++ ../Configure2005-12-29 15:58:10.0
you're right, I only built it statically ...
Shared does infact fail, trying to figure out what all needs
patching...
-Brad
Andy Polyakov wrote:
--- Configure2005-08-02 06:59:42.0 -0400
+++ ../Configure2005-12-29 15:58:10.0 -0500
@@ -404,6 +404,7 @@
IBM's AIX.
In OpenSSL 0.9.7, you could successfully perform RSA decryption
without needing a seeded RNG (think systems like AIX, SCO, Solaris
which may not have /dev/urandom). In OpenSSL 0.9.8a,
RSA_private_decrypt() returns -1 unless the RNG is seeded. Is
there a particular reason this change has been
Actually, calling
RSA_blinding_off(rsa)
resolves the issue. Thanks for the hint!
-Brad
Nils Larsch wrote:
Brad House wrote:
In OpenSSL 0.9.7, you could successfully perform RSA decryption
without needing a seeded RNG (think systems like AIX, SCO, Solaris
which may not have /dev/urandom
Hi, I've been playing around with the FIPS stuff, and figured I'd
mention a few things I've run into ... they may be bugs, or just
user error ;)
1) I had to modify the 'fipsld' script that comes with the distribution
to work with autoconf/automake/libtool applications, since libtool
does
Ulf Möller wrote:
The dladdr() function used in DSO_pathbyaddr within
crypto/dso/dso_dlfcn.c is not a standard function, though
quite a few OSs appear to have it. Those that specifically
don't (that I've tested) are:
AIX 4.3.3+
AIX 5.1 (though 5.2/5.3 may have it, though it may be
Ran into 3 problems, all of which are addressed here:
1) dladdr() does not exist in AIX4 or AIX5.1, but the
DSO_pathbyaddr() function from crypto/dso/dso_dlfcn.c
is not called from anywhere so it's dead code...
Just #if'd it out.
2) The inline assembler in fips-1.0/fips_canister.c for
It is not only fips_canister.c which cannot be modified. *NOTHING* in the
fips-1.0 tarball can be modified without invalidating the certification. There
is a published hash for that tarball in the security policy and it is
effectively frozen.
The possibility of including minor
Steve Marquess wrote:
On Tue 2006-04-11 18:09, Brad House wrote:
-Original Message-
From: [EMAIL PROTECTED] on behalf of Brad House
Sent: Tue 2006-04-11 18:09
To: openssl-dev@openssl.org; [EMAIL PROTECTED]
Subject: Re: OpenSSL FIPS 1.0 AIX using GCC patches
It is not only
As for libz.so ... think it should be trying to load libz.dylib as that
is the only thing that will exist on the system (since MacOSX
differentiates between DSO's and Dynamic Libraries, but you can
still dlopen() a .dylib, just dlclose() won't actually do anything
as it will remain loaded in your
16458:error:25066067:DSO support routines:DLFCN_LOAD:could not load the
shared library:dso_dlfcn.c:162:filename(libz.so): dlopen(libz.so, 2):
^^^
great. why is openssl looking for libz.*so* on a _mac_ in the first place?
Because
% openssl engine gmp
10543:error:2506406A:DSO support routines:DLFCN_BIND_FUNC:could
not
bind to the requested symbol name:dso_dlfcn.c:261:symname(bind_engine):
dlsym(0x201070, bind_engine): symbol not found
10543:error:2506C06A:DSO support
Worked fine for me without making any of those manual modifications.
You just need to install the current Windows Server 2003 R2 x64 platform
SDK along with a current ActiveState Perl, then go to:
Start-All Programs-Microsoft Platform SDK for Windows Server 2003
R2-Open Build Environment
The more valid question I think would be where did you get the Security
Policy Version 1.1? As far as I know 1.1 has not completed validation
yet, therefore nothing has been released, or at least officially linked
on the oss-institute.org site (after-note, searching a bit, google does
turn up
I have an SSL session in which the client and server has negotiated for
cipherSuite SSL_RSA_WITH_RC4_128_MD5
compressionMethodzlib-compression
Now, is the zlib-compression applied before encryption or after ?
data - zlib-compression - encryption == decrypt -
The security advisory only has 3 security issues referenced within it,
though it mentions 4 security fixes. Is the fourth one the RSA
signature with modulus 3 forgery issue fixed in 0.9.8c and 0.9.7k?
No, look closer, the first one (ASN.1 Denial of Service Attacks [yes,
plural]), has two
I simply work around it by using gmake instead of the native make on
the relevant platforms.
Truthfully though, I'd like to see OpenSSL use something better than
the current kludge of build scripts, and would be willing to dedicate
time to it... Personally I'd prefer something truly
time to it... Personally I'd prefer something truly cross-platform like
CMake. It would actually allow a Windows x64 fips build (which is
cmake isn't exactly native on the platforms where I compile
OpenSSL. Currently OpenSSL builts out of the box on all of them
without having to install some
Also, please check to make sure that gcc is properly installed. Other
platforms seem to have the same type of problem when the system
headers aren't properly fixed up by the installation process.
SCO provides gcc as part of a package of precompiled GNU tools so I can
only assume it's
On Sun, Oct 08, 2006, The Havenard wrote:
Hi. I use OpenSSL in some of my applications and I noticed that
sometimes
(I could say less then 2% times I run it) it crashed without apparent
reason, but lately it happened ALWAYS, without any changes on the
program,
what's very strange. So I
Hi. I use OpenSSL in some of my applications and I noticed that sometimes
(I could say less then 2% times I run it) it crashed without apparent
reason, but lately it happened ALWAYS, without any changes on the
program,
what's very strange. So I decided to track this bug, and I almost found
I did have a question though. Is there any reason to define the
dynamic thread locking functions? There is a note stating:
Also, dynamic locks are currently not used internally by OpenSSL,
but may do so in the future.
Is this still accurate? If OpenSSL does start to use them internally,
Hi All,
When I compile fips-1.2 of the openssl-0.9.8m in hpux platform, I have
encounter some errors when bulding the
fips. I have traced the problem to the Makefile in fips dir.
snip
if [ -z $(HOSTCC) ] ; then \
$(CC) $(CFLAGS) -DFIPSCANISTER_O -o $@ sha/fips_standalone_sha1.c
Sounds like you want to look into the ocf-linux patchset.
http://ocf-linux.sourceforge.net/
That said, you should realize that even if you have a hardware
crypto accelerator, small encryption blocks will probably be
faster in pure userland due to the penalty of kernel/userland
context switches,
This patchset is against OpenSSL 1.0.1c.
It does 2 things very minor things.
First, it adds a linux-mipsel target to Configure.
Second, it fixes the MIPS perlasm, it appears as though at some point
AES_set_encrypt_key and AES_set_decrypt_key in the ASM needed to be
renamed to
It appears if you pass something like:
./Configure linux-mips --sysroot=/opt/uclibc
because the Configure script doesn't expect compiler options
to begin with 2 hyphens, it errors out.
The attached patch against OpenSSL 1.0.1c fixes that.
Thanks.
-Brad
diff -ruN openssl-1.0.1c.old/Configure
On 09/07/2012 11:55 AM, Brad House wrote:
This patchset is against OpenSSL 1.0.1c.
It does 2 things very minor things.
First, it adds a linux-mipsel target to Configure.
Second, it fixes the MIPS perlasm, it appears as though at some point
AES_set_encrypt_key and AES_set_decrypt_key
This patchset is against OpenSSL 1.0.1c.
It does 2 things very minor things.
First, it adds a linux-mipsel target to Configure.
Second, it fixes the MIPS perlasm, it appears as though at some point
AES_set_encrypt_key and AES_set_decrypt_key in the ASM needed to be
renamed to
Commenting below ...
This patchset is against OpenSSL 1.0.1c.
Whatever we will do, will apply to HEAD and optionally 1.0.2. 1.0.1 is closed
for new features, including new platforms,
and linux-generic32 is the one that serves MIPS there.
Ok, not a problem ... more about future support, I
SSL negotiation (where the device is the server) takes about 2s
as it currently stands, and that's with the current MIPS assembler
support in OpenSSL.
I was planning on running some actual benchmarks but hadn't gotten
around to it yet.
I've just made some commits and here is workflow. First
SSL negotiation (where the device is the server) takes about 2s
as it currently stands, and that's with the current MIPS assembler
support in OpenSSL.
I was planning on running some actual benchmarks but hadn't gotten
around to it yet.
I've just made some commits and here is workflow. First
I was expecting a bit better performance (in absolute terms),
Could you double-check one thing? Run 'mipsel-linux-objdump -d
crypto/sha/sha1-mips.o | grep ror | wc'. Do you get a lot of hits? This is to
double-check that -mips32r2 was in fact effective and passed down
_MIPS_ARCH_MIPS32R2
There is more code committed. Check-out or wait for *tomorrow*
openssl-SNAP-20120919 snapshot. There is SmartMIPS AES code (pass
-msmartmips to Configure) and Configure accepts double dash as compiler
options. Please double-check and optionally post performance for new AES
code.
Do I also need
There is more code committed. Check-out or wait for *tomorrow*
openssl-SNAP-20120919 snapshot. There is SmartMIPS AES code (pass
-msmartmips to Configure) and Configure accepts double dash as compiler
options. Please double-check and optionally post performance for new AES
code.
On a different
There is more code committed. Check-out or wait for *tomorrow*
openssl-SNAP-20120919 snapshot. There is SmartMIPS AES code (pass
-msmartmips to Configure) and Configure accepts double dash as compiler
options. Please double-check and optionally post performance for new AES
code.
Do I also need
There is more code committed. Check-out or wait for *tomorrow*
openssl-SNAP-20120919 snapshot. There is SmartMIPS AES code (pass
-msmartmips to Configure) and Configure accepts double dash as compiler
options. Please double-check and optionally post performance for new AES
code.
I've done some
./openssl-generic32 speed rsa1024 rsa2048
rsa 1024 bits 0.342000s 0.010615s 2.9 94.2
rsa 2048 bits 1.328750s 0.027632s 0.8 36.2
./openssl-mips32r2 speed rsa1024 rsa2048
rsa 1024 bits 0.128228s 0.008619s 7.8116.0
rsa 2048 bits 1.055000s 0.023870s 0.9 41.9
On a different note, thanks for the double dash fix for Configure. That
said, I have one more issue in relation to the way Configure handles
flags completely unrelated to MIPS...
On MacOSX, you have to target a specific SDK if you want to ensure
it targets the proper release of MacOSX. That
It appears there is a major regression with OpenSSL 1.0.1d over
1.0.1c. I've narrowed it down to setting a custom cipher
list I think as if I do not set a cipher list, the issue does
not occur.
I have reproduced the issue with the openssl s_server/s_client
command line utility. You can see my
On 02/06/2013 12:30 PM, Brad House wrote:
...snip...
I should also note that currently I am using
OpenSSL 1.0.1d-fips 5 Feb 2013
On an Intel(R) Core(TM) i7-3770S CPU @ 3.10GHz running Ubuntu 12.04 64bit
(so presumably I'm using AES-NI ... noticed changes to that in the
changelog).
I have
On 02/06/2013 01:37 PM, Dr. Stephen Henson wrote:
A possibility is the AESNI+SHA1 stitched code which is handled as a special
case. You'd only see that with AES+SHA1 ciphersuites on AES-NI supporting
processors.
DHE-RSA-CAMELLIA256-SHA also has the same issue. I'm thinking it may be
a -SHA
On 02/06/2013 02:14 PM, Dr. Stephen Henson wrote:
On Wed, Feb 06, 2013, Brad House wrote:
On 02/06/2013 01:37 PM, Dr. Stephen Henson wrote:
A possibility is the AESNI+SHA1 stitched code which is handled as a special
case. You'd only see that with AES+SHA1 ciphersuites on AES-NI supporting
On 02/06/2013 03:07 PM, Holger Weiß wrote:
* Dr. Stephen Henson st...@openssl.org [2013-02-06 20:14]:
On Wed, Feb 06, 2013, Brad House wrote:
DHE-RSA-CAMELLIA256-SHA also has the same issue. I'm thinking it may be
a -SHA issue as the only -SHA cipher I've gotten to work so far is RC4-SHA
On 02/06/2013 03:21 PM, Brad House wrote:
On 02/06/2013 03:07 PM, Holger Weiß wrote:
* Dr. Stephen Henson st...@openssl.org [2013-02-06 20:14]:
On Wed, Feb 06, 2013, Brad House wrote:
DHE-RSA-CAMELLIA256-SHA also has the same issue. I'm thinking it may be
a -SHA issue as the only -SHA cipher
On 02/07/2013 04:22 PM, Stephen Henson via RT wrote:
On Thu Feb 07 00:43:10 2013, steve wrote:
On Wed Feb 06 23:01:25 2013, bugs-...@moonlit-rail.com wrote:
I haven't had a chance (yet?) to bisect the code to find the culprit,
but I can take a stab at it if a developer doesn't know off the
1 - 100 of 115 matches
Mail list logo
