1. 20 Nov, 2018 4 commits
    • Eric Biggers's avatar
      crypto: adiantum - add Adiantum support · 059c2a4d
      Eric Biggers authored
      Add support for the Adiantum encryption mode.  Adiantum was designed by
      Paul Crowley and is specified by our paper:
      
          Adiantum: length-preserving encryption for entry-level processors
          (https://eprint.iacr.org/2018/720.pdf)
      
      See our paper for full details; this patch only provides an overview.
      
      Adiantum is a tweakable, length-preserving encryption mode designed for
      fast and secure disk encryption, especially on CPUs without dedicated
      crypto instructions.  Adiantum encrypts each sector using the XChaCha12
      stream cipher, two passes of an ε-almost-∆-universal (εA∆U) hash
      function, and an invocation of the AES-256 block cipher on a single
      16-byte block.  On CPUs without AES instructions, Adiantum is much
      faster than AES-XTS; for example, on ARM Cortex-A7, on 4096-byte sectors
      Adiantum encryption is about 4 times faster than AES-256-XTS encryption,
      and decryption about 5 times faster.
      
      Adiantum is a specialization of the more general HBSH construction.  Our
      earlier proposal, HPolyC, was also a HBSH specialization, but it used a
      different εA∆U hash function, one based on Poly1305 only.  Adiantum's
      εA∆U hash function, which is based primarily on the "NH" hash function
      like that used in UMAC (RFC4418), is about twice as fast as HPolyC's;
      consequently, Adiantum is about 20% faster than HPolyC.
      
      This speed comes with no loss of security: Adiantum is provably just as
      secure as HPolyC, in fact slightly *more* secure.  Like HPolyC,
      Adiantum's security is reducible to that of XChaCha12 and AES-256,
      subject to a security bound.  XChaCha12 itself has a security reduction
      to ChaCha12.  Therefore, one need not "trust" Adiantum; one need only
      trust ChaCha12 and AES-256.  Note that the εA∆U hash function is only
      used for its proven combinatorical properties so cannot be "broken".
      
      Adiantum is also a true wide-block encryption mode, so flipping any
      plaintext bit in the sector scrambles the entire ciphertext, and vice
      versa.  No other such mode is available in the kernel currently; doing
      the same with XTS scrambles only 16 bytes.  Adiantum also supports
      arbitrary-length tweaks and naturally supports any length input >= 16
      bytes without needing "ciphertext stealing".
      
      For the stream cipher, Adiantum uses XChaCha12 rather than XChaCha20 in
      order to make encryption feasible on the widest range of devices.
      Although the 20-round variant is quite popular, the best known attacks
      on ChaCha are on only 7 rounds, so ChaCha12 still has a substantial
      security margin; in fact, larger than AES-256's.  12-round Salsa20 is
      also the eSTREAM recommendation.  For the block cipher, Adiantum uses
      AES-256, despite it having a lower security margin than XChaCha12 and
      needing table lookups, due to AES's extensive adoption and analysis
      making it the obvious first choice.  Nevertheless, for flexibility this
      patch also permits the "adiantum" template to be instantiated with
      XChaCha20 and/or with an alternate block cipher.
      
      We need Adiantum support in the kernel for use in dm-crypt and fscrypt,
      where currently the only other suitable options are block cipher modes
      such as AES-XTS.  A big problem with this is that many low-end mobile
      devices (e.g. Android Go phones sold primarily in developing countries,
      as well as some smartwatches) still have CPUs that lack AES
      instructions, e.g. ARM Cortex-A7.  Sadly, AES-XTS encryption is much too
      slow to be viable on these devices.  We did find that some "lightweight"
      block ciphers are fast enough, but these suffer from problems such as
      not having much cryptanalysis or being too controversial.
      
      The ChaCha stream cipher has excellent performance but is insecure to
      use directly for disk encryption, since each sector's IV is reused each
      time it is overwritten.  Even restricting the threat model to offline
      attacks only isn't enough, since modern flash storage devices don't
      guarantee that "overwrites" are really overwrites, due to wear-leveling.
      Adiantum avoids this problem by constructing a
      "tweakable super-pseudorandom permutation"; this is the strongest
      possible security model for length-preserving encryption.
      
      Of course, storing random nonces along with the ciphertext would be the
      ideal solution.  But doing that with existing hardware and filesystems
      runs into major practical problems; in most cases it would require data
      journaling (like dm-integrity) which severely degrades performance.
      Thus, for now length-preserving encryption is still needed.
      Signed-off-by: 's avatarEric Biggers <ebiggers@google.com>
      Reviewed-by: 's avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      059c2a4d
    • Eric Biggers's avatar
      crypto: nhpoly1305 - add NHPoly1305 support · 26609a21
      Eric Biggers authored
      Add a generic implementation of NHPoly1305, an ε-almost-∆-universal hash
      function used in the Adiantum encryption mode.
      
      CONFIG_NHPOLY1305 is not selectable by itself since there won't be any
      real reason to enable it without also enabling Adiantum support.
      Signed-off-by: 's avatarEric Biggers <ebiggers@google.com>
      Acked-by: 's avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      26609a21
    • 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: 's avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: 's avatarMartin Willi <martin@strongswan.org>
      Signed-off-by: 's avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      aa762409
    • 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: 's avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: 's avatarMartin Willi <martin@strongswan.org>
      Signed-off-by: 's avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      de61d7ae
  2. 16 Nov, 2018 1 commit
  3. 09 Nov, 2018 2 commits
  4. 12 Oct, 2018 1 commit
  5. 28 Sep, 2018 1 commit
  6. 04 Sep, 2018 1 commit
  7. 08 Jul, 2018 1 commit
  8. 01 Jul, 2018 2 commits
    • Eric Biggers's avatar
      crypto: vmac - remove insecure version with hardcoded nonce · 0917b873
      Eric Biggers authored
      Remove the original version of the VMAC template that had the nonce
      hardcoded to 0 and produced a digest with the wrong endianness.  I'm
      unsure whether this had users or not (there are no explicit in-kernel
      references to it), but given that the hardcoded nonce made it wildly
      insecure unless a unique key was used for each message, let's try
      removing it and see if anyone complains.
      
      Leave the new "vmac64" template that requires the nonce to be explicitly
      specified as the first 16 bytes of data and uses the correct endianness
      for the digest.
      Signed-off-by: 's avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      0917b873
    • Eric Biggers's avatar
      crypto: vmac - add nonced version with big endian digest · ed331ada
      Eric Biggers authored
      Currently the VMAC template uses a "nonce" hardcoded to 0, which makes
      it insecure unless a unique key is set for every message.  Also, the
      endianness of the final digest is wrong: the implementation uses little
      endian, but the VMAC specification has it as big endian, as do other
      VMAC implementations such as the one in Crypto++.
      
      Add a new VMAC template where the nonce is passed as the first 16 bytes
      of data (similar to what is done for Poly1305's nonce), and the digest
      is big endian.  Call it "vmac64", since the old name of simply "vmac"
      didn't clarify whether the implementation is of VMAC-64 or of VMAC-128
      (which produce 64-bit and 128-bit digests respectively); so we fix the
      naming ambiguity too.
      Signed-off-by: 's avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      ed331ada
  9. 12 Jun, 2018 1 commit
    • Kees Cook's avatar
      treewide: kmalloc() -> kmalloc_array() · 6da2ec56
      Kees Cook authored
      The kmalloc() function has a 2-factor argument form, kmalloc_array(). This
      patch replaces cases of:
      
              kmalloc(a * b, gfp)
      
      with:
              kmalloc_array(a * b, gfp)
      
      as well as handling cases of:
      
              kmalloc(a * b * c, gfp)
      
      with:
      
              kmalloc(array3_size(a, b, c), gfp)
      
      as it's slightly less ugly than:
      
              kmalloc_array(array_size(a, b), c, gfp)
      
      This does, however, attempt to ignore constant size factors like:
      
              kmalloc(4 * 1024, gfp)
      
      though any constants defined via macros get caught up in the conversion.
      
      Any factors with a sizeof() of "unsigned char", "char", and "u8" were
      dropped, since they're redundant.
      
      The tools/ directory was manually excluded, since it has its own
      implementation of kmalloc().
      
      The Coccinelle script used for this was:
      
      // Fix redundant parens around sizeof().
      @@
      type TYPE;
      expression THING, E;
      @@
      
      (
        kmalloc(
      -	(sizeof(TYPE)) * E
      +	sizeof(TYPE) * E
        , ...)
      |
        kmalloc(
      -	(sizeof(THING)) * E
      +	sizeof(THING) * E
        , ...)
      )
      
      // Drop single-byte sizes and redundant parens.
      @@
      expression COUNT;
      typedef u8;
      typedef __u8;
      @@
      
      (
        kmalloc(
      -	sizeof(u8) * (COUNT)
      +	COUNT
        , ...)
      |
        kmalloc(
      -	sizeof(__u8) * (COUNT)
      +	COUNT
        , ...)
      |
        kmalloc(
      -	sizeof(char) * (COUNT)
      +	COUNT
        , ...)
      |
        kmalloc(
      -	sizeof(unsigned char) * (COUNT)
      +	COUNT
        , ...)
      |
        kmalloc(
      -	sizeof(u8) * COUNT
      +	COUNT
        , ...)
      |
        kmalloc(
      -	sizeof(__u8) * COUNT
      +	COUNT
        , ...)
      |
        kmalloc(
      -	sizeof(char) * COUNT
      +	COUNT
        , ...)
      |
        kmalloc(
      -	sizeof(unsigned char) * COUNT
      +	COUNT
        , ...)
      )
      
      // 2-factor product with sizeof(type/expression) and identifier or constant.
      @@
      type TYPE;
      expression THING;
      identifier COUNT_ID;
      constant COUNT_CONST;
      @@
      
      (
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(TYPE) * (COUNT_ID)
      +	COUNT_ID, sizeof(TYPE)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(TYPE) * COUNT_ID
      +	COUNT_ID, sizeof(TYPE)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(TYPE) * (COUNT_CONST)
      +	COUNT_CONST, sizeof(TYPE)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(TYPE) * COUNT_CONST
      +	COUNT_CONST, sizeof(TYPE)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(THING) * (COUNT_ID)
      +	COUNT_ID, sizeof(THING)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(THING) * COUNT_ID
      +	COUNT_ID, sizeof(THING)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(THING) * (COUNT_CONST)
      +	COUNT_CONST, sizeof(THING)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(THING) * COUNT_CONST
      +	COUNT_CONST, sizeof(THING)
        , ...)
      )
      
      // 2-factor product, only identifiers.
      @@
      identifier SIZE, COUNT;
      @@
      
      - kmalloc
      + kmalloc_array
        (
      -	SIZE * COUNT
      +	COUNT, SIZE
        , ...)
      
      // 3-factor product with 1 sizeof(type) or sizeof(expression), with
      // redundant parens removed.
      @@
      expression THING;
      identifier STRIDE, COUNT;
      type TYPE;
      @@
      
      (
        kmalloc(
      -	sizeof(TYPE) * (COUNT) * (STRIDE)
      +	array3_size(COUNT, STRIDE, sizeof(TYPE))
        , ...)
      |
        kmalloc(
      -	sizeof(TYPE) * (COUNT) * STRIDE
      +	array3_size(COUNT, STRIDE, sizeof(TYPE))
        , ...)
      |
        kmalloc(
      -	sizeof(TYPE) * COUNT * (STRIDE)
      +	array3_size(COUNT, STRIDE, sizeof(TYPE))
        , ...)
      |
        kmalloc(
      -	sizeof(TYPE) * COUNT * STRIDE
      +	array3_size(COUNT, STRIDE, sizeof(TYPE))
        , ...)
      |
        kmalloc(
      -	sizeof(THING) * (COUNT) * (STRIDE)
      +	array3_size(COUNT, STRIDE, sizeof(THING))
        , ...)
      |
        kmalloc(
      -	sizeof(THING) * (COUNT) * STRIDE
      +	array3_size(COUNT, STRIDE, sizeof(THING))
        , ...)
      |
        kmalloc(
      -	sizeof(THING) * COUNT * (STRIDE)
      +	array3_size(COUNT, STRIDE, sizeof(THING))
        , ...)
      |
        kmalloc(
      -	sizeof(THING) * COUNT * STRIDE
      +	array3_size(COUNT, STRIDE, sizeof(THING))
        , ...)
      )
      
      // 3-factor product with 2 sizeof(variable), with redundant parens removed.
      @@
      expression THING1, THING2;
      identifier COUNT;
      type TYPE1, TYPE2;
      @@
      
      (
        kmalloc(
      -	sizeof(TYPE1) * sizeof(TYPE2) * COUNT
      +	array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2))
        , ...)
      |
        kmalloc(
      -	sizeof(TYPE1) * sizeof(THING2) * (COUNT)
      +	array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2))
        , ...)
      |
        kmalloc(
      -	sizeof(THING1) * sizeof(THING2) * COUNT
      +	array3_size(COUNT, sizeof(THING1), sizeof(THING2))
        , ...)
      |
        kmalloc(
      -	sizeof(THING1) * sizeof(THING2) * (COUNT)
      +	array3_size(COUNT, sizeof(THING1), sizeof(THING2))
        , ...)
      |
        kmalloc(
      -	sizeof(TYPE1) * sizeof(THING2) * COUNT
      +	array3_size(COUNT, sizeof(TYPE1), sizeof(THING2))
        , ...)
      |
        kmalloc(
      -	sizeof(TYPE1) * sizeof(THING2) * (COUNT)
      +	array3_size(COUNT, sizeof(TYPE1), sizeof(THING2))
        , ...)
      )
      
      // 3-factor product, only identifiers, with redundant parens removed.
      @@
      identifier STRIDE, SIZE, COUNT;
      @@
      
      (
        kmalloc(
      -	(COUNT) * STRIDE * SIZE
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      |
        kmalloc(
      -	COUNT * (STRIDE) * SIZE
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      |
        kmalloc(
      -	COUNT * STRIDE * (SIZE)
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      |
        kmalloc(
      -	(COUNT) * (STRIDE) * SIZE
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      |
        kmalloc(
      -	COUNT * (STRIDE) * (SIZE)
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      |
        kmalloc(
      -	(COUNT) * STRIDE * (SIZE)
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      |
        kmalloc(
      -	(COUNT) * (STRIDE) * (SIZE)
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      |
        kmalloc(
      -	COUNT * STRIDE * SIZE
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      )
      
      // Any remaining multi-factor products, first at least 3-factor products,
      // when they're not all constants...
      @@
      expression E1, E2, E3;
      constant C1, C2, C3;
      @@
      
      (
        kmalloc(C1 * C2 * C3, ...)
      |
        kmalloc(
      -	(E1) * E2 * E3
      +	array3_size(E1, E2, E3)
        , ...)
      |
        kmalloc(
      -	(E1) * (E2) * E3
      +	array3_size(E1, E2, E3)
        , ...)
      |
        kmalloc(
      -	(E1) * (E2) * (E3)
      +	array3_size(E1, E2, E3)
        , ...)
      |
        kmalloc(
      -	E1 * E2 * E3
      +	array3_size(E1, E2, E3)
        , ...)
      )
      
      // And then all remaining 2 factors products when they're not all constants,
      // keeping sizeof() as the second factor argument.
      @@
      expression THING, E1, E2;
      type TYPE;
      constant C1, C2, C3;
      @@
      
      (
        kmalloc(sizeof(THING) * C2, ...)
      |
        kmalloc(sizeof(TYPE) * C2, ...)
      |
        kmalloc(C1 * C2 * C3, ...)
      |
        kmalloc(C1 * C2, ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(TYPE) * (E2)
      +	E2, sizeof(TYPE)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(TYPE) * E2
      +	E2, sizeof(TYPE)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(THING) * (E2)
      +	E2, sizeof(THING)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(THING) * E2
      +	E2, sizeof(THING)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	(E1) * E2
      +	E1, E2
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	(E1) * (E2)
      +	E1, E2
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	E1 * E2
      +	E1, E2
        , ...)
      )
      Signed-off-by: 's avatarKees Cook <keescook@chromium.org>
      6da2ec56
  10. 30 May, 2018 1 commit
    • Eric Biggers's avatar
      crypto: testmgr - eliminate redundant decryption test vectors · 92a4c9fe
      Eric Biggers authored
      Currently testmgr has separate encryption and decryption test vectors
      for symmetric ciphers.  That's massively redundant, since with few
      exceptions (mostly mistakes, apparently), all decryption tests are
      identical to the encryption tests, just with the input/result flipped.
      
      Therefore, eliminate the redundancy by removing the decryption test
      vectors and updating testmgr to test both encryption and decryption
      using what used to be the encryption test vectors.  Naming is adjusted
      accordingly: each cipher_testvec now has a 'ptext' (plaintext), 'ctext'
      (ciphertext), and 'len' instead of an 'input', 'result', 'ilen', and
      'rlen'.  Note that it was always the case that 'ilen == rlen'.
      
      AES keywrap ("kw(aes)") is special because its IV is generated by the
      encryption.  Previously this was handled by specifying 'iv_out' for
      encryption and 'iv' for decryption.  To make it work cleanly with only
      one set of test vectors, put the IV in 'iv', remove 'iv_out', and add a
      boolean that indicates that the IV is generated by the encryption.
      
      In total, this removes over 10000 lines from testmgr.h, with no
      reduction in test coverage since prior patches already copied the few
      unique decryption test vectors into the encryption test vectors.
      
      This covers all algorithms that used 'struct cipher_testvec', e.g. any
      block cipher in the ECB, CBC, CTR, XTS, LRW, CTS-CBC, PCBC, OFB, or
      keywrap modes, and Salsa20 and ChaCha20.  No change is made to AEAD
      tests, though we probably can eliminate a similar redundancy there too.
      
      The testmgr.h portion of this patch was automatically generated using
      the following awk script, with some slight manual fixups on top (updated
      'struct cipher_testvec' definition, updated a few comments, and fixed up
      the AES keywrap test vectors):
      
          BEGIN { OTHER = 0; ENCVEC = 1; DECVEC = 2; DECVEC_TAIL = 3; mode = OTHER }
      
          /^static const struct cipher_testvec.*_enc_/ { sub("_enc", ""); mode = ENCVEC }
          /^static const struct cipher_testvec.*_dec_/ { mode = DECVEC }
          mode == ENCVEC && !/\.ilen[[:space:]]*=/ {
          	sub(/\.input[[:space:]]*=$/,    ".ptext =")
          	sub(/\.input[[:space:]]*=/,     ".ptext\t=")
          	sub(/\.result[[:space:]]*=$/,   ".ctext =")
          	sub(/\.result[[:space:]]*=/,    ".ctext\t=")
          	sub(/\.rlen[[:space:]]*=/,      ".len\t=")
          	print
          }
          mode == DECVEC_TAIL && /[^[:space:]]/ { mode = OTHER }
          mode == OTHER                         { print }
          mode == ENCVEC && /^};/               { mode = OTHER }
          mode == DECVEC && /^};/               { mode = DECVEC_TAIL }
      
      Note that git's default diff algorithm gets confused by the testmgr.h
      portion of this patch, and reports too many lines added and removed.
      It's better viewed with 'git diff --minimal' (or 'git show --minimal'),
      which reports "2 files changed, 919 insertions(+), 11723 deletions(-)".
      Signed-off-by: 's avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      92a4c9fe
  11. 26 May, 2018 2 commits
    • Eric Biggers's avatar
      crypto: testmgr - fix testing OPTIONAL_KEY hash algorithms · 9b3abc01
      Eric Biggers authored
      Since testmgr uses a single tfm for all tests of each hash algorithm,
      once a key is set the tfm won't be unkeyed anymore.  But with crc32 and
      crc32c, the key is really the "default initial state" and is optional;
      those algorithms should have both keyed and unkeyed test vectors, to
      verify that implementations use the correct default key.
      
      Simply listing the unkeyed test vectors first isn't guaranteed to work
      yet because testmgr makes multiple passes through the test vectors.
      crc32c does have an unkeyed test vector listed first currently, but it
      only works by chance because the last crc32c test vector happens to use
      a key that is the same as the default key.
      
      Therefore, teach testmgr to split hash test vectors into unkeyed and
      keyed sections, and do all the unkeyed ones before the keyed ones.
      Signed-off-by: 's avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      9b3abc01
    • Eric Biggers's avatar
      crypto: testmgr - remove bfin_crc "hmac(crc32)" test vectors · a179a2bf
      Eric Biggers authored
      The Blackfin CRC driver was removed by commit 9678a8dc ("crypto:
      bfin_crc - remove blackfin CRC driver"), but it was forgotten to remove
      the corresponding "hmac(crc32)" test vectors.  I see no point in keeping
      them since nothing else appears to implement or use "hmac(crc32)", which
      isn't an algorithm that makes sense anyway because HMAC is meant to be
      used with a cryptographically secure hash function, which CRC's are not.
      
      Thus, remove the unneeded test vectors.
      Signed-off-by: 's avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      a179a2bf
  12. 18 May, 2018 3 commits
  13. 05 May, 2018 1 commit
    • Gilad Ben-Yossef's avatar
      crypto: ccree - enable support for hardware keys · a794d8d8
      Gilad Ben-Yossef authored
      Enable CryptoCell support for hardware keys.
      
      Hardware keys are regular AES keys loaded into CryptoCell internal memory
      via firmware, often from secure boot ROM or hardware fuses at boot time.
      
      As such, they can be used for enc/dec purposes like any other key but
      cannot (read: extremely hard to) be extracted since since they are not
      available anywhere in RAM during runtime.
      
      The mechanism has some similarities to s390 secure keys although the keys
      are not wrapped or sealed, but simply loaded offline. The interface was
      therefore modeled based on the s390 secure keys support.
      Signed-off-by: 's avatarGilad Ben-Yossef <gilad@benyossef.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      a794d8d8
  14. 20 Apr, 2018 2 commits
    • Mahipal Challa's avatar
      crypto: testmgr - Allow different compression results · 33607384
      Mahipal Challa authored
      The following error is triggered by the ThunderX ZIP driver
      if the testmanager is enabled:
      
      [  199.069437] ThunderX-ZIP 0000:03:00.0: Found ZIP device 0 177d:a01a on Node 0
      [  199.073573] alg: comp: Compression test 1 failed for deflate-generic: output len = 37
      
      The reason for this error is the verification of the compression
      results. Verifying the compression result only works if all
      algorithm parameters are identical, in this case to the software
      implementation.
      
      Different compression engines like the ThunderX ZIP coprocessor
      might yield different compression results by tuning the
      algorithm parameters. In our case the compressed result is
      shorter than the test vector.
      
      We should not forbid different compression results but only
      check that compression -> decompression yields the same
      result. This is done already in the acomp test. Do something
      similar for test_comp().
      Signed-off-by: 's avatarMahipal Challa <mchalla@cavium.com>
      Signed-off-by: 's avatarBalakrishna Bhamidipati <bbhamidipati@cavium.com>
      [jglauber@cavium.com: removed unrelated printk changes, rewrote commit msg,
       fixed whitespace and unneeded initialization]
      Signed-off-by: 's avatarJan Glauber <jglauber@cavium.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      33607384
    • Nick Terrell's avatar
      crypto: zstd - Add zstd support · d28fc3db
      Nick Terrell authored
      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: 's avatarNick Terrell <terrelln@fb.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      d28fc3db
  15. 16 Mar, 2018 1 commit
  16. 22 Feb, 2018 3 commits
    • 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: 's avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: 's 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: 's avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      c3bb521b
    • 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: 's avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      da7a0ab5
  17. 25 Jan, 2018 1 commit
  18. 12 Jan, 2018 1 commit
  19. 03 Nov, 2017 1 commit
  20. 22 Sep, 2017 1 commit
  21. 28 Jun, 2017 1 commit
  22. 20 Jun, 2017 1 commit
  23. 19 Jun, 2017 1 commit
  24. 10 Jun, 2017 1 commit
  25. 24 Apr, 2017 2 commits
  26. 21 Apr, 2017 1 commit
  27. 24 Mar, 2017 1 commit
  28. 09 Mar, 2017 1 commit