Re: How can I 'echo' into fd 3 to be able to use it on a gpg cmd line?
= Prologue: Re-reading https://web.archive.org/web/20171225062127id_/http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/redirection.mspx?mfr=true , I now notice '<& Reads the input from one handle and writes it to the output of another handle.' (Read from one, write to another.) So 'echo %passphrase% <&3' would seem to input from stdin and output it to fd 3. - I can’t think how to test this (under %COMSPEC%), though, and under everything else it doesn’t matter. [If it doesn’t work there, there are workarounds.] - Under %COMSPEC%, file descriptors being broken – as below. = Answer / Solution: How can I 'echo' into fd 3 to be able to use it on a gpg cmd line? Summary: - [outside of %COMSPEC%], short answer: mkfifo myfifo; echo %passphrase% > myfifo & ; echo data | gpg ... 3< myfifo; unset passphrase ; rm myfifo. - [inside of %COMSPEC%], short answer: you can’t (*). %COMSPEC% file descriptors are broken. See thread ending at https://lists.gnupg.org/pipermail/gnupg-users/2024-March/067020.html - cygwin64 is gnupg unsupported, and cygwin32 is deprecated. See https://lists.gnupg.org/pipermail/gnupg-users/2024-March/067014.html for why. - even GnuWin (https://sourceforge.net/projects/gnuwin32/) [https://getgnuwin32.sourceforge.net/] is of no help, the root cause being %COMPEC%, everything run therein remains broken (in this regard) – at least in terms of pipelining file descriptors outside of 0, 1, 2 == ‘stdin, out, err’. So, for example, 3, 4, 5, 6, and beyond == ‘stdwarn, verb, debug, info’ [per https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_redirection] - use wsl, instead. [https://learn.microsoft.com/en-us/windows/wsl/install] (*) Afterward: - Werner kindly appended to the https://lists.gnupg.org/pipermail/gnupg-users/2024-March/067020.html thread above, at https://lists.gnupg.org/pipermail/gnupg-users/2024-March/067021.html, indicating that a workaround for this %COMSPEC% issue will be included in gnu2.6 – with the addition of a ‘--disable-fd-translation’ optional parameter. (Proof of Concept) Goal (Reminder): - echo secret data | gpg –pinentry-mode loopback –passphrase-fd 3 -c 3< $(echo %passphrase%) ; unset passphrase [i.e. without any unencrypted data landing within your filesystems, pipe your sensitive data directly into gpg, towards direct secure storage. e.g. (web) BitWarden backup towards secure (local) storage should BitWarden servers ever become incommunicado (e.g. broken wi-fi or internet provider). BitWarden phones home before unlocking – if it can’t get there, you’re S.O.L. - Nevermind the duplicate functionality of gpg vs Bitwarden, this is a backup, and Bitwarden offers turnkey cross-machine consistency out of the gate. - - But thank all that is holy for what GnuPG was, is, and will be. You want to have both applications to hand. Proof of Concept example script solutions: = gpggetpin-wsl.cmd: - @rem #! %COMSPEC% @echo off set "GOTPASSPHRASE=" for /f "delims=" %%p in ('wsl /mnt/c/bin/gpggetpin.bash') do set "GOTPASSPHRASE=%%p" set /p "scratch=%GOTPASSPHRASE%" < nul: set “ GOTPASSPHRASE=” = gpggetpin.bash: - #! /usr/bin/env bash # gpggetpin.bash: # SHORT VERSION: # GPG_TTY=$(tty) ; printf "GETPIN\n" | pinentry -T "${GPG_TTY}" | sed -e "s/^OK.*$//" -e "/^[[:space:]]*$/d" -e "s/^D //" bash -n "${0}" || true shellcheck -W 0 -Calways "${0}" || true # printf "getpin\n" | pinentry -g -T "$(tty)"# - NOT HAPPY! declare -g GPG_TERM ; GPG_TERM="${TERM}" ; export GPG_TERM declare -g GPG_TTY ; GPG_TTY="$(tty)" ; export GPG_TTY declare -g gs_passphrase="-1" declare -gi gi_0=-1 gs_passphrase=\ "$( \ printf "SETDESC My description\nSETPROMPT My prompt\nSETTITLE My window title, iif there is a window\nGETPIN\nBYE\n" \ | pinentry --debug --ttyname "${GPG_TTY}" --ttytype "${GPG_TERM}" --lc-ctype "en_ca.UTF-8" --lc-messages "en_ca.UTF-8" \ | sed -e "s/^OK.*$//" -e "/^[[:space:]]*$/d" -e "s/^D //" \ )" gi_0="${?}" # USELESS - too many progs (retcodes) between source and end. if false ; then { (( ! gi_0 )) && { printf "\n:: passphrase retrieval failed (%d), exiting.\n\n" "${gi_0}" ; exit "${gi_0}" ; } } ; fi case "${gs_passphrase}" in ( "-1" );& ( "" );& ( "ERR 83886179 Operation cancelled " ) # printf ":: no valid password retrieved (%d)[%d]. Exiting.\n\n" "${gi_0}" "${#gs_passphrase}" exit "${gi_0}" ;; (*);; esac # printf ":: passphrase retrieved (%d)[%d].\n\n" "${gi_0}" "${#gs_passphrase}" # printf "\n|%s|\n\n" "${gs_passphrase}" printf "%s" "${gs_passphrase}" unset gs_passphrase = gpgtest-wsl.cmd: - @rem #! %COMSPEC% @echo off wsl /mnt/c/bin/gpgtest.bash = gpgtest.bash: - #! /usr/bin/env bash printf "\n" set -vx declare -g gs_mysecretpassphrase="KXhtctw4_zFfhRop" # More usually acquired somehow else. declare -g gs_myfifo="$(mktemp -ut fifo.XXX)" mkfifo -m 0600 "${gs_myfifo}" printf "%s" "${gs_mysecretpassphrase}" > "${gs_myfifo}" &
Re: x488 vs all other : keyid flip
On Thu, 28 Mar 2024 13:54, Christian Sommer said: > Likewise by telling GnuPG you really want the short keyID displayed > (gpg --keyid-format short) it takes the LAST 32 bytes of the FIRST 64 > bytes of the fingerprint. The thing here is that the short keyid is not from the specification but a convenience thing PGP-2 implemented (which actually did not compute the keyid from the fingerprint). Yes, it would indeed be nicer if we could work with the keyid in the same way as git handles a commit id. Unfortunately it will be pretty hard to change how the short keyid is derived from the long keyid or even use arbitrary sized keyids of fingerprints. In GnuPG the keyid is a "u32 kid[2]" and this is used a lot all over the code, for example: fprint ("long keyid: %08lX%08lX\n", (ulong)kid[0], (ulong)kid[1]); fprint ("short keyid: %08lX\n", (ulong)kid[1]); > discovered GnuPG for myself. so i'm completley new to this community > what's the preferred development model? i guess filing an issue, See doc/HACKING for hints. Please also be aware that for any unattended use you need to use the --with-colons and --status-fd interfaces. Some ignore this advice and thus we are nice and try to minimize all changes even to the human readable output format. 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: x488 vs all other : keyid flip
you are absolutely right: when explicitly telling GnuPG to display x448 fingerprints (gpg --fingerprint) it just spits out the "abbreviated hex format" by takes the first 50 bytes and sweeping the rest under the rug! Not very nice. Likewise by telling GnuPG you really want the short keyID displayed (gpg --keyid-format short) it takes the LAST 32 bytes of the FIRST 64 bytes of the fingerprint. i prefer getting what i ordered. of course it's a trivial thing for my self counting the first eight hexadecimal characters to fulfill my particular use-case (i'd like to have matching mail-addresses and short key-IDs). although you gave the impression nobody would use those command line options (plainly because of that ?"fingerprint-forgery-attack" occurring on short key-IDs) why then don't ditch it? on the other hand, until it's here i feel inclined on fixing it. so if there are no objectiions i'd like to try myself on both errorneous outputs. as you may have notices it's just a few weeks ago when i discovered GnuPG for myself. so i'm completley new to this community what's the preferred development model? i guess filing an issue, forking the repository, making a pull-request, but there are also those T-numbers linked by releases. ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Get the private portion of subkeys
Hi Damien! On 28.03.24 08:26, Damien Cassou via Gnupg-users wrote: As you can see, there is a '>' character before each subkey but not before the master key. Someone on the web has a similar setup but doesn't have the '>' before his subkeys [1]. The ">" indicates that the key is on a smartcard. (The > is the corner of a card ;) (Smartcard is synonym to USB tokens like YubiKeys) Is that a problem? Am I missing something important? It seems this causes me the troubles mentioned at [1]. In [2] it is mentioned, that the key marked with an [A] is needed. [A] indicates the "authentication" key. This is what you want. But the private part of your [A] key is only on the smartcard. And the security idea of the smartcard is, that you can not extract it from there. In [1] you described your 'gpg --export-secret-keys'. If you do a `gpg --list-packets ./damien.asc` on your export, you can see that this still references the card. So it won't work this way. But if it is about ssh login into another system you can use the gpg-agent as a the ssh-agent and get the security with your smartcard. You have to add 'enable-ssh-support' to your gpg-agent.conf. See: man gpg-agent [1] https://github.com/pinpox/pgp2ssh/issues/6 [2] https://github.com/pinpox/pgp2ssh Best regards Alexander OpenPGP_0x213E2CD3CABCF0B9.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Get the private portion of subkeys
On Thu, 28 Mar 2024 08:26, Damien Cassou said: > Is that a problem? Am I missing something important? It seems this > causes me the troubles mentioned at [1]. Your subkeys are all stored on a smartcard. The primary key is online. This is as intended. If you remove the the primary private key (.key) You should see a '#' mark for the primary key. > My private master key is symlinked in ~/.gnupg/private-keys-v1.d: That is intended to work but has not been thoroughly tested. > [1] https://github.com/pinpox/pgp2ssh/issues/6 That reminds me that we have a function export_secret_ssh_key but it will always fail with a not-implemented error ;-). Noone of the core hackers felt a need for it. For example I have not used anything else than gpg-agent based ssh access since 2005. 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
Re: x488 vs all other : keyid flip
On Thu, 28 Mar 2024 00:49, Christian Sommer said: > on the other hand a x488 fingerprint is 50 hex characters long. let's say > it's 1 2 3 4 0 0 A B C D then its > long keyid is 1 2 3 4 and its short keyid is 22 3 4. x448 keys are created as version 5 keys and version 5 keys come with a 32 byte fingerprint (v4 has 20 bytes). Also the way the keyid is computed has changed: For v5 keys the keyid are the left most 32 or 64 bits. For display purposes an abbreviated hex format is used. It might be that the keyid is then display wrongly - frankly I have not checked because keyids are rarely used. Even the formatted fingerprint ("gpg --fingerprint") is not very useful anymore because the majority of users just copy+paste the fingerprint and thus the straight hex format as displayed by "gpg -k" is more useful. Here is an example: pub ed25519 2016-02-02 [SC] FD8FEC4F8595AB1B6F60D43FC2CED0800E50ACF1 uid [ unknown] chicago sub cv25519 2016-02-02 [E] 532D5C7677B4D806B50B0E0F11E7BF9EE1034B1C sub cv448 2024-03-27 [E] FB6A3BC5EB92C8AA9F3807A9B4C79C38F16E9AA4CF9384B07485923574773DCF where a v5 subkey has been added. Note also that I use the --with-subkey-fongerprint option which will eventually be the default. 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
Re: x488 vs all other : keyid flip
excuse me sirs. when i wrote that question i was already very tired. so in the meantime i realized that there are different code paths for ed/x448 goldilocks. one of them distinguishes the Endiannes on behalf of the algorithm (e.g. sets is_little_endian to true | false in g10/ecdh.c). i haven't found the time to go much deeper yet, but this and the read_16 / 32 in g10/parse-packet.c as well as the convert_le_u16 / 32 functions in scd/ccid-driver.c / tools/ccidmon.c seem to play a role. i guess key-IDs are calculated on demand and not stored separately along fingerprints. based on what i've seen until now i tend to accept that the short keyid 22 3 4 of above example is in fact right. on the next occasion my search will go on, but if anybody can confirm and tell even more about that observation, i'd be very grateful. ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Get the private portion of subkeys
Hi, I have a usb smart card containing my subkeys and my master key is stored offline on a usb disk. When I list my secret keys while the usb disk is plugged in, I get: sec ed25519/0xF72C652AE7564ECC 2018-07-09 [C] [expires: 2027-12-21] Key fingerprint = 8E64 FBE5 45A3 94F5 D35C D202 F72C 652A E756 4ECC Keygrip = 35A4020C4AFC2279CEE0BC36E2CEE4EFA8C6CFD5 uid [ultimate] Damien Cassou uid [ultimate] Damien Cassou uid [ultimate] Damien Cassou ssb> ed25519/0xB68746238E59B548 2018-07-09 [S] [expires: 2026-01-02] Keygrip = C89E5AABCBF7142DBC26E68FB3121DE12DCBF4FF ssb> cv25519/0x65CD5E0200C56C17 2018-07-09 [E] [expires: 2026-01-02] Keygrip = 867EA9F6ADBEBE18ED98253B884F53CBD53C526B ssb> ed25519/0xF36CF32DF9B09855 2018-07-09 [A] [expires: 2026-01-02] Keygrip = 553D56865642B05AB3C5B62DC68795691702B960 As you can see, there is a '>' character before each subkey but not before the master key. Someone on the web has a similar setup but doesn't have the '>' before his subkeys [1]. Is that a problem? Am I missing something important? It seems this causes me the troubles mentioned at [1]. Recently, I changed my usb smart card and kept the same keys so I believe I have everything needed in some form. My private master key is symlinked in ~/.gnupg/private-keys-v1.d: $ ls -l ~/.gnupg/private-keys-v1.d/ … 35A4020C4AFC2279CEE0BC36E2CEE4EFA8C6CFD5.key -> /media/mystick/key … [1] https://github.com/pinpox/pgp2ssh/issues/6 -- Damien Cassou "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users