An error occurred fetching the project authors.
- 04 Mar, 2012 1 commit
-
-
Herbert Xu authored
commit 58d7d18b upstream. The previous patch used the modulus operator over a power of 2 unnecessarily which may produce suboptimal binary code. This patch changes changes them to binary ands instead. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 03 Feb, 2012 2 commits
-
-
Alexey Dobriyan authored
commit 51fc6dc8 upstream. For rounds 16--79, W[i] only depends on W[i - 2], W[i - 7], W[i - 15] and W[i - 16]. Consequently, keeping all W[80] array on stack is unnecessary, only 16 values are really needed. Using W[16] instead of W[80] greatly reduces stack usage (~750 bytes to ~340 bytes on x86_64). Line by line explanation: * BLEND_OP array is "circular" now, all indexes have to be modulo 16. Round number is positive, so remainder operation should be without surprises. * initial full message scheduling is trimmed to first 16 values which come from data block, the rest is calculated before it's needed. * original loop body is unrolled version of new SHA512_0_15 and SHA512_16_79 macros, unrolling was done to not do explicit variable renaming. Otherwise it's the very same code after preprocessing. See sha1_transform() code which does the same trick. Patch survives in-tree crypto test and original bugreport test (ping flood with hmac(sha512). See FIPS 180-2 for SHA-512 definition http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdfSigned-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Alexey Dobriyan authored
commit 84e31fdb upstream. commit f9e2bca6 aka "crypto: sha512 - Move message schedule W[80] to static percpu area" created global message schedule area. If sha512_update will ever be entered twice, hash will be silently calculated incorrectly. Probably the easiest way to notice incorrect hashes being calculated is to run 2 ping floods over AH with hmac(sha512): #!/usr/sbin/setkey -f flush; spdflush; add IP1 IP2 ah 25 -A hmac-sha512 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000025; add IP2 IP1 ah 52 -A hmac-sha512 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000052; spdadd IP1 IP2 any -P out ipsec ah/transport//require; spdadd IP2 IP1 any -P in ipsec ah/transport//require; XfrmInStateProtoError will start ticking with -EBADMSG being returned from ah_input(). This never happens with, say, hmac(sha1). With patch applied (on BOTH sides), XfrmInStateProtoError does not tick with multiple bidirectional ping flood streams like it doesn't tick with SHA-1. After this patch sha512_transform() will start using ~750 bytes of stack on x86_64. This is OK for simple loads, for something more heavy, stack reduction will be done separatedly. Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 22 Jul, 2009 2 commits
-
-
Herbert Xu authored
This patch replaces the 32-bit counters in sha512_generic with 64-bit counters. It also switches the bit count to the simpler byte count. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Herbert Xu authored
This patch renames struct sha512_ctx and exports it as struct sha512_state so that other sha512 implementations can use it as the reference structure for exporting their state. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- 25 Dec, 2008 2 commits
-
-
Adrian-Ken Rueegsegger authored
This patch changes sha512 and sha384 to the new shash interface. Signed-off-by:
Adrian-Ken Rueegsegger <ken@codelabs.ch> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Adrian-Ken Rueegsegger authored
The message schedule W (u64[80]) is too big for the stack. In order for this algorithm to be used with shash it is moved to a static percpu area. Signed-off-by:
Adrian-Ken Rueegsegger <ken@codelabs.ch> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- 21 Apr, 2008 2 commits
-
-
Kamalesh Babulal authored
On Thu, Mar 27, 2008 at 03:40:36PM +0100, Bodo Eggert wrote: > Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote: > > > This patch cleanups the crypto code, replaces the init() and fini() > > with the <algorithm name>_init/_fini > > This part ist OK. > > > or init/fini_<algorithm name> (if the > > <algorithm name>_init/_fini exist) > > Having init_foo and foo_init won't be a good thing, will it? I'd start > confusing them. > > What about foo_modinit instead? Thanks for the suggestion, the init() is replaced with <algorithm name>_mod_init () and fini () is replaced with <algorithm name>_mod_fini. Signed-off-by:
Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Jan Glauber authored
Rename sha512 to sha512_generic and add a MODULE_ALIAS for sha512 so all sha512 implementations can be loaded automatically. Keep the broken tabs so git recognizes this as a rename. Signed-off-by:
Jan Glauber <jang@linux.vnet.ibm.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- 02 Nov, 2007 1 commit
-
-
Adrian Bunk authored
Not architecture specific code should not #include <asm/scatterlist.h>. This patch therefore either replaces them with #include <linux/scatterlist.h> or simply removes them if they were unused. Signed-off-by:
Adrian Bunk <bunk@kernel.org> Signed-off-by:
Jens Axboe <jens.axboe@oracle.com>
-
- 10 Oct, 2007 1 commit
-
-
Jan Glauber authored
There are currently several SHA implementations that all define their own initialization vectors and size values. Since this values are idential move them to a header file under include/crypto. Signed-off-by:
Jan Glauber <jang@de.ibm.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- 11 Dec, 2006 1 commit
-
-
Herbert Xu authored
The SHA384 block size should be 128 bytes, not 96 bytes. This was spotted by Andrew Donofrio. Fortunately the block size isn't actually used anywhere so this typo has had no real impact. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- 26 Jun, 2006 3 commits
-
-
Herbert Xu authored
Up until now algorithms have been happy to get a context pointer since they know everything that's in the tfm already (e.g., alignment, block size). However, once we have parameterised algorithms, such information will be specific to each tfm. So the algorithm API needs to be changed to pass the tfm structure instead of the context pointer. This patch is basically a text substitution. The only tricky bit is the assembly routines that need to get the context pointer offset through asm-offsets.h. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Herbert Xu authored
Various digest algorithms operate one block at a time and therefore keep a temporary buffer of partial blocks. This buffer does not need to be initialised since there is a counter which indicates what is and isn't valid in it. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Atsushi Nemoto authored
Some hash modules load/store data words directly. The digest layer should pass properly aligned buffer to update()/final() method. This patch also add cra_alignmask to some hash modules. Signed-off-by:
Atsushi Nemoto <anemo@mba.ocn.ne.jp> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- 09 Jan, 2006 1 commit
-
-
Herbert Xu authored
A lot of crypto code needs to read/write a 32-bit/64-bit words in a specific gender. Many of them open code them by reading/writing one byte at a time. This patch converts all the applicable usages over to use the standard byte order macros. This is based on a previous patch by Denis Vlasenko. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- 16 Apr, 2005 1 commit
-
-
Linus Torvalds authored
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-