http://eprint.iacr.org/2010/594 (Access Based Cache Attacks on AES) a problem?

is http://eprint.iacr.org/2010/594 a problem and if so what has to be done? rgds -- 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 http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1.5 5/5] keys: add new key-type encrypted

Mimi Zohar wrote: > +#define KEY_TRUSTED_PREFIX "trusted:" > +#define KEY_TRUSTED_PREFIX_LEN (sizeof (KEY_TRUSTED_PREFIX) - 1) > +#define KEY_USER_PREFIX "user:" > +#define KEY_USER_PREFIX_LEN (sizeof (KEY_USER_PREFIX) - 1) I'd recommend using static const char arrays. > +static int datablob_pa

[PATCH] Make sure sk_security is initialized on accept()ed sockets

Signed-off-by: Miloslav Trmač --- crypto/af_alg.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/crypto/af_alg.c b/crypto/af_alg.c index cabed0e..bd9e53c 100644 --- a/crypto/af_alg.c +++ b/crypto/af_alg.c @@ -242,6 +242,7 @@ int af_alg_accept(struct sock *sk, struct soc

[PATCH] Add missing lockdep class names

Signed-off-by: Miloslav Trmač --- net/core/sock.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/net/core/sock.c b/net/core/sock.c index 3eed542..634d5bc 100644 --- a/net/core/sock.c +++ b/net/core/sock.c @@ -157,7 +157,7 @@ static const char *const af_family_key_s

RE: [PATCH 2/3] RFC4106 AES-GCM Driver Using Intel New Instructions

Hi Herbert and Andrew, Sorry for delay. We have the patch almost ready. We just want to do some more testing before we send it. We should be ready to send it out next week. Next Friday (10 Dec) will be worst case date. Thanks, Tadeusz -Original Message- From: Herbert Xu [mailto:herb...

Re: [PATCH 3/5] xfrm: Traffic Flow Confidentiality for IPv4 ESP

On Fri, Dec 03, 2010 at 09:32:55AM +0100, Martin Willi wrote: > > > What is the basis of this random length padding? > > Let assume a peer does not support ESPv3 padding, but we have to pad a > small packet with more than 255 bytes. We can't, the ESP padding length > field is limited to 255. > We

Re: [PATCH 3/5] xfrm: Traffic Flow Confidentiality for IPv4 ESP

> What is the basis of this random length padding? Let assume a peer does not support ESPv3 padding, but we have to pad a small packet with more than 255 bytes. We can't, the ESP padding length field is limited to 255. We could add 255 fixed bytes, but an eavesdropper could just subtract the 255