Slashdot Mirror
TrueCrypt 4.3 Released
RedBear writes "A new update to the best open source transparent encryption software has been released. TrueCrypt is (the only?) open source encryption software capable of creating and mounting encrypted virtual disk images that can then be worked with transparently like any other storage drive, with data encrypted and decrypted in real-time. These virtual disks can be created as files, or entire partitions or physical drives can be encrypted and mounted transparently. Sadly there is still no Linux GUI or Mac OS X port in sight. If you are one of the thronging hordes who have been patiently awaiting ubiquitous multi-platform encryption, please consider donating time or money to the cause, and add your voice to the forum." From the site:"Among the new features [are] full compatibility with 32-bit and 64-bit Windows Vista, support for devices and file systems that use a sector size other than 512 bytes (such as new hard drives, USB flash drives, DVD-RAM, MP3 players, etc.), auto-dismount when a host device (e.g., a USB flash drive) is inadvertently removed, and many more." Read on for more features of TrueCrypt and cached versions of all the links above.
Also including features like plausible deniability, steganographically hidden volumes, unidentifiable partition headers, traveler mode, and your choice of the strongest available encryption algorithms up to and including multi-algorithm cascades. TrueCrypt is practically the Holy Grail for advocates of free ubiquitous encryption. Now, if only it were platform independent.
To reduce load on their servers here are some Coralized versions of all the links:
TrueCrypt home page
Future development goals
Forum thread about Mac OS X version
Donations page
General forum
Plausible deniability
Hidden volumes
Traveler mode
Encryption algorithms
Multi-algorithm cascades
Version history
Also including features like plausible deniability, steganographically hidden volumes, unidentifiable partition headers, traveler mode, and your choice of the strongest available encryption algorithms up to and including multi-algorithm cascades. TrueCrypt is practically the Holy Grail for advocates of free ubiquitous encryption. Now, if only it were platform independent.
To reduce load on their servers here are some Coralized versions of all the links:
TrueCrypt home page
Future development goals
Forum thread about Mac OS X version
Donations page
General forum
Plausible deniability
Hidden volumes
Traveler mode
Encryption algorithms
Multi-algorithm cascades
Version history
you dont have to install it. so there is no way that any researcher can discover it was used.
I can not believe that the other encryption software out there is not even 1/20 as good as truecrypt.
you can hide your data pretty easy with it.
Do not look at laser with remaining good eye.
What are the advantages of this software over using an encrypted disk image created with Tiger's build-in Disk Utility?
These stories are free but worth money.
"from the windows-only-alas dept."
Not really, you can download ubuntu binaries from their download section.
I share your skepticism. Any product that makes those kind of assumptions needs to really back itself up. But if it's true? Sweet.
Karma police, arrest this man. He talks in math. He buzzes like a fridge. He's like a detuned radio.
In fact the Linux kernel itself has had support for many of the capabilities quoted here for a long time now, already starting with kernel 2.6.4 when they basically started to push dm-crypt in favour over cryptoloop. Probably not nearly as much stuff to click on as with TrueCrypt, but there is cryptsetup and the LUKS project which aims for similar goals.
Why do you need a linux GUI for something like this? I installed debian etch a while ago and noticed encrypted partition was a an option along with normal filesystems, RAID, and LVM. So I tried it out. It was quite simple to setup. I made an encrypted / and an encrypted swap partition. Then when I booted into freshly installed system I had to enter my passphrase for each partition and after that it was just like a normal system. I didn't even notice any I/O performance loss. (Although I still went back to a RAID system after the experiment since I am not paranoid enough to sacrifice any performance or space yet :)
Only pirates, terrorists, and criminals need encryption. :)
I'm using dm-crypt with cryptsetup. Works great.
Exactly as described? Does Disk Utility let you create hidden volumes (indistinguishable from the main encrypted volume unless you know the key), or encrypt an entire partition, or use a file instead of a password as the key?
Visual IRC: Fast. Powerful. Free.
They're too busy moving their pr0n collections to new TrueCrypt disks.
allows you to create encrypted disk images that operate exactly as described.
I don't expect you to read the article, but at least read the summary. Does disk utility give you plausible deniability, steganographically hidden volumes, unidentifiable partition headers, traveler mode, and your choice of the strongest available encryption algorithms up to and including multi-algorithm cascades?
I'm afraid this is definitely an area where os x lags.
There are shills on slashdot. Apparently, I'm one of them.
(Along with anarchy and freedom. But I think the subject is more likely just now.)
I had the recent misfortune to forget the password to an encrypted file. It has stuff that isn't that important or/and can be replaced, but the point is, it takes time to replace this sort of stuff (if it can be replaced). The reason is simply, running on a laptop, if it falls into someone elses hands (and they manage to get past the various passwords (reset the BIOS, insert KNOPPIX away you go)) I don't really want them to have that stuff.
I know it is possible to make a back up of the head of the file (or partition), and in the case you do forget the password you can simply replace the head with the back up (with a known password). However, I didn't do that.
I do, however, know the approximate password (where is x is a number or character or blank), it is something like xxxsomewordxxx. Having a dictionary and brute force attack ability on the password would potentially recover my stuff with little effort (have you ever tried typing in hundreds of different passwords? Changing one byte at a time! It sucks). It would also have the added advantage of telling a user if they have a poor password (though I guess you don't really need this system to do that).
I know it is Free Software, and as such I really should either program it myself or pay (or whatever) someone else to do it for me. But I'm not a very good programmer, and my languages (Java and PHP) aren't really relevant I don't think. I also don't have the (people) networks to contact people who might know how to do it.
Shit happens, take greater care next time.
The moral of the story? Be sure to back your stuff up. And make sure you have a non-encrypted copy somewhere if it is important that someone else know about it if you die (or something else happens). And also write your password down. (That is another thing, a whole bunch of passwords are in that file! For things like Internet banking and so on. Damn it.)
I wank in the shower.
Truecrypt provides provides plausible deniability using steganography, so if you are forced to reveal the password, you can mount the "outer" filesystem and still have a hidden volume inside of your encrypted image. This is the only open source cross platform software capable of this that I'm aware of.
I am, actually, a mathematician (though not a cryptographer), but I could've sworn that doing "cascades" like this is actually a bad idea, mathematically? I seem to remember times where it can actually *weaken* the overall level of protection if you just do it carelessly without regard to the mathematics.
Other than that, it is a very nice little program.
I don't know about you, but I have certain bits of stuff that I would prefer to remain encrypted up until I want to use them. The obvious one for most people is stuff like porn (or pictures of your significant other in various states of undress).
But beyond those two (which I admit I have both, in separate containers) what about the spy (industrial or otherwise), what about the activist, the journalist and so on?
They want to be able to turn on their computer and use it for whatever, and then if they need access to that special information, then (and only then) access it.
It also allows another level of plausible deniability (if you have a person who doesn't know much about computers or is in a hurry) added to that of the double layer mentioned in the summary.
I wank in the shower.
think TrueCrypt is "the only" one.
Clipped (and truncated) from the website:
512 bytes encryption? Way to go! Using SE Linux and 512 keys i don't really think i should even consider of the "necessity" of Treacherous Computing
I just wanted to point out that TrueCrypt differs from most other disk-encryption-tools mentioned by my fellow posters in that it also supports 'hidden volumes', which allows a user (for example if forced to give out a password, since the existence of an encrypted volume seems suspicious) to give out a password, which simply shows a 'bogus' partition - but there is no way to prove that the password that was provided is not the 'important' one, or for that matter it's impossible to prove that such a hidden volume even exists.
Loop-aes was deprecated because there were problems with the implementation IIRC (use dm-crypt instead!). Also if you put it in the fstab, that means EVERY SINGLE TIME YOU BOOT you have to be at a keyboard to enter in all the passwords before the system will finish booting (and then you only have protection while your machine is off!)
A GUI to mount/umount a volume would be useful to just setup a little utility with a link say on your desktop so all you'd have to do is click the icon on your desktop/panel/menu then enter the password and it would mount, then just click twice again to unmount. Also you could use the GUI to create the volumes (theres often lots of options in utilities like that, and not everyone wants to check in the man pages every single time they want create a new volume for the perfect parameters).
Also if you use the console you'll leave an on-disk record in your shell's history (which you can edit away, but it will still have been written to the disk, showing that you ran truecrypt and with what options and be possible to recover it).
Truecrypt is a great solution for people who work on laptops and need to cart around sensitive data. On Windows, you can actually encrypt your entire "My Documents" folder. Unfortunately it's quite a bit harder to encrypt the entire user data directory (C:\Documents and Settings\username\), at least I haven't found an easy way to do it yet. Maybe some other Slashdotter has figured this out?
Hopefully hardware-based encryption will become standard soon. I want to boot up, type in my passphrase, and have AES encryption for the entire drive, completely transparent to whatever OS(es) happen to be running on it. The new drives from Seagate look promising in this regard.
Took less than 15 mins to setup the whole thing at the first try and you get to understand the whole thing better.
PS: if you are using kernel 2.16, you dont need to follow the steps in section 4.1 and 4.2.
Enjoy Linux!!
While I support a lot of what the FOSS movement does, I think this is a good example of the overall trend -- it (over)fills very small niches very well, but doesn't do much for the masses.
(Not that Apples are owned by the masses; but that's a different discussion.)
-- I'm old enough to have lived through six different meanings of the word "hacker."
Or is the word rsunc ? Regardless, a lot of people do not realize that a truecrypt volume, although it is a single encrypted file, can be successfully kept up to date with the rsync tool. This is because the entire file is NOT reorganized every time it is unmounted. Therefore, if you only change a few files in a truecrypt volume, you can rsync it to a remote system in an efficient (changes only) manner.
Just be sure to read about the --checksum option. I personally keep all of my most sensitive files in a single, 4 GB truecrypt volume that I rsync nightly to my offsite backup at rsync.net. They are NOT affiliated with the actual rsync project, but I can't speak highly enough about them. This, and especially this are what sold me over strongspace and exavault.
If you have a container X big, one can have smaller containers inside that. The key opens the outer container, but exposes the inside (to use their language). Even if these hidden volumes dont have publically readable containers, one can still see them and delete them.
Incorrect, there is no container file inside the first container, and if you don't enter the password for the second container the same time as the first container you *CAN* overwrite the data in the second container, thus corrupting it.
From the website (If only people would RTFM (no, I'm not new here)):
Protection of Hidden Volumes Against Damage
As of TrueCrypt 4.0, it is possible to write data to an outer volume without risking that a hidden volume within it will get damaged (overwritten).
When mounting an outer volume, the user can enter two passwords: One for the outer volume, and the other for a hidden volume within it, which he wants to protect. In this mode, TrueCrypt does not actually mount the hidden volume. It only decrypts its header and retrieves information about the size of the hidden volume (from the decrypted header). Then, the outer volume is mounted and any attempt to save data to the area of the hidden volume will be rejected (until the outer volume is dismounted).
Note that TrueCrypt never modifies the filesystem (e.g., information about allocated clusters, amount of free space, etc.) within the outer volume in any way. As soon as the volume is dismounted, the protection is lost. When the volume is mounted again, it is not possible to determine whether the volume has used hidden volume protection or not. The hidden volume protection can be activated only by users who supply the correct password (and/or keyfiles) for the hidden volume (each time they mount the outer volume).
Do you Gentoo!?
why do you have pictures of my significant other in various states of undress?
Do you even lift?
These aren't the 'roids you're looking for.
We all do. We thought you knew about it?
How I would attack this stego: I would obtain a sector-logger via ICE or somesuch driver first. Then I would mount the container and proceed to do a "DOD 7 times rewrite" via eraser or somesuch tool. I then would watch what sectors arent affected. Those would be the hidden ones. Essentially I would show hidden places by what isnt touched. It is not BS... It allows you to overwrite the hidden partition (and will gladly do so) UNLESS you provide both the keys to the hidden partition and the outer partition to the program when mounting - and even then, it will just prevent clobbering the inner partition because he knows where it is, but if the outer partition algorithm tries to write on them, it can only fail the operation (it will not use other empty places, and I assume that happens since it would allow an attack like you propose - although if you can sniff mem while it is running with both passwords you wouldn't need such an attack). So, hidden volumes aren't perfect, but don't fall for simple attacks.
Yes, that's fine, but as you pointed out, it's for the LINUX kernel. If you need something that is portable across platforms, transportable on a USB thumb drive and usable under Windows and Linux (and maybe some day OSX), then dm-crypt or cryptoloop is not going to help you.
I use EncFS http://arg0.net/encfs on Linux every day and love it. Even root can't snoop a mounted directory (but could delete the encrypted source directory). How is TrueCrypt better?
An interesting anagram of "BANACH TARSKI" is "BANACH TARSKI BANACH TARSKI"
Your interrogators will just keep pushing you, and you can give them as many passwords as you want, even as many as you can remember or as exist, and they will keep on torturing you until you die.
An interesting anagram of "BANACH TARSKI" is "BANACH TARSKI BANACH TARSKI"
look at the first few bytes of the file and determine that it's a TrueCrypt volume.
The first few bytes of the file contain the encrypted symmetric key for the block cypher, which looks random, just like the rest of the file.
it will even tell you what volume you've mounted - Standard or Hidden
So? By definition that information has to be available or Truecrypt wouldn't know where to read or write. That it's displayed to you doesn't make a difference if someone gets to inspect the running system. Plausible deniability only exists when the filesystem is not mounted (or when you've mounted only the standard volume without the hidden key.) Besides, don't put too much weight on the plausible deniability feature: The deniability is not as plausible as you might think.
I'd like to have a system where all disks are encrypted, but a password isn't needed to mount them.
Problem: I run a server with a RAID-1 setup. After a few months a disk fails. I remove it and want to get it replaced under warranty. The problem is that the disk isn't in a good enough condition to be able to fully overwrite it, and something sensitive could remain in some obscure area, like reallocated sectors. Server stores a quite large amount of rather private data I feel really uncomfortable letting go. What if it gets fixed and somebody else ends up recovering my stuff?
Solution idea: Make the box boot from an alternate media, such as a CD or a flash drive that would contain kernel, initrd and keys. Whole hard disk would go through dmcrypt, then RAID, then LVM. If disk fails, it can be removed and exchanged without leaving anything readable on it. If the boot media is removed any stored data is quickly made inaccessible.
I'd really like to see something like this being offered as an advanced install option in a distribution.
Yes. Seriously. You've been able to do this in FreeBSD for ages.
/dev/md0 /dev/md0 /dev/md0.eli /dev/md0.eli /mnt/secret
dd if=/dev/zero of=image_name bs=1k count=lenth
mdconfig -a -t vnode -f image_name -u 0
geli init -a hmac/sha256
geli attach
dd if=/dev/random of=/dev/md0.eli bs=1m
newfs
mount
okay its a bunch of commands, but I'm basically reading out of the man page. And this setup has tamper detection.
Maybe because the tinfoil hat crowd usually doesn't buy Apple computers.
Errrr right - did you not read the linked thread where all the os x users were asking for a truecrypt port?
While I support a lot of what the F/OSS movement does, I think this is a good example of the overall trend -- it (over)fills very small niches very well, but doesn't do much for the masses.
Right dude, apart from the craploads of FOSS stuff you use on your mac every day? OS X is built on F/OSS - absolutely nothing on the system would run without F/OSS.
Oh, and:
While I support a lot of what the Apple does, I think this is a good example of the overall trend -- it (over)fills very small niches very well, but doesn't do much for the masses.
There are shills on slashdot. Apparently, I'm one of them.
...and just like the previous versions of Truecrypt, all indications are its once again gonna be a little bitch trying to get it to build on FC6.
I use truecrypt because I need to be able to hand over my laptop to a gun wielding thug if it ever comes up. This got me to thinking, if its a virtual filesystem, and seen as such by Linux, what would happen if I put my entire virtual machine on an encrypted partition. Would it then be possible for me to use Linux with TS + Xen (or VMWare if you prefer) to provide an entirely encrypted OS, including its filesystem? I'd assume that I'd need to have no swap (or file based swap, also on an encrypted partition) but that seems pretty doable to me. If my machine gets stolen, then is everything on the encrypted partition as safe as my password?
B) Eliminate all the stupid users. This is frowned upon by society.
If you don't necessarily need plausible deniability, and if you're looking for per-file encryption with just as much transparency and a lot more flexibility, check out eCryptfs. It can be used directly on top of your existing mounted filesystem in Linux. eCryptfs has been in the mainline Linux kernel since 2.6.19. Here is a section in the eCryptfs FAQ that compares and contrasts block device encryption with stacked filesystem encryption:
# compare
http://ecryptfs.sourceforge.net/ecryptfs-faq.html
An unjust law is no law at all. - St. Augustine
If you're using encryption at all, it's because you want to keep something private, right? Now imagine someone discovers an encrypted partition on your computer. In some circumstances (e.g. if you live in the UK), you may be forced to reveal the password, or punished for refusing to reveal it. So you can either accept the punishment, or reveal the files that you thought were private enough to justify using encryption in the first place.
That's not a good outcome. Systems like OS X's are good for keeping your private information out of the hands of hackers or laptop thieves, but not for hiding it from anyone who has any leverage over you: family, employers, governments, etc. In other words, they're good for data you don't want strangers to find, but you need something like TrueCrypt for data you don't want anyone to find.
With hidden volumes, you have another option. When someone demands your password, you can put on a show of resisting, but eventually hand over the password to the main volume, revealing some mildly embarrassing "cover" files - all the while keeping your real private data safely hidden.
Visual IRC: Fast. Powerful. Free.
Now this is nice! Even since PGP took away PGPDisk from the freeware version and Scramdisk went commercial, we've been screwed for open options. I've been using Filedisk: http://www.acc.umu.se/~bosse/ It's Windows and Linux, reliable (used for years with no data losses) and the source is there. But it's very bare bones and a CLI only.
TrueCrypt looks good. It's got a nice GUI, explains everything, has promised not to go commercial and best-yet they give you the option to use MULTIPLE CIPHERS! YAY! As in why choose: Use AES *AND* TwoFish *AND* Serpent. Why other cipher packages haven't offered this is beyond me.
My only bitch: All the online help is on the web. People serious about security work on systems disconnected from the Internet. TrueCrypt *should* be fully self-contained. Overkill? Nah. Consider the case of the Half Life developers: one of them got email with a trojan which found and copied the Half Life source.
Not as bad as I thought: It only goes online for help during volume creation. Once you start TrueCrypt proper there's a PDF.
I run a server with a RAID-1 setup. After a few months a disk fails. I remove it and want to get it replaced under warranty. The problem is that the disk isn't in a good enough condition to be able to fully overwrite it, and something sensitive could remain in some obscure area, like reallocated sectors. Server stores a quite large amount of rather private data I feel really uncomfortable letting go. What if it gets fixed and somebody else ends up recovering my stuff?
Easy solution: Run RAID-5, or RAID-6. There isn't enough data on one drive to reconstruct its contents.
-- If we don't stand up for our rights, now, there will be no right to stand up for them later.
Driver versions being incompatible and not overwritable. For example the thumb drive I carry around uses True Crypt but now next time I plug it into my desktop I'll get the incompatible driver error.
If you wanna get rich, you know that payback is a bitch
Two Words: BIG magnet Expose the drive to an powerful (industrial) magnetic field to realign the bits. Cheaper than making a box to wipe drives, and easier than using any form on encryption.
Actually you are wrong about there not being a Linux GUI. There is actually a pretty good one for KDE. It is Called OneKript:t ent=49071
http://kde-apps.org/content/show.php/OneKript?con
That would need to be the heck of a magnet. From what I hear, a magnet strong enough would bend the platters. If I had the cash and right place (I'm definitely not going to use something like that anywhere near anything valuable) for that sort of thing I wouldn't really worry about getting warranty replacements.
That has some problems.
It'd require an extra disk, which I don't really need right now as I have enough space. Overall it'd be less reliable (3 drives are more likely to fail than 2). It's also a suboptimal configuration for a database server. And it's a lot more error prone, as any component of a RAID-1 can be used independently if needed, while that can't be done with a RAID-5.
My concern is that data can't be recovered from a broken disk sent for replacement, but while it's here I'd like to have as much convenience as possible.
The biggest drawback, and a showstopper for me, is the lack of Whole Disk Encryption. Sure, you can boot Windows XP in a 5GB partition and encryption all of your other partitions using TrueCrypt, however the Windows paging file, Documents & Settings (and all of the hidden files in there), etc. are left unencrypted. I use PGP Whole Disk Encryption for Windows XP and it works wonderfully on my laptop.
I would use TrueCrypt in conjuction with PGP WDE, however, on a secondary harddrive containing, um, "artistic images & videos". There are times you (or a friend / family member) want to use your PC, but not have every drive decrypted.
I think the reason the TrueCrypt developers won't/don't do WDE is due to stupid users. Their support E-mails would be flooded with people who forgot their decryption passphrase wondering how to access their now permanently locked data. Um, hello! That's the whole point of secure encryption - there is no back door!
OpenBSD runs Linux binaries under emulation, does OS X? Could it be made available through fink?
Try using the largest Rare Earth Magnet you can buy. Just be careful to keep it away from every piece of electronic equipment you don't want to damage.
I've written a TrueCrypt-based simple HOWTO for laptop data-security.
Its called "Steal my laptop (I don't care) - Securing laptop-data"
Here's the link to it:
http://ergo.rydlr.net/?p=39
There are flavours for OpenBSD, FreeBSD, and NetBSD. Here's a handy introduction.
Oh well. Ive already taken a mod hit (I dont care). Ill respond to your refutation.
/tmp and /var at most). Of course, TCB on Linux wouldnt be a bad thing, nor would FreeBSD's security levels.
---Incorrect, there is no container file inside the first container, and if you don't enter the password for the second container the same time as the first container you *CAN* overwrite the data in the second container, thus corrupting it.
I am talking about this link in which displays a large container and 2 containers inside of it. The text accompanying it is also sort of misleading. What does worry me is this statement:
"NTFS file system stores various data throughout the entire volume (as opposed to FAT) leaving little room for the hidden volume."
This indicates that the hidden volume is just a free-space volume. This can be attacked by my method: get the 'sucker volume' and swap bits on the files stored to get an idea on how big the hidden is.
---From the website (If only people would RTFM (no, I'm not new here)):
I did read the fucking manual (and website). Free space storage can be 'found out' rather readily. Yes, they do use "advanced encryption techniques" and such, but as they warn, someone who has access to the unmounted volume over many writes can prove there are hidden volumes. This is no good thing in any way. Also there is provided a way to "maintain data security": context levels suggested by Shamir is the way to go, and not the Truecrypt way. Placing multiple sectors along with reed solomon codes would allow rebuilding of partially corrupted hidden files, even if somebody knew the password for a specific context.
Also, how does one prevent Windows from cacheing any of this in places it shouldnt? Does Windows even offer a way to encrypt a swap? Or has one hibernated with this program in memory?
At least with Linux, if Im a user, I know my data is in there, and not leaked through the system (well...
---The hidden volume protection can be activated only by users who supply the correct password (and/or keyfiles) for the hidden volume (each time they mount the outer volume).
I know you didnt say this, but the fact this is a go/nogo is just wrong from a security standpoint.
If the volume is not hidden, it should be easy to verify good/bad password. However, for the application of the hidden volume phrase, it should NEVER acknolodge if you have a good phrase or bad phrase. In addition to that, there shouldnt even be a check for that. The "hidden" phrase should work for all phrases, but only guarantee hidden data security if it is the same phrase.
My ideas are much eviller in terms of data loss, but that is the price of hiding the data in plain sight. Like I said before, check up on StegFS. I use it, and it's very interesting.. It reminds me of a capability system, but filesystem level.
The hidden volume is put in the empty space of the outer volume. You can't tell it's there because all volumes are filled with random bits upon creation. Since a good encryption algorithm's cyphertext looks random, you can't tell if it's still the random data from the format or a hidden volume. You need the hidden volume's key so you can decrypt it and only then will you know that it even exists. When you mount a volume and it asks for a password, it first tries it with the outer volume, and if that fails it looks for a hidden one. So the mounting procedure is identical, only the passwords differ.
The "data retention" (they call it protection) requires the hidden volume's key. If an attempt is made to write to an area that's part of the hidden volume, then the write will be denied and the outer volume will be thrown into read only mode. It must be remounted to be able to write to it again. If you don't give Truecrypt the hidden volume's key and attempt to write over the hidden volume, it will happily oblige because even Truecrypt doesn't know about the hidden volume. You'll corrupt some data, but at least nobody will know it's there. That's the idea.
boldly going forward, 'cause we can't find reverse
You know, that most state laws put restrictions on the tesla strength a magnet has?
If it has over a certain limit (Mythbusters ran against this limit too), it has to be used only by 'licensed professionals'.
Best bet: create an electromagnet.
Can you do full disk encryption on the primary partition - i.e. does it have it's own bootloader yet? This would make it a nice replacement for DriveCrypt Plus Pack...
---The hidden volume is put in the empty space of the outer volume. You can't tell it's there because all volumes are filled with random bits upon creation.
/mnt/steghda/4 and on. What you hide at level 4, 3 and lower cannot see. This is the default capability, and can be separated in that different levels can only see certain levels above them (due to key pairing techniques). Data can still be lost (and is much preferable to data retention) but is mitigated by thoughtful integration of redundancy.
I understand that. I'm not going to challenge if the random # gen is actually random, because that is aside the point.
Instead, if one can watch the sectors and bits changed, one can identify after the "sucker" password is given. A hidden volume can be identified. Also, one would have to be absolutely sure that any parts of the unencrypted system does not contain contextural clues indicating a hidden volume. The work required to prevent the OS from knowing is is drastically greater than just providing a cryptofs or stegofs by itself.
---Since a good encryption algorithm's cyphertext looks random, you can't tell if it's still the random data from the format or a hidden volume. You need the hidden volume's key so you can decrypt it and only then will you know that it even exists. When you mount a volume and it asks for a password, it first tries it with the outer volume, and if that fails it looks for a hidden one. So the mounting procedure is identical, only the passwords differ.
By definition of a hidden setup, one should NEVER know if any password works. The fact this program does let you know if it works or not works indicates that there is known data inside the container. Known data can be successfully cracked much easier than unknown data.
---The "data retention" (they call it protection) requires the hidden volume's key. If an attempt is made to write to an area that's part of the hidden volume, then the write will be denied and the outer volume will be thrown into read only mode.
That is unacceptable. By preventing writes to a range of areas deemed hidden allows mapping of hidden data. In filling up a container with a hidden section, one fills up approaching the boundaries of the hidden one, but never encroaching upon it. In order to prevent hiding, one must allow above all overwriting of data. The loss of data can only be mitigated by creating duplicate sectors around the container (with changing encryption codes locked to your start code + salt).
---It must be remounted to be able to write to it again. If you don't give Truecrypt the hidden volume's key and attempt to write over the hidden volume, it will happily oblige because even Truecrypt doesn't know about the hidden volume. You'll corrupt some data, but at least nobody will know it's there. That's the idea.
But that guarantees data loss at ratings appraching 100%. StegFS has sector duplication techniques to prevent that sort of loss when dealing with security contexts above the level you hid things at. It works by allowing contexts (levels) from 0 to N. If you have security context 4, you have 4 and 3 and 2 and 1 and 0. It appears as
I use it to take banking information with me. Certificates, certain codes... I like to have them with me. I'm not exactly scared that anyone wants this information. I use it in case I lose my USB key: anyone finds it, will have a nice USB key that he can format and put his own stuff on. My banking information will not be visible to them. Just call it an insurance ;-)
No tin-foil here...
Ahhh...the great dumpster continuum. Many a free computer will be found there. -- sowth (748135)
I suspect that suddenly finding plaintext data is a strong indication that the password worked.
Read more deeply into the documentation. There are two ways to mount the outer volume. The first is "outer volume passphrase only" in which case TrueCrypt knows nothing of the hidden volume. Any writes to the outer volume risk data loss on the inner volume. The second mode of operation involves entering two separate passphrases, the second of which allows TrueCrypt to figure out where the blocks of the hidden volume are and avoid destroying the hidden volume. If you get a volume mounted this way, it's trivial to figure out which blocks contain the hidden volume. The problem is that if you have a volume mounted that way, you already have the passphrase to the hidden volume making the whole exercise moot.
An interesting anagram of "BANACH TARSKI" is "BANACH TARSKI BANACH TARSKI"
Actually, there is no need to write anything directly to the registry, Windows will do it for you when you call the Service Manager's functions (that's what you do when you install or start a driver).
The saddest poem
My idea probably isn't all that original but I haven't seen anyone else do it. I wanted relatively secure passwords without having to remember or write down some terribly arcane phrase.
So I wrote a little windows program, which resides on my usb key, that does the conversion for me. For example, I can easily remember the phrase 'fluffybunnyhops' and want to use it as my pw. Put that phrase into the program and the output is: pHl+0F4pHy@!b08Nn!yH20p@$
So all I have to remember is the thing about the bunny and I get a semi-decent password as a result. And since the program result is dumped onto the clipboard, using this method would defeat simple keyloggers that don't grab the clipboard, since all they would see is the unaltered password, not the correct one. Unless there's something about keyloggers I don't know about. I've never played with one before.
Isn't perfectly secure, obviously, but is probably more useful than coming up with a secure password on your own and then forgetting it later.
Check out Private Disk, it has a 'password quality meter', a built-in brute forcer, and a nifty feature called 'disk firewall' among other things. It is not open-source.
As for your original problem - TrueCrypt uses various command line parameters, you can write a script that generates strings that match the xxxxsomethingxxxx pattern and then calls TrueCrypt with the respective command line args. Such a script is easy to write, and your typing speed won't be the bottleneck anymore.
The saddest poem
So long as the VM's disk is on an encrypted volume, that'll work. As you noted, swap is a potential problem. If your VM can mark it's memory as non pageable, that'd probably do the trick.
Can someone comment TripleDES? They DES it once, then decrypt it with the wrong key, then DES again the output obtained at step #2.
Does this really have a positive effect on security? It seems that it does not (according to the other comments), but why did they use such an approach?
There is another type of cascade - apply the same algorithm twice, this is especially effective with ROT13...
The saddest poem
1. there's no hidden volume at the end and there's only a main encrypted volume
2. there is a hidden volume and this was either the wrong password or wrong encryption method tried
3. the entire file is simply random noise and there's no encryption used at all
In that sense, minimal knowledge about the data is available as it's only after a failed decryption effort that you know the decryption didn't work. The way you're suggesting, it would blindly do a decrypt, get a bunch of bytes back and then simply assume those bytes represent a filesystem structure which likely wouldn't be too OS friendly in the case of an invalid password. By preventing writes to a range of areas deemed hidden allows mapping of hidden data. In filling up a container with a hidden section, one fills up approaching the boundaries of the hidden one, but never encroaching upon it. In order to prevent hiding, one must allow above all overwriting of data. Unless you supply the password to the hidden volume at the same time that you provide the password for the main volume, all your hidden data will get completely overwritten as the program has no clue that there even should be hidden data there or not, thereby fulfilling your "must allow all overwriting of data" criterion. But that guarantees data loss at ratings appraching 100%. Indeed, there's no redundancy present. Without actively protecting the hidden volume every time (if there even is one in the first place) then it'll get easily blown away. To prevent this, you can choose to mount the volume as read only and nothing gets lost. But preventing overwriting the hidden data in read/write mode is impossible as it's up to the filesystem driver as to how sectors on the volume get allocated. Though, as you've outlined, there are techniques to overcome a partial loss of data.
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
Does the whole disk encryption support partitions? PGP WholeDisk 9.5 does. at last. Anyway, in about 2 years I am moving towards Seagate full drive encryption and eventually solid state with full encryption, software drive encryption will be a thing of the past.
http://www.rense.com/general79/wdx1.htm
TC is an ace application, especially in that it is cross-platform, making it ideal for dual-booters. but please, give the Linux crew a GUI.
Wow, I checked the replies so I wouldn't be redundant. There is a solution to your sensitive data problem as it is common.
After a few months a disk fails. I remove it and want to get it replaced under warranty
Contact the manufacture. Explain the problem. Most will accept the removed top cover with serial number intact in place of the entire drive for warranty replacement. They offer this service because they do not want to lose volume customers to the competition. Securely dispose of the remainder of the drive in a safe fashion.
The truth shall set you free!
Oh well. Ive already taken a mod hit (I dont care). Ill respond to your refutation.
---Incorrect, there is no container file inside the first container, and if you don't enter the password for the second container the same time as the first container you *CAN* overwrite the data in the second container, thus corrupting it.---
I am talking about this link in which displays a large container and 2 containers inside of it. The text accompanying it is also sort of misleading. What does worry me is this statement:
"NTFS file system stores various data throughout the entire volume (as opposed to FAT) leaving little room for the hidden volume."
This indicates that the hidden volume is just a free-space volume. This can be attacked by my method: get the 'sucker volume' and swap bits on the files stored to get an idea on how big the hidden is.
Except that isn't what happens. The *ONLY* time truecrypt has knowledge of the hidden volume is when you provide the correct hidden volume password. If you don't provide that password, it treats the outer volume as though there is no inner volume. Thus, if you make a change to the outer volume while there is no inner volume information entered/read into truecrypt, truecrypt will allow that hidden volume information to be overwritten. So someone who gets your outside volume password and tries to attack the inner volume by writing data to the free space in the outer volume will be allowed to corrupt the inner volume, thus destroying any data you had there.
---From the website (If only people would RTFM (no, I'm not new here)):---
I did read the fucking manual (and website). Free space storage can be 'found out' rather readily. Yes, they do use "advanced encryption techniques" and such, but as they warn, someone who has access to the unmounted volume over many writes can prove there are hidden volumes. This is no good thing in any way. Also there is provided a way to "maintain data security": context levels suggested by Shamir is the way to go, and not the Truecrypt way. Placing multiple sectors along with reed solomon codes would allow rebuilding of partially corrupted hidden files, even if somebody knew the password for a specific context.
In this context, RTFM is "read the fine material". I believe the warning you are pointing out is the following:
If an adversary has access to a (dismounted) TrueCrypt volume at several points over time, he may be able to determine which sectors of the volume are changing. If you change the contents of a hidden volume (e.g., create/copy new files to the hidden volume or modify/delete/rename/move files stored on the hidden volume, etc.), the contents of sectors (ciphertext) in the hidden volume area will change. After being given the password to the outer volume, the adversary might demand an explanation why these sectors changed. Your failure to provide a plausible explanation might cause the adversary to suspect that the volume contains a hidden volume.
The same is true of stegography, if you hide your data in the unused bits of a jpeg file and that jpeg file data changes over the course of time as you update your data you run into the same issue. That said, you can easilly add an extra level of deniability by just mounting the outer volume in protected mode after you update your hidden volume and write/delete some data. That way sectors all over the container change, and you have your plausible deniability.
Also, how does one prevent Windows from cacheing any of this in places it shouldnt? Does Windows even offer a way to encrypt a swap? Or has one hibernated with this program in memory?
Truecypt flags it's memory to not be swapped, and generally (not always) windows will obey that request. That said, there is a long list of security precautions on their website with the solution and/or workaround for each.
At least
Do you Gentoo!?
Just get one of those things they make to erase videocassette tapes. Its basically an electromagnet that looks like an iron. You push the button and it goes on and erases the videotape. It should do the same thing to a hard drive or any magnetic media I should thing (I only ever tested a floppy).
I'll have to disagree with you here. The registry is a vastly superior method of recording configuration data for many reasons. I won't go into them here (but you can read about it here), but suffice to say there's a lot of good reasons to keep it around.
But there's nothing stopping a developer from using an INI file instead of or even alongside registry entries. If this is done, I think it's very important to use current standards in Windows for such things, and giving the user (or more importantly in a corporate environemnt--the system administrator) the option for how configuration / metadata storage is handled. For example, I think a good policy is to use the registry by default. Include an option to support a config file, and by default make it go to the user profile (specifically, a folder under %appdata%). And lastly, provide an option for the config file to be located in an arbitrary user-specified location, or failing that, the location should be set to the location the binaries are stored. Under no circumstances should you be writing things to c:\, or c:\windows, and other rude behavior like that. Just keep it predictable, and start with the most accepted current standards FIRST. Doing otherwise ends up costing tons of time & money later in extra user support problems.
Let me also add--don't ditch the registry or go your own way because you think it's cool. Have a good reason for it please! Plausible deniability--that's a good reason. Portability (USB key/external drive storage) that's a good reason. Ignorance of standard practices, that's not a good reason. Using the latest fad meta-format, that isn't a very good reason either.
Any judge would view that dodge as the moral equivalent to going around in public all the time with a Zoro mask over your face in order than no-one can conclude that the Zoro mask implies you are up to something.
The same notion shows up in onion routing: you create a fixed rate stream of false traffic (in this case, random sector rewrites under a changed sector key) and valid traffic merely displaces slots in the fake traffic stream, ensuring that there are no shifts in data rate to analyse or correlate.
In a disk scenario, you'd probably want to move the valid sectors around a lot to disguise the active locations. Flash doesn't much like the extra data churn, and harddrives don't like the acess pattern fragmentation. This application is best suited to a "spintronics" solid-state technology (infinite rewrite cycles, fast, low-cost random access). It'll be a while yet before spin reaches the capacities to convincingly front your undeclared eBay earnings with your porn collection.
But, your honour, I happen to like 32x32 icon-base Anime porn!
I once conceived of this in a Russian doll format: each password supplied decrypts half the remaining unencrypted capacity. When questioned, after each broken limb, you reveal another password, but there is always another smaller region where your secret secret secrets reside. Eventually they throw you into the river. If you drown, you were telling the truth that the last password didn't exist.
Russian proverb: Not wise to get into a pissing competition with a rubber hose.
Given that your sysadmin has decided that s/he doesn't want you plugging in random media with god knows what on it this is a feature not a bug. Linux is doing what it's supposed to be doing. If you have a legitmate reason for adding this media to the system then request that your admin makes the necessary changes to do this.
What is the best Open Source file wiper, unused disc area scrubber? I remember when the latter function was actually part of Norton Utilities. Preference for Windows here.
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
Truecrypt works on Linux, and is planned to work on Mac too.
Only problem there is that I'm not a large customer, just a normal guy with a server in the closet
it appears that there has never been a third-party review of truecrypt's source:
truecrypt code analysis
http://forums.truecrypt.org/viewtopic.php?p=23552
All of the first comments are hidden. You need to install TrueCrypt to see them. And let me tell you, there was one hilarious one about Soviet Russia...
At least in the U.S., (adult) porn won't put you in jail. Many other things, including certain types of software, potentially will.
... it might be good to develop an interest in homo-erotic behavior, because you might be in for a lot of it from your cellmates.
You can watch people shitting on each other to your heart's content, but if the wrong people take note of your work on something like libdvdcss and really want to mess with you, well
There are probably other parts of the world where you'd want to disguise things the other way around.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
That's exactly what I use it for as well. That and for portable Firefox / portable gaim so I can browse without having my history/cookies/accounts/whatever easily discoverable if someone grabs my USB drive.
It's a great use, and that's all I use it for.
Only problem there is that I'm not a large customer, just a normal guy with a server in the closet
Again, contact the manufacture. Your milage may vary.
The truth shall set you free!