1. 31 3月, 2018 3 次提交
    • H
      crypto: api - Keep failed instances alive · eb02c38f
      Herbert Xu 提交于
      This patch reverts commit 9c521a20 ("crypto: api - remove
      instance when test failed") and fixes the underlying problem
      in a different way.
      
      To recap, prior to the reverted commit, an instance that fails
      a self-test is kept around.  However, it would satisfy any new
      lookups against its name and therefore the system may accumlulate
      an unbounded number of failed instances for the same algorithm
      name.
      
      The reverted commit fixed it by unregistering the instance.  Hoever,
      this still does not prevent the creation of the same failed instance
      over and over again each time the name is looked up.
      
      This patch fixes it by keeping the failed instance around, just as
      we would if it were a normal algorithm.  However, the lookup code
      has been udpated so that we do not attempt to create another
      instance as long as this failed one is still registered.  Of course,
      you could still force a new creation by deleting the instance from
      user-space.
      
      A new error (ELIBBAD) has been commandeered for this purpose and
      will be returned when all registered algorithm of a given name
      have failed the self-test.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      eb02c38f
    • H
      crypto: api - Make crypto_alg_lookup static · 3ca1e994
      Herbert Xu 提交于
      The function crypto_alg_lookup is only usd within the crypto API
      and should be not be exported to the modules.  This patch marks
      it as a static function.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      3ca1e994
    • H
      crypto: api - Remove unused crypto_type lookup function · 4989d4f0
      Herbert Xu 提交于
      The lookup function in crypto_type was only used for the implicit
      IV generators which have been completely removed from the crypto
      API.
      
      This patch removes the lookup function as it is now useless.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      4989d4f0
  2. 16 3月, 2018 4 次提交
  3. 09 3月, 2018 2 次提交
  4. 03 3月, 2018 26 次提交
  5. 22 2月, 2018 5 次提交
    • 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 - export common helpers · c8c36413
      Eric Biggers 提交于
      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: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      c8c36413
    • 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