From: "Loc Ho" <locnho@sbcglobal.net>
To: "'Herbert Xu'" <herbert@gondor.apana.org.au>
Cc: <linux-crypto@vger.kernel.org>
Subject: RE: New Crypto Hardware
Date: Thu, 17 Jan 2008 10:37:20 -0800 [thread overview]
Message-ID: <001c01c85937$ff3313f0$5c05420a@amcc.com> (raw)
In-Reply-To: <20080117112314.GC9020@gondor.apana.org.au>
Hi,
The current hash_alg struct is:
struct hash_alg {
int (*init)(struct hash_desc *desc);
int (*update)(struct hash_desc *desc, struct scatterlist *sg,
unsigned int nbytes);
int (*final)(struct hash_desc *desc, u8 *out);
int (*digest)(struct hash_desc *desc, struct scatterlist *sg,
unsigned int nbytes, u8 *out);
int (*setkey)(struct crypto_hash *tfm, const u8 *key,
unsigned int keylen);
unsigned int digestsize;
};
It looks like update and final functions are used for continuous hashing.
And digest function is used for single hashing. I was thing changing to this
for async:
struct ahash_alg {
int (*init)(struct ahash_request *req);
int (*digest)(struct ahash_request *req);
int (*setkey)(struct crypto_ahash *tfm, const u8 *key,
unsigned int keylen);
unsigned int digestsize;
};
But it seems like there is still a need to support continuation hashing as
well as just single hash.
Questions:
1. Is my assume about update/final and digest function correct?
2. What is the difference between digest and hash type besides one operation
on transformation structure (tfm) and the other on descriptor (desc)?
3. Currently, cryptodev-2.6 git doesn't work under PPC4xx development board
but Denx linux latest works. Have anyone tested on PPC4xx board?
The context between update and final function will be moved into the request
just like ablkcipher.
-Loc
-----Original Message-----
From: Herbert Xu [mailto:herbert@gondor.apana.org.au]
Sent: Thursday, January 17, 2008 3:23 AM
To: Loc Ho
Cc: linux-crypto@vger.kernel.org
Subject: Re: New Crypto Hardware
On Wed, Jan 16, 2008 at 10:19:04AM -0800, Loc Ho wrote:
> Hi,
>
> For hashing, there are HMAC key if HMAC and digest size. As digest
> size is part of the algorithm, there is only HMAC key. Are you
> referring to moving the HMAC key from transformation into the request
> structure? As I am modeled after ablkcipher_request structure, there
> will be a context point 'void *__ctx[] CRYPTO_MINALIGN_ATTR;' for the
request operation.
No I meant the context that has to be stored between calls to
crypto_hash_update and crypto_hash_final.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page:
http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
next prev parent reply other threads:[~2008-01-17 18:44 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <0CA0A16855646F4FA96D25A158E299D603B5A5EB@SDCEXCHANGE01.ad.amcc.com>
2007-11-12 18:19 ` New Crypto Hardware Loc Ho
2007-11-13 1:41 ` Herbert Xu
[not found] ` <0CA0A16855646F4FA96D25A158E299D603EB866F@SDCEXCHANGE01.ad.amcc.com>
2007-12-25 7:32 ` Herbert Xu
[not found] ` <0CA0A16855646F4FA96D25A158E299D603FCC15D@SDCEXCHANGE01.ad.amcc.com>
2008-01-17 11:23 ` Herbert Xu
2008-01-17 18:37 ` Loc Ho [this message]
2008-01-17 20:27 ` Sebastian Siewior
[not found] ` <0CA0A16855646F4FA96D25A158E299D603FCC4D7@SDCEXCHANGE01.ad.amcc.com>
2008-01-18 23:07 ` Sebastian Siewior
2008-01-22 1:29 ` Loc Ho
2008-01-22 23:18 ` Sebastian Siewior
2008-01-23 2:17 ` Loc Ho
2008-01-24 21:07 ` RFC: Async Hash Support Loc Ho
2008-01-24 23:09 ` Sebastian Siewior
2008-01-25 2:45 ` [PATCH 1/1] CryptoAPI: Add " Loc Ho
2008-03-13 11:42 ` Herbert Xu
2008-03-13 17:39 ` Loc Ho
2008-04-10 2:03 ` Loc Ho
2008-04-10 2:29 ` Herbert Xu
2008-04-22 11:16 ` Herbert Xu
2008-04-22 17:23 ` Loc Ho
2008-05-07 13:00 ` Herbert Xu
2008-05-07 13:09 ` Patrick McHardy
2008-05-07 13:15 ` Herbert Xu
2008-05-13 20:27 ` [PATCH 1/3] [CRYPTO] hash: " Loc Ho
2008-05-14 12:40 ` Herbert Xu
2008-05-14 12:44 ` Herbert Xu
2008-05-14 13:26 ` Herbert Xu
2008-05-13 20:29 ` [PATCH 2/3] [CRYPTO] cryptd: " Loc Ho
2008-05-13 20:30 ` [PATCH 3/3] [CRYPTO] tcrypt: " Loc Ho
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='001c01c85937$ff3313f0$5c05420a@amcc.com' \
--to=locnho@sbcglobal.net \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.