[dm-crypt] EXTERNAL: Re: LUKS encryption standards

Sven Eschenberg sven at whgl.uni-frankfurt.de
Wed Feb 29 23:40:38 CET 2012

Hi Justin,

If RHEL gets a FIPS Certification, the certificate will explicitly name
the mode of operation etc.

If you look at some of the certificates/validations (There is one for an
F-Prot Kernel Module or something like that which I looked at) there will
be listed, which hash methods/functions etc. took place in the
certification process and which didn't.

>From a plain technical POV (I only briefly looked at the FIPS-140 docs)
you'd have to make sure to use SHA as hashing, and AES (or possibly 3DES
if I saw it right) as cipher. Most of the docs on allowed functions refer
to other resources, so there would be some reading up to clarify this. I
could not find (as example) any indication on the desired mode of
operation that needs to be chosen, maybe FIPS really leaves this question

What I am trying to say: dm-crypt (using the provided modules) can provide
the necessary cipher, hashing, HMAC functions that are acceptable. Same
holds probably true for Mode of Operation. Oh and the RNG source can be
chosen too, of course, thus it is easy to use any acceptable (P)RNG from

Now from a security point of view: FIPS is not a standard, it is a
certification and revenue program. Basicly certain ciphers etc. need to be
supported (and none else when if FIPS mode) then some tests are conducted
and the module gets certified ... and what exactly does this prove? The
certification takes place at a certain point in time, everything after
that point in time is not covered, from what I read.

Since it's the very nature of OSS, that everyone can change and thus
tamper it, it is hard to get certified, then again, certified products
currently listed can be easily tampered with (esp. at the manufacturer)
and they would still be FIPS certified, and the whole (specific)
certification process (for a certain module) and the product's (tech.)
documenatation is not readily available for peer review...

I could not find any signatures in the certificate/validation document for
the module (in question) to check that no one tampered with it, since it
was 'certified'. That's just one of several scenarios that seem to be
neglected by the whole procedure.

Just a sidenote, why you might be lucky with a commercial distribution
like RHEL getting certified and why it is (IMHO) pointless afterall.



On Wed, February 29, 2012 20:51, Bennett, Justin wrote:
> Sven,
> Understood. The physical and key mgmt portions of the FIPS-140-2 are taken
> care of in our existing implementation, I am strictly looking for a
> comparable encryption module that I can use in place of the product we had
> been using.
> That said, if I install RHEL 5.5 and choose to encrypt the disk, am I
> doing everything necessary or is there more setup that needs to be done to
> make sure that I am using the appropriate encryption methodologies? The
> previous response from Milan on this issue seemed to indicate that the
> module included in RHEL 5 was not FIPS-140-2 compliant but the one
> included in RHEL 6 is...
> Thank you very much for your help,
> Justin
> -----Original Message-----
> From: dm-crypt-bounces at saout.de [mailto:dm-crypt-bounces at saout.de] On
> Behalf Of Sven Eschenberg
> Sent: Wednesday, February 29, 2012 2:09 PM
> To: dm-crypt at saout.de
> Subject: EXTERNAL: Re: [dm-crypt] LUKS encryption standards
> Hi there,
> From a technical POV LUKS easily can achieve everything demanded by
> FIPS-140-2 for the technical stuff.
> That being said:
> One Major thing about 140-2 considers physical device security (tampering
> detection) which naturally is outside of LUKS' scope. Further, you'D
> probably need a certification, to really conform to FIPS-140-2.
> The Key management Part etc. is (again) completely outside of LUKS' scope,
> it's a question fo procedure.
> Concerning the actual encryption algorithm, Hashign Methods etc. LUKS can
> achieve everything FIPS-140-2 demands, as long as you choose wisely.
> So, in general, everything from FIPS-140-2 that is limited to the area of
> implemenation (software), LUKS can generally achieve, but that's just a
> rather small part of what your customer is asking for, as far as I can
> tell.
> Regards
> -Sven
> On Wed, February 29, 2012 17:23, Bennett, Justin wrote:
>> Hello all,
>> At my work, we have a requirement from our customer to provide total
>> hard
>> drive encryption on pieces of our system that are considered mobile
>> (laptops, for instance).  Previously, we have been using a commercial
>> product to achieve this, but that product has since been discontinued in
>> favor of a hardware based product that the company is now using.
>> I'd like to use the LUKS-based encryption that is available during the
>> installation of RHEL 5 (the OS we'll be using going forward) but I need
>> to
>> know some specific information regarding the encryption standards that
>> are
>> met by LUKS.  Specifically, the customer requires that the encryption
>> meet
>> the standards set forth by the United States Dept. of Commerce in
>> FIPS-140-2 (http://en.wikipedia.org/wiki/FIPS_140-2).
>> I'm wondering if someone can tell me whether the current cryptsetup or
>> dm-crypt offerings support this or not.  I tried looking through a list
>> of
>> validated cryptographic modules kept by the NIST, but I didn't have any
>> luck.
>> Any help you can offer would be greatly appreciated.
>> Thank you,
>> Justin Bennett
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt at saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
> _______________________________________________
> dm-crypt mailing list
> dm-crypt at saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> _______________________________________________
> dm-crypt mailing list
> dm-crypt at saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

More information about the dm-crypt mailing list