On 23/03/10 13:32, ext Herbert Xu wrote:
On Wed, Mar 17, 2010 at 03:12:49PM +0200, Dmitry Kasatkin wrote:
Earlier kernel contained omap sha1 and md5 driver, which was not maintained,
was not ported to new crypto APIs and removed from the source tree.
This driver implements async and sync crypto API.
It still contains pr_debug() for debugging purpose.
Will be remove for integration.
Dmitry Kasatkin (2):
sec: omap sha1& md5 driver
sec: Makefile/Kconfig update for omap sha1 md5 driver
It looks good to me as far as the Crypto API is concerned.
My only question is what's your plan with respect to HMAC? If
you're going to do it in hardware then it's fine as it is.
Otherwise you need to implement export/import and we also need
to add ahash support to hmac.c.
Thanks,
Hello.
Interesting case with hmac.
return crypto_shash_init(&desc.shash) ?:
crypto_shash_update(&desc.shash, ipad, bs) ?:
crypto_shash_export(&desc.shash, ipad) ?:
crypto_shash_init(&desc.shash) ?:
crypto_shash_update(&desc.shash, opad, bs) ?:
crypto_shash_export(&desc.shash, opad);
Basically it does not call final.
Then call init again.
hw has certain limitation that it requires to process last block with
some bit set.
WHen update is called there is no possibility to know that no more
update() will come.
So possible last block is stored and then hashed out from the final.
I see that above code will not work with the driver.
I wonder how intermediate export/import could be done with omap hw.
But if it's not possible, then why not to have hmac(sha1) as just sw.
Anyway hmac should not process as huge amount of data as hash itself.
What is your opinion/advice?
Thank you
- Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
