1. 13 Dec, 2018 1 commit
  2. 20 Nov, 2018 1 commit
    • 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
      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: default avatarEric Biggers <ebiggers@google.com>
      Reviewed-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
  3. 16 Nov, 2018 1 commit
  4. 09 Nov, 2018 1 commit
  5. 28 Sep, 2018 3 commits
  6. 21 Sep, 2018 1 commit
  7. 03 Aug, 2018 1 commit
  8. 01 Jul, 2018 1 commit
    • 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: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
  9. 26 May, 2018 1 commit
  10. 05 May, 2018 1 commit
  11. 16 Mar, 2018 1 commit
  12. 12 Jan, 2018 2 commits
  13. 28 Dec, 2017 6 commits
  14. 29 Nov, 2017 2 commits
  15. 03 Nov, 2017 3 commits
  16. 22 Sep, 2017 2 commits
  17. 03 Aug, 2017 1 commit
  18. 18 May, 2017 1 commit
  19. 23 Jan, 2017 1 commit
    • Rabin Vincent's avatar
      crypto: tcrypt - Add debug prints · 76512f2d
      Rabin Vincent authored
      tcrypt is very tight-lipped when it succeeds, but a bit more feedback
      would be useful when developing or debugging crypto drivers, especially
      since even a successful run ends with the module failing to insert. Add
      a couple of debug prints, which can be enabled with dynamic debug:
       # insmod tcrypt.ko mode=10
       insmod: can't insert 'tcrypt.ko': Resource temporarily unavailable
       # insmod tcrypt.ko mode=10 dyndbg
       tcrypt: testing ecb(aes)
       tcrypt: testing cbc(aes)
       tcrypt: testing lrw(aes)
       tcrypt: testing xts(aes)
       tcrypt: testing ctr(aes)
       tcrypt: testing rfc3686(ctr(aes))
       tcrypt: all tests passed
       insmod: can't insert 'tcrypt.ko': Resource temporarily unavailable
      Signed-off-by: default avatarRabin Vincent <rabinv@axis.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
  20. 01 Jul, 2016 4 commits
  21. 29 Jun, 2016 1 commit
  22. 28 Jun, 2016 3 commits
  23. 27 Jun, 2016 1 commit