[openssl-dev] ARM optimised montgomery multiplication (armv4-mont)

[Andy Polyakov]

Hi,

>>>>> With some experimentation, it turns out that if I *stop* using the
>>>>> crypto/bn/asm/bn/armv4-mont.pl generated asm "optimised" version, the time for
>>>>> a simplish test to establish and close a simple SSL connection went from 28
>>>>> seconds to 18. (It's quite a slow target at any time).
>>>>>
>>>>> In other words, this "optimised" version has slowed things down dramatically.
>>>>> Has anyone queried the value of the asm of armv4-mont.pl any time in the last
>>>>> few years?
> [snip]
> 
> I found the cause - although OPENSSL_BN_ASM_MONT was defined, I hadn't noticed
> that a colleague had put a #define OPENSSL_NO_ASM somewhere else (this isn't
> linux but a port to our own OS). It turns out that (surprisingly) this
> combination changes behaviour rather than barfing - it's even explicitly
> catered for in bn_asm.c.

In other words sanity restored. Phew! Incidentally, as next step I was
going to ask for copy of your bn_asm.o (yes, binary .o, yes, bn_asm.o,
not armv4-mont.o), and bn_mul_mont should have shown up and presumably
noticed as unexpected...

> Regardless, the effect is that a different bn_mul_mont implementation gets
> used, and the armv4-mont.pl implementation gets ignored entirely.

Right. And as mentioned in commentary bn_mul_mont in bn_asm.c is just a
template with no performance promises attached. Note that it still
exhibits previously mentioned breaking point...

> With that fixed, I now have greatly improved performance as expected.

So that with armv4-mont actually in the loop, the breaking point is
still beyond practical key lengths, even on ARM9.

> An
> unfortunate waste of time for us both, but thanks for the assistance.

Given that presented timings for ARM9 are kind of astronomic you might
want to consider if it's possible to use other algorithms. EC is getting
wider adoption now and can perform better. Not to mention that optimized
NIST P-256 EC was recently added...

Cheers.