[.I found an old message in the archives, from July 2006, that I'd like
to comment.]
> - Would it possible to use GMP in gcrypt?
No. For security reasons we don't wnat the whole GMP suff. Just the
modified and meanwhile hopefuly well security audited libgcrypt code.
Of course, not using "the whole GMP suff" doesn't mean one needs to
rip out the code one wants to use. That's the wonderful thing with
libraries.
> - Why using MPI instead of GMP?
At the time I wrote GnuPG (1997) GMP development had stalled for years
and was stuck at 2.something.
There had been 3 releases (2.0 through 2.0.2) in the year before 1997.
GMP 2.0 was the biggest ever change of GMP ever. How many releaases
per year would you want not to consider a project as "stalled"?
There was no maintainer for years.
That is simply not true. I have been maintainer since the first
release, without any interruption.
Only later GMP 3 started and changed a lot of the assembler stuff - I
have seen eports that GMP is far less portable than it used to be.
I cannot question if you have "seen reports" about this and that, but
GMP is about as portable as it has always been.
It is a shame that you seem to have based your decision only on false
information.
There are quite some heavy changes in the internal working and what we
actually only need are the low level fucntions - should be easy to
adjust to libgcrypt but it is more work than I can spend on it.
So now GMP changed too much? Either it is stalled, or it moves to
rapidly. :-)
We also need better optimized code for modern ia32 CPUS as well as for
ia64 or AMD.
If you have some specific optimization ideas for "modern ia32 CPUS",
I'd like to hear about them. People often makes such claims, but they
never seem to be able to get down to details of the optimization they
have in mind. (Granted, the x86_64 code in GMP is far from optimal.)
--
Torbjörn
_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
to comment.]
> - Would it possible to use GMP in gcrypt?
No. For security reasons we don't wnat the whole GMP suff. Just the
modified and meanwhile hopefuly well security audited libgcrypt code.
Of course, not using "the whole GMP suff" doesn't mean one needs to
rip out the code one wants to use. That's the wonderful thing with
libraries.
> - Why using MPI instead of GMP?
At the time I wrote GnuPG (1997) GMP development had stalled for years
and was stuck at 2.something.
There had been 3 releases (2.0 through 2.0.2) in the year before 1997.
GMP 2.0 was the biggest ever change of GMP ever. How many releaases
per year would you want not to consider a project as "stalled"?
There was no maintainer for years.
That is simply not true. I have been maintainer since the first
release, without any interruption.
Only later GMP 3 started and changed a lot of the assembler stuff - I
have seen eports that GMP is far less portable than it used to be.
I cannot question if you have "seen reports" about this and that, but
GMP is about as portable as it has always been.
It is a shame that you seem to have based your decision only on false
information.
There are quite some heavy changes in the internal working and what we
actually only need are the low level fucntions - should be easy to
adjust to libgcrypt but it is more work than I can spend on it.
So now GMP changed too much? Either it is stalled, or it moves to
rapidly. :-)
We also need better optimized code for modern ia32 CPUS as well as for
ia64 or AMD.
If you have some specific optimization ideas for "modern ia32 CPUS",
I'd like to hear about them. People often makes such claims, but they
never seem to be able to get down to details of the optimization they
have in mind. (Granted, the x86_64 code in GMP is far from optimal.)
--
Torbjörn
_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel