Hi Marco,
On Dec 19, 2008, at 3:57 PM, [email protected] 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
