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

Comments

huh?

[Vegeta99]

Wow. No comments? I smell a Slashdot bug. Or nobody cares?

Re:huh?

[Guntram Shatterhand,]

I share your skepticism. Any product that makes those kind of assumptions needs to really back itself up. But if it's true? Sweet.

Re:huh?

[Anonymous Coward]

They're too busy moving their pr0n collections to new TrueCrypt disks.

Re:huh?

[Chapter80]

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

Re:huh?

[Anonymous Coward]

>Wow. No comments? I smell a Slashdot bug. Or nobody cares?

Best first post ever 8-).

The coolest part.

[Lumpy]

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.

Re:The coolest part.

[Eddi3]

"you dont have to install it. so there is no way that any researcher can discover it was used."

That's not entirely true. When TrueCrypt opens, it installs a driver (in Windows). This driver remains there unless you remove it. In fact, I just had to manually remove it because the old version of the driver was already installed, and the new version of it couldn't override it.

Don't get me wrong, I absolutely LOVE TrueCrypt, I use it everyday, however it's not entirely true that it leaves no footprint. At least, not in my experience.

  -Eddie

Re:The coolest part.

[Anonymous Coward]

there is no way that any researcher can discover it was used.

wrong, if you read the info on the site about "traveller mode"

After examining the registry file, it may be possible to tell that TrueCrypt was run (and that a TrueCrypt volume was mounted) on a Windows system even if it is run in traveller mode.

so it still writes to the registry and so can be discovered by forensics in an instant
why it writes to the registry really needs to be addressed, i wish apps went back to the old .ini method of storing config data, much more secure and no messing in the registry looking for obscure keys and entries, deleting a single ini file is a lot easier than digging through the registry

Re:The coolest part.

[Anonymous Coward]

from the truecrypt site:

Traveller Mode

TrueCrypt can run in so-called 'traveller' mode, which means that it does not have to be installed on the operating system under which it is run. However, there are two things to keep in mind:

        * You need administrator privileges in order to able to run TrueCrypt in 'traveller' mode.
        * After examining the registry file, it may be possible to tell that TrueCrypt was run (and that a TrueCrypt volume was mounted) on a Windows system even if it is run in traveller mode.

If you need to solve these problems, we recommend using BartPE for this purpose. For further information on BartPE, see the question "Is it possible to use TrueCrypt without leaving any 'traces' on Windows?" in the section Frequently Asked Questions.

Re:The coolest part.

[apathy maybe]

Added to what the other people have said, in GNU/Linux, you have to use a command line. Which gets added to the history. And if you don't know how to delete the history (or if you don't know it exists) ...

Re:The coolest part.

[Eddi3]

Generally, Windows itself keeps the names of files that have run recently, and that's probably what they're refering to, not TrueCrypt's settings. In that aspect, no executable on Windows can leave absolutely NO footprint. Of course, these registry entries can be removed manually.

In fact, TrueCrypt's settings are maintained in a file called Configuration.xml in the same directory as TrueCrypt.exe, in order to remain truly portable.

Re:The coolest part.

[SirTalon42]

Don't forget that to load drivers you have to modify files on the system (unless you use an ugly hack, but then the driver may be swapped out which can be Very Bad (TM) in some situations (especially if the key is swapped out!).

Re:The coolest part.

[Anonymous Coward]

Rename truecrypt on your thumbdrive to vi. now all it shows is that you ran VI from /mnt/sda1/utilities

Now if you can get that I ran the trucrypt binary that was renamed to vi on that thumbdrive then you are an incredible researcher and need to be working for the FBI/NSA right now.

leave the history intact. it shows I ran VI.

Re:The coolest part.

[Lumpy]

windows writes last ran items to the registry. Simply renaming the executable to notepad.exe will solve that problem. If truecrypt writes anything to the registry then it does have a major flaw, I need to look further into that.

Re:The coolest part.

[stuuf]

But if you have to run it from the command line, you probably need to give it command-line arguments. Do truecrypt's typical arguments look like typical vi arguments?

$ unset HISTFILE

Re:The coolest part.

[CastrTroy]

Easy, Just ensure that you're home partition is encrypted.

Re:The coolest part.

[computer_guy57]

Also, IIRC when you use it on Windows, even in traveler mode, it might make registry entries that might linger around. It is possible that soneone dedicated enough could find out that you've been using it.

One other downside worth mentioning is that on Windows you have to have administrator rights on the machine to use it.

Re:The coolest part.

[jeremymiles]

One other downside worth mentioning is that on Windows you have to have administrator rights on the machine to use it.

I don't think that's true - I used to use it on my machine at work, where I didn't have admin rights.

Re:The coolest part.

[Ingenium13]

In fact, I just had to manually remove it because the old version of the driver was already installed, and the new version of it couldn't override it.

Really? I just installed it over version 1.2a, and it upgraded fine without any problems.

Re:The coolest part.

[Anonymous Coward]

Steve Gibson has a great Podcast of the Truecrypt utility at http://www.grc.com/SecurityNow.htm (and search on truecrypt - episode 14 from memory.

Davo.

Re:The coolest part.

[pyite]

HKEY_CURRENT_USER

Re:The coolest part.

[xtracto]

