Hmm,
$ gpg --with-colons --list-config curve cfg:curve:cv25519;ed25519;cv448;ed448;nistp256;nistp384;nistp521;brainpoolP256r1;brainpoolP384r1;brainpoolP512r1;secp256k1
How would Kleopatra know that cv* is for encryption, ed* is for signing, and all other curves are for both uses? Or are the cv/ed prefixes a (de facto) standard?
You may run
We have tests in gniibe/new-pk-api, which can be backported.
Thank you, applied.
Thanks jukivili for the review.
I have just a note about this issue, that it would be helpful to exercise this new API in some tests. Right now, only the old API is tested.
It turns out that the asymmetric key operations are not yet properly enforced with the .disabled flag. While the other key crypto usually has some "open" api, where this can be simply captured, the pubkey API has several entry points and the "test_algo" is not enough to check for disabled key types.
Just to be correct: Kleopatra takes the default key algorithm from gpg's default_pubkey_algo pseudo option. (Technically, this pseudo option probably uses gpg's --default-new-key-algo option, but only if the latter is set.)
Thanks, however I didn't see your email on mailing-list. Maybe the email got stuck on the way.
I sent a copy to gcrypt-devel@gnupg.org. Hope this is the right process. Thanks.
Please read doc/HACKING carefully on the process of sending DCO the right way.
For the part 1, I created: T5710: FIPS: disable DSA for FIPS
Also, applied the part 2, improving basic.c.
Applied the part 3, the 3DES is no-FIPS patch.
Applied the part 4, the indicator patch.
When the device-side feature was proposed, I had suggested to extend the protocol so that host side can know device side requires user interaction and prompt a user. But... the result was "it can be done with device side only".
I do not like the idea of using the get_config interface for this. It should be easily usable by applications to check for single cipher/mode so int/bool return values would be preferred against the string ones (which are now used in the get_config). I am not sure if getting all the configuration in one string blob would be any use (except for some auditing) either.
Thanks @ikloecker - I'll rebase to the original repo and send it to the email list.
And you may want to read the section "Sending patches" of https://dev.gnupg.org/source/gnupg/browse/master/doc/HACKING.
Hi Werner, Here is the DCO. Thanks.
FWIW: We need a DCO; see doc/HACKING.
No, too much release work. Better just one AppImage. Or well one VSD (based on 2.2) and one regular (based on 2.3)
Just a quick comment regarding GitHub: This mirror of the gpg repo hasn't been updated since many months. Please get the sources of gpg directly from the original source: git://git.gnupg.org/gnupg.git. See https://gnupg.org/download/git.html
Not sure if we want a separate AppImage for gpg & Co. Setting priority to "Needs Triage".
Files added and changed.
The implementation is for Power 10 and above. The improvement is as follow for AES128,
Actually, I have already implemented 1, 2, and 3. For now, I will disallow exporting multiple groups at the same time.
@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.
Your item "2. Allow exporting multiple groups at the same time." is not really important. If you want to do that, please make sure that each group is exported to a separate file.
Importing exported certificate group files from the file manager now also works, at least on XDG-compatible systems. I have also made sure that the application-certificate icon is used for those files in the Breeze icon theme.
Ready for testing
We could use a new mode #define GCRY_GET_CONFIG_FIPS 1 with gcry_get_config:
With just implicit indicators, we would have to block all non-approved cipher modes and kdfs including the OCB mode and skcrypt, which would probably make gnupg2 unusable in FIPS mode, which is not our intention.
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]
A first version has landed.
I compiled the Appimage with the scripts in Gpg4win and it runs Kleopatra and works :-)
I'll fix regressions: failures of pubkey and pkcs1v2.
Blowfish is not part of OpenPGP and according to its creator not the best cipher. Sorry to say no. You may nevertheless be interested in the recent discussion threads on PQC on the cryptography ML.
Applied and pushed symmetric algo for basic.
Any news here? Is this issue going to be fixed or not? It's really annoying.
Thank you for merging the important parts of the patches and implementing similar stuff for DSA. You are right that DSA is supported in the 140-3 specs so it is fine to keep it enabled with the keylength constraints.
Applied parts except part 2.
The part 3 are modified version, so that memory can be released correctly.
Implicit indicators mean that we need to go through the all algorithms and verify that they work if they have approved key sizes/parameters and do not work when they do not.
Yes, no, maybe. :-) Thanks for asking!
I have been using pgpdump for a long time, but it is out of date with regards to ECC. I have looked at its source code but would rather spend my time on my own code.
Please no new levels. And also consider the problems with global config files, conditionals and values taking from the registry. We can't simply do everything in the GUI - it would get too complex and we end up supporting the supportive config dialogs. Maybe a syntax checking editor would eventually be better.
OpenPGP folks now the algo number by heart ;-)
How would you handle a combination of X509 Certificates and PGP Certificates in that case? Wouldn't that require two files?
I was planning to export the certificates in the usual textual formats (.asc, .pem) with the information about the groups added as armor headers for OpenPGP and explanatory text for CMS. This would allow the certificates to be imported with any software supporting OpenPGP or X.509 certificates. When importing certificates Kleopatra simply looks for the additional group information and adds/updates the groups (probably after asking the user).
Regarding the level "internal" I just remembered that gpgconf doesn't list "internal" options. Given that didn't find any internal options that could probably be changed. Or we add yet another level. Or, all invisible options, that shall be offered to users are promoted (or demoted?) from "invisible" to "expert" level.
Okay, but then we need a new level for those options that really must not be shown in a UI, but that still need to be accessible via gpgconf. In fact, there is the level "internal" which does not yet seem to be used for any options, but that seems suitable at least for the deprecated gpg/keyserver option.
While we should have an explicit Import setting I would also like to have a file extension like "kgrp" for key group, cgrp for certificate group is already used by another software.
So that we can register this with a file handler in windows so that such files can get an icon and a double click handler.
I had explicitly added these options because for me the whole "GnuPG System" is an expert level configuration. I would rather move the very important options like the agent timeout settings out of this and then maybe show an info when the user first selects those settings that changing options here could lead to errors in operation.
:-) I thought about such a setting, but at first I want to exclude invisible options from Kleopatra's UI.
FWIW, GPA has a setting where you can select at which level options are shown (but not invisible). IIRC we had the same in Kleopatra but it has been removed.
For libgcrypt, it was fixed in: T5637: Use poll for libgcrypt (support more than 1024 fds)
Configuration dialog with reader-port drop down:
Given it's just in the examples folder it seems strange to remove it, given it doesn't hurt those who don't want to use it, but it's obviously useful to those who want to. But even then, until it's there, why not fix these 2 lines? It's just a config item that will work everywhere
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.
Actually we do not really support the systemd thing and it is likeley that the support in GnuPG will eventually be removed again. You may want to contact the Debian maintainer, who took responsibility for all systemd things.