Bug 346741

I may be interested in implementing this one. I have asked Clemens Fruhwirth if
he would be interested in integrating an NSS patch into the upstream source tree.

After looking at cryptsetup closer, the changes would be quite small. The only
use of libgcrypt is to hash passwords. This is done in lib/gcrypt.c. The code is
already modular, so writing a module that uses NSS should not be too difficult.
One would need to:

1. Modify configure.in to check for the existence of NSS
2. Implement lib/nss.c (get hashes, hash and free hashes functions)
3. Modify lib/Makefile.am to build lib/nss.c

On the other hand, if one uses the LUKS features of cryptsetup, as is being done
with most of the encrypted disk efforts in Fedora, then the hash option is not
used. So, it may make sense to simply disable the hash feature.

Created attachment 294501 [details]
Patch cryptsetup to use NSS for hashing

This patch is not yet complete, but demonstrates how cryptsetup could be
modified to use NSS. Currently, only the "sha1" hash is supported.

The upstream maintainer has expressed concern that using NSS will increase the
size of a statically-linked cryptsetup. I have sent him this patch and asked
for comments.

FWIW, cryptsetup is not linked statically in Fedora.

It much more complicated that attached patch.

Cryptsetup consists basically from two joined versions:

1) former cryptestup, where the Mater Key is generated like hash of passphrase
(this code uses libgcrypt for hash, the patch must support all hash algoritms provided by gcrypt, not olny subset)

2) LUKS version - with key store on disk.

LUKS implementeation uses PBKDF2 with SHA1 and some special anti-split algorithms based on these algorithms for storing randomly generated Master Key on device itself.

The SHA1 and PBKDF2 implementation is *hardcoded* in this part of source code.

Porting this to NSS is mostly equivalent to rewriting the whole LUKS part...

And LUKS part is more important - because this is used by anaconda during installation.

cryptsetup is widely used in boot process, requiring nss will probably break some systems (maybe not in Fedora, but such change must be through upstream).

(The main data encryption process runs through kernel cryptoAPI/dm-crypt, so I am talking here only about simple key obfuscation/management inside cryptsetup.)

--
Note about FIPS:
If the main reason for this change is FIPS validation, there is problem:

I think that mode 1) cannot be used in FIPS system anyway (master key is directly computed as hash from password).

LUKS uses hardcoded (not validated) SHA1 implementation so there can be problem because it is used in security related operation.

I guess switching this part of code to crypto library will be needed.

Anyway, I think we need lightweight crypto library here (note that cryptsetup is used in initrd, various small and rescue environments etc.)
NSS is too big for this purpose IMHO. Or when some lightweight NSS is available...

I think that libgcrypt is still better alternative here.

cryptstup now uses libgcrypt for all crypto operations and there is currently no plans to use NSS library.