Password from stdin alternatives.

[masarlabs]

Hi,
I have batch script that used to call Scrypt in a pileline in this way:

1. { echo "$PASS" ; cat file_to_decrypt ; } | scrypt dec -P -
2. { echo "$PASS" ; cat file_to_encrypt ; } | scrypt enc -P -

With the new version of Scrypt I get the error:
scrypt: Cannot read both passphrase and input file from standard input

Is there an alternative way to pass the password, for example from an environment variable or from a file?
If not, is it possible enable the old way to pass the password?

[gperciva]

Fascinating! I didn't expect that to work, but it clearly does in scrypt 1.2.1. Test case:

#!/bin/sh
echo "secret" > secret.txt
{ echo "hunter2" ; cat secret.txt; } | ./scrypt enc -P - > secret.enc

(assuming that you're in a directory containing an scrypt binary which is version 1.2.1, and you're not using csh. It works in FreeBSD sh and bash; I haven't tested ksh or tsch or foosh)

Background: I stopped this from working in 1306fba, or #198. That happened in August 2019, but unfortunately I can't remember why I thought it was necessary. It was right before I added scrypt info, but I can't see any hint in those commits which might have prompted me to "clean up" the existing main.c. in that manner.

(I still don't see the use case for this -- if you already know the file_to_encrypt, surely the shell script is easier to write as echo "$PASS" | scrypt enc -P file_to_encrypt.)

If @cperciva thinks that we should allow this behaviour, it'd be trivial to revert those commits and add it to our test suite.

[gperciva]

Update: the test case works in csh if we replace {} with ():

#!/usr/bin/env csh
echo "secret" > secret.txt
( echo "hunter2" ; cat secret.txt; ) | ./scrypt enc -P - > secret.enc

I'm still curious about the goal of having both the password and input file on stdin, though.

[gperciva]

A silly example:

#!/bin/sh
printf "hunter2\nI like fluffy kittens\n" > secret.txt
cat secret.txt | ./scrypt enc -P - > secret.enc

Test it like this:

$ ./silly.sh ; scrypt dec secret.enc
Please enter passphrase: *******
I like fluffy kittens

I think this type of situation is why I thought it was a bad idea to have both the passphrase and input on stdin -- a little mistake in the shell script could end up with the file being encrypted using the first line of the input file, and the encrypted data not containing the first line of the intended plaintext. Of course, we'd hope that everybody would test that their encrypted files contain what they think they do... just like we hope that everybody tests their backups.

I still can't think of a case where having the passphrase and input both on stdin is a good idea, so I'm leaning towards breaking this "workflow" (oblig. xkcd 1172). [[I was tempted to make a dark joke here, but it would look really bad out of context, especially since a close friend's child was born today.]]

[masarlabs]

Thank you for your answer.
I'll wait for the "--passphrase-environ" fix :-)

NB: usually is considered more secure to read the password from a file than from an environment.
https://www.openssl.org/docs/manmaster/man1/openssl.html#Pass-Phrase-Options

[gperciva]

Hi @masarlabs and @nodesocket (from #201),

The master branch of scrypt now includes --passphrase method:arg, such as --passphrase env:VAR and --passphrase file:FILENAME, and they should be part of the next official tarball release.