Posted
by
Cliff
on Tuesday April 18, 2006 @06:45PM
from the peer-review-or-third-party-approved dept.

j_crane asks: "Our company is looking for disk encryption software that runs on Windows XP/2003 and Linux. There are hundreds of commercial disk encryption programs (most are Windows-only though). Some of them are FIPS-validated by the US NIST, but none of these are open-source. On the other hand, there is an excellent open-source on-the-fly disk encryption software, called TrueCrypt, for Windows and Linux (the program even provides plausible deniability), but it does not have a FIPS-validation. Which would you prefer -- open source or FIPS-validated -- and why?"

While many of the NIST approved ciphers are "open", I would still completely trust the Open Source application. Look at the Skipjack algorithim produced by the NSA. It was flawless until about a month after it was released openly. In the realm of cryptography, a strong Open Source solution is very trustworthy.

Besides, who is more concerned about their privacy being breached - an open source community or the NIST?

It's true that, with Closed Source, you can never be sure. That doesn't mean, however, that Open Source is guaranteed to be secure.There are not only crypto algorithms but also many details surrounding an implementation that are equally important.

as far as I know the law in England (although it was a few years since I read this and then it was in an old book - they were talking about the storage capacity of hard drives being measured in kilobytes or megabytes) anywho, I seem to remember it saying that it was illegal to use an encryption or send an encrypted e-mail without providing the authorites with a copy of the key... I don't know if this is the law now or what it meant by having to provide them with it in advance or just if they asked... still,

The Regulation of Investigatory Powers Act (2000) was set to make all legitimate uses of encrytion have a third party store a backup of the key in escrow. That part of the law, to my knowledge, got scrubbed before it hit the statute books.

So I think that answers your question. But why? Because it's open source. I don't trust anything that isn't, and not everything that is... But it's highly used, which suggests that it's highly scrutinized.

I agree to a point, but I think that the overall decision about FIPS vs. OSS should be based on your requirements. If you're doing business with the US federal government, for instance, there may well be a strict requirement to use something that is FIPS certified. If you're just doing a small in-house project for a start-up, OTOH, you're probably better off using TruCrypt.In my mind, it comes down to the following tradeoff:-If you need to know that your data is truly and safely encrypted, use FIPS. The

Just becaue it is opensource and not validated should not mean you can't trust it. First, you can do a review if you are worried about it and make sure its implementation is worthy. With that said, truecrypt has a lot of eyes on it and I do believe it is a safe choice. The encryption ciphers used are all industry standard and have withstood the test of time, so they are better choices than any closed source cipher would be. I have never used a closed source encryption product so I am not sure what they use

But as a company, I can advertise FIPS compliance as proof that I care about your data. And if it's insecure and unstable, I can at least fall back on the "But it's FIPS compliant" and save a few karma points.

But I would have no qualms about going Open Source at every opportunity. The whole concept has proven itself so utterly and completely superior that you really are shorting yourself for not seriously considering Open Source products. In the event that

I wouldn't necessarily trust either.Standards validation is good -- provided that you understand what the standard signifies, and the standard is in your judgement a good one for what you want to do. Vendors sometimes treat standard certification like magic pixie dust, or something you can measure by weight.

If this is important, I would read the relevant standard; if the standard everything that is sufficient to your needs, then I'd go with a certified product.

Is your company required to use encryption that is FIPS validated? (HIPAA, classified stuff, etc)If not, you should evaluate the costs of the commercial alternatives versus TrueCrypt. To the best of my knowledge, TrueCrypt has all of the features of commercial programs. They all basically use the same algorithm anyhow.

Since all of these products are merely ways to get the files into and out of an encrypted blob, the key for FIPS acceptance (should you ever decide to seek it) would be the algorithm used.Also, what levels of FIPS compliance are these all stating they have? There is low, medium, and high - if it's low or medium you could basically put your own FIPS OK over it that would satisfy auditors (it's just a question of outlininy policy around use of the products) where high would be much harder.