And in Linux it is NOT possible to use it in any computer unless you have ROOT access (to install it). I have a 2GB USB stick and I wanted to use half of it as an encrypted drive. In Windows environments I could use it without problems but there is *no* way to access the drive in Linux unless you have root access to mount the device, or unless the computer you are using has got FUSE *AND* you are allowed to mount this file system (sheesh in FC6 I am not allowed to mount a simple USB device unless I've got root access!!).

I love truecrypt for what it is, I have used it but it does not works for what I need it (protect sensitive information in my thumb drive, making it available whenever/wherever I need it). And I *require* Linux support as my work computer is Linux and my home computer is Windows (and I do not have admin access to my work computer as University Policy does not allow it.

Re:The coolest part.

[Constantine XVI]

And on Windows, you cannot use it without Admin access, unless it's already been installed

Re:The coolest part.

[fatphil]

WTF?

Have you thought of adding "user" to the mount options in fstab?

Re:The coolest part.

[Ktistec Machine]

> You need administrator privileges in order to able to run TrueCrypt in 'traveller' mode.

This makes it mostly useless. I can't count on having administrative privileges on a computer wherever I am. I've been looking for a solution that is (a) cross-platform, (b) has executables that can be store on a thumb drive, along with an encrypted filesystem image and (c) doesn't require root/administrative access. TrueCrypt looks good for the first two, but fails on (c). Why is administrative access required if "Traveller" mode doesn't install any drivers?

Re:The coolest part.

[Anonymous Coward]

Because there are 2 ways to install drivers, one way is to actually register and install it via the usual interfaces (which ends up saving a copy of the driver). The other way is to actually load the driver at runtime and unload on exit, either way you're still injecting code into kernel space (read: requires admin).

Re:The coolest part.

[xtracto]

WTF?

Have you thought of adding "user" to the mount options in fstab?

Yes I have, but first I will need to find an exploit to get root privileges in such machine in order to be able to MODIFY fstab...
AND if I had root privileges I wont need to change the mount options

DOH!

Re:The coolest part.

[ShecoDu]

Well you could always create a script named vi which runs vi.bin (truecrypt) with the right arguments, couldn't you?

Re:The coolest part.

[zippthorne]

Since you don't know anything about the random computer you have no control over's cache settings, why bother with drivers (or truecrypt) at all? Just use encrypted zip files or equivalent. There's no reason to bother with encrypted volumes or even "believed good" algorithms if you're just going to have plain-text copies sitting in cache or swapfile on random computers you don't own.

Re:The coolest part.

[fatphil]

This is therefore not a truecrypt/linux issue, this is a you/sysadmin issue.

You wish to violate the restrictions that your system administrator has imposed, and you're blaming linux for not letting you do so.

What was your user name again?
<click click click ... >

Re:The coolest part.

[Kjella]

Since you don't know anything about the random computer you have no control over's cache settings, why bother with drivers (or truecrypt) at all? Just use encrypted zip files or equivalent. There's no reason to bother with encrypted volumes or even "believed good" algorithms if you're just going to have plain-text copies sitting in cache or swapfile on random computers you don't own.

You might trust them, even if you don't have admin rights. For example, I have to work with several clients. It would be good if I can "compartmentalize" my USB stick so that for client A, I only use client A's password, when I'm at client B's site I use client B's password. Hopefully with multiple passwords per container, so I can have my "common" password to unlock everything for myself. The first bit you can make happen with encrypted zips, but it's very impractical. The second you can't even make happen without containers, also I'd have to unzip and rezip so many files. Basicly, a container and a keyring is much easier to work with than a bunch of encrypted zips.

Re:The coolest part.

[Anonymous Coward]

I mount my tc volumes all the time on my linux boxes (one Ubuntu, one Fedora) without any problem. I do have root access, but have not had to use them to mount or use my encrypted drives. I just run it as "truecrypt -u /home/hidden/file /home/user/mountpoint" and it works fine. No su, no sudo, etc.

Re:The coolest part.

[petermgreen]

if they haven't locked down the bootloader as well you can use init=/bin/sh on the kernel command line to get a rootshell on linux.

No OS X Port?

[CheeseburgerBrown]

What are the advantages of this software over using an encrypted disk image created with Tiger's build-in Disk Utility?

Re:No OS X Port?

[Apple Acolyte]

You're right, it does not look like there's much of any advantage for OS X users because we have encrypted disk image support built-in and hence no reason to port it. I imagine a lot of work would have to be done to support not only OS X in the form of a Universal Binary but also HFS+.

Re:No OS X Port?

[Anonymous Coward]

Why? Binary compatibility of the encrypted files between win32 and Linux systems.
Entirely self contained EXE and data on a single USB drive.

To be sure, TrueCrypt isn't as friendly as OSX, but OTOH, TrueCrypt is open source, which means if you don't like it, either stay on the version you like forever or change it to what you like. With Parallels, you can run either win32 or Linux AND have OSX and Linux and win32 data file compatible.

I would ask this, how can I open an OSX encrypted file on both Linux and win32, assuming cross platform is really that important to you?

Re:No OS X Port?

[fbjon]

It has some advantages: it's portable, and it has plausible deniability (hidden partitions).

Re:No OS X Port?

[Mr2001]

Hidden volumes, for one. A single image can have two volumes in it, with different passwords, encryption methods, etc., and you can't even tell the hidden one is there unless you know the key.

You can also use any file as the key, instead of (or in combination with) a password.

And you can encrypt an entire partition, instead of putting the image inside another filesystem and letting it get copied around by the defragmenter (which may have security implications for the ultra-paranoid).

Re:No OS X Port?

[Mr2001]

TrueCrypt provides device-level encryption, so it doesn't need to be aware of HFS+ or any other filesystem you use with an encrypted volume. It also provides a few important features that are not built into OS X.

Re:No OS X Port?

[apathy maybe]

Nothing says Apple Fan then a user name like Apple Acolyte.

Unless they are commenting about that Music Company, iTunes wasn't it? Or unless they enjoy playing with snakes with strange naked women (mind you that does sound like fun). Insert other comments here (preferably funny).

Re:No OS X Port?

[networkBoy]

And therein lies its true power.
As an example:
I have a volume with porn in it. The hidden volume contains other things. All I can divulge is that first password and they get a volume of porn. Hey, I was hiding my secrete homo-autoerotic transvestite fetish from my S.O. Nevermind the 15 megs of "unused" space at the end of the volume.
-nB

Re:No OS X Port?

[Simon Garlick]

Why don't you download the source code for Truecrypt, and the source code for OS X Disk Utility, and compare how they implement their respective algorithms. The advantage will be pretty obvious.

Re:No OS X Port?

[Geheimagent]

Hidden volumes, for one. A single image can have two volumes in it, with different passwords, encryption methods, etc., and you can't even tell the hidden one is there unless you know the key.

Won't the partitions be smaller than they should be? Since the feature is well known by now, it's easy to detect.

Re:No OS X Port?

[Anonymous Coward]

nope. you cant detect it as it's all "random looking data" in the empty space.

Yes if you open the fake volume and write files to it you destroy the hidden volume.
which is perfect, open it and add a file, BOOM your data cant be recovered even if they tortured you to get the password.

Re:No OS X Port?

[Anonymous Coward]

It also provides a few important features that are not built into OS X. You could have listed them, instead of just waving your hands.

Re:No OS X Port?

[Mr2001]

Nope.

When you create the (main) volume, it's filled with random data. Formatting overwrites some of that, but the empty space is still full of random bytes. So, let's say you create a main volume on a 100 MB partition, and copy over some "cover" files, leaving 75 MB of free space at the end.

Then you create a 50 MB hidden volume, which is stored at the end of the partition. You put your top secret files in there, dismount it, and remount the main volume. The main volume still says "100 MB total, 75 MB free", and the free space still appears to be full of random bytes (since the hidden volume is encrypted), but they're different random bytes than they were at first.

So no, you can't tell just by looking at the mounted main volume that there's a hidden volume. All you can do is suspect that there might be something hidden in that free space, but you can't prove it - there are no plaintext headers, so both volumes are completely encrypted and appear random without the correct key. TrueCrypt will even let you reformat the main volume, destroying the hidden volume in the process, unless you specifically tell it to protect the hidden volume (using the correct key) when you mount the main one.

OTOH, you might be able to make a snapshot of the entire encrypted partition (without alerting the owner), then come back later and look for changes once you've gotten him to give up the key to the main volume. If the changes are in the main volume's free space, and they can't be explained by creating and deleting files, then you know there's a hidden volume. However, this requires covert monitoring over a period of time while the system is in active use; you can't detect the hidden volume simply by seizing a drive and examining it all at once.

Re:No OS X Port?

[themadplasterer]

o rly? How can you download source code for a utility that isn't open source. "Disk Utility" is not an open source program.

Re:No OS X Port?

[Mr2001]

I did list them earlier, and they're listed on TrueCrypt's site as well as all over the rest of this thread. The main feature is hidden volumes.

Re:No OS X Port?

[Anonymous Coward]

Another nice feature...you can use a key file with TrueCrypt in addition to your password. Generate a nice 16-32 byte key file and place it on a USB drive. Then you have poor mans two-factor authentication. Without that key file on your USB drive it is impossible to decrypt the data. So for instance if you had data you absolutely could not have someone recover it would be pretty easy to simply destroy the USB drive. Like say.. you keep it in your pocket and the police are coming to serve a warrant. Simply destroy the USB drive (sufficiently, to where even the most sophisticated data recovery would fail) and you raise the bar for data recovery significantly to say the last.

Re:No OS X Port?

[Sancho]

Ah ha! Therein lies the obvious advantage!

Re:No OS X Port?

[bendodge]

you can't detect the hidden volume simply by seizing a drive and examining it all at once. I might just be naive (as I have never used TrueCrypt), but I don't understand why you can't just look for the true TrueCrypt driver, run the appropriate TrueCrypt version and brute-force the user password until you get to see everything.

Re:No OS X Port?

[jesboat]

It provides plausible deniability, a lot more encryption options, is open source (which may actually matter to you for crypto), supports efficiently encrypting entire disks, an open disk format, and is probably faster.

OTOH, DiskImaging is more flexible w.r.t to image formats (e.g. sparse images), has identifiable images (which means you can open them without opening DU first), can therefore be integrated with the GUI, and is also usable in other nice places (e.g. asr).

Re:No OS X Port?

[Simon Garlick]

That, believe it or not, is my point. We have no way of knowing how secure OS X Disk Utility is. For all we know every encrypted .dmg can be decrypted with one master passphrase. For all we know the algorithms are deliberately crippled. We'll never know, because we can't audit the source.

Re:No OS X Port?

[mOdQuArK!]

Go look up how long it would take to "brute force" a good key with a good (as in, hasn't been mathematically broken yet) encryption implementation. It's not something you should worry about.

Of course, if someone can access your computer as freely as you've described, it would probably be a lot easier for them to install a keylogger program (or a hardware hack) & get your secret key when you type it in.

Re:No OS X Port?

[bendodge]

They only have to force the user password, not the actual monster key.

Re:No OS X Port?

[Anonymous Coward]

I might just be naive (as I have never used TrueCrypt), but I don't understand why you can't just look for the true TrueCrypt driver, run the appropriate TrueCrypt version and brute-force the user password until you get to see everything.

Brute forcing true crypt takes a LONG TIME. Just using the standard truecrypt executable, it takes about 2.26 seconds per guess on my Athlon 2500+. To put that in perspective, it would take my machine nearly 70 days to brute force a 4 charactor password (Aprox 14 million combos using all the keys normally typeable on the keyboard). Why does it take so long? Because the header contains no hints the app has to try:
  * 11 Encryption methods.
  * 3 hash methods (per encryption method)
  * Try to mount as a normal volume, if that fails, try as a hidden volume (2 choices)

So each passphrase/keyfile has to be computed and least 33 times and applied 66 times before the app knows it failed.

If one knew any of the above settings (except the passphase/keyfile) one could gain 10-30 times the speed. Making even my machine able to crack it in a few days.

Of course a 4 charactor password is weak, and Truecrypt allows passwords of 64 charactors + the use of key files. A proper passphrase/keyfile combo will be un-bruteforceable for the useful life of the protected data.

Not to say that a more intellegent approach to trying to break the password won't work, but brute force is not that intellegent.

Re:No OS X Port?

[ancient_kings]

>However, this requires covert monitoring over a period of time while the system is in active use; >you can't detect the hidden volume simply by seizing a drive and examining it all at once. If we assume we are being monitored covertly and we have a secret secondary partition, is it possible to have TrueCrypt "act like" the user and add many different phoney files and phoney passowrds to that secret hidden partition? The phoney files and phoney passwords should have a distribution of length and timing similar to the users real behavior. In other words, to fool the covert monitors by blasting it with lots of phoney file additions and passwords entries all day long.

Re:No OS X Port?

[twistedcubic]

Then you create a 50 MB hidden volume, which is stored at the end of the partition. You put your top secret files in there, dismount it, and remount the main volume. The main volume still says "100 MB total, 75 MB free", and the free space still appears to be full of random bytes (since the hidden volume is encrypted), but they're different random bytes than they were at first.

Since the random data in the "free space" was created using a well-known algorithm (whatever truecrypt uses) it is not hard to distinguish this from encrypted data, which is definitely not random.

Re:No OS X Port?

[MrTheBunny]

Discloser: I have a Mac and I love it. :)

However, the main advantage would be portability. I use TrueCrypt on my work laptop and on USB or external drives, but I can't open those files on my mac at home. And Vice-versa. It's not a major problem.

Also, the hidden volume feature and the fact that the TrueCrypt disk image cannot be identified as such by looking at its binary content are other advantages over its Mac OS X counterpart (which I also like!).

If I didn't have enough of coding of coding as a full-time programmer I would cheerly give time to this problem. But I like to spend my evenings and weekend away from an IDE. ;)

Re:No OS X Port?

[toadlife]

"Nevermind the 15 megs of "unused" space at the end of the volume." If "Secret Homo-Erotic Transvestite Fetish" is the mild stuff, I'm not sure if I'd want to see the porn on the 15meg drive.

Re:No OS X Port?

[mOdQuArK!]

I was talking about the user's password when I mentioned a "good" key.

Here's a page from Microsoft that does some calculations on how hard it is to brute force a good key:

http://www.microsoft.com/technet/security/secnews/ articles/itproviewpoint091004.mspx

and the followup article about using passphrases:

http://www.microsoft.com/technet/security/secnews/ articles/itproviewpoint100504.mspx

Not lifetime-of-the-universe lengths of time, but any security-conscious individual can certainly make their hidden password long enough so that they'll be long dead before anyone short of the NSA can crack it.

Re:No OS X Port?

[Anonymous Coward]

Encrypted data looks random. If they use a cryptographic pseudo-random number generator to fill up empty space, AFAIK it should be indistinguishable from encrypted data or (if the algorithms used are good enough) truly random numbers.

Re:No OS X Port?

[Geheimagent]

Then you create a 50 MB hidden volume, which is stored at the end of the partition. You put your top secret files in there, dismount it, and remount the main volume. The main volume still says "100 MB total, 75 MB free", and the free space still appears to be full of random bytes (since the hidden volume is encrypted), but they're different random bytes than they were at first.

So no, you can't tell just by looking at the mounted main volume that there's a hidden volume.

All you have to do is fill up the first volume. Either there won't fit enough into it or the second volume will be destroyed.

Re:No OS X Port?

[Anonymous Coward]

Presumably the person looking at the main encrypted volume is looking there because you gave them the key for some reason (maybe they are law enforcement or something), but you don't want them finding the hidden encrypted volume. But what happens if they completely fill up the main encrypted volume? Does it overwrite the hidden volume? If is does error instead of overwriting then that is a dead give away that there is a hidden volume and how does it know where not to write?

Re:No OS X Port?

[Solra Bizna]

Blew mod points to respond to this.

Disk Utility, the graphical application, is not open source. diskutil and hdiutil, the command-line programs it is a front-end for, are open source. I don't know whether the DiskImages framework (which hdiutil could be considered a front-end for) is open source, though. (my guess is "yes")

-:sigma.SB

Re:No OS X Port?

[Mr2001]

Yes, you can fill up the main volume, which will overwrite the data on the hidden volume. TrueCrypt can't prevent that, because it doesn't even know the hidden volume exists until you enter the correct key. An attacker who gets your main key can destroy your hidden data, but he can't read it, and he can't even be sure that there was really anything there to destroy in the first place.

(There is a mode where TrueCrypt will protect the hidden volume from being overwritten while the main volume is mounted, but you have to enter both keys for it to work. Without the hidden volume's key, TC can't figure out which part of the partition belongs to the hidden volume.)

Re:No OS X Port?

[Mr2001]

If your encrypted data doesn't look random, you need to replace your encryption program ASAP. Any patterns in the output are failures in the algorithm.

Re:No OS X Port?

[Anonymous Coward]

But what happens if they completely fill up the main encrypted volume? Does it overwrite the hidden volume? Yes.

Re:No OS X Port?

[Mr2001]

No.. in fact, that would just make it more obvious that you've got a hidden partition. Here's how the covert monitoring might work:

Monday morning, the attacker sneaks in and records a snapshot of your 100 MB partition.

Friday evening, he comes back with guns blazing and forces you to reveal a key. He uses it to mount both copies of your main volume, the current one and the snapshot, and then compares them byte-for-byte. Some of the changes are in files present on the main volume, but other changes are in free space.

He then examines the changes made inside the free space, and finds that there aren't any directory entries or recognizable data - it was random before and it's still random now, only different. He concludes that either (1) you wrote new random data into your drive's free space for some reason, or (2) the free space contains an encrypted volume.

Actually, that suggests a way to defend against such an attack: every so often, write new random data to randomly selected parts of each mounted volume's free space. This is close to what you mentioned, but you'd only do it when there isn't a hidden volume. That way, an attacker will always see these suspicious changes, whether there's a hidden volume or not, and #1 above becomes a believable excuse as long as everyone knows about this feature.

(Of course, TrueCrypt would have to be aware of the filesystem you're using in order to know which parts are free space. And you'd have to be able to turn this feature off temporarily if you ever needed to mount the main volume without possibly overwriting a hidden volume.)

Re:No OS X Port?

[Anonymous Coward]

Wouldn't FUSE (and MacFUSE) be a way of unifying the Linux and MacOS progress on this front?

Re:No OS X Port?

[julesh]

Brute forcing true crypt takes a LONG TIME. Just using the standard truecrypt executable, it takes about 2.26 seconds per guess on my Athlon 2500+.

I think there's an intentional timed delay going on in here. It doesn't take significantly longer than that to attempt to mount a truecrypt drive on my PII-400. A version without the delay should be easy to produce.

Re:No OS X Port?

[julesh]

They only have to force the user password, not the actual monster key.

My truecrypt password is a sentence containing over 10 words, one of which doesn't appear in any dictionary, using unusual capitalisation and punctuation. Admittedly, most of the rest of the words are fairly common, but still: brute forcing this key is going to take a *lot* of attempts. I'd say I easily have at least 2^100 bits of randomness in there. There's about 2^20 in just how you choose to capitalise the sentence.

Good luck brute-forcing that.

Re:No OS X Port?

[julesh]

Actually, that suggests a way to defend against such an attack: every so often, write new random data to randomly selected parts of each mounted volume's free space. This is close to what you mentioned, but you'd only do it when there isn't a hidden volume. That way, an attacker will always see these suspicious changes, whether there's a hidden volume or not, and #1 above becomes a believable excuse as long as everyone knows about this feature.

You'd also have to do it when there *is* a hidden volume, but it isn't currently being used, otherwise the lack of changes in empty space would suggest there was data in that space. I think the only plausible way of doing this would be to have multiple keys and randomly switch between them.

Of course, TrueCrypt would have to be aware of the filesystem you're using in order to know which parts are free space.

TrueCrypt (at least as of the last version, I haven't looked at the new one yet) requires a FS to be FAT in order to be able to make a hidden volume in it.

And you'd have to be able to turn this feature off temporarily if you ever needed to mount the main volume without possibly overwriting a hidden volume

If you're going to be making changes to the main volume, you practically need to also provide the password for the hidden volume anyway, so that it can protect its contents from unwanted changes.

Re:No OS X Port?

[julesh]

TrueCrypt provides device-level encryption, so it doesn't need to be aware of HFS+ or any other filesystem you use with an encrypted volume.

TrueCrypt has to understand your volume format if you want to use the hidden volume feature, because it needs to be able to find unused space in order to initialize the hidden volume.

Re:No OS X Port?

[twistedcubic]

In this case, the precise definition of "looks random" really, really matters. There are many ways you can define it (data doesn't compress, has no "patterns", etc...) but for most well-known encryption algorithms, there is probably a definition completely missed by the creators, which is easy to test. It should not be difficult to distinguish (with good certainty) random data from "random-looking" encrypted data when given the device on which the data was created. It's very popular, but silly, to think that distinguishing "random-looking" encrypted data from random data is hard. I bet *most* scientists (in the appropriate disciplines) could do this in a reasonable amount of time.

Re:No OS X Port?

[bendodge]

http://en.wikipedia.org/wiki/Deep_Crack
This can brute-force a 56-bit DES key in a matter of days. This was built by the EFF for $250,000, so we can safely assume that the vastly better funded NSA can do the same or better.

It get's better: http://www.copacobana.org/
This costs less than $10,000 and takes no longer than a week on average to brute-force a DES key. It is not limited to DES, and can attack any symmetric cipher up to roughly 64 key bits. Examples include CSA (Common Scrambling Algorithm) or GSM A5.

January 13, 2006: Improved code reduces brute-force attack against DES to 7 days

Our new DES design can now be clocked at 120MHz. This reduces the average search time of the DES key space to 7.2 days. The worst case for a brute-force attack is now 14.4 days.

Re:No OS X Port?

[Anonymous Coward]

Now that you mention it, an intentional delay makes sense. I browsed the source and found a couple of Sleep()'s, and the most promising one is a Sleep(2000) in the Init function. If this is the correct call, then removing it would give an immediant 8x speedupspeed increase on my machine (much more on a modern CPU) for brute forcing. Of course, making the password longer (or adding a keyfile) is still effictive against this type of attack.

Re:No OS X Port?

[mOdQuArK!]

Uhhh...brute forcing the key for a symmetric cryptography scheme is a different problem than brute-forcing a user's password. And being able to crack up to 64-bit in a "reasonable" amount of time is a pretty useless feat when faced with 3DES or similar strength cryptographic schemes - that's when you start talking about lifetime-of-the-universe scenarios, no matter what kind of hardware you've got.

Your original argument of cracking the user's password (and taking advantage of the fact that a lot of users pick lousy passwords) was a better argument.

Re:No OS X Port?

[Mr2001]

Not really. The reason it requires the outer volume to be FAT, AFAIK, is because FAT is the only Windows filesystem that won't access the full extent of the disk when it's mostly empty - NTFS puts structures at the middle or end of the disk, where they're likely to be clobbered by the hidden volume.

Re:No OS X Port?

[Mr2001]

It should not be difficult to distinguish (with good certainty) random data from "random-looking" encrypted data when given the device on which the data was created. Do you have any evidence whatsoever for this belief? Because I'm sure the creators of TrueCrypt, and the rest of the crypto community, would love to hear about it.

Re:No OS X Port?

[bendodge]

I know; I just want people to realize that nothing is truly invincible. Also, don't forget some of those quirky mathematicians who do things like break SHA-1...

Re:No OS X Port?

[Mr2001]

You'd also have to do it when there *is* a hidden volume, but it isn't currently being used, otherwise the lack of changes in empty space would suggest there was data in that space. I think the only plausible way of doing this would be to have multiple keys and randomly switch between them. I'm not sure what you mean by switching between multiple keys.

The thing about main volumes which contain hidden volumes is they're a pain to use. You have to supply both keys when you mount, to prevent the hidden volume from being overwritten, and then you still face the possibility of denied writes and a corrupted filesystem when the OS decides to store something in the protected space. Even with FAT, Windows will still sometimes write to the end of the disk when there's perfectly good free space at the beginning.

What that means is the problem you point out, while indeed it is a problem in theory, isn't much of one in practice. You only have to worry about it if you use the main volume a lot more than you use the hidden volume, but in practice, you'll probably use the hidden volume a lot more, and the main volume rarely if ever.

Of course, if you never use the main volume, the modification times on your files will pose another problem. You have a bunch of changing random data in the volume's free space, which you explain by pointing out that TrueCrypt automatically writes random data there when it's mounted, but then the attacker wonders "If you're mounting this volume all the time, why haven't you written any new files since last year?"

TrueCrypt (at least as of the last version, I haven't looked at the new one yet) requires a FS to be FAT in order to be able to make a hidden volume in it. Right, but that seems to be because of the characteristics of FAT, not because TrueCrypt needs to parse the filesystem. FAT is, at least in theory, able to only write its structures and your files to the beginning of the disk, leaving the end untouched. (Whether Windows actually operates that way in practice is another story.)

Re:No OS X Port?

[julesh]

Right, but that seems to be because of the characteristics of FAT, not because TrueCrypt needs to parse the filesystem.

No, it does actually parse the file system to determine which clusters are in use. Of course, this is incredibly easy for FAT. I believe NTFS also doesn't touch the end of the disk unless you need it for storage, although it's much more likely to stick a file out there to reduce fragmentation.

Linux downloads available

[tabo_peru]

"from the windows-only-alas dept."

Not really, you can download ubuntu binaries from their download section.

Re:Linux downloads available

[GenKreton]

Except, the summary implies it is the only opensource method of doing this when, in fact, linux has several others and a few of them are superior (like a few luks implementations using dm-crypt).

Re:Linux downloads available

[Anonymous Coward]

Although it appears that they are only for 32-bit ubuntu (unlike the Windows builds, which also work on 64-bit installs).

Re:Linux downloads available

[Athenais]

Or emerge truecrypt on Gentoo; it apparently is suitable for amd64 as well.

Re:Linux downloads available

[ink]

Yep, I've been using luks under Linux for ages. It works transparently, and is portable from system to system. I don't think that the article submitter has ever used OSX or Linux; both have nice, mature encrypted block systems.

Hell, I used PGPdisk back in the '90s, and it was "all that".

Re:Linux downloads available

[RedBear]

Yep, I've been using luks under Linux for ages. It works transparently, and is portable from system to system. I don't think that the article submitter has ever used OSX or Linux; both have nice, mature encrypted block systems.

Well, think again. I've been using both Linux and Mac OS X for years, with OS X being my primary desktop choice for a couple of years now. I'm very much aware that there are various other encryption software choices for all operating systems, which is why I said (the only?) with a question mark. Back when I was using Linux as my primary desktop I chose to use Mandrake for a while and used the built-in encryption, which didn't actually work as advertised and was only compatible with that version of Mandrake. I had to do my setup and mounting all from the command line because there were no GUI mounting tools that understood how to ask the user for a password if the volume was encrypted. LUKS at the time was just starting out, I think.

Now, looking around real quick I don't really see much that allows me to compare LUKS with TrueCrypt for usability. The LUKS website itself describes it as "the upcoming standard for Linux hard disk encryption". I see there is FreeOTFE for Windows and Windows-based PDAs, and that's great, but it still doesn't do me any good in Mac OS X. I'm also having trouble finding any Linux GUI applications, so apparently not much has changed on the Linux side in terms of usability in the last few years, besides the name of the encryption software. So LUKS is basically in the same boat as TrueCrypt, except there doesn't appear to be any stated focus on such niceties as plausible deniability, hidden volumes and all that other good stuff talked about on the TrueCrypt site.

Now, I'm all about having multiple standards to choose from, but for now I'm going to put my money on TrueCrypt being the first to come to the table with a real cross-platform (Mac/Win/Lin/etc) encrypt solution that can be used by both geeks and non-geeks. If LUKS comes first, I'll be all over it, but I don't see it happening yet.

Re:Linux downloads available

[Anonymous Coward]

For your information, the Ubuntu packages work on Debian etch as well.

Re:Linux downloads available

[ndansmith]

The Linux version of Truecrypt (mostly) works on PowerPC as well. I currently use it with Gentoo on my iBook. What is broken is creating volumes. Truecrypt on ppc seems to have trouble creating the file system on the encrypted volume properly. However, volumes created on x86 (Windows or Linux) can be opened and modified on ppc. It's plenty cross-platform for me.

Re:Linux downloads available

[Library Spoff]

I'm probably wrong but...

Didn't truecrypyt break on ubuntu after you did a kernel update?
I thought i read somehing on the forums about having to recompile truecrypt each time...

or was that only if you wanted a partition such as /home encrypted?

Re:Linux downloads available

[Bazer]

You should really try setting up dm-crypt on fedora.

No GUI but it all boils down to:
1) Adding an entry to /etc/crypttab pointing to a regular partition (fstab look-a-like)
2) Modifying /etc/fstab to auto-mount the created dm-crypt device

You can configure regular and swap partitions this way.

Re:Linux downloads available

[Bishop]

plausible deniability, hidden volumes and all that other good stuff talked about on the TrueCrypt site. That is because real security experts know that plausible deniability and hidden volumes are script kiddie features that don't work in the real work. Both "features" assume unrealistic attackers. In the real world there is little point in pretending that an encrypted volume isn't. The attacker is going to assume that it is regardless of what you claim.

Re:Linux downloads available

[drinkypoo]

The attacker is going to assume that it is regardless of what you claim.

I think the idea is that you can deny it in a court of law. That's pretty useful.

Re:Linux downloads available

[Bishop]

But what does trying to deny crypto in a court of law do? Believing that there is any deniability is naive. It is an arrogant assumption that the attacker is stupid. When a court of law sees random data they are going to assume cryptography. It is going to be tough to convince a court differently. Hidden volumes may give an out, but counting on that is foolish. Assuming that an attacker is going to be able to find all the encrypted data and planning for it is a saner course of action.

Re:Linux downloads available

[drinkypoo]

When a court of law sees random data they are going to assume cryptography. It is going to be tough to convince a court differently. Hidden volumes may give an out, but counting on that is foolish.

The point is that your actual volume is hidden within a decoy volume. You give them the key to open the decoy volume, and they find a bunch of files that won't get you incarcerated.

Assuming that an attacker is going to be able to find all the encrypted data and planning for it is a saner course of action.

There is no plan that will cover you if (for a horrible, horrible example) the law finds your kiddie porn stash.

Actually, along those lines, you might elect to store any naked baby pictures of your children on such an encrypted volume, since the "think of the children" DAs have actually been going after people for crap like that. I know my mom has pictures of me as a naked baby. I'm pretty sure that it's not pornography, yet people have been hauled into court for that kind of shit. Pathetic.

Raarrgh

[psaunders]

If you are one of the thronging hordes who have been patiently awaiting ubiquitous multi-platform encryption

Yes, I am one of the thronging hordes! *stomp stomp stomp*

Re:Raarrgh

[gardyloo]

Shit. And here I originally read it as "thonging hores" and I was all excited that, finally, here was a post worth reading.

    So much for education.

Re:Raarrgh

[Anonymous Coward]

What's a hore?

Mac OS X Has Encrypted Disk Images

[aldheorte]

It's not that much of a tragedy on Mac OS X. Disk Utility, a standard application in /Application/Utlities allows you to create encrypted disk images that operate exactly as described. Perhaps the advantage here is that this is open source?

Re:Mac OS X Has Encrypted Disk Images

[Mr2001]

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?

Re:Mac OS X Has Encrypted Disk Images

[Whiney Mac Fanboy]

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.

Re:Mac OS X Has Encrypted Disk Images

[Natales]

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.

Re:Mac OS X Has Encrypted Disk Images

[Reaperducer]

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.

Maybe because the tinfoil hat crowd usually doesn't buy Apple computers.

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

Re:Mac OS X Has Encrypted Disk Images

[Anonymous Coward]

Overfills? Do you realize that real world uses of this software can have peoples LIVES depend on this software? Are you going to trust your life and the lives of your family to OSX functionality? Windows Vista has built in disk encryption, big friggin deal, encryption in the OS means nothing. It has to be USEFUL, not just to hide your porno from your wife. Encryption is meant to hide secrets, many times very important secrets, secrets people may kill over, secrets that could land you in prison, or in front of a firing squad.

The use of disk encryption in OSX is the fluff here, not TrueCrypt. The stuff in OSX (and Vista) is useless and is only for mundane uses in which encryption isn't even really called for, or for corporate due diligence to protect against law suits. It doesn't save lives.

Since when does high functionality software catering to highly paranoid (rightfully so in many cases) people have ANYTHING to do with the masses? This software does what it does, VERY well, and thats that.

BTW your wonderful OS X is based heavily on open source software, so take that into account before you go around making grand statements about how marginal OSS is and how niche its tools are.

Re:Mac OS X Has Encrypted Disk Images

[Whiney Mac Fanboy]

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.

Re:Mac OS X Has Encrypted Disk Images

[croddy]

No, things like plausible deniability, unidentifiable partition headers, multi-algorithm cascades, and steganographically hidden volumes are not so important to Apple's market, which consists pretty much exclusively of consumers in free nations in the developed world.

For those living in developing nations, the cost of OS X is prohibitive. For those living under oppressive regimes, Disk Utility's encryption is basically a toy. There are people in this world who need to protect data against extremely high levels of scrutiny, and do it for free on 5-year old hardware. This software is an excellent choice for those groups, as it costs nothing and provides very high levels of security.

Or perhaps all those kids out in Tiananmen Square back in 1989 were just part of the "tinfoil hat crowd".

Re:Mac OS X Has Encrypted Disk Images

[Mr2001]

Maybe because the tinfoil hat crowd usually doesn't buy Apple computers. This stuff isn't just for the tinfoil hat crowd.

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.

Re:Mac OS X Has Encrypted Disk Images

[jawtheshark]

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

This really is not _the only_ program out there...

[Thilo2]

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.

debian has transparent encryption

[Danny Rathjens]

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 :)

Re:debian has transparent encryption

[CastrTroy]

The same option is available in the Mandriva install. Although you have to select the advanced option for it to show up. Encrypt your swap partition, along with your home partition, and you probably don't have to worry much about leaking your personal data. There's other stuff in the /tmp and /var folders that you may want to worry about, but not too much that I would worry about.

Re:debian has transparent encryption

[Rich0]

While I agree that transparent encryption is a built-in kernel feature in linux (and has been for some time), one thing truecrypt does offer is plausible deniability with hidden partitions. This allows you to store data in a volume whose existence is impossible to infer (unless you somehow record its existence elsewhere - like in a shell history). You can enter one password and get one set of data, and another password to get a different set of data. If you're threatened and asked to divulge the decryption key to what appears to be a file that could contain an encrypted drive you can give a password which divulges nothing of value to the attacker.

You can't do that with a loopback filesystem in linux. If somebody finds a huge file full of random data and can reasonably suggest that it is an encrypted drive then you're going to have to give up the key or face consequences (beatings, imprisonment, etc - depending on who is trying to get a hold of the data).

Re:debian has transparent encryption

[Anonymous Coward]

What about swap, temporary files, cache, and so on? Are those encrypted too? I think encrypting everything is safer than plausible deniability, especially in a country where there are no cases of compelled key disclosure. It seems the 5th amendment would prevent anyone from having to disclose their encryption key, but it hasn't been tested.

Re:debian has transparent encryption

[Anonymous Coward]

Yeah except when the encrypted files are the names and addresses of couriers for large cocaine shipments and a rival in your organization is attempting to take over your network.... Do you think this is only for hiding from law enforcement? What about if you are a political revolutionary in the united states and have detailed information on members of your organization (who may also have families) do you think the government is going to take you to court? You completely miss the reason this software exists. You are relying on the GOVERNMENT to protect you when you may be hiding information they want? Trust me, you do not need encryption bub. You have no idea who actually needs it and why they need it. Plausible deniability is to keep people alive dumbass. Keep them from getting tortured and their children murdered. Not to hide tax fraud.

Re:debian has transparent encryption

[Anonymous Coward]

You can't do that with a loopback filesystem in linux

Not exactly the same way, you can specify offsets and lengths using losetup, but if your 4GB file only has a 500MB filesystem on it when you decrypt it, they're going to get out the rubber hoses.

Not sure how truecrypt makes filesystem A look like it takes up the whole drive while filesystem B is hidden there as well, ie how to keep data written to filesystem B from looking like corruption on filesystem A.

Re:debian has transparent encryption

[Kjella]

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 :)

Not entirely sure what you're hinting at here with the space bit, the encryption is 1:1 and doesn't consume any space (except maybe a few kb headers), and you can use whatever combination of crypto/RAID/LVM you want, looped into each other. Also if you want an encrypted container you can create that on a current system, the only reason you need the installer is if you're doing encrypted root for full machine encryption, it serves a bit different purpose than TrueCrypt.

P.S. Full disk encryption doesn't help against a compromised machine. Apart from the hardware bugs, people can modify your /boot partition to record your password. It only helps in "cold" forensics, like if someone found/stole your laptop.

Re:debian has transparent encryption

[Bishop]

But plausible deniability will not keep people alive. An attacker willing to resort to violence is not going to stop to consider if the volume is encrypted or not. The attacker will assume it is and proceed accordingly. Proper steganography will hide the encryption and is the correct defense against these sorts of attacks.

Plausible deniability and hidden volumes are script kiddie features.

Re:debian has transparent encryption

[Rich0]

Swap and stuff like that is simple - encrypt with a random key on each reboot. Nothing can be recovered after the system is shut down - even the owner doesn't know the key.

Tempfiles or cache can be stored in tmpfs - with the protection of the encrypted swap.

Re:debian has transparent encryption

[Rich0]

Not sure how truecrypt makes filesystem A look like it takes up the whole drive while filesystem B is hidden there as well, ie how to keep data written to filesystem B from looking like corruption on filesystem A.

Filesystem B uses unused space in filesystem A. If you mount A without supplying the password for B it gets wiped out when you write to A (since there is no way for truecrypt to know B even exists).

And a 4GB filesystem with 500MB of data isn't suspicious at all - do you run all your drives at 99% capacity? Now, if you have a 4GB filesystem and the only file on it is a copy of the GPL that might look suspicious.

Nothing to see here

[Kpt Kill]

Only pirates, terrorists, and criminals need encryption. :)

