I can try to offer some impressions on the encrypted filesystems, as I went through all of those. Perhaps it's a bad choice, as it is the "default" project, but it's the area I am most interested in. I am not an expert in encrypted file systems, but I am a developer for a private cloud storage provider, and have some passing familiarity with the subject.

* Paranoia: Another Encrypted File System

They make repeated statements about relying on the server to protect the file from access such as "We depend on the server to correctly process ACLs and serve files that the user is authorized to view." and "If the server can be trusted to enforce the ACLs,no malicious user, perhaps named Mallory, can be permitted to read Alice's files." but since the premise of these projects is to deny trust to the server it seems odd to trust the server with anything. They do make sure that file contents cannot be read by the server without the client key, however I'm not sure why they went ahead and implemented a server except as a learning exercise or perhaps to provide an end-to-end solution. Inspection of the GitHub code raised some odd practices, such as explicit calls to sys.path.insert(0, '/home/henchill/Documents/Workspace/encrypted_file_system/server'), which makes me think perhaps it wasn't packaged correctly. At least they put it on GitHub, some of the other project were shipped as tar.gz.

* FyreBox - Encrypted File System

"Our filesystem is made up of 3 components: the client, the server, and a trusted cloud service." A trusted cloud service for the keys? I don't know why you would trust a cloud service and not the server. GitHub code seems reasonably clean, but requiring trusted cloud service seems like a dealbreaker.

* KBox: An Encrypted File System

I see a lot of math and LaTex, and security seems well considered, but I have to wonder about usability. The solution seems to store so much on the client side, including information needed to reconstruct the root directory and file names, that access from multiple clients or using it for sharing files seems untenable. However, I could have misunderstood. Noticed mixed tabs and spaces in the Python code, as well as cleartext password and private key in the code. Even if it is for testing, seems like bad practice.

* DarkFS - An Encrypted File System

I think I actually liked this one the best. They start right out by saying they do not trust the server for anything, and implemented their solution against the Dropbox API. They insert and encrypt the permissions/ACLs with the file data. However, these permissions are enforced by the client, so I wonder if a malicious client implementation could sidestep the permissions checking entirely. It is unclear if the permissions are enforced by the nature and sequence of the encryption itself. They also mention that had some issues with the Dropbox API, specifically being unable to encode file sharing data. I wonder if they would have been better served to implement their solution against the Amazon S3 API, as it supports file metadata and is quickly become the standard for file storage. S3 API is implemented by OpenStack Swift, EMC Atmos, Hitachi HCP, etc. Their code seemed well organized and the writers seemed familiar with Python. Would have preferred to see it on GitHub.

I was also a bit disappointed not to see anything here about distributed filesystems, leveraging torrents or other distributed infrastructure so that no server has the whole picture. There was interesting work done in projects such as Tahoe-LAFS years ago, nothing in these MIT projects seems radically innovative.