
Cryptographic filesystem for the cloud - j_s
https://github.com/cryfs/cryfs
======
j_s
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...](https://github.com/cryfs/cryfs/issues/64#issuecomment-285968655)

Here is a comparison of several similar options:

>
> [https://nuetzlich.net/gocryptfs/comparison/](https://nuetzlich.net/gocryptfs/comparison/)

------
spaceheeder
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
Sure why not?

------
Johnny555
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)

~~~
brango
[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)

------
metalliqaz
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)

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

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

~~~
drdaeman
I 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.

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

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

------
daxorid
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
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...](https://bitcartel.wordpress.com/2012/10/21/rbic-redundant-bunch-of-
independent-clouds)

> _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
DokanY (LGPL) provides a FUSE-compatible API on Windows.

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

~~~
smarx
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...](https://github.com/cryfs/cryfs/blob/master/src/cpp-
utils/crypto/symmetric/GCM_Cipher.h#L40). 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.)

------
temp321
Cryptomator is another alternative.
[https://cryptomator.org/](https://cryptomator.org/)

