Posted
by
timothy
on Saturday May 07, 2005 @04:33PM
from the freenetesque dept.

mistermark writes "I built a fully encrypted (samba) fileserver with a web interface for managing torrent downloads on it. All I used is OpenBSD 3.6 and its package collection, except for the TorrentFlux-interface (which you need to install separately). Anyway, it can be built using binary packages only. I included a rough HOWTO on how to make one of these yourself."

On 2000/XP, you can do this yourself by right clicking on the folder containing your warez/tunez and checking the encryption box. As long as Bittorrent runs with you as the current user, its reads and writes to that folder are automatically encrypted and decrypted by the filesystem.

If the cops bust you, and you have an encrypted hard drive and you don't hand over the password, you will be charged with obstruction of justice. The maximum sentence of obstruction of justice is the same as the crime you are trying to avoid. So it really doesn't help you avoid anything.

I've already been doing this for quite some time now with Azureus [sourceforge.net], and the Swing Web Interface [sourceforge.net] plugin alongside RSS Feed Scanner [sourceforge.net] plugin (to download TV shows automatically). There's even an IRC bot [sourceforge.net] plugin to allow control over an IRC network/channel.

Why is my way better? Well, the default BitTorrent client is somewhat lacking feature wise. Azureus is more powerful and gives you more control over what to do with the torrents when they are done downloading. Not to mention the support for trackerless torrents [slashdot.org] in the latest version. As for encryption goes... uh, why? The only people who have access to my "files" are those that are on the network. And the Swing Web Interface plugin has password functionality with HTTP SSL (you need GPG to be installed).

Be very, very careful when using the Windows XP built-in file encryption,
called EFS (Encryping File System).

EFS is very poorly documented. The encryption is tied to your user
password in a way that is apparently not documented. EFS depends on being part
of a Windows 2003 Server domain in a way that is not clearly documented; if
you are using Windows XP on a stand alone computer, there are situations in
which you will lose your files forever.

Microsoft technical support agrees with what I just said, and provides
no help or fixes.

The official Microsoft forums contain the complaints of many people
who have lost their files due to problems with EFS. One man said he lost 11
years of research.

People complain about Microsoft every day on Slashdot, but I've never
seen a discussion by anyone who seemed to realize how bad Microsoft truly is.

And don't forget that as a member of a domain, a GPO can cause an EFS key to be escrowed with the admininstrators. So if you're thinking this will hide your MP3z at work from the domain admins or SMS sweeps, no go. (Of course, if the filesystem is mounted during an SMS enumeration/collection sweep, it doesn't matter what encryption you're using.)

Any data recovery agent can recover an encrypted file when a user's private key fails to decrypt the file.

To recover an encrypted file
1. Log on to a computer that has access to the user's profile; for example, a computer that has a designated recovery console or a recovery key on removable media such as a floppy disk. You might log on at the user's computer or the user might have a roaming profile.
2. Locate the encrypted file. For example, the user might have made a backup of the file by using Backup or sent the file to a WebDAV Web folder.
3. Decrypt the file by using either the cipher command or My Computer. This will make the file available to the user.

For more information about decrypting files, see "Working with Encryption and Decryption" earlier in this chapter.

As for corrupted encripted files, well, I think it is almost impossible for an encripted file to be restored if it is corrupted, unless it has some kind of recovery record overhead...

Of course, I would better opt out for an standard open cyphering method.

I use Truecrypt [truecrypt.org]. It is free and open source. Provides much more flexibility and the encrypted source file(s) can be stored on any medium (network, flash, floppy, etc..) Sure it is not durectly integrated into the OS but for me, it strikes the perfect balance between security and piece of mind.

Despite my handsomely elaborate defense, I end up in jail for [crime] with a definitive sentence.

At that point, the zealous cop shows up and tells me he's also going to charge me with obstruction of justice, because he kindly asked me a question the first time around, and I lied or said nothing?

You got it backwards, I guess. The suspect is never required to collaborate with his/her prosecutors. They may strike a deal if they choose to do so. Obstruction of justice is a felony witnesses and persons who haven't been charged commit.

