Patch e68410ebf626 ("crypto: x86/sha512_ssse3 - move SHA-384/512
SSSE3 implementation to base layer") changed the prototypes of the
core asm SHA-512 implementations so that they are compatible with
the prototype used by the base layer.
However, in one instance, the register that was used for passi
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
Home Page:
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 authenticat
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
>> memc
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
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. chaini
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
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 4:10 PM, Ard Biesheuvel
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
> --- a/arch/x86/cr
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
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 f
On 23 April 2015 at 21:27, Bobby Powers wrote:
> Hello,
>
> Linus Torvalds 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 e68410ebf62676dfb93aafff7c55b76644f37072 in Linus's tree from
> this crpyto upd
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
> ---
> Documentation/devicetree/bindings/crypto/sunxi-ss.txt | 9 +
> 1
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'
img-hash.c:(.text
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()
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
#i
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 thi
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
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
> > + * ===
> > + *
> > + *
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 p
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 ope
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
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 gc
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
---
arch/x86/crypto/sha-mb/sha1_mb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/crypto/sha-mb/sha1_
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 ava
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 loo
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
o
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 implemen
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
diff --gi
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
diff --gi
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
inte
31 matches
Mail list logo
