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

Russ Housley housley at vigilsec.com
Tue Nov 18 21:10:31 UTC 2014


>> 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.
> 
> Yeah, this is where I'm not really sure what is the right way to go.
> 
> 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
> memcmp() complete blocks in one go, similarly map the entire output
> digest so one could memcmp() 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. :)
> 
> 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.
> 
> If you think I'm nuts about the simple byte strings, say so.  I'm
> trying to avoid a lot of complicated data shuffling that it sounds
> like the core Verilog code doesn't really need, but if it turns out
> that I'm just transferring pain from C to Verilog we may want
> something else.

I am most familiar with command+data interfaces.  This maps easily to PKCS#11 and MS CAPI.

I am familiar with some command+data interfaces that allowed command chains so that the result of once command could be operated on bay another.  This is especially useful for hash-and-then-sign, but it is often impossible to take advantage of these chains from above the PKCS #11 or MS CAPI where the real applications live.

Russ



More information about the Tech mailing list