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?"
Open Source (Score:1)
Skipjack (Score:1)
Besides, who is more concerned about their privacy being breached - an open source community or the NIST?
Re:Skipjack (Score:1)
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_v pn.txt [auckland.ac.nz]:
"These programs have been around for years (CIPE goes back to 1996 and vtun
to 1998) and (apparently) have quite sizeable user communities without
plausible deniability (Score:1)
What are you? A spy or something?
Re:plausible deniability (Score:5, Funny)
>
> What are you? A spy or something?
Naw, he's probably just a British subject or an American citizen.
Re:plausible deniability (Score:2)
-nB
Re:plausible deniability (Score:2)
Re:plausible deniability (Score:1)
Re:plausible deniability (Score:2)
Re:plausible deniability (Score:2)
Re:plausible deniability (Score:2)
"plausible deniability" doesn't count for much with the sort of people who extract this kind of information for a living.
and they don't always play by the rules.
I use truecrypt (Score:4, Insightful)
Re:I use truecrypt (Score:2)
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
TreuCrypt (Score:1)
Depends on the Audience (Score:1)
Personally I would trust Open Source over FIPS.
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
Re:Depends on the Audience (Score:2)
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.
If the standard is not sufficient, then I would
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.
Algoritm most important (Score:2)
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.
It's not like FIPS
My question is... (Score:2)
Re:My question is... (Score:1)
DUHHH (Score:5, Funny)
- mboverload
Re:DUHHH (Score:2)
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.
Re:DUHHH (Score:2)
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.
[1] Decent != ROT13.
Re:DUHHH (Score:2)
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.
Double encrypting data with different cyph
Re:DUHHH (Score:1)
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.)
which crashes less? (Score:1)
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
Depends (Score:3, Interesting)
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.
FIPS == Government (Score:2)
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*
TrueCrypt works grea
Re:FIPS != Government (Score:2, Informative)
Re:FIPS == Government (Score:2, Informative)
Re:FIPS == Government (Score:2)
FIPS-140 certification means that the code (source) has been certified. Change the source, loose the cert.
Also, the crypto has to be checked (the load module cannot be tampered with, so tamper prevention). Which typically means that the binary build is "locked" down as well.
Still, there are open source implementations that have FIPS-140.
As to encrypting everything... its a given, isn't it? I mean, if you only encrypt the data, the meta-data is valuable (file names, sizes, etc.) If you encr
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:Different requirements (Score:2)
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
Re:Different requirements (Score:2)
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.
Very good point. With open source, you can get any certifications or assurances you want.
Keep in mind the implementation and your goals! (Score:2)
However, the important thing is to determine your security goals and design around them a
*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 twofi
Re:*DO NOT* write it yourself ! (Score:1)
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
Re:Write it yourself (Score:1, Insightful)
Re:Write it yourself (Score:1)
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 government
2: Open source developers and their claimed peer reviewers*
3: Yourself
4: 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
OpenSSL is FIPS 140-2 validated (Score:3, Interesting)
http://csrc.nist.gov/cryptval/140-1/1401val2006.h
Look for # 642
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!!!
Re:OpenSSL is FIPS 140-2 validated (Score:2)
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
Use both? (Score:2)
To turn the question on it's head a bit (Score:2)
Re:To turn the question on it's head a bit (Score:2)
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
Re:To turn the question on it's head a bit (Score:2)
Not to knock OSS development, but i think it lacks the design documentation required for FIPS certification. The OS
Re:To turn the question on it's head a bit (Score:2)
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
FreeOTFE (Score:2)
Re:FreeOTFE (Score:1)
There may be other features missing though, I wouldn't know...
Re:FreeOTFE (Score:2)
We recommend it to our clients for securing their synchronised laptops [thefilehighclub.com].
A major factor is in how you use it (Score:1)
You could use a "bullet proof" cryptosystem but if used incorrectly it wont help anything.
Now for the question on FIPS versus OSS I would say it doesn't really matter from my understading of your situation. I know a little about encryption schemes.
FIPS 140-2 [nist.gov], the main security publication for cryptographic modules, requires tested and PUBLICLY known cryptosystems that include Triple DES and AES. There is no reason in my mind to use
Certification may give you less than expected (Score:2)
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
Boot time encryption (Score:2)
I know http://www.securstar.com/products_drivecryptpp.php [securstar.com] and http://www.pgp.com/products/wholediskencryption/in dex.html [pgp.com] claim to do this, but I need an open source solution.
Does anyone know of one?
Re:Boot time encryption (Score:1)
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.
USB drives (Score:2)
Speaking about encryption,
Is there a solution that will enable me to encrypt data on a USB stick without having to install the app on any (Windows) machine I want to use the stick on?