Slashdot Mirror
Encrypted Fileserver with Bittorrent Web Interface
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."
Pirate away :). FreeBSD 5.3 FreeBSD 4.11
So you can have an encrypted MP3 collection.
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.
Simple: You have random users which make backups to your machine but don't want anybody else to be able to read these backups.
My wife's sketchblog Blob[p]: Gastrono-me
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 d=138
http://www.ohiobar.org/pub/lycu/index.asp?article
I've already been doing this for quite some time now with Azureus, and the Swing Web Interface plugin alongside RSS Feed Scanner plugin (to download TV shows automatically). There's even an IRC bot 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 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.
from MSDN: Taking Recovery Precautions
Recovering Encrypted Files
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.
Ubuntu is an African word meaning 'I can't configure Debian'
It looks like the article is down. As usual, MirrorDot has the mirror available.
~Jay
Don't forget that by itself, vnc traffic is NOT encrypted... (realvnc has a version that is, but I don't think anyone else does yet)
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.
You said, "This is another example of mod-by-agreement. Anyway, EFS is documented perfectly well."
Correction: This is another example of someone on Slashdot acting sure when he knows nothing about the issue, and didn't even read the document at his first link in his Google Search: Microsoft Windows XP - Data Recovery and Data Recovery Agents, which says:
"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
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'.