1. 21 4月, 2018 1 次提交
    • N
      crypto: zstd - Add zstd support · d28fc3db
      Nick Terrell 提交于
      Adds zstd support to crypto and scompress. Only supports the default
      level.
      
      Previously we held off on this patch, since there weren't any users.
      Now zram is ready for zstd support, but depends on CONFIG_CRYPTO_ZSTD,
      which isn't defined until this patch is in. I also see a patch adding
      zstd to pstore [0], which depends on crypto zstd.
      
      [0] lkml.kernel.org/r/9c9416b2dff19f05fb4c35879aaa83d11ff72c92.1521626182.git.geliangtang@gmail.com
      Signed-off-by: NNick Terrell <terrelln@fb.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      d28fc3db
  2. 16 3月, 2018 1 次提交
  3. 22 2月, 2018 3 次提交
    • E
      crypto: speck - add test vectors for Speck64-XTS · 41b3316e
      Eric Biggers 提交于
      Add test vectors for Speck64-XTS, generated in userspace using C code.
      The inputs were borrowed from the AES-XTS test vectors, with key lengths
      adjusted.
      
      xts-speck64-neon passes these tests.  However, they aren't currently
      applicable for the generic XTS template, as that only supports a 128-bit
      block size.
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      41b3316e
    • E
      crypto: speck - add test vectors for Speck128-XTS · c3bb521b
      Eric Biggers 提交于
      Add test vectors for Speck128-XTS, generated in userspace using C code.
      The inputs were borrowed from the AES-XTS test vectors.
      
      Both xts(speck128-generic) and xts-speck128-neon pass these tests.
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      c3bb521b
    • E
      crypto: speck - add support for the Speck block cipher · da7a0ab5
      Eric Biggers 提交于
      Add a generic implementation of Speck, including the Speck128 and
      Speck64 variants.  Speck is a lightweight block cipher that can be much
      faster than AES on processors that don't have AES instructions.
      
      We are planning to offer Speck-XTS (probably Speck128/256-XTS) as an
      option for dm-crypt and fscrypt on Android, for low-end mobile devices
      with older CPUs such as ARMv7 which don't have the Cryptography
      Extensions.  Currently, such devices are unencrypted because AES is not
      fast enough, even when the NEON bit-sliced implementation of AES is
      used.  Other AES alternatives such as Twofish, Threefish, Camellia,
      CAST6, and Serpent aren't fast enough either; it seems that only a
      modern ARX cipher can provide sufficient performance on these devices.
      
      This is a replacement for our original proposal
      (https://patchwork.kernel.org/patch/10101451/) which was to offer
      ChaCha20 for these devices.  However, the use of a stream cipher for
      disk/file encryption with no space to store nonces would have been much
      more insecure than we thought initially, given that it would be used on
      top of flash storage as well as potentially on top of F2FS, neither of
      which is guaranteed to overwrite data in-place.
      
      Speck has been somewhat controversial due to its origin.  Nevertheless,
      it has a straightforward design (it's an ARX cipher), and it appears to
      be the leading software-optimized lightweight block cipher currently,
      with the most cryptanalysis.  It's also easy to implement without side
      channels, unlike AES.  Moreover, we only intend Speck to be used when
      the status quo is no encryption, due to AES not being fast enough.
      
      We've also considered a novel length-preserving encryption mode based on
      ChaCha20 and Poly1305.  While theoretically attractive, such a mode
      would be a brand new crypto construction and would be more complicated
      and difficult to implement efficiently in comparison to Speck-XTS.
      
      There is confusion about the byte and word orders of Speck, since the
      original paper doesn't specify them.  But we have implemented it using
      the orders the authors recommended in a correspondence with them.  The
      test vectors are taken from the original paper but were mapped to byte
      arrays using the recommended byte and word orders.
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      da7a0ab5
  4. 25 1月, 2018 1 次提交
  5. 12 1月, 2018 1 次提交
  6. 03 11月, 2017 1 次提交
  7. 22 9月, 2017 1 次提交
  8. 28 6月, 2017 1 次提交
  9. 20 6月, 2017 1 次提交
  10. 19 6月, 2017 1 次提交
  11. 10 6月, 2017 1 次提交
  12. 24 4月, 2017 2 次提交
  13. 21 4月, 2017 1 次提交
  14. 24 3月, 2017 1 次提交
  15. 09 3月, 2017 1 次提交
  16. 11 2月, 2017 1 次提交
  17. 13 1月, 2017 3 次提交
    • A
      crypto: testmgr - use calculated count for number of test vectors · 21c8e720
      Ard Biesheuvel 提交于
      When working on AES in CCM mode for ARM, my code passed the internal
      tcrypt test before I had even bothered to implement the AES-192 and
      AES-256 code paths, which is strange because the tcrypt does contain
      AES-192 and AES-256 test vectors for CCM.
      
      As it turned out, the define AES_CCM_ENC_TEST_VECTORS was out of sync
      with the actual number of test vectors, causing only the AES-128 ones
      to be executed.
      
      So get rid of the defines, and wrap the test vector references in a
      macro that calculates the number of vectors automatically.
      
      The following test vector counts were out of sync with the respective
      defines:
      
          BF_CTR_ENC_TEST_VECTORS          2 ->  3
          BF_CTR_DEC_TEST_VECTORS          2 ->  3
          TF_CTR_ENC_TEST_VECTORS          2 ->  3
          TF_CTR_DEC_TEST_VECTORS          2 ->  3
          SERPENT_CTR_ENC_TEST_VECTORS     2 ->  3
          SERPENT_CTR_DEC_TEST_VECTORS     2 ->  3
          AES_CCM_ENC_TEST_VECTORS         8 -> 14
          AES_CCM_DEC_TEST_VECTORS         7 -> 17
          AES_CCM_4309_ENC_TEST_VECTORS    7 -> 23
          AES_CCM_4309_DEC_TEST_VECTORS   10 -> 23
          CAMELLIA_CTR_ENC_TEST_VECTORS    2 ->  3
          CAMELLIA_CTR_DEC_TEST_VECTORS    2 ->  3
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      21c8e720
    • A
      crypto: testmgr - Allocate only the required output size for hash tests · e93acd6f
      Andrew Lutomirski 提交于
      There are some hashes (e.g. sha224) that have some internal trickery
      to make sure that only the correct number of output bytes are
      generated.  If something goes wrong, they could potentially overrun
      the output buffer.
      
      Make the test more robust by allocating only enough space for the
      correct output size so that memory debugging will catch the error if
      the output is overrun.
      
      Tested by intentionally breaking sha224 to output all 256
      internally-generated bits while running on KASAN.
      
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NAndy Lutomirski <luto@kernel.org>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      e93acd6f
    • E
      crypto: testmgr - use kmemdup instead of kmalloc+memcpy · d2110224
      Eric Biggers 提交于
      It's recommended to use kmemdup instead of kmalloc followed by memcpy.
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      d2110224
  18. 27 12月, 2016 1 次提交
    • L
      crypto: testmgr - Use heap buffer for acomp test input · 02608e02
      Laura Abbott 提交于
      Christopher Covington reported a crash on aarch64 on recent Fedora
      kernels:
      
      kernel BUG at ./include/linux/scatterlist.h:140!
      Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
      Modules linked in:
      CPU: 2 PID: 752 Comm: cryptomgr_test Not tainted 4.9.0-11815-ge93b1cc8 #162
      Hardware name: linux,dummy-virt (DT)
      task: ffff80007c650080 task.stack: ffff800008910000
      PC is at sg_init_one+0xa0/0xb8
      LR is at sg_init_one+0x24/0xb8
      ...
      [<ffff000008398db8>] sg_init_one+0xa0/0xb8
      [<ffff000008350a44>] test_acomp+0x10c/0x438
      [<ffff000008350e20>] alg_test_comp+0xb0/0x118
      [<ffff00000834f28c>] alg_test+0x17c/0x2f0
      [<ffff00000834c6a4>] cryptomgr_test+0x44/0x50
      [<ffff0000080dac70>] kthread+0xf8/0x128
      [<ffff000008082ec0>] ret_from_fork+0x10/0x50
      
      The test vectors used for input are part of the kernel image. These
      inputs are passed as a buffer to sg_init_one which eventually blows up
      with BUG_ON(!virt_addr_valid(buf)). On arm64, virt_addr_valid returns
      false for the kernel image since virt_to_page will not return the
      correct page. Fix this by copying the input vectors to heap buffer
      before setting up the scatterlist.
      Reported-by: NChristopher Covington <cov@codeaurora.org>
      Fixes: d7db7a88 ("crypto: acomp - update testmgr with support for acomp")
      Signed-off-by: NLaura Abbott <labbott@redhat.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      02608e02
  19. 08 12月, 2016 1 次提交
  20. 07 12月, 2016 1 次提交
  21. 28 11月, 2016 2 次提交
  22. 25 10月, 2016 1 次提交
  23. 02 10月, 2016 1 次提交
  24. 31 8月, 2016 1 次提交
  25. 09 8月, 2016 1 次提交
  26. 19 7月, 2016 1 次提交
  27. 05 7月, 2016 1 次提交
  28. 01 7月, 2016 2 次提交
  29. 23 6月, 2016 2 次提交
  30. 20 6月, 2016 1 次提交
  31. 09 5月, 2016 1 次提交
  32. 05 5月, 2016 1 次提交