GnuPG Security Disaster?

[Dmitri]

Quoting Bernard <bht at actrix.gen.nz>:

> I am using gnupg decryption executed from within a Java application in
> an external Win95 process.
> 
> Due to a bug somewhere between Win95/98 and the Java Virtual Machine,
> Java cannot write to stdin of the external gnupg process.
> 
> That forces me to write and execute a batch file that pipes the
> passphrase into stdin of the gnupg program.
> 
> I suppose that security-wise, this technique is the opposite of what
> the designers intended to achieve with the option
> 
>        --passphrase-fd n
>                  Read  the  passphrase from file descriptor n. If
>                  you use 0 for n, the  passphrase  will  be  read
>                  from  stdin.     This  can  only be used if only
>                  one passphrase  is  supplied.   Don't  use  this
>                  option if you can avoid it.
> 
> The pgp command line program which I used before has a passphrase
> command parameter (-z). I guess it was more secure with Java because
> the passphrase was not written to disk.

Java does not have DOS loader built in (it's part of the OS), therefore it
has to pass the executable name and parameters to the OS for loading and
starting the process (like system() call). At this moment you lose control
of your command line parameters, passphrase included. The OS itself, and
any 3rd party utilities (like pview and debuggers) can get to that data.

> Can anyone suggest a more civilised approach to interfacing to the
> Windows executable from within Java?

Use GPGME? JNI would be nice.

> As far as I can see the current situation is a disaster.

Dmitri

P.S. Does anybody know why this piece returns Out_Of_Core?
The similar code works before and after (to list the keyring).
Could it be a timing issue? I couldn't find a GPGME manual anywhere.

The 'ctx' handle is opened once and used by all procedures, sequentially
(since I have only 1 thread, this is GNOME/GTK app).

-----------------------------------------------------------
void pgp_del_key(char *ring, int secretRing, char *del_uid)
{
    GpgmeError ge;
    GpgmeCtx ctx;
    GpgmeKey rkey;
    int num_deleted = 0;

    (void)ring;

    if (OpenGpgme() != GPGME_No_Error) {
        pgman_error = "gpgme_new() failed";
        printf("pgp_del_key: gpgme_new: ge=%d.\n", ge);
        return;
    }

    ge = gpgme_op_keylist_start(ctx, del_uid, secretRing);
    if (GPGME_No_Error != ge)
        return;

    while (TRUE) {
        ge = gpgme_op_keylist_next(ctx, &rkey);
printf("gpgme_op_keylist_next: ge=%d.\n",ge); <=========== HERE =====
        if (GPGME_No_Error != ge) {
            if (GPGME_EOF != ge) {
                    //pgman_error = "gpgme_op_keylist_next() failed";
            }
            break;
        }

        /* Have a valid key - process all UIDs of it */
[...snip...]
        gpgme_key_release(rkey); /* Frees the key */
    }
    gpgme_op_keylist_end(ctx);
}
-----------------------------------------------------------

-- 
All theoretical chemistry is really physics;
and all theoretical chemists know it.
  -- Richard P. Feynman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
Url : /pipermail/attachments/20020102/10db5205/attachment.bin