Thanks for the patch. However, this the getopt is unfortunately GNU specific which is the reason why the original code open coded the option parser.

Thanks for testing. It's actually an error of generating _unicode_mapping.c, which utf8.c includes.

Thanks for reporting; the code is really new and not yet fully tested.

Data (ie.e CMS) signatures do now also work.

Fixed in rC0ff36e04f7cd: ecc: Remove hard-coded value for ECC_DIALECT_ED25519..

In the function nist_generate_key (cipher/ecc.c), ec->nbits is number of bits of P.
... while mpi/ec.c sets 256.

It's a kind of "bug compatibility" but it's a regression anyway.

I can't find any places where it is interpreted as signed integer.

@aheinecke could you review it?

I think I fixed a memory leak on error but no other changes for old code except that the array to old the args now takes void* and not gcry_mpi_t - which does not make a difference.

It was a problem of libgcrypt master.
As of today's libgcrypt rC60c179b59e53: sexp: Extend gcry_sexp_extract_param with new format specifiers., it works fine.

It seems it's a falure of ECDH.
I ran a server by s_server and saw following error:

$ openssl s_server -key key.pem -cert cert.pem -accept 44330 -www
Using default temp DH parameters
ACCEPT
140203176436992:error:10067064:elliptic curve routines:ec_GFp_simple_oct2point:buffer too small:../crypto/ec/ecp_oct.c:280:
140203176436992:error:1419C010:SSL routines:tls_process_cke_ecdhe:EC lib:../ssl/statem/statem_srvr.c:3245:

Because it also fails in 0.1.2 (with no GCM support), it seems that it's not GCM thing.

I'm honestly surprised this isn't being given any sort of priority.
gnupg for windows is simply broken. Even Kleopatra, its supplied and designated key management application doesn't work re: keyserver communication.

There are no betas; either you apply the patch mentioned above ( rG2f08a4f25df7) to a stock 2.2.20 or you build from the Git repo (STABLE-BRANCH-2-2, see https://gnupg.org/download/git.html).

thanks a lot dkg and werner :)

Okay certificate and CRL checking does now work with rsaPSS. Need to work on data signatures and check the compliance modes.

Could you guide me to where I find the beta or snapshot, so I could test it and give you feedback? I seem to be unable to find it on my own.

Push the change to master.

Noch was: Die Tipps für die Passphrase auf Seite 26 sind teilweise katastrophal. Der Tipp mit "jeden 3. Buchstaben" sollte entfallen. Die Überschrift heißt doch Passphrase, nicht Passwort. Eine Phrase kann gerne lang sein und auch vollständige Wörter enthalten, es müssen nur genug davon sein.

I started to work on it so that I can actually use the certificates on my new D-Trust card. This will be a verify-only implementation.

Hi @slandden.
Do you have any updates?

That's odd. :-)

FWIW, the code was written by the author of the specs and he note in his original patch (rGe0972d3d96) :

It seems that the reference to PKCS#5 is correct. It is an issue of how to describe the case of more than 8-byte padding in OpenPGP.

Your example data is malformed, I suppose.

Thanks for your report. The problem of GnuPG was that it mandated padding length < 16 bytes, which is wrong.

That smells very much like an old and insecure version 3 key. We don't allow them anymore - use gpg 1 to decrypt old material but never use that key to sign stuff or give it to others to encrypt to you. It is just too weak.

In T4909#134002, @werner wrote:

• Is it a PGP 2 key (OpenPGP version 3 key format)? Support for this has been removed from gnupg 2 for security reasons.

The key was generated with gpg (not gpg2).

• Did you created or imported the key with gpg 1 after you installed GnuPG 2?

Yes.

In this cae, use gpg 1 to export the key and then import it again using gpg 2.

Importing the secret keys gives: