On 13/04/10 15:02, ext Herbert Xu wrote:
On Tue, Apr 13, 2010 at 01:13:47PM +0300, Dmitry Kasatkin wrote:
As I can see from the patch initial vectors calculated with SW shash
Rest is done in hw, basically sha1.
Ideally that code shouldn't be duplicated either, but honestly
that doesn't matter when it comes to whether the hardware can
do HMAC directly.
You only compute the IVs once for each key, so whether it's done
in software or hardware doesn't matter.
The same can be done with omap driver.
Just in addition to finalize as done in hmac_final().
If you do hmac_final in software, then this is no longer a hw
HMAC implementation and we should instead implement an ahash
version of hmac.
The difference here is that ipad/opad is computed only once for
a key, while final happens many times over the lifetime of that
key.
I do not see your point.
As stated by Uri Simchoni, hw hmac(sha1) in mv_cesa case requires sw
sha1 driver.
Initial vectors are calculated per key by sw.
So it is no longer hw HMAC implementation.
I just want to understand what make it defferent from mv_cesa if in
omap-sham case
hash(opad ∥ hash(ipad ∥ message))
I would also:
1. calc hash(opad) using sw, export
2. hash(ipad ∥ message) using hw
3. then import and finup hash from step 1 with results of step 2 (using sw)
What makes it different from mc_cesa case?
Cheers,
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
