1. 05 May, 2016 1 commit
  2. 01 Feb, 2016 1 commit
  3. 27 Jan, 2016 2 commits
  4. 26 Jan, 2016 1 commit
    • Arnd Bergmann's avatar
      crypto: ghash,poly1305 - select CRYPTO_HASH where needed · 578c60fb
      Arnd Bergmann authored
      The ghash and poly1305 hash implementations can be enabled when
      CONFIG_CRYPTO_HASH is turned off, causing a link error:
      
      crypto/built-in.o: In function `ghash_mod_init':
      (.init.text+0xd0): undefined reference to `crypto_register_shash'
      crypto/built-in.o: In function `ghash_mod_exit':
      (.exit.text+0xb4): undefined reference to `crypto_unregister_shash'
      crypto/built-in.o: In function `poly1305_mod_init':
      (.init.text+0xb4): undefined reference to `crypto_register_shash'
      crypto/built-in.o: In function `poly1305_mod_exit':
      (.exit.text+0x98): undefined reference to `crypto_unregister_shash'
      
      This adds an explicit 'select', like all other hashes have it.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      578c60fb
  5. 15 Oct, 2015 1 commit
  6. 21 Sep, 2015 1 commit
  7. 17 Aug, 2015 2 commits
  8. 14 Aug, 2015 1 commit
  9. 05 Aug, 2015 1 commit
  10. 17 Jul, 2015 4 commits
    • Martin Willi's avatar
      crypto: poly1305 - Add a four block AVX2 variant for x86_64 · b1ccc8f4
      Martin Willi authored
      Extends the x86_64 Poly1305 authenticator by a function processing four
      consecutive Poly1305 blocks in parallel using AVX2 instructions.
      
      For large messages, throughput increases by ~15-45% compared to two
      block SSE2:
      
      testing speed of poly1305 (poly1305-simd)
      test  0 (   96 byte blocks,   16 bytes per update,   6 updates): 3809514 opers/sec,  365713411 bytes/sec
      test  1 (   96 byte blocks,   32 bytes per update,   3 updates): 5973423 opers/sec,  573448627 bytes/sec
      test  2 (   96 byte blocks,   96 bytes per update,   1 updates): 9446779 opers/sec,  906890803 bytes/sec
      test  3 (  288 byte blocks,   16 bytes per update,  18 updates): 1364814 opers/sec,  393066691 bytes/sec
      test  4 (  288 byte blocks,   32 bytes per update,   9 updates): 2045780 opers/sec,  589184697 bytes/sec
      test  5 (  288 byte blocks,  288 bytes per update,   1 updates): 3711946 opers/sec, 1069040592 bytes/sec
      test  6 ( 1056 byte blocks,   32 bytes per update,  33 updates):  573686 opers/sec,  605812732 bytes/sec
      test  7 ( 1056 byte blocks, 1056 bytes per update,   1 updates): 1647802 opers/sec, 1740079440 bytes/sec
      test  8 ( 2080 byte blocks,   32 bytes per update,  65 updates):  292970 opers/sec,  609378224 bytes/sec
      test  9 ( 2080 byte blocks, 2080 bytes per update,   1 updates):  943229 opers/sec, 1961916528 bytes/sec
      test 10 ( 4128 byte blocks, 4128 bytes per update,   1 updates):  494623 opers/sec, 2041804569 bytes/sec
      test 11 ( 8224 byte blocks, 8224 bytes per update,   1 updates):  254045 opers/sec, 2089271014 bytes/sec
      
      testing speed of poly1305 (poly1305-simd)
      test  0 (   96 byte blocks,   16 bytes per update,   6 updates): 3826224 opers/sec,  367317552 bytes/sec
      test  1 (   96 byte blocks,   32 bytes per update,   3 updates): 5948638 opers/sec,  571069267 bytes/sec
      test  2 (   96 byte blocks,   96 bytes per update,   1 updates): 9439110 opers/sec,  906154627 bytes/sec
      test  3 (  288 byte blocks,   16 bytes per update,  18 updates): 1367756 opers/sec,  393913872 bytes/sec
      test  4 (  288 byte blocks,   32 bytes per update,   9 updates): 2056881 opers/sec,  592381958 bytes/sec
      test  5 (  288 byte blocks,  288 bytes per update,   1 updates): 3711153 opers/sec, 1068812179 bytes/sec
      test  6 ( 1056 byte blocks,   32 bytes per update,  33 updates):  574940 opers/sec,  607136745 bytes/sec
      test  7 ( 1056 byte blocks, 1056 bytes per update,   1 updates): 1948830 opers/sec, 2057964585 bytes/sec
      test  8 ( 2080 byte blocks,   32 bytes per update,  65 updates):  293308 opers/sec,  610082096 bytes/sec
      test  9 ( 2080 byte blocks, 2080 bytes per update,   1 updates): 1235224 opers/sec, 2569267792 bytes/sec
      test 10 ( 4128 byte blocks, 4128 bytes per update,   1 updates):  684405 opers/sec, 2825226316 bytes/sec
      test 11 ( 8224 byte blocks, 8224 bytes per update,   1 updates):  367101 opers/sec, 3019039446 bytes/sec
      
      Benchmark results from a Core i5-4670T.
      Signed-off-by: default avatarMartin Willi <martin@strongswan.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      b1ccc8f4
    • Martin Willi's avatar
      crypto: poly1305 - Add a SSE2 SIMD variant for x86_64 · c70f4abe
      Martin Willi authored
      Implements an x86_64 assembler driver for the Poly1305 authenticator. This
      single block variant holds the 130-bit integer in 5 32-bit words, but uses
      SSE to do two multiplications/additions in parallel.
      
      When calling updates with small blocks, the overhead for kernel_fpu_begin/
      kernel_fpu_end() negates the perfmance gain. We therefore use the
      poly1305-generic fallback for small updates.
      
      For large messages, throughput increases by ~5-10% compared to
      poly1305-generic:
      
      testing speed of poly1305 (poly1305-generic)
      test  0 (   96 byte blocks,   16 bytes per update,   6 updates): 4080026 opers/sec,  391682496 bytes/sec
      test  1 (   96 byte blocks,   32 bytes per update,   3 updates): 6221094 opers/sec,  597225024 bytes/sec
      test  2 (   96 byte blocks,   96 bytes per update,   1 updates): 9609750 opers/sec,  922536057 bytes/sec
      test  3 (  288 byte blocks,   16 bytes per update,  18 updates): 1459379 opers/sec,  420301267 bytes/sec
      test  4 (  288 byte blocks,   32 bytes per update,   9 updates): 2115179 opers/sec,  609171609 bytes/sec
      test  5 (  288 byte blocks,  288 bytes per update,   1 updates): 3729874 opers/sec, 1074203856 bytes/sec
      test  6 ( 1056 byte blocks,   32 bytes per update,  33 updates):  593000 opers/sec,  626208000 bytes/sec
      test  7 ( 1056 byte blocks, 1056 bytes per update,   1 updates): 1081536 opers/sec, 1142102332 bytes/sec
      test  8 ( 2080 byte blocks,   32 bytes per update,  65 updates):  302077 opers/sec,  628320576 bytes/sec
      test  9 ( 2080 byte blocks, 2080 bytes per update,   1 updates):  554384 opers/sec, 1153120176 bytes/sec
      test 10 ( 4128 byte blocks, 4128 bytes per update,   1 updates):  278715 opers/sec, 1150536345 bytes/sec
      test 11 ( 8224 byte blocks, 8224 bytes per update,   1 updates):  140202 opers/sec, 1153022070 bytes/sec
      
      testing speed of poly1305 (poly1305-simd)
      test  0 (   96 byte blocks,   16 bytes per update,   6 updates): 3790063 opers/sec,  363846076 bytes/sec
      test  1 (   96 byte blocks,   32 bytes per update,   3 updates): 5913378 opers/sec,  567684355 bytes/sec
      test  2 (   96 byte blocks,   96 bytes per update,   1 updates): 9352574 opers/sec,  897847104 bytes/sec
      test  3 (  288 byte blocks,   16 bytes per update,  18 updates): 1362145 opers/sec,  392297990 bytes/sec
      test  4 (  288 byte blocks,   32 bytes per update,   9 updates): 2007075 opers/sec,  578037628 bytes/sec
      test  5 (  288 byte blocks,  288 bytes per update,   1 updates): 3709811 opers/sec, 1068425798 bytes/sec
      test  6 ( 1056 byte blocks,   32 bytes per update,  33 updates):  566272 opers/sec,  597984182 bytes/sec
      test  7 ( 1056 byte blocks, 1056 bytes per update,   1 updates): 1111657 opers/sec, 1173910108 bytes/sec
      test  8 ( 2080 byte blocks,   32 bytes per update,  65 updates):  288857 opers/sec,  600823808 bytes/sec
      test  9 ( 2080 byte blocks, 2080 bytes per update,   1 updates):  590746 opers/sec, 1228751888 bytes/sec
      test 10 ( 4128 byte blocks, 4128 bytes per update,   1 updates):  301825 opers/sec, 1245936902 bytes/sec
      test 11 ( 8224 byte blocks, 8224 bytes per update,   1 updates):  153075 opers/sec, 1258896201 bytes/sec
      
      Benchmark results from a Core i5-4670T.
      Signed-off-by: default avatarMartin Willi <martin@strongswan.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      c70f4abe
    • Martin Willi's avatar
      crypto: chacha20 - Add an eight block AVX2 variant for x86_64 · 3d1e93cd
      Martin Willi authored
      Extends the x86_64 ChaCha20 implementation by a function processing eight
      ChaCha20 blocks in parallel using AVX2.
      
      For large messages, throughput increases by ~55-70% compared to four block
      SSSE3:
      
      testing speed of chacha20 (chacha20-simd) encryption
      test 0 (256 bit key, 16 byte blocks): 42249230 operations in 10 seconds (675987680 bytes)
      test 1 (256 bit key, 64 byte blocks): 46441641 operations in 10 seconds (2972265024 bytes)
      test 2 (256 bit key, 256 byte blocks): 33028112 operations in 10 seconds (8455196672 bytes)
      test 3 (256 bit key, 1024 byte blocks): 11568759 operations in 10 seconds (11846409216 bytes)
      test 4 (256 bit key, 8192 byte blocks): 1448761 operations in 10 seconds (11868250112 bytes)
      
      testing speed of chacha20 (chacha20-simd) encryption
      test 0 (256 bit key, 16 byte blocks): 41999675 operations in 10 seconds (671994800 bytes)
      test 1 (256 bit key, 64 byte blocks): 45805908 operations in 10 seconds (2931578112 bytes)
      test 2 (256 bit key, 256 byte blocks): 32814947 operations in 10 seconds (8400626432 bytes)
      test 3 (256 bit key, 1024 byte blocks): 19777167 operations in 10 seconds (20251819008 bytes)
      test 4 (256 bit key, 8192 byte blocks): 2279321 operations in 10 seconds (18672197632 bytes)
      
      Benchmark results from a Core i5-4670T.
      Signed-off-by: default avatarMartin Willi <martin@strongswan.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      3d1e93cd
    • Martin Willi's avatar
      crypto: chacha20 - Add a SSSE3 SIMD variant for x86_64 · c9320b6d
      Martin Willi authored
      Implements an x86_64 assembler driver for the ChaCha20 stream cipher. This
      single block variant works on a single state matrix using SSE instructions.
      It requires SSSE3 due the use of pshufb for efficient 8/16-bit rotate
      operations.
      
      For large messages, throughput increases by ~65% compared to
      chacha20-generic:
      
      testing speed of chacha20 (chacha20-generic) encryption
      test 0 (256 bit key, 16 byte blocks): 45089207 operations in 10 seconds (721427312 bytes)
      test 1 (256 bit key, 64 byte blocks): 43839521 operations in 10 seconds (2805729344 bytes)
      test 2 (256 bit key, 256 byte blocks): 12702056 operations in 10 seconds (3251726336 bytes)
      test 3 (256 bit key, 1024 byte blocks): 3371173 operations in 10 seconds (3452081152 bytes)
      test 4 (256 bit key, 8192 byte blocks): 422468 operations in 10 seconds (3460857856 bytes)
      
      testing speed of chacha20 (chacha20-simd) encryption
      test 0 (256 bit key, 16 byte blocks): 43141886 operations in 10 seconds (690270176 bytes)
      test 1 (256 bit key, 64 byte blocks): 46845874 operations in 10 seconds (2998135936 bytes)
      test 2 (256 bit key, 256 byte blocks): 18458512 operations in 10 seconds (4725379072 bytes)
      test 3 (256 bit key, 1024 byte blocks): 5360533 operations in 10 seconds (5489185792 bytes)
      test 4 (256 bit key, 8192 byte blocks): 692846 operations in 10 seconds (5675794432 bytes)
      
      Benchmark results from a Core i5-4670T.
      Signed-off-by: default avatarMartin Willi <martin@strongswan.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      c9320b6d
  11. 21 Jun, 2015 1 commit
  12. 17 Jun, 2015 3 commits
  13. 11 Jun, 2015 1 commit
  14. 04 Jun, 2015 5 commits
  15. 02 Jun, 2015 1 commit
  16. 27 May, 2015 1 commit
    • Stephan Mueller's avatar
      crypto: jitterentropy - add jitterentropy RNG · bb5530e4
      Stephan Mueller authored
      The CPU Jitter RNG provides a source of good entropy by
      collecting CPU executing time jitter. The entropy in the CPU
      execution time jitter is magnified by the CPU Jitter Random
      Number Generator. The CPU Jitter Random Number Generator uses
      the CPU execution timing jitter to generate a bit stream
      which complies with different statistical measurements that
      determine the bit stream is random.
      
      The CPU Jitter Random Number Generator delivers entropy which
      follows information theoretical requirements. Based on these
      studies and the implementation, the caller can assume that
      one bit of data extracted from the CPU Jitter Random Number
      Generator holds one bit of entropy.
      
      The CPU Jitter Random Number Generator provides a decentralized
      source of entropy, i.e. every caller can operate on a private
      state of the entropy pool.
      
      The RNG does not have any dependencies on any other service
      in the kernel. The RNG only needs a high-resolution time
      stamp.
      
      Further design details, the cryptographic assessment and
      large array of test results are documented at
      http://www.chronox.de/jent.html.
      
      CC: Andreas Steffen <andreas.steffen@strongswan.org>
      CC: Theodore Ts'o <tytso@mit.edu>
      CC: Sandy Harris <sandyinchina@gmail.com>
      Signed-off-by: default avatarStephan Mueller <smueller@chronox.de>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      bb5530e4
  17. 26 May, 2015 1 commit
  18. 21 May, 2015 2 commits
    • Herbert Xu's avatar
      crypto: echainiv - Add encrypted chain IV generator · a10f554f
      Herbert Xu authored
      This patch adds a new AEAD IV generator echainiv.  It is intended
      to replace the existing skcipher IV generator eseqiv.
      
      If the underlying AEAD algorithm is using the old AEAD interface,
      then echainiv will simply use its IV generator.
      
      Otherwise, echainiv will encrypt a counter just like eseqiv but
      it'll first xor it against a previously stored IV similar to
      chainiv.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      a10f554f
    • Herbert Xu's avatar
      crypto: seqiv - Add support for new AEAD interface · 856e3f40
      Herbert Xu authored
      This patch converts the seqiv IV generator to work with the new
      AEAD interface where IV generators are just normal AEAD algorithms.
      
      Full backwards compatibility is paramount at this point since
      no users have yet switched over to the new interface.  Nor can
      they switch to the new interface until IV generation is fully
      supported by it.
      
      So this means we are adding two versions of seqiv alongside the
      existing one.  The first one is the one that will be used when
      the underlying AEAD algorithm has switched over to the new AEAD
      interface.  The second one handles the current case where the
      underlying AEAD algorithm still uses the old interface.
      
      Both versions export themselves through the new AEAD interface.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      856e3f40
  19. 11 May, 2015 1 commit
    • Dan Streetman's avatar
      crypto: 842 - change 842 alg to use software · 2062c5b6
      Dan Streetman authored
      Change the crypto 842 compression alg to use the software 842 compression
      and decompression library.  Add the crypto driver_name as "842-generic".
      Remove the fallback to LZO compression.
      
      Previously, this crypto compression alg attemped 842 compression using
      PowerPC hardware, and fell back to LZO compression and decompression if
      the 842 PowerPC hardware was unavailable or failed.  This should not
      fall back to any other compression method, however; users of this crypto
      compression alg can fallback if desired, and transparent fallback tricks
      callers into thinking they are getting 842 compression when they actually
      get LZO compression - the failure of the 842 hardware should not be
      transparent to the caller.
      
      The crypto compression alg for a hardware device also should not be located
      in crypto/ so this is now a software-only implementation that uses the 842
      software compression/decompression library.
      Signed-off-by: default avatarDan Streetman <ddstreet@ieee.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      2062c5b6
  20. 07 Apr, 2015 1 commit
  21. 24 Mar, 2015 1 commit
  22. 12 Mar, 2015 1 commit
  23. 10 Mar, 2015 1 commit
  24. 04 Mar, 2015 2 commits
  25. 02 Mar, 2015 1 commit
  26. 01 Mar, 2015 1 commit
  27. 27 Feb, 2015 1 commit