> 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_omcuj...@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 _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
