An error occurred fetching the project authors.
  1. 04 Mar, 2012 1 commit
  2. 03 Feb, 2012 2 commits
    • Alexey Dobriyan's avatar
      crypto: sha512 - reduce stack usage to safe number · 4d385100
      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: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4d385100
    • Alexey Dobriyan's avatar
      crypto: sha512 - make it work, undo percpu message schedule · bef4c3be
      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: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bef4c3be
  3. 22 Jul, 2009 2 commits
  4. 25 Dec, 2008 2 commits
  5. 21 Apr, 2008 2 commits
  6. 02 Nov, 2007 1 commit
  7. 10 Oct, 2007 1 commit
  8. 11 Dec, 2006 1 commit
  9. 26 Jun, 2006 3 commits
  10. 09 Jan, 2006 1 commit
  11. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      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!
      1da177e4