Show HN: Shell utility to encrypt a file into a self-decrypting script | Hacker News Reader

Show HN: Shell utility to encrypt a file into a self-decrypting script

github.com

46 pointsvbezhenar20 comments

I don't like the idea of needing to execute a file to decrypt it. That could be abused by someone, adding malicious code to the decryption code.

Of course you could inspect the file, but that's extra work which many people won't bother with.

I guess what's really needed is a simple encrypted format that's easy to decrypt without needing to worry about command line arguments. For example, people are generally satisfied with .tar.* formats and not looking for self extracting compressed formats.

Thanks, that's a very reasonable suggestion. It's easy to add --decrypt option to the main tool, so it'll decrypt encrypted archive without executing anything. I'll implement it.

> without needing to worry about command line arguments. For example, people are generally satisfied with .tar.

I have to google the extract arguments for tar every single time I use it. What was it again, -xfv?

Sorry for offtopic, but I find it strange that so many people find it hard to remember, it's just: e(x)tract, be (v)erbose and use (f)ile. If it was gzipped add -z. If you're compressing the file use -c (for compress) instead of -x. To me it was one of the easier commands to memorize...

A few extra tips for tar:

-xvf is sufficient even if the archive is compressed

The dash is optional as well. tar xvf archive.tar.gz works just fine.

Right near the top of `tar --help`:

    tar -xf archive.tar  # Extract all files from archive.tar.

If you work with lots of different types of archives or have a hard time remembering the various tools and arguments, I recommend dtrx (Do The Right Extraction). Super simple and it ensures you don't accidentally dump a whole directory tree somewhere it shouldn't. Assuming you have pip and hg installed, you can install the latest version to your user site with the following command:

    pip2 install --user hg+http://www.brettcsmith.org/2007/dtrx/dtrx

Then all you have to remember is `dtrx ARCHIVE...`

It looks useful, especially for sharing something confidential with people who aren't fluent in Terminal (e.g.: "pick what I've sent you, copy to Desktop and execute"). Would be nice to get it packaged via brew/apt-get.

Here's one I wrote a while back that has its own RC4 routine in Perl, so no external dependencies needed.

https://github.com/psypete/public-bin/blob/public-bin/src/sy...

Don't ever use RC4.

Can you show any reasonable case where encrypting a small file once would be unsafe with RC4? Maybe if you had 74 million such files...

There are known biases throughout RC4 output. There are really bad biases towards the beginning. A small file would likely be XOR'd with certain bytes or patterns of bytes. If this is not exploitable in your hypothetical scenario, it maybe exploitable in others. I think this is generally unsafe.

I was thinking about the same tool not long ago. It could be a way to include simple secrets in your configuration/deploy scripts without having to add an extra dependency on some arbitrary "vault" tool. OpenSSL is available everywhere.

Except you need to type in the password to decrypt.

So it still requires either storing that new secret (the password) somewhere (which defeats the purpose of using this technique to guard your secrets), or you need a human (which defeats the purpose of automated deployments).

Nice! I actually did a similar project which is a web app to encrypt files which produces self-decrypting html files: https://hypervault.github.io/

Needs a digital signature to verify that neither the data nor the code to decrypt it has been modified.

.. and that signature can't really be verified by unverified code.

Yes, encrypted file includes unencrypted public key (even if it doesn't need it to decrypt) and it means that anyone who has access to the encrypted file, can produce another encrypted file with the same key. I wanted it to be very simple to use, but probably I'll reconsider that.

How is this better than using gpg in symmetric mode, perhaps with its own wrapper?

It's not; it's worse than using GPG in symmetric mode.

Encryption scheme is similar or identical, AFAIK. GPG requires a little bit of manual setup and you need not to forget to include key with the encrypted file. And, of course, to install GPG when you need to decrypt. I wanted to be able to decrypt the file on any system without any additional dependencies (except OpenSSL, of course).

Why would not just use a asymmetric crypto and just use the public key to encrypt files for automated back ups without needing a password? Seems like a lot of work to produce something with less security.

Reply on news.ycombinator.com