In many instances this makes it easier for a cryptoanalyist to break. Encrypting encrypted data can lead to instances where you can subtract sets and figure out how it was converted, granted modern cryptology avoids this, mostly.

I was also advised by a professional Cryptologist who works for BAE that you shouldn't use two different ciphers on the same drive when doing entire disk encryption. I was planning on using Twofish for my swap and Serpent for my root but was strongly advised against it.

Uh, I think you misunderstand. I think it's more of you should avoid encrypting the _same_ data with different ciphers, or different keys.

Whereas the OP is talking about encrypting already encrypted data.

If you are using decent[1] ciphers encrypting something that's encrypted is unlikely to make it easier to decrypt. Otherwise cryptologists would be running stuff through other ciphers all the time, just to make stuff easier to decrypt, doh.

Double encrypting data with different cyphers and different keys gives you the security of the stronger of the two algorithms plus a percentage (from 0 to 100%) of the security of the weaker algorithm, depending on the mathematical interactions of the two cyphers.If you get decreased security from double encrypting with different keys, the algorithm is broken, and you have to redefine the strength of the cypher to take that into account, and everything remains true.

I think it goes without saying that you should use a different key on each volume when doing this. After all, you don't want anyone to brute-force the outer volume and be able to use the same key to open the inner volume - especially if the outer volume happens to use the weaker algorithm.

Open Source doesn't even enter our spectrum at the moment; I'm dealing with a client who's got a pure Microsoft shop (private bank) and who can't muster people to "play around" with things; they need to know that they can call a vendor and have them figure it out if they have a problem. Their support guys just don't have the time and/or clue to futz around with something if it breaks.

Also, depending on their regulatory status, national laws, whatever, they may be required to present some sort of certification for various software components if audited. Thus it wouldn't matter if open source or not--rather, "certified or not". Whether or not the certification actually means anything is irrelevant. It'd be a case of you-know-and-I-know-but-do-they-know?

That's not to say I wouldn't do open source--In a larger organization, one with more tolerance in terms of resources and clue, or one with a different end-user profile, I wouldn't be so concerned with implementing something, such as TrueCrypt, where I know it's a quality product and wouldn't be under such pressure to justify a decision to management and users (these guys are private client advisors, and there is _very_ little tolerance for any software screwups, and even less so if your ass isn't 100% covered.)

So, "it depends". What are your legal/regulatory/compliance requirements? What's your user profile? What resources/clue do you have at your disposal? What's your use case? What's your management (the people who have to sign off on a solution) like?

If any of these are in doubt, I'd start looking at things like Pointsec pretty quickly (don't know offhand if Utimaco works on Linux.)

Good cryptography can be important to a business, for the catastrophic case where a laptop is lost or stolen. I agree with the idea that open source cryptography allows more eyeballs-- in the long run, better security.But data integrity is probably more important on a daily basis. And in terms of risk assessment, you're probably more likely to suffer some kind of data corruption than to lose your laptop.

It's been my observation that commercial software tends to be more robust in cases where a bit has been

How concerned are you that this is safe and what are your resources? Something like TrueCrypt is tempting because of low price. However OSS isn't some magical security gaurentee. You don't know it's secure unless someone competent has looked at the code and verified it is. If you have people that are competent, then you can have them audit the code and make sure it's good. Otherwise, it's no different than CSS, you assume that the people who wrote it know what they are doing, but you haven't checked.

Certified softwares, someone else competent has checked for you. You can be as certian as is possible that there's not a problem.

Now maybe you don't care. You can be pretty sure TrueCrypt is good stuff. It's implementing public alogrithms that have been extensively evaulated, and people HAVE looked over the code and found nothing to worry about so far. However that's not the same as trained, competent people doing a specific, intensive audit.

So if you can do the audit in house, and trust your people more, go OSS. If you can't and you are concerned that one hasn't been done, go FIPS.

