[Cryptech Tech] Incremental digest outputs

[Bernd Paysan]

Am Sonntag, 16. November 2014, 15:08:48 schrieb Rob Austein:
> 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.

Good point; I've been looking through my Ed25519 code, which I recalled is 
doing something very similar.

First, you compute hash(message), which in my case is a SHA-3 hash, using the 
full Keccak state to compute further.  This state is used twice, first you add 
the secret key as data to compute the deterministic, but pseudo-random number 
k=hashadd(sk) for Dan Bernstein's variant of ellyptic curve signatures 
(r=k*base). Then you revert back to the original state after the message 
digest, to compute z=hashadd(r+pk), not recalculating hash(message), which can 
be an expensive operation.  s=z*sk+k completes the signature algorithm.

So yes, I'd like to have a push/pop the current state of a hash algorithm.  
That's doable when the entire state is memory mapped.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/