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

[Rob Austein]

At Wed, 19 Nov 2014 17:39:07 -0500, Paul Selkirk wrote:
...
> 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.)

In the category of things everybody may already know but better said
than misunderstood: other things being equal, chatty is bad.  How bad
depends on the software environment: if a real operating system is
included and each exchange requires multiple context switches, it can
be quite bad; in a classical deeply embedded environment (operating
system? what's that?), the amount of context to be switched goes way
down or disappears entirely, but there's usually still some overhead
and idle time.  All of this eats into performance.

NB: I have no problem with coretest's chattiness, it's a test tool,
and sometimes one just has no choice, or really needs the debugging
feedback, or really just wants to get //something// usable so one can
move on to a more interesting part of the problem space.  No apologies
needed for any of this.  But in the long run, as we head more towards
what we'd like to see in a production environment, we should be
mindful of the cost incurred by chatty protocols, and avoid them
unless there's an overriding reason why we must do things that way.