From: Alexander Duyck
Date: Fri, 29 May 2015 11:28:26 -0700
> From: Steffen Klassert
>
> We currently rely on the PMTU discovery of xfrm.
> However if a packet is localy sent, the PMTU mechanism
> of xfrm tries to to local socket notification what
> might not work for applications like ping tha
On 05/31/2015 10:48 PM, Herbert Xu wrote:
> On Thu, May 28, 2015 at 09:54:41AM -0700, Tadeusz Struk wrote:
>>
>> If we do this that way then we will be able to pass only one input and one
>> output parameter. There are cases when we will need more that this.
>> For instance for ECDSA signature gene
When performing a dma_map_sg() call, the number of sg entries to map is
required. Using sg_nents to retrieve the number of sg entries will
return the total number of entries in the sg list up to the entry marked
as the end. If there happen to be unused entries in the list, these will
still be count
Scatter gather lists can be created with more available entries than are
actually used (e.g. using sg_init_table() to reserve a specific number
of sg entries, but in actuality using something less than that based on
the data length). The caller sometimes fails to mark the last entry
with sg_mark_e
This series introduces and makes use of a new scatterlist function named
sg_nents_for_len. The purpose of this function is determine the number
of scatterlist entries required to satisify a specified length. The
resulting count can be used as input to the dma_map_sg function to map
only the entries
Am Montag, 1. Juni 2015, 16:35:26 schrieb Johannes Berg:
Hi Johannes,
>
>IOW, I think something like this would make sense:
>
That looks definitely cleaner :-)
Though, my main concern was just to ensure that the aad length value is not
zero.
Ciao
Stephan
--
To unsubscribe from this list: sen
On Mon, Jun 01, 2015 at 03:24:03PM +0200, Marek Vasut wrote:
> On Friday, May 29, 2015 at 03:30:18 PM, Herbert Xu wrote:
> > On Fri, May 29, 2015 at 03:02:59PM +0200, Marek Vasut wrote:
> > > This does look somewhat hacky to me. Wouldn't it make more sense to
> > > add a CRYPTO_TFM_REQ flag ?
> >
On Mon, 2015-06-01 at 16:05 +0200, Johannes Berg wrote:
> Ok - here the length is kinda passed a part of the AAD buffer, but this
> is really just some arcane code that should be fixed to use a proper
> struct. The value there, even though it is __be16 and looks like it came
> from the data, is ac
On Mon, 2015-06-01 at 15:49 +0200, Stephan Mueller wrote:
> >The contents, now, that's a more interesting question. I believe it can
> >never be all zeroes, since association request frames are not
> >encrypted/protected and thus at least one byte in here must be non-zero.
> >The MAC addresses are
Am Montag, 1. Juni 2015, 15:42:41 schrieb Johannes Berg:
Hi Johannes,
>On Mon, 2015-06-01 at 15:21 +0200, Stephan Mueller wrote:
>> Just a short question on ieee80211_aes_ccm_encrypt,
>> ieee80211_aes_ccm_decrypt, ieee80211_aes_gcm_encrypt,
>> ieee80211_aes_gcm_decrypt, ieee80211_aes_gmac: can th
On Mon, 2015-06-01 at 15:21 +0200, Stephan Mueller wrote:
> Just a short question on ieee80211_aes_ccm_encrypt,
> ieee80211_aes_ccm_decrypt,
> ieee80211_aes_gcm_encrypt, ieee80211_aes_gcm_decrypt, ieee80211_aes_gmac: can
> the aad parameter of these functions be zero?
What do you mean by "zero
On Friday, May 29, 2015 at 03:30:18 PM, Herbert Xu wrote:
> On Fri, May 29, 2015 at 03:02:59PM +0200, Marek Vasut wrote:
> > This does look somewhat hacky to me. Wouldn't it make more sense to
> > add a CRYPTO_TFM_REQ flag ?
>
> What are you going to do when you have more than one hard-coded
> key
Am Donnerstag, 21. Mai 2015, 13:20:49 schrieb Johannes Berg:
Hi Johannes,
> On Thu, 2015-05-21 at 18:44 +0800, Herbert Xu wrote:
> > This patch makes use of the new AEAD interface which uses a single
> > SG list instead of separate lists for the AD and plain text.
>
> Looks fine - want me to run
ChaCha20 is a high speed 256-bit key size stream cipher algorithm designed by
Daniel J. Bernstein. It is further specified in RFC7539 for use in IETF
protocols as a building block for the ChaCha20-Poly1305 AEAD.
This is a portable C implementation without any architecture specific
optimizations. I
We explicitly set the Initial block Counter by prepending it to the nonce in
Little Endian. The same test vector is used for both encryption and decryption,
ChaCha20 is a cipher XORing a keystream.
Signed-off-by: Martin Willi
---
crypto/testmgr.c | 15 +
crypto/testmgr.h | 177 +
Signed-off-by: Martin Willi
---
net/xfrm/xfrm_algo.c | 12
1 file changed, 12 insertions(+)
diff --git a/net/xfrm/xfrm_algo.c b/net/xfrm/xfrm_algo.c
index 67266b7..42f7c76 100644
--- a/net/xfrm/xfrm_algo.c
+++ b/net/xfrm/xfrm_algo.c
@@ -159,6 +159,18 @@ static struct xfrm_algo_desc
Signed-off-by: Martin Willi
---
crypto/testmgr.c | 9 ++
crypto/testmgr.h | 259 +++
2 files changed, 268 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index abd09c2..faf93a6 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr
Signed-off-by: Martin Willi
---
crypto/testmgr.c | 15 +
crypto/testmgr.h | 179 +++
2 files changed, 194 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 915a9ef..ccd19cf 100644
--- a/crypto/testmgr.c
+++ b/crypto/test
draft-ietf-ipsecme-chacha20-poly1305 defines the use of ChaCha20/Poly1305 in
ESP. It uses additional four byte key material as a salt, which is then used
with an 8 byte IV to form the ChaCha20 nonce as defined in the RFC7539.
Signed-off-by: Martin Willi
---
crypto/chacha20poly1305.c | 26 +++
Signed-off-by: Martin Willi
---
crypto/testmgr.c | 15
crypto/testmgr.h | 269 +++
2 files changed, 284 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index faf93a6..915a9ef 100644
--- a/crypto/testmgr.c
+++ b/crypto/testm
This AEAD uses a chacha20 ablkcipher and a poly1305 ahash to construct the
ChaCha20-Poly1305 AEAD as defined in RFC7539. It supports both synchronous and
asynchronous operations, even if we currently have no async chacha20 or poly1305
drivers.
Signed-off-by: Martin Willi
---
crypto/Kconfig
Poly1305 is a fast message authenticator designed by Daniel J. Bernstein.
It is further defined in RFC7539 as a building block for the ChaCha20-Poly1305
AEAD for use in IETF protocols.
This is a portable C implementation of the algorithm without architecture
specific optimizations, based on public
This is a first version of a patch series implementing the ChaCha20-Poly1305
AEAD construction defined in RFC7539. It is based on the current cryptodev tree.
The first two patches implement the ChaCha20 cipher, the second two the Poly1305
authenticator, both in portable C for all architectures. Pa
Am Montag, 1. Juni 2015, 17:52:45 schrieb Herbert Xu:
Hi Herbert,
> On Mon, Jun 01, 2015 at 11:44:22AM +0200, Stephan Mueller wrote:
> > That code crashes with the following stacktrace:
> >
> > [ 2000.433502] BUG: unable to handle kernel NULL pointer dereference at
> > (null)
>
> This crash is
On Mon, Jun 01, 2015 at 11:44:22AM +0200, Stephan Mueller wrote:
>
> That code crashes with the following stacktrace:
>
> [ 2000.433502] BUG: unable to handle kernel NULL pointer dereference at
>
> (null)
This crash is totally different from the previous crash you sent.
This one is ex
Am Montag, 1. Juni 2015, 17:15:51 schrieb Herbert Xu:
Hi Herbert,
> On Mon, Jun 01, 2015 at 11:12:45AM +0200, Stephan Mueller wrote:
> > another crash with all of the latest patches and using gcm_base(ctr(aes-
> > asm),ghash-generic) using the standard AEAD interface and performing
> > encryption
Am Montag, 1. Juni 2015, 17:09:51 schrieb Herbert Xu:
Hi Herbert,
> On Mon, Jun 01, 2015 at 11:04:39AM +0200, Stephan Mueller wrote:
> > Just FYI: when testing rfc4106(gcm(aes-aesni)) with the old givcipher API,
> > I got a crash in my code invoking the cipher which used to work in older
> > kern
On Mon, Jun 01, 2015 at 11:12:45AM +0200, Stephan Mueller wrote:
>
> another crash with all of the latest patches and using gcm_base(ctr(aes-
> asm),ghash-generic) using the standard AEAD interface and performing
> encryption.
Can you send me the patch of libkcapi against
b1e885f64f7b7f6cbc34faa
On Mon, Jun 01, 2015 at 11:27:42AM +0200, Stephan Mueller wrote:
>
> Just a question: is the new API without an IV generator to be used
> differently
> when using the new API with an IV generator?
Sorry I'm totally confused by your question :)
Please give an example using actual code.
Thanks,
Am Montag, 1. Juni 2015, 17:17:45 schrieb Herbert Xu:
Hi Herbert,
> On Mon, Jun 01, 2015 at 11:12:45AM +0200, Stephan Mueller wrote:
> > [ 599.243227] [] old_crypt+0xc5/0xe0
> > [ 599.243229] [] old_encrypt+0x1d/0x20
> > [ 599.243233] [] kccavs_aead_encdec+0x53/0x80
> > [kcapi_cavs] [ 599.
On Mon, Jun 01, 2015 at 11:12:45AM +0200, Stephan Mueller wrote:
>
> [ 599.243227] [] old_crypt+0xc5/0xe0
> [ 599.243229] [] old_encrypt+0x1d/0x20
> [ 599.243233] [] kccavs_aead_encdec+0x53/0x80 [kcapi_cavs]
> [ 599.243235] [] kccavs_test_aead+0x23a/0x3e0 [kcapi_cavs]
> [ 599.243238] [] k
Hi Herbert,
another crash with all of the latest patches and using gcm_base(ctr(aes-
asm),ghash-generic) using the standard AEAD interface and performing
encryption.
[ 599.243110] [ cut here ]
[ 599.243113] kernel BUG at crypto/scatterwalk.c:37!
[ 599.243115] invalid
On Mon, Jun 01, 2015 at 11:04:39AM +0200, Stephan Mueller wrote:
>
> Just FYI: when testing rfc4106(gcm(aes-aesni)) with the old givcipher API, I
> got a crash in my code invoking the cipher which used to work in older
> kernels
> and which works with the C implementations. So, there must be som
Am Montag, 1. Juni 2015, 15:53:06 schrieb Herbert Xu:
Hi Herbert,
>On Mon, Jun 01, 2015 at 03:50:22PM +0800, Herbert Xu wrote:
>> This patch converts the low-level __gcm-aes-aesni algorithm to
>> the new AEAD interface.
>
>Oops, I missed two more spots.
That patch fixes the crash. Thanks
Just F
On architectures where flush_dcache_page is not needed, we will
end up generating all the code up to the PageSlab call. This is
because PageSlab operates on a volatile pointer and thus cannot
be optimised away.
This patch works around this by checking whether flush_dcache_page
is needed befor
On Mon, Jun 01, 2015 at 03:50:22PM +0800, Herbert Xu wrote:
> This patch converts the low-level __gcm-aes-aesni algorithm to
> the new AEAD interface.
Oops, I missed two more spots.
---8<---
This patch converts the low-level __gcm-aes-aesni algorithm to
the new AEAD interface.
Signed-off-by: Her
This patch converts the low-level __gcm-aes-aesni algorithm to
the new AEAD interface.
Signed-off-by: Herbert Xu
diff --git a/arch/x86/crypto/aesni-intel_glue.c
b/arch/x86/crypto/aesni-intel_glue.c
index 5660a18..8ab9630 100644
--- a/arch/x86/crypto/aesni-intel_glue.c
+++ b/arch/x86/crypto/aesn
On Fri, May 29, 2015 at 11:39:03PM +0200, Stephan Mueller wrote:
>
> Not sure what goes wrong, but when using algif_aead with the new code, I get:
This is a bug in the way it's using scatterwalk. It needs to
advance the walk object by the number of bytes it has processed.
Previously it didn't cra
38 matches
Mail list logo
