6 ms·

OweFS – One-way encrypted file system

50 points by nyan4 11y ago

detaro 11y ago
Looks useful, although it probably will have problems with all kind of applications that do anything more than just writing new files or directly appending to old ones (e.g. those that add to files by writing the changed version to disk and then swapping it in place -> old, already encrypted parts of the changed file would then be encrypted again)
doomrobo 11y ago
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.
res0nat0r 11y ago
Is this essentially the same thing as encrypted loopback filesystems? http://www.techrepublic.com/blog/linux-and-open-source/create-encrypted-loopback-filesystems-on-linux/ http://www.techrepublic.com/blog/linux-and-open-source/creat...
- rincebrain 11y ago
  No - the primary benefit this filesystem claims is that you can have a system with write access without knowing the private key to read data back, so even if the system is somehow compromised, the attacker doesn't get to read the sensitive data written.
- xrcltr 11y ago
  Except that that the kek and horrible crypto are different in this project, it's really not a different approach.
vive-la-liberte 11y ago
Does anyone know a similar but BSD-like instead of GPLv3 licensed fs?
- floatboth 11y ago
  Yeah… liberal license + not in a dynamic language + NaCl crypto instead of RSA+AES please.
ipsin 11y ago
Nice. I'd previously written a similar FUSE-based one-way filesystem, but I never did publish it. "Go laziness!" The two applications that caught my eye were "home security cameras" (which the docs allude to) and secure telemetry. You have a device (say, a drone) that logs telemetry data, but if the drone is lost, the data cannot be recovered by a third party without the private key.
ziedaniel1 11y ago
The inability to edit or append to files is not really a fundamental limitation of this approach - it would just require some more bookkeeping. Reading back data, of course, is (by design) impossible.
timmclean 11y ago
Heads up to anyone considering using this: the author wrote their own crypto code[1]. I would recommend against using this until that is fixed... I've already spotted a few vulnerabilities. [1] https://github.com/FedericoCeratto/owefs/blob/master/pycryptoenc.py https://github.com/FedericoCeratto/owefs/blob/master/pycrypt...
- Sir_Cmpwn 11y ago
  I don't necessarily disagree, but at some point the buck has to stop, right? How would you implement this any other way? The author didn't implement AES or so on himself, he uses standard library encryption and applies it as appropriate. You should probably report the issues you find to federico.ceratto-at-gmail.com (from Github).
  - lotyrin 11y ago
    You could make this a frontend to an existing system like GPG
    - marbu 11y ago
      It looks like OP has that in the roadmap. Unfortunately it also seems that the last work has been done in 2013.
  - timmclean 11y ago
    The author should use a library that provides a simple "encryptWithPublicKey" method, so that any choices about RSA key size, AES mode of operation, etc are all taken care of. NaCl[1] would probably be best, since it's written and audited by prominent cryptographers. [1] http://nacl.cr.yp.to/ http://nacl.cr.yp.to/
  - xrcltr 11y ago
    There are a tremendous number of other ways this could be implemented. Authenticated encryption? GCM? XTS? Salt the CFB? Guard against interblock attacks? The crypto needs to be completely reworked. This is an asymmetric kek around symmetric encryption, which is done in many other projects. Half-backed crypto such as this is worse than no crypto at all, as it lulls people into believing they are using a valid cryptographic system. But, the project implements (poorly) a subset of what is needed and pushes the rest into application code - but app writers don't know this and wouldn't know what to implement even if they know of the shortcomings. Cryptographers see this all the time. People think they invented a new concept but only implemented a well-known design but did it incompletely and with well-known flaws in the crypto. Then, people defend the system, when it would be far easier to use better primitives.
ausjke 11y ago
asymmetric key encryption is quite cpu intensive comparing to , say AES256. why not use the asymmetric keypair to guard an AES key, and use AES to do the encryption instead, something like what https is doing.
- arkadiyt 11y ago
  That is exactly what the project does: "Every time a new file is being written, owefs_encrypt creates a one-time random key. The random key is encrypted using the public key and is embedded in the new file. The contents of the file are encrypted using such random key."
  - ausjke 11y ago
    I see. Thanks!
