Steve Marquess wrote:
Thor Lancelot Simon wrote:
On Thu, Sep 10, 2009 at 06:10:27PM +0200, Dr. Stephen Henson wrote:
On Wed, Sep 09, 2009, Thor Lancelot Simon wrote:
On Sat, Aug 29, 2009 at 05:34:04PM -0400, Steve Marquess wrote:
That this wasn't the obvious approach from the very
On Wed, Sep 09, 2009, Thor Lancelot Simon wrote:
On Sat, Aug 29, 2009 at 05:34:04PM -0400, Steve Marquess wrote:
That this wasn't the obvious approach from the very beginning speaks
worlds about the limitations of the ENGINE interface.
The actual story of why FIPS is the way it is is rather
On Thu, Sep 10, 2009 at 06:10:27PM +0200, Dr. Stephen Henson wrote:
On Wed, Sep 09, 2009, Thor Lancelot Simon wrote:
On Sat, Aug 29, 2009 at 05:34:04PM -0400, Steve Marquess wrote:
That this wasn't the obvious approach from the very beginning speaks
worlds about the limitations of the
On Sat, Aug 29, 2009 at 05:34:04PM -0400, Steve Marquess wrote:
Long term what we'd really like to do is create a truly independent and
separate FIPS mode algorithm implementation in the form of a FIPS mode
ENGINE. That way the associated source distribution would contain only
relevant
On Thu, 2009-08-27 at 13:39 +0200, Mark Phalan wrote:
...
A consequence of delivering two libcryptos is that one will have the
FIPS_* symbols and the other will not. This makes building applications
which support the FIPS mode problematic if they are to run with both
libcrypto versions.
Mark Phalan wrote:
...
As you noted the incorporation of fipscanister.o in a FIPS capable
OpenSSL displaces the corresponding FIPS allowed algorithms of the
latter. While we retain functional equivalence (goal 1 above) any
platform optimizations or other improvements of the newer
On Sat, 2009-08-29 at 17:34 -0400, Steve Marquess wrote:
Mark Phalan wrote: ...
Due to the way the FIPS Capable OpenSSL is built it ends up with
older implementations of ciphers (all the ones that fipscanister.o
implements). These cipher implementations are used regardless of
being
On Sun, 2009-08-30 at 09:13 -0700, Kyle Hamilton wrote:
You forgot:
./config fipscanisterbuild asm
Appendix A of the Security Policy (v1.2) lists the allowed command sets.
./config fipscanisterbuild asm isn't one of them.
The asm will be pulled in anyway as for solaris64-x86_64-gcc config
It goes without saying that any changes you have to make to the FIPS
module would be quite welcome if you passed them along upstream, along
with any information about the Priesthood of the CMVP that you're
dealing with which required the change, and why.
Then again, I don't know if there's an NDA
Mark Phalan wrote: ...
Due to the way the FIPS Capable OpenSSL is built it ends up with
older implementations of ciphers (all the ones that fipscanister.o
implements). These cipher implementations are used regardless of
being in FIPS mode or not. As the ciphers from fipscanister.o (FIPS
You forgot:
./config fipscanisterbuild asm
Since you're on an x86_64 platform, you can benefit a lot from the asm speedups.
-Kyle H
On Fri, Aug 28, 2009 at 2:48 AM, Mark Phalanmark.pha...@sun.com wrote:
On Thu, 2009-08-27 at 10:23 -0400, Steve Marquess wrote:
Mark Phalan wrote:
I've been
On Fri, 2009-08-28 at 10:36 -0400, Steve Marquess wrote:
Steve Marquess wrote:
Mark Phalan wrote: ...
Due to the way the FIPS Capable OpenSSL is built it ends up with
older implementations of ciphers (all the ones that fipscanister.o
implements). These cipher implementations are used
Steve Marquess wrote:
Mark Phalan wrote: ...
Due to the way the FIPS Capable OpenSSL is built it ends up with
older implementations of ciphers (all the ones that fipscanister.o
implements). These cipher implementations are used regardless of
being in FIPS mode or not.
Ummm, not so. Use
Mark Phalan wrote:
I've been working on getting a FIPS Capable OpenSSL into OpenSolaris.
Excellent, we designed the OpenSSL FIPS Object Module and the FIPS
capable OpenSSL to enable just this sort of support in vendor O/S
distros. One set of FIPS capable OpenSSL libraries shipped to all
14 matches
Mail list logo
