gcrypt, MPI, GMP and powerpc64

[Torbjorn Granlund]

Werner Koch <wk at gnupg.org> writes:

  It is a matter of code auditing.  We don't want to have unused code in a
  security critical application.  Even if not used it increases complexity
  and requires an auditor to look at the unused code.
  
OK, but then you have a wonderful tool called ar.  It can extract what
you need.

  > That is simply not true.  I have been maintainer since the first
  > release, without any interruption.
  
  Comments in the ssh included gmp also indicated that there was no active
  maintenance at that time.  Quite some bugs in the configure scripts and
  longlong.h had been fixed in Debian and not by you. 

I cannot comment about Debian's local changes to any package, since I
don't follow them.  But if you're judging local changes in any GNU/Linux
or BSD system is an indicator on whether a package is maintained or not,
then I suppose all and every package is unmaintained.

  > It is a shame that you seem to have based your decision only on false
  > information.
  
  "Based on no information" would express that better.  Anyway, there are
  enough other reasons not to use GMP for GnuPG.
  
The NIH factor is usually the most important one in situation such as
this.  Even if people very rarely would confess that to be a factor.

Writing your own bignum code will almost surely introduce more
security related bugs than using a well-tested library.  Do you BTW
completely avoid the C library too?

  When eventually GMP 3 was released I was a bit disappointed that the
  entire configuration system changed in a way which makes it very hard to
  port the code to libgcrypt/gnupg but well that is my responsibility.

You're paying for the NIH stuff.  If you had made the right decision,
and used the GMP low-level interfaces just as they are, then you'd been
much better off.

  >> So now GMP changed too much?  Either it is stalled, or it moves to
  > rapidly.  :-)
  
  I am talking about the years 1997 to 2000.

Do I understand you correctly that the decisions you made in 1997 were
based on what happened in the years 1997 to 2000?

  > 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.)
  
  Meanwhile Werner Dittmann contributed faster X86_64 code.
  
Alright!  But what about your claims about x86 32-bit code?  Show us
your hidden tricks!  Let me again quote your statement from last year:
"We also need better optimized code for modern ia32 CPUS [than in GMP]
..."

-- 
Torbjörn