zhenjl 11y ago
Should call it 1fs with the number 1. 1fs.io is even avail!
Scaevolus 11y ago
This is similar to how Apple's iOS File Data Protection works with "Protected Unless Open": https://www.apple.com/business/docs/iOS_Security_Guide.pdf https://www.apple.com/business/docs/iOS_Security_Guide.pdf > Some files may need to be written while the device is locked. A good example of this is a mail attachment downloading in the background. This behavior is achieved by using asymmetric elliptic curve cryptography (ECDH over Curve25519). The usual per-file key is protected by a key derived using One-Pass Diffie-Hellman Key Agreement as described in NIST SP 800-56A. > The ephemeral public key for the agreement is stored alongside the wrapped per-file key. The KDF is Concatenation Key Derivation Function (Approved Alternative 1) as described in 5.8.1 of NIST SP 800-56A. AlgorithmID is omitted. PartyUInfo and PartyVInfo are the ephemeral and static public keys, respectively. SHA-256 is used as the hashing function. As soon as the file is closed, the per-file key is wiped from memory. To open the file again, the shared secret is re-created using the Protected Unless Open class’s private key and the file’s ephemeral public key; its hash is used to unwrap the per-file key, which is then used to decrypt the file.
gkya 11y ago
The first faq paragraph has a typo, he probably wanted to say "Traditional encrypted filesystems cannot proctect".
- lotyrin 11y ago
  No, he's right. He could be clearer though, Probably adding either "while" to the first or "however" to the second sentence.
johnhenry 11y ago
I was initially turned off by the title of this thread because 'one-way encryption' generally refers to hashing and not asymmetric encryption. https://en.wikipedia.org/wiki/Cryptographic_hash_function https://en.wikipedia.org/wiki/Cryptographic_hash_function

50 points by nyan4 11y ago

Looks useful, although it probably will have problems with all kind of applications that do anything more than just writing new files or directly appending to old ones (e.g. those that add to files by writing the changed version to disk and then swapping it in place -> old, already encrypted parts of the changed file would then be encrypted again)

doomrobo 11y ago

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.

res0nat0r 11y ago

Is this essentially the same thing as encrypted loopback filesystems? http://www.techrepublic.com/blog/linux-and-open-source/create-encrypted-loopback-filesystems-on-linux/ http://www.techrepublic.com/blog/linux-and-open-source/creat...

rincebrain 11y ago
No - the primary benefit this filesystem claims is that you can have a system with write access without knowing the private key to read data back, so even if the system is somehow compromised, the attacker doesn't get to read the sensitive data written.
xrcltr 11y ago
Except that that the kek and horrible crypto are different in this project, it's really not a different approach.

vive-la-liberte 11y ago

Does anyone know a similar but BSD-like instead of GPLv3 licensed fs?

floatboth 11y ago
Yeah… liberal license + not in a dynamic language + NaCl crypto instead of RSA+AES please.

ipsin 11y ago

Nice. I'd previously written a similar FUSE-based one-way filesystem, but I never did publish it. "Go laziness!" The two applications that caught my eye were "home security cameras" (which the docs allude to) and secure telemetry. You have a device (say, a drone) that logs telemetry data, but if the drone is lost, the data cannot be recovered by a third party without the private key.

ziedaniel1 11y ago

The inability to edit or append to files is not really a fundamental limitation of this approach - it would just require some more bookkeeping. Reading back data, of course, is (by design) impossible.

timmclean 11y ago

Heads up to anyone considering using this: the author wrote their own crypto code[1]. I would recommend against using this until that is fixed... I've already spotted a few vulnerabilities. [1] https://github.com/FedericoCeratto/owefs/blob/master/pycryptoenc.py https://github.com/FedericoCeratto/owefs/blob/master/pycrypt...