It's interesting that this FIPS certification you speak of hasn't certified any OSS solutions. Funny, that! I don't trust that as far as I can throw it.I'd go with the OSS solution any day. If you don't trust OSS you can grab the code, review it and compile it yourself to ensure that it is trustworthy. You can't do that with some black box certified by a government (read: NSA) funded agency that may or may not be certifying that their back-doors are functional! *adjusts tin-foil hat*

NSS (the crypto library used in Firefox, and some Red Hat and Sun products) is open-source, and FIPS-140 level 2 certified:
http://www.mozilla.org/projects/security/pki/nss/f ips/ [mozilla.org]
If you implement an application such as disk encryption using NSS for crypto, you'd be able to claim that it was FIPS 140 compliant. But, as far as I know, no such application currently exists.
FIPS 140 is a US goverment standard for cryptographic implementations. Federal agencies/departments purchasing software with cryptograph

Disclaimer: I'm not deep in the crypto world, but I follow it occasionally out of personal interest.

By "FIPS validated", I assume you mean FIPS 140-2. This basically standardizes procedures for implementing crypto and certifies that you didn't make horrible mistakes doing so. EG, that your security is appropriate to the situation, that key handling is done properly, etc. By itself it doesn't guarantee that the product will be secure for your situation.

A couple examples: It allows 56-bit DES. These days, DES can be broken by modest levels of brute force, so it can only secure your data against people who have a modest level of interest. Or another: It guarantees key handling is done right, but once it's given you the key, do YOU handle it right?

It's designed to keep government employees who know *nothing* about crypto from buying products that don't solve their problems. It doesn't guarantee success, but it prevents some of the most common mistakes.

#1 - Why do you want a FIPS seal of approval? I assume this isn't a requirement handed to you from elsewhere, or we wouldn't be having this conversation. Do you think you're not capable of evaluating the software?

#2 - Why do you want open source? Open source lets a much wider range of people audit the software than FIPS, and for a wider range of situations. But it's up to you to make sure that someone actually did this work if it doesn't have a cert.

FIPS gives you less to evaluate. Open source gives you the usual open source advantages: if you upgrade your OS, you're not at the mercy of your crypto provider to update (And re-FIPS-certify!) the encryption software.

Personally, I'd get an abstract of FIPS, and then do a bit of legwork to make sure that the open source solution of your choice is protecting against relevant attacks that FIPS deals with. Make sure it's using a popular, well reviewed algorithm. Make sure it manages keys sanely. Make sure they're committed to a good review process to make sure future changes don't screw things up.

Either way, make sure your *process* is secure. No software will save you if you make people enter the key on the keyboard, and they end up just writing the key on sticky notes and keep it with their laptop.

A couple examples: It allows 56-bit DES. These days, DES can be broken by modest levels of brute force, so it can only secure your data against people who have a modest level of interest. Or another: It guarantees key handling is done right, but once it's given you the key, do YOU handle it right?

To be fair, DES is being phased out. New products (as opposed to products that are already validated and are just have a modification revalidated) cannot have the DES algorithm validated, and every module that use

I'm not saying the FIPS 140-2 is bad. It just has limited scope. It doesn't mean you've got "military grade" crypto. It certifies a product to work within certain constraints. My point is, user needs to make sure those constraints are relevant to their problem.

it might be worthwhile to work with a FIPS 140-2 testing lab to have the algorithms tested.

Very good point. With open source, you can get any certifications or assurances you want.

First, as many have said, there is a lot to FIPS and just because something meets a FIPS evaluation doesn't mean that it is implemented securely. However, the same could be said for open source as well. Basically, if you have some regulatory or management mandate (marketing perhaps? there are a lot of corporate reasons), you may be forced into the FIPS stuff. If not, you might have more room to choose something else.However, the important thing is to determine your security goals and design around them a

> The standards are all available, and it isn't hard at all to implement some of them

I can probably knock up a working implimentation of SSH in a few days.
Who do you trust most, openSSH code -peer reviewed code written by crypto geeksmy code -a physicist with little formal programing training

Crypto algorithams are bombproof, but this isn't where people make mistakes, its in the implimentation of the code... Acidently writing passphrases to swap/tmp is one such example of how the best use of twofi

