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

[Jacob Lifshay]

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

> i just had a word with michiel again and he's happy to move the EUR 12k
> budget to this task.
>
> i say "happy", but because the PET Programme is ended this *cannot be done
> again*, even if we needed it.
>
> just this once then we have the opportunity for a budget for:
>
> * VERY BASIC gcc support for SV
> * binutils
> * the macros idea that you came up with, jacob
>
> https://bugs.libre-soc.org/show_bug.cgi?id=577
>
> the other thing is: i have been looking at Rijndael and after a bit of
> analysis i think we can do crypto-primitives at the basic level through SV
> REMAP...*not* by adding hardcoded 128 bit opcodes.
>

I think that we should have hardcoded 128-bit opcodes for AES
decrypt/encrypt step and SHA* step since that makes it very easy to
guarantee that they will take the same time to execute no matter what data
is being encrypted/decrypted/hashed. using mv.x on bytes to implement a
256-byte lookup table runs the very plausible risk of reading from the
later bytes in the table taking longer than reading from the earlier bytes,
making AES breakable over the network. Also, having to analyze our whole
scheduler just to show data-independent execution time for mv.x is waaay
harder than just analyzing a dedicated pipeline. Additionally, the 128-bit
pipeline will likely give much higher performance since it can execute one
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.

>
> making the router proposal under the Assure Programme mostly about these,
> adding in something about blockchain just to keep the EU Commission happy,
> we stand a good chance of a successful application.
>
> given that bitmanipulation is a heavy part of crypotography we have a way
> to get funding for bitmanip into SV as well.


> now i need to find someone to put as the main signatory.
>

Jacob

>