1. 02 Mar, 2018 27 commits
  2. 22 Feb, 2018 13 commits
    • Fengguang Wu's avatar
      crypto: ccree - fix memdup.cocci warnings · 01745706
      Fengguang Wu authored
      drivers/crypto/ccree/cc_cipher.c:629:15-22: WARNING opportunity for kmemdep
      
       Use kmemdup rather than duplicating its implementation
      
      Generated by: scripts/coccinelle/api/memdup.cocci
      
      Fixes: 63ee04c8 ("crypto: ccree - add skcipher support")
      CC: Gilad Ben-Yossef <gilad@benyossef.com>
      Signed-off-by: default avatarFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      01745706
    • Markus Elfring's avatar
      crypto: atmel - Delete error messages for a failed memory allocation in six functions · 02684839
      Markus Elfring authored
      Omit extra messages for a memory allocation failure in these functions.
      
      This issue was detected by using the Coccinelle software.
      Signed-off-by: default avatarMarkus Elfring <elfring@users.sourceforge.net>
      Reviewed-by: default avatarTudor Ambarus <tudor.ambarus@microchip.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      02684839
    • Markus Elfring's avatar
      crypto: bcm - Delete an error message for a failed memory allocation in do_shash() · 72e8d3f8
      Markus Elfring authored
      Omit an extra message for a memory allocation failure in this function.
      
      This issue was detected by using the Coccinelle software.
      Signed-off-by: default avatarMarkus Elfring <elfring@users.sourceforge.net>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      72e8d3f8
    • Markus Elfring's avatar
      crypto: bfin_crc - Delete an error message for a failed memory allocation in... · 5471f2e2
      Markus Elfring authored
      crypto: bfin_crc - Delete an error message for a failed memory allocation in bfin_crypto_crc_probe()
      
      Omit an extra message for a memory allocation failure in this function.
      
      This issue was detected by using the Coccinelle software.
      Signed-off-by: default avatarMarkus Elfring <elfring@users.sourceforge.net>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      5471f2e2
    • Eric Biggers's avatar
      crypto: speck - add test vectors for Speck64-XTS · 41b3316e
      Eric Biggers authored
      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: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      41b3316e
    • Eric Biggers's avatar
      crypto: speck - add test vectors for Speck128-XTS · c3bb521b
      Eric Biggers authored
      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: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      c3bb521b
    • Eric Biggers's avatar
      crypto: arm/speck - add NEON-accelerated implementation of Speck-XTS · ede96221
      Eric Biggers authored
      Add an ARM NEON-accelerated implementation of Speck-XTS.  It operates on
      128-byte chunks at a time, i.e. 8 blocks for Speck128 or 16 blocks for
      Speck64.  Each 128-byte chunk goes through XTS preprocessing, then is
      encrypted/decrypted (doing one cipher round for all the blocks, then the
      next round, etc.), then goes through XTS postprocessing.
      
      The performance depends on the processor but can be about 3 times faster
      than the generic code.  For example, on an ARMv7 processor we observe
      the following performance with Speck128/256-XTS:
      
          xts-speck128-neon:     Encryption 107.9 MB/s, Decryption 108.1 MB/s
          xts(speck128-generic): Encryption  32.1 MB/s, Decryption  36.6 MB/s
      
      In comparison to AES-256-XTS without the Cryptography Extensions:
      
          xts-aes-neonbs:        Encryption  41.2 MB/s, Decryption  36.7 MB/s
          xts(aes-asm):          Encryption  31.7 MB/s, Decryption  30.8 MB/s
          xts(aes-generic):      Encryption  21.2 MB/s, Decryption  20.9 MB/s
      
      Speck64/128-XTS is even faster:
      
          xts-speck64-neon:      Encryption 138.6 MB/s, Decryption 139.1 MB/s
      
      Note that as with the generic code, only the Speck128 and Speck64
      variants are supported.  Also, for now only the XTS mode of operation is
      supported, to target the disk and file encryption use cases.  The NEON
      code also only handles the portion of the data that is evenly divisible
      into 128-byte chunks, with any remainder handled by a C fallback.  Of
      course, other modes of operation could be added later if needed, and/or
      the NEON code could be updated to handle other buffer sizes.
      
      The XTS specification is only defined for AES which has a 128-bit block
      size, so for the GF(2^64) math needed for Speck64-XTS we use the
      reducing polynomial 'x^64 + x^4 + x^3 + x + 1' given by the original XEX
      paper.  Of course, when possible users should use Speck128-XTS, but even
      that may be too slow on some processors; Speck64-XTS can be faster.
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      ede96221
    • Eric Biggers's avatar
      crypto: speck - export common helpers · c8c36413
      Eric Biggers authored
      Export the Speck constants and transform context and the ->setkey(),
      ->encrypt(), and ->decrypt() functions so that they can be reused by the
      ARM NEON implementation of Speck-XTS.  The generic key expansion code
      will be reused because it is not performance-critical and is not
      vectorizable, while the generic encryption and decryption functions are
      needed as fallbacks and for the XTS tweak encryption.
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      c8c36413
    • Eric Biggers's avatar
      crypto: speck - add support for the Speck block cipher · da7a0ab5
      Eric Biggers authored
      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: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      da7a0ab5
    • Dave Watson's avatar
      crypto: aesni - Update aesni-intel_glue to use scatter/gather · e8455207
      Dave Watson authored
      Add gcmaes_crypt_by_sg routine, that will do scatter/gather
      by sg. Either src or dst may contain multiple buffers, so
      iterate over both at the same time if they are different.
      If the input is the same as the output, iterate only over one.
      
      Currently both the AAD and TAG must be linear, so copy them out
      with scatterlist_map_and_copy.  If first buffer contains the
      entire AAD, we can optimize and not copy.   Since the AAD
      can be any size, if copied it must be on the heap.  TAG can
      be on the stack since it is always < 16 bytes.
      
      Only the SSE routines are updated so far, so leave the previous
      gcmaes_en/decrypt routines, and branch to the sg ones if the
      keysize is inappropriate for avx, or we are SSE only.
      Signed-off-by: default avatarDave Watson <davejwatson@fb.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      e8455207
    • Dave Watson's avatar
      crypto: aesni - Introduce scatter/gather asm function stubs · fb8986e6
      Dave Watson authored
      The asm macros are all set up now, introduce entry points.
      
      GCM_INIT and GCM_COMPLETE have arguments supplied, so that
      the new scatter/gather entry points don't have to take all the
      arguments, and only the ones they need.
      Signed-off-by: default avatarDave Watson <davejwatson@fb.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      fb8986e6
    • Dave Watson's avatar
      crypto: aesni - Add fast path for > 16 byte update · 933d6aef
      Dave Watson authored
      We can fast-path any < 16 byte read if the full message is > 16 bytes,
      and shift over by the appropriate amount.  Usually we are
      reading > 16 bytes, so this should be faster than the READ_PARTIAL
      macro introduced in b20209c9 for the average case.
      Signed-off-by: default avatarDave Watson <davejwatson@fb.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      933d6aef
    • Dave Watson's avatar
      crypto: aesni - Introduce partial block macro · ae952c5e
      Dave Watson authored
      Before this diff, multiple calls to GCM_ENC_DEC will
      succeed, but only if all calls are a multiple of 16 bytes.
      
      Handle partial blocks at the start of GCM_ENC_DEC, and update
      aadhash as appropriate.
      
      The data offset %r11 is also updated after the partial block.
      Signed-off-by: default avatarDave Watson <davejwatson@fb.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      ae952c5e