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:
