[Cryptech Core] meeting 28th and 29th

[Paul Selkirk]

On 07/14/2014 06:38 PM, Randy Bush wrote:
>> I haven't heard any work being done related to Novena and would be
>> very interested in hearing about it. Yes, unless we want to
>> standardize on Cryptech 1.0 == Novena, I think we need to consider the
>> other boards too.
> 
> i think paul may be a closet swede. :)  yes, i am told that is where he
> is spending time.

My wife's grandmother was a Swedish Finn, so I have a fondness for that
part of the world. :) But yes, I do tend to go dark when I'm working on
things but don't yet have anything to report.

Anyway, yes, I've been getting intimate with the Novena board, trying to
learn what I can about its FPGA (coming from a pure software background,
so all this is new to me).

My plan is to adapt xobs's novena-ws2312b-fpga project to talk directly
to the SHA-1 core (and later the SHA-256 and SHA-512 cores) over the I2C
interface. Briefly, I2C is a 2-wire serial bus with its own device
addressing scheme, so this would replace the uart and coretest bits of
the coretest_hashes project.

In fact, I'd like to connect the I2C slave directly to the sha1_core,
and dispense with the pseudo-memory scheme in sha1.v. Stripped down to
its essentials, the host would write 512 bits at a time to the I2C
slave, as many cycles as needed. When done, the host would read the 160
bit digest. Reading automatically resets the internal state so that the
next write is for a new digest. The 'init' and 'next' lines then become
internal state bits (in the I2C slave). On the host side, adapt
hash_tester.py to use py-smbus from the i2c-tools package.

The idea is that sha1_core.v is the important bit, that actually
implements SHA-1, and everything else is rigging (board-specific and/or
project-specific). So sha1_core.v wouldn't change, but everything else
would, in a hopefully more streamlined way.

I don't see this as necessarily replacing the Altera/Terasic design, but
rather validating the algorithm on a different chip/board.

				paul