Show HN: Ezcrypt – A file encryption tool (simple, strong, public domain)
codeberg.org
codeberg.org
Seems like age has multiple implementations (rust, go), has a permissive license, a public specification (https://github.com/C2SP/C2SP/blob/main/age.md) and the spec/core implementation is developed by someone with a history with cryptography (I don't know if you do, but there is no indication or name attached to the repo).
While many things can be built as a hobby or learning project I feel like cryptography is one of those spaces where you should be clear if it is that and if it is not you need to expressively argue its bona fides up front.
Some motives (some of which may sound strange, but mattered to me):
* Completely public domain.
* Without any third party dependencies (not even openssl or similar).
* Don't rely on a single cipher (low trust).
* Extremely portable (should easily build for and run on anything from an M4 Mac to a Raspberry Pi to an old OpenWRT MIPS router with 32 MB RAM for instance).
* Should be easy to use (e.g. no key management, unless you want to), and composable in standard Unix ways (pipes etc).
* Security focused, obviously. E.g. software architecture-wise, minimize dependencies, properly manage files, processes and secrets, etc.
* Personally: To learn and to build something that I trust.
"Zero dependencies" is also not especially reassuring, as it implies you're using your own cipher implementations (or reference implementations).
Why?
I am confident and trust the OpenSSL and LibreSSL projects each have multiple folks capable of merging and releasing critical updates.
Amazing as he is, Filippo is a single person who presumably has human needs. If he's a Terminator, though, swell, do let me know.
In your pursuit of "no dependencies", you made a classic blunder: making AES vulnerable to cache-timing attacks.
https://codeberg.org/ezcrypt/ezcrypt/src/commit/3268d71e80d3...
I'm not going to review the rest of your code. This is sufficient for me to recommend everyone run the other way screaming.
Look to BearSSL for inspiration for how to implement cryptography right
Thanks for the reference to BearSSL - it appears to be very much in line with my own preferred design principles.
Prefer using libsodium for the crypto, which has made sensible choices for you.
It's missing a basic building block: authentication.
Unfortunately, the author hasn't spent long enough researching cryptography. (Even the briefest of research would have made this mistake obvious.)
I have been planning to look into authentication. I didn't need it for my use cases, yet, but as you say that should be an integral part of any serious tool. I added a ticket: https://codeberg.org/ezcrypt/ezcrypt/issues/3
In the meantime, signing and verification can be done separately, e.g. with ssh-keygen, although that is a bit inconvenient (which kind of defeats one of the key points of the tool).
It should be, but a lot of developers don’t have formal security training, nor especially management which may end up selecting the contractors/developers and deciding on the technical approach.
If it’s explicitly not production ready, it should probably say so up front, not advertise itself as “strong encryption”. However painful that may be.
I think its always good to dive into topics if you are actually interested and lets face it, the beginning of most of the big things nowadays started somewhere in a basement or a garage.
It still falls slightly outside of my zone of preference, though, as it's a .Net application, which limits which platforms it can be run on (I'm aiming for a tool that can readily be used on most of my devices, including on an old Raspberry Pi or a router).
Just for fun, I tested now to build and publish for an ARM processor running Linux (linux-arm) and the build worked fine. I don't have a device to test it on though.
So... as long as it runs Linux and has an ARM or ARM64 processor and sufficient storage & memory it could work! (It's not tiny like a pure C-program unfortunately).
Would be cool to try...!
What?