Re:Nothing to see here

[networkBoy]

Or those of us who would like to store personal documents on our work PCs (allowed by AUP), but would rather not have a snoopy admin remote in and see them, or when the notebook is in for service have the service people snoop around. All they see is a single large file called video.corrupt.save.

While ideally they wouldn't snoop for snooping's sake, we all know there are wanna-be Simons out there :-(

-nB

Re:Nothing to see here

[apathy maybe]

If you are worried, you shouldn't store stuff on work computers at all. Keystroke loggers to catch the password, remote desktop to view where you click or which file you use. Face it, if you don't own the computer (and I mean control), you don't have any security in the face of people like Simon.

Re:Nothing to see here

[wile_e_wonka]

I keep the family meatloaf recipe on a TruCrypt partition. No one has discovered it yet!

Anyway--I think there are legitimate reasons to want to encrypt data. How about a doctor wanting to ensure patient records are private? Or a corporation that has done some research that it doesn't want to get out? Or what about your personal diary (some people, believe it or not, don't think MySpace is the best place for a private diary)? Or what if you work for the CIA and have been stealing data from a small quiet--a little too quiet--Scandinavian company for a couple years...and they find you out and take your computer after breaking your legs? (ok, that last one's a stretch).

I'm sure commenters will add many more legitimate items to this list.

Re:Nothing to see here

[Anonymous Coward]

I don't agree with your theory at all. I assume you are saying that since someone can install a keylogger or a screen capture utility, you should never even bother with encryption or any method of protecting your data, hell, why even have passwords and logins at all. Do you lock your front door? Why, I can just cut the glass on your window and get in that way.

An encrypted volume will protect you from the snooper. It will also protect you from the default tools that are available to a Windows admin out of the box. Like preventing someone with admin rights from typing \\your_computer\c$\Documents and Settings\your_name\My Documents and seeing what you have there. It will also prevent someone searching for *.jpg on \\your_computer as well. It will prevent the hardware technician from browsing your files while he has your computer to replace the memory. You are correct, a keylogger and screen capture utilities can see what you are doing but if you have that stuff going on at work at random or as a normal practice, you have other problems far more serious then some jpg files on your HD to worry about.

Re:Nothing to see here

[dtzWill]

Only pirates, terrorists, and criminals need encryption. :) ...which according to the media industry and the US government is just about everyone. :-D

