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.
age is definitely more mature, and as you say, it should probably say somewhere that ezcrypt is still a hobby project (albeit a serious one).
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.
In a way: When the dust settles after the nuclear apocalypse, if you manage to dig out a C compiler, this is your tool. ;-)
This seem to use home made cryptography, which is never a good idea. In particular it's not clear why this design with layered algorithms is needed, nor why it uses a non standard KDF.
Prefer using libsodium for the crypto, which has made sensible choices for you.
The code isn't especially easy to follow, but is this a cascade of Serpent, Twofish, ChaCha20, and AES, all in CBC except for ChaCha, without an authenticator? With its own stream construction, that doesn't stop truncation?
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).
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 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.
The idea isn't really to make the encryption stronger or to widen the key. It's a classical case of trust - if one cipher is compromised, there are others to cover for you. Also, I wanted to learn the different ciphers, and speed wasn't a top priority.
How would you compare this to existing tools in the space like https://github.com/FiloSottile/age?
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.
age is definitely more mature, and as you say, it should probably say somewhere that ezcrypt is still a hobby project (albeit a serious one).
Some motives (some of which may sound strange, but mattered to me):
In a way: When the dust settles after the nuclear apocalypse, if you manage to dig out a C compiler, this is your tool. ;-)This seem to use home made cryptography, which is never a good idea. In particular it's not clear why this design with layered algorithms is needed, nor why it uses a non standard KDF.
Prefer using libsodium for the crypto, which has made sensible choices for you.
Also you are missing a MAC, which is also a bad idea
The code isn't especially easy to follow, but is this a cascade of Serpent, Twofish, ChaCha20, and AES, all in CBC except for ChaCha, without an authenticator? With its own stream construction, that doesn't stop truncation?
That's pretty much spot on. Authentication is planned (and that should handle truncation too if I'm not mistaking): https://codeberg.org/ezcrypt/ezcrypt/issues/3
Don't use this.
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.)
Very good point!
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).
I recently gave building a file encryption tool a shot myself ( https://github.com/voodooEntity/go-tachicrypt ) tho i didnt implement my own crypto to be fair.
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.
Don't use cryptographic software from people refusing to identify themselves.
This should be the top rated comment ;-) Sorry. I can't remedy the situation for you, though.
PSA: it should be obvious that it's a really dumb idea to use random new encryption tools from GitHub (sorry, author)
> it should be obvious
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.
All good points. I intend to make it clearer: https://codeberg.org/ezcrypt/ezcrypt/issues/4
What’s the advantage over symmetric PGP encryption?
what does this provide which cannot be done with openssl, which is available for most systems?
OpenSSL should not be used for encryption of files. PGP/GnuPG should.
No, PGP isn't much better.
Why not?
Last I checked, there's no authenticated encryption option in the OpenSSL CLI.
> Encryption is done in four layers.
What?
It's a cipher cascade. (Don't build cipher cascades.)
The idea isn't really to make the encryption stronger or to widen the key. It's a classical case of trust - if one cipher is compromised, there are others to cover for you. Also, I wanted to learn the different ciphers, and speed wasn't a top priority.