[Cryptech Tech] Incremental digest outputs

[Joachim Strömbergson]

Aloha!

The cores do not support padding. We had a discussion about it and you said it was ok to push padding to upper levels (SW).

Skickat från min iPhone

> 17 Nov 2014 kl. 02:08 skrev Rob Austein <sra at hactrn.net>:
> 
> 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?
> 
> NB: I'm not saying that we need to support this, just making sure we
> haven't overlooked something we intended to support.
> _______________________________________________
> Tech mailing list
> Tech at cryptech.is
> https://lists.cryptech.is/listinfo/tech