Re:Nothing to see here

[Anonymous Coward]

Mod up the parent, anyone?

Re:Nothing to see here

[Anonymous Coward]

nonono - the real use of this software is to store all those pictures and um, videos of your ex-girlfriend(s) on your home PC...

Re:Nothing to see here

[apathy maybe]

I'm saying, that if you are worried about people like Simon (the BOFH if you didn't know), then you should not have personal stuff on your *work* computer.

Because, unless you actually control the computer, then these things are possible.

So, no I am not saying don't ever use encryption. I'm saying don't *rely* on it it situations where you can not control the computer (mind you, having a key file does go some ways to mitigate the problem).

I'm an anarchist and an activist. I don't really want the government (any government) looking through my files thanks.
I have a laptop and a USB key. If I lose them, I don't want whomever finds them looking through my files thanks.

Re:Nothing to see here

[fatphil]

... including the media industry and the US government.

Re:Nothing to see here

[networkBoy]

I understand your point, but nonetheless think it is flawed. I realize that other measures could capture the requisite data, but in all honesty the average helldesk Simon wannabe won't be likely to be that resourceful. Protection of the files when out of my immediate control is good enough.
-nB

Re:Nothing to see here

[Ed_Pinkley]

The secret is it's made of real family!
I've said too much, haven't I?

