[Cryptech Core] meeting 28th and 29th

Joachim Strömbergson joachim at secworks.se
Mon Jul 21 07:00:32 UTC 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Aloha!

Paul Selkirk wrote:
> 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).

Great to hear that. If you have any questions on FPGA design, Verilog or
the cores, then don't hesitate to contact 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.

To get started this is a good way forward, and you should actually just
have to replace the uart interface with the I2C interface.

I would however assume that we further on would use either SPI or even
better the EBM interface that provides much higher performance and more
complex transactions (shared data structures etc). The I2C is a slow
single wire interface used for peripherals like temperature sensors. For
testing purposes it will work, but when we want to do real operations
and esp in the use case scenarios we would quite probably need to move
to the other interfaces.

I think we should start talking to xobs and Bunnie about how to move
forward with the EBM interfacing and is why I have previously proposed
this as an action. It will benefit Cryptech as well as Novena and other
Novena projects. EBM with working HW in the FPGA and corresponding SW
drivers running on the CPU is the key to high speed/high performance,
tightly connected FPGA functionality that is the differentiator of
Novena (besides the open source, of course).


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

That should work. The sha1.v (and sha256.v uart.v etc) as you say are
only wrappers that provides a specific interface. We could add
sha1_i2c.v to wrap the core with a suitable I2C interface, for example.

I do this design on purpose to allow one to easily strip away the
interface functionality from the real core.

For EBM we would (imho) probably use word based transactions and what is
in sha1.v should work pretty much as it is for register based API. For
more complex transactions (descriptor ring passing of data blocks +
commands) we would probably need to develop a specific sha1_ebm.v or
similar.


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

Yes. We want diversity of using both Altera and Xilinx FPGAs. Novena
allows us to do higher speed processing and running SW on a more
capable, networked or even GUI enabled system. Esp when using EBM to
connect the Cryptech HW to the CPU.

There is also a question about price and availability that I think makes
sense to keep using TerasIC boards.

Finally, I see the TerasIC boards to be closer to what will be used as
Cryptech applications. At least for more embedded applications such as
Tor key handling.


- -- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
 Joachim Strömbergson          Secworks AB          joachim at secworks.se
========================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJTzLqQAAoJEF3cfFQkIuyNDJIQAI1QUwKfqDZjDJPSFyc8nsnb
+LJP4xwOL54U8ZTml6m4VG1dq0bsDn7EKVnflkDg82lTbgg7htLXhYShyCXONQlA
JZncM/g3lECpUiwGY7t5WlXEig51dxPTBdz/18wzNQ8e6xUsBtjEGdTz312dYo9d
I4qplCSS6q6Mezddl9eOaNzHfdnS3G7RvOkBD9GD6WQ3+0wuSWdkALUdBuINE5BD
jwHIb2EkPDMucvfe+yIBSKmNDwYRHvYad+VX5PtnUNDrAx1Gd3cRjvturIoSj31U
asEfbpDwhB91R2h6GqFw9w61s8eFWsIeDU7Ez+x4EHX8I8PsmdHcgk2OdWJ2IJGj
vkl7U/rMlo1ZSwIml9G+3AbHjHLb7JoTQ2LJi5eP3pIb2/cRgY9PLuxLsBrhTIgB
g+QKGVEQx1TxW3yWJ9jqQcTiyzTtNgTKM59Sasbrk+SmmafQC6QgBzEF3Ps5KEFZ
pq2nRGM4Yk0Tl7jjZI5CD5/hWyJ5YRyk7RNoPhZZFF8TDTJnxq8GcnXMSxwOj9bP
MODIuP7F+ECuD/465ugIKaC29Y6uOb2pv1pq6BZJRO7wxadojkmkbkv/uqf2wlBn
9t/thj3R6S07T2Mg9M1C0E1H30G+YK4FNsSvwPaKibNyi1IbzeNPNQw5hmNFjASp
qu8dPK0qU6EM1cEqdiR3
=CJQh
-----END PGP SIGNATURE-----



More information about the Core mailing list