[Cryptography] Specialized crypto processor architectures ?

Thierry Moreau thierry.moreau at connotech.com
Wed Mar 28 10:44:15 EDT 2018


Is this post about instruction set architecture for some algorithm or 
about isolation of "secure" computations in a modern processor 
implementation? See more comments in-line.


On 27/03/18 04:46 PM, 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.
>

I guess that those vulnerabilities are intrinsic to two broad classes of 
challenges: an API for a crypto module, and side channel leakage.

> 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.
>

Then what? The economics of fielding a new processor architecture makes 
this attempt at reducing side channel vulnerabilities not feasible.

I see the "open source HSM" model with application agility as a more 
promising research avenue (put both the critical crypto and application 
logic in a device on which the end-user has more control than with 
features-rich computing devices).

Regards,

- Thierry

> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
>



More information about the cryptography mailing list