Enigma: A simple cross-platform encrypted filesystem in Golang | Hacker News Reader

Enigma: A simple cross-platform encrypted filesystem in Golang

github.com

71 pointsaegistudio27 comments

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.

May I repeat your statements in my words, so that we can have understanding in common and communicate efficiently?

1. Elaborated and formalized description about encryption method is required.

2. Processes need to be authenticated before they could access ciphertext / plaintext directory, so that they can't recover the key stream.

3. On encrypting the file names, the threshold of directory tree size for the birthday attack to become innegligible, should also be elaborated.

(1) and (3), yes. (2) is not about process authentication but about using authenticated encryption that detects tampering.

More broadly, there needs to be a threat model that states what your attacker is capable of.

Even more broadly, I get the impression you’re not an experienced cryptography engineer and you didn’t work with one. Learning is great, but this is not presented with any warnings, which is irresponsible.

You are right. I don't come with cryptography background and haven't consider the attack model carefully. I will warn the users about the current status and strive to design it to confront potential attacks.

I recommend reading Cryptography Engineering [0] and then re-evaluating the design and then get it audited. I took that path and I learned a ton and still had (some smaller) issues in the audit.

[0] https://www.schneier.com/books/cryptography-engineering/

Cryptography Engineering was great for its time but has been outdated for years, which in cryptography doesn’t mean “lacks fancy new stuff” but “we learned the hard way to do things differently”. Serious Cryptography and Real World Cryptography are commonly mentioned as successors.

Thanks. Was not aware of that. I bought/read it in 2015, I think.

I'll check out Serious Cryptography - just found out that I already have it! I like JP's approach to things and his bold thinking.

You forgot to mention a better source - please be constructive, thanks.

Sure. Thanks for the reference.

This. Sad, I can only upvote once.

>Don’t roll your own crypto

as far as I can tell, they're neither inventing their own algorithms nor implementing existing algorithms from scratch. that's what "Don't roll your own crypto" supposed to mean, not "just use Bitlocker"

> ... neither inventing their own algorithms nor implementing existing algorithms ...

Even if you just cobble together existing primitives from battle tested libraries, if you don't fully grasp their properties or interactions, you can still shoot yourself in the foot pretty heftily.

Particularly, encrypting data at rest is an entirely different beast on it's own.

Personally, I don't really like blindly praying that old "don't roll your own crypto" mantra for this exact reason. It means so much more than "don't implement crypto primitives from scratch" which people seem to often interpret it as, but is IMO really poorly/vaguely phrased to convey that.

Well, I (and most security and cryptography experts I discussed this with) disagree, and I don’t think we’re going to find a canonical source for what the warning is supposed to mean.

Its broader version that includes protocols and formats easily applies here (although is also arguably defeated because it didn’t stop this project from being published without caveats and making it to the HN front page).

We had a discussion about this with tptacek on his podcast. https://securitycryptographywhatever.buzzsprout.com/1822302/...

I should probably listen to that podcast, but to me the "It's gatekeeping" thing is entirely annulled by experiences like this HN post. If I went a few years without seeing people ignorantly doing this I would re-think my stance, but I don't think I ever go more than a few months and I'm not paying that close attention.

I feel like it belongs in the same category as "Don't eat wild mushrooms". I know some people who are really interested in fungi and they definitely don't see this as gatekeeping, they see it as fewer dead people. Bad cryptography is less immediately deadly than eating the wrong mushroom, but on the other hand even tremendous incompetence (e.g. feed housemates delicious mushroom soup you made, oops that was poison, they're all hospitalised) has narrower consequences than for software which can trivially be spread to millions of people.

I wrote some crypto example software as a demo for an acquaintance (I was going to write "friend", but given subsequent events lets go with "acquaintance") last century, and I made sure to cover it in "Not for production use" warnings, but how sure can I ever be that the warnings were still on it when anybody else saw it ? Perhaps I should rather have said "No".

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

As a French, if I do an amateur crypto algorithm, I'll name it Waterloo.

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.

[1]: https://www.cryfs.org/howitworks

A comparison gocryptfs would be appreciated, since this software, at first glance, has no differentiating features from it.

https://nuetzlich.net/gocryptfs/

Plus gocryptfs has gone through security audits.

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.

Just store the file system on top of pi.

Well, time to advertise my own competing offering: https://github.com/netheril96/securefs. Works on Win, Linux, Mac and BSD.

Looks great, much better. Love the BSD support!

I work on a cross platform P2P encrypted filesystem - Peergos: https://peergos.org

https://book.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

Enigma is a weird name because the World War II Enigma is the last famous example of the bad way cryptographic systems for serious purposes used to be built. During that same war the Germans also used Lorenz, which while it's obviously not secure today is a much more normal modern design, a stream cipher.

Nothing we use today resembles Enigma at all, it's the sort of thing a crank would come up with and post to Reddit or whatever, but stream ciphers like Lorenz are totally normal. ChaCha20 is a famous modern stream cipher.

Reply on news.ycombinator.com