[Cryptography] Specialized crypto processor architectures ?

[Ray Dillinger]

On 03/27/2018 09:46 AM, Henry Baker wrote:
> 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.)

Probably two distinct buses with different size words.  One instruction
bus (32 bits? 64? depends on instr and addr structure) And one data bus
(probably 1024 bit blocks, if we project "ordinary" block ciphers into a
post-quantum world by doubling block sizes).  Multiple internal buffers
for both, totalling megabytes long in both cases.  Data instructions
mainly operate on or between buffers, doing operations in parallel or
serially at intervals of one block (for internally defineable block sizes).

One special instruction is "flush all" - it returns every bit on the
crypto coprocessor to a known state, including bits that cannot be
directly read.  I think "flush all" is essential because it's not a
Trusted system, and that therefore a key enclave should be a separate
component from the crypto subprocessor.

This is not a general purpose computer.  A "wall" exists between
instruction bits and data bits.  This starts with separate pins on the
chip die to carry the addresses and separate pins to provide channels
for incoming/outgoing bits, specifically to support special treatment of
these lines in motherboard design and visual/electronic tracing of these
lines to verify designs. Internally, Nothing read on the data bus can
ever find its way into an instruction buffer and nothing can be written
on the external instruction bus.

An Internal MMU is required to ensure that the external address ranges
mapped by the instruction bus never overlap any address ranges which
have been mapped onto the data bus since the last "flush all."
Additionally the "data" bus uses three offsets, also protected by the
MMU to prevent unintentional overlap: Plaintext, Ciphertext, and
KeyMaterial (which includes keys, RNG states, IVs, etc) have different
semantics supported by specialized instructions.

(which ranges have been used as data are by definition forgotten when a
"flush all" is executed and therefore cannot have semantics).

The instruction set is one hundred percent explicit with no speculative
anything.  There are no semantics which are both dynamic and implicit.
To achieve the information bandwidth required to remain performant while
not raising the bit bandwidth to the point where it interferes with
performance, use an explicitly compressed instruction stream.

For explicit compression think "dynamic management of microcode tables",
not "gzip baked into silicon."  Essentially I mean the instruction set
includes "compressed instructions" like "store the subsequent N
decompressed instructions in compression buffer #4" and "execute
compression buffer #4", etc.  "Decompressed instructions" are defined as
those which do not have any semantics that depend on the compression
buffers.  Compressed instructions can not be written into the
compression buffers nor executed from the compression buffers.  On-chip
memory is pretty cheap; you can probably have a lot of fairly long
compression buffers.


	Just a few desiderata to see if anyone has agreements or disagreements
supported by reasoning.


					Bear
----
"It's okay, it's not permanent.  It'll only do that until it explodes."

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20180328/d6d3d1bf/attachment.sig>