Re: Example of 'PINENTRY_USER_DATA which can fulfill the' (envpassphrase) 'task'?
> 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 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
Re: Example of 'PINENTRY_USER_DATA which can fulfill the' (envpassphrase) 'task'?
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
Re: Example of 'PINENTRY_USER_DATA which can fulfill the' (envpassphrase) 'task'?
> 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. > Or a socket or some > another secure IPC mechanism locator. Or ... 3 lines of script in the example you seem to be ignoring? mkfifo myfifo secret="passphrase" echo $secret > myfifo & unset secret echo "secret stuff" | gpg -c ... -fd 3 3< myfifo > For unattended use Unattended has not been mentioned. > For unattended use the only reason for a passphrase - which protects the > private key There is no private key in any scenario listed here. The point has been to avoid key infrastructure overhead entirely. [Yes, the passphrase is the key, but that is irrelevant semantics for purposes here.] Again ... 'echo "secret stuff" | gpg -c ...' Again, posting an actual workaround to the bottom of https://dev.gnupg.org/T4154 would be very welcome, and websearch visible to those so looking. - and the providing of such an example was the only purpose in writing the message you responded to, first, today. Saying the expressly desired use (e.g. dev.gnupg) is inappropriate is specious and counter-productive. Clearly the use is intended, given the presence of the word 'passphrase', even within 'man gpg'. On Mon, Apr 29, 2024 at 7:44 AM Werner Koch wrote: > > On Mon, 29 Apr 2024 07:03, Bee said: > > > But that environment is not passed and used by pinentry - it has no > > knowledge of them. PINENTRY_USER_DATA may exist, but it has no > > knowledge as to how to interpret it. Ergo, some other mechanism must > > Its is called "USER DATA" for a reason - you have to decide what to do > with it. If your really really want a passphrase, what about passing > the filename of a file holding the passphrase. Or a socket or some > another secure IPC mechanism locator. > > For unattended use the only reason for a passphrase - which protects the > private key against local users - are stupid policy requirements you > have to follow. In all other cases, first come up with an attack tree > to show that a passphrase is of any use for your application. ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Example of 'PINENTRY_USER_DATA which can fulfill the' (envpassphrase) 'task'?
On Mon, 29 Apr 2024 07:03, Bee said: > But that environment is not passed and used by pinentry - it has no > knowledge of them. PINENTRY_USER_DATA may exist, but it has no > knowledge as to how to interpret it. Ergo, some other mechanism must Its is called "USER DATA" for a reason - you have to decide what to do with it. If your really really want a passphrase, what about passing the filename of a file holding the passphrase. Or a socket or some another secure IPC mechanism locator. For unattended use the only reason for a passphrase - which protects the private key against local users - are stupid policy requirements you have to follow. In all other cases, first come up with an attack tree to show that a passphrase is of any use for your application. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Example of 'PINENTRY_USER_DATA which can fulfill the' (envpassphrase) 'task'?
Again, specious. > Simply don't use a passphrase if you need to resort to such a thing. On > many systems you - and other users - can easily look at the > environment. But that environment is not passed and used by pinentry - it has no knowledge of them. PINENTRY_USER_DATA may exist, but it has no knowledge as to how to interpret it. Ergo, some other mechanism must be used. Such as an environment variable. So that the passphrase is not visible within the script or a command line listing of the process table. And preferably not even stored anywhere, in plain text. A script (containing a hardwired passphrase) may well remain in existence for some time, even, as a service, forever. The passphrase remaining visible - both script, and/or command line, for the duration. The solution given, for example, leaves no passphrase visible in script or command line - in plain text only for the minimal number of script lines - assuming a nefarious user is even present for those microseconds, never mind a casual one, -AND- that they have superuser privileges to even be able to examine foreign (to the userid) process variables. While even casual users can view scripts and process tables [but not foreign process' environment variables]. It is quite evident that passphrase use is intended by gpg design. Search 'passphrase' within 'man gpg' and one cannot escape such a conclusion. Particularly '-c'. e.g. echo "Secret data to be encrypted" | gpg -c ... Examples of on the fly script use without key overhead have been requested [here (thread(s) earlier) and elsewhere], that do not involve keys or hardwiring a passphrase - without answer. If you have such, please post. If I missed it, apologies, please advise of links. If passphrase use was not to be used, then all code and documentation containing the word 'passphrase' would have been stripped from the content long ago. That it hasn't been can only be taken to mean that it is intended and desired functionality. A working alternative algorithm posted to the end of https://dev.gnupg.org/T4154 would be welcome, and websearch visible to those so looking. As it stands, things are circular - the suggested solution is a custom PINENTRY_USER_DATA, and ergo a customized gpg environment crafted to receive it, but if that were in place or desired, the requested and delivered enhancement wouldn't be needed. This is circular. A working alternative (key-free and clear text free) algorithm posted to the end of https://dev.gnupg.org/T4154 would be welcome, and websearch visible to those so looking. On Sun, Apr 28, 2024 at 12:53 PM B.S. wrote: > > > > At https://dev.gnupg.org/T4154 , 'allow setting passphrase from an > environment variable', there is a comment of "I don't see why we > should add yet more clumsy passphrase workarounds to gpg. We already > have PINENTRY_USER_DATA which can fulfill the same task." > > Of course, the reference here to PINENTRY_USER_DATA is specious. To > incorporate the processing of such a customized PINENTRY_USER_DATA requires > the coding of a corresponding pinentry executable to receive it. > > And if one has the capacity to code one's own unique pinentry executable ... > they could code around the stated problem outside of using PINENTRY_USER_DATA > in the first place. > > And the T4154 request would never have been made, in the first place. > > > So, given the above, a solution towards: > > >+ (https://dev.gnupg.org/T4154) > >+ > >+ So this patch adds a new form of passphrase-passing, using an environment > >+ variable. In POSIX shell, this looks like (for example): > >+ > >+ mypass="IUuKctdEhH8' gpg --batch --pinentry-mode=loopback \ > >+ --passphrase-env=mypass --decrypt < message.txt > >+ > > can be effected without resorting to PINENTRY_USER_DATA - so no need to code, > customize, maintain, update per gpg upgrades, or apply patches to in-house > self-solutions. > > > > Can anyone give an example of doing so? > > > I am looking to effect the equivalent of ... > > > Has anyone got a link to a working example of '3<' or 'PINENTRY_USER_DATA > > which can fulfill the same task' of gpg picking up its passphrase from an > > environment variable? > > > Examine https://lists.gnupg.org/pipermail/gnupg-users/2024-March/067030.html > ('How can I 'echo' into fd 3 to be able to use it on a gpg cmd line?') for a > more detailed example script solution, but in brief for this thread: > > > gs_myfifo="$(mktemp -ut fifo.XXX)" > mkfifo -m 0600 "${gs_myfifo}" > > gs_mysecretpassphrase="KXhtctw4_zFfhRop" > > echo -e "${gs_mysecretpassphrase}" > "${gs_myfifo}" & > unset gs_mysecretpassphrase > > echo -e "Stuff to be encrypted." \ > | gpg --pinentry-mode loopback --passphrase-fd 3 -c 3< "${gs_myfifo}" > > rm "${gs_myfifo}" > > > Of course, 'gs_mysecretpassphrase="KXhtctw4_zFfhRop"' would be replaced with > some other mechanism of acquiring the passphrase. Perhaps via something such > as: > > export GPG_TERM="${TERM}" > echo -e "GETPIN\nBYE\n" \ > | pinen
Re: Example of 'PINENTRY_USER_DATA which can fulfill the' (envpassphrase) 'task'?
On Sun, 28 Apr 2024 13:02, Bee said: >>+ (https://dev.gnupg.org/T4154) [...] >>+ mypass="IUuKctdEhH8' gpg --batch --pinentry-mode=loopback \ >>+ --passphrase-env=mypass --decrypt < message.txt >>+ > > can be effected without resorting to PINENTRY_USER_DATA - so no need to > code, customize, maintain, update per gpg upgrades, or apply patches to > in-house self-solutions. Simply don't use a passphrase if you need to resort to such a thing. On many systems you - and other users - can easily look at the environment. It is also part of all kind of bug reports. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users