RE: New Crypto Hardware

["Loc Ho" <locnho@sbcglobal.net>]

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@vger.kernel.org
[mailto:linux-crypto-owner@vger.kernel.org] On Behalf Of Sebastian Siewior
Sent: Tuesday, January 22, 2008 3:18 PM
To: Loc Ho
Cc: 'Sebastian Siewior'; Herbert Xu; linux-crypto@vger.kernel.org
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