Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×

Open-Source or FIPS-Validated Disk Encryption? 74

Posted by Cliff from the peer-review-or-third-party-approved dept.
j_crane asks: "Our company is looking for disk encryption software that runs on Windows XP/2003 and Linux. There are hundreds of commercial disk encryption programs (most are Windows-only though). Some of them are FIPS-validated by the US NIST, but none of these are open-source. On the other hand, there is an excellent open-source on-the-fly disk encryption software, called TrueCrypt, for Windows and Linux (the program even provides plausible deniability), but it does not have a FIPS-validation. Which would you prefer -- open source or FIPS-validated -- and why?"
This discussion has been archived. No new comments can be posted.

Open-Source or FIPS-Validated Disk Encryption? More

Open-Source or FIPS-Validated Disk Encryption?

Comments Filter:
  • Without any doubt Open Source is a prerequisite for security, as Open Source is a prerequisite for extensive peer review.
    • 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?
      • Yes, that's an excellent example of superiority of Open Source in the field of security.

        • Re:Skipjack (Score:3, Insightful)

          by TCM ( 130219 )
          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
  • 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 (Score:5, Funny)

      by Anonymous Coward on Tuesday April 18, 2006 @07:02PM (#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.

      • Yup, at least in my case.
        -nB
      • 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,
    • There are legitimate needs for plausible deniability. E.g., doctor-patient and attorney-client confidentiality.
    • 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.

  • I use truecrypt (Score:4, Insightful)

    by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Tuesday April 18, 2006 @06:53PM (#15153313) Homepage Journal
    So I think that answers your question. But why? Because it's open source. I don't trust anything that isn't, and not everything that is... But it's highly used, which suggests that it's highly scrutinized.
    • I agree to a point, but I think that the overall decision about FIPS vs. OSS should be based on your requirements. If you're doing business with the US federal government, for instance, there may well be a strict requirement to use something that is FIPS certified. If you're just doing a small in-house project for a start-up, OTOH, you're probably better off using TruCrypt.

      In my mind, it comes down to the following tradeoff:
      -If you need to know that your data is truly and safely encrypted, use FIPS. The
  • Just becaue it is opensource and not validated should not mean you can't trust it. First, you can do a review if you are worried about it and make sure its implementation is worthy. With that said, truecrypt has a lot of eyes on it and I do believe it is a safe choice. The encryption ciphers used are all industry standard and have withstood the test of time, so they are better choices than any closed source cipher would be. I have never used a closed source encryption product so I am not sure what they use

  • 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

    • 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

  • FIPS Validation (Score:3, Insightful)

    by b0lt ( 729408 ) on Tuesday April 18, 2006 @07:01PM (#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.
    • 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
  • Where's the Mac compatibility factor?

  • DUHHH (Score:5, Funny)

    by mboverload ( 657893 ) on Tuesday April 18, 2006 @07:08PM (#15153395) Journal
    Put a Truecrypt volume inside of a FIPS one.
    - mboverload
    • In many instances this makes it easier for a cryptoanalyist to break. Encrypting encrypted data can lead to instances where you can subtract sets and figure out how it was converted, granted modern cryptology avoids this, mostly.

      I was also advised by a professional Cryptologist who works for BAE that you shouldn't use two different ciphers on the same drive when doing entire disk encryption. I was planning on using Twofish for my swap and Serpent for my root but was strongly advised against it.
      • Uh, I think you misunderstand. I think it's more of you should avoid encrypting the _same_ data with different ciphers, or different keys.

        Whereas the OP is talking about encrypting already encrypted data.

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

        [1] Decent != ROT13. ;)
      • 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 cyph
    • 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.

  • Loaded question? (Score:1, Insightful)

    by rabiddeity ( 941737 )
    Ask slashdot: Which is better, open source or [government entity]?

    Wow, talk about a loaded question.

  • Short Answer: "It Depends" (Score:3, Insightful)

    by fuzzybunny ( 112938 ) on Tuesday April 18, 2006 @07:41PM (#15153584) Homepage Journal
    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.)
  • 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

  • Depends (Score:3, Interesting)

    by Sycraft-fu ( 314770 ) on Tuesday April 18, 2006 @07:56PM (#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.
  • 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 grea
    • NSS (the crypto library used in Firefox, and some Red Hat and Sun products) is open-source, and FIPS-140 level 2 certified: http://www.mozilla.org/projects/security/pki/nss/f ips/ [mozilla.org] If you implement an application such as disk encryption using NSS for crypto, you'd be able to claim that it was FIPS 140 compliant. But, as far as I know, no such application currently exists. FIPS 140 is a US goverment standard for cryptographic implementations. Federal agencies/departments purchasing software with cryptograph
    • 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.
    • 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 encr

  • Different requirements (Score:3, Insightful)

    by subreality ( 157447 ) on Tuesday April 18, 2006 @08:14PM (#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.

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

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

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

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

    However, the important thing is to determine your security goals and design around them a

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

    by baasnad ( 836461 ) on Tuesday April 18, 2006 @09:38PM (#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!!!

    • 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:
      Cer

  • 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 [wikipedia.org], it doesn't sound particularly difficult to clear level 1 security.
    • As a side note, a lot of certification processes are basically worthless. FIPS makes sure the software doesn't do some of the most boneheaded security mistakes, like not encrypting anything, but it doesn't actually certify the security of the software. It would be easy to write a completely insecure FIPS-certifiable program.

      On the other hand, an open source application in wide usage is generally hardened against attack. If people find a vulnerability, they can report it (without going to Jail, thank you
    • fips certification is essentailly a design review, where your finsihed product is evaluated against the manuufactureeres design documentation, and vairious standards for ensuring Confidentiality, and Integrity of the data and the device. Fips certification is a long process because of the evaluation, and when documentation is not up to snuff, it has to be updated and then the process continues.

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

        You should tell the authors of crypto++, OpenSSL and NSS. I bet they'd like to know this, as they all have FIPS-certified open source software crypto. The documentation stack required for FIPS certification is not actually that onerous; it's even feasible for someone
  • Another suggestion might be FreeOTFEhttp://www.freeotfe.org/ [freeotfe.org] which is just about the only encryption product I'm aware of that fully supports both Linux and Windows (no 9x) for creating and opening volumes.

  • 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
  • FIPS certification sounds nice, but you need to look at what the certification really gives you. Like other security certification, I would expect that it has different levels. The minimal levels can have requirements as low as "there exits a design document" and "some testing was performed".

    As long as it is a relatively high-profile system (TrueCrypt is IMO), I would go with Open Source. If it is, it will get peer review and continued maintenance. Security problems will be found and fixed. And you can have
  • I 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?
    • 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.

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

Slashdot Top Deals

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Close