[dm-crypt] EXTERNAL: Re: LUKS encryption standards
justin.bennett at lmco.com
Thu Mar 1 14:19:47 CET 2012
Again, thanks for taking the time to provide such a great answer. After I emailed I did more research and looking over some of the other certifications I would tend to agree with your points regarding the pointless nature of the FIPS certification.
As an aside, your email address is from Germany, is the government there hung up on pointless certifications like these? It would be so nice to see a move toward a more open approach where standards and specifications for cryptographic soundness are developed and then employed across the board, as opposed to the vague certifications that leave everything open for debate/discussion and invite many organizations to design and implement their own solutions to the problem.
From: dm-crypt-bounces at saout.de [mailto:dm-crypt-bounces at saout.de] On Behalf Of Sven Eschenberg
Sent: Wednesday, February 29, 2012 5:41 PM
To: dm-crypt at saout.de
Subject: Re: [dm-crypt] EXTERNAL: Re: LUKS encryption standards
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:
> 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,
> -----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
> 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
>> 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
>> know some specific information regarding the encryption standards that
>> met by LUKS. Specifically, the customer requires that the encryption
>> 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
>> validated cryptographic modules kept by the NIST, but I didn't have any
>> Any help you can offer would be greatly appreciated.
>> Thank you,
>> Justin Bennett
>> dm-crypt mailing list
>> dm-crypt at saout.de
> dm-crypt mailing list
> dm-crypt at saout.de
> dm-crypt mailing list
> dm-crypt at saout.de
dm-crypt mailing list
dm-crypt at saout.de
More information about the dm-crypt