FIPS mode restrictions and DES

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 13/04/2015 18:48, Steve Marquess wrote:
> On 04/13/2015 12:14 PM, Jakob Bohm wrote:
>> On 13/04/2015 17:48, Salz, Rich wrote:
>>>> In other words, is the only
>>>> practical and viable option regarding this to re-implement crypt()
>>>> using EVP
>>>> methods ?  - thanks.
>>> Yes.  That would be so much easier than anything you can imagine.
>> Yes, the only thing easier would be if someone (maybe Red Hat)
>> already has a FIPS validatedopen source implementation of
>> crypt().
> And even if Red Hat does, you would be limited to using the specific
> commercial versions of RHEL that included that specific validated binary
> module.
>
> With the very unique exception of the OpenSSL FIPS Object Module, there
> are no FIPS 140-2 validated cryptographic modules that can be obtained
> in source form and compiled by the end user. The fact that Red Hat (or
> whomever) has taken open source code and obtained a FIPS 140-2
> validation of binaries generated from that code does you no good unless
> you have those specific binaries, which is to say you're a commercial
> customer paying for a commercial license from that vendor.
>
> Then, even for the OpenSSL FIPS module the validation imposes some
> pretty perverse constraints (from the usual software engineering
> perspective). You have to start with a snail-mailed CD, you have to
> build the binary module in a very special way that will conflict with
> whatever configuration management you use, etc.; you have to treat it
> differently that all the other software components of your product. FIPS
> 140-2 is the tail that wags the dog.
>
> -Steve M.
Of cause.

One point is that if this is a delivery for someone
subject to the FIPS-only procurementrequirement
imposed on various US Government related entities,
then whatever OS theyuse, MUST (by that requirement)
have already passed this for its password handling.

This provides a baseline of already validated stuff
on which other contractors can thenbuild, with
reasonable care to the (bureaucratic) FIPS
requirements.

So if the OPs customer is already using/requiring a
specificLinux/BSD/Solaris/etc. distribution, and
that distributioncontains a FIPS 140-2 validated
crypt() function for its loginprocessing, then
the OP could reuse that.  Red Hat is anexample
here.

Another possibility is that Red Hat or some other
open source supplier to the US government has
already reimplemented crypt() in terms of some other
FIPS-validated piece of software, such as the OpenSSL
FIPS module, with that crypt() reimplementation
being outside the cryptographic boundary and thus
reusable on other "platforms" with the same FIPS
module.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux