Comment by FiloSottile | Hacker News Reader

Comment by FiloSottile | Hacker News Reader

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.

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/

Sure. Thanks for the reference.

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.

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

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.

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

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"

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

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

Reply on news.ycombinator.com