One point is that if this is a delivery for someone
subject to the FIPS-only procurementrequirement
imposed on various US Government related entities,
then whatever OS theyuse, MUST (by that requirement)
have already passed this for its password handling.
This is *technically* true, in the
From: Steve Marquess marqu...@openssl.com
Date: 04/14/15 09:31
and note that of the 101 platforms (OEs) appearing there, most of
those operating systems are neither CC certified nor have any other FIPS
140-2 validated crypto. Keep in mind that at Level 1 the validation
applies to the
On 04/13/2015 01:30 PM, Jakob Bohm wrote:
..
With the very unique exception of the OpenSSL FIPS Object Module, there
are no FIPS 140-2 validated cryptographic modules that can be obtained
in source form and compiled by the end user. The fact that Red Hat (or
whomever) has taken open source
On 04/14/2015 09:42 AM, jonetsu wrote:
From: Steve Marquess marqu...@openssl.com Date: 04/14/15 09:31
and note that of the 101 platforms (OEs) appearing there, most
of those operating systems are neither CC certified nor have any
other FIPS 140-2 validated crypto. Keep in mind that at
Two things to consider with IPSec: key exchange mechanisms as provided by
packages like StrongSwan, and the actual encryption/authentication of
packets that is typically being done by the kernel stack and I believe is
based on the Kernel Crypto API. So I believe to do IPSec you do need both
crypto
Two things to consider with IPSec: key exchange mechanisms as provided by
packages like StrongSwan, and the actual encryption/authentication of
packets that is typically being done by the kernel stack and I believe is
based on the Kernel Crypto API. So I believe to do IPSec you do need both
crypto
Salz, Rich wrote
As the old joke goes, if you have to ask, you can't afford it.
Well, exploration can be free. I noticed that Strongswan uses a plug-in
architecture for crypto that seemingly allows the use of OpenSSL instead of
the kernel for crypto operations, for use under FIPS. Does anyone
Thanks for all the comments, they're much appreciated. It is a Debian
system, so there is no Red Hat FIPS validation (or SuSE which also has one I
think) or validated components that can be used.
If I may, I'd like to ask about including the Linux kernel in the
validation. Now, including glibc2
If I may, I'd like to ask about including the Linux kernel in the validation.
As the old joke goes, if you have to ask, you can't afford it.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
On 13/04/2015 18:48, Steve Marquess wrote:
On 04/13/2015 12:14 PM, Jakob Bohm wrote:
On 13/04/2015 17:48, Salz, Rich wrote:
In other words, is the only
practical and viable option regarding this to re-implement crypt()
using EVP
methods ? - thanks.
Yes. That would be so much easier than
On 04/13/2015 12:14 PM, Jakob Bohm wrote:
On 13/04/2015 17:48, Salz, Rich wrote:
In other words, is the only
practical and viable option regarding this to re-implement crypt()
using EVP
methods ? - thanks.
Yes. That would be so much easier than anything you can imagine.
Yes, the only
On 13/04/2015 17:48, Salz, Rich wrote:
In other words, is the only
practical and viable option regarding this to re-implement crypt() using EVP
methods ? - thanks.
Yes. That would be so much easier than anything you can imagine.
Yes, the only thing easier would be if someone (maybe Red Hat)
Thanks for the comments - much appreciated.
The following question might be on the naive side of things, but then I'm
all new to this. Since crypt() in glibc2 supports SHA-256 and SHA-512 for
password, and assuming that these two are FIPS compatible, what would be the
(financial) overhead of
In other words, is the only
practical and viable option regarding this to re-implement crypt() using EVP
methods ? - thanks.
Yes. That would be so much easier than anything you can imagine.
___
openssl-users mailing list
To unsubscribe:
14 matches
Mail list logo
