Libgcrypt

As a continuation of the yesterday brainstorming, I want to write something more about the research project. Today I will think about what can make to contribute in the libgcrypt. In this library, the ECDSA that I did in my last research project, was rewritten. This was the objective of the project, to contribute in the free software.

It is necessary to do somethings in this library. The file 'cipher/ecc.c' contains a TODO list with the necessary improvements that this library needs:

• If we support point compression we need to decide how to compute the keygrip - it should not change due to compression.

• In mpi/ec.c we use mpi_powm for x^2 mod p: Either implement a special case in mpi_powm or check whether mpi_mulm is faster.

• Decide whether we should hide the mpi_point_t definition.

• Support more than just ECDSA.

In my opinion, a research project can not be the solution of one of this points. If the research project goes in this direction, the two first points needs to be solve and the third needs to be decided.

How the project was adapted to the libgcrypt? The patch from it comes was written in a monolithic file in the way to do as less modifications as possible in the gnupg (in the 1.4 branch).

Then Werner made a good work moving the particular elliptic data structures to 'src/mpi.h' maintaining in the cryptofile 'cipher/ecc.c' the ones that have a direct relation with the pub and the private keys. Then, there are another file 'mpi/ec.c' that have everything about the mathematics background. But, in my opinion, this have one problem: the elliptic curve discrete logarithm problem (ecdlp) can be brought over primary fields (F_p) and also over fields of characteristic 2 (F_{2^m}), and this file should be split in this two mathematics bases.

This last paragraph propose another possible research project, that is implement what we had over primary fields but over characteristic 2 fields...