
Encrypted libraries leak lots of information in Seafile - networked
https://github.com/haiwen/seafile/issues/350
======
tinco
Are people actually using Seafile? I found it interesting back then, and
participated in this discussion but dismissed it as the author didn't really
seem to take it serious. His statement:

"I don't quite understand why using a single IV for the whole library is
vulnerable to known-plaintext attacks."

That might be an acceptable response if you're trying to build a secure system
and don't fully understand your tools yet, not many people do, but it should
be followed with an eager question on how to improve. Instead he follows up
with:

"I know it's better to use different IV and key for each file/block. But that
would greatly increase complexity."

As if that's an excuse. And besides, solutions had been suggested and it's not
_that_ complex. Finally he just states that the security improvements are not
scheduled.

~~~
bwblabs
I actually use SeaFile for some clients (since OwnCloud doesn't do client side
encryption at all), after Wuala shut down last year. I actually was
disappointed by the security and features too ([https://forum.seafile-
server.org/t/encryption-the-pro-added-...](https://forum.seafile-
server.org/t/encryption-the-pro-added-features/3887)), you cannot securely
share sub trees/dirs like in Wuala (with their Cryptree).

Is there a better FOS alternative?

The Wuala service did had a lot's of deadlocks, either on server or the client
side, and customer service was not done secure: please send over the log files
(included file names) or the client storage block, etc...

~~~
ianopolous
In Peergos we are using exactly the cryptree data structure from wuala for our
encrypted filesystem on top of ipfs.
[https://github.com/ianopolous/Peergos](https://github.com/ianopolous/Peergos)

------
reedloden
Note that Seafile seems to still be using a very old and EOL'd version of
Django that has known security issues (currently v1.5.12, I believe).

[https://github.com/haiwen/seafile/issues/1502](https://github.com/haiwen/seafile/issues/1502)

------
kmfrk
GEEZ. At first I wondered "is that really the way to disclose a
vulnerability?", and then I saw that the date was 2013 and it doesn't really
matter at this point.

~~~
ausjke
It started in 2013 but the issue persists ever since, so I think it still
matters.

The thing I don't get is that why can't I just aes-encrypt my file and upload
somewhere for secure-backup, there is no way to break it unless you gave out
your aes key.

~~~
mappu
So you transmitted AES(original) to the server, now what do you do when you
want to update your file?

Transmitting AES(updated) to the server is bandwidth-inefficient and storage-
inefficient.

Transmitting DIFF(AES(original), AES(updated)) gives you no filesize benefit.

You can do AES(DIFF(original, updated)) but that requires your local client to
have the original file, or enough of it indexed to produce the diff - and it
means that restoring the latest file means restoring a giant chain of
increments - which means you'll probably want to periodically reupload the
original file - which is bandwidth-inefficient and storage-inefficient.

You can transmit the encryption key to the server and have it rollup diffs.
But that's not a good idea if you don't really trust your server (got some
cheap cloud storage?)

The solution to this problem is to use a deduplication algorithm like content-
defined chunking, as seen in attic/restic/obnam/tarsnap.

~~~
ausjke
Learned something new. Thanks!

