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.
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.
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.
[0] https://www.schneier.com/books/cryptography-engineering/
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"
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.
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/...
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).
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.
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
