Show HN: Ezcrypt – A file encryption tool (simple, strong, public domain)(codeberg.org)

37 pointsby ezcrypt2 tahun yang lalu50 comments

Show HN: Ezcrypt – A file encryption tool (simple, strong, public domain)

https://codeberg.org/ezcrypt/ezcrypt

52 comments

SahAssar2 tahun yang lalu

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.

ezcrypt2 tahun yang lalu

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

tptacek2 tahun yang lalu

"Don't rely on a single cipher" is an anti-goal, and a reason your hobby project won't be taken seriously. You'd be better off striking it from the list.

"Zero dependencies" is also not especially reassuring, as it implies you're using your own cipher implementations (or reference implementations).

shanusmagnus2 tahun yang lalu

> "Don't rely on a single cipher" is an anti-goal, and a reason your hobby project won't be taken seriously.

Why?

metadat2 tahun yang lalu

If unanticipated issues are discovered, end users may not receive the updates in a timely fashion if, for example, the repo owner is the only committer and they're on vacation when the next Heartbleed 0day hits.

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.

shanusmagnus2 tahun yang lalu

Ah. I was thinking the critique was about combining different crypto methods in serial; I've heard people say this is a bad idea but have never understood why.

tptacek2 tahun yang lalu

Mostly it's just that it doesn't accomplish anything.

some_furry2 tahun yang lalu

> Without any third party dependencies (not even openssl or similar).

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.

ezcrypt2 tahun yang lalu

Thanks for having a look. The software implementation of AES is actually mostly a copy-paste of https://github.com/kokke/tiny-AES-c (see https://github.com/kokke/tiny-AES-c/blob/master/aes.c#L189 ). I have been meaning to replace and/or improve it. Even moderately modern x86 machines will always take the fast AES-NI path, though.

some_furry2 tahun yang lalu

"mostly a copy-paste" is also known as a dependency

Look to BearSSL for inspiration for how to implement cryptography right

ezcrypt2 tahun yang lalu

"also known as a dependency" - There are different kinds of dependencies. The ones I'm usually concerned with are the ones that cause you headaches when you try to get the software working on an exotic platform ten years from now. I've developed software for 30+ years, and along the way I have grown a strong disliking to external dependencies (be it Python packages, Boost C++ libraries, 3rd party C libraries or a hefty Mono or Java runtime).

Thanks for the reference to BearSSL - it appears to be very much in line with my own preferred design principles.

forty2 tahun yang lalu

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.

forty2 tahun yang lalu

Also you are missing a MAC, which is also a bad idea

tptacek2 tahun yang lalu

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?

ezcrypt2 tahun yang lalu

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

tptacek2 tahun yang lalu

Public key signatures and ciphertext authentication are not the same thing.

ezcrypt2 tahun yang lalu

No, I realize that (I was thinking that ssh-keygen could be used as a poor-man's authentication for some use cases - basically share a secret between sender & receiver that can be used to ensure that the message has not been tampered with). One of the reasons that I haven't implemented authentication yet is that I want to better understand the differences and nuances of different methods and use cases before deciding on a method. Recommendations are welcome.

tptacek2 tahun yang lalu

Get rid of the weird cipher cascade and replace it either with XAES-GCM or ChaPoly. Do some research into how to handle large ciphertexts with a chunking construction. Use a well-defined construction; don't invent your own.

sevg2 tahun yang lalu

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

ezcrypt2 tahun yang lalu

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

tptacek2 tahun yang lalu

You can't safely encrypt without authentication, so you do indeed need it.

ezcrypt2 tahun yang lalu

For the record: The latest release of ezcrypt (v1.3.0) has poly1305 authentication. Thanks for the feedback!

dist-epoch2 tahun yang lalu

PSA: it should be obvious that it's a really dumb idea to use random new encryption tools from GitHub (sorry, author)

spease2 tahun yang lalu

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

ezcrypt2 tahun yang lalu

All good points. I intend to make it clearer: https://codeberg.org/ezcrypt/ezcrypt/issues/4

CarpaDorada2 tahun yang lalu

Don't use cryptographic software from people refusing to identify themselves.

ezcrypt2 tahun yang lalu

This should be the top rated comment ;-) Sorry. I can't remedy the situation for you, though.

voodooEntity2 tahun yang lalu

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.

gbraad2 tahun yang lalu

Have used axcrypt before; easy and portable

ezcrypt2 tahun yang lalu

If it's the AxCrypt I think it is, it doesn't even run on Linux, never mind Raspberry PI or Milk-V for instance. And it's not free either. So it doesn't meet many of my requirements, unfortunately.

svantex2 tahun yang lalu

I'm the original author of AxCrypt. There's a new compatible iteration of it based on the original cryptography code called Xecrets, with several components. Xecrets Cli is the main fully featured command line engine, free open source GPL on https://github.com/xecrets/xecrets-cli . Xecrets Ez is a simple GUI frontend, single executable, portable. Runs on Linux, macOS and Windows. There are several more components available as nuget packages.

ezcrypt2 tahun yang lalu

Very interesting! Thanks for the link, I didn't know about it and I'll have to check it out.

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

svantex2 tahun yang lalu

Fair enough, that's a little out of main scope for Xecrets Cli.

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

gbraad2 tahun yang lalu

Can actually try this for you. Will have a look over the weekend. Ping me otherwise on a GitHub issue with the same username

sirjaz2 tahun yang lalu

I'm just glad you support Windows. We need more of this!

[deleted]2 tahun yang lalu

everfree2 tahun yang lalu

What’s the advantage over symmetric PGP encryption?

ezcrypt2 tahun yang lalu

Can you use PGP in the same way (I haven't tried)? Basically, symmetric file encryption based on a secret password and optionally a secret pepper file (effectively a secret key).

everfree2 tahun yang lalu

Symmetric file encryption yes, key file I’m not aware of.

chasil2 tahun yang lalu

What's wrong with "openssl enc"?

deknos2 tahun yang lalu

what does this provide which cannot be done with openssl, which is available for most systems?

cynicalsecurity2 tahun yang lalu

OpenSSL should not be used for encryption of files. PGP/GnuPG should.

tptacek2 tahun yang lalu

No, PGP isn't much better.

stackghost2 tahun yang lalu

GnuPG and PGP are a shit show. Just make an encrypted drive volume instead.

max_2 tahun yang lalu

Why not?

tptacek2 tahun yang lalu

Last I checked, there's no authenticated encryption option in the OpenSSL CLI.

andrewmcwatters2 tahun yang lalu

> Encryption is done in four layers.

What?

tptacek2 tahun yang lalu

It's a cipher cascade. (Don't build cipher cascades.)

ezcrypt2 tahun yang lalu

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.

tptacek2 tahun yang lalu

Yeah, that's why everyone writes cipher cascades. There's a reason you don't see them in any mainstream vetted cryptography. The bigger problem is that none of this is authenticated.

underlogic2 tahun yang lalu

Why not exactly?

phinnino12 tahun yang lalu