[Cryptech Core] meeting 28th and 29th

[Leif Johansson]

On 2014-07-17 18:03, Paul Selkirk wrote:
> 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.

Is that how the fpga is connected then? Interesting...

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

Nice!

	Cheers Leif