[Cryptech Tech] NaCL in hardware

[Peter Stuge]

Pavel Shatov wrote:
>>> I don't think it's OK at all to restrict the usefulness of cryptech
>>> modules so severely, making it impossible to use them with any other
>>> hardware than one particular hardware from one particular vendor.
>
> I don't think, that our modules are impossible to use on a different 
> hardware. To use our modules with a different device, vendor-specific 
> wrappers will need to be ported.

That's what I mean by impossible. If modules aren't already portable
then they aren't immediately usable with other technology.

A single line equivalent is obviously not a big problem, but this is
one of the things that quickly become a slippery slope (things get
worse and worse because of a small step in the wrong direction a long
time ago), which I've seen happen too often already, so I feel it is
important to nag.


> Even if we have a completely vendor-independent module, we still 
> need to generate a bitstream from it, and this process required 
> constraints, that are always device- and vendor-specific.

Constraints and a single line multiplier is not a problem, not having
wrappers for them would be (but cryptech already has wrappers, right?)
and larger blocks without generic equivalents would be problematic too.


> So far we use DSP-based 32x32-bit multiplier in modular exponentiation 
> core. This multiplier can also be synthesized using only generic fabric 
> resources, it will require 1088 LUTs in this case,

What if I would like to synthesize the multiplier to be much slower
but also much smaller? Does it absolutely need to be combinatorial?


> I'm afraid, without DSP-based multipliers we wouldn't have been able
> to show anything at all.

I think you are right, and I don't think it was a mistake to use
them so far, but I do think it is a mistake to have a built-in
reliance on anything vendor-specific in the artefacts that cryptech
wants to output before all funds are spent.

I think it would be wise to run a very tight ship, that is to not
keep temporary solutions in place for long.


> even if you don't explicitly use any vendor-specific stuff, synthesis
> tools may still use vendor-specific features during implementation.

Yes, but that is then a property of the toolchain and not of the modules,
which I think is a very important difference.

The point is to make sure that users actually *do* have a choice of
toolchains.


> Speaking of multipliers, if you think, that DSP slices from Xilinx
> are backdoored, you can force ISE to avoid them at all by using (*
> USE_DSP48="NO" *) attribute.

Good tip! Thanks for that. Personally my worry is about portability
in this (and the next similar) case.


//Peter