> From: "Lennart Sorensen" <[email protected]> > Date: 04/14/15 09:01
> But certainly libreswan does the actual packet encryption either with > xfrm or with klips, both in the kernel, which is where it belongs. Len, I see from the source that indeed all crypto is through XFRM. And we already mentioned that. But, the concern is about the FIPS validation. Making a parallel, it was termed recently that re-implementing glibc2's crytpto() for passwords using OpenSSL EVP methods would be a far cry better than submitting the glibc2 crypto source code for FIPS validation. Following the same approach for the crypto done in the kernel - eg. submitting the kernel's crypto code for FIPS validation would also be something costly in both time and money - I looked around and saw that Strongswan uses a plug-in architecture that allows replacing the kernel crypto by OpenSSL, specifically for the goal of FIPS validation. We all know that doing this crypto in user space has a (significant) performance penalty. OTOH, what if most if not all FIPS-certified systems are known to be slow ? What if no-one (apart perhaps for Red Hat) has put the kernel code through FIPS validation ? Do we want to go that way if there's a way to save a significant amount of time and money if possible ? _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