Not the only one

[Hangeron]

I'm using dm-crypt with cryptsetup. Works great.

FileDisk: Window and Linux and OS X, Oh My!

[Anonymous Coward]

Well, there's FileDisk, which is a Windows driver that will do the same thing and is compatible with encrypted disks on Linux. Since most (all?) of that work is released under F/OSS licenses, I bet there is an OS X port as well. If not, someone could create one.

There's even instructions for using this to create an encrypted USB drive that can move between Linux/Windows.

Donate?

[Qwerpafw]

If there is no port in sight, why would I donate? Once they announce a port and start making headway, that's when my wallet will become interested.

Re:Donate?

[Anonymous Coward]

Yeah right. Then you'll wait until another feature is added. Of course, in the mean time you'll keep using it since it is free. Hypocrite.

Brute force attack built in, is what I want

[apathy maybe]

(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.)

Re:Brute force attack built in, is what I want

[SirTalon42]

Or, just remember your password. It really isn't that hard to do!

You could always use something like jack the ripper to try and brute force your password. You'd still have to produce your own dictionary file though.

Re:Brute force attack built in, is what I want

[Anonymous Coward]

The problem is that brute force simply isn't effectively against this type of cryptography. Even if you know part of the password, it could take hundreds of years of processing on the world's fastest supercomputer to break through it.

Re:Brute force attack built in, is what I want

[Anonymous Coward]

That's why you wait six months, and buy a new box for $600 that's twice as powerful as last year's supercomputers. Technology is a wonderful thing.

Re:Brute force attack built in, is what I want

[Anonymous Coward]

it's oldskool in extremis, but search for "claymore brute force". might help you in the future.

Re:Brute force attack built in, is what I want

[vhold]

Hmm, it's an interesting story. If you are encrypting things that are vitally important to you, but you don't really care about the privacy enough that you are willing to keep unencrypted backups or write passwords down, perhaps you should just use weak encryption that can be reasonably broken, or simply weak passwords.

Re:Brute force attack built in, is what I want

[Anonymous Coward]

"The problem is that brute force simply isn't effectively against this type of cryptography. Even if you know part of the password, it could take hundreds of years of processing on the world's fastest supercomputer to break through it."

what sort of cockshite is that? Sure, it might take hundreds of years to bruteforce the actual 1024bit private key, but the 14 character password that protects that key? a couple of weeks, tops.

Re:Brute force attack built in, is what I want

[Sancho]

The best solution is an unencrypted version with strong physical security (i.e. a safe, or the equivalent). You use the encrypted version most of the time because, simply, it is easier to work with. If you lose the password, open the safe to recover it.

Re:Brute force attack built in, is what I want

[Maltheus]

Actually Java provides a CipherOutputStream supporting all of the AES candidates right out of the box. It wouldn't be too hard to write something yourself. Although for real security, I'd put my trust in the experts. You can screw up encryption if you do it wrong. Truecrypt is pretty slick and the price is right.

loop-aes

[Anonymous Coward]

What's wrong with loop-aes http://loop-aes.sourceforge.net/ and why the heck does somebody needs a GUI to mount a volume??? There's fstab for that.

Re:loop-aes

[apathy maybe]

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.

Re:loop-aes

[SirTalon42]

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

Re:loop-aes

[Anonymous Coward]

>Loop-aes was deprecated because there were problems with the implementation IIRC (use dm-crypt instead!)

That was cryptoloop with the implementation problems. dm-crypt isn't bad, but loop-aes is the clear winner for data protection. There's a whitepaper out there comparing them all. loop-aes isn't in the kernel because the group never got their act in gear enough for that. However, it is maintained well enough if you want to patch. Loop-aes is the fastest between itself and dm-crypt. I don't know if cryptoloop is faster than either of them, but considering the major security holes in it, I never bothered trying to find out.

>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!)

That's the point. If you can't be bothered to memorize a password and salt, and you can't be bothered to type that in when you turn on your machine (what, every few months?), you just don't have strong encryption! What's next, the computer booting straight to a root shell because typing the password is too much effort?! :-) There are ways around not being able to ssh in and enter the password (Set up an initrd with basic networking and ssh that lets you enter the password, mount the true root volume, and boot it... not all that impossible).

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

I'm sure someone here could whip that up in Perl/Tk for loop-aes in an hour or two. I'm no programmer, so I won't bother...

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

One of the benefits of loop-aes, if you use with an initrd boot setup on read-only media and encrypted root is that the only thing someone could ever know is that you have an encrypted filesystem. They cannot figure out anything past that, assuming you manage to unmount root, reboot, or power off before they get their dirty hands on the machine. That goes for any encrypted filesystem -- if they can keep the machine alive, unless it auto-unmounts (also possible to do with loop-aes and some scripting) they have the data.

Re:loop-aes

[larry bagina]

why do you have pictures of my significant other in various states of undress?

Re:loop-aes

[Anonymous Coward]

We all do. We thought you knew about it?

Re:loop-aes

[cortana]

I'm sure someone here could whip that up in Perl/Tk for loop-aes in an hour or two. I'm no programmer, so I won't bother...

Nooo, that would not be very safe. If you are typing your passphrase into an X11 session then there is nothing to stop another X client from stealing it. ;)

Re:loop-aes

[Anonymous Coward]

First, since when loop-aes become "deprecated"? Second, I typically want my encrypted $HOME to be mounted every single time I boot, duh. So GUI is still useless here.

Algorithm Cascades == BAD?

[Anonymous Coward]

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.

Re:Algorithm Cascades == BAD?

[Copid]

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.

My understanding is that in the general case, there's no truly compelling reason to believe that cascades are either stronger or weaker. I believe that there are special cases with certain algorithms, but the people who maintain TrueCrypt are aware of them. I don't recall the exact details, but it's discussed fairly frequently on sci.crypt.

Re:Algorithm Cascades == BAD?

[Anonymous Coward]

If multi-algorithm cascades weakened the protection, that's what the codebreakers would do: encrypt the data again and crack the "weakened" data.

Re:Algorithm Cascades == BAD?

[Copid]

If multi-algorithm cascades weakened the protection, that's what the codebreakers would do: encrypt the data again and crack the "weakened" data.

There's a special case you're not considering: Multi-algorithm cascade with the same key. Arbitrary (and dumb) example: A single cipher in CTR mode. Encrypt once with key k and you're in good shape. Run the algorithm again with key k and your data is plaintext again. It's an extreme case, but one can come up with other more reasonable thought experiments. It's quite possible that two algorithms that are secure by themselves can interact in funny ways when you use the same (or a related) key for both of them.

Anyway, for independent keys, I agree with your assessment. If algorithm B weakens algorithm A when used with an independent key, it's a bug in algorithm A, not in the idea of cascading ciphers.

Re:Algorithm Cascades == BAD?

[andy_t_roo]

