[Cryptech Core] Input to NGI_trust presentation?

Paul Selkirk paul at psgd.org
Wed Mar 4 20:00:56 UTC 2020


(Copied to core@ because I think it's a matter of general interest.)

Here are a few performance numbers from recent work.

The following table is signatures/second, using
libhal/tests/parallel-signatures.py, 2048-bit key, 1000 signatures per
run, with 1-4 signers.

        releng      clocking    modexpng    ng + keywrap
1:       6.924       8.106      10.815      13.358
2:      11.660      13.450      16.302      22.188
3:      14.898       9.836       7.095      25.696
4:       7.865       6.848       4.975      25.688

releng: from 2019-09-03 releng tarball
clocking: Pavel's clocking work (90MHz FPGA, 45MHz FMC)
modexpng: Pavel's modexpng core (clocked at 90MHz)
ng + keywrap: modexpng + Joachim's keywrap core

Note that, in all cases, the bitstream is minimally resourced: 1 pair of
modexpa7 cores and/or 1 modexpng core for signing, 1 AES core and/or 1
keywrap core for key wrap/unwrap.

In particular, note that there is a regression going from "releng" to
"clocking" with >2 signers. I believe this is because of excessive
contention for the one AES core for key unwrap. This is made worse by
the fact that the clocking changes reduced the FMC clock while
increasing the FPGA clock, and the "old" keywrap spends a lot of its
time pushing data back and forth across the FMC bus.

Anyway, I don't know how you want to report this. We can show a
performance increase of 2x or 3x, depending on how you pick the numbers.

BTW, Pavel built and tested modexpng with an internal clock of 180MHz; I
wasn't able to get that to meet timing, so my tests were all with a
90MHz modexpng. I did recently fix the driver to take advantage of the
hardware blinding factor mutation, but I haven't addressed the
byte-swapping issues. Point being that we should be able to squeeze more
performance out of this core without a lot of trouble.

				paul


More information about the Core mailing list