Cryptographic filesystem for the cloud(github.com)
github.com
Cryptographic filesystem for the cloud
https://github.com/cryfs/cryfs
28 comments
[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
[1] https://www.cryfs.org/comparison
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.
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.
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.
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.
Cryptomator is another alternative.
https://cryptomator.org/
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
[0] OweFS discussion thread on HN: https://news.ycombinator.com/item?id=10911913
Sure why not?
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-285968...
Here is a comparison of several similar options:
> https://nuetzlich.net/gocryptfs/comparison/
> https://github.com/cryfs/cryfs/issues/64#issuecomment-285968...
Here is a comparison of several similar options:
> https://nuetzlich.net/gocryptfs/comparison/
Better links to get an introduction to what they're offering: https://www.cryfs.org/ and https://www.cryfs.org/howitworks
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
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-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).
It looks like it is an off-label use, circa 2012: 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).
DokanY (LGPL) provides a FUSE-compatible API on Windows.
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/
Interesting point mentioned about the Tahoe-LAFS remote there:
>Tahoe-LAFS does not support removing data once it is stored in the Tahoe grid
>Tahoe-LAFS does not support removing data once it is stored in the Tahoe grid
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.
> 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/comparisonI believe they talk about authenticated encryption (AEAD schemes, like GCM which CryFS uses).
VeraCrypt uses XTS, which is not authenticated. AFAIK, if attacker messes with some bytes of your encrypted disk, you'll get some garbage but you won't know it's not the correct data.
VeraCrypt uses XTS, which is not authenticated. AFAIK, if attacker messes with some bytes of your encrypted disk, you'll get some garbage but you won't know it's not the correct data.
But that doesn't really give the attacker much, if they just scramble an encrypted container no? They can't really do much by doing that.
Well, there was a problem with CBC, where an attack exists that malicious party may flip specific bits by somehow XORing inputs (I'm not a cryptographer and haven't grokked the details properly). If attacker has a good idea what the plaintext is, they may alter it, like, replace my ~/.ssh/authorized_keys with theirs - and that would be really bad. Such attacks is AFAIK not possible with XTS, though, so irrelevant to VeraCrypt. Just an example.
All I've got is that this stuff is not as simple as "it's either encrypted and safe or not". There are tons of different algorithms (cipher modes etc) with different properties, assumptions about their use and possible attack scenarios.
While this may not give much, I still don't want anyone to mess with my files without me (or, better say, my software) noticing until it's too late and backups are also corrupt. And remote storage knows exactly where I'm writing to (with block-level granularity), so the encrypted blob isn't completely opaque.
All I've got is that this stuff is not as simple as "it's either encrypted and safe or not". There are tons of different algorithms (cipher modes etc) with different properties, assumptions about their use and possible attack scenarios.
While this may not give much, I still don't want anyone to mess with my files without me (or, better say, my software) noticing until it's too late and backups are also corrupt. And remote storage knows exactly where I'm writing to (with block-level granularity), so the encrypted blob isn't completely opaque.
> 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
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.pdfThat'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.
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.
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.
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.
That is, unless they have your container password / key then it's all over anyway so that point is moot regardless.
Actually I think, the misunderstanding is on your side. Unauthenticated DOES mean that the attacker can modify anything without you noticing. You might only notice because you are getting a file that looks like random junk but you wanted it to be a picture. But that is not something you should rely on for security.
from 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.
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.
As far as I can tell, the IV is randomly chosen, as you would expect: https://github.com/cryfs/cryfs/blob/master/src/cpp-utils/cry.... Did you see something different?
Assuming the 128-bit IV is indeed randomly chosen, after encrypting a trillion blocks, you would have roughly a 1.5E-15 (on the order of a quadrillionth) chance of hitting a collision.
Unless I'm mistaken, even if you hit that one-in-a-quadrillion lottery, the result is that the two blocks encrypted with the same IV are more crackable (because you can XOR them together), not that the key itself is easier to obtain, right? (My understanding is that AES is resistant to known-plaintext attacks.)
Assuming the 128-bit IV is indeed randomly chosen, after encrypting a trillion blocks, you would have roughly a 1.5E-15 (on the order of a quadrillionth) chance of hitting a collision.
Unless I'm mistaken, even if you hit that one-in-a-quadrillion lottery, the result is that the two blocks encrypted with the same IV are more crackable (because you can XOR them together), not that the key itself is easier to obtain, right? (My understanding is that AES is resistant to known-plaintext attacks.)
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.
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.
"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.
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.
[1] https://en.wikipedia.org/wiki/EncFS