only when you use the same encryption scheme. In some cases you can prove that encrypting twice it is equivelent to encrypting once with a different key. In other cases, especially when encryption and decrytion are similar processes, it does weaken the encryption. However if you use different encryption methods the encryption/decryption of 1 method is practically orthogonal to the other method. This does not increase the security as much as you would think, as if you can break the encryption using twice as many "encryption layers" only doubles the amount of work to do, while doubling your overhead in encryption, leaving the ratio of your overhead to their effort of breaking it unchanged.

Ignoring mathematical breakthroughs which render a particular encryption method practically useless, it would be better to use a longer key where, in many situations, each _bit_ you add to the key doubles the hardness of breaking the problem, leading to each extension of the key length moving the overhead/effort to break ration further in your faviour (with an 8k key, assuming a resonable crack, where you only need to check the sqrt of the number of keys (2^4k keys) - this leads to a 10^1000 year breaking time (this assumes 10^200 calcuations/year - way more than theoretically possable).

using 8 1k keys leads to 2x2^512 keys to check (or about 8x10^150 computations)

i know which calculation i would rather have protecting my sensitive data.

an upper bound on the plausible calculation limit (within the scope of this universe) is about 10^100 calculations - the rough number of atoms in the universe ( 10^81 ) times the number of seconds the universe is expected to be in existence (10^18 seconds in 100 billion years)

baring a mathematical breakthrough there are certain encryption methods which are statistically secure for someone with access to the entire plausible computation power which could exist within this universe

Re:Algorithm Cascades == BAD?

[andy_t_roo]

sorry about the hard to read link concerning the number of atoms in the universe - wikipedia also mentions the number of atoms, but gives a figure 100x lower, so i chose the larger one.

the estimate of 100 billion years is also probably 10x to big (13 billion years, 4e17) is a better estimate for the age of the universe. - but even making these optimistic assumptions, we only get to 10^99, leading to the conclusion that anything with a chance less than 1 in 10^100 will never happen within this universe.

Re:Algorithm Cascades == BAD?

[Anonymous Coward]

Well, first of all, see 3DES.

The general idea against stacking is that it really doesn't help, but it *shouldn't* hurt. Shouldn't being the key word here. If you truly trust algorithm1, what do you gain by adding algorithmX? If algorithm1 is crackable, then it is likely so is your chosen algorithmX. You gain no benefit, but you *might* be causing the data to be less secure, especially if there is a known-plaintext attack against BOTH algorithms. If there is a known-plaintext attack against only one, you may be adding security. However, do you know if there are known-plaintext attacks against either? Probably not, or you wouldn't be using them.

So in essence, don't add levels of complexity that may theoretically degrade the strength of either algorithm alone. Trust your algorithm, or use a different one. Adding layers simply adds the possibility to be able to crack any one of them, or perhaps all of them. Most people do not know the true strengths of these algorithms, so at least narrow the field of attacks to a single algorithm, instead of allowing a broader range of attacks by stacking.

It really all depends on how secure the chosen algorithms REALLY are, but not many truly know that info except for potential attackers. In theory, two totally independent algorithms that are truly secure, should not degrade each other by stacking.

Re:Algorithm Cascades == BAD?

[Anonymous Coward]

Theoretically multiple encryption can be weaker than any of the encryptors.
In practice this is very unlikely to happen, but proving this cannot happen with any key is beyond current state-of-the-art.
In practice it is also unlikely that the resulting cipher is considerably stronger than any of the ciphers[1], especially if you consider them all using same key (or key derived from same passphrase).
I'd *much* rather use one well designed cipher than several badly designed, or badly designed key generator, or ...

[1] provided, of course, the ciphers are "sane".

Re:Algorithm Cascades == BAD?

[fatphil]

That's only the case if you've not got an injective mapping, such as when hashing.
If you're injective, such as encryption, then there's no weakness.

Re:Algorithm Cascades == BAD?

[guardian-ct]

If something has a 1 in 10^100 chance of happening, then it has a 1 in 10^100 chance of happening (unless you are using the wrong odds). The chance of it happening in this universe is not "never", but exceedingly small. The likelihood of any of us being around to see it, is extremely small. We're talking small enough it seems to "never happen".

They don't call it Probability and Sadistics for nothing.

Re:Algorithm Cascades == BAD?

[elbarney]

"Ignoring mathematical breakthroughs which render a particular encryption method practically useless"
This is exactly what double cyphering(with different algorithms, of course) is about. It provides a solution against known plaintext attacks, given that the intermediate output is cyphered, so you are protected against this problem, something that longer keys doesn't give you.
And you can always use longer keys, if you like.
Ivan

FreeOTFE?

[Lawrence_Bird]

I have been using this and have no association other than as a happy user. From the description I don't
think TrueCrypt is "the only" one.

Clipped (and truncated) from the website:

FreeOTFE: A free "on-the-fly" transparent disk encryption program for MS Windows 2000/XP/Vista PCs and Windows Mobile 2003/2005 PDAs Using this software, you can create one or more "virtual disks" on your computer - anything written to these disks is automatically, and securely, encrypted before being stored on your computers hard drive.

Features

        * Source code freely available
        * "Portable mode" included; FreeOTFE doesn't need to be installed before it can be used - making it ideal for carrying your data securely on USB drives!
        * Operates under both PC (MS Windows 2000/XP) and PDA (Windows Mobile 2003/2005) platforms
        * Linux compatibility (Cryptoloop "losetup", dm-crypt and LUKS supported)
        * "Hidden" volumes may be concealed within other FreeOTFE volumes, providing "plausible deniability"
        * FreeOTFE volumes have no "signature" to allow them to be identified as such
        * Encrypted volumes can be either file or partition based.

Re:FreeOTFE?

[geminidomino]

Does that one work without Admin privs? That's what kills TC's use for me.

Re:FreeOTFE?

[Eddi3]

I agree.

Also, a quick look at their docs says:

"Note: Administrator rights are required in order to start and stop portable mode."

Re:FreeOTFE?

[Anonymous Coward]

I have used both OTFE and true crypt. They essentially accomplish the same thing. OTFE isn't updated as much as TC and its interface and functionality leaves a lot of room for improvement. for instance you have to install drivers individually for each type of encryption you are using each time you wish to open your encrypted volume. That is why it needs administrator access. I thought the administrator part true for TC as well.

Re:FreeOTFE?

[geminidomino]

It is true for TC as well. Blast it.

Re:FreeOTFE?

[user24]

I just use commandline gpg. sure, anyone can tell there are encrypted files on my USB 'disk', but so what? I'm not a secret agent, nor a corporate informant, I don't actually need plausible deniability.

It doesn't need admin privs, leaves no tracesif set up properly, and is open source. If you want to store multiple files under one encrypted file, slap them in a zip file and encrypt that.
Don't get me wrong, I'm sure there are legitimate purposes for transparent volume encryption, and plausible deniability, but aside from the cool factor, I just don't need them.

Re:FreeOTFE?

[geminidomino]

Hmm... Good point. I forgot GPG was around for windows. :)

I'll have to look at it and see if it can be installed "portable" (that is, on a usb stick without drivers and registry settings).

Re:FreeOTFE?

[geminidomino]

What the hell? Even gpg requires administrator access? Not the plugins or any of that stuff, just the base GPG tells me it requires Admin rights.

Re:FreeOTFE?

[user24]

commandline doesn't. use "--homedir ." when you run it, eg:

decrypt:
gpg --homedir . --force-mdc -q -o %output_file% %input_file%

encrypt:
gpg --homedir . -z9 -q -o %output_file% --force-mdc -c %input_file%

then just have a directory with gpg.exe in it and you're away. I also recommend sdel.exe

Re:FreeOTFE?

[Jherek Carnelian]

Don't get me wrong, I'm sure there are legitimate purposes for transparent volume encryption, and plausible deniability, but aside from the cool factor, I just don't need them.As long as you are OK with your encrypted data leaking out into the clear through your swapfile.

Re:FreeOTFE?

[user24]

oh no! the hordes of expert crackers tailing me will be able to find my FTP password.

also:
"Furthermore, TrueCrypt cannot prevent the contents of sensitive files that are opened in RAM from being saved unencrypted to a paging file (note that when you open a file stored on a TrueCrypt volume, for example, in a text editor, then the content of the file is stored unencrypted in RAM). "
http://www.truecrypt.org/docs/paging-file.php

Re:FreeOTFE?

[user24]

somehow I failed to click reply on your comment and instead replied to myself:

http://it.slashdot.org/comments.pl?sid=227415&cid= 18437183

Re:FreeOTFE?

[user24]

oh, no I didn't. ignore that post.
and this one, for that matter.

Re:FreeOTFE?

[Lawrence_Bird]

well clearly I'm not up on the behind the scenese technical details, but any driver installation happens transparently after the first time.  All I do now
is open the encrypted volume anything else happens automagically.

Re:FreeOTFE?

[Jherek Carnelian]

oh no! the hordes of expert crackers tailing me will be able to find my FTP password.

If the data you encrypting with gpg is so trivial to you, why are you encrypting it in the first place?

"Furthermore, TrueCrypt cannot prevent the contents of sensitive files that are opened in RAM from being saved unencrypted to a paging file (note that when you open a file stored on a TrueCrypt volume, for example, in a text editor, then the content of the file is stored unencrypted in RAM). "

TCTEMP automates the process of using TrueCrypt to on-the-fly encrypt the Windows paging (swap) file...

Beat this...BigBrother

[elkosmas]

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

TrueCrypt also supports 'plausible deniabilty'

[schweini]

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.

Re:TrueCrypt also supports 'plausible deniabilty'

[SamSim]

If I may be insanely paranoid for a moment: that only works as a feature as long as not too many people are aware of it. There must always be a gap between the size of the first encrypted volume and the size of the bogus "hidden files" in the volume, and that gap must be big enough to hide all your genuinely secret stuff. If, for example, you have ~15GB of stuff to hide, but only 50MB of "hidden files" in your 15GB encrypted volume, that's going to raise red flags. You have to be careful.

Re:TrueCrypt also supports 'plausible deniabilty'

[Maltheus]

Then again, AFAIK, you can't resize a truecrypt volume. So even if you're not using the hidden volume feature, it's best to make your volume as big as you think you'll ever need. After all, I have some large unencrypted partitions with very few files on them.

Good interim solution . . .

[scarolan]

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.

Re:Good interim solution . . .

[Eddi3]

How about TCGINA? It's a supported third party add on for exactly what you're talking about.

Re:Good interim solution . . .

[egumtow]

Have you tried the TrueCrypt + MojoPac combo yet? You can you encrypt your user folder, you can encrypt every file, you can encrypt every registry entry.

Re:Good interim solution . . .

[GeePrime]

If you go through the disk management utility, you can actually mount an NTFS drive to an empty NTFS folder. A little known feature in XP. Go through the administrative tools, component management, storage, disk management. If you right click on a partition, and go to "change drive letter and paths" or something, you can put it in an empty folder.

Hope this helps!

