TrueCrypt - Current Thoughts??

I've had some conversations with him in the past, circa August 2006. If PGP wants to avoid any concerns, they can use the proper adjectives when describing their source code (as in "complete", "full", "entire"). Absent that, I have no reason to think anything has changed. From my recollection, that page with the source code downloads has exactly the same wording as it did in 2006.

Further, it is relevant because you can't compile the source code to match the binary. So, you can't verify that what's in the binary matches what you just looked at in the code. So, when they release this code, it does in fact allow you to determine if there are unintentional flaws in the code.

But it does nothing about concerns of intentional flaws (i.e. back doors). Again, I will state that I don't believe there are back doors. We already have a few cases of the U.S. government not being able to break into PGP volumes. But, still, this is an important matter. PGP is not fully open-source.

TrueCrypt is open-source. Because you can compile the TrueCrypt source code to precisely match the binary, we know for a fact that everyone is using a binary that matches the source code. I'm not saying that it would necessarily be easy to discover a back door with fully open-source products, but it may be nearly impossible without the full source code.

p.s. I'm 100% serious. If you want to change people's minds, then let them know to add a proper adjective in front of the word "source code" to let us know it's complete. I'm not going to ask every single time if anything has changed.

 

Yes, I was refering to file volumes (disk volumes always have multiple of 512 sizes ).

 

Note that PGP describes the availability of “full source code” (see here). The use of the adjective “full” suggests that the company is providing all of the code.

Tom McCune, a PGP Forum Administrator, notes: “It is only the 7.x versions of PGP that did not have full source code available for public review. This was corrected when the current owner of PGP (PGP Corp.) produced its first version (8.0), and remains so through the current version” (see here). This comment was made in November of 2007, which is consistent with the hypothesis that the policy and practices of PGP concerning the release of source code may have evolved over time.

 

Verifying the integrity of the PGP application could be done, I believe, in the absence of matching binaries.

Consider a test case in which a file is (a) encrypted with the PGP executable and (b) decrypted with your own complied version of the source code that has been inspected and verified (and the reverse sequence). If, using the same public-private key pair and/or passphrase, the encryption of the plaintext is identical in both cases and the decryption of the ciphertext is also identical in both cases, then both versions are functionally equivalent from a cryptographic perspective, which is the outcome to be proved.

Since, by definition, we know that the inspected source code is free of any “backdoor” or (un-)intentional defect, then the same must be logically true of the PGP executable -- correct?

 

Functionally equivalent yes but the same maybe not. LOL.......................

 

It says "full", but only under PGP Universal, not PGP Desktop.

Probably but not necessarily. There may be a way to leak the key or other vital information in the executable, although it's unlikely.

I don't want to turn this into a thread where I'm the bad guy bashing PGP. I don't know for certain what's in the code. And I wasn't really happy with Tom's answer, starting with "As far as I know". I wish PGP would say exactly what they're releasing, but I'm not going to push it any further.

 

On BitLocker, TrueCrypt, open-source, and closed-source.

