Symmetric encription in batch mode

[Jure]

> On Thu Jan 03 2002; 22:00, Bernard wrote:
> 
> IMO, you can send the data with the passphrase at the begin like this:
> "stupid_passphrase\n"
> "raw/text data"
> 
> I used this style in early code of WinPT and it seems to work. It's
> only important that you add a '\n' to the end because gpg expected
> one line for the passphrase.
> 
> 
> There is another way you can choose for sending the passphrase down
> to gpg. With the --command-fd switch you can control all gpg input.
> In the case gpg needs a passphrase the --status-fd output is:
> [GNUPG:] GET_HIDDEN passphrase.enter
> and then you can send the data with the pipe. I know this way is
> more complicated because you need two additional pipes (status,
> command) but it's the tidiest way.

I came across exactly the same problem: how to pass the passphrase to
gnupg when doing symmetric encryption/decryption from a Java program. In
my program, I am trying to do something like this:

encrypt(InputStream plainText, OutputStream cipherText, String password);

(For example, suppose that a stream coming from one network connection has
to be encrypted and send to other network connection). To accomplish this,
I would like gpg.exe to read plainText from stdin and write output to
stdout. Using --passphrase-fd to specify passphrase presents two problems:

1. how to separate passphrase from data (prepending passphrase + '\n' is a
rather inelegant and possibly dangerous approach)

2. it simply doesn't work - although my program pipes the entire stream
(passphrase + '\n' + data) to gpg's input and receives something which
appears to be the gpg's header - that's where gpg hangs. I suppose this is
an issue of file descriptors (either due to a problem in OS, Java process
implementation, or a gpg's way of handling descriptors).

Realizing security issues, I am nevertheless convinced that the ease of
GnuPG reading the passphrase from an environment variable would greatly
outweight many problems that users (including me) who would like to embed
GnuPG in their own solutions, are confronted with, and are now forced to
invent problematic workarounds like the use of batch files.

So, how about supporting an environment variable (e.g. GPG_PASSPHRASE),
just like PGP does? Of course, a warning should be included wherever it
appears throughout documentation.

Forgive me if this has already been discussed - I did not find any trace
of it.

Jure