1. 27 6月, 2012 6 次提交
  2. 12 6月, 2012 2 次提交
    • J
      crypto: serpent - add x86_64/avx assembler implementation · 7efe4076
      Johannes Goetzfried 提交于
      This patch adds a x86_64/avx assembler implementation of the Serpent block
      cipher. The implementation is very similar to the sse2 implementation and
      processes eight blocks in parallel. Because of the new non-destructive three
      operand syntax all move-instructions can be removed and therefore a little
      performance increase is provided.
      
      Patch has been tested with tcrypt and automated filesystem tests.
      
      Tcrypt benchmark results:
      
      Intel Core i5-2500 CPU (fam:6, model:42, step:7)
      
      serpent-avx-x86_64 vs. serpent-sse2-x86_64
      128bit key:                                             (lrw:256bit)    (xts:256bit)
      size    ecb-enc ecb-dec cbc-enc cbc-dec ctr-enc ctr-dec lrw-enc lrw-dec xts-enc xts-dec
      16B     1.03x   1.01x   1.01x   1.01x   1.00x   1.00x   1.00x   1.00x   1.00x   1.01x
      64B     1.00x   1.00x   1.00x   1.00x   1.00x   0.99x   1.00x   1.01x   1.00x   1.00x
      256B    1.05x   1.03x   1.00x   1.02x   1.05x   1.06x   1.05x   1.02x   1.05x   1.02x
      1024B   1.05x   1.02x   1.00x   1.02x   1.05x   1.06x   1.05x   1.03x   1.05x   1.02x
      8192B   1.05x   1.02x   1.00x   1.02x   1.06x   1.06x   1.04x   1.03x   1.04x   1.02x
      
      256bit key:                                             (lrw:384bit)    (xts:512bit)
      size    ecb-enc ecb-dec cbc-enc cbc-dec ctr-enc ctr-dec lrw-enc lrw-dec xts-enc xts-dec
      16B     1.01x   1.00x   1.01x   1.01x   1.00x   1.00x   0.99x   1.03x   1.01x   1.01x
      64B     1.00x   1.00x   1.00x   1.00x   1.00x   1.00x   1.00x   1.01x   1.00x   1.02x
      256B    1.05x   1.02x   1.00x   1.02x   1.05x   1.02x   1.04x   1.05x   1.05x   1.02x
      1024B   1.06x   1.02x   1.00x   1.02x   1.07x   1.06x   1.05x   1.04x   1.05x   1.02x
      8192B   1.05x   1.02x   1.00x   1.02x   1.06x   1.06x   1.04x   1.05x   1.05x   1.02x
      
      serpent-avx-x86_64 vs aes-asm (8kB block):
               128bit  256bit
      ecb-enc  1.26x   1.73x
      ecb-dec  1.20x   1.64x
      cbc-enc  0.33x   0.45x
      cbc-dec  1.24x   1.67x
      ctr-enc  1.32x   1.76x
      ctr-dec  1.32x   1.76x
      lrw-enc  1.20x   1.60x
      lrw-dec  1.15x   1.54x
      xts-enc  1.22x   1.64x
      xts-dec  1.17x   1.57x
      Signed-off-by: NJohannes Goetzfried <Johannes.Goetzfried@informatik.stud.uni-erlangen.de>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      7efe4076
    • J
      crypto: twofish - add x86_64/avx assembler implementation · 107778b5
      Johannes Goetzfried 提交于
      This patch adds a x86_64/avx assembler implementation of the Twofish block
      cipher. The implementation processes eight blocks in parallel (two 4 block
      chunk AVX operations). The table-lookups are done in general-purpose registers.
      For small blocksizes the 3way-parallel functions from the twofish-x86_64-3way
      module are called. A good performance increase is provided for blocksizes
      greater or equal to 128B.
      
      Patch has been tested with tcrypt and automated filesystem tests.
      
      Tcrypt benchmark results:
      
      Intel Core i5-2500 CPU (fam:6, model:42, step:7)
      
      twofish-avx-x86_64 vs. twofish-x86_64-3way
      128bit key:                                             (lrw:256bit)    (xts:256bit)
      size    ecb-enc ecb-dec cbc-enc cbc-dec ctr-enc ctr-dec lrw-enc lrw-dec xts-enc xts-dec
      16B     0.96x   0.97x   1.00x   0.95x   0.97x   0.97x   0.96x   0.95x   0.95x   0.98x
      64B     0.99x   0.99x   1.00x   0.99x   0.98x   0.98x   0.99x   0.98x   0.99x   0.98x
      256B    1.20x   1.21x   1.00x   1.19x   1.15x   1.14x   1.19x   1.20x   1.18x   1.19x
      1024B   1.29x   1.30x   1.00x   1.28x   1.23x   1.24x   1.26x   1.28x   1.26x   1.27x
      8192B   1.31x   1.32x   1.00x   1.31x   1.25x   1.25x   1.28x   1.29x   1.28x   1.30x
      
      256bit key:                                             (lrw:384bit)    (xts:512bit)
      size    ecb-enc ecb-dec cbc-enc cbc-dec ctr-enc ctr-dec lrw-enc lrw-dec xts-enc xts-dec
      16B     0.96x   0.96x   1.00x   0.96x   0.97x   0.98x   0.95x   0.95x   0.95x   0.96x
      64B     1.00x   0.99x   1.00x   0.98x   0.98x   1.01x   0.98x   0.98x   0.98x   0.98x
      256B    1.20x   1.21x   1.00x   1.21x   1.15x   1.15x   1.19x   1.20x   1.18x   1.19x
      1024B   1.29x   1.30x   1.00x   1.28x   1.23x   1.23x   1.26x   1.27x   1.26x   1.27x
      8192B   1.31x   1.33x   1.00x   1.31x   1.26x   1.26x   1.29x   1.29x   1.28x   1.30x
      
      twofish-avx-x86_64 vs aes-asm (8kB block):
               128bit  256bit
      ecb-enc  1.19x   1.63x
      ecb-dec  1.18x   1.62x
      cbc-enc  0.75x   1.03x
      cbc-dec  1.23x   1.67x
      ctr-enc  1.24x   1.65x
      ctr-dec  1.24x   1.65x
      lrw-enc  1.15x   1.53x
      lrw-dec  1.14x   1.52x
      xts-enc  1.16x   1.56x
      xts-dec  1.16x   1.56x
      Signed-off-by: NJohannes Goetzfried <Johannes.Goetzfried@informatik.stud.uni-erlangen.de>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      107778b5
  3. 10 4月, 2012 1 次提交
  4. 24 3月, 2012 1 次提交
  5. 14 3月, 2012 1 次提交
    • J
      crypto: camellia - add assembler implementation for x86_64 · 0b95ec56
      Jussi Kivilinna 提交于
      Patch adds x86_64 assembler implementation of Camellia block cipher. Two set of
      functions are provided. First set is regular 'one-block at time' encrypt/decrypt
      functions. Second is 'two-block at time' functions that gain performance increase
      on out-of-order CPUs. Performance of 2-way functions should be equal to 1-way
      functions with in-order CPUs.
      
      Patch has been tested with tcrypt and automated filesystem tests.
      
      Tcrypt benchmark results:
      
      AMD Phenom II 1055T (fam:16, model:10):
      
      camellia-asm vs camellia_generic:
      128bit key:                                             (lrw:256bit)    (xts:256bit)
      size    ecb-enc ecb-dec cbc-enc cbc-dec ctr-enc ctr-dec lrw-enc lrw-dec xts-enc xts-dec
      16B     1.27x   1.22x   1.30x   1.42x   1.30x   1.34x   1.19x   1.05x   1.23x   1.24x
      64B     1.74x   1.79x   1.43x   1.87x   1.81x   1.87x   1.48x   1.38x   1.55x   1.62x
      256B    1.90x   1.87x   1.43x   1.94x   1.94x   1.95x   1.63x   1.62x   1.67x   1.70x
      1024B   1.96x   1.93x   1.43x   1.95x   1.98x   2.01x   1.67x   1.69x   1.74x   1.80x
      8192B   1.96x   1.96x   1.39x   1.93x   2.01x   2.03x   1.72x   1.64x   1.71x   1.76x
      
      256bit key:                                             (lrw:384bit)    (xts:512bit)
      size    ecb-enc ecb-dec cbc-enc cbc-dec ctr-enc ctr-dec lrw-enc lrw-dec xts-enc xts-dec
      16B     1.23x   1.23x   1.33x   1.39x   1.34x   1.38x   1.04x   1.18x   1.21x   1.29x
      64B     1.72x   1.69x   1.42x   1.78x   1.81x   1.89x   1.57x   1.52x   1.56x   1.65x
      256B    1.85x   1.88x   1.42x   1.86x   1.93x   1.96x   1.69x   1.65x   1.70x   1.75x
      1024B   1.88x   1.86x   1.45x   1.95x   1.96x   1.95x   1.77x   1.71x   1.77x   1.78x
      8192B   1.91x   1.86x   1.42x   1.91x   2.03x   1.98x   1.73x   1.71x   1.78x   1.76x
      
      camellia-asm vs aes-asm (8kB block):
               128bit  256bit
      ecb-enc  1.15x   1.22x
      ecb-dec  1.16x   1.16x
      cbc-enc  0.85x   0.90x
      cbc-dec  1.20x   1.23x
      ctr-enc  1.28x   1.30x
      ctr-dec  1.27x   1.28x
      lrw-enc  1.12x   1.16x
      lrw-dec  1.08x   1.10x
      xts-enc  1.11x   1.15x
      xts-dec  1.14x   1.15x
      
      Intel Core2 T8100 (fam:6, model:23, step:6):
      
      camellia-asm vs camellia_generic:
      128bit key:                                             (lrw:256bit)    (xts:256bit)
      size    ecb-enc ecb-dec cbc-enc cbc-dec ctr-enc ctr-dec lrw-enc lrw-dec xts-enc xts-dec
      16B     1.10x   1.12x   1.14x   1.16x   1.16x   1.15x   1.02x   1.02x   1.08x   1.08x
      64B     1.61x   1.60x   1.17x   1.68x   1.67x   1.66x   1.43x   1.42x   1.44x   1.42x
      256B    1.65x   1.73x   1.17x   1.77x   1.81x   1.80x   1.54x   1.53x   1.58x   1.54x
      1024B   1.76x   1.74x   1.18x   1.80x   1.85x   1.85x   1.60x   1.59x   1.65x   1.60x
      8192B   1.77x   1.75x   1.19x   1.81x   1.85x   1.86x   1.63x   1.61x   1.66x   1.62x
      
      256bit key:                                             (lrw:384bit)    (xts:512bit)
      size    ecb-enc ecb-dec cbc-enc cbc-dec ctr-enc ctr-dec lrw-enc lrw-dec xts-enc xts-dec
      16B     1.10x   1.07x   1.13x   1.16x   1.11x   1.16x   1.03x   1.02x   1.08x   1.07x
      64B     1.61x   1.62x   1.15x   1.66x   1.63x   1.68x   1.47x   1.46x   1.47x   1.44x
      256B    1.71x   1.70x   1.16x   1.75x   1.69x   1.79x   1.58x   1.57x   1.59x   1.55x
      1024B   1.78x   1.72x   1.17x   1.75x   1.80x   1.80x   1.63x   1.62x   1.65x   1.62x
      8192B   1.76x   1.73x   1.17x   1.78x   1.80x   1.81x   1.64x   1.62x   1.68x   1.64x
      
      camellia-asm vs aes-asm (8kB block):
               128bit  256bit
      ecb-enc  1.17x   1.21x
      ecb-dec  1.17x   1.20x
      cbc-enc  0.80x   0.82x
      cbc-dec  1.22x   1.24x
      ctr-enc  1.25x   1.26x
      ctr-dec  1.25x   1.26x
      lrw-enc  1.14x   1.18x
      lrw-dec  1.13x   1.17x
      xts-enc  1.14x   1.18x
      xts-dec  1.14x   1.17x
      Signed-off-by: NJussi Kivilinna <jussi.kivilinna@mbnet.fi>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      0b95ec56
  6. 20 12月, 2011 5 次提交
  7. 30 11月, 2011 1 次提交
  8. 21 11月, 2011 2 次提交
  9. 14 11月, 2011 1 次提交
  10. 09 11月, 2011 1 次提交
  11. 01 11月, 2011 1 次提交
  12. 26 10月, 2011 1 次提交
  13. 21 10月, 2011 2 次提交
  14. 22 9月, 2011 2 次提交
  15. 10 8月, 2011 1 次提交
    • M
      crypto: sha1 - SSSE3 based SHA1 implementation for x86-64 · 66be8951
      Mathias Krause 提交于
      This is an assembler implementation of the SHA1 algorithm using the
      Supplemental SSE3 (SSSE3) instructions or, when available, the
      Advanced Vector Extensions (AVX).
      
      Testing with the tcrypt module shows the raw hash performance is up to
      2.3 times faster than the C implementation, using 8k data blocks on a
      Core 2 Duo T5500. For the smalest data set (16 byte) it is still 25%
      faster.
      
      Since this implementation uses SSE/YMM registers it cannot safely be
      used in every situation, e.g. while an IRQ interrupts a kernel thread.
      The implementation falls back to the generic SHA1 variant, if using
      the SSE/YMM registers is not possible.
      
      With this algorithm I was able to increase the throughput of a single
      IPsec link from 344 Mbit/s to 464 Mbit/s on a Core 2 Quad CPU using
      the SSSE3 variant -- a speedup of +34.8%.
      
      Saving and restoring SSE/YMM state might make the actual throughput
      fluctuate when there are FPU intensive userland applications running.
      For example, meassuring the performance using iperf2 directly on the
      machine under test gives wobbling numbers because iperf2 uses the FPU
      for each packet to check if the reporting interval has expired (in the
      above test I got min/max/avg: 402/484/464 MBit/s).
      
      Using this algorithm on a IPsec gateway gives much more reasonable and
      stable numbers, albeit not as high as in the directly connected case.
      Here is the result from an RFC 2544 test run with a EXFO Packet Blazer
      FTB-8510:
      
       frame size    sha1-generic     sha1-ssse3    delta
          64 byte     37.5 MBit/s    37.5 MBit/s     0.0%
         128 byte     56.3 MBit/s    62.5 MBit/s   +11.0%
         256 byte     87.5 MBit/s   100.0 MBit/s   +14.3%
         512 byte    131.3 MBit/s   150.0 MBit/s   +14.2%
        1024 byte    162.5 MBit/s   193.8 MBit/s   +19.3%
        1280 byte    175.0 MBit/s   212.5 MBit/s   +21.4%
        1420 byte    175.0 MBit/s   218.7 MBit/s   +25.0%
        1518 byte    150.0 MBit/s   181.2 MBit/s   +20.8%
      
      The throughput for the largest frame size is lower than for the
      previous size because the IP packets need to be fragmented in this
      case to make there way through the IPsec tunnel.
      Signed-off-by: NMathias Krause <minipli@googlemail.com>
      Cc: Maxim Locktyukhin <maxim.locktyukhin@intel.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      66be8951
  16. 11 7月, 2011 1 次提交
  17. 30 6月, 2011 1 次提交
  18. 16 5月, 2011 1 次提交
  19. 28 12月, 2010 1 次提交
  20. 29 11月, 2010 1 次提交
  21. 27 11月, 2010 1 次提交
    • M
      crypto: aesni-intel - Ported implementation to x86-32 · 0d258efb
      Mathias Krause 提交于
      The AES-NI instructions are also available in legacy mode so the 32-bit
      architecture may profit from those, too.
      
      To illustrate the performance gain here's a short summary of a dm-crypt
      speed test on a Core i7 M620 running at 2.67GHz comparing both assembler
      implementations:
      
      x86:                   i568       aes-ni    delta
      ECB, 256 bit:     93.8 MB/s   123.3 MB/s   +31.4%
      CBC, 256 bit:     84.8 MB/s   262.3 MB/s  +209.3%
      LRW, 256 bit:    108.6 MB/s   222.1 MB/s  +104.5%
      XTS, 256 bit:    105.0 MB/s   205.5 MB/s   +95.7%
      
      Additionally, due to some minor optimizations, the 64-bit version also
      got a minor performance gain as seen below:
      
      x86-64:           old impl.    new impl.    delta
      ECB, 256 bit:    121.1 MB/s   123.0 MB/s    +1.5%
      CBC, 256 bit:    285.3 MB/s   290.8 MB/s    +1.9%
      LRW, 256 bit:    263.7 MB/s   265.3 MB/s    +0.6%
      XTS, 256 bit:    251.1 MB/s   255.3 MB/s    +1.7%
      Signed-off-by: NMathias Krause <minipli@googlemail.com>
      Reviewed-by: NHuang Ying <ying.huang@intel.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      0d258efb
  22. 26 11月, 2010 1 次提交
    • H
      crypto: algif_skcipher - User-space interface for skcipher operations · 8ff59090
      Herbert Xu 提交于
      This patch adds the af_alg plugin for symmetric key ciphers,
      corresponding to the ablkcipher kernel operation type.
      
      Keys can optionally be set through the setsockopt interface.
      
      Once a sendmsg call occurs without MSG_MORE no further writes
      may be made to the socket until all previous data has been read.
      
      IVs and and whether encryption/decryption is performed can be
      set through the setsockopt interface or as a control message
      to sendmsg.
      
      The interface is completely synchronous, all operations are
      carried out in recvmsg(2) and will complete prior to the system
      call returning.
      
      The splice(2) interface support reading the user-space data directly
      without copying (except that the Crypto API itself may copy the data
      if alignment is off).
      
      The recvmsg(2) interface supports directly writing to user-space
      without additional copying, i.e., the kernel crypto interface will
      receive the user-space address as its output SG list.
      
      Thakns to Miloslav Trmac for reviewing this and contributing
      fixes and improvements.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      8ff59090
  23. 19 11月, 2010 2 次提交
    • H
      crypto: algif_hash - User-space interface for hash operations · fe869cdb
      Herbert Xu 提交于
      This patch adds the af_alg plugin for hash, corresponding to
      the ahash kernel operation type.
      
      Keys can optionally be set through the setsockopt interface.
      
      Each sendmsg call will finalise the hash unless sent with a MSG_MORE
      flag.
      
      Partial hash states can be cloned using accept(2).
      
      The interface is completely synchronous, all operations will
      complete prior to the system call returning.
      
      Both sendmsg(2) and splice(2) support reading the user-space
      data directly without copying (except that the Crypto API itself
      may copy the data if alignment is off).
      
      For now only the splice(2) interface supports performing digest
      instead of init/update/final.  In future the sendmsg(2) interface
      will also be modified to use digest/finup where possible so that
      hardware that cannot return a partial hash state can still benefit
      from this interface.
      
      Thakns to Miloslav Trmac for reviewing this and contributing
      fixes and improvements.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Tested-by: NMartin Willi <martin@strongswan.org>
      fe869cdb
    • H
      crypto: af_alg - User-space interface for Crypto API · 03c8efc1
      Herbert Xu 提交于
      This patch creates the backbone of the user-space interface for
      the Crypto API, through a new socket family AF_ALG.
      
      Each session corresponds to one or more connections obtained from
      that socket.  The number depends on the number of inputs/outputs
      of that particular type of operation.  For most types there will
      be a s ingle connection/file descriptor that is used for both input
      and output.  AEAD is one of the few that require two inputs.
      
      Each algorithm type will provide its own implementation that plugs
      into af_alg.  They're keyed using a string such as "skcipher" or
      "hash".
      
      IOW this patch only contains the boring bits that is required
      to hold everything together.
      
      Thakns to Miloslav Trmac for reviewing this and contributing
      fixes and improvements.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Tested-by: NMartin Willi <martin@strongswan.org>
      03c8efc1
  24. 12 9月, 2010 1 次提交
  25. 03 9月, 2010 1 次提交
  26. 06 8月, 2010 1 次提交
    • H
      crypto: testmgr - Default to no tests · 00ca28a5
      Herbert Xu 提交于
      On Thu, Aug 05, 2010 at 07:01:21PM -0700, Linus Torvalds wrote:
      > On Thu, Aug 5, 2010 at 6:40 PM, Herbert Xu <herbert@gondor.hengli.com.au> wrote:
      > >
      > > -config CRYPTO_MANAGER_TESTS
      > > -       bool "Run algolithms' self-tests"
      > > -       default y
      > > -       depends on CRYPTO_MANAGER2
      > > +config CRYPTO_MANAGER_DISABLE_TESTS
      > > +       bool "Disable run-time self tests"
      > > +       depends on CRYPTO_MANAGER2 && EMBEDDED
      >
      > Why do you still want to force-enable those tests? I was going to
      > complain about the "default y" anyway, now I'm _really_ complaining,
      > because you've now made it impossible to disable those tests. Why?
      
      As requested, this patch sets the default to y and removes the
      EMBEDDED dependency.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      00ca28a5