Hi, All:
When i use the cryptsetup command to set the aes-xts-plain
encryption, the system will entry the crypt() routine which defined in
the xts.c file. I find the routine will call two important routines:
tw and fn. I think the fn will point to the aes_encrypt/decrypt
routine. But i want to kn
- Original message -
> Hi:
>
> OK so you did answer my question :)
>
> Dmitry Kasatkin wrote:
> >
> > Interesting case with hmac.
> >
> > return crypto_shash_init(&desc.shash) ?:
> > crypto_shash_update(&desc.shash, ipad, bs) ?:
> > crypto_shash_export(&desc.shash, ipad) ?:
> > crypto_
Add sha1 and hmac(sha1) async hash drivers
Signed-off-by: Uri Simchoni
---
diff -upr linux-2.6.32.8_p9/drivers/crypto/mv_cesa.c
linux-2.6.32.8_p10/drivers/crypto/mv_cesa.c
--- linux-2.6.32.8_p9/drivers/crypto/mv_cesa.c 2010-03-16 12:33:45.504199755
+0200
+++ linux-2.6.32.8_p10/drivers/crypto/m
Support processing of data from previous requests (as in hashing
update/final requests).
Signed-off-by: Uri Simchoni
---
diff -upr linux-2.6.32.8_p8/drivers/crypto/mv_cesa.c
linux-2.6.32.8_p9/drivers/crypto/mv_cesa.c
--- linux-2.6.32.8_p8/drivers/crypto/mv_cesa.c 2010-03-16 12:25:34.815950170
Make the copy-back of data optional (not done in hashing requests)
Signed-off-by: Uri Simchoni
---
diff -upr linux-2.6.32.8_p7/drivers/crypto/mv_cesa.c
linux-2.6.32.8_p8/drivers/crypto/mv_cesa.c
--- linux-2.6.32.8_p7/drivers/crypto/mv_cesa.c 2010-03-16 12:07:31.147897717
+0200
+++ linux-2.6.32
Execute some code via function pointers rathr than direct calls
(to allow customization in the hashing request)
Signed-off-by: Uri Simchoni
---
diff -upr linux-2.6.32.8_p6/drivers/crypto/mv_cesa.c
linux-2.6.32.8_p7/drivers/crypto/mv_cesa.c
--- linux-2.6.32.8_p6/drivers/crypto/mv_cesa.c 2010-03-
Rename a variable to a more suitable name
Signed-off-by: Uri Simchoni
---
diff -upr linux-2.6.32.8_p5/drivers/crypto/mv_cesa.c
linux-2.6.32.8_p6/drivers/crypto/mv_cesa.c
--- linux-2.6.32.8_p5/drivers/crypto/mv_cesa.c 2010-03-16 11:43:37.443646086
+0200
+++ linux-2.6.32.8_p6/drivers/crypto/mv_c
Enqueue generic async requests rather than ablkcipher requests
in the driver's queue
Signed-off-by: Uri Simchoni
---
diff -upr linux-2.6.32.8_p4/drivers/crypto/mv_cesa.c
linux-2.6.32.8_p5/drivers/crypto/mv_cesa.c
--- linux-2.6.32.8_p4/drivers/crypto/mv_cesa.c 2010-03-16 10:54:07.322816221
+020
Fix for situations where the source scatterlist spans more data than the
request nbytes
Signed-off-by: Uri Simchoni
---
diff -upr linux-2.6.32.8_p3/drivers/crypto/mv_cesa.c
linux-2.6.32.8_p4/drivers/crypto/mv_cesa.c
--- linux-2.6.32.8_p3/drivers/crypto/mv_cesa.c 2010-03-16 09:06:10.183753278
+
Bugfix for situations where the destination scatterlist has a different
buffer structure than the source scatterlist (e.g. source has one 2K
buffer and dest has 2 1K buffers)
Signed-off-by: Uri Simchoni
---
diff -upr linux-2.6.32.8_p2/drivers/crypto/mv_cesa.c
linux-2.6.32.8_p3/drivers/crypto/mv_
Remove compiler warning
Signed-off-by: Uri Simchoni
---
diff -upr linux-2.6.32.8_p1/drivers/crypto/mv_cesa.c
linux-2.6.32.8_p2/drivers/crypto/mv_cesa.c
--- linux-2.6.32.8_p1/drivers/crypto/mv_cesa.c 2010-03-16 08:59:12.074583163
+0200
+++ linux-2.6.32.8_p2/drivers/crypto/mv_cesa.c 2010-03-16
Invoke the user callback from a softirq context
Signed-off-by: Uri Simchoni
---
diff -upr linux-2.6.32.8_orig/drivers/crypto/mv_cesa.c
linux-2.6.32.8_p1/drivers/crypto/mv_cesa.c
--- linux-2.6.32.8_orig/drivers/crypto/mv_cesa.c2010-02-09
14:57:19.0 +0200
+++ linux-2.6.32.8_p1/dri
This is a resubmission of a patchset I set a while ago, and that was corrupted
by my email client.
The following patchset adds async hashing (sha1 and hmac-sha1) to the mv_cesa
crypto driver. This driver utilizes the Marvell CESA crypto accelerator that
exists in some Marvell CPU's (Orion and K
Hi:
OK so you did answer my question :)
Dmitry Kasatkin wrote:
>
> 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.
On Tue, Mar 23, 2010 at 07:32:39PM +0800, Herbert Xu wrote:
>
> 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.
Dmitry, d
On Thu, 8 Apr 2010, Dmitry Kasatkin wrote:
> Hi,
>
> BTW..
>
> How will it work if those resource structures anyway conditionally compiled
> for OMAP2 or 3 or 4?
> only one structure will be compiled at once.
Hi Dmitry,
it is possible to build a kernel that will run on both OMAP2 and OMAP3
(f
Hi,
BTW..
How will it work if those resource structures anyway conditionally
compiled for OMAP2 or 3 or 4?
only one structure will be compiled at once.
- Dmitry
On 30/03/10 12:41, ext Paul Walmsley wrote:
Hi Dmitry,
a few comments:
On Thu, 25 Mar 2010, Dmitry Kasatkin wrote:
- regi
* Herbert Xu | 2010-04-07 17:29:07 [+0800]:
>Sebastian, how about precomputing the IV and provide them directly
>as a hex array?
>
>To test arc4_setup_iv itself, you can add an alg_test_arc4 function
>(like alg_test_crc32) that tests IV generation specifically.
>
>Alternatively, just add an alg_te
18 matches
Mail list logo
