Open-Source or FIPS-Validated Disk Encryption? 74
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?"
I use truecrypt (Score:4, Insightful)
FIPS Validation (Score:3, Insightful)
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.
Loaded question? (Score:1, Insightful)
Wow, talk about a loaded question.
Short Answer: "It Depends" (Score:3, Insightful)
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.)
Different requirements (Score:3, Insightful)
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.
Re:Skipjack (Score:3, Insightful)
There are not only crypto algorithms but also many details surrounding an implementation that are equally important.
My famous example being http://www.cs.auckland.ac.nz/~pgut001/pubs/linux_
"These programs have been around for years (CIPE goes back to 1996 and vtun
to 1998) and (apparently) have quite sizeable user communities without
anyone having noticed (or caring, after flaws were pointed out) that they
have security problems. I only heard of CIPE when a friend of mine
mentioned it to me in passing, and came across vtun by coincidence when I
was looking for more info on CIPE. Who knows how many more insecure Linux
crypto-tunnel products there may be floating around out there."
To a non-expert in cryptography, an Open Source security program may just be as obscure as a closed one. So if you rely on an Open Source program, then actually go out and seek reviews. Don't just think "it's Open Source, _someone_ surely must have audited it".
*DO NOT* write it yourself ! (Score:3, Insightful)
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 geeks
my 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 twofish/AES/3DES/IDEA etc can be shafted.
Re:Write it yourself (Score:1, Insightful)