My AES code encrypts and decrypts perfectly without any mistakes (I have proven it to be exactly compliant with the published algorithm). But that isn't the point.The point was if you need to ask slashdot about whether to trust a FIPS assured commercial vender or a heavily peer reviewed open source implementation there is something wrong (and I doubt you need the encryption at that point).

Encryption is based on the fact that you want certain people to hear you and others not to. To have people hear you you

This has got to be up there with the worst advice ever posted on Slashdot. It's not about the Crypto. That's the easy part. What is hard is everything else: Key generation, memory management, generally secure coding, etc. FIPS certification has a lot more to do with how the keys are handled then the actual encryption algorithm.

No, it is about trust (the question, not FIPS).You need to trust someone with securing your information so that the people you choose can see it.

You have several choices of who you are going to trust with this:1: The commercial supplier in combination with the government2: Open source developers and their claimed peer reviewers*3: Yourself4: Slashdot

The poster went straight to 4. I intended to question this with my post.

I do agree that an uninformed person would have a very difficult time getting the encryp

This was (is) the first case of open source software being validated, as opposed to a specific product.

It is important to note that FIPS 140-2 validation simply, proves that the cryptographic algorithms (the math) has been implemented correctly, it does not necessarily mean that the system actually works as advertised.

Also, if you are a government type or contractor, make sure the vendor supplied product actually uses the version that received accreditation. Many times, that was an older version, but the marketing types keep (falsely) stating that the product is FIPS certified!!!

This was (is) the first case of open source software being validated, as opposed to a specific product.

Actually OpenSSL wasn't the first, and what was validated was a specific compiled binary version, however recompiling with the exact same source code would be covered under the rules for vendor porting of validate modules.

But another example of a validate OpenSource product is the Wei Dai crypto libraries:Cer

As a side note, a lot of certification processes are basically worthless. FIPS makes sure the software doesn't do some of the most boneheaded security mistakes, like not encrypting anything, but it doesn't actually certify the security of the software. It would be easy to write a completely insecure FIPS-certifiable program.On the other hand, an open source application in wide usage is generally hardened against attack. If people find a vulnerability, they can report it (without going to Jail, thank you

fips certification is essentailly a design review, where your finsihed product is evaluated against the manuufactureeres design documentation, and vairious standards for ensuring Confidentiality, and Integrity of the data and the device. Fips certification is a long process because of the evaluation, and when documentation is not up to snuff, it has to be updated and then the process continues.Not to knock OSS development, but i think it lacks the design documentation required for FIPS certification. The OS

Not to knock OSS development, but i think it lacks the design documentation required for FIPS certification. The OSS montra of find a problem, write,and submit a patch really doesent leave any formal pre code, paper based design to fall back on.

You should tell the authors of crypto++, OpenSSL and NSS. I bet they'd like to know this, as they all have FIPS-certified open source software crypto. The documentation stack required for FIPS certification is not actually that onerous; it's even feasible for someone

Another suggestion might be FreeOTFEhttp://www.freeotfe.org/ [freeotfe.org] which is just about the only encryption product I'm aware of that fully supports both Linux and Windows (no 9x) for creating and opening volumes.

FIPS certification sounds nice, but you need to look at what the certification really gives you. Like other security certification, I would expect that it has different levels. The minimal levels can have requirements as low as "there exits a design document" and "some testing was performed".As long as it is a relatively high-profile system (TrueCrypt is IMO), I would go with Open Source. If it is, it will get peer review and continued maintenance. Security problems will be found and fixed. And you can have

I have been using LUKS [endorphin.org] to do this on my Gentoo box. It sees to it that the root partition is completely encrypted; only the boot partition is in the clear. (Gentoo itself has support for encrypted swap.) The instructions are a bit scattershot, but I was able to get it to work. YMMV.

Before doing this, use Darik's Boot and Nuke [sourceforge.net] or something like that to fill the drive with random data; I do not think LUKS takes any steps to randomize the contents of a newly-created partition.