Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

[Dmitry Kasatkin <dmitry.kasatkin@nokia.com>]

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html