Bug 346741 - Port cryptsetup-luks to use NSS library for cryptography
Summary: Port cryptsetup-luks to use NSS library for cryptography
Alias: None
Product: Fedora
Classification: Fedora
Component: cryptsetup-luks
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Milan Broz
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: CryptoConsolidation
TreeView+ depends on / blocked
Reported: 2007-10-23 10:17 UTC by Peter Vrabec
Modified: 2013-03-01 04:05 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
: 483570 (view as bug list)
Last Closed: 2009-09-18 10:02:44 UTC
Type: ---

Attachments (Terms of Use)
Patch cryptsetup to use NSS for hashing (5.21 KB, patch)
2008-02-10 18:21 UTC, W. Michael Petullo
no flags Details | Diff

Description Peter Vrabec 2007-10-23 10:17:19 UTC
cryptsetup-luks should be ported to use NSS library for cryptography.
See the tracking bug for details and links on how it could be done.

Comment 1 W. Michael Petullo 2008-01-31 10:03:09 UTC
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.

Comment 2 W. Michael Petullo 2008-02-03 19:11:38 UTC
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.

Comment 3 W. Michael Petullo 2008-02-10 18:21:39 UTC
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.

Comment 4 Till Maas 2008-03-03 22:09:50 UTC
FWIW, cryptsetup is not linked statically in Fedora.

Comment 5 Milan Broz 2009-01-12 11:39:02 UTC
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.

Comment 6 Milan Broz 2009-09-18 10:02:44 UTC
cryptstup now uses libgcrypt for all crypto operations and there is currently no plans to use NSS library.

Note You need to log in before you can comment on or make changes to this bug.