Example of 'PINENTRY_USER_DATA which can fulfill the' (envpassphrase) 'task'?

[omcujl92 at duck.com]

> Yes, this is a fundamental limitation of public-key cryptography:  to
decrypt a message or generate a signature, the private key must be
available in cleartext.  Some would say that that is the point.

But NOT necessarily saved in clear text to a storage medium.

Which is what >  Some would say that that is the point.

[And if not in clear text, then some mechanism such as 'gpg -d
-passphrase...' must be employed ... and we're circular back to the
point of this thread.]

> If you are trying to have some semblance of security with an unattended
application, have you considered using a smartcard or HSM to store the key?

[Again, unattended has not been an element herein. (Which doesn't mean
it is contraindicated.)]

If trying to avoid cleartext storage, and the infrastructure overhead
of key storage, inherently there is no tolerance for the overhead of a
smartcard or usb stewardship. And there is certainly no tolerance, and
probably no capacity, for the creation or maintenance of a customized
PINENTRY_USER_DATA (to receive the parameter) as T4154 suggests.

Elements such as 'gpg -c ...' exist, for reasonable reasons, or the
effort to code and document things such as passphrases would not have
been made in the first place.

I can understand, coming from the premise of 'public-key
cryptography', that the assumption and requirement of one's own
public-key storage infrastructure be in place. But the presence of
'passphrase' and 'gpg -c' notes that 'gpg' doesn't exist -only-
-within- a public-key storage infrastructure. And thank all for having
so. [This all matters because of the well deserved trust attached to
'gpg', its coding, its auditing, and every other good thing making it
the world's 'go to' for this stuff - including passphrase use. It's a
well known and trusted hammer, and everything herein IS a nail.
Inherently, one wants to stay within the facilities it provides (like
passphrases), rather than customize surroundings to be maintained that
break those predicates.]

Within the subject of this thread: "Example of 'PINENTRY_USER_DATA
which can fulfill the' (envpassphrase) 'task'?" I simply provided one
solution for later readers and web searchers.

[Avoiding everyone easily visible command line and scripted storage of
passphrase, and minimal time of visibility to sensitive data within a
processes superuser-only visible environment variable storage. tmpfs
being a memdisk and duration so short as to be unlikely to be swapped
to physical medium.]

If it is not entirely satisfactory, most certainly alternative
passphrase examples would be most appreciated.

And noted that appending an alternative workaround to the given patch
provided therein at https://dev.gnupg.org/T4154 would be useful to web
searchers.

On Mon, Apr 29, 2024 at 8:14 PM Jacob Bachmeyer
<jcb62281_at_gmail.com_omcujl92 at duck.com> wrote:
>
> Bee via Gnupg-users wrote:
> >> Its is called "USER DATA" for a reason - you have to decide what to do
> >> with it.
> >>
> >
> > But a novel pinentry must be created to receive the data. Again, this
> > is circular.
> >
> >
> >> If your really really want a passphrase, what about passing
> >> the filename of a file holding the passphrase.
> >>
> >
> > AGAIN, this requires clear text storage trying to be avoided in the
> > first place, or ... decrypting the encrypted file on the fly ... which
> > requires a passphrase to be passed ... and we're circular again.
> >
>
> Yes, this is a fundamental limitation of public-key cryptography:  to
> decrypt a message or generate a signature, the private key must be
> available in cleartext.  Some would say that that is the point.
>
> If you are trying to have some semblance of security with an unattended
> application, have you considered using a smartcard or HSM to store the key?
>
>
> -- Jacob