Am Donnerstag, 23. April 2015, 16:18:31 schrieb Paul Bolle:
Hi Paul,
On Thu, 2015-04-23 at 16:08 +0200, Stephan Mueller wrote:
Other patches that are in the kernel that I wrote (e.g.
the crypto/drbg.c) have the same license as above, but use
MODULE_LICENSE(GPL) -- Thus I would think that
On 04/23/2015 07:45 AM, Steffen Klassert wrote:
On Thu, Apr 23, 2015 at 11:26:20AM +0800, Herbert Xu wrote:
Hi:
It looks like our IPsec implementations of CCM and GCM are buggy
in that they don't include the IV in the authentication calculation.
Seems like crypto_rfc4106_crypt() passes the
On Thu, 2015-04-23 at 16:08 +0200, Stephan Mueller wrote:
Other patches that are in the kernel that I wrote (e.g.
the crypto/drbg.c) have the same license as above, but use
MODULE_LICENSE(GPL) -- Thus I would think that leaving it as is should be
ok.
Why not submit the trivial patches to
Using sendfile with below small program to get MD5 sums of some files,
it appear that big files (over 64kbytes with 4k pages system) get a
wrong MD5 sum while small files get the correct sum.
This program uses sendfile() to send a file to an AF_ALG socket
for hashing.
/* md5sum2.c */
#include
If NO_DMA=y:
drivers/built-in.o: In function `img_hash_write_via_dma_stop':
img-hash.c:(.text+0xa2b822): undefined reference to `dma_unmap_sg'
drivers/built-in.o: In function `img_hash_xmit_dma':
img-hash.c:(.text+0xa2b8d8): undefined reference to `dma_map_sg'
Bug happens when a data size less than SHA block size is passed.
Since first attempt will be saved in buffer, second round attempt
get into two step to calculate op.inlen and op.outlen. The issue
resides in this step. A wrong value of op.inlen and outlen was being
calculated.
This patch fix this
On Thu, Apr 23, 2015 at 08:45:21AM +0200, LABBE Corentin wrote:
This patch adds documentation for Device-Tree bindings for the Security
System cryptographic accelerator driver.
Signed-off-by: LABBE Corentin clabbe.montj...@gmail.com
---
On 23 April 2015 at 21:27, Bobby Powers bobbypow...@gmail.com wrote:
Hello,
Linus Torvalds torva...@linux-foundation.org wrote:
Ok, this patch seems to fix it for me, so I undid my revert that I
hadn't pushed out yet, and pushed out this instead.
Commit
On Thu, Apr 23, 2015 at 4:10 PM, Ard Biesheuvel
ard.biesheu...@linaro.org wrote:
Hello Bobby,
Would you be able to check whether the following patch fixes the crash?
diff --git a/arch/x86/crypto/sha512-avx2-asm.S
b/arch/x86/crypto/sha512-avx2-asm.S
index a4771dcd1fcf..1f20b35d8573 100644
In NX we need to pass always a 16 multiple size nx_sg_list to
co processor. Trim function handle with this assuring all nx_sg_lists
are 16 multiple size, although data was not being considerated when
crop was done. It was causing an unalignment between size of the list
and data, corrupting csbcpb
On Thu, Apr 23, 2015 at 03:24:59PM +0200, Martin Willi wrote:
Do you have any pointer for me where this is defined? Why is it needed,
given that GCM implicitly authenticates the IV by using it in Y0?
The IV if present must be covered by the ICV. This is required
by RFC4303 (section 2). But
On Thu, Apr 23, 2015 at 03:42:19PM +0200, Stephan Mueller wrote:
Now, shall I kind of re-implement the chainiv ablkcipher wrapper into an IV
handler that just helps my code? That will be a lot of code for a simple
memcmp.
No no no. You don't need to do a template for givencrypt. chainiv
On Fri, Apr 24, 2015 at 02:22:15AM +0200, Stephan Mueller wrote:
I also have the givencrypt and givdecrypt functions. How would I directly
hook
them into the ablkcipher without using a reference for inst-
alg.cra_ablkcipher.geniv?
ablkcipher itself has givencrypt/givdecrypt so you don't
Am Freitag, 24. April 2015, 07:21:05 schrieb Herbert Xu:
Hi Herbert,
On Thu, Apr 23, 2015 at 03:42:19PM +0200, Stephan Mueller wrote:
Now, shall I kind of re-implement the chainiv ablkcipher wrapper into an IV
handler that just helps my code? That will be a lot of code for a simple
memcmp.
On Thu, Apr 23, 2015 at 01:45:34PM +0200, Steffen Klassert wrote:
Adding a second template for the correct implementation is
probaply the only thing that we can do if we don't want to
break backwards compatibility. But maybe we can add a warning
to the old implementation, such that users
A nit only, I'm afraid: this patch adds a license mismatch.
On Wed, 2015-04-22 at 21:25 +0200, Stephan Mueller wrote:
--- /dev/null
+++ b/crypto/jitterentropy.c
+ * License
+ * ===
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are
Am Donnerstag, 23. April 2015, 16:05:08 schrieb Paul Bolle:
Hi Paul,
A nit only, I'm afraid: this patch adds a license mismatch.
On Wed, 2015-04-22 at 21:25 +0200, Stephan Mueller wrote:
--- /dev/null
+++ b/crypto/jitterentropy.c
+ * License
+ * ===
+ *
+ * Redistribution
The Security System is a hardware cryptographic accelerator that support
AES/MD5/SHA1/DES/3DES/PRNG algorithms.
It could be found on many Allwinner SoC.
This patch enable the Security System on the Allwinner A20 SoC Device-tree.
Signed-off-by: LABBE Corentin clabbe.montj...@gmail.com
---
Hello
This is the driver for the Security System included in Allwinner SoC A20.
The Security System (SS for short) is a hardware cryptographic accelerator that
support AES/MD5/SHA1/DES/3DES/PRNG algorithms.
It could be found on others Allwinner SoC:
- A10, A10s, A13, A31 and A33 manual give the
Add support for the Security System included in Allwinner SoC A20.
The Security System is a hardware cryptographic accelerator that support:
- MD5 and SHA1 hash algorithms
- AES block cipher in CBC/ECB mode with 128/196/256bits keys.
- DES and 3DES block cipher in CBC/ECB mode
Signed-off-by:
This patch adds documentation for Device-Tree bindings for the Security System
cryptographic accelerator driver.
Signed-off-by: LABBE Corentin clabbe.montj...@gmail.com
---
Documentation/devicetree/bindings/crypto/sunxi-ss.txt | 9 +
1 file changed, 9 insertions(+)
create mode 100644
On Thu, Apr 23, 2015 at 02:27:36PM +0800, kbuild test robot wrote:
tree:
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
head: 8a1a2b717e0d4d5f3e3bb59b7dee5079a15ab24b
commit: 59afdc7b32143528524455039e7557a46b60e4c8 [42/56] crypto: api - Move
module sig
On 04/22/2015 07:02 AM, Herbert Xu wrote:
There is currently a large ifdef FIPS code section in proc.c.
Ostensibly it's there because the fips_enabled sysctl sits under
/proc/sys/crypto. However, no other crypto sysctls exist.
In fact, the whole ethos of the crypto API is against such user
When the user explicitly states that they don't care whether the
algorithm has been tested (type = CRYPTO_ALG_TESTED and mask = 0),
there is a corner case where we may erroneously return ENOENT.
This patch fixes it by correcting the logic in the test.
Signed-off-by: Herbert Xu
On Thu, Apr 23, 2015 at 12:03:38PM +0300, Horia Geantă wrote:
This applies also to GMAC (rfc4543), right?
No RFC4543 appears to be correctly implemented.
Does this mean that even the test vectors (crypto/testmgr.h) are broken?
Indeed. The test vectors appear to be generated either through
When the user explicitly states that they don't care whether the
algorithm has been tested (type = CRYPTO_ALG_TESTED and mask = 0),
there is a corner case where we may erroneously return ENOENT.
This patch fixes it by correcting the logic in the test.
Signed-off-by: Herbert Xu
On 4/23/2015 6:26 AM, Herbert Xu wrote:
Hi:
It looks like our IPsec implementations of CCM and GCM are buggy
This applies also to GMAC (rfc4543), right?
in that they don't include the IV in the authentication calculation.
This definitely breaks interoperability with anyone who implements
Hi Herbert,
Does this mean that even the test vectors (crypto/testmgr.h) are broken?
Indeed. The test vectors appear to be generated either through
our implementation or by one that is identical to us.
I'm not sure about that. RFC4106 refers to [1] for test vectors, which
is still
Since kzalloc() returns a void pointer, we don't need to cast the
return value in arch/x86/crypto/sha-mb/sha1_mb.c::sha1_mb_mod_init().
Signed-off-by: Firo Yang fir...@gmail.com
---
arch/x86/crypto/sha-mb/sha1_mb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
On Thu, Apr 23, 2015 at 11:58:52AM +0200, Martin Willi wrote:
I'm not sure about that. RFC4106 refers to [1] for test vectors, which
is still available at web.archive.org [2].
When looking for example at Test Case 3, this is the same as in a newer
revision of the document [3]. That looks
Hi Steffen,
It looks like our IPsec implementations of CCM and GCM are buggy
in that they don't include the IV in the authentication calculation.
Seems like crypto_rfc4106_crypt() passes the associated data it
got from ESP directly to gcm, without chaining with the IV.
Do you have any
Am Donnerstag, 23. April 2015, 10:55:58 schrieb Herbert Xu:
Hi Herbert,
On Thu, Apr 23, 2015 at 04:51:56AM +0200, Stephan Mueller wrote:
Encrypt input: IV, plaintext
Encrypt output: processed IV, ciphertext
Decrypt input: processed IV, ciphertext, IV to use for compare operation
On Thu, Apr 23, 2015 at 11:26:20AM +0800, Herbert Xu wrote:
Hi:
It looks like our IPsec implementations of CCM and GCM are buggy
in that they don't include the IV in the authentication calculation.
Seems like crypto_rfc4106_crypt() passes the associated data it
got from ESP directly to gcm,
On Thu, Apr 23, 2015 at 03:24:59PM +0200, Martin Willi wrote:
Do you have any pointer for me where this is defined? Why is it needed,
given that GCM implicitly authenticates the IV by using it in Y0?
Actually you're quite right. Both GCM and CCM implicitly includes
the IV in the
On Fri, Apr 24, 2015 at 01:30:00PM +0800, Herbert Xu wrote:
Now we just need to figre out whether we're still OK with RFC4543.
Looks like we're OK here too as the diagram in section 3.5 says
that the IV should be included in the AAD.
So we're all good!
Thanks,
--
Email: Herbert Xu
35 matches
Mail list logo
