[Cryptography] Specialized crypto processor architectures ?

Henry Baker hbaker1 at pipeline.com
Tue Mar 27 12:46:14 EDT 2018


OK, if we're going to have to incorporate a separate
crypto processor on each SoC, then what would be a
good architecture for such a processor?

Essentially all of these crypto "enclaves" appear to
be derivatives of existing designs, and as such, they
inherit most/all of the vulnerabilities of the parent
architectures -- e.g., the recent Intel enclave HW/SW
debacle.

If we're going to have to have a separate processor,
why not a processor *specialized* for crypto?  I.e.,
very wide data words -- 512 bits?  1024 bits?  2048
bits?  4096 bits?  (Think ICL DAP or Pratt's boolean
vector machines.)

With a Harvard architecture, there's no need for
instructions to use either the same memory or the
same word size.  Indeed, I don't see much need for
byte addressable data memory at all.  [We could
even bring back Intel's iAPX432 bit-aligned
instructions!  :-) ]

It's not clear that the data memory for such a
crypto processor needs to be all that large, so
perhaps no cache, but instead a large directly
addressable data memory?

Instructions would likely be VLIW, except that
the instruction cache should be managed by the
compiler, in order to eliminate non-determinism.

With very large data paths -- including very
large ALU's -- there's less need for high clock
rates, and high clock rates would drive up power
requirements.

We could go back to an extremely simple (very
short pipelines) -- and extremely *deterministic*
-- instruction execution regime, with perhaps the
first fully deterministic instruction timing in
30 years.

With today's on-chip memory sizes and today's
on-chip capabilities for wide data paths, a
lot of the constraints limiting performance
of deterministic machines have been lifted,
at least for this class of computations.



More information about the cryptography mailing list