6 ms·

Cryptographic filesystem for the cloud

83 points by j_s 9y ago

spaceheeder 9y ago
Since the strategy here is to split the files up into equal-sized pieces, I wonder if the encryption key of each piece could be encrypted with a public key rather than a symmetric key, a-la the experimental (and now apparently defunct) One-way encrypted File System[0]. [0] OweFS discussion thread on HN: https://news.ycombinator.com/item?id=10911913 https://news.ycombinator.com/item?id=10911913
- lowglow 9y ago
  Sure why not?
j_s 9y ago
A number of HN anecdotes vouched for this project (and it is used for the new-ish KDE Plasma Vault utility), but after further review I can not recommend it for heavy usage. There are multiple open issues reporting lock-ups (re-mount works; no data loss): > https://github.com/cryfs/cryfs/issues/64#issuecomment-285968655 https://github.com/cryfs/cryfs/issues/64#issuecomment-285968... Here is a comparison of several similar options: > https://nuetzlich.net/gocryptfs/comparison/ https://nuetzlich.net/gocryptfs/comparison/
metalliqaz 9y ago
Better links to get an introduction to what they're offering: https://www.cryfs.org/ https://www.cryfs.org/ and https://www.cryfs.org/howitworks https://www.cryfs.org/howitworks
daxorid 9y ago
This was already done long ago by the Tahoe-LAFS project: https://tahoe-lafs.org/trac/tahoe-lafs https://tahoe-lafs.org/trac/tahoe-lafs
- j_s 9y ago
  Does Tahoe-LAFS help with this project's intended use case, local encryption of files stored on various commercial cloud providers? It looks like it is an off-label use, circa 2012: https://bitcartel.wordpress.com/2012/10/21/rbic-redundant-bunch-of-independent-clouds https://bitcartel.wordpress.com/2012/10/21/rbic-redundant-bu... >Tahoe doesn’t directly support online storage providers as remote back-ends, but we can work around this problem by using sync folders, at the expense of local disk space I noticed mention of a Windows virtual drive as a client; I believe CryFS requires "real" FUSE (aka not Windows).
  - mappu 9y ago
    DokanY (LGPL) provides a FUSE-compatible API on Windows.
- drdaeman 9y ago
  Also, git-annex, although it's not a filesystem (IIRC there is some way to mount it with FUSE, but I don't think it's a good idea) http://git-annex.branchable.com/special_remotes/ http://git-annex.branchable.com/special_remotes/
  - j_s 9y ago
    Interesting point mentioned about the Tahoe-LAFS remote there: >Tahoe-LAFS does not support removing data once it is stored in the Tahoe grid
urda 9y ago
Browsing through the website I came across this: > VeraCrypt runs on Windows, Linux and Mac, and is believed to be a secure encryption tool to encrypt your files locally. It keeps your files confidential, but does not protect the integrity, i.e. a hacker can't read your files, but they could modify them without you noticing. [1] Veracrypt encrypts an entire container. I would love to know what they mean by a hacker being able to modify my container's files without being able to read them. Encrypted is encrypted, so this is either PR fluff or the maintainers truly do not understand how encryption works, which is concerning when they are shipping a security app themselves. [1] https://www.cryfs.org/comparison
- vengefulduck 9y ago
  > Encrypted is Encrypted This is very much not the case as their are numerous side channel attacks against unauthenticated symmetric ciphers with regards to padding [1] http://www.cs.colorado.edu/~jrblack/papers/padding.pdf
  - urda 9y ago
    That's not what my comment, or the article is about at all though. There are a number of attacks, my question was in regards to some of the copy on their site. We would spend our entire day here if we had to discuss attack surfaces and different encryption trade offs if that was the original topic I was discussing.
    - vengefulduck 9y ago
      I understand, but your first comment was criticizing how the comparison was misleading and their are valid concerns that people who are using veracrypt on the cloud might have if their data was unauthenticated; which cryfs addresses.
      - urda 9y ago
        I still think it is misleading. Once you have a veracrypt container created, an attacker can't just modify a file inside of it without you noticing because it'll just be garbage data at that point. That is, unless they have your container password / key then it's all over anyway so that point is moot regardless.
IncRnd 9y ago
from https://www.cryfs.org/howitworks https://www.cryfs.org/howitworks: > The current version protects the encrypted blocks from being modified by an attacker, since it uses an authenticated encryption scheme like aes-256-gcm. However, it doesn't prevent an attacker yet from rolling back the filesystem by replacing blocks with an earlier valid version of the same block. GCM only retains its security properties when nonce/IV & Key combinations are never repeated. If these repeat under a specific key, the algebraic ability to completely break the scheme is drastically heightened. Therefore, this implementation appears to be broken. Is there an expectation for when this will be fixed? It's very serious, and the scheme seems somewhat well-planned in other ways. Also, with this implementation of GCM, what is the practical limit before reuse happens, given the blob/block difference and nonce size? I call this out, as this is disk encryption not file encryption.
- m_eiman 9y ago
  The text you quote says nothing about what values are used for IV. To me it looks like each block has a static name, probably based on its offset in the address space of the virtual block device, and that there's nothing telling the block pointing at a block which version of the block to use. So you can replace block N with any known good version of that block. To point at specific versions of a block you'd have to point at something like hash(encrypted_block) or hash(block_offset || block_version) instead, but then you'd have to update pointers all the way up to the root for every edit made anywhere in the FS.