Re:Good interim solution . . .

[Anonymous Coward]

I have used it and it works perfectly, in case anybody was wondering.

My clients' laptops are partitioned so that windows + apps are on normal C: and all their profiles are within a TruCrypt volume.

The only difference that they notice is that they get asked a second password, which (after explaining) they like. Most of them have secretaries and/or assistants that eventually get to know their normal domain password but their TruCrypt one is different and not shared.

Re:Good interim solution . . .

[Technician]

Hopefully hardware-based encryption will become standard soon.

FYI, it is on the NAS by Simple Tech, the Simple Share external Network Attached Storage. Works fine. When the volume is un-mounted (power down) it does not re-mount on power-up. To enable the encrypted volume, you have to use a web based configuration utilitie into which the encryption key is entered. The only downside is the key is sent in the clear. For the truly paranoid, use a laptop and unplug the NAS from the net to enter the key to prevent any man in the middle attack.

Re:Good interim solution . . .

[pezzonovante1]

The TrueCrypt 3-rd party tools might help with this.

http://www.truecrypt.org/third-party-projects/

TCGINA encrypts Windows user profiles...I have not looked into if this is C:\Documents and Settings\username\ as you mentioned.

Linux had this a long time ago...

[Anonymous Coward]

Not to say truecrypt sucks (it doesn't) but this isn't a new idea (It made it into tldp almost 5 years ago!) Check out the howto and set it up yourself. Shouldn't take more than an hour (well, it didn't for me, anyways). It's quite efficient; That being said, I *can* feel the performance difference on my RAID setup, it's still worth it.

The real open source option to encrypt your folder

[NovaSupreme]

Look at this section 4.3

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!!

What a load of BS...

[Creepy Crawler]

Why do I call this BS? Encryption is legit and can be proved. Thats a good. And it's open source. Thats good.

They claim to have "hidden" containers. That's false if they guarantee data retention. Why?

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.

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.

If truecrypt prevents me from writing on "stego"'ed places, we also have a easy find. No more plausible... Instead, we MUST, at all costs, allow any user to write over the hidden portions to demonstrate that it's just entropy: nothing. To do this, we must be readily able to sacrifice data to prevent capture.

StegFS does this, however it only works for 2.2 kernels. Too bad it's not being worked on, as this project, along with loopback crypto had real promise for very secure stations (thinking laptops and such with super-sensitive data).

Re:What a load of BS...

[Binestar]

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

Re:What a load of BS...

[Anonymous Coward]

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.

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.

Re:What a load of BS...

[Copid]

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.

More terse version of another response you've seen already: If you do this, TrueCrypt will happily overwrite the hidden sectors and you will get nothing. TrueCrypt will protect hidden sectors ONLY if you say "protect my hidden sectors, and here's the key that will allow you to find them." If you don't do that, TrueCrypt is as clueless as the attacker is as to which "unused" sectors store secret data.

Re:What a load of BS...

[Anonymous Coward]

Gee you really did your research, didn't you?

Try reading up on something a bit before you criticize or start making up imaginary flaws.

Re:What a load of BS...

[Anonymous Coward]

What an idiot... RTFA you dipshit.

Re:What a load of BS...

[Creepy Crawler]

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.

---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... /tmp and /var at most). Of course, TCB on Linux wouldnt be a bad thing, nor would FreeBSD's security levels.

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

Re:What a load of BS...

[enos]

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.

Re:What a load of BS...

[Creepy Crawler]

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

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

Re:What a load of BS...

[Copid]

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.

I think you're really not understanding how this system works. If you only have the "sucker" password, you can manipulate the contents of the mounted outer volume all you want. TrueCrypt, having no clue that there's a hidden volume, will simply overwrite useful data blocks and destroy the hidden volume. Hidden volumes are only protected from corruption if you mount the outer volume with both passphrases. If you don't have the inner volume passphrase, this attack is a non-starter.

By definition of a hidden setup, one should NEVER know if any password works.

I suspect that suddenly finding plaintext data is a strong indication that the password worked.

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

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.

Re:What a load of BS...

[nacturation]

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. My understanding of how it works is that it assumes the random bytes on the end of the file are a header and tries decrypting that using its plethora of decryption methods. If that decryption effort simply returns more random bytes without structure, then there's several possibilities:

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.

Re:What a load of BS...

[Binestar]

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

Re:What a load of BS...

[Anonymous Coward]

best use of this kind of technology would be incorporation in a popular OS (=Linux distribution) which has option to use encrypted non-hidden truecrypt partitions in the installer menu. By default it should reccommend a portion of volume space to stay reserved (i.e. empty), so in this area user could set hidden volume. This actually improves plausible deniability as this is default installer behavior and probably many "innocent" users will have same setup, so it is actually believable and plausible that you are one, and impossible to prove what is contained in empty space.

Installer should also rewrite all of disk/partition data with random bits, so that it isn't suspicious if data looks really random (usually this is only the case if hdd had encrypted partition before).

Re:What a load of BS...

[Anonymous Coward]

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

Truecrypt theoretically reserves a block of final bytes at the end of the file or device to determine if the supplied hidden password was correct. This is no different from the header blocks in the beginning. If it finds a header, then it will "know" the password was correct:

http://www.truecrypt.org/hiddenvolume.php

So long as an attacker supplies a wrong password, Truecrypt will be none the wiser that there is a hidden volume. An attacker's only resort to know if the reserved block is, in fact, a header versus random unused data is to use brute force, which is what we want.

As for the known versus unknown data, any partition-based encryption system will have known data: a partition table. So long as the underlying algoritms have sufficiently large keyspaces and are correctly implemented, then we have minimized the risk. But there is another element: we only "know" the beginning header exists if we can presuppose it's a truecrypt container. We don't *know* that the ending block is a header or not.

Does this make sense, or am I missing something?

Not quite ubiquitous multi-platform encryption...

[Anonymous Coward]

> ubiquitous multi-platform encryption
Not quite without support for OpenSolaris.
Anyone up to porting TrueCrypt to OpenSolaris?

Spread the word - truecrypt volumes can be rsync'd

[enselsharon]

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.

Re:This really is not _the only_ program out there

[Anonymous Coward]

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.

EncFS

[jumperboy]

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?

Re:EncFS

[Creepy Crawler]

Might I remind you that root CAN read /proc/kcore .

Do you have a system in that which memory is encrypted to prevent superuser attacks (TPM)?

Re:EncFS

[Anonymous Coward]

lol, a case where TPM is actually useful for something? I'm sceptical.

Couldn't root have you unknowingly running inside a userspace rootkit without affecting the basic 'integrity' of the OS as far as TPM remote attestation was concerned?

Re:EncFS

[Creepy Crawler]

If the rootkit was signed by the owner of the TPM, it could.

That's why the TPM should be owned by nobody other than the owner of the computer. Anything else would allow tremendous evil.

Dangerous feature

[cortana]

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.

Re:Dangerous feature

[cptgrudge]

If you're going to be indefinitely held while being tortured, until you die or are killed, all the software features in the world aren't going to help you. It's more useful in places where "plausible deniability" can be used to get you out of trouble, not in countries or organizations where the concept is irrelevant.

Re:Dangerous feature

[animaal]

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 Are they the lyrics for a Morrissey song?

Re:Dangerous feature

[Anonymous Coward]

Yes, the lyrics for a Morrissey song are the torture.

Say, billy budd
So you think you should ?
Oh, everyones laughing
Say, billy budd
So you think that you should ?
Everyones laughing !
Since I took up with you

Arrgh! Enough, please I confess, I CONFESS!

Re:Spread the word - truecrypt volumes can be rsyn

[Copid]

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.

It should be noted that this is not necessarily a good idea if you have a hidden volume and like to write to it. In that case, you'd be keeping two different versions of the same volume at two different points in time, which can allow an attacker to negate your plausible deniability. To put it in a concrete example, if somebody takes your two machines at the same time and they're not up to date, the attacker can compare the "free" space on your outer volume and determine that you're using a hidden volume.

Re:Be Careful!!

[Anonymous Coward]

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.

What I'd like to see (and plan to implement soon)

[DaleGlass]

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.

Re:This really is not _the only_ program out there

[drmerope]

Yes. Seriously. You've been able to do this in FreeBSD for ages.

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 /dev/md0
geli attach /dev/md0
dd if=/dev/random of=/dev/md0.eli bs=1m
newfs /dev/md0.eli
mount /dev/md0.eli /mnt/secret

okay its a bunch of commands, but I'm basically reading out of the man page. And this setup has tamper detection.

Fedora Blues

[mwilliamson]

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

Re:Fedora Blues

[Slashcrap]

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

Objection! Comment implies that installing other software from source on FC may not be a bitch.

Why not wait until someone builds a shitty 3rd party RPM? Then you can complain about how that doesn't install properly because FC is now using libcock-1.1.3 instead of the libcock-1.1.2 that the RPM expects.

Alternatively get a proper fucking distro.

Re:Fedora Blues

[mwilliamson]

Using 3rd party crypto binaries is really smart, dude. I've got a really neat rpm for you to install...

Re:Fedora Blues

[mwilliamson]

Here are detailed instructions on how I got Truecrypt to work under Fedora Core 6 (FC6). It wasn't that hard after all. http://www.aggiegeeks.com/wordpress/?p=74

Re:Fedora Blues

[Anonymous Coward]

His point wasn't that you should wait, but that you shouldn't be using FC6.

I guess your inability to read that comment might be indicative of the problems you are having with FC6.

Virtual Machine + TS = Fully encrypted OS?

[ancientt]

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?

Re:Virtual Machine + TS = Fully encrypted OS?

[Bishop]

With luks and dm-crypt you can use full disk encryption with Linux. You still need a small unencrypted partition or usb drive for the kernel and initrd. The Debian/Etch (and Ubuntu ??) installer has a full encryption option that configures everything automatically. You should be able to install your favorite distro similarly by layering LVM on top of a luks/dm-crypt partition.

My laptop is configure this way. It is very slick.

eCryptfs

[omnirealm]

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:

http://ecryptfs.sourceforge.net/ecryptfs-faq.html# compare

Caveated Gush

[BillGatesLoveChild]

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.

Re:Caveated Gush

[Dr. Sp0ng]

As in why choose: Use AES *AND* TwoFish *AND* Serpent. Why other cipher packages haven't offered this is beyond me.

Because this is bad cryptography. When you combine two algorithms, you're essentially creating a new one - one that hasn't been reviewed or tested for weaknesses. Given that many of the current algorithms can be considerably weakened by seemingly benign changes, I find it odd to assume that drastic changes won't result in breaking the encryption.

Encryption isn't a wrapper that's applied around something, where you can add another layer for added protection. It's a transformation, and when you mix algorithms you're really just changing the equation that governs the transformation. There's no guarantee (and I'd say it's even rather unlikely) that the resulting equation just happens to be a stronger form of encryption.

Re:Caveated Gush

