Ubuntu will kill my hard drive if I enter the wrong password.

I don't, but that's a particularly tasty brand of awesome. Incidentally, I don't think it's accurate to say it will "kill" your hard drive since it appears from the project page that it will simply overwrite the encrypted data and present either false information or a fresh install afterwards. Did I miss another option?

No, you're right. It doesn't kill the hard drive, just the data. The wording was for the sake of mirroring the inspiring claim, a game for which I have a penchant. (My drafts list is chock full of these.)

Mine too. I also wonder how long it would take to boot if the duress password is used. Given the direction of things, you might need to use this option entering or leaving the country.

The overhead of the duress password is about 2 seconds. At least on a VMWare box with a 16GB (virtual) hard drive. I haven't tested it on a production box. I kind of wish I did when I installed my laptop, but alas. When I formatted my hard drive, it took a little longer than it did on VMWare (also about 10x the size), but I can confidently say less than 10 seconds overhead in any situation.

The border situation had not escaped our notice when this was conceived.

What use do you have for your 'duress' password? I ask because I can't think of a practical situation where it would be useful.

Of course it's not practical in most situations. Otherwise, you'd be losing your data left and right. It's mostly a joke, but it is completely operational.

Though, I did add another password that allows you to overlay a ramdisk instead of your encrypted drive, so you can allow somebody to use your system without giving them access to your personal data. This mode is also useful for stupid laptop thieves, as they can use the system while a program you added calls home.

The border scenario might work. It seems simpler to just have a clean computer when crossing the border.

The issue is that they are just as likely to take the computer as give you the chance to enter or disclose a duress password. In that case, your life becomes much harder. If they find out that you tried to destroy data, then your life is even more exciting... but not in the good way.

The trouble is I can't think of a single situation where this approach is more practical than other simpler methods. You imply otherwise. I'm curious.

How about a stolen laptop scenario combined with a relatively simple duress password and a brute force attack of some sort? You're still out a laptop, but you might not have your data (personal or corporate) compromised.

Hell, write your duress password on a sticky note and put it in your laptop bag.

A relatively complex real password / passphrase is a better bet because a real attacker is going to image your drive first.

You're such a naysayer, saying nay and all.

Well, you have every right to destroy your data if you have not been informed that you are under investigation. Furthermore, last December, a court quashed a subpoena which required a suspect to divulge his encryption passphrase, under 5th amendment protections.

Now, I'm not sure it's simpler, but it has a few advantages. First, it leaves a usable system behind. Second, it protects all of your personal data from anybody who takes your laptop (unless, of course, you leave it on and unlocked). Third, there is almost no evidence that there was an erasure at the time of that particular boot.

You cannot hide that you had an encrypted drive, so this makes it look like it was simply freshly encrypted, and you even give them a key to look inside.

Under any circumstances, if someone images your drive, you're pretty much screwed and have to depend on the strength of your password and encryption, as you do in all cases.

Also, the duress password isn't part of the encryption itself, but rather part of the boot scripts. So brute force attacks can't activate it.

Project Beer Bottle will hopefully do some other fun things involving plausible deniability; the project got started while we were trying to figure out how to properly do a duress password. The problem is that I haven't had enough time lately to do any work on it. It's in my "awesome projects that I don't have time for" along with The Dragon.

It will also hopefully allow me to present something at DefCon. I've always wanted to present while smoking a cigarette and drinking from a hip flask, and DefCon seems like the place for that.

Chron, I hate you for abandoning the lab.

Chron: I'll bet you a nickel that there is evidence that there was an erasure at that particular boot (at least in this incarnation of the tools / instructions)

Specifically, a) the existence of duress password handling tools is strong evidence, unless they are wiped, and b) unless wiped, the duress password itself (cleartext or a hash that the 'evil' person can access) is verifiable. Finally, c), the existence of a large partition of apparently encrypted data that you 'don't know the password for' and certainly cannot give the password for is not something you want to have around if they are suspicious of you and ill intentioned.

You are going to be a lot better off with a lawyer and the court that quashed the subpoena than anything that looks like you destroyed evidence (IMHO).

Finally, it would be nice to be able to make the decision that protecting the information is no longer worthwhile, at least for most information. You can suggest fake passwords until you are blue in the face, but a duress password only once.

The idea of an encrypted overlay is starting to grow on me though. Thinking about the implications of this on backups and recovery is interesting.

I have a debian 'test' machine that requires me to open the case and fix the hard disk every now and then as something seems to come loose.

I don't know if you actually read the README or NOTES, but we've considered all of these points.

a) The duress password handling tools are: mcrypt, cryptsetup, lvm, mkswap, mkfs.xfs, install. None of these are particularly incriminating, though perhaps a bit odd. And, at present, the initrd in which they are stored is copied over, and could be shredded instead.

b) The duress password is not represented as either a cleartext or a hash. The user encrypts a script with the duress password, and on entry, the script is decrypted and run. (Decryption is attempted each time; if successful, the result is run.) The code which performs the wipe is therefore never unencrypted on your hard drive.

c) You know exactly what the password is. It is now your duress password, which is what you gave them in the first place. What they *cannot* access is the data that used to be there, and there is very sparse evidence that there ever was any there.

Here is a complete list of the evidence that this procedure leaves:

1) Timestamps on the base system will show the actual install date. You can touch the entire system frequently to update these, but your logs would be nontrivial to similarly update.

2) The initramfs image on which the scripts that do the wiping is stored may be recoverable. This can be amended by shredding, though that will add a few extra seconds to the process.

3) The fresh crypt drive will begin collecting logs at the first boot post-wipe.

However, I don't think it's possible to demonstrate that the duress password *must* have been entered at any given time; only when the first boot after the encrypted drive was most recently set up occurred.

A tricky move would be to use a ramdisk overlay the first time, so that the first logs they have would be if they booted it again, after confiscating it.

I should say that I believe that is a complete list. It's possible I've neglected something, though I have spent a great deal of time thinking about and tinkering with this.

Chron: I stand corrected. I owe you a nickel.

I'm mildly interested in the topic, but given its impracticality (IMHO), I might not find the time anytime soon.

A slight update: Chron accidentally triggered the Beer Bottle mechanism. It works as advertised. That is all.