- jorangreef 9y ago
  "However, it doesn't prevent an attacker yet from rolling back the filesystem by replacing blocks with an earlier valid version of the same block." All cryptographic filesystems have that limitation. The attacker cannot modify or tamper data or create new data (thanks to authenticated encryption), but they can always return the raw disk back to an earlier version if they have a copy of it. The fact that the filesystem can be rolled back, does not automatically imply GCM IV reuse as you suggest. In fact, it should increase confidence on the basis that the authors are aware of the possibility of rollback.
- smarx 9y ago
temp321 9y ago
Cryptomator is another alternative. https://cryptomator.org/ https://cryptomator.org/
Johnny555 9y ago
How does this differ from encfs [1]? Has it had the same level of security vetting? [1] https://en.wikipedia.org/wiki/EncFS https://en.wikipedia.org/wiki/EncFS
- EToS 9y ago
  I've used encfs with google drive for about 3 years now, I would love to see better client-side encryption tools out there targeted at cloud storage, but cannot see where CryFS offers much over encfs in this space.
- brango 9y ago
  [1] says "A probably even larger issue with EncFS is a security audit from 2014 that attests EncFS to deviate from established security standards and also found some vulnerabilities in the current EncFS implementation." [1] https://www.cryfs.org/comparison https://www.cryfs.org/comparison
eighthnate 9y ago
The #1 rule of computer/data security is physical security. If you have data/information you don't know anyone to access, don't put it on the cloud. Store it locally somewhere with no or limited internet connection.
- alethiophile 9y ago
  I mean, that's true, but it's also very limiting. Everything is a tradeoff between security and functionality; the only perfectly secure computer is one turned off and embedded in a concrete block. In particular, a whole lot of people want to be able to use cloud storage for the synchronization/offsite benefits, yet not expose all their data to $ARBITRARY_CLOUD_HOST.

83 points by j_s 9y ago

Since the strategy here is to split the files up into equal-sized pieces, I wonder if the encryption key of each piece could be encrypted with a public key rather than a symmetric key, a-la the experimental (and now apparently defunct) One-way encrypted File System[0]. [0] OweFS discussion thread on HN: https://news.ycombinator.com/item?id=10911913 https://news.ycombinator.com/item?id=10911913

lowglow 9y ago
Sure why not?

j_s 9y ago

A number of HN anecdotes vouched for this project (and it is used for the new-ish KDE Plasma Vault utility), but after further review I can not recommend it for heavy usage. There are multiple open issues reporting lock-ups (re-mount works; no data loss): > https://github.com/cryfs/cryfs/issues/64#issuecomment-285968655 https://github.com/cryfs/cryfs/issues/64#issuecomment-285968... Here is a comparison of several similar options: > https://nuetzlich.net/gocryptfs/comparison/ https://nuetzlich.net/gocryptfs/comparison/

metalliqaz 9y ago

Better links to get an introduction to what they're offering: https://www.cryfs.org/ https://www.cryfs.org/ and https://www.cryfs.org/howitworks https://www.cryfs.org/howitworks

daxorid 9y ago

This was already done long ago by the Tahoe-LAFS project: https://tahoe-lafs.org/trac/tahoe-lafs https://tahoe-lafs.org/trac/tahoe-lafs

j_s 9y ago
Does Tahoe-LAFS help with this project's intended use case, local encryption of files stored on various commercial cloud providers? It looks like it is an off-label use, circa 2012: https://bitcartel.wordpress.com/2012/10/21/rbic-redundant-bunch-of-independent-clouds https://bitcartel.wordpress.com/2012/10/21/rbic-redundant-bu... >Tahoe doesn’t directly support online storage providers as remote back-ends, but we can work around this problem by using sync folders, at the expense of local disk space I noticed mention of a Windows virtual drive as a client; I believe CryFS requires "real" FUSE (aka not Windows).
- mappu 9y ago
  DokanY (LGPL) provides a FUSE-compatible API on Windows.
drdaeman 9y ago
Also, git-annex, although it's not a filesystem (IIRC there is some way to mount it with FUSE, but I don't think it's a good idea) http://git-annex.branchable.com/special_remotes/ http://git-annex.branchable.com/special_remotes/
- j_s 9y ago
  Interesting point mentioned about the Tahoe-LAFS remote there: >Tahoe-LAFS does not support removing data once it is stored in the Tahoe grid