As I can't seem to post, or even re-register, at the TrueCrypt forums, I'll post this here, for those of you who might be involved in the discussions there. (I'm quoting someone from the TrueCrypt forum, by the way.)

I don't know, as I've never analyzed either of the two implementations. Ask me, "Which of the two -- TrueCrypt or BitLocker -- is backed by more knowledgeable designers?," and I'd answer, "I'd go with BitLocker." It's evident by the design decisions behind the two that those working on BitLocker have a much better grasp on this type of cryptographic application (i.e., simply sticking to the AES, better addressing data granularity with a wide-block approach, et cetera). In other words, there's clearly a lot more cryptographic understanding going on behind the scenes, and their design decisions reflect a more progressive, tailored-to-fit approach. TrueCrypt's design decisions aren't really state-of-the-art, or even progressive, and changes appear to be made after the fact (i.e., moving from CBC to LRW to XTS). Leader versus follower, perhaps?

As for the open-source versus closed-source debate, the reality seems rather simple to me. It's a matter of potential. Being open-source does not equal being inherently more secure, and the "many eyes" principle is incomplete. It's "whose eyes" that matters, and closed-source software entities can often pay for these, as opposed to some open-source projects, which, despite their rallying community, can't attract the right eyes; it could be because they were simply unnoticed, the demand wasn't there, or because those eyes need to make a living too. It doesn't really matter, though. It all comes back around to potential. Open-source certainly has the potential to be more secure, and this model complements cryptographic research, and is necessary for good results; it's just not a given, and doesn't automatically give you an advantage over the closed-source model.

Neither of the two are optimal, and the design decisions were not only affected by security, but architecture, as well. There's a lot of work to be done and many improvements to be made, and it's interesting to pay attention to who is trailblazing and who is tailgating.

 

Re: On BitLocker, TrueCrypt, open-source, and closed-source.

Justin, You've had a lot of good things to say here. But lately you've simply become a shill for BitLocker.

To claim that there's "clearly" a lot more cryptographic understanding with BitLocker over TrueCrypt, based on the few things you said, is ridiculous.

 

Re: On BitLocker, TrueCrypt, open-source, and closed-source.

I don't recall talking about BitLocker much, aside from my praise regarding the design decisions of Niels Ferguson, et al. But, I'm a Linux user, so I don't really have investment in it as a product.

TrueCrypt throws in a lot of different primitives, but ends up with a narrow-block approach, with finer data granularity; BitLocker sticks to one primitive, along with a custom diffuser, and ends up with a wide-block approach, with coarser data granularity. What this shows me is that the latter understands the problem a bit better.

To be fair, I've always cheered for TrueCrypt's success, which can be referenced in my posts as often as my praise for BitLocker's cryptographic approach. I'm neither pro-BitLocker nor anti-TrueCrypt; it's the design decisions I'm most interested in.

(Edit: My work is geared towards making sure developers understand the right security goals they should be looking for, so that the end result maximally benefits the end user. In its own way, TrueCrypt is doing for disk encryption what PGP did for e-mail encryption, in regards to community building and cryptographic integration for the everyday computer user, so it's obvious why the evolution of TrueCrypt would matter to me.)

 

Re: On BitLocker, TrueCrypt, open-source, and closed-source.

Justin, I have to agree with LockBox (not the shill part though). I'm not sure that such generalizations can be made about a product based simply on the most basic design choices made by the developer, unless there are some obvious, gross problems with decision-making.

To my thinking, anyone competent enough to develop/program either TrueCrypt or Bitlocker is more than competent enough to make these basic design decisions. Otherwise, one would assume that such developers/programmers would be making a great deal of actual implementation/coding flaws. Because the actual implementation and coding is so much more difficult than the basic design choices, I would assume that if your observations were correct, there would be obvious implementation flaws in the code. In other words, incompetence here equals even more incompetence there. I'm not an expert, but in the absence of problems in the actual code, I'm willing to believe that they have a good reason for their choices.

But, I'm willing to concede that because of my lack of expertise, you may be seeing something that I'm missing. I've probably read most of what you've said about the whole AES vs AES+Twofish+Serpent debate, and I'm not at all convinced that that's a design flaw or overly complex. After all the recent scares with AES, I'm not unconvinced that TrueCrypt was way ahead of the curve on this matter. I know these problems with AES don't affect properly-implemented disk encryption products, but I don't see the harm in offering two additional ciphers to people who don't want to use AES. It's not like they're offering every possible cipher. In that sense, they're both pleasing their customers and being conservative.

Furthermore, as far as the whole coding complexity debate, you would have a very hard time finding a lighter program that can do everything that TrueCrypt can do. Comparing TrueCrypt to PGP or Bitlocker is like comparing apples to apple trees. I don't know much about Bitlocker but I know Microsoft's reputation. And PGP is a coding monster. And while I believe PGP is secure, I don't think they've ever met a feature they could resist implementing, regardless of how meaningless or useless it is. People on this forum are routinely being fooled by everything PGP is incorporating, believing that it's a must have and completely sets it apart from TrueCrypt (when all the while TrueCrypt is quietly incorporating only the features that have some benefit). While I don't understand all of the factors that go into choosing the crypto, I do definitely see a lot of intelligence and foresight with respect to other security decisions they've made.

This is the only thing you said that I don't understand, so I'm willing to bet that most people won't understand it either. So, I presume that Bitlocker uses wide-block encryption while TrueCrypt uses XTS, which is narrow-block. What benefits do wide-block encryption offer over narrow block? Also, I'm not sure what you mean by data granularity (although I might have some idea) or how this is impacted by the types of encryption implemented in TrueCrypt and Bitlocker.

 

Thanks for at least disagreeing with the "shill" part. My observations of these design decisions point to a deeper cryptographic issue. Those behind BitLocker seem to have a better understanding of this type of cryptographic application. Does this null the real-world security of TrueCrypt, as far as these design decisions go? Probably not. But it does indicate who is more "hip" to cryptography, from a cryptographer's point-of-view. Then again, I know of at least one leading cryptographer behind BitLocker, yet I am unsure of the case with TrueCrypt.

It's certainly not easy to implement cryptography and have it hold up in practice, so I'm not opposing their coding abilities; then again, I'm not sure who all is actually looking at the code, so I can't say that it's holding up because it's good or because noone is looking. That's beside the point, though. To be perfectly honest, I wouldn't attempt designing such software myself, because I know how tricky it can be. The thing to note here is that my observations don't conclude that TrueCrypt is practically insecure; the design decisions just aren't reflective of those of a cryptographer. For a role model that will no doubt inspire future applications of this type, I think this is important. Unfortunately, those behind it don't seem to be accessible to the public. Is it just me? Has anyone had any luck?

As I've mentioned before, the likelihood of an implementation mistake is a stack of magnitudes greater than a practical attack on the AES; history, along with the present, confirms this. If I were going to make a design decision that was more in line with the reality of cryptographic design and deployment, I would ditch the multiple algorithm choices and work on a wide-block approach to encryption. It's less to analyze within the implementation, and it buys you better integrity protection -- even if it's not a proper MAC. There are performance trade-offs with wide-block versus narrow-block, but since TrueCrypt offers cascades of primitives, I don't think this would be that big of a deal. This would be even more conservative. If you're implementing other block ciphers, and cascades of block ciphers, "just in case," then that's indicative of not really understanding where things usually go wrong. Designs that worry about the cryptography more than the implementation worry me. And that customers can influence this worries me even more, because customers are more than likely going to understand this less.

Right, that's why I'm comparing only the cryptographic design decisions as they relate to the implementation; otherwise, it very well may be a different argument. Although, I wouldn't agree that TrueCrypt's design decisions are optimal, in terms of benefits. As a whole, it may set itself apart, but cryptographically, it does not. Again, is this an immediate real-world issue? Probably not. Could it get better? Of course. And I think it should, because people are talking about TrueCrypt in ways they aren't talking about BitLocker at all, nor about PGP anymore -- even if I feel that there is more collective cryptographic manpower behind the latter two.

With disk encryption, there's often no room for a MAC, or Message Authentication Code, to provide authentication; although I used to sympathize with this, I do less these days because of laziness in the industry. (Security is still "tack-on.") Since a MAC has been ruled out, there needs to be some way to prevent meaningful manipulation of data. If you operate on larger block sizes -- let's say 512 bytes -- while attacks are not impossible, it's more likely that any manipulation will lead to a system crash or some other failure, as opposed to being a controlled, meaningful attack. Why? The thought is that by randomizing more plaintext during manipulation, you increase the odds of doing damage over opening a security hole. Narrow-block modes, like XTS, leave more room for attack, since they operate on block sizes of 16 bytes; wide-block modes, like EME, given their larger block size range, make these attacks a lot harder.

Read the paper on BitLocker's AES-CBC+Elephant diffuser, if you haven't already, as it talks about this. They refer to this as "poor man's authentication," since a MAC is the proper mechanism for integrity preservation; in short, wide-block modes do a better job at this. This is worth noting, as it can be a practical concern. Oh, and if it's not already clear, data granularity refers to how narrow or wide the blocks are; in this case, the wider, better, in regards to integrity. For example, modes that turn block ciphers into stream ciphers, like CTR, have a "fine" granularity of one bit; obviously, this provides no integrity at all, and requires authentication. It gets a little better as you go from CBC, to LRW, to XTS, but it's still narrow, which is where wide-block modes come into play, with their "coarse" granularity.

 

Justin, exactly what first-hand knowledge makes you capable to
analyse anything about how BitLocker is designed or implemented except for the most obvious ? Who, outside Redmont, has seen the code ? Who has seen the code to the OS bitlocker runs under ? It's true that we often don't know who, if anyone, reviews open-source code but we do know witch independent parties review closed-source software : NOBODY .

The idea put forward earlier in this thread, that the AES-algorithm should have a US-ordered back-door, is pretty ridiculous,
if it did they wouldn't be using it themselves and seriously :
The Americans are not the smartest guys on the face of the Earth any more,
how long would it take for the Chinese or Indians to find that backdoor ?
The fact is that it's in the interest of "US national security" to have strong, presumably unbreakable, encryption-algorithms available .
If this means private citizens may be able to conceal their petty secrets
("illegal" music and video, pr0n etc etc) so be it ..

Being unknown as a software-developer does have it's advantages, for instance it's hard to serve a court-order that requires you to release a back-doored version to assist an ongoing sting, like it happened to JAP.
I'm sure Phil Zimmermann at some point has wished no-one knew his name to ..

 

Aside from conversations with Niels Ferguson, I only know what's at the obvious design decision level, and it's at that level that I'm comparing them. Here's something for thought: Take two pieces of software -- one open-source and one closed-source. We don't know who designed the open-source software, but it's completely open for us to scrutinize. We can't inspect the closed-source software, but we know that some prolific cryptographers were behind its design.

Don't forget the case were the closed-source model can hire the best help; openness is more ideal, but no more so than expertise. Being closed does not mean being inherently less secure, just as being open does not mean being inherently more secure; open can potentially be better, but there's no guarantee. (I'm pro-open, by the way.)

I agree.

Openness is why cryptography, as we know it, has flourished; the same should be expected of implementations -- especially software as trendsetting as TrueCrypt. Otherwise, you might turn away the ones you really want to be looking.

 

Justin,
If you were to give someone one advice, who's business relies on securing the data of their laptops. What would you advice: Truecrypt (given its being installed by somone knowledgeable, or Windows 7 Ultimate with Bitlocker?

 

I would say that it's a matter of numerous things, including policy and the size of the deployment. BitLocker has integration on its side and might be more manageable in that regard. I would say either one has its place, and I think matching it to the right environment and ensuring proper use are most important in this case. In other words, identify your threat model, figure in your constraints, and calculate the needs of your user base, and then decide which will be the simplest to deploy and manage.

 

I'm a longtime TrueCrypt user and I find that it fits my small business needs perfectly. However, keep in mind that TrueCrypt doesn't offer any technical support whatsoever, and as such it's target audience consists mainly of power users who are able to solve their own problems. Put another way, "Who you gonna call?" There are also no group management policies or similar features that might be of use in a corporate setting.

TrueCrypt is great if you know what you're doing and are willing to take the proper precautions (e.g. learn about the known pitfalls so you can avoid them, and always keep current backups of your data). However, I would only suggest TrueCrypt if you had ready access to the "someone knowledgeable" that you speak of or were willing to become that person yourself.

 

TrueCrypt's lack of official support in combination with its extremely restrictive license (an lawsuit waiting to happen) makes TC unfit for corporate use.

Linux for example also does not have any official support, not even an official manufacture, but thanks to its License there is plenty of support through communities ad well as commercial support from like RedHat.
A company wanting to use the Product can purchase support from qualified parties and relay on it.

Due to TC's license its unlikely that some Company will start providing business support.

TC is hindering its own potential through its License.
As already someone said TC is open source and comes at no cost but it is not free.

 

I'm glad y'all brought support and licensing up; that's probably the biggest deal, in regards to TrueCrypt as a business decision. There's a lot of potential, yet it appears that they aren't sure what to do with it. Maybe they are. Then again, without any involvement in the community that they are fortunate to have amassed, who knows what their vision is. With all of this in mind, it probably doesn't scale half as well as it could. If they don't harness this potential, they're going to shut themselves off to the audience that would likely benefit most.

 

Well I think their agenda is to provide an encryption program for dissidents and people living under live threat. Like in china.
Thay seams not to be interested in providing encryption for organizations and/or people just consurned about their privacy/rights (like for example Filesharers)

For people who just needs some privacy to prevent people like the RIAA/MPAA a.k.a. MAFIAA being able to prove how much MP3's and cam rips one head on his multiple TB large raid array.
The TC devs seams to have lite more than plain disregard.

The reason behind this I don't know or understand.
But my impression is as stated above and I'm convinced its quite accurate.

I'm still using TC but more and more I'm looking for an alternative...

 

And, the inability of TrueCrypt to centrally provide key management, provisioning and policy enforcement further suggests that it will not succeed within a corporate environment.

 

i use TrueCrypt,

basically ive created just a 1gb volume which i put all my personal and private things in, just incase my machine should be infected or compromised.

its 1gb storage of my personal files, a safe net - a just incase type of volume.

impressive software indeed, just what everyone should use for those personal-type of files within their computer.

 

I've tried Truecrypt and a bunch of others through the past couple of years and am back with gpg for Windows.

gpg encrypt the files I want protected plus I have the added benefit of email encryption. It doesn't encrypt entire discs. Maybe some day, but I doubt I'd use the feature anyway.

 

Where did you get that from ?
And how does filesharers wanting to "hide" their "secrets" from the MAFIAA differ from anyone else wanting to hide their secrets from xxx ??
Corporations are 100% free to PAY someone to modify the TC-code to fit their needs ..AND PAY someone for providing support .. But NO...
Lets see if we can get them to do it for us for free and then use the forum as a helpdesk ..
Maybe this board is more "free" than TC's , lets test it :
Y'all a bunch of whining bitches

 

Well from experience based on accepted/refused feature requests and the way features are implemented in TC.

For example the Hidden OS feature, when you use it TC prevents you from writing to unencrypted drives and even encrypted but not hidden TC Volumes.
And there is no option to disable this limitation and the TC devs made clear they will not implement an OFF switch for this "misbehavior".
The reason behind this is that this may leave indications for the presence of an hidden OS, well yes it might and in a repressive regime this may be enough to get your killed.
But when you are only leaving in the US or EU and your adversary are some RIAA/MPAA a.k.a. MAFIAA lawyers its enough that thay cant prove beyond any doubt that there is a hidden OS.
So for all this users this "feature", a.k.a. intended misbehavior, is just plain harassment and not relay a benefit.

Or when they implemented whole disk encryption they dropped support for TCGina and TCTemp, under the argument that informations may still leek to the OS and those everyone should use now whole disk encryption instead.
But whole disk encryption has its dissadvantages as well, like when restoring from OS from backup, or when more users uses the PC and each wants to have his files encrypted separately, etc...
Sure from the point of view of a dissident leaving in China or so whole disk encryption is an advantage.
But for the average EU/US user that only needs to keep an Notebook burgle away from his work data and user profile, WDE is overkill and in fact can pose an inconvenience.

Or a feature request to enable reboot without password reentry like in PGP, by storing the key temporary on the HDD and erasing it after use.
imho. an absolute must have in any larger IT infrastructure.


The point is that while people living under live threat always take whats the most secure despite of all practical downsides.

People leaving in EU/US are in the luxury position to be able to find a balance between how much security they need and how much hassle they are willing to take.

The TC devs completely ignore the second group of users