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 mar...@strongswan.org
---
Signed-off-by: Martin Willi mar...@strongswan.org
---
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
---
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 mar...@strongswan.org
---
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 mar...@strongswan.org
---
crypto/testmgr.c | 15 +
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.
Signed-off-by: Martin Willi mar...@strongswan.org
---
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
Signed-off-by: Martin Willi mar...@strongswan.org
---
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
---
Signed-off-by: Martin Willi mar...@strongswan.org
---
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
---
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
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.
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 some
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
This patch converts the low-level __gcm-aes-aesni algorithm to
the new AEAD interface.
Signed-off-by: Herbert Xu herb...@gondor.apana.org.au
diff --git a/arch/x86/crypto/aesni-intel_glue.c
b/arch/x86/crypto/aesni-intel_glue.c
index 5660a18..8ab9630 100644
---
On Mon, Jun 01, 2015 at 11:12:45AM +0200, Stephan Mueller wrote:
[ 599.243227] [812b7b85] old_crypt+0xc5/0xe0
[ 599.243229] [812b7bdd] old_encrypt+0x1d/0x20
[ 599.243233] [a02c1183] kccavs_aead_encdec+0x53/0x80 [kcapi_cavs]
[ 599.243235] [a02c1cca]
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
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,
--
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
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 FYI:
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:17:45 schrieb Herbert Xu:
Hi Herbert,
On Mon, Jun 01, 2015 at 11:12:45AM +0200, Stephan Mueller wrote:
[ 599.243227] [812b7b85] old_crypt+0xc5/0xe0
[ 599.243229] [812b7bdd] old_encrypt+0x1d/0x20
[ 599.243233] [a02c1183]
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
kernels
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
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:
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]
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 totally
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: send
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
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
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 any
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 also
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 ?
What are
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?
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 the aad
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
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 generation
35 matches
Mail list logo