urda 9y ago

Browsing through the website I came across this: > VeraCrypt runs on Windows, Linux and Mac, and is believed to be a secure encryption tool to encrypt your files locally. It keeps your files confidential, but does not protect the integrity, i.e. a hacker can't read your files, but they could modify them without you noticing. [1] Veracrypt encrypts an entire container. I would love to know what they mean by a hacker being able to modify my container's files without being able to read them. Encrypted is encrypted, so this is either PR fluff or the maintainers truly do not understand how encryption works, which is concerning when they are shipping a security app themselves. [1] https://www.cryfs.org/comparison

vengefulduck 9y ago
> Encrypted is Encrypted This is very much not the case as their are numerous side channel attacks against unauthenticated symmetric ciphers with regards to padding [1] http://www.cs.colorado.edu/~jrblack/papers/padding.pdf
- urda 9y ago
  That's not what my comment, or the article is about at all though. There are a number of attacks, my question was in regards to some of the copy on their site. We would spend our entire day here if we had to discuss attack surfaces and different encryption trade offs if that was the original topic I was discussing.
  - vengefulduck 9y ago
    I understand, but your first comment was criticizing how the comparison was misleading and their are valid concerns that people who are using veracrypt on the cloud might have if their data was unauthenticated; which cryfs addresses.
    - urda 9y ago
      I still think it is misleading. Once you have a veracrypt container created, an attacker can't just modify a file inside of it without you noticing because it'll just be garbage data at that point. That is, unless they have your container password / key then it's all over anyway so that point is moot regardless.

IncRnd 9y ago

from https://www.cryfs.org/howitworks https://www.cryfs.org/howitworks: > The current version protects the encrypted blocks from being modified by an attacker, since it uses an authenticated encryption scheme like aes-256-gcm. However, it doesn't prevent an attacker yet from rolling back the filesystem by replacing blocks with an earlier valid version of the same block. GCM only retains its security properties when nonce/IV & Key combinations are never repeated. If these repeat under a specific key, the algebraic ability to completely break the scheme is drastically heightened. Therefore, this implementation appears to be broken. Is there an expectation for when this will be fixed? It's very serious, and the scheme seems somewhat well-planned in other ways. Also, with this implementation of GCM, what is the practical limit before reuse happens, given the blob/block difference and nonce size? I call this out, as this is disk encryption not file encryption.

m_eiman 9y ago
The text you quote says nothing about what values are used for IV. To me it looks like each block has a static name, probably based on its offset in the address space of the virtual block device, and that there's nothing telling the block pointing at a block which version of the block to use. So you can replace block N with any known good version of that block. To point at specific versions of a block you'd have to point at something like hash(encrypted_block) or hash(block_offset || block_version) instead, but then you'd have to update pointers all the way up to the root for every edit made anywhere in the FS.
jorangreef 9y ago
"However, it doesn't prevent an attacker yet from rolling back the filesystem by replacing blocks with an earlier valid version of the same block." All cryptographic filesystems have that limitation. The attacker cannot modify or tamper data or create new data (thanks to authenticated encryption), but they can always return the raw disk back to an earlier version if they have a copy of it. The fact that the filesystem can be rolled back, does not automatically imply GCM IV reuse as you suggest. In fact, it should increase confidence on the basis that the authors are aware of the possibility of rollback.
smarx 9y ago

temp321 9y ago

Cryptomator is another alternative. https://cryptomator.org/ https://cryptomator.org/

Johnny555 9y ago

How does this differ from encfs [1]? Has it had the same level of security vetting? [1] https://en.wikipedia.org/wiki/EncFS https://en.wikipedia.org/wiki/EncFS

EToS 9y ago
I've used encfs with google drive for about 3 years now, I would love to see better client-side encryption tools out there targeted at cloud storage, but cannot see where CryFS offers much over encfs in this space.
brango 9y ago
[1] says "A probably even larger issue with EncFS is a security audit from 2014 that attests EncFS to deviate from established security standards and also found some vulnerabilities in the current EncFS implementation." [1] https://www.cryfs.org/comparison https://www.cryfs.org/comparison

eighthnate 9y ago

The #1 rule of computer/data security is physical security. If you have data/information you don't know anyone to access, don't put it on the cloud. Store it locally somewhere with no or limited internet connection.

alethiophile 9y ago
I mean, that's true, but it's also very limiting. Everything is a tradeoff between security and functionality; the only perfectly secure computer is one turned off and embedded in a concrete block. In particular, a whole lot of people want to be able to use cloud storage for the synchronization/offsite benefits, yet not expose all their data to $ARBITRARY_CLOUD_HOST.