It's an interesting choice of name. I assume they must have deliberately chosen the name of the most infamously broken encryption system of all time.
That's bold and funny but it does smack of hubris.
Good luck to them, there's nothing like painting a target on your back (although, I guess that's true for all encryption regardless of name).
I’m not a crypto expert at all but I wouldn’t use Enigma as it exposes file structure which could be a potential vector for an attack afaik. Not sure how Enigma differs from CryFS[1] but at the glimpse the latter does the same across all major platforms but doesn’t expose a folder structure, has a security analysis, and in development for years.
A comparison gocryptfs would be appreciated, since this software, at first glance, has no differentiating features from it.
Will deniable encryption ever be added, i.e. you can type another set of password to access another "filesystem" thats stores garbage, without revealing the real one with valuable information. Otherwise you're just reinventing the VeraCrypt wheels.
Well, time to advertise my own competing offering: https://github.com/netheril96/securefs. Works on Win, Linux, Mac and BSD.
I work on a cross platform P2P encrypted filesystem - Peergos: https://peergos.org
https://github.com/peergos/peergos
Features:
* audited by Cure53
* protects metadata (directory structure, file name and properties, file sizes, social graph)
* fine grained capability-based access control
* built-in social media
* sandboxed 3rd-party apps: e.g. word doc viewer, calendar, text editor, games etc.
* FUSE bindings
* CLI
* cross platform
* browser client
Yes, let’s name it after the machine that helped the Germans kill and isolate the Allied powers. Great work /s
I am usually on the side of “Don’t roll your own crypto” being gatekeeping (at least more than the average engineer), but this kind of project with no notes on threat model, experimental status, authors and reviewers is a real problem.
From a quick read of the README, which is not a rigorous description of the design (what does “computed from the cryptological digest” mean?), it seems this offers no authentication, fails completely if an attacker can observe the same file at two points in time, and there is no analysis of how big a tree can get before the chance of at least one directory having two files with the same nonce becoming significant.
However, it’s presented without caveats, and there’s no way for non-practitioners to assess whether it’s fit for their purposes.
Users might be led to think this is usable in the same scenarios as, say, gocryptfs, when if fact it’s completely insecure for real world use cases like encrypting a home directory to sync it on Dropbox.