[Cryptech Tech] Incremental digest outputs

[Joachim Strömbergson]

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

Aloha!

Rob Austein wrote:
> At Sun, 16 Nov 2014 17:03:02 +0100, Joachim Strömbergson wrote:
>> Rob Austein wrote:
>>> unless I'm missing something, our digest cores don't support 
>>> incremental digest results.
>> You are missing something. ;-)
>> 
>> The cores supports (or at least should) support incremental
>> digests. You can read the digest registers between every block in a
>> multiblock message and get the digest for all blocks up to the
>> latest block.
> 
> The key word here is "blocks".  The API has to deal with bytes (or 
> bits, in theory, but the APIs I've seen are all byte-oriented). For
> all of the digests in question, finalizing the digest involves 
> digesting one or two padding blocks (which are not just zeros,
> there's a fencepost bit and a length count).  Going back to the
> example:
> 
> context = SHAxxxInit() context.addData(foo) result1 =
> context.finalize() context.addData(bar) result2 = context.finalize()
> 
> The first .finalize() call has to generate padding and send it to
> the digest core.  OK, fine.  The HAL can stash a copy of the partial
> block containing the tail end of foo just before generating the
> padding and sending the padding block(s) for foo to the core, that's
> easy.  But how does the HAL set the digest core's state back to where
> it was before sending the padding block(s) so that the user can add
> bar?

That is actually fairly easy to achieve. We just need to expose the
internal space for writing.

Btw: The cores deals with blocks (or whatever the fundamental data size
the core operats o). The sha512_core.v for example has a 1024 bit input
block port and a 512 bit digest output port. The top level wrapper
(sha512.v for example) maps these into 32-bit words accessible fairly
similar to a memory (chip select, write enable and address and data ports).

             input wire           cs,
             input wire           we,
             input wire  [7 : 0]  address,
             input wire  [31 : 0] write_data,
             output wire [31 : 0] read_data,
             output wire          error

This interface is imho a fairly good guess at what is normally used in
system on chip designs implemented in FPGAs and ASICs with a 32-bit CPU
talking to a number of cores. This interface works for example with the
Altera Nios II CPU, OpenRISC, LEON, MicroBlaze and ARM cores.

But if the interface needs to be changed or is not needed the top can be
discarded. In the trng for example I use sha512_core, not sha512.v

If we look at the EIM interface connecting the Spartan-6 to the ARM CPU
it is fairly similar, but only 16 bits wide:

    input wire EIM_BCLK,
    input wire [1:0] EIM_CS,
    input wire [18:16] EIM_A,
    input wire EIM_LBA,
    input wire EIM_OE,
    input wire EIM_RW,
    inout wire [15:0] EIM_DA,

We either need to add a new wrapper that maps the 32-bit registers to 16
bit registers, or implement this at the next level above the cores.

And then the driver/HAL needs to do the mux/demux in SW to map blocks
and other data structures to read/write operations against these
registers. It really is the electrical interface between FPGA and CPU
that controls what the interface to the cores needs to look like and
what SW has to do. This is where the yes, no, maybe comes in. ;-)

But what we could discuss is if the register based, memory like access
is what we want as API between SW and HW. Or if it instead should be
more command+data. It is quite possible that SW talks to the HW by
writing to a single address. And what is written is formatted into
packets with commands and data which then has to be parsed by the HW.

We have been talking about things in this area (netstrings, Randys FIFOs
etc) before. And it is getting about time to decide on how we want to do
this.

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

iQIcBAEBCAAGBQJUabZvAAoJEF3cfFQkIuyNt0MQAMSy7iVEF1KN2c13XHZSitXT
mInSWr9ea05xfGgGFFPJOXmRcVxFaooWNaIkkAqi5r850O/OyCpXfyqvwT5n9g7x
c/7sY91+so64HuL1Heg3lKTfsNqyKiIJHNJINBkNLmGIuy/kTD73u8SKWEjIm6s9
Nze4Ef8EA04JGpvHzKcKCronU1QahGObpcHp9vGFs+8nV+YwPB/3v+/6TZxSKsWI
urr+59J9Aj28P3+FlnvinZFOxAyI87oOpmQj8TeRa5CvqUqNVANGbKhRe6yH+rCI
FsSr8KBlOqarMIxmXjUwjSX7Xc+1MOQFH+XlxrMLlubuoq8CxTKF6cM0h9G2G4ib
giij6+hauIKVlFh7gTho+sa+y1jllCRM/HQS7f4/zEREqq48EB1f9pB//iZQJFw8
l406WWL7gIcj2dnaiBeGwQhe2x2g48yVBJ1n9zgDDRr61CiG44eE2ZqcTSWLj20C
6DvPzX0e8S5TtquwHDDRD2eVlphdv+fV99+JtQtcku14o3ZDs3c7a1w4lq+HBQrs
wfY/lySpjy2XvvMigXvlQWGDRPqD0ZXjul1WOVVAWYJzDNLkwR+VHVqMpjEzZRi0
R/Plfg1vOx1uuYIKEsELw1noTyv70fdYIqp67LiTDTFNLT+pRipZOTavPV/5PKw2
cmM7iwldCtE4aAhy3ggr
=vvAy
-----END PGP SIGNATURE-----