Sir_Cmpwn 11y ago
I don't necessarily disagree, but at some point the buck has to stop, right? How would you implement this any other way? The author didn't implement AES or so on himself, he uses standard library encryption and applies it as appropriate. You should probably report the issues you find to federico.ceratto-at-gmail.com (from Github).
- lotyrin 11y ago
  You could make this a frontend to an existing system like GPG
  - marbu 11y ago
    It looks like OP has that in the roadmap. Unfortunately it also seems that the last work has been done in 2013.
- timmclean 11y ago
  The author should use a library that provides a simple "encryptWithPublicKey" method, so that any choices about RSA key size, AES mode of operation, etc are all taken care of. NaCl[1] would probably be best, since it's written and audited by prominent cryptographers. [1] http://nacl.cr.yp.to/ http://nacl.cr.yp.to/
- xrcltr 11y ago
  There are a tremendous number of other ways this could be implemented. Authenticated encryption? GCM? XTS? Salt the CFB? Guard against interblock attacks? The crypto needs to be completely reworked. This is an asymmetric kek around symmetric encryption, which is done in many other projects. Half-backed crypto such as this is worse than no crypto at all, as it lulls people into believing they are using a valid cryptographic system. But, the project implements (poorly) a subset of what is needed and pushes the rest into application code - but app writers don't know this and wouldn't know what to implement even if they know of the shortcomings. Cryptographers see this all the time. People think they invented a new concept but only implemented a well-known design but did it incompletely and with well-known flaws in the crypto. Then, people defend the system, when it would be far easier to use better primitives.

ausjke 11y ago

asymmetric key encryption is quite cpu intensive comparing to , say AES256. why not use the asymmetric keypair to guard an AES key, and use AES to do the encryption instead, something like what https is doing.

arkadiyt 11y ago
That is exactly what the project does: "Every time a new file is being written, owefs_encrypt creates a one-time random key. The random key is encrypted using the public key and is embedded in the new file. The contents of the file are encrypted using such random key."
- ausjke 11y ago
  I see. Thanks!

zhenjl 11y ago

Should call it 1fs with the number 1. 1fs.io is even avail!

Scaevolus 11y ago

This is similar to how Apple's iOS File Data Protection works with "Protected Unless Open": https://www.apple.com/business/docs/iOS_Security_Guide.pdf https://www.apple.com/business/docs/iOS_Security_Guide.pdf > Some files may need to be written while the device is locked. A good example of this is a mail attachment downloading in the background. This behavior is achieved by using asymmetric elliptic curve cryptography (ECDH over Curve25519). The usual per-file key is protected by a key derived using One-Pass Diffie-Hellman Key Agreement as described in NIST SP 800-56A. > The ephemeral public key for the agreement is stored alongside the wrapped per-file key. The KDF is Concatenation Key Derivation Function (Approved Alternative 1) as described in 5.8.1 of NIST SP 800-56A. AlgorithmID is omitted. PartyUInfo and PartyVInfo are the ephemeral and static public keys, respectively. SHA-256 is used as the hashing function. As soon as the file is closed, the per-file key is wiped from memory. To open the file again, the shared secret is re-created using the Protected Unless Open class’s private key and the file’s ephemeral public key; its hash is used to unwrap the per-file key, which is then used to decrypt the file.

gkya 11y ago

The first faq paragraph has a typo, he probably wanted to say "Traditional encrypted filesystems cannot proctect".

lotyrin 11y ago
No, he's right. He could be clearer though, Probably adding either "while" to the first or "however" to the second sentence.

johnhenry 11y ago

I was initially turned off by the title of this thread because 'one-way encryption' generally refers to hashing and not asymmetric encryption. https://en.wikipedia.org/wiki/Cryptographic_hash_function https://en.wikipedia.org/wiki/Cryptographic_hash_function