from Hacker News

OweFS – One-way encrypted file system

by nyan4 on 1/15/16, 8:33 PM with 38 comments

  • by timmclean on 1/15/16, 11:33 PM

    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/pycrypt...

  • by Scaevolus on 1/15/16, 11:54 PM

    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

    > 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.

  • by detaro on 1/15/16, 10:49 PM

    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)

  • by ziedaniel1 on 1/15/16, 11:25 PM

    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.

  • by ipsin on 1/15/16, 11:22 PM

    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.

  • by vive-la-liberte on 1/16/16, 12:10 AM

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

  • by gkya on 1/16/16, 12:18 AM

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

  • by doomrobo on 1/15/16, 10:58 PM

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

  • by johnhenry on 1/16/16, 1:24 AM

    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

  • by res0nat0r on 1/15/16, 11:03 PM

    Is this essentially the same thing as encrypted loopback filesystems?

    http://www.techrepublic.com/blog/linux-and-open-source/creat...

  • by ausjke on 1/15/16, 11:33 PM

    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.

  • by zhenjl on 1/15/16, 11:41 PM

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