3 ms·

Exposing filenames in the clear like that is a significant drawback. I'm not sure how you could get around it, though.

cfcef 11y ago
Perhaps I'm missing something obvious, but why can't the filename be encrypted as well? (So you have public key 0xDEAFBEEF; you want to write a file named 'secret.txt' with the contents 'We attack at dawn'. OweFS encrypts 'We attack at dawn' to 010101 and writes that to 'secret.txt'. But why couldn't it have encrypted the contents to 010101 and encrypted the filename 'secret.txt' to 111000, and then written a file named 111000.encrypted with the contents 010101? Then when the owner of 0xDEAFBEEF wanted to read it, he simply decrypts 111000.encrypted to 'secret.txt' and decrypts its content 010101 to 'We attack at dawn.')
- craigds 11y ago
  You could do that, but it'd be quite inefficient. Firstly, let's assume that directories aren't encrypted. Otherwise this would be a real PITA - just to locate /foo/bar/baz.txt you'd have to decrypt each component of 001001/011101/110101.encrypted separately. More importantly, the decrypting software has no way to encrypt things, only decrypt them. So to read 'secret.txt' you can't just encrypt 'secret.txt' to '111000.encrypted'. Instead, you have to iterate through the entire directory listing and decrypt every single filename, until you find one that decrypts to 'secret.txt'. Obviously this gets pretty bad with even moderately-sized directories. I assume this is why the project doesn't encrypt filenames.
  - cfcef 11y ago
    If you're reading files rather than writing them, then you must be decrypting them and in possession of the private key, which means you are permitted access to everything; so you could cache all the decryptions. Initial reads might be more expensive to locate, but then free. Also, how many cycles could it take to decrypt the few hundred or few thousand characters that could possibly make up a full filepath?
pliu 11y ago
Linux 4.1+ with ext4 supports filesystem level encryption, and it encrypts filenames. The implementation seems very complex, I'm not sure how mature this feature is. I think the state is probably "not production ready", but I don't know very much about this. http://blog.quarkslab.com/a-glimpse-of-ext4-filesystem-level-encryption.html http://blog.quarkslab.com/a-glimpse-of-ext4-filesystem-level... https://docs.google.com/document/d/1ft26lUQyuSpiu6VleP70_npaWdRfXFoNnB8JYnykNTg/edit https://docs.google.com/document/d/1ft26lUQyuSpiu6VleP70_npa...
- doomrobo 11y ago
  This can't be used for assymetric encryption. The reason you can still see files and filenames on normally encrypted drives is because your OS holds the encryption key AND decryption key in memory (they're actually the same because it's using symmetric encryption). The problem with the assymetric case is that you no longer have the decryption key, so if you encrypt a filename, you don't get to refer to the file anymore, of course unless (as another user commented) you encrypt the filename you're using to reference the file every time you reference the file, which isn't a terrible idea.

cfcef 11y ago

Perhaps I'm missing something obvious, but why can't the filename be encrypted as well? (So you have public key 0xDEAFBEEF; you want to write a file named 'secret.txt' with the contents 'We attack at dawn'. OweFS encrypts 'We attack at dawn' to 010101 and writes that to 'secret.txt'. But why couldn't it have encrypted the contents to 010101 and encrypted the filename 'secret.txt' to 111000, and then written a file named 111000.encrypted with the contents 010101? Then when the owner of 0xDEAFBEEF wanted to read it, he simply decrypts 111000.encrypted to 'secret.txt' and decrypts its content 010101 to 'We attack at dawn.')

craigds 11y ago
You could do that, but it'd be quite inefficient. Firstly, let's assume that directories aren't encrypted. Otherwise this would be a real PITA - just to locate /foo/bar/baz.txt you'd have to decrypt each component of 001001/011101/110101.encrypted separately. More importantly, the decrypting software has no way to encrypt things, only decrypt them. So to read 'secret.txt' you can't just encrypt 'secret.txt' to '111000.encrypted'. Instead, you have to iterate through the entire directory listing and decrypt every single filename, until you find one that decrypts to 'secret.txt'. Obviously this gets pretty bad with even moderately-sized directories. I assume this is why the project doesn't encrypt filenames.
- cfcef 11y ago
  If you're reading files rather than writing them, then you must be decrypting them and in possession of the private key, which means you are permitted access to everything; so you could cache all the decryptions. Initial reads might be more expensive to locate, but then free. Also, how many cycles could it take to decrypt the few hundred or few thousand characters that could possibly make up a full filepath?

pliu 11y ago

Linux 4.1+ with ext4 supports filesystem level encryption, and it encrypts filenames. The implementation seems very complex, I'm not sure how mature this feature is. I think the state is probably "not production ready", but I don't know very much about this. http://blog.quarkslab.com/a-glimpse-of-ext4-filesystem-level-encryption.html http://blog.quarkslab.com/a-glimpse-of-ext4-filesystem-level... https://docs.google.com/document/d/1ft26lUQyuSpiu6VleP70_npaWdRfXFoNnB8JYnykNTg/edit https://docs.google.com/document/d/1ft26lUQyuSpiu6VleP70_npa...

doomrobo 11y ago
This can't be used for assymetric encryption. The reason you can still see files and filenames on normally encrypted drives is because your OS holds the encryption key AND decryption key in memory (they're actually the same because it's using symmetric encryption). The problem with the assymetric case is that you no longer have the decryption key, so if you encrypt a filename, you don't get to refer to the file anymore, of course unless (as another user commented) you encrypt the filename you're using to reference the file every time you reference the file, which isn't a terrible idea.