>> 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* tr
pto from OpenSSL instead of the kernel ?
>
> Regards.
>
>
>
>
> --
> View this message in context:
> http://openssl.6102.n7.nabble.com/openssl-users-FIPS-mode-restrictions-and-DES-tp57497p57541.html
> Sent from the OpenSSL - User mailing list archive at Nabble.com.
>
pto from OpenSSL instead of the kernel ?
>
> Regards.
>
>
>
>
> --
> View this message in context:
> http://openssl.6102.n7.nabble.com/openssl-users-FIPS-mode-restrictions-and-DES-tp57497p57541.html
> Sent from the OpenSSL - User mailing list archive at Nabble.com.
>
On 04/14/2015 09:42 AM, jonetsu wrote:
>
>
>> From: "Steve Marquess" 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 Leve
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 ope
> From: "Steve Marquess"
> 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 cryptographic
under FIPS. Does anyone have an
idea of the order of magnitude in performance loss this could be for IPSec,
to use crypto from OpenSSL instead of the kernel ?
Regards.
--
View this message in context:
http://openssl.6102.n7.nabble.com/openssl-users-FIPS-mode-restrictions-and-DES-tp57497p57541.
> 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
openssl.6102.n7.nabble.com/openssl-users-FIPS-mode-restrictions-and-DES-tp57497p57533.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
___
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 anyt
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
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)
a
> 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: https://m
- thanks.
Regards.
--
View this message in context:
http://openssl.6102.n7.nabble.com/openssl-users-FIPS-mode-restrictions-and-DES-tp57497p57527.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
___
openssl-users mailing list
To u
14 matches
Mail list logo
