vitusb: We had this discussion on cryptography@ years ago. No need to start it again - or well, try it over there. This is a bug tracker and not a discussion forum.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jan 28 2022
Jan 18 2022
These curves are not the default in the compliance mode "gnupg" only if you explicitly switch to the BSI defined "VS-NfD" mode they become default.
Jan 17 2022
In T5783#153879, @werner wrote:Sending a private key with just the local protection is not a good idea.
In T5784#153872, @werner wrote:Please no holy wars on the type of curves. NIST as its opinon, Europe has its opinion, DJB has of course a different opinion. Please use the the cryptography ML for such political/technical discussions.
Sending a private key with just the local protection is not a good idea. It is better to export the key and then send it in an encrypted mail - for example in symmetric mode with a strong password.
Please no holy wars on the type of curves. NIST as its opinon, Europe has its opinion, DJB has of course a different opinion. Please use the the cryptography ML for such political/technical discussions.
Jan 16 2022
Jan 15 2022
Jan 14 2022
Jan 11 2022
I found this post when I was searching everywhere for a solution, and I was delighted. I've recently been trying to upload GpgFrontned in the Apple Store vs Microsoft and I'm having some trouble.
Jan 10 2022
Dec 23 2021
The odds for this case are infinitesimal so this should not have high priority. I consider this only a code-is-as-specified thing.
Dec 22 2021
Dec 20 2021
We can even remove the hexfingerrprint call. Will go into 2.3.4. Thanks.
So, this is the patch. Note that this is for master.
diff --git a/g10/keygen.c b/g10/keygen.c index 7f15027a2..a452ab6d6 100644 --- a/g10/keygen.c +++ b/g10/keygen.c @@ -5619,7 +5619,7 @@ do_generate_keypair (ctrl_t ctrl, struct para_data_s *para, pk = find_kbnode (pub_root, PKT_PUBLIC_KEY)->pkt->pkt.public_key;
The use of register_trusted_key in do_generate_keypair was a dirty hack utilizing a bug in --trusted-key ; it would be better to set the key as ultimately trusted.
I think that the change for T5685 introduced the issue.
Dec 19 2021
Okay, sorry. In the first two cases (encryption), GnuPG 2.2.33 generates
[GNUPG:] INV_RECP 10 F3C987C36C5C6343C9A5D5A1A3F494F6028E4866 [GNUPG:] FAILURE encrypt 53 gpg: [stdin]: encryption failed: Unusable public key
and exits with error code 2, whereas 2.2.32 doesn't display these messages and exits with return code 0.
Please be so kind and describe the regressions you see. 3 log files from your software are not very helpful.
Dec 10 2021
The first is a warning and the other error codes are exactly what we want.
Dec 9 2021
Nov 25 2021
Not a bug but a limitation of 2.2's option listing: In contrast to 2.3 we can't *show* the used options via gpgconf correcly if there is a conflict between global and local options. However, the actually *used* values are different and correct according to the config. In particular a global forced option overrides any local or command line option.
Nov 23 2021
No, too much release work. Better just one AppImage. Or well one VSD (based on 2.2) and one regular (based on 2.3)
Nov 22 2021
Not sure if we want a separate AppImage for gpg & Co. Setting priority to "Needs Triage".
Nov 17 2021
@werner That is not helpful. I tried 4 or 5 different readers. And the Reiner SCT cyberjack is the one that works best out of all of them on both Windows and Linux.
Nov 13 2021
Nov 12 2021
Do not user Reiner SCT those readers are all buggy and work only on Windows - if at all. Stay away from them and get a real reader and not the incompatible broken stuff from that company. I spent way too much time trying to get those readers working. That time is better invested in support for hardware which is standard compatible or are helpful to get stuff running.
Some more info: OpenVPN does not care about the second reader only gnupg agent is sensitive to what is present when it is started. So a workaround that I just found is to disable the Virtual Smartcard reader first so that only the ReinerSCT smartcard reader with an OpenPGP V3.4 card is present. Make sure to open an SSH connection. Then reconnect the second reader. And reconnect to VPN. After the PIN for the OpenPGP V3.4 card is already cached and a connection to the card established I can also open more SSH connections with the second reader attached and disconnect and reconnect the VPN as I want.
Even removing the smartcard from the ReinerSCT reader and plugging it back in works and I can still authenticate with new SSH tunnels and both readers present. So it seems it is actually only important which readers are present when the agent connects for the first time.
So this is a practical woraround. Although disabling the TPM backed reader temporarily needs Admin rights and is really janky.
I am on Windows 10 21H1 and I using gnupg-w32-2.3.3_20211012 from here [1]
Together with win-gpg-agent, which extends gnupg to play nicely with Windows sockets. [2]
Nov 10 2021
In T5598#151696, @aheinecke wrote:I compiled the Appimage with the scripts in Gpg4win and it runs Kleopatra and works :-)
I compiled the Appimage with the scripts in Gpg4win and it runs Kleopatra and works :-)
Nov 2 2021
Tehre has never been an option "shared-access" in GnuPG. At least not in upstream. In general we suggest the use of the interal ccid driver, but if you want PC/SC you need to use disable-ccid-driver. This is because 2.3 does not feature an automatic fallback to PC/SC anymore. Using pcsc-shared with OpenPGP cards can lead to surprising effects. You may want to try Scute as PCKSC#11 access module.
Oct 31 2021
So, I have something working… in the apparent absence of any sort of clear documentation that I could find. I had some time on my hands this afternoon, so had another look.
Oct 19 2021
This has not been set high on the priorities, because keyserver access works for most with Gpg4win (and thus GnuPG) on windows. A recent exception has been occurred about a month ago with Let's encrypt expired root certificate. So currently for Gpg4win 3.1.16 you need to update to a newer GnuPG (Version 2.2.32 at time of writing), by installing the simple installer,e.g. https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.32_20211006.exe
Oct 11 2021
Fix for this issue landed RNP master, and will be included to the RNP v0.16.0 release.
Within fix:
- new keys will be generated with correctly tweaked bits
- using secret key with non-tweaked bits would issue a warning
- CLI command --edit-key [--check-cv25519-bits | --fix-cv25519-bits] added, allowing to fix older key
Oct 10 2021
I did in fact check --status-fd before, but I'm not sure whether it gives me the information I wanted.
Please use the --status-fd interface. This yields all the info you need. An exit code is not distinct enough for such purpose and you need to check the status lines in any case. For scripting gpgme-tool or gpgme-json might be useful as well because they do all the nitty-gritty parts of using gpg correctly
Oct 8 2021
Argh, sorry for bugging. Clearing comment out - I simply missed fact that my tests are run with random messages, so with 5% probability another password will be interpreted as 'good' for the first SKESK.
Sep 29 2021
In my understanding, it should be possible to wait for the gpg command pipe from a different process and then terminate the connection on a timeout, kllling the process eventually. So the Enigmail side could implement something. These days I'm not sure what Enigmail uses for OpenPGP support. Thunderbird has moved on to a different implementation and Enigmail stops supporting Thunderbird 68 in two days https://www.enigmail.net/index.php/en/home/news/71-2021-08-31-end-of-support-for-thunderbird
Well, as I've said in the comment above, there doesn't seem to be any correction towarads --passphrase-fd not requiring --pinentry-mode loopback (still works withou)... and --no-default-keyring still gives the impression that it would be needed (while --no-keyring works as well).
Sep 28 2021
Please don't, if you really feel like tha tis not resolved please re-open this ticket.
@werner shall I open a new ticket for the remaining stuff?
Works if one puts
rootdir = $APPDIR/usr
in the gpgconf.ctl file.
Sep 27 2021
Sep 23 2021
Sep 21 2021
I'm not really sure which version it worked with earlier. This yubikey setup is quite old now, and I've not signed keys recently. I think the last I signed were at least 2 yrs back, hence the very vague allusion to the setup working previously. Apologies, no definite answer there.
Sep 20 2021
- >>gpg2 --version
gpg (GnuPG) 2.0.30 (Gpg4win 2.3.3)
libgcrypt 1.6.6
@amit: Do you say it used to work with GnuPG 2.2.27 or did it worked with an older version?
Which gpg version?
Which Python library? (gnupg is pretty generic)
How does the Python library call gpg?
Are you aware that gpg uses utf8 and not Windows Unicode?
When you sign data, then the signing subkey is used
ssb> rsa4096/0xEB0B4DFC657EF670 2016-04-01 [S]
Just noting that the logs were captured by enabling debug logs for the agent:
eval $(gpg-agent --daemon --debug-all --log-file /var/tmp/gpgagent.log)
Thanks for clarification, indeed attempt to decrypt data returns an error afterwards.
Well, while importing you get the warning:
Yes, for migration from GnuPG 2.0 reasons, a batch import delays the key checking (i.e. converting from OpenPGP to GnuPG internal format) to the first use. Thus you don't see an error immediately. But if you encrypt something , you won't be able to decrypt it again:
Thanks, Werner.
During further work on this got another issue:
Sep 17 2021
The actual patch is rGd4768bb982adb5c8410303334ee8d82ba0d71f3b (our parser in dev.gnupg.org missed to pick up the bug-id due to teh use of scissor lines in the commit message).
The changes do not seem to touch anything I've mentoned in (1)?
I see, I wasn't aware of this. Thanks for fixing!
Thanks for commenting. I close this bug then.
Sep 16 2021
Your proposed fix (in your first comment) has actually already been applied (commit 1305baf0994059f458b1d5ca28a355c12932fab3 in master, backported to the -2.2 branch in 455ba49071dea7588c9de11785b3092e45e4560b). It is part of gnupg-2.2.31 released today. :)
The Qt upstream bug report has just been rejected. I hope something can be done here...
Some quick ideas: On Windows we have envvars (and APIs) to determine certain locations. There is also the registry. We use of all them. IT would be best to do this simalar on Unix. We also have a control file on Windows which switches to that portable mode; maybe it is best to do this also on Unix - A text file installed alongside gpg which gpg (common/homedir.c) uses to enable the use of certain envvars to locate the root etc..
Sep 15 2021
One challenge of the AppImage is how to make gpg and its helpers use the helpers baked into the AppImage. Currently, everything is built with prefix /build/AppDir/usr. This causes
gpg: failed to start agent '/build/AppDir/usr/bin/gpg-agent': No such file or directory
unless gpg finds an already running agent.
Sep 14 2021
Thanks. I meanwhile pushed a fix to 2.3 so that a warning is shown if the low bits are set.
Thanks for the replies, this makes things clear. We'll update RNP to correctly set/unset those bits while saving a generated secret key and a way to fix up previously generated keys.
Right, as long as there is only one format in widespread use (based on a long existing 4880bis draft) only this format should go over the wire.
Thus, it is a matter how the key is exported. In cryptography you should never have several options - one clearly defined format is what you want. We have had enough trouble with PGP5 peculiarities but in that case their implementation had more users and thus GnuPG had to work around it. Not good, but there was no standard at all at this time.
@onickolay No sorry needed. It was me, who cannot answer promptly.
Sep 13 2021
@gniibe sorry for pinging, but this issue gets attention as TB users (with RNP OpenPGP backend) cannot import to GnuPG EdDSA secret key which was generated by RNP since it doesn't tweak bits when storing or exporting a secret key.
Should we update RNP to tweak those bits during storage to be more compatible (given that those bits doesn't make any difference)?
Yes, --no-keyring should enough for the subset of gpg commands which do not need keys.
Sep 12 2021
In T1621#149541, @werner wrote:GnuPG stable (i.e. 2.3.2) has full support for several readers and tokens. This won't be backported to the LTS versions (2.2), though. Better switch.
Sep 11 2021
GnuPG stable (i.e. 2.3.2) has full support for several readers and tokens. This won't be backported to the LTS versions (2.2), though. Better switch.
I've recently acquired two Yubikeys: one Yubikey 5 NFC from my workplace, and shortly after, I bought a Yubikey 5C for my own personal keys… both security tokens have _different_ keys on them. (There are some questions being asked regarding the use of the same GnuPG key duplicated on separate smartcards; this is a different case).
Sep 8 2021
Sep 3 2021
I think the behavior makes perfect sense for Unix but the default delimiter for .txt in Windows is \r\n.
The OP wants to do symmetric encryption. This isn't about the passphrase that protects a key.