[Cryptech Tech] IO interface (was Re: Incremental digest outputs)

[Paul Selkirk]

On 11/18/2014 10:30 AM, Rob Austein wrote:
> Eg, if we were just talking about what's most convenient for C code,
> the representation that might make the most sense for a memory-mapped
> implementation might be to map an entire block so one could just
> memcpy() complete blocks in one go, similarly map the entire output
> digest so one could memcpy() the result out.  Control registers might
> be mapped directly; separating these into read-only and write-only
> might be easier to get right, as read-write control registers would be
> potential race conditions even when using C's "volatile" type
> qualifier.  I would like to think that we can avoid byte swapping. :)

This is what the eim interface offers. It uses the same register layout
as the uart and i2c designs, but actually mapped into memory. Down in
the verilog, it still has 16 separate 32-bit registers to hold the block
data, but it memory-maps them to 64 contiguous bytes of address space.
There's also one write-only control register, and one read-only status
register. For systems that support that kind of thing, it's the way to
go for both simplicity and performance.

> But if it turns out that it's simpler to do some kind of command +
> data interface, that's probably OK too, and the semantics might be
> better.  Still would prefer that the data in and out be simple byte
> strings, preferably complete blocks where that makes sense.

This approach makes more sense in a serial interface API, e.g. uart and i2c.

i2c follows Joachim's original uart design, with an odd mix of
command+data and memory-like access. From a user-API point of view, it's
rather chatty. To hash one block with SHA-1, you have to send 16 write
commands, and another write command for the control register, send a
read command for the status register, and another 5 read commands to get
the digest data.

i2c_simple is command+data, but with implicit commands, so it can be
seen as data-only. You write a string of 64 bytes to the magic device
address, and sha1 automatically starts hashing it. Write another string
of bytes, and it hashes that. Read a string of 20 bytes, and you've got
the digest. (And it resets the internal state, so the next write is a
new digest, which means it doesn't support incremental digest outputs.)

So the answer is it depends on the underlying communications channel.
(With an upper-layer API to hide the gory details.)

				paul