why is truecrypt discouraged??

[dudu386]

Hi

I just set up my own Home NAS after getting frustrated with some netgear NAS solutions( i dont wanna make this thread about that, i'll just say that u needed to have flash before u could even login to the web based frontend to set it up)
and I am very happy with my setup now, but since i throw a intel D510 Atom dual core at it, i thought i may use the extra cycles as well, So i was looking around for some cross-os encryption that i can use between Linux/Mac/Win7

The first thing that came to my mind was truecrypt but i found this:

http://fedoraproject.org/wiki/ForbiddenItems#TrueCrypt

It says "Avoid this software entirely".

i was wondering if someone could explain why is this software discouraged ???

is it only because of legal issues ( which i truely don't care becuz of location and other matters )

or is there any other reason like bad implementation of the encryption algorithms or some other reason??


please answer the question rather than driving the threat into other marginal stuff. if you have other thoughts why not start a new threat of your own. ---- Thank you

---------- Post added at 11:28 PM CDT ---------- Previous post was at 10:46 PM CDT ----------

a quick update: I just realized that putting a truecrypt container on the NAS rather than the files themselves doesn't put any extra load on the NAS CPU but rather they will be handeled on the clients requesting them .....
....
but it doesn't change anything about the threat topic

sorry for being a bit noobie :D

[forkbomb]

As far as the Fedora Project is concerned, uhh, well, it's explained in the link you yourself provided: TC has an ugly license. Fedora avoids all sorts of stuff with iffy or ugly licenses (this is also why the Fedora repos don't have stuff like mp3 codecs and the like). Fedora aims to be totally Free Software (see the Foundation and Overview) and the license TC is distributed under doesn't fit into the definitions of Free Software dominant among distribution developers.

Implementation-wise, I'm not sure. But last time I checked, TrueCrypt isn't included in the standard official repositories for several of the popular distributions (Debian, Fedora, Ubuntu, Gentoo, openSUSE) due to its licensure and the doubts surrounding who actually codes the thing. Those reasons are enough to give me pause, but YMMV. I personally stopped using Truecrypt in favor of LUKS-based encryption in conjunction with device mapper (FreeOTFE on Windows can access LUKS-based encrypted "containers").

Regardless of all that, if you want to use it on Fedora, I think TrueCrypt has been rebranded as "RealCrypt" in RPMFusion.

(PS: be careful about storing encryption containers of any implementation on network drives, especially if you're accessing over wireless; first of all, NFS for one may have trouble with this from a permissions standpoint. Second, a networking hiccup such as a few dropped frames can cause corruption of a TC volume. I've seen it happen. The simplest course of action is to just encrypt the disks on the file server.)

[dudu386]

yeah you are right, if i put the container on the server, 1 byte of corrupted data is probably gonna make the whole volume unreadable,, whereas 1 byte of corrupt data in a 300GB moive library is probably gonna make some red pixel turn blue in the middle of a movie (assuming 24 fps that is unlikely to be even visible)

another downside is that i cant access them on multiple clients. For instance if someone is watching a movie on the home theatre pc then i can't access my files on other computers

[forkbomb]

Yup. Exactly. I lost a ~120-GB TC volume on one occasion because I was accessing it over SMB.

Also, the problem I noticed with NFS was something like that you effectively need to have root access to mount an encrypted file container sitting on a remote NFS mount (because you need to make a device-mapper loop device to mount a LUKS file container). Unfortunately that requires you to set the NFS server up with no_root_squash on - which is a security nightmare. Not necessarily a big deal on a LAN you have secured, but between that and the issue of possible data loss, I determined that encrypting the whole disk on the server side was the best course of action.

On-the-fly whole-disk encryption on the server side sidesteps the issue at the cost of CPU cycles on the server. Once you've encrypted the disk, all there is to it is to secure the networking protocol itself (such as a password for samba shares). Plus if it's a headless file server, it can probably spare the CPU cycles to do the on-the-fly encryption itself.

[nakarti]

(Hate to resurrect old threads but this was third in Google search "truecrypt over nas")
I was looking for whether the concern mentioned here (corruption) existed, but this thread also reminds me: If you encrypt/decrypt at the NAS, you have unencrypted data going across the network. This kills half the reason to have encryption in the first place, and IMO the more important half (especially over wireless. The other half is 'if my disk is stolen, people can't access the data on it.')

Do you have a NAS encryption solution that does client-side encryption/decryption and still handles multiple-access?

[droidhacker]

(Hate to resurrect old threads but this was third in Google search "truecrypt over nas")
I was looking for whether the concern mentioned here (corruption) existed, but this thread also reminds me: If you encrypt/decrypt at the NAS, you have unencrypted data going across the network. This kills half the reason to have encryption in the first place, and IMO the more important half (especially over wireless. The other half is 'if my disk is stolen, people can't access the data on it.')

Do you have a NAS encryption solution that does client-side encryption/decryption and still handles multiple-access?

In *most* cases, your local network is considered to be "secure". Unenecrypted data over a local network is only a security risk when hostile adversaries have physical access to that network WHILE the data is being transferred over it. Further, use of a switched network rather than old fashioned network hubs causes the unencrypted data to be transferred directly between server and workstation. Another machine on that switch won't have access to the data at all.

On Wifi, obviously there is some additional security risk, however, wifi data is itself encrypted. Use a strong cypher on your wifi.

Your other option at this stage, if you are truly worried about unencrypted data on your local network, is to implement IPSEC on your network. In this way, the communications will be further encrypted on the network, regardless of the transfer protocol.


To be completely honest with you, given that this is a home network (i.e., topic of this thread), you are the one with full physical control over it. Worrying about encrypted transfers there is going WAY overboard. The only thing you really need to worry about is the encrypted storage.


That is, unless you KNOW that you're doing something completely illegal and have black helicopters circling continually, in which case some FBI might have broken in while you were out and rewired the internals of your network switch to transfer everything out to the windowless black van parked out in front of your place. However, if THAT'S going on, then they have microscopic cameras pointed at your keyboard to steal your passwords anyway, so you're SOL.


Have fun!

[nakarti]

Well, Truecrypt is the 'I'm doing something illegal in my country, so how can I avoid them knowing about it when they come for me' encryption software, so my comments are valid in context. Also wifi encryption is much easier to break with lots of traffic, so I generally don't consider data across it totally safe.

[droidhacker]

Well, Truecrypt is the 'I'm doing something illegal in my country, so how can I avoid them knowing about it when they come for me' encryption software, so my comments are valid in context. Also wifi encryption is much easier to break with lots of traffic, so I generally don't consider data across it totally safe.

As I said, it really depends on what KIND of wifi encryption you're using. WEP and you're dead in an instant. There are some certificate based options that work very well.

As far as the use of truecrypt to avoid detection of illegal data, it doesn't help.
I.e., WTF is all this seemingly-random crap sitting here?

Data is never random. A disk will contain the remainder of files that have been deleted, or will tend to be zeroed out, neither of which leaves anything that even REMOTELY resembles randomness, as truecrypt does.

[Gareth Jones]

Well, Truecrypt is the 'I'm doing something illegal in my country, so how can I avoid them knowing about it when they come for me' encryption software, so my comments are valid in context.

Don't fool yourself. File-system encryption alone won't protect you from law enforcement etc. True, it can be applied so that they cannot recover the content of your file-systems, but by the time that they're actually looking it's likely already too late. They must already have enough evidence to suspect you, and it's a criminal offence to withhold the key (in the UK). Either way, unless you are essentially innocent and willing to hand over the key to prove it, you're in real trouble by then.

The normal domestic reason for encryption is to prevent criminals from getting access to you personal files, logins, bank details or anything else they might abuse, should your computer or removable media be misplaced or stolen (or thrown out without first being wiped or destroyed). Frankly encryption is as basic and important as a login password for domestic security. Companies and government agencies etc. should also encrypt for the same reasons, but as with the population in general, all too often they don't.

[Yellowman]

Don't fool yourself. File-system encryption alone won't protect you from law enforcement etc. True, it can be applied so that they cannot recover the content of your file-systems, but by the time that they're actually looking it's likely already too late. They must already have enough evidence to suspect you, and it's a criminal offence to withhold the key (in the UK). Either way, unless you are essentially innocent and willing to hand over the key to prove it, you're in real trouble by then.

The normal domestic reason for encryption is to prevent criminals from getting access to you personal files, logins, bank details or anything else they might abuse, should your computer or removable media be misplaced or stolen (or thrown out without first being wiped or destroyed). Frankly encryption is as basic and important as a login password for domestic security. Companies and government agencies etc. should also encrypt for the same reasons, but as with the population in general, all too often they don't.

I wouldn't comply as they can only give you a two years sentence (you would serve one year), this is likely to be less than if you gave them access to the evidence to incriminate.

Under Section 49[8] and Section 53[9] of the Regulation of Investigatory Powers Act 2000 (RIPA), it is an offence to fail to disclose when requested the key to encrypted data (with a penalty of two years in prison).

[Gareth Jones]

I wouldn't comply as they can only give you a two years sentence (you would serve one year), this is likely to be less than if you gave them access to the evidence to incriminate.

True, assuming that that is the only thing you end up charged with. Since 9/11 and 7/7 we have some frankly draconian paranoid-state laws that would almost certainly be used/abused if you were suspected of anything that'd carry a long sentence if you were convicted under normal laws.

[japafi]

Your other option at this stage, if you are truly worried about unencrypted data on your local network, is to implement IPSEC on your network. In this way, the communications will be further encrypted on the network, regardless of the transfer protocol.

Have fun!

Not knowing how easy/hard is it to implement IPSEC, one option is to use NFS tunneled inside ssh.
That did take some trial and error though when I set it up.

[droidhacker]

Not knowing how easy/hard is it to implement IPSEC, one option is to use NFS tunneled inside ssh.
That did take some trial and error though when I set it up.

If you're going to use NFS inside SSH, why not just use SFTP? There's a very easy to use FUSE filesystem called SSHFS for mounting an SFTP filesystem.

As far as IPSEC goes, there can be a slight learning curve to it, but once you have a basic understanding of it, its pretty easy to work with and has great flexibility. You can make host-to-host, network-to-network, and host-to-network encryption tunnels with it, and once it is set up, it becomes completely transparent -- i.e., ALL traffic between the end points becomes encrypted on all ports. IPSEC is built into the Linux kernel.

[japafi]

Why?
Cause I wanted to know if it's possible. And to see if it would work better than SSHFS with high latency connection (3g). It didn't, performance was the same.

SSHFS is way easier to setup and quite fool proof.