[Cryptech Tech] goals / use cases

[Randy Bush]

< fearlessly speaking well above my level of competence >

> What methodology can we use to choose MCU? I think the choice at this
> time is either for an ARM Cortex M4 (later on perhaps upgraded to pin
> compatible new M7), or Cortex A8/A9.

if we choose the fpga based on gate count, any variance throughput and
scale will be dominated by the arm and i/o.  even if we say we want
312.18 dnssec sigs per second, there would be a massive amount of
prototyping and research to go from that to knowing we need a 42.3GHz
arm69 to reach that.  this is an alpha prototype.  as with the fpga, go
for the power.

M vs A seems to be how much do you want to pay in power and bucks for
more compute, with A being the higher powered.  i do not think we are in
the low power game unless we aim for a thumb drive (with a $350 fpga?).
any cost difference between arms will be dwarfed by the fpga.  

in theory, cryptlib and getting things in and out of the fpga and the
board quickly could be helped by core count and speed.  i.e.  having
compute for cryptlib, i/o 'southbound' to the fpga, and i/o 'northbound'
to the world, might take advantage of multiple cores.

otoh, code complexity, threads, ... may not be what we want in the
aplha.  i would really love to hear if paul and rob are prepared to take
advantage multi-core in 2015.  my impression is that they are thinking
an extremely minimal embedded world.  peter has already weighed in favor
of an rtos.  and joachim has been inclined to the simpler M series.  so
i am hoping for serious push-back from our various factions.

A8 vs A9 seems to be 1 (A8) vs 1-4 (A9) cores and outbound bus.  tons of
other details and varies pretty widely between manufacturers.  i presume
that, if we went for the A9 it would be for the cores.  i doubt we need
floating point.  bernd argues for the mmu.

in all cases, there is finding the manufacturer and model that has the
memory, i/o, ... we want and which allows us to minimize the unneeded
attack surface(s).

> there would/could be a huge difference in how we do development in the
> next year or so based on this choice.

my guess is that, for the mid term, i.e. after the aplha, we will want
to be scaling up in terms of speed and capability, not down.  our goal
is to disrupt the hsm and encryption markets, not that of personal
authentication.

< so, since i am blowing smoke way above my level of competence, let me
  really go out on a limb and then saw it off behind me.  this is meant
  as a target to be shot down. >

o the A8/9 series has more horsepower than the M4/M9, we plan to scale
  up.  and the fpga will dominate cost, power consumption, ...

o if we are not ready for multi-core now, then A8, as it puts us on the
  development base which scales better upward

o if we go with something such as embOS, then we have the threads to use
  multi-core when we are ready

o if the bostonians say that can handle more cores now, then A9, else A8

puhleeze fire away!

randy, who will now use packing as an excuse for running for cover