1. 16 3月, 2018 1 次提交
  2. 22 2月, 2018 4 次提交
    • 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
    • C
      crypto: testmgr - Fix incorrect values in PKCS#1 test vector · 333e18c5
      Conor McLoughlin 提交于
      The RSA private key for the first form should have
      version, prime1, prime2, exponent1, exponent2, coefficient
      values 0.
      With non-zero values for prime1,2, exponent 1,2 and coefficient
      the Intel QAT driver will assume that values are provided for the
      private key second form. This will result in signature verification
      failures for modules where QAT device is present and the modules
      are signed with rsa,sha256.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NGiovanni Cabiddu <giovanni.cabiddu@intel.com>
      Signed-off-by: NConor McLoughlin <conor.mcloughlin@intel.com>
      Reviewed-by: NStephan Mueller <smueller@chronox.de>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      333e18c5
  3. 25 1月, 2018 1 次提交
  4. 22 9月, 2017 1 次提交
  5. 22 8月, 2017 1 次提交
  6. 20 6月, 2017 1 次提交
  7. 10 6月, 2017 1 次提交
  8. 24 4月, 2017 1 次提交
  9. 09 3月, 2017 1 次提交
  10. 01 3月, 2017 1 次提交
    • L
      crypto: testmgr - Pad aes_ccm_enc_tv_template vector · 1c68bb0f
      Laura Abbott 提交于
      Running with KASAN and crypto tests currently gives
      
       BUG: KASAN: global-out-of-bounds in __test_aead+0x9d9/0x2200 at addr ffffffff8212fca0
       Read of size 16 by task cryptomgr_test/1107
       Address belongs to variable 0xffffffff8212fca0
       CPU: 0 PID: 1107 Comm: cryptomgr_test Not tainted 4.10.0+ #45
       Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014
       Call Trace:
        dump_stack+0x63/0x8a
        kasan_report.part.1+0x4a7/0x4e0
        ? __test_aead+0x9d9/0x2200
        ? crypto_ccm_init_crypt+0x218/0x3c0 [ccm]
        kasan_report+0x20/0x30
        check_memory_region+0x13c/0x1a0
        memcpy+0x23/0x50
        __test_aead+0x9d9/0x2200
        ? kasan_unpoison_shadow+0x35/0x50
        ? alg_test_akcipher+0xf0/0xf0
        ? crypto_skcipher_init_tfm+0x2e3/0x310
        ? crypto_spawn_tfm2+0x37/0x60
        ? crypto_ccm_init_tfm+0xa9/0xd0 [ccm]
        ? crypto_aead_init_tfm+0x7b/0x90
        ? crypto_alloc_tfm+0xc4/0x190
        test_aead+0x28/0xc0
        alg_test_aead+0x54/0xd0
        alg_test+0x1eb/0x3d0
        ? alg_find_test+0x90/0x90
        ? __sched_text_start+0x8/0x8
        ? __wake_up_common+0x70/0xb0
        cryptomgr_test+0x4d/0x60
        kthread+0x173/0x1c0
        ? crypto_acomp_scomp_free_ctx+0x60/0x60
        ? kthread_create_on_node+0xa0/0xa0
        ret_from_fork+0x2c/0x40
       Memory state around the buggy address:
        ffffffff8212fb80: 00 00 00 00 01 fa fa fa fa fa fa fa 00 00 00 00
        ffffffff8212fc00: 00 01 fa fa fa fa fa fa 00 00 00 00 01 fa fa fa
       >ffffffff8212fc80: fa fa fa fa 00 05 fa fa fa fa fa fa 00 00 00 00
                                         ^
        ffffffff8212fd00: 01 fa fa fa fa fa fa fa 00 00 00 00 01 fa fa fa
        ffffffff8212fd80: fa fa fa fa 00 00 00 00 00 05 fa fa fa fa fa fa
      
      This always happens on the same IV which is less than 16 bytes.
      
      Per Ard,
      
      "CCM IVs are 16 bytes, but due to the way they are constructed
      internally, the final couple of bytes of input IV are dont-cares.
      
      Apparently, we do read all 16 bytes, which triggers the KASAN errors."
      
      Fix this by padding the IV with null bytes to be at least 16 bytes.
      
      Cc: stable@vger.kernel.org
      Fixes: 0bc5a6c5 ("crypto: testmgr - Disable rfc4309 test and convert
      test vectors")
      Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NLaura Abbott <labbott@redhat.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      1c68bb0f
  11. 25 2月, 2017 1 次提交
  12. 11 2月, 2017 1 次提交
  13. 13 1月, 2017 1 次提交
    • 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
  14. 07 12月, 2016 1 次提交
  15. 31 8月, 2016 1 次提交
  16. 05 7月, 2016 1 次提交
  17. 01 7月, 2016 1 次提交
  18. 23 6月, 2016 2 次提交
  19. 20 6月, 2016 1 次提交
  20. 27 1月, 2016 1 次提交
  21. 15 10月, 2015 2 次提交
  22. 14 10月, 2015 1 次提交
  23. 04 8月, 2015 1 次提交
  24. 17 7月, 2015 3 次提交
  25. 14 7月, 2015 1 次提交
  26. 07 7月, 2015 1 次提交
  27. 17 6月, 2015 4 次提交
  28. 09 6月, 2015 1 次提交
  29. 04 6月, 2015 2 次提交