Hi, I had an working version of async hashing (for HMAC mode). Have not tested with software wrapper yet like async blkciper implementation but with an async hash sample driver wrapped directly over hmac(md5). Currently, async block ciper calls crypto_alloc_ablkciper for various mode. I would like to do the same. If we do need two version, I would still like to keep the interface called by tcrypt.c to be identical, except calling 'setkey' would be either no operation or return error. Until this is confirmed, will start testing the async software wrapper over synchronous interface. -Loc -----Original Message----- From: linux-crypto-owner@xxxxxxxxxxxxxxx [mailto:linux-crypto-owner@xxxxxxxxxxxxxxx] On Behalf Of Sebastian Siewior Sent: Tuesday, January 22, 2008 3:18 PM To: Loc Ho Cc: 'Sebastian Siewior'; Herbert Xu; linux-crypto@xxxxxxxxxxxxxxx Subject: Re: New Crypto Hardware * Loc Ho | 2008-01-21 17:29:13 [-0800]: >If that is the case, then in order to fully support async hashing, I >would need an async version of HASH interface and an async version of >digest. Am I correct? Yes. In case you support hmac+sha1 in HW and you don't do sha1 (as digest) at all you could skip that part. >Do you think it will be inconsistent if it is assumed that if the >functional setkey is not called, then it is digest. If it is called, >then it is hash. I would prefer to seperate them. However, this is one of those things where Herbert has the last word :) >-Loc Sebastian - 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
