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

[Luke Kenneth Casson Leighton]

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.

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.

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.

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 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.

l.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68