Solved in master (1.9). We won't do it in 1.8.

I'm afraid that the dynamic linker doesn't allow hardcoding library path in an executable on macOS.
(It is only supported on some limited platforms.)

For the reference of full mod_sqrt, see https://eli.thegreenplace.net/2009/03/07/computing-modular-square-roots-in-python/

There are no log file but you can run the test by hand:

Patch backported to 2.2

• compressed representation of EC point can be used in:
  • public key
  • (exporting) private key
  • signature
  • ECDH ephemeral key
• For the initial implementation, I'd like to limit our effort for curves of NIST and Brainpool, except NIST P-224, which p = 3 mod 4.

Creating is not that useful - we prefer modern curves anyway.

I think that retrieving a parameter in compressed format is all what we need as per API.

(3) _gcry_ecc_os2ec in libgcrypt/cipher/ecc-misc.c should be modified to support parsing compressed representation.

What kind of API should we offer?
(1) offering something like q@comp name for gcry_mpi_ec_get_mpi
But...
If the intended use case will be in create_request function in gpg/sm/certreqgen.c, the 'q' is already generated in the form of SEXP.
It is up to an application (gpgsm), to convert non-compressed point representation to compressed point representation, here.

We will need this for 1.9

Yes please.

Ok. This was just something that I noticed while going through configure.ac. Should I make patch for this or do you want to?

Changes pushed to master.

Thanks for the info. So I guess me added that restrictions to be on the safe side regarding the VS-Nfd evaluation. For 1.9 we can and should lift that.

Please see [1] appendix F - I tested it more or less on all major CPUs, small
and large, old and new:

AFAIK, Stephan evaluated it only for x86, let me ask him ...

As of now we doubt that the proposed patch helps and we even fear that it could make things worst. Thus, as long as there is we have no description of an attack we won't do anything about it.

Change of gpg-agent for ECC-SOS

Taking a look at other GNU manuals, both GNU make and GNU Bison have a better phrasing,
so I suggest the Bison way (https://www.gnu.org/software/bison/manual/html_node/index.html):

This manual (7 December 2019) is for GNU Bison (version 3.5), the GNU parser generator.

Ah, okay, then the phrasing is missleading, the sentence looks like libgcrypt was released on this date and not the manual.

Nope, that is correct, the last update of the manual was

I tested with this patch (which changes use of constant-time routine when it's secure memory):

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.

Hi @slandden.
Do you have any updates?