[Cryptech Tech] Happier RSA timing numbers

[Joachim Strömbergson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Aloha!

Some more results.

I have now coalesced the round operations in aes_encipher to a single
cycle. This reduces the number of cycles for AES-128 ECB Encipher to 17
cycles. An improvement of 3.35 compared to the old aes core.

With these changes the core implemented results are:

- - 2168 slices
- - 2984 regs
- - 122 MHz. (8.17ns)

Slightly bigger core. Still good margin to 100 MHz. I will implement
similar optimization to aes_decipher.

Yours
JoachimS


Joachim Strömbergson wrote:
> Aloha!
> 
> Joachim Strömbergson wrote:
>> Aloha!
> 
>> Rob Austein wrote:
>>> For future reference: a branch of the existing aes repository 
>>> would have been much simpler to test than a whole new
>>> repository.
>> I did considered that, but decided that having two separate cores 
>> with different architectures would be much less confusing.
> 
> To clarify: I expected that the aes core optimized for speed would be
> so much larger (in terms of resources used) that we would never merge
> it into the normal aes core. My experience is that having two quite 
> different architectures and designs in the same repo in different 
> branches that never merge will lead to confusion. Normally the one
> not being the master will be lost, forgotten, not found etc. Even if
> you try to be very explicit in branch naming, documentation etc.
> 
> 
> But I have now done some synthesis runs of the aes_speed core and 
> compared it to the normal aes core. I think that we could consider 
> replacing the aes core with aes_speed.
> 
> Results for Xilinx Artix7-t200.
> 
> Old core (aes) - 2102 slices - 2991 regs - 113 MHz (8.79ns)
> 
> New core (aes_speed) - 2019 slices - 2984 regs - 131 MHz. (7.58ns)
> 
> The better clock speed and a few less registers isn't surprising. A 
> couple of MUXes to provide S-box sharing within the encipher path
> and between encipher and key expansion has been removed.
> 
> But the number of slices is a bit surprising. The mapping tool seems
> to do a great job mapping the S-boxes. For reference, I've done a
> similar modification of the AES core for an ASIC-implementation, and
> there we could see an increase in cells as the number of S-boxes
> increased.
> 
> 
> So, we need to test the AES core in the actual FPGA. If it works we 
> should probably replace the old aes core with the design in
> aes_speed.
> 
> 
> One thing I will do right away is to further optimize performance and
> do cycle measurements between aes and aes_speed.
> 
> This is fun! _______________________________________________ Tech
> mailing list Tech at cryptech.is 
> https://lists.cryptech.is/listinfo/tech

- -- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Assured AB
========================================================================

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJbA9c5AAoJEF3cfFQkIuyN+Y0QAMeDcc/oJ5TI89/kuC7D0K33
1ftvcvHdM+4fOwSQ+ipZOmXaMrdoGDb+J7Bg8HAeNYdAhsoojEQrAZoXvBVzscua
TErxbZz0GyK4EIjR3/mO/Pi6birKjD3UQXjJGXC23gKJvIdcjkHHqU7bFhAXdMpc
OBd5y36P1V8IVl7XAni7BQ+lzBX2mlZvyut3gHlzFMi0NJE+55uyUFuQUjRVdrKA
4vjIk4ygsE7t2r1jVIucQBiG4J8Skfd07W9DqLS/WnYEWuj0p5fWGnmoaM16VIzg
PWY95WeTeD4TjuwUschzi4Z3TggeHkzuP7blbQ3RexWPlJOQPhNQlAdLtZP+y7c8
4FtRMPQyFGWuFxjCCUOIXOmpW2JVYJGPafe53z9z29pJOrZRPabJ+n5GLNZYrpQX
rokFN6Na2o0WlHw9C+ZK+GH7WND4ZXQFyuJ0Q2uretUGwW8IGlEdQ3Wg2zp9Y3oy
F21znDtqh8Hzn4LSlLagqnY2+TPrknWxnkeKRdJFkgHvHfrace7udSKHjR0aUAiX
uL8irKDKXBAcV+dBP3qk5En8P6qrAqwxHyqdUeDZ+BCjUndvaXZleaLGwehb84yl
lgdgZXpyjmbjojifGzOizRNt5ExNCOIgtJ4+vz0WsbOriQhdiXT8kS0VzM4uDzIi
T+EbIH7jnhMViFhce3mG
=SGRU
-----END PGP SIGNATURE-----