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:

Please explain what your problems is. Setting arbitrary debug flags is not helpful for your or us.

In T4906#133954, @JW wrote:

@jukivili,

I'd be interested in seeing the results of testing the patch. Can you provide a link to the results?

Of course, you are absolutely correct. I'll update the text accordingly. I thought EdDSA and EcDSA would be expressing differences between Cv25519 and NIST-256. I am not an expert. :-)

EdDSA is sign only - how do you want to encrypt to such a key? Did you mean cv25519 and ECDH?

I also don't think that key size obfuscation is useful, after all the preferences of the key demand a certain key size.

Small fix to translation - found by my friend

I'd be interested in seeing the results of testing the patch. Can you provide a link to the results?

Clever idea.

I'm testing this as an initial start:

ac_ext=c
ac_objext=o

@jukivili : Thank you. Please apply & push it.

Installer in Win10 / Ukrainian environment:

These changes were reworked into Kleopatra patch for all platforms:
https://phabricator.kde.org/D28580

Today I wanted to check linked issue: main window of Kleopatra doesn't remember size.
I worked on it again full day and found really good solution which is already present in KDE libs.
This is new fix for dialogs mentioned in this ticket and for MainWindow:
https://phabricator.kde.org/D28580

@werner what size of each additionally allocated secure memory area would you recommend? Is this something, that is better to set or leave up to the gpg-agent to decide? Will this additional memory be freed when not needed anymore or will it stay allocated until the process dies? I guess, the documentation could be expanded to answer this.

Attached patch should solve the issue for gcc 7.5 and clang 8.

Patch with my fix: https://dev.gnupg.org/D498
(now I know how to submit it!)