Thread for TrueCrypt alternatives [FOSS preferred]

@LockBox and @blainefry,

Thanks to you both. Your knowledgeable, thoughtful and non-confrontational responses are of great benefit to these forums IMO.

A couple of thoughts and I'll stop talking (typing).

I'm not bothered that I cannot say, or that the experts can't or won't say how NSA might have been able to weaken cryptography via their involvement in the selection process. As to myself, I lack both knowledge and talent sufficient to devise a workable scheme. As to the experts, history and experience teach us that inventing, or otherwise crafting an elegant solution to a complex technological problem is an altogether different matter than the ability to explain or understand such a solution once that solution has been created and revealed.

Same question from a different angle. There is simply no question but that trade secrets exist and have value across a wide range of commercial technologies, businesses, and military and political endeavors. Hence, the possibility of valuable and closely guarded cryptographic trade secrets is clearly within the realm of reason, if not a virtual certainty. But if people knew the nature and substance of such trade secrets, then the secrets would no longer be secret. Their value would be drastically decreased if not eliminated altogether.

IMO we can be pretty certain that secrets of great value do exist in cryptography. It is fundamental that any such secrets must be maintained in strictest secrecy. Hence we shouldn't expect anyone to be revealing any such secrets.

My uneducated guess would be that NSA would prefer widespread adoption of cryptographic code that could be drastically weakened or eviscerated entirely by tiny and virtually undetectable changes to the code. The plan would be to make the smallest of (possibly temporary) changes to codes on or delivered to adversary's systems with a net result that secrets entered into adversary's systems would become insecure or substantially less secure.

Other approaches must certainly exist. The fact that I can't identify such approaches means nothing. Be assured that what I don't know could fill encyclopedias of encyclopedias.

Best Regards.

__

 

Both. Remember this article? http://www.wired.com/2012/03/ff_nsadatacenter/all/1
From the article

I take that to mean that they have broken AES. It makes sense that they'd focus on AES, the "unbreakable standard" that most everyone uses. For me, that's sufficient reason to stay with another, one that didn't become the standard due to performance reasons, not because it's weak, one that they most likely haven't focused on because it's not commonly used.

 

I disagree with your insistence that we must agree to disagree.

I think you're misunderstanding my point there. The point was that the govt wants to keep its own secrets. Sure the suits are going to want to spy on each other. But they're not going to go around suggesting that the entire US government use insecure encryption just so that they might be able to read communications from Congress members. The idea of a branch of the federal govt purposefully leaving the entire federal government (including the military) using a broken cipher just so that the spy branch can eavesdrop on them is pretty absurd. If there's one thing they like less than not knowing something about someone else, it's someone else (i.e. a foreign power) knowing something about them.

As I keep saying, the math is the strongest point in the chain. Even the NSA is not magic and they are bound by the same laws of mathematics and physics as the rest of the world. I don't know any other way to say it. Maybe you just don't have a firm enough grasp of how cryptography works yet. (I don't mean that in an insulting way, I'm just saying that to keep insisting that an algorithm is compromised somehow, as if it were a piece of hardware or a software utility, suggests a basic fundamental misunderstanding.)

And also as I keep saying, the weakness is going to be found in the implementation. And just as with everything else, the subversion of standards/equipment we've seen goes right in line with that...

-http://www.infosecurity-magazine.com/view/34405/did-the-nsa-subvert-the-security-of-ipv6/

An algorithm is not a product. And the "standards" they have worked to subvert are general protocols, not foundational encryption. (Again, you can't "subvert" core math.)

For example, one major issue is in cell phone standards. As that article above notes,

Simply making it the "standard" to have poor encryption (or none at all) in the general telephone network does not expose anyone who is actually concerned with privacy and actively takes steps to ensure it. It just makes it easier to spy in general. It makes bulk data collection easier. But it's not as if the NSA or anyone else is really affected by it. They can implement end-to-end encryption on their own communications through the use of 3rd party tools (just like you can.) The problem is not with the encryption. It's either with how it's implemented, or the fact that it's not implemented at all.

Another example, the famous Dual_EC_DRBG. This was a single CSPRNG in a single cryptography library that they got RSA to make the default for a certain security suite. While it's nice to have a specific "backdoored" program you can point to, it's not as if the implications are very great here.

Again, this wasn't any kind of "standard" by any real means, and it's not like anyone in-the-know would be exposed. All you have to do is avoid that CSPRNG. It's a pretty far leap from that to "AES is compromised."

Not only that, but pretty much right when the thing was published the crypto community was all over it, raising suspicions of a possible backdoor and explicitly stating more or less that "nobody is going to touch this thing."

Matthew Green (one of the cryptographers on the TrueCrypt audit, actually) stated:

Schneier also stated as early as 2007 that the backdoor as too obvious to trick anyone to use it.

So the bottom line is:

1) The NSA is not magic. They can't subvert the laws of math and physics, and they can't hide an insecurity in an algorithm. Certainly not for 15 years. And certainly not the most widely used encryption algorithm in history.

2) Bullrun and any programs like it are about weakening protocol standards and specific products. Again you can't "weaken" an algorithm. It is what it is. It's either secure or not. You can figure a way to crack it (i.e. cryptanalysis, which of course would immediately make it insecure), or you can weaken its implementation/get around it (i.e. side channel it).

If you want to argue that the NSA has a practical cryptanalytic attack that allows them to recover keys from AES ciphertext, then that's fine. It's unlikely, but it's certainly possible. But to suggest that somehow the algorithm itself was broken from the start, and the entire world has just been oblivious to it for 15 years, despite it being the most widely scrutinized cipher ever...is only good for a movie script. In the real world, it just doesn't add up. It doesn't even pass the smell test.

 

If by "cryptographic code" you mean a piece of software or a router or a CSPRNG, sure, I guess. (Even though changes to such code would require access to the target's equipment...which, if you have that, you don't really need the code to rigged for subversion. You can just...subvert it.)

If you're just talking about an algorithm (like AES), then what you're saying doesn't even make sense.

It's ironic that you would cite that article, as of course, that's the exact comment that Schneier was talking about in the exact post I linked earlier...the one I used to quote him explicitly saying that he doesn't believe they can break it.

I'll quote another part from it, since you brought it up, and it reiterates what I've been saying:

-https://www.schneier.com/blog/archives/2012/03/can_the_nsa_bre.html

Again, as I've been saying, the attacks are more than likely going to be side-channel. It's just the practicality of it. The math is the strongest link in the chain. It only makes sense to go around it by attacking a weaker link in the chain. Why the heck would you waste time and resources trying to chop down a 100ft stake in the ground?

-https://www.schneier.com/blog/archives/2008/10/quantum_cryptog.html

You just go around it.

 

hi
If someone wishes to make a comparative algorithms stress testing/cracking, there is a few dedicated tools, but it would be BIG waste of time.
And with a simple option on TC, these tools become totally useless.
And this is not new, as revealed by some old real stories http://www.theregister.co.uk/2010/06/28/brazil_banker_crypto_lock_out/
There is currently two forensic softwares designed for defeating full disk encryption, and both take advantage of the the encryption implementation and interaction on and with the OS, not on algorithm weaknesses.
I do not think that B. Schneier is the Evangelist of Crypto, as these years the crypto world is more shaken by Russian, French, Chinese and German teams...
Blowfish, Onefish. 2fish. selfish or fishfish...sorry, endless questions...since no absolute proof...
And to focus on the toppic, another alternative list here
http://arstechnica.com/civis/viewtopic.php?f=21&t=1245367
I think that Tomb is promising, even if using the stego option can be easily detected by law enforcement solutions.
The "French National Network Agency" urges to use alternatives, and provide a liste of French certified product,, a few month only after a certification of the 7.1a version of TC (change .pda to .pdf)
http://www.ssi.gouv.fr/fr/menu/actualites/possible-abandon-de-truecrypt-par-ses-developpeurs.html
http://www.ssi.gouv.fr/IMG/cspn/anssi-cspn_2013-09fr.pdf
The European Union recommend 3 certified products, two in France, one in UK http://www.consilium.europa.eu/poli...ist-of-approved-cryptographic-devices?lang=en
Now regarding NSA power, it is suited to look at their official devices 8 years ago http://www.nsa.gov/ia/programs/inline_media_encryptor/
Due to military implications in crypto, no one can be sure of anything, Bruce Schneier included.

Rgds

 

Many thanks I never used the 35-pass anyway. It would take several years to finish hehehehe

