secure file system

[GLneo]

hi all, ok, I am hearing much about people who have been cought downloading MP3's, and stuff... and the FBI or someone takes there HD for evidence! now I know about secure FS's but they seem to just be add on progams, I was wondering if anyone else has thought about a secure FS at kernel level? with stuff like multi write delete and stuff???, how hard would this be?

p.s. is this in the right spot?

[Pyr0Mathic]

Hi,

I am currently building a FTP-server. Not for Mp3 etc, but cause Windows sometimes has great errors in its filesystem. due to that i already lost lots of data... And if u write it yourself, then u atleast know how is to blame .

I would, am using FTP, so the Client program, on the windows computer, does all the multi write delete and stuff.

But this is a very nice idea. i might implement some sort of encryption later on in my OS. I did already build my own file-system.

List of things u should do:
-build your own driver, Ethernet driver
-Build IP/TCP/UDP handlers.
-Build a FAT. simple one.
-Build some means to enter a very large password on boot-up of the computer. So your computer can load its code which is located encrypted on the drive.
-and offcourse build a way to get Files, like FTP.
-and maybe some sort of user interface, so u can change user profile for the FTP server..
-code, "unhackeble code" if you can..


Regards.
PyroMathic.

[xenos]

A secure filesystem as you suggested should be quite simple to implement. For example, all blocks could be symmetrically encoded (using AES, CAST, IDEA, twofish... whatever). (This is also very fast, so there are really no disadvantages.) Of course this also applies to the directory structures, because the encryption of thousands of MP3 files would be pretty useless if their names are still readable... The key should not be stored on the disk, of course - the best way is to use a (long, hard to memorize) password or a passphrase which is used to compute the key.

It's even easier to safely delete files, you just need to overwrite every file that is deleted with random numbers, alternating bits, zeros... Of course it has the disadvantage that deleting a file becomes quite slow. And you have to make sure that an interrupted deletion continues after a possible crash... Besides that, you should be absolutely sure before you delete something...

[Candy]

The key should not be stored on the disk, of course - the best way is to use a (long, hard to memorize) password or a passphrase which is used to compute the key.

Of course?

What if you store a double-one-way hash of the key on disk? That way you can make the user enter a given key, calculate the first and second hash and check whether it's correct before sending trash over the network. Ideally the two hashes should be noninterlocked, say, SHA256 and AES256H. That way you get both authentication and encryption with a single key without losing any cryptographical strength.

Of course it's not necessary to authenticate first, but this allows you to use one key to send over the network, after which you get packets encrypted with another without sending the other over the network as well.

[Pyr0Mathic]

hi,

What about a USB stick for booting? whit all your code on it. so encryptor/decryptor. so whit the usb stick no way "they" are able to decode it.

For example a key of like 4MB u put somewhere in your memory. then u take the USB drive out and once the FBI, or whatever, comes in and takes your pc, they offcourse have to turn it off, which switches the power off. after that they only have the encrypted data. So that way there is now way it can be decoded.

Regards
PyroMathic

[Kemp]

Not to ruin your hopes, but doesn't law require you to provide the authorities with unencrypted versions of the data or at least a way for them to decrypt it themselves? I can't imagine they'd let something this simple get by, everyone doing anything even slightly illegal could very easily just encrypt everything.

[paulbarker]

I'm not encouraging law-dodging but google for TrueCrypt.

Plausible deniability... Governments have it so why can't we?

[Pype.Clicker]

hu hu ... yeah, i suppose pointers to /sfs/zik/mp3/madonna/music.mp3 in your playlist will be highly suspicious aswell, even if the whole /sfs... is encrypted

and using the USB key as "secure" wallet for your passphrase just means they need to get their hands on your key ...

bah. if you're too much concerned, just buy an external disk you can throw in fireplace when the cops arrive ^_^ ... or just don't gather illegal content.

[Pyr0Mathic]

Not to ruin your hopes, but doesn't law require you to provide the authorities with unencrypted versions of the data or at least a way for them to decrypt it themselves?

is it really against the law to encrypt your data?
i know that in the US there are laws against it, but in europe aswell?

[Pype.Clicker]

well, i don't think they may "forbid" you to encrypt whatever you like, but if for some reasons, you're being investigated and that you refuse to decrypt some material, you're putting yourself in trouble, the same way that you might get in trouble by refusing to open a safe they've found etc.

[Candy]

well, i don't think they may "forbid" you to encrypt whatever you like

Yes they do. See for example France, in which iirc PGP is forbidden.

, but if for some reasons, you're being investigated and that you refuse to decrypt some material, you're putting yourself in trouble, the same way that you might get in trouble by refusing to open a safe they've found etc.

which is exactly why encryption is useful. If you have a corrupt government or if the "target" you're defending against isn't the government. With a corrupt government you're screwed anyway and in the other case you'll just give them the key anyway.

Also a small point for not encrypting: if you're looking for a fire, the thing you're going to go after is smoke. If there's no smoke, you won't see a small fire even if there is one. In short (and oversimplified), where there's smoke, there's fire. If you encrypt your files, there must be <some> reason why you're encrypting files, so they're going to put you under pressure to give up your key and if you don't, they have reasonable suspicion that you're doing something you don't want them to see, so you can be put to jail.

Try steganography (using unused bits for your information).

[paulbarker]

Hence my suggestion of TrueCrypt. Its statistical encryption which looks no different from unused disk sectors full of random bytes, plus you can layer 2 encrypted volumes inside each other in a way that the inner volume is undetectable. Google for more info.

[bluecode]

Also a small point for not encrypting: if you're looking for a fire, the thing you're going to go after is smoke. If there's no smoke, you won't see a small fire even if there is one. In short (and oversimplified), where there's smoke, there's fire. If you encrypt your files, there must be <some> reason why you're encrypting files, so they're going to put you under pressure to give up your key and if you don't, they have reasonable suspicion that you're doing something you don't want them to see, so you can be put to jail.

Honestly, I don't think so. If someone accuses you of having commited a crime he has to proof that you did that. It's not the other way round. At least in Germany, where there's also no restriction on using cryptographie imho.

[GLneo]

so i should have a false FAT root dir tree and behind it have the real dir tree? good idea! hehehe

[paulbarker]

Cryptography is really a branch of mathematics rather than programming. It is one of the most interesting subjects out there, in my not-so-humble opinion, but also one of the most complicated. I would suggest some serious research into existing algorithms, digests, public-key infrastructure and the like.

Different algorithms have different strengths and weaknesses, mostly because of different purposes for the design.