One instance where you could be right might be if a suspect tampers with something that already has been "identified" as evidence, or falsifies something as evidence in their defense. Your linked citation doesn't mention a single instance where a suspect is actually committing obstruction of justice. RTFC.

I've read the many scattered, poorly written documents about EFS. I find them very misleading. For example, the information above does not say that it applies only if the encrypting computer is part of a Windows domain.

"The default design for the EFS recovery policy is different in Windows XP Professional than it was in Windows 2000 Professional. Stand-alone computers [using Windows XP] do not have a default DRA, but Microsoft strongly recommends that all environments have at least one designated DRA.

"In a Windows 2000 environment, if an administrator attempts to configure an EFS recovery policy with no recovery agent certificates, EFS is automatically disabled. In a Windows XP Professional environment, the same action enables users to encrypt files without a DRA. In a mixed environment an empty EFS recovery policy turns off EFS on Windows 2000 computers, but only eliminates the requirement for a DRA on Windows XP Professional computers."

This information means that you can lose your files in Windows XP in a way that you could not lose them in Windows 2000. Microsoft made this change, but provided no on-screen warning.

The Microsoft document quoted above says, "Stand-alone computers do not have a default DRA,..."

It should say, Stand-alone computers CANNOT have a DRA that allows decryption of files from a different computer with the same user name and password.

As I mentioned, this was verified by Microsoft Tecnhical Support representatives, as was the information in my parent post.

You said above, "I believe the process can be started with a simple cipher/r." This is a VERY serious matter. People lose their files!!! You should not be posting comments in which you take a seemingly sure position, but that sureness is based on "belief".

That already exists. I forget what it's called, but there's a type of encryption where you actually encrypt two files into one, so if someone forces you to hand over the key, you give them a secondary one wich unencrypts the dummy files.

I'm not sure if we're thinking of the same project, but the one I knew was called "rubber hose". For a while, it was hosted at www.rubberhose.org, but that site dropped off the net several years ago, and to the best of my knowledge has not reappeared since.

A few sites still carry copies of the rubberhose 0.8.3 source - a quick Google
for the tarball [google.com] returns a half-dozen or so hits, although some of the copies no longer exist.

The goal of the project was to allow a virtually unlimited number of encrypted filesystems to live on a drive, each with its own key. If someone attempts a "rubber hose" crypto attack (beating you with a rubber hose until you cough up a key), you can provide key(s) for accessing the sacrificial filesystem(s). Since there's no way for the attacker to know how many keys you may have created, there's no way for the attacker to be certain that you've handed over every single key. Conversely, there's also no way for you to prove that you've actually cooperated and turned over every key. The doc/beatings.txt file from the source tarball has some interesting thoughts about the implications of neither attacker nor defender being able to prove/disprove the existence of additional keys.

Not exactly. A public/private key set is generated the first time you encrypt a file. The public key is used to encrypt files and the private to decrypt them. The only place these keys are stored are in a special key store that is encrypted with your password, unless you explicitly export the keys with the Certificates snap-in. On a domain, this is in the Active Directory and on stand-alone computers it's in the SAM. When your account is deleted or the password is reset, the key store is lost. Even though you have the original password, the old key store is gone. At this point, you re-import your backed up keys into the new store.There aren't any 'hidden passwords'.

Bullshit. EFS isn't tied to your user password in any way, undocumented or otherwise: it's tied to a certificate created the first time you encrypt any file on your filesystem. Without this certificate, you'll be unable to access your encrypted files, regardless what user account or password you happen to be using, so it's wise to back up your certificates to a CD in case of accidental deletion or corruption. THIS IS TRUE OF ANY SECURITY CERTIFICATE UNDER WINDOWS OR ANY OTHER OPERATING SYSTEM. If you can't be bothered to read the documentation for a high-powered feature before using it, don't complain if your lack of preparation backfires on you.

Summary: Rejoin your original domain and change your password to your original password.

People complain about Microsoft every day on Slashdot, but I've never seen a discussion by anyone who seemed to realize that if all you wannabe Windows Administrators left the "market", the world would be a better place for everyone.