[Cryptech Tech] NaCL in hardware

[Pavel Shatov]

On 29.09.2015 13:57, Peter Stuge wrote:
> 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?

Well, the whole point of using a multiplier was to speed up calculations 
in FPGA and make it at least on par with software implementation. If you 
don't need high speed core, you don't need a multiplier at all, an adder 
will do.

>
>> 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
> _______________________________________________
> Tech mailing list
> Tech at cryptech.is
> https://lists.cryptech.is/listinfo/tech
>

-- 
With best regards,
Pavel Shatov