Re: Fwd: crypto accelerator driver problems

2011-01-25 Thread Hamid Nassiby
On Wed, Jan 26, 2011 at 10:39 AM, Herbert Xu wrote: > On Wed, Jan 26, 2011 at 10:26:33AM +0330, Hamid Nassiby wrote: >> >> As you know, I posted my problem again to crypto list and no one answered. >> Now I >> emphasize one aspect of the problem as a concept related to IPSec protocol, >> free >> o

Re: hash finup() issue

2011-01-25 Thread Dmitry Kasatkin
I am not talking about user space API at all. I talk about kernel crypto API and kernel clients. Please understand the following: when update() is called driver does not know if it is last update or not... That is essential. If client code would always use update/finup then it is fine.. But origi

Re: Fwd: crypto accelerator driver problems

2011-01-25 Thread Hamid Nassiby
On Sat, Jan 8, 2011 at 11:09 AM, Hamid Nassiby wrote: > > On Fri, Dec 31, 2010 at 12:49 AM, Herbert Xu > wrote: > > > > Hamid Nassiby wrote: > > > Hi, > > > > > > As some good news and additional information, with the following patch > > > I no more get > > > "UDP bad cheksum" error as I mention

Re: Fwd: crypto accelerator driver problems

2011-01-25 Thread Herbert Xu
On Wed, Jan 26, 2011 at 10:26:33AM +0330, Hamid Nassiby wrote: > > As you know, I posted my problem again to crypto list and no one answered. > Now I > emphasize one aspect of the problem as a concept related to IPSec protocol, > free > of my problem's nature, and I hope to get some guidelines at t

Re: hash finup() issue

2011-01-25 Thread Herbert Xu
On Tue, Jan 25, 2011 at 03:44:47PM +0200, Dmitry Kasatkin wrote: > > What we have done in our system is introduced a new flag which is set to > request. > flags |= CRYPTO_TFM_REQ_USE_FINUP; > ahash_request_set_callback(req, flags, tcrypt_complete, &tresult); We don't need a flag for this, we just

[PATCH] crypto: mark xts(aes) as fips_allowed

2011-01-25 Thread Jarod Wilson
We (Red Hat) are intending to include dm-crypt functionality, using xts(aes) for disk encryption, as part of an upcoming FIPS-140-2 certification effort, and xts(aes) *is* on the list of possible mode/cipher combinations that can be certified. To make that possible, we need to mark xts(aes) as fips

Re: [PATCH] crypt: ablkcipher: remove redundant NULL check

2011-01-25 Thread David Miller
From: Davidlohr Bueso Date: Tue, 25 Jan 2011 13:27:45 -0300 > From: Davidlohr Bueso > > Signed-off-by: Davidlohr Bueso Acked-by: David S. Miller -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo inf

[PATCH] crypt: ablkcipher: remove redundant NULL check

2011-01-25 Thread Davidlohr Bueso
From: Davidlohr Bueso Signed-off-by: Davidlohr Bueso --- crypto/ablkcipher.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/crypto/ablkcipher.c b/crypto/ablkcipher.c index a854df2..fdc67d3 100644 --- a/crypto/ablkcipher.c +++ b/crypto/ablkcipher.c @@ -141,8 +141,7 @@

hash finup() issue

2011-01-25 Thread Dmitry Kasatkin
Hello, It is often very important to know for implementation or optimization if we get more data to process or not. New user space crypto API uses socket MSG_MORE flag to know if more data is coming. >From kernel crypto API it is also may be very important to know if more data is coming. OMAP S