>> you're losing free performance.
> I am really not comfortable having garbage in the keytable.
Kim, do you have any other solution in mind?
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at h
>>> why do you need to clear the entire key table if it will be
>>> overwritten anyway?
>> If you set a > 128-bit key and then set a 128-bit key, the remaining
>> bits still remain in the key table. Similarly, if we use updated IV in
>> one operation and want to use the initial IV for the next, th
On Wed, 16 Nov 2011 14:35:00 +0530
Varun Wadekar wrote:
>
> > it's not - it saves writes.
>
> Are you ok with this solution? Either way I wan to start with a clear
> key table before programming the hardware.
the hardware doesn't care.
> > why do you need to clear the entire key table if it w
> it's not - it saves writes.
Are you ok with this solution? Either way I wan to start with a clear
key table before programming the hardware.
> why do you need to clear the entire key table if it will be
> overwritten anyway?
If you set a > 128-bit key and then set a 128-bit key, the remaining
On Wed, 16 Nov 2011 12:44:50 +0530
Varun Wadekar wrote:
> > That doesn't make the duplicate memset/copy cease to be redundant.
> >
> > Why not copy the key to where it goes, then memset the rest of the data;
> > wouldn't that be as simple as:
> >
> > memcpy(dd->ivkey_base, ctx->key, ctx->keylen);
> That doesn't make the duplicate memset/copy cease to be redundant.
>
> Why not copy the key to where it goes, then memset the rest of the data;
> wouldn't that be as simple as:
>
> memcpy(dd->ivkey_base, ctx->key, ctx->keylen);
> memset(dd->ivkey_base + ctx->keylen, 0, AES_HW_KEY_TABLE_LENGTH_BY
Varun Wadekar wrote at Monday, November 14, 2011 9:11 PM:
> >> Why?
> > To avoid redundant work; there's little point memset()ing a region that's
> > going to be copied over the top of immediately afterwards.
> >
>
> The length used for memset is different from the length being copied
> over. I am
>> Why?
> To avoid redundant work; there's little point memset()ing a region that's
> going to be copied over the top of immediately afterwards.
>
The length used for memset is different from the length being copied
over. I am initially memsetting the entire key struct (which contains
the key + o
On Mon, 14 Nov 2011 09:26:16 -0800
Stephen Warren wrote:
> Varun Wadekar wrote at Saturday, November 12, 2011 3:23 AM:
> > >> +/* assign new context to device */
> > >> +ctx->dd = dd;
> > >> +dd->ctx = ctx;
> > >> +
> > >> +if (ctx->flags & FLAGS_NEW_KEY) {
> > >>
Varun Wadekar wrote at Saturday, November 12, 2011 3:23 AM:
> >> + /* assign new context to device */
> >> + ctx->dd = dd;
> >> + dd->ctx = ctx;
> >> +
> >> + if (ctx->flags & FLAGS_NEW_KEY) {
> >> + /* copy the key */
> >> + memset(dd->ivkey_base, 0, AES_HW_KEY_TABLE_LENGTH_B
>> +/* assign new context to device */
>> +ctx->dd = dd;
>> +dd->ctx = ctx;
>> +
>> +if (ctx->flags & FLAGS_NEW_KEY) {
>> +/* copy the key */
>> +memset(dd->ivkey_base, 0, AES_HW_KEY_TABLE_LENGTH_BYTES);
>> +memcpy(dd->ivkey_base, ctx->key, ctx->
On Sat, 5 Nov 2011 16:12:14 +0530
wrote:
> +config CRYPTO_DEV_TEGRA_AES
> + tristate "Support for TEGRA AES hw engine"
> + depends on ARCH_TEGRA
> + select CRYPTO_AES
> + help
> + TEGRA processors have AES module accelerator. Select this if you
> + want to use the TEGR
From: Varun Wadekar
driver supports ecb/cbc/ofb/ansi_x9.31rng modes and
128, 192 and 256-bit key sizes.
Signed-off-by: Varun Wadekar
---
v1: fixed comments from Stephen Warren, Kim Phillips and Henning Heinold
drivers/crypto/Kconfig |8 +
drivers/crypto/Makefile|1 +
drivers/c
13 matches
Mail list logo
