Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Open-Source or FIPS-Validated Disk Encryption?

Cliff posted more than 8 years ago | from the peer-review-or-third-party-approved dept.

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?"

cancel ×

74 comments

Sorry! There are no comments related to the filter you selected.

Open Source (1)

trifish (826353) | more than 8 years ago | (#15153300)

Without any doubt Open Source is a prerequisite for security, as Open Source is a prerequisite for extensive peer review.

Skipjack (1)

slashbob22 (918040) | more than 8 years ago | (#15153398)

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?

Re:Skipjack (1)

trifish (826353) | more than 8 years ago | (#15153570)

Yes, that's an excellent example of superiority of Open Source in the field of security.

Re:Skipjack (2, Insightful)

TCM (130219) | more than 8 years ago | (#15154188)

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.

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
    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".

plausible deniability (1)

Neil Blender (555885) | more than 8 years ago | (#15153307)

Provides two levels of plausible deniability, in case an adversary forces you to reveal the password:

What are you? A spy or something?

Re:plausible deniability (5, Funny)

Anonymous Coward | more than 8 years ago | (#15153360)

> > Provides two levels of plausible deniability, in case an adversary forces you to reveal the password:
>
> What are you? A spy or something?

Naw, he's probably just a British subject or an American citizen.

Re:plausible deniability (1)

networkBoy (774728) | more than 8 years ago | (#15153446)

Yup, at least in my case.
-nB

Re:plausible deniability (1)

joe 155 (937621) | more than 8 years ago | (#15153787)

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, it kinda proves your point

Re:plausible deniability (0)

Anonymous Coward | more than 8 years ago | (#15153876)

Re:plausible deniability (1)

wild_berry (448019) | more than 8 years ago | (#15155821)

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.

Re:plausible deniability (1)

geeklawyer (85727) | more than 8 years ago | (#15159265)

it didnt get scrubbed - it was just never enabled. It's dangling above us like the Sword of Damocles.

Re:plausible deniability (0)

Anonymous Coward | more than 8 years ago | (#15156719)

Please stop propogating the myth that Brits are subjects not citizens. Outside of a couple of exceptional circumstances, every Brit is a citizen. Next time you meet a Brit, ask to see their passport. It explicitly states "citizen".

Whenever I hear somebody refer to a Brit as a "subject", it immediately red-flags that person as an ignorant Yank. Perhaps you are not from the USA (this would be the first time I've ever seen somebody of a different nationality make this mistake), but if you are, please try and bear in mind that you are helping to reinforce the negative USA stereotype.

Re:plausible deniability (0)

Anonymous Coward | more than 8 years ago | (#15153841)

Of course not, just trying to keep my SSN and bank card numbers out of the hands of asshats who think if you're not doing anything wrong, you've got nothing to hide.

Re:plausible deniability (1)

coyote-san (38515) | more than 8 years ago | (#15153854)

There are legitimate needs for plausible deniability. E.g., doctor-patient and attorney-client confidentiality.

Re:plausible deniability (1)

westlake (615356) | more than 8 years ago | (#15154105)

Provides two levels of plausible deniability, in case an adversary forces you to reveal the password

"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.

Re:plausible deniability (0)

Anonymous Coward | more than 8 years ago | (#15156514)

accusing some one of being a spy because the want to use encryption is so '80-ish, come on, get with the times, accuse them of child pornography

I use truecrypt (3, Insightful)

drinkypoo (153816) | more than 8 years ago | (#15153313)

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.

Re:I use truecrypt (1)

Mattcelt (454751) | more than 8 years ago | (#15155957)

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 certification is expensive ($50k for each level, IIRC), requires dedicated effort to tackle, and has been scrutinized by very smart people with a very precise goal in a very methodical manner. This makes FIPS a great deal if you need VERY strong evidence to prove to some other entity that your data is well protected.

-However, if you need to be reasonably certain that the government, the corporate who wrote the FIPS software, or any others cannot get to your data by bypassing the crypto or escrowing the keys, you may wish to take the OSS route. TruCrypt in particular is popular, has a strong and demanding user base, and has a relatively low risk of compromise, since those who program it have a vested interest in keeping the code safe.

So in short, I'd say that NIST has the upper hand when it comes to "provable" security, but OSS has the upper hand when it comes to "keeping everybody's hands out of my cookie jar". But the race is neck-and-neck; as a security professional, I would say that either one will most likely meet your needs in most situations.

TreuCrypt (0)

GenKreton (884088) | more than 8 years ago | (#15153316)

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.

Depends on the Audience (0)

tacocat (527354) | more than 8 years ago | (#15153320)

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.

Re:Depends on the Audience (1)

hey! (33014) | more than 8 years ago | (#15153471)

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.

If the standard is not sufficient, then I would go open source definitely. AND OBTAIN AND BUILD THE SOURCE!!!

The reason is that if the company that produced the product goes out of business, you can potentially find yourself in a situation where you cannot read your disk.

F/OSS. (0)

Anonymous Coward | more than 8 years ago | (#15153322)

I wouldn't trust a black box for my security.

FIPS Validation (2, Insightful)

b0lt (729408) | more than 8 years ago | (#15153354)

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.

Algoritm most important (1)

SuperKendall (25149) | more than 8 years ago | (#15154928)

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.

My question is... (1)

creimer (824291) | more than 8 years ago | (#15153356)

Where's the Mac compatibility factor?

Re:My question is... (1)

Virak (897071) | more than 8 years ago | (#15153397)

Maybe they don't use macs?

Well... (0)

Anonymous Coward | more than 8 years ago | (#15153368)

I'm not sure it's really logical to advocate one approach over the other; really, that's just an informal referendum on the virtues of closed source vs. open source without any practical value in determining the quality of a cryptographic solution.

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.

DUHHH (4, Funny)

mboverload (657893) | more than 8 years ago | (#15153395)

Put a Truecrypt volume inside of a FIPS one.
- mboverload

Re:DUHHH (0)

Anonymous Coward | more than 8 years ago | (#15153641)

Might not be a bad idea. You would have a performance hit though.

Re:DUHHH (1)

GenKreton (884088) | more than 8 years ago | (#15153923)

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.

Re:DUHHH (1)

TheLink (130905) | more than 8 years ago | (#15154388)

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.

[1] Decent != ROT13. ;)

Re:DUHHH (1)

flonker (526111) | more than 8 years ago | (#15156059)

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.

Double encrypting data with different cyphers with the same key potentially destroys the security of both cyphers.

Re:DUHHH (1)

log0 (714969) | more than 8 years ago | (#15154329)

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.

Encryption (0)

Anonymous Coward | more than 8 years ago | (#15153461)

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.

Sorry, acronym already in use - try again (0)

Anonymous Coward | more than 8 years ago | (#15153475)

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..

Re:Sorry, acronym already in use - try again (0)

Anonymous Coward | more than 8 years ago | (#15153616)

Go complain to the opensource partition splitting tool people, since they are the newcomers to that name.

Loaded question? (1, Insightful)

rabiddeity (941737) | more than 8 years ago | (#15153528)

Ask slashdot: Which is better, open source or [government entity]?

Wow, talk about a loaded question.

Short Answer: "It Depends" (2, Insightful)

fuzzybunny (112938) | more than 8 years ago | (#15153584)

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.)

which crashes less? (1)

dru (4742) | more than 8 years ago | (#15153668)

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.

Depends (2, Interesting)

Sycraft-fu (314770) | more than 8 years ago | (#15153687)

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.

FIPS == Government (1)

thegrassyknowl (762218) | more than 8 years ago | (#15153688)

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!!!

Re:FIPS != Government (2, Informative)

steveparkinson (945551) | more than 8 years ago | (#15154102)

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 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.

Re:FIPS == Government (2, Informative)

ocelotbob (173602) | more than 8 years ago | (#15154571)

In addition to the aforementioned NSS libraries, OpenSSL also has FIPS-certified builds. While in the past OSS crypto was tradtionally not usually certified, that's changed in the past year or two.

Re:FIPS == Government (1)

ratboy666 (104074) | more than 8 years ago | (#15154864)

You would be wrong

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 encrypt that as well, the fact that there are vast hunks of low-entropy on the disk (zeros, AA, 55, whatever) can tell how much of the disk actually contains data.

SOP is to encrypt the entire volume, and rely on key change by sector to avoid giving away where there is unused data. At least I hope so: those "evil" commercial programs do it.

Anyway, the NSA reviewed DES, and provided valuable feedback. Maybe you should use what the NSA themselves use. KastenChase.com

Ratboy.

Different requirements (2, Insightful)

subreality (157447) | more than 8 years ago | (#15153812)

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.

Re:Different requirements (1)

Jonathan_S (25407) | more than 8 years ago | (#15156938)

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 uses DES is require to state that DES is allowed for transitional use only and that DES will be withdrawn in May 2007.

Its not perfect, but as you pointed out FIPS 140-2 is a Federal Standard, so changes to it can be a tad slow :)

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.
Also, as part of FIPS 140-2 each supported algorithm is objectively tested for its ability to correctly perform a variety of tasks on a variety of data. Here are the various validated algorithm lists. http://cs-www.ncsl.nist.gov/cryptval/vallists.htm [nist.gov]
For example OpenSSL has AES algorithm certificate #146
http://cs-www.ncsl.nist.gov/cryptval/aes/aesval.ht ml [nist.gov]

Even if you don't purchase a FIPS 140-2 validated product, it might be worthwhile to work with a FIPS 140-2 testing lab to have the algorithms tested. This is usually much cheaper than having the whole product validated, and at least proves that the product you bought implements the algorithm correctly. And with an open source product you can do this yourself, without having to involve the vendor like you would if you wanted this testing done on a closed source product.

Re:Different requirements (1)

subreality (157447) | more than 8 years ago | (#15161274)

To be fair, DES is being phased out.

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.

Keep in mind the implementation and your goals! (1)

rdunnell (313839) | more than 8 years ago | (#15154002)

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.

Write it yourself (0)

after fallout (732762) | more than 8 years ago | (#15154177)

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.

*DO NOT* write it yourself ! (2, Insightful)

SomethingOrOther (521702) | more than 8 years ago | (#15155347)

> 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 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:*DO NOT* write it yourself ! (1)

after fallout (732762) | more than 8 years ago | (#15191845)

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.

Re:Write it yourself (1, Insightful)

Anonymous Coward | more than 8 years ago | (#15155453)

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.

Support (0)

Anonymous Coward | more than 8 years ago | (#15171940)

What about support? not the least thing when you are a company...

Re:Write it yourself (1)

after fallout (732762) | more than 8 years ago | (#15191726)

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 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 encryption economy working correctly the first time and because that is so, he/she aught to realize that there are other people in the world who they should trust. After all, the whole trust question could easily beg "Can the algorithm itself (and its designer) be trusted?" There was a whole philosophical idea that just went completely over the heads of most of the people who read this.

* Which, by the way, I do believe exist (other than myself). That is, I am fairly certain I am not the only one who has a decent grasp on the ideas, and I am not the only one of such people who have looked into various open source implementations. "Claimed" is there only because the hypothetical person asking the question would need to phrase it in such a way.

OpenSSL is FIPS 140-2 validated (3, Interesting)

baasnad (836461) | more than 8 years ago | (#15154295)

OpenSSL is FIPS 140-2 validated:

http://csrc.nist.gov/cryptval/140-1/1401val2006.ht m [nist.gov]

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 (1)

Jonathan_S (25407) | more than 8 years ago | (#15156979)

OpenSSL is FIPS 140-2 validated:

http://csrc.nist.gov/cryptval/140-1/1401val2006.ht [nist.gov] m

Look for # 642

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:
Cert #343 http://cs-www.ncsl.nist.gov/cryptval/140-1/1401val 2003.htm#343 [nist.gov]
Cert #562 http://cs-www.ncsl.nist.gov/cryptval/140-1/1401val 2005.htm#562 [nist.gov]
Admittedly, these are nowhere near as well known, or as widely used as OpenSSL.

Use both? (1)

TheLink (130905) | more than 8 years ago | (#15154411)

If you're that bothered why don't you just use both - one within the other?

To turn the question on it's head a bit (1)

cgenman (325138) | more than 8 years ago | (#15154479)

How much would it cost to get True Crypt certified? By the Wiki entry [wikipedia.org] , it doesn't sound particularly difficult to clear level 1 security.

Re:To turn the question on it's head a bit (1)

cgenman (325138) | more than 8 years ago | (#15154512)

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 DMCA) and it will generally be fixed quickly. If it is popular a lot of people will look at the code, a lot of people will try to attack the code, and things like buffer overflows which may lie dormant in commercial packages for years are quickly rooted out. It is much harder to have a popular, completely insecure open-source application.

Re:To turn the question on it's head a bit (1)

linuxbert (78156) | more than 8 years ago | (#15154697)

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 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. I also recall FIPS certification being in the $250,000us range.(though i may be way off)

How do you decide fips or open source? well you have to first look at what you want to protect, and why you want to protect it - evaluate what the system is supposed to do and do a threat and risk assessment (TRA). this will help you to understand what you need to protect aginst, and help you design safe guards (crypto is not allways the answer! dont forget policy or other non technical solutions) next look at the regulatory frame work that surrounds your project? what do various laws, industry standards and corporate policy have to say about your choice? then you have to evaluate your platforms, and existing technology, review your budgets, and based on that narrow your selection of choices.

Dont fall into the trap of we need to protect data - Lets use crypto!

crypto is not the magic bullet that solves all our problems. we also have to concern ourself with policy (user accounts/passwords/Acceptable use etc)

Re:To turn the question on it's head a bit (1)

petard (117521) | more than 8 years ago | (#15154853)

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 other than the author to produce the necessary documentation, produce the alg certs and work with the lab to get the job done.

FreeOTFE (1)

rtechie (244489) | more than 8 years ago | (#15154809)

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.

Re:FreeOTFE (1)

beef3k (551086) | more than 8 years ago | (#15155647)

According to the website, TrueCrypt 4.2 (released only 2 days ago) now also supports creation of volumes under linux.

There may be other features missing though, I wouldn't know...

A major factor is in how you use it (1)

flying gecko (695109) | more than 8 years ago | (#15155132)

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 [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 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.

It depends (0)

Anonymous Coward | more than 8 years ago | (#15155474)

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.

Certification may give you less than expected (1)

gweihir (88907) | more than 8 years ago | (#15155525)

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.

Boot time encryption (1)

RenHoek (101570) | more than 8 years ago | (#15155749)

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.

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 (1)

Diphthong (461653) | more than 8 years ago | (#15156726)

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.

Was LUKS reviewed by anyone other than the author? (0)

Anonymous Coward | more than 8 years ago | (#15159962)

There used to be a fierce and bitchy battle between the Loop-AES camp and the dm-crypt (now LUKS) camp. It seems to have died down, maybe because LUKS finally implemented new keying methods similar to Loop-AES to address the problems the original dm-crypt had.

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?

USB drives (1)

alexo (9335) | more than 8 years ago | (#15160052)


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?

Re:USB drives (0)

Anonymous Coward | more than 8 years ago | (#15171996)

Yes, Private Disk or Truecrypt. But Private Disk (http://www.dekart.com/ [dekart.com] ) also offers disk firewall feature - application level protection for the encrypted partitions.

Use ZFS on Solaris10 (1)

Ino (68074) | more than 8 years ago | (#15163554)

Lookup ZFS and encryption. It is aleged that ZFS will have a FS encryption module. Whether the encryption module is going to be there from the start or it's going to be a later "add-on", that I don't know, but still... watch that space.
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>