On 03/31/2018 11:52 AM, Björn 'besser82' Esser wrote:
Am Dienstag, den 13.03.2018, 10:11 +0100 schrieb Nikos
Mavrogiannopoulos:
On Wed, 2017-11-08 at 18:08 +0100, Björn 'besser82' Esser wrote:
Anyways, before this can happen, there is still some work to be done
with libxcrypt, like adding a FIPS mode or FIPS compliance in a
different way.
I agree with Florian's comment on that.
To clarify, my comments were:
“
I think the best way to achieve that would be to contribute libxcrypt
(its interfaces and its peculiar build process) to some FIPS-validated
cryptographic libraries, so that the actual algorithms and FIPS mode
logic could be reused from that library.
Otherwise, unless you have experience dealing with FIPS requirements and
getting cryptographic libraries through validation, I strongly recommend
not to work on this at all. If and when we need this downstream, we can
contribute exactly what is needed according to the auditors back
upstream. Personally, I do not have a way to know what the requirements
would be in advance.
”
Well, my current plan for bringing FIPS compliance to libxcrypt would be
to use the Linux Kernel Userspace Crypto API [1], which provides a large
variety of hashing and crypto-algorithms using hardware capabilities, if
supported / available on the system (software implementations
otherwise).
We aren't convinced that FIPS compliance for libxcrypt would be
meaningful. With shadow passwords, password hashes do not cross a trust
boundary, so that part of libxcrypt does not perform any cryptographic
function.
Functions like encrypt_r, which have to be included for backwards
compatibility, are unlikely to be implementable using AF_ALG because few
kernels will have built-in single DES support. The AF_ALG interface of
course uses file descriptors, so failures are a possibility, and
functions like encrypt_r cannot report failure. We could terminate the
process, but combined with the potential lack of a kernel implementation
and the existence of applications which have not yet migrated their data
away from single DES, I'm not sure if that's a good idea.
Thanks,
Florian
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
