[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