if I, hypothetically, want to open a theatre where you are allowed to talk on the cellphone?
Actually, there's a play in New York called Mono in which an ``audience member'' receives a cell phone call in the middle of the play and acts in a very obnoxious way. Only it turns out that the phone call is part of the play.
Maybe the interrogators exacted the confession with physical force. People will often make up whatever they think the interrogator wants to hear when they are tortured.
1) Is a standard cipher used? (easy, now that libraries are widely available)
AES/Rijndael, which is a good algorithm.
2) Is a standard cipher used *correctly*? (e.g., no ECB mode!)
It encrypts the file offset and a per-file IV, XORs this with the plaintext, and then encrypts again. Thus the same block encrypts differently if it appears in two different files or at two different locations in the same file.
3) Does the same data in two blocks encrypt to the same ciphertext? If not, how are you
randomizing them? What happens if you copy an encrypted FS from one media to another, e.g.,
via backups?
Same data encrypts differently, as described above. The IV is stored within the file itself. There is a 512-byte space overhead, but you can safely copy encrypted directories to back them up, etc.
4) How do you detect an incorrect encryption key?
There is redundancy in encrypted file names, so if you type the wrong passphrase you won't see any files. (Or you could have multiple passphrases for an encrypted directory, and see different files depending on which you typed.)
The system was described in a Usenix paper on user-level file systems last year (actually won best paper award).
There is a cryptographic file system you can get for SFS. If you go to the download page, it's called cryptfs. Unfortunately, you have to install SFS first to compile cryptfs.
Cryptfs is fully functional, though it was indented mostly as a proof of concept. The point is that such file systems are not hard to build, should someone want to maintain one. Here's an undergraduate programming assignment in which the students build a fully-functional cryptographic file system as an NFS loopback server.
Slashdot Mirror
Actually, there's a play in New York called Mono in which an ``audience member'' receives a cell phone call in the middle of the play and acts in a very obnoxious way. Only it turns out that the phone call is part of the play.
So will this law ban the play Mono?
Maybe the interrogators exacted the confession with physical force. People will often make up whatever they think the interrogator wants to hear when they are tortured.
AES/Rijndael, which is a good algorithm.
2) Is a standard cipher used *correctly*? (e.g., no ECB mode!)
It encrypts the file offset and a per-file IV, XORs this with the plaintext, and then encrypts again. Thus the same block encrypts differently if it appears in two different files or at two different locations in the same file.
3) Does the same data in two blocks encrypt to the same ciphertext? If not, how are you randomizing them? What happens if you copy an encrypted FS from one media to another, e.g., via backups?
Same data encrypts differently, as described above. The IV is stored within the file itself. There is a 512-byte space overhead, but you can safely copy encrypted directories to back them up, etc.
4) How do you detect an incorrect encryption key?
There is redundancy in encrypted file names, so if you type the wrong passphrase you won't see any files. (Or you could have multiple passphrases for an encrypted directory, and see different files depending on which you typed.)
The system was described in a Usenix paper on user-level file systems last year (actually won best paper award).
Cryptfs is fully functional, though it was indented mostly as a proof of concept. The point is that such file systems are not hard to build, should someone want to maintain one. Here's an undergraduate programming assignment in which the students build a fully-functional cryptographic file system as an NFS loopback server.