EDIT: I use "bs=4096" in the command (dd if=/dev/zero of=/dev/sda bs=4096). I read somewhere that it doesn't affect the zero fill process because my HD has a cache memory of 64 MB and physical sectors of 4096 bytes. Is this correct or it could be possible that the zeroing process skips some sectors?

 

Yeah I loved the feature really makes one consider Drivecrypt as being an option despite its bad rap and past....I love the idea one can run a screensaver and its not linked to Windows it requires a specific password to get back into the system. I wonder if Drivecrypt have further programmed this feature to disable or block any usb ports or any other adversary forensics but perhaps wishful thinking they had thought this far.

In regards to all this talk about AES and blowfish etc, perhaps its better to to use 2 systems and create a further partition of trust.

Lets say FDE via AES and Hidden Container via blowfish ?

 

Two layers of conventional strong encryption is IMO the wrong approach. Consider this. With conventional strong encryption, if you enter an incorrect password, the file just refuses to decrypt. With 2 layers of conventional encryption, you know that the outer layer is properly decrypted when you reach the inner layer. IMO, when one attempts to decrypt the outer layer, it should give you a result regardless of whether the password was right or not. The wrong password should just give incorrect decryption, aka gibberish. That gibberish should look like encrypted material.

This is vastly oversimplified but demonstrates the idea. The inner layer can be conventional strong encryption, the cipher being irrelevant at the moment. Make the outer layer of encryption a character substitution cipher that also adds extra characters for padding. If you decrypt the outer layer wrong, it still gives you a result, an incorrect result. If the result of improper decryption looks basically the same as it would if correctly decrypted, an adversary would have no realistic way of knowing if they correctly decrypted the outer layer. The only way they could know if the outer layer was correctly decrypted is to crack the inner layer of strong encryption. It would be like running an already encrypted file through an Enigma machine that also adds extra characters. If the substitution layer is sufficiently complex, the 2 together should be darned near unbreakable.

 

You could use oflag=direct if you want to turn the caching off, only practical effect will be to slow it down, nothing will get skipped either way.

 

Just a quick question, if anyone uses BestCrypt. Does BC give you the ability to have hidden volumes like TrueCrypt? And can you create a volume within a file, instead of having the obvious BC file extension? I loved that TC would utilize steganography.

Are there any programs that offer those features if BC doesn't?

Thanks for your help!

 

hi
it looks like truecrypt, would like to know differences between them

thanks

 

hi
is there a real benchmark about how faster is it ?

 

I just found out about M.A.I.D. (Mutually Assured Information Destruction), it is not available yet, and as far I could see the development status is unknown.
However, this offers an interesting alternative to the deniable encryption dilemma. Instead of providing deniable encryption, it has automatic destrucion of encryption keys, but can still verify whether the password is correct or not. So instead of being prosecuted or imprisoned because you don't give up a second password that you might not even exist, you wait until the user-configurable time has passed and decryption is no longer possible, then you give up your password and the software can confirm it is the real password, but it's useless. Of course this may not help in extreme torture/kill situations, but in other situations it might make a great difference.
https://www.noisebridge.net/wiki/M.A.I.D.

 

hi

Not sure that a fork is 100% possible
http://www.net-security.org/secworld.php?id=17031
This is an opportunity for proprietary code encryption solutions, and many editors take advantage of the decline of TC https://www.jetico.com/welcome-truecrypt-users-migrate-to-bestcrypt
Great marketing name from Russia, but i will not put even my cat's name on it (free version or not)
http://cybersafesoft.com/

Rgds

 

I asked about bestcrypt if it supports hidden containers the bestcrypt container encryption software has hidden containers support noted here:

https://www.jetico.com/products/personal-privacy/bestcrypt-container-encryption

closest to your Q though from what I can see is the software can mount a drive as a sub folder.

I would have jumped over to bestcrypt volume encryption software but from what I can see it does not support Hidden O/S feature not unless am wrong on this?

 

there are no alternatives to Truecrypt, not for a long time yet and a worthy alternative would actually be a TC fork.

 

Hey, thanks for the link... My issue was just simply trying to have an exact copy of TC without being TC, as in I got used to it, spoiled and enabled, but don't trust it so want something new but the same thing. So yeah, illogical to say the least.

I still miss the basic features of TC like the HV's and what not. I guess the token to go by really, is simply try to keep your data secure if you loose it or it's stolen. Gov alphabet soup agencies will more than likely be able to beat anything and everything in no time anyway.