1. 20 Nov, 2018 9 commits
    • Eric Biggers's avatar
      crypto: chacha - add XChaCha12 support · aa762409
      Eric Biggers authored
      Now that the generic implementation of ChaCha20 has been refactored to
      allow varying the number of rounds, add support for XChaCha12, which is
      the XSalsa construction applied to ChaCha12.  ChaCha12 is one of the
      three ciphers specified by the original ChaCha paper
      (https://cr.yp.to/chacha/chacha-20080128.pdf: "ChaCha, a variant of
      Salsa20"), alongside ChaCha8 and ChaCha20.  ChaCha12 is faster than
      ChaCha20 but has a lower, but still large, security margin.
      
      We need XChaCha12 support so that it can be used in the Adiantum
      encryption mode, which enables disk/file encryption on low-end mobile
      devices where AES-XTS is too slow as the CPUs lack AES instructions.
      
      We'd prefer XChaCha20 (the more popular variant), but it's too slow on
      some of our target devices, so at least in some cases we do need the
      XChaCha12-based version.  In more detail, the problem is that Adiantum
      is still much slower than we're happy with, and encryption still has a
      quite noticeable effect on the feel of low-end devices.  Users and
      vendors push back hard against encryption that degrades the user
      experience, which always risks encryption being disabled entirely.  So
      we need to choose the fastest option that gives us a solid margin of
      security, and here that's XChaCha12.  The best known attack on ChaCha
      breaks only 7 rounds and has 2^235 time complexity, so ChaCha12's
      security margin is still better than AES-256's.  Much has been learned
      about cryptanalysis of ARX ciphers since Salsa20 was originally designed
      in 2005, and it now seems we can be comfortable with a smaller number of
      rounds.  The eSTREAM project also suggests the 12-round version of
      Salsa20 as providing the best balance among the different variants:
      combining very good performance with a "comfortable margin of security".
      
      Note that it would be trivial to add vanilla ChaCha12 in addition to
      XChaCha12.  However, it's unneeded for now and therefore is omitted.
      
      As discussed in the patch that introduced XChaCha20 support, I
      considered splitting the code into separate chacha-common, chacha20,
      xchacha20, and xchacha12 modules, so that these algorithms could be
      enabled/disabled independently.  However, since nearly all the code is
      shared anyway, I ultimately decided there would have been little benefit
      to the added complexity.
      Reviewed-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: default avatarMartin Willi <martin@strongswan.org>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      aa762409
    • Eric Biggers's avatar
      crypto: chacha20-generic - refactor to allow varying number of rounds · 1ca1b917
      Eric Biggers authored
      In preparation for adding XChaCha12 support, rename/refactor
      chacha20-generic to support different numbers of rounds.  The
      justification for needing XChaCha12 support is explained in more detail
      in the patch "crypto: chacha - add XChaCha12 support".
      
      The only difference between ChaCha{8,12,20} are the number of rounds
      itself; all other parts of the algorithm are the same.  Therefore,
      remove the "20" from all definitions, structures, functions, files, etc.
      that will be shared by all ChaCha versions.
      
      Also make ->setkey() store the round count in the chacha_ctx (previously
      chacha20_ctx).  The generic code then passes the round count through to
      chacha_block().  There will be a ->setkey() function for each explicitly
      allowed round count; the encrypt/decrypt functions will be the same.  I
      decided not to do it the opposite way (same ->setkey() function for all
      round counts, with different encrypt/decrypt functions) because that
      would have required more boilerplate code in architecture-specific
      implementations of ChaCha and XChaCha.
      Reviewed-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: default avatarMartin Willi <martin@strongswan.org>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      1ca1b917
    • Eric Biggers's avatar
      crypto: chacha20-generic - add XChaCha20 support · de61d7ae
      Eric Biggers authored
      Add support for the XChaCha20 stream cipher.  XChaCha20 is the
      application of the XSalsa20 construction
      (https://cr.yp.to/snuffle/xsalsa-20081128.pdf) to ChaCha20 rather than
      to Salsa20.  XChaCha20 extends ChaCha20's nonce length from 64 bits (or
      96 bits, depending on convention) to 192 bits, while provably retaining
      ChaCha20's security.  XChaCha20 uses the ChaCha20 permutation to map the
      key and first 128 nonce bits to a 256-bit subkey.  Then, it does the
      ChaCha20 stream cipher with the subkey and remaining 64 bits of nonce.
      
      We need XChaCha support in order to add support for the Adiantum
      encryption mode.  Note that to meet our performance requirements, we
      actually plan to primarily use the variant XChaCha12.  But we believe
      it's wise to first add XChaCha20 as a baseline with a higher security
      margin, in case there are any situations where it can be used.
      Supporting both variants is straightforward.
      
      Since XChaCha20's subkey differs for each request, XChaCha20 can't be a
      template that wraps ChaCha20; that would require re-keying the
      underlying ChaCha20 for every request, which wouldn't be thread-safe.
      Instead, we make XChaCha20 its own top-level algorithm which calls the
      ChaCha20 streaming implementation internally.
      
      Similar to the existing ChaCha20 implementation, we define the IV to be
      the nonce and stream position concatenated together.  This allows users
      to seek to any position in the stream.
      
      I considered splitting the code into separate chacha20-common, chacha20,
      and xchacha20 modules, so that chacha20 and xchacha20 could be
      enabled/disabled independently.  However, since nearly all the code is
      shared anyway, I ultimately decided there would have been little benefit
      to the added complexity of separate modules.
      Reviewed-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: default avatarMartin Willi <martin@strongswan.org>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      de61d7ae
    • Eric Biggers's avatar
      crypto: chacha20-generic - don't unnecessarily use atomic walk · 5e04542a
      Eric Biggers authored
      chacha20-generic doesn't use SIMD instructions or otherwise disable
      preemption, so passing atomic=true to skcipher_walk_virt() is
      unnecessary.
      Suggested-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: default avatarMartin Willi <martin@strongswan.org>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      5e04542a
    • Eric Biggers's avatar
      crypto: chacha20-generic - add HChaCha20 library function · dd333449
      Eric Biggers authored
      Refactor the unkeyed permutation part of chacha20_block() into its own
      function, then add hchacha20_block() which is the ChaCha equivalent of
      HSalsa20 and is an intermediate step towards XChaCha20 (see
      https://cr.yp.to/snuffle/xsalsa-20081128.pdf).  HChaCha20 skips the
      final addition of the initial state, and outputs only certain words of
      the state.  It should not be used for streaming directly.
      Reviewed-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: default avatarMartin Willi <martin@strongswan.org>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      dd333449
    • Eric Biggers's avatar
      crypto: drop mask=CRYPTO_ALG_ASYNC from 'shash' tfm allocations · 3d234b33
      Eric Biggers authored
      'shash' algorithms are always synchronous, so passing CRYPTO_ALG_ASYNC
      in the mask to crypto_alloc_shash() has no effect.  Many users therefore
      already don't pass it, but some still do.  This inconsistency can cause
      confusion, especially since the way the 'mask' argument works is
      somewhat counterintuitive.
      
      Thus, just remove the unneeded CRYPTO_ALG_ASYNC flags.
      
      This patch shouldn't change any actual behavior.
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      3d234b33
    • Eric Biggers's avatar
      crypto: drop mask=CRYPTO_ALG_ASYNC from 'cipher' tfm allocations · 1ad0f160
      Eric Biggers authored
      'cipher' algorithms (single block ciphers) are always synchronous, so
      passing CRYPTO_ALG_ASYNC in the mask to crypto_alloc_cipher() has no
      effect.  Many users therefore already don't pass it, but some still do.
      This inconsistency can cause confusion, especially since the way the
      'mask' argument works is somewhat counterintuitive.
      
      Thus, just remove the unneeded CRYPTO_ALG_ASYNC flags.
      
      This patch shouldn't change any actual behavior.
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      1ad0f160
    • Eric Biggers's avatar
      crypto: remove useless initializations of cra_list · d4165590
      Eric Biggers authored
      Some algorithms initialize their .cra_list prior to registration.
      But this is unnecessary since crypto_register_alg() will overwrite
      .cra_list when adding the algorithm to the 'crypto_alg_list'.
      Apparently the useless assignment has just been copy+pasted around.
      
      So, remove the useless assignments.
      
      Exception: paes_s390.c uses cra_list to check whether the algorithm is
      registered or not, so I left that as-is for now.
      
      This patch shouldn't change any actual behavior.
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      d4165590
    • Eric Biggers's avatar
      crypto: inside-secure - remove useless setting of type flags · 2b78aeb3
      Eric Biggers authored
      Remove the unnecessary setting of CRYPTO_ALG_TYPE_SKCIPHER.
      Commit 2c95e6d9 ("crypto: skcipher - remove useless setting of type
      flags") took care of this everywhere else, but a few more instances made
      it into the tree at about the same time.  Squash them before they get
      copy+pasted around again.
      
      This patch shouldn't change any actual behavior.
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Acked-by: default avatarAntoine Tenart <antoine.tenart@bootlin.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      2b78aeb3
  2. 16 Nov, 2018 23 commits
  3. 09 Nov, 2018 8 commits