Re: encryption
On Fri 20 Apr 2018 at 17:07:10 -0700, David Christensen wrote:
> On 04/20/18 12:38, Brian wrote:
> > T have a script. It contains an important password.
> >
> > I have encrypted the script with
> >
> > scrypt dec -t 10 /usr/local/bin/myscript
>
> Looking at:
>
> http://manpages.org/scrypt
>
>
> That command decrypts /usr/local/bin/myscript (and I don't know if the -t
> option is valid for decryption).
A typo. It should be "enc", not "dec".
> > I can, of course, decrypt it with
> >
> > scrypt dec /usr/local/bin/myscript
>
> Assuming /usr/local/bin/myscript is ciphertext, that command will print the
> script on STDOUT.
Another bit of sloppiness. Redirection to a file should have been
mentioned.
> As scrypt is going to prompt you for a passphrase anyway, why don't you
> leave the script unencrypted and revise it to prompt for the "important
> password"?
>
> > and then execute the script.
>
> How are you executing a script printed on STDOUT? A pipeline?
The redirected file was executed with 'eval'.
> > The two last steps have been combined into
> >
> > DECRYPT=$(scrypt dec /usr/local/bin/myscript) && eval "$DECRYPT"
> >
> > Should I have any more concerns with this command than I have with the
> > two-step process?
>
> If the script is too big to fit in an environment variable, that would be a
> problem.
That passed through my mind. The script is 73 lines and, fortunately.
does fit. Putting the secret in a separate file is, however, a good way
to avoid that problem and the one of having trouble evaluating the
variable.
> Assuming the script fits into an environment variable, evaluating that
> variable in double-quoted context requires deep understanding of both your
> shell and the script (especially if the script is written for a different
> shell, and potentially a different version of the same shell). If you're
> intent upon doing it this way, be sure to test thoroughly.
>
> A pipeline would be more conventional-- decrypt the ciphertext and pipe the
> script to the appropriate interpreter. Here is an example using Perl and
> the ccrypt tools:
>
> 2018-04-20 16:59:50 dpchrist@vstretch ~/sandbox/ccrypt
> $ ll secret-script.pl
> -rwxr-xr-x 1 dpchrist dpchrist 66 2018/04/20 16:58:19 secret-script.pl*
>
> 2018-04-20 17:00:02 dpchrist@vstretch ~/sandbox/ccrypt
> $ cat secret-script.pl
> #!/usr/bin/env perl
> print "The important password is 'secret'\n";
>
> 2018-04-20 17:00:08 dpchrist@vstretch ~/sandbox/ccrypt
> $ ./secret-script.pl
> The important password is 'secret'
>
> 2018-04-20 17:00:14 dpchrist@vstretch ~/sandbox/ccrypt
> $ ccencrypt --key foo secret-script.pl
>
> 2018-04-20 17:00:26 dpchrist@vstretch ~/sandbox/ccrypt
> $ ll secret-script.pl.cpt
> -rwxr-xr-x 1 dpchrist dpchrist 98 2018/04/20 16:58:19 secret-script.pl.cpt*
>
> 2018-04-20 17:00:30 dpchrist@vstretch ~/sandbox/ccrypt
> $ ll decrypt-run-secret.sh
> -rwxr-xr-x 1 dpchrist dpchrist 86 2018/04/20 16:57:27 decrypt-run-secret.sh*
>
> 2018-04-20 17:00:40 dpchrist@vstretch ~/sandbox/ccrypt
> $ cat decrypt-run-secret.sh
> #!/usr/bin/env sh
> echo "The decryption key is 'foo'"
> ccat secret-script.pl.cpt | perl
>
> 2018-04-20 17:00:51 dpchrist@vstretch ~/sandbox/ccrypt
> $ ./decrypt-run-secret.sh
> The decryption key is 'foo'
> Enter decryption key:
> The important password is 'secret'
I prototyped with gpg but ended up with scrypt because it is memory-hard
and slow to decrypt. That seemed to be an advantage; the decryption
passphrase could afford to be shorter and not give users here too much
to remember or type. I'll certainly take a look at what you suggest,
though.
That's two recommendations for putting the secret in a separate file;
I'll follow the advice. My concern was missing some important security
implication but that doesn't appear to be the case. Thanks to Greg
Wooledge and yourself.
--
Brian.
Reply to: