[Libre-soc-dev] gcc binutils sv cryptoprimitives etc

[Jacob Lifshay]

On Tue, Jan 19, 2021, 12:07 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> On Tuesday, January 19, 2021, Jacob Lifshay <programmerjake at gmail.com>
> wrote:
>
> > AES step per clock rather than needing many separate instructions
> > before/after the mv.x for the table lookup for all the bit-twiddling
> needed
> > for one AES step.
>
> i am not hugely concerned about constant execution time.  as in: with us
> being an OoO engine i have already made it very clear to Michiel that
> trying to get any kind of constant timing guarantee is an extremely bad
> idea and would require vast sums of money far in excess of what they can
> provide.
>

I strongly disagree: what we *need* to get anyone to ever use our processor
for cryptography is data-independent execution time. it doesn't need to be
constant or even consistent (allowing instruction scheduling variations),
it just needs to *not depend* on the actual data values that we're
processing. If we don't provide a AES step instruction (which I think we
should since it will make it much more palatable for OpenPower as well as
being consistent with what lots of existing not-necessarily-cryptographic
software expects), then at the very least we *need* a data-independent
execution time table-lookup instruction.

>
> to reiterate: i am keenly aware from my expertise in cryptography of
> constant execution time: i am saying that for the purposes of this Grant
> application it is HARD excluded - 100% - as out of scope.
>

I'm saying without data-independent execution time our cpu is 99.9% useless
for cryptography. These are minimum viable requirements imho.

>
> this makes for an *achievable* multi-faceted application that steers us
> AWAY from an area that i know from experience will quickly get us into
> absolute hell and cause us immense problems if we cannot deliver.
>
> the other reason for not doing a hardcoded Rijndael primitive is because GF
> operations have many other uses.  ECC, Elliptic Curve, etc etc.
>

Just because we have a AES instruction doesn't prevent us from also having
GF(2) multiply aka. clmul (I even proposed adding it to our integer mul-add
ALU back when I was writing it, since all you need to do is disable carry
propagation).

Also, GF(2) isn't technically part of AES proper, it's commonly used with
AES though for things like AES GCM.

>
> the other reason: anyone can do a hardcoded Rijndael primitive.  i want to
> showcase that SV is a hell of a lot more than just "an excuse to chuck in a
> few custom hard macros and slap an ISA frontend on it".
>

we could alternatively go all-out and make a custom-crypto-primitive
instruction that takes 128-bit inputs, does a bit-swizzle, optionally does
a table-lookup on 8-bit chunks, then does another bit-swizzle. Kinda like a
FPGA. We'd want to try to design it to be usable with SHA3's permutation
function (which operates on 1600 bits!), not just AES/SHA256/SHA1/MD5.

>
> we can do things that other ISAs simply can't, and they are *forced* to
> make these compromises.
>
> also the idea is to load the Grant Application with so many buzzwords that
> all trace back to "blockchain" that they have no choice but to approve the
> independent review :)
>
> if the application mentions EC and its uses in blockchain, and AES and its
> uses in blockchain, and blockchain bl... you get the idea.
>
> i found a couple of papers about this, and they're pretty awesome, the
> tricky bit is the GF modulo rounding when going beyond 64 bit.  i have only
> looked at it briefly bit it seems that having certain base 8/16/32/64 bit
> primitives can be leveraged to do "long bitwidth GF multiply" using
> Karatsuba style multiply algorithms, adapted to GF arithmetic.
>
> that to me is far more interesting than slapping in a 128 bit custom
> MixColumns HDL and saying "ok, done" because it speeds up Elliptic Curve
> Cryptography at arbitrary bitwidth as well.
>

as I said above, having AES step instructions doesn't prevent also having
clmul.

Jacob