
Zbox – Zero-knowledge, privacy-focused embeddable file system written in Rust - gbrown_
https://github.com/zboxfs/zbox
======
nudpiedo
I will be a bit harsh with the project since I understand it aims to be a
technology to be used in production and not just a pet project... (not "Show
HN" tag was present.)

I only see here yet another key value store with an application programming
interfaces that resembles the typical filesystem operations, but it is only
accessible within a programming framework.

I know it is not finished but the flaws I see at the moment are completely
fundamental: it aims to be general purpose, not unix compliant, not mountable,
not language or truly operating system agnostic and in conclusion does not
permit leverage existing filesystem tools such as mount/find/grep/sshfs etc...
not to speak about support for multiple processes, users, time validations...

I wish you all the luck in the world as pet project (really! especially since
filesystems are quite hard to get mature and stable) but I hope it never
succeeds as a serious alternative to filesystems, because that could be worse
than mongodb to rdbms.

Now trying to be constructive: there is value in the concept of runtime
embeddable file systems. Why don't reframe the project as a key-value store
which is embeddable within applications and mountable? (for example via fuse
so you can even mount it mac/linux/others). Even if it is mountable only as RO
that could bring several advantages over existing key-value-stores and
advanced filesystems which are not embeddable.

Again, impressive work, good luck.

EDIT: the way you store data is also a great discussion topic... who is
interested in so many possible ways to store the information anyway? that
mostly depends on the requirements of the consuming application... for example
if you target users which want to have a file-system-alike embedded runtime,
why they would like to use this project if they have access to advanced unix
compliant filesystems which support encryption and RAID and advanced tools out
of the box?

~~~
simias
I'm also surprised that there's no Fuse interface, it's the first thing I
expected while reading the title.

For single process crypto storage I'd sooner use a crypto shim for SQLite, I
don't know if there's any good one available out there (besides the one sold
by the SQLite devs).

~~~
chrisballinger
You can use SQLCipher [1] with libsqlfs [2], which has a FUSE interface.

1\.
[https://github.com/sqlcipher/sqlcipher](https://github.com/sqlcipher/sqlcipher)

2\.
[https://github.com/guardianproject/libsqlfs](https://github.com/guardianproject/libsqlfs)

------
Confiks
Before an entire bikeshed discussion arises over the misused term "zero-
knowledge", know that the author is sensitive to this issue and will likely
correct it soon [1].

[1]
[https://github.com/zboxfs/zbox/issues/4](https://github.com/zboxfs/zbox/issues/4)

~~~
easytiger
Seems to me the bigger issue is calling it a file system. As far as I can tell
it is nothing of the sort.

~~~
_Codemonkeyism
So it's not a file system and not zero-knowledge :-)

~~~
frankmcsherry
Or perhaps it is zero-knowledge, but about file systems. ;)

------
vog
Great project, I applaud the effort! Some curious questions:

\- Where exactly does "zero-knowledge" play a role here? Does this provide
steganography? Or, what is meant?

\- Why do they use libsodium (excellent choice, but C) instead of a native
Rust crypto library?

\- Does this only work with Rust applications?

~~~
0xFFC
Does Rust have _official_ implementations of Crypto algorithms (in pure Rust)?

I am not talking about some github repo in some dudes repository which
contributes to it in his spare time.

~~~
steveklabnik
I'm not sure what you mean by "official" exactly, but I think for any of them,
the answer would be "no".

That said, [https://crates.io/crates/ring](https://crates.io/crates/ring) is
what most people suggest you should reach for: it's a slow and steady port of
BoringSSL's code to Rust + asm. Of course, that only has a subset of crypto;
there's other great projects too, the tor people have been putting out crates
like
[https://github.com/isislovecruft/curve25519-dalek](https://github.com/isislovecruft/curve25519-dalek)

~~~
vog
Is there something like "ring" for libsodium instead of BoringSSL?

Also, does it really make sense to create a separate crate for every crypto
primitive (or small set of primitives)? This has so many obvious disadvantages
compared to the "libsodium approach".

~~~
steveklabnik
I think it has pros and cons, honestly.

I'm not aware of anyone porting libsodium, though it's also not my area of
specialty.

~~~
vog
Of course maintaining some kind of "libsodium for rust" is more work, but on
the other hand, a central project for rust crypto stuff is highly desirable:
Even if initially run by mere crypto enthusiasts, such a central place is
needed for the real crypto experts to condensate. Then, obsolete crypto can
centally be deprecated and put with a warning, and competing implementations
can be resolved at a central place getting (hopefully) all knowing people
together to discuss.

What's the alternative? That each individual developer has to pick and combine
their favourite set of crypto libs, making crypto libs spread by popularity
(which is more often than not a self-fulfilling prophecy) rather than actual
quality.

~~~
dbrgn
Tweetnacl ([http://tweetnacl.cr.yp.to/](http://tweetnacl.cr.yp.to/)) would be
a good candidate for porting to Rust, since it's very small. Others have done
it successfully in other languages: [https://github.com/dchest/tweetnacl-
js](https://github.com/dchest/tweetnacl-js)

Someone has given it an attempt:
[https://github.com/jmesmon/sodalite](https://github.com/jmesmon/sodalite) But
the port doesn't seem to be too mature yet.

(Edit: For those not aware, Libsodium is based on a portable rewrite of NaCl.)

------
O1111OOO
Looks interesting - on my checklist for serious testing.

Currently using cryptomator[0] for encrypting local directories under Linux.
Works very well with Nemo (File Manager), browsers (I keep local html pages
here..), gedit. Some apps don't like accessing the DAV-based links (geany),
while others generally work will enough that I have long-term confidence (ZIM
Desktop Wiki = issues only with moving pages around within ZIM itself).

[0] [https://cryptomator.org/](https://cryptomator.org/)

------
cdoxsey
Perhaps there are use cases where this would make sense (mobile?), but for a
server-side application, wouldn't encrypting the filesystem be better?

I'm just imagining an operator trying to debug the system only to find out
that he can't read any of the files from the terminal and will have to build
custom programs using this library to operate with the data.

And it seems like there are API abstraction issues too... Imagine you use a
library that writes some state to the file system using the standard lib. None
of that data would end up encrypted because it didn't go through this library.

Whereas using the operating system's filesystem allows transparent compression
and encryption without having to change your code at all.

~~~
kazagistar
I could see it being used alongside Intel SGE for DRM or security reasons, in
situations where the OS and system are considered hostile adversaries, but you
still need extensive mutable external storage outside the application binary.

------
pibefision
I wonder how can this coexist with docker. Docker volumes maybe could be
encrypted?

------
fiatjaf
Can it run in the browser and store files on IndexedDB?

~~~
burmecia
Not yet, but could be possible if you can compile it into WebAssembly.

