[Cryptech Tech] RSA timing experiments with multiple cores

[Rob Austein]

On Mon, 02 Apr 2018 14:13:55 -0400, Pavel Shatov wrote:
> 
> Well, that's very weird.

I thought so :)

> I guess it's stupid to ask,

There are no stupid questions, only arrogant answers.

> but are you sure, you're using the cores correctly? I mean, when you
> need to sign, you look for the first idle core, load it with input
> data and toggle the corresponding control bit? Then you save the
> core's number (to keep track of which core is signing what) and go
> do something else?

Think so, but no, not sure.  This is the first time we've given the
code which assigns cores to tasks a real workout.  We're reasonably
certain it handles two cores correctly, because the current RSA CRT
code uses two cores and we saw the performance improvement when we
enabled that.  Past that...we think it works, but could be wrong.

> Another question, with say three clients does each one of them do 3333
> signatures on average? I mean, aren't you doing 30000 tests for 3
> clients by chance?

Overall structure of test program is a queue of work items and however
many client threads pulling work items from that queue.
Non-preemptive threading, but overall structure should be very
familiar to anyone who's worked with pthreads or similar.

So the number of tasks (signatures to perform) is independent of the
number of clients, and while I'm sure I could screw this up if I
really tried, the overall structure is simple enough that it would
take some effort.

I assume that the underlying problem is on the ARM, not the FPGA.
Just don't know what it is (yet).