Slashdot Mirror
Open-Source or FIPS-Validated Disk Encryption?
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?"
Without any doubt Open Source is a prerequisite for security, as Open Source is a prerequisite for extensive peer review.
Provides two levels of plausible deniability, in case an adversary forces you to reveal the password:
What are you? A spy or something?
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.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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 for ciphers, but I would not trust anything outside of a few open, and time-tested ones.
With that said I highly recommend cryptsetup-luks. The downside is there is no rela windows support yet, so if that's a requirement, truecrypt is where it's at.
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 you evaluate something that's too buggy for you, consider it a service to provide constructive critique of the products on any level.
I wouldn't trust a black box for my security.
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.
got sig?
Where's the Mac compatibility factor?
Certainly you want software that uses an algorithm that has been (favorably) peer reviewed. Then you'd want to make sure the output from that software can be read back -- in other words, that there are no fundamental problems with preserving the integrity of the data you're about to trust to the program. Finally you'd want to test the output of the program against the output you'd expect from the cryptographic algorithm the program allegedly implements.
If you can and will perform all those steps, the open source solution should offer a little more peace of mind. If you can't, then it's basically a popularity contest -- albeit one that I would hand to the FIPS-validated product if only because it'd be easier to sell to the boss.
Put a Truecrypt volume inside of a FIPS one.
- mboverload
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?
Proof by very large bribes. QED.
Like many posters on this site I would trust open source over FIPS, as FIPS is just a formal procedure for justifying the mathematical "correctness" of the encryption, when the reality is that most information attacks do not try to break the encryption itself but go for implmentation flaws in the program, host OS etc...
I have personally used TrueCrypt and found it to be an excellent solution, although you can only open and read volumes on linux, you cannot currently modify volumes on linux, only windows. Depending on your organizations internal managment, sensitvity of the information, business workflow... you may have to go FIPS, especially if you do work for the US government, as FIPS software used in government contract work may be required for protecting information.
In reality (unless you're a VERY big company with information that could save or destory mankind) when information is encrypted with any current (>= 128 bit key size) algorithm people will try to use other means of getting that information.
When I saw this article, I thought that it related to FIPS - the opensource partition splitting tool.
Doesn't anyone bother to check when coining a `new` acronym? Or is it that they just don't care..
Ask slashdot: Which is better, open source or [government entity]?
Wow, talk about a loaded question.
I'm looking at the same sort of thing right now.
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.)
Cole's Law: Thinly sliced cabbage
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 corrupted here or there. And in the worst case, if your encrypted mission-critical data has been horribly mangled by a disk crash, your vendor is more likely to be contractually obligated to recover your data.
Having said that, I'm happily using FreeBSD with GBDE.
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*
TrueCrypt works great. I haven't used it lately because I have nothing to hide from anyone and I couldn't afford the performance hit on my (now very dated) server.
Remember, encrypt everything if you're taking that route. The only thing that shouldn't be encrypted is the kernel and read-ony initrd images needed to boot and mount all the encrypted volumes. Most successful cryptographic attacks involve having some of the plaintext, and if anything gets dumped in unencrypted swap or temp space then they can retreive it even if you delete and wipe it!!!
I drink to make other people interesting!
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.
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 as well. For example, if you need super-uber-crypto and you have a password embedded in a file somewhere, you're leaving a huge hole that you may want to fill with some sort of hardware credential storage. Or if you use weak keys, it may be trivial to break your crypto. Or, if you don't plan for some sort of escrow, someone might cause data to become unrecoverable if you lose the credentials. FIPS won't stop those sort of problems and neither will open source, although the additional formality associated with implementing a FIPS compliant system might help clear up some of the policy and procedural issues (because the software/hardware may force it on you).
Ultimately, unless you have a specific reason to use FIPS or want the additional "peace of mind" that the additional review can bring, you could go either way as long as you're careful about how the ultimate solution is implemented.
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/
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 cryptography are required to buy FIPS-140 validated solutions if they exist.
But, it's not only federal government. It's really the only such standard in the US, and so anyone looking for some product which has gone through some type of validation (such as financial industry) will probably require FIPS-140 valdiation.
That's what I did (although I had to for a class assignment). The standards are all available, and it isn't hard at all to implement some of them, AES for instance is actually suprisingly simple to understand. My implementations (I wrote DES, 3DES, AES) are likely not secure against implementation attacks like time-attacks, but those attacks essentially require my system to already be comprimised.
Besides, this way you truly understand the algorithm.
If you have trouble deciding what type of implementation you are going to trust, you likely have far worse problems than which encryption method to trust (with both Open Source and FIPS compliant you are required to trust someone else, or to spend so much time pouring over the code to understand it, you might as well have written it yourself). However with Open Source you will at least be able to make the assumption that it was peer reviewed.
OpenSSL is FIPS 140-2 validated:
t m
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!!!
If you're that bothered why don't you just use both - one within the other?
How much would it cost to get True Crypt certified? By the Wiki entry, it doesn't sound particularly difficult to clear level 1 security.
The ______ Agenda
Another suggestion might be FreeOTFEhttp://www.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.
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.
It's not like FIPS is really that much of a technical requirement so much as a documentation one, and documentation you could produce if you had to for the open source product.
So use the best one and obey the spirit, rather than the letter, of FIPS.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Regardless of the system, the security is largely based on how it is used.
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, 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 OSS over FIPS just because the source code is available for OSS. Any cryptosystem used by a FIPS approved system is open and very well known. And you can easily read the FIPS publications for yourself to see what is being used since they are all public (although a good understanding of the subject is suggested since they are not easy reads). Also, the use of any FIPS approved system should describe what they are using, lots of documentation is required for approval.
As long as good cryptosystems are being used (like those suggest by FIPS) you should be fine. It doesn't matter if its FIPS compilant or not... in theory if the cryptosystem is implemented (correct) than you should be safe. However, as I mentioned earlier you have to use them correctly.
Also, for FIPS 140-2, other factors are included for the cryptographic modules that may add extra things that you don't really need to worry about. Things like roles, self-tests, and hardware requirements like the use of "opaque tamper-evident encapsulating material." I don't believe you need these requirements.
The only reason that I can see to use FIPS over OSS is if you need to work with the government in some secure way (like storing or transmitting sensitive material). From a marketing stand point, it might be nice to say you are using FIPS approved system, but as long as you say something like "We are using a AES symmetric key cryptosystem for disk encryption," it should be fine enough. Anyone that knows what you are talking about will understand and realize it is secure regardless of being FIPS approved.
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.
Anyone quoted by a reporter knows how little they understand
Don't believe what you read is the truth.
If you need FIPS certified for regulatory reasons, this isn't even a question. FIPS will ensure basic security in key handling and it's been through a design review, I would not consider anything that is closed source but isn't FIPS. If you're going closed source, also see if it's been looked at by the NSA (not certified, they don't certify, anyone who tells you anything else is giving you BS). As expected from an organization made up of rediculously bright people, they perform significantly stronger testing, especially of the keying algorithms.
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 your own experts look at it or even modify it if you have special needs.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I love truecrypt, but what I really want is boot time encryption. Boot and the first thing you enter is a password, then the OS gets booted, be it linux or windows.
p and http://www.pgp.com/products/wholediskencryption/in dex.html claim to do this, but I need an open source solution.
I know http://www.securstar.com/products_drivecryptpp.ph
Does anyone know of one?
If you look at the documentation for LUKS, it claims it's an implementation of this or that design, but all the references point to stuff written by the same guy. And the only expert third-party comment I've seen came from crypto expert David Wagner from UC Berkeley, who commented "It looks to me like the author of that page does not understand cryptography very well."
So, has anybody heard anything new since July 2004?
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?
What about support? not the least thing when you are a company...
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 need to trust them (to some extent).
Acidently writing passphrases to swap/tmp is one such example
If this affects the integrity of the encrypted information, then you are already comprimised. Still, it is something to guard against (along with many other considerations) because it helps make other holes bigger.