Patch to speed-up LibTomMath

[Peter Turczak]

Hi Marco,
On Dec 19, 2008, at 3:57 PM, bodrato at mail.dm.unipi.it wrote:

> Hi Peter,
>
>> clocked at 166 MHz), I realised that libtommath was simply too slow.
>
> I agree. LibTomMath has two basic advantages: it is simple, it is  
> portable.
> Speed is not it's main goal, nor memory efficiency (on my 32-bit CPU  
> it
> stores 28 bit per word).
Ok, here you are right. Libtomsfastmath contains ansi-C for  
portability reasons as well as assembler-snippets. So portability  
should not be an issue, more the maintainability.  (See http://tfm.libtomcrypt.com/features.html 
  )
>
>
>> Therefore I adapted the whole dropbear code and libtomcrypt (which
>> already comes with an appropriate interface) to use libtomsfastmath,
>> which heavily uses fix-precision numbers and assembly.
>
> On the other side, assembly coding can give huge improvements to  
> speed, at
> the expense of portability.
You may see above. I tested the code both on an i386 a ppc-mac and a  
m68k, both with assembler and ansi-c, all these test where successful.  
As it was to be expected there where significant speedups when using  
asm snippets.
>
>
>> It would be interesting how close Marco's and my approaches regarding
>> speedups are under real word conditions, say slow/underpowered/
>
> I'm sure that for medium sized integers (exponentiations needed for
> 1024-bit RSA, for example) it is possible to obtain better results by
> introducing efficient base case operations than by fine tuning higher
> level algorithms.
>

Maybe we could use the same abstraction in dropbear as in libtomcrypt  
which seems to work quite well, and let the use decide while compiling.

Furthermore it would be interesting to port your idea to tomsfastmath,  
so we could get even faster ;)


>
>> If there is any demand for a pre-alpha release maybe I would put it
>> on my webpage for you to download, just let me know.
>>
>> Best regards,
>>   Peter
>
> Regards,
> Marco

Regards
   Peter
>