[BillGatesLoveChild]

TrueCrypt *does* use different keys for each cipher. Even so, this would seem unlikely:

One night at Langley...

Analyst #1: "Another Commie Chinese Transmission picked up by our Man in Beijing"
Analyst #2: "Ah yes. Mr. Jerry Wang GREAT AT SPYING ON THE CHINESE!"
Analyst #1: ".. but if they ever found out ..."
Analyst #2: "Then Mr. ---**Jerry Wang**--- of ---*Yahoo*--- would be in a lot of trouble!"
Analyst #1: "Hmm... seems the transmission Jerry picked up is encrypted by that subverise TwoFish."
Analyst #2: "No problem... feed it through AES to decrypt it"
Analyst #1: "But we don't know the key!"
Analyst #2: "Pick anything! It doesn't matter..."
Analyst #1: "Wow. I'll never understand cryptography!"
Analyst #2: "It's not that hard. Ask any Slashdotter."
Analyst #1: "Hey! You.. said AES... but wasn't that designed by..."
Analyst #2: "Yes, Mr. Robert Redford. Hollywood Good Looks and a crack hand at cryptography. The perfect cover."

Caveated Caveat

[BillGatesLoveChild]

Not as bad as I thought: It only goes online for help during volume creation. Once you start TrueCrypt proper there's a PDF.

Re:What I'd like to see (and plan to implement soo

[minion]

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.

Pet Peeve

[bogie]

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.

Re:What I'd like to see (and plan to implement soo

[freedomlinux]

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.

OneKript

[11110-1975]

Actually you are wrong about there not being a Linux GUI. There is actually a pretty good one for KDE. It is Called OneKript:
http://kde-apps.org/content/show.php/OneKript?cont ent=49071

Re:What I'd like to see (and plan to implement soo

[DaleGlass]

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.

Re:What I'd like to see (and plan to implement soo

[DaleGlass]

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.

Whole Disk Encryption missing from TrueCrypt

[SpecialAgentXXX]

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!

Will it run on OS X command line?

[Beryllium Sphere(tm)]

OpenBSD runs Linux binaries under emulation, does OS X? Could it be made available through fink?

Re:Will it run on OS X command line?

[Slashcrap]

OpenBSD runs Linux binaries under emulation, does OS X? Could it be made available through fink?

You want to run a utility that does lots of low level filesystem stuff under binary emulation?

Actually, it's a good idea. Every Mac user should try it. But then I think every Mac user should try playing Russian roulette, so I may not be the best person to take advice from.

Re:Will it run on OS X command line?

[Anonymous Coward]

I love guys like you. The parent asks an honest question -- an uninformed one, but that's why it's being asked -- and you respond by mocking him and saying that Mac users should commit suicide. It's guys like you who make Slashdot the intelligent, civilized place that it is.

Re:What I'd like to see (and plan to implement soo

[SpecialAgentXXX]

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.

Re:What I'd like to see (and plan to implement soo

[Anonymous Coward]

If you are that worried, pull the drive, open its case, and use a belt sander on the platter.

Laptop data-security using TrueCrypt

[rao]

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

For *BSD

[whamett]

... there's vnconfig. It's less feature-rich than TrueCrypt, but it works.

There are flavours for OpenBSD, FreeBSD, and NetBSD. Here's a handy introduction.

Re:What I'd like to see (and plan to implement soo

[Creepy Crawler]

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.

Bootable FDE?

[DigitAl56K]

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

Re:What I'd like to see (and plan to implement soo

[DamnStupidElf]

echo 0 `/sbin/blockdev --getsize /dev/md0` crypt aes-cbc-essiv:sha256 0102030405060708090A0B0C0D0E0F 0 /dev/md0 0 | /usr/sbin/dmsetup create encrypted_raid

This will take /dev/md0, create an encrypted volume from it using the supplied 16 byte password in hex, and create /dev/mapper/encrypted_raid to mount as your root file system. Replace /dev/md0 and /dev/mapper paths with the appropriate locations your devices for your distro. A combination of pivot_root and chroot can be used to move the mounted encrypted raid device to the root of the filesystem. There are howtos out there, and apparently some easier (less manual) ways to get the encrypted root filesystem mounted by some distributions.

Using Windows machines for cryptographic sec!?

[Anonymous Coward]

Wow ... just WOW. Why state something like TrueCrypt is the ONLY (?) open source method to do these things if you have no idea beforehand? Just use mount using loopback device with any of a dozen methods of encryption on anything that can be mounted (a file, a partition, a flash drive, ......). dd can create arbitrary files to mount if you like. You can do this for encrypted swap space (recommended -- see swapon/off) and any other data pool. Linux has had and will have TrueCrypt beaten for years! Select all of the encryption methods you would like to support in kernel build if it doesn't support it now. I would also strongly advise those already using Windows for anything that you really need to cryptographically secure to NOT use Windows at all!

Use of the registry is inevitable

[gr8dude]

why it writes to the registry really needs to be addressed, i wish...

The program uses a driver. Each driver is listed ini the registry, along with its startup mode, friendly name, and the full path to it.

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

obvious problem with hidden partitions

[Anonymous Coward]

as far as i have read, when you make a hidden partition, the inner partition MUST be a FAT one.

um... great...
so if im using linux what would my plausable response be when someone asks:
"if you have no windows computers in your posession why did you format this 100gb disk in with FAT?"
honestly... apart from rather small usb flash drives why would anybody using win2k and above use FAT?

does not the mere use of FAT call into question the veracity of deniability?

months ago i was reading the truecrypt lists and it was suggested that FAT is the only cross platform option. well, my response to this is that perhaps if they want deniability to actually be useful then the choice of filesystem should NOT be subject to cross platform concerns. the container partition format should not raise eyebrows... it should look like a natural choice for your given os. i.e. give me ext2/3 for a container format!!!

a way to remember secure passwords

[pandaba]

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.

Alternatives

[gr8dude]

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.

Re:Alternatives

[apathy maybe]

That I had thought of! I've been using it with the option of typing the password not on the command line (so it doesn't get saved in the history).

Thanks, now I just have to learn some bash scripting skills ... (still easier then learning C I am sure).

Sure

[Sycraft-fu]

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.

Other types of cascades

[gr8dude]

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

Partitions

[JackMeyhoff]

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.

All well and good, but...

[Anonymous Coward]

Who is behind the "Truecrypt Foundation"? Domain name ownership records do not yield any clue, neither does the website. An enquiring mind wants to know before trusting this stuff.

Now give me a Linux GUI please.

[Dimble ThriceFoon]

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.

Re:What I'd like to see (and plan to implement soo

[Technician]

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.

TrueCrypt is NOT OPEN SOURCE

[Anonymous Coward]

At least not Open Source as defined by the OSI (or Free Software by the FSF). Check out the license:
http://www.truecrypt.org/license.php

Why is slashdot promoting windows only software?

[Anonymous Coward]

This story is basically an ad, and it doesn't make sense for Slashdot to promote software that only works on Micro$oft Winblows.

Re:What I'd like to see (and plan to implement soo

[petabyte]

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

The RIGHT way to do away with the registry

[halr9000]

i wish apps went back to the old .ini method of storing config data, much more secure and no messing in the registry looking for obscure keys and entries, deleting a single ini file is a lot easier than digging through the registry

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.

Russian rag doll

[epine]

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.

Re:Russian rag doll

[Mr2001]

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. Well, you could say the same thing about filling the free space with random bytes when the volume is created, or even about using TrueCrypt in the first place (instead of some other software that doesn't provide hidden volumes). If your attackers will punish you merely for using a crypto system intended to provide plausible deniability, there's not much you can do about that.

Feature not a bug

[crush]

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 OpenSource file wiper?

[Nom du Keyboard]

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.

Re:What is the best OpenSource file wiper?

[drlivesey]

Eraser (GPL): http://www.heidi.ie/eraser/

Re:Why is slashdot promoting windows only software

[Dimble ThriceFoon]

Truecrypt works on Linux, and is planned to work on Mac too.

Re:What I'd like to see (and plan to implement soo

[DaleGlass]

Only problem there is that I'm not a large customer, just a normal guy with a server in the closet

source never third-party reviewed

[unger]

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

Re:What I'd like to see (and plan to implement soo

[Anonymous Coward]

Get two (for redundancy) or three (for an additional off-site backup) USB key fobs. Put the same keyfile on all of them, plug two of them into your server, and use truecrypt, which, according to the documentation, can use a keyfile as well as a password or a combination of both - you will want to use the keyfile alone. Create a script that mounts the encrypted volume after booting, and store your important stuff on the encrypted partition. Of course, this doesn't encrypt the entire drive, so changing your system passwords might be a smart move after a disk failure, as their hash values are stored on the unencrypted part in /etc/shadow. If you have enough computing power, you could of course create a "dumb" host system that runs virtual machines from the encrypted volume - that way, your virtual machine(s) would be totally encrypted.

The question that remains is what you do when one of your USB key fobs gets damaged (although read-only access should be rather harmless) - I'd suggest breaking it into bits and pieces or a similarly destructive method.
Given the price of a USB key fob these days, this sounds like a reasonably cheap alternative compared to wrecking an entire hard disk.

Going back to your original idea, booting from a sufficiently large USB key fob is possible too (given a suitable BIOS), there are some modifications to KNOPPIX for example that allow just that. Again, you could also use this for virtual machines, as the latest KNOPPIX release comes with several virtualization tools (at least in the DVD edition, haven't checked out the CD edition yet).

Porn could be the least of it.

[Kadin2048]

At least in the U.S., (adult) porn won't put you in jail. Many other things, including certain types of software, potentially will.

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

There are probably other parts of the world where you'd want to disguise things the other way around.

Non-tinfoil hat uses of truecrypt

[Matthew Bafford]

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 ;-)

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.

Re:What I'd like to see (and plan to implement soo

[Technician]

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.

And what's wrong with EFS on Windows XP?

[Anonymous Coward]

I'm running with EFS encrypted "Documetnts and settings/username" for more than a year, no problem.

Re:Flawed system or flawed usage?

[Anonymous Coward]

It'll take quite a while to crack a strong 14 character password. Assuming alphanumeric (no punctuation) gives a possible 36**14 different ones...
This is approximately 6,140,942,214,464,815,497,216 possibilities. If you choose them at random, it'll take approximately half that number of guesses. Assuming you can run your tests at 1,000,000 checks per second, it'll take approximately 3070471107232407.748608 seconds. This works out to about 97 megayears, or if your guessing is particularly poor, 194 megayears. Keeping track of what guesses you've already made may be the hardest part of the problem though.

However, if you know enough about the password, you can significantly reduce the number of required guesses. If you know that the middle of the password is "someword", then you've reduced the problem to guessing a 6 character password, which is a much simpler problem involving around 2,000,000 possibilities, and given the above highspeed checker, 2 seconds. I wouldn't admit to knowing this, though.