[Cryptech Tech] goals / use cases

[Randy Bush]

>>> Fredrik actually suggested that if we are afraid that our design 
>>> wont fit in the C7, we can take _two_ FPGAs. I think it is a 
>>> splendid idea.
>> really?  you are that worried about the c7.  tim's curve 25519 scared
>> you?
> Yes and no. If we want to get going fast and rather start
> experimenting than doing measurements and planning, by getting a roomy
> and fast CPU, we should do the same with the FPGA.

for sure

> We could go for the C9 which is about 4x in size, but then we need to
> start paying for the FPGA tools (1995 for one seat Windows version.)

i think your argument against license fee is strong.  not a
show-stopper, but strong.

> Instead we can just take two C7 FPGAs and have the be connected to
> each other.

a lot of pins and traces

> And yes, the Curve25519 core scared me.

sigh

> The whole point of Cryptech (at least my understanding of it) is to
> gain trust by as far as is possibly have control by moving away from
> dependencies of application specific functionality that we don't have
> the source to and can control. That is why we want to provide our own
> custom hardware that we can compartmentalize as much as we want.

bingo!

> If we suddenly decided that we trust black boxes in our CPU for random
> generation as well as crypto operations, blobs for firmware and sw, we
> could simply buy ourselves a security chip, add Cryptlib, write some
> custom SW to tie it all together put it in a box and be done.

why bother?  other folk do that.

Peter Gutmann wrote:
> I know that's the theoretical answer, but how would you side-channel
> AES or SHA-1?  For DSA and ECDSA, which are a whole smorgasbord of
> side-channel opportunities, I can see this would be an issue (thus the
> comment about leaving that for an FPGA), but any side-channel on AES
> is going to be something like leaking the key via EMI, in which case
> an FPGA can do exactly the same thing.

that is our code in the fpga, and not our code in the arm.

randy