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