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
• Accepting compressed representation,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?

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?

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

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

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

You can test with newer compiler.

OK. I reopen this ticket to collect information.

It looks like the recipe to build the source file is missing the necessary arch options. I.e., -mcpu=power7 -mvsx ...

I can't reproduce the error (no problem for build). My (cross-)compiler is:

I think that it is compiler issue for AltiVec (now, VSX) support.
The usage is not ambiguous. It _is_ ambiguous in the header file.

Thansk for your report.

Please write proper bug reports and do not just post snippets from some arbitrary build process. In addition master is non-released software and thus it is in general better to ask at gcrypt-devel@gnupg.org for help.

I recall that I talked with Stephan about it but things got lost.

Related the changes, before we did the changes, we received two independent reports.