[Cryptech Core] Regarding high speed- and ASIC-capabilities

Joachim Strömbergson joachim at secworks.se
Tue Jun 3 06:51:14 UTC 2014


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

Aloha!

Randy yesterday raised the question if we can state that we will be able
to support/do high speed and ASIC implementations.

The short answer from me is that, yes we should be able to state that
with a straight face. But I would like to expand on that answer.

First off, I think one should separate the two issues. High speed does
not hinge on implementing Cryptech in an ASIC. High speed and low cost
is more closely connected to ASIC implemenation.

There are today several FPGA families designed specifically for doing
high speed network processing. These FPGAs have multiple Gbps I/Os as
well as dual port RAM as well as logic and registers to implement
pipelined packet processing, switching etc. There are also Boards with
these FPGAs mounted. Some of them includes SMA or SFP+ cages etc to
allow PHY/MAC interfaces for different technologies.

For my point of view. Implementing really high performance Cryptech
systems with parallel functional cores as well as pipelines within cores
as needed to meet performance targets is quite feasible. Hard but feasible.

The big issues for this being practically feasible is price and power
consumption. But if we are talking fairly low volume, price compared to
an ASIC is probably moot anyway.

Going the opposite direction and doing an ASIC implementation for cost
and power reasons (battery powered key handling for TOR or IoT-stuff for
example) is also possible.

I've worked on both types of ASIC designs as well as high speed in FPGA,
and should be able to assemble a team for doing these things.

The big questions I back to the ones asking would be:

* What they mean with high-speed - is it bulk encryption (GCM mode for
MACsec, AEAD for IPsec or TLS for example), high capacity key
generation, verification and storage etc.

* What are the target applications and environments. Big Iron rack
systems or embedded?

* Unit price acceprable and volume (including what can be pooled by
multiple projects)

* What interfaces would be needed. Data- and contol plane.

* When in time this would be needed?

I have a hard time seeing that we do this in 2014, but possibly in 2015.
But that we could do it I'm pretty sure.

The HW design we do today is not tied to FPGAs and in fact would
probably work better in std cell ASIC technology. Some cores, for
example ChaCha, SHA-x would benefit directly and scale nicely with a
higher clock frequency. In an ASIC or big FPGA we could also pipeline
and/or instantiate multiple cores.

Also, a lot of the control functionality running outside could be
executed on a good CPU core within the FPGA/ASIC with good performance
given more headroom these chips would provide.

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

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
 Joachim Strömbergson          Secworks AB          joachim at secworks.se
========================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJTjXBiAAoJEF3cfFQkIuyN1iMP/ia9hoPcXHyR/GW/okYBjL2+
5mPtL82qoZC1ylSvgDHgM3jnZIM1res4WSafSQiEpOXVtT12rfknXUqxVZRE1zuB
Tsm706CnvWSGwiehqhCry1Ucti4lnYCGZ0x15eZbfVTEpd0WfRjbENRg3rtzXIEx
NOiKG/0mJ66Alzy5DMLl8Q7IJDJg77AZZsZy7zj+RJ2snLGt7yEbBZvmQtaFipLX
Euldi4rzBEHIx+Nsl/ID7jgo5sYylFgEQS/LGz+Nb4pE6Sl4hneBIsel+Rukmi99
RMX6k/mKbZa7ii0S6T8BZxejLJMLMXHQF7TUexqa7Q1oVHqrhNyzQif5/lR+Eut8
bufuNRbcff2lit4sbGeMdZ5BMCyA/4U2ZInaOKbdfmksZ049OIdrbpm+Lp+ytJbe
rJoSRRQ65fcqPCqXWg6zofT3NW69DNP7PLM+orSKLh7O1PP01uBsfJHC4do4DERj
rBv8tiaYxp5pmxxSYqUDICoHey8LNXTiv06tnxcwJhAvXkmMHBINGE1UY908T4AW
7Bk4G9EX1gS2um6lNEhOnpICjYEMdYXH7Eq7GkCTCMW0rbx2+66NVLAHPY6GA0I7
ZpxumoLRG4yhcM0fB6A0oVRD2q3gNbw3xgQRHSmgGHFLiGVOEwvz+iRZ9uEjTQR8
M1I5NYaUzyf9lE7B7rI6
=k9+l
-----END PGP SIGNATURE-----



More information about the Core mailing list