Ok, I'll add.

Seen. @jukivili can you please add it to the AUTHORS file?

Ok, I have subscribed to the mailing list. I have resent the DCO.

DCO has not appeared on mailing-list. You can this from check list archives, https://lists.gnupg.org/pipermail/gcrypt-devel/2021-December/thread.html

Thanks Jussi, I did not receive the list moderator's email so I am not sure if the it has been posted on gcrypt-devel@gnupg.org. If not, I can resend the DCO. Thanks.

I did some finishing touches on coding style:

Hi Jussi,

Few comments on new patch:

Hi jukivili,

Thank you, applied.

It turned out that the new *.inp files are not part of the release tarball, which makes the tests from generated tarball fail. The attached patch should fix this issue.

Reading compressed point format has been done.
If writing support is needed, please open another task.

This new API is not for FIPS directly (any more), as we introduced pk_hash_sign/verify for FIPS.

Pushed the backport.

Hi jukivili,
I ran some basic tests and it did show the errors. I am in the process investigating what went wrong. In the meantime, i also included test result that I have used in my testing from bench-slope. In this test, I captured the message with 272 bytes buffer from the original libgcrypt repo and my optimized repo. Note that the bulk version of my code do 8x unrolling and the rest will do 16 bytes. So the first 2 128 bytes ran thru gcry_ppc_aes_gcm_encrypt and the rest of the 16 bytes thru gcm_ctr_encrypt (cipher-gcm.c).

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.

• t-dsa
• t-ecdsa
• t-rsa-pss
• t-rsa-15

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.

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 :-)

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 ;-)