1. 01 Feb, 2016 1 commit
  2. 30 Jan, 2016 1 commit
  3. 27 Jan, 2016 1 commit
  4. 09 Dec, 2015 1 commit
    • Andrzej Zaborowski's avatar
      crypto: rsa - RSA padding algorithm · 3d5b1ecd
      Andrzej Zaborowski authored
      This patch adds PKCS#1 v1.5 standard RSA padding as a separate template.
      This way an RSA cipher with padding can be obtained by instantiating
      "pkcs1pad(rsa)".  The reason for adding this is that RSA is almost
      never used without this padding (or OAEP) so it will be needed for
      either certificate work in the kernel or the userspace, and I also hear
      that it is likely implemented by hardware RSA in which case hardware
      implementations of the whole of pkcs1pad(rsa) can be provided.
      Signed-off-by: default avatarAndrew Zaborowski <andrew.zaborowski@intel.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      3d5b1ecd
  5. 15 Oct, 2015 1 commit
  6. 14 Oct, 2015 1 commit
  7. 21 Aug, 2015 1 commit
    • Herbert Xu's avatar
      crypto: skcipher - Add top-level skcipher interface · 7a7ffe65
      Herbert Xu authored
      This patch introduces the crypto skcipher interface which aims
      to replace both blkcipher and ablkcipher.
      
      It's very similar to the existing ablkcipher interface.  The
      main difference is the removal of the givcrypt interface.  In
      order to make the transition easier for blkcipher users, there
      is a helper SKCIPHER_REQUEST_ON_STACK which can be used to place
      a request on the stack for synchronous transforms.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      7a7ffe65
  8. 17 Aug, 2015 1 commit
  9. 25 Jun, 2015 1 commit
    • Stephan Mueller's avatar
      crypto: jitterentropy - avoid compiler warnings · dfc9fa91
      Stephan Mueller authored
      The core of the Jitter RNG is intended to be compiled with -O0. To
      ensure that the Jitter RNG can be compiled on all architectures,
      separate out the RNG core into a stand-alone C file that can be compiled
      with -O0 which does not depend on any kernel include file.
      
      As no kernel includes can be used in the C file implementing the core
      RNG, any dependencies on kernel code must be extracted.
      
      A second file provides the link to the kernel and the kernel crypto API
      that can be compiled with the regular compile options of the kernel.
      Signed-off-by: default avatarStephan Mueller <smueller@chronox.de>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      dfc9fa91
  10. 17 Jun, 2015 2 commits
  11. 09 Jun, 2015 1 commit
  12. 04 Jun, 2015 4 commits
  13. 27 May, 2015 1 commit
    • Stephan Mueller's avatar
      crypto: jitterentropy - add jitterentropy RNG · bb5530e4
      Stephan Mueller authored
      The CPU Jitter RNG provides a source of good entropy by
      collecting CPU executing time jitter. The entropy in the CPU
      execution time jitter is magnified by the CPU Jitter Random
      Number Generator. The CPU Jitter Random Number Generator uses
      the CPU execution timing jitter to generate a bit stream
      which complies with different statistical measurements that
      determine the bit stream is random.
      
      The CPU Jitter Random Number Generator delivers entropy which
      follows information theoretical requirements. Based on these
      studies and the implementation, the caller can assume that
      one bit of data extracted from the CPU Jitter Random Number
      Generator holds one bit of entropy.
      
      The CPU Jitter Random Number Generator provides a decentralized
      source of entropy, i.e. every caller can operate on a private
      state of the entropy pool.
      
      The RNG does not have any dependencies on any other service
      in the kernel. The RNG only needs a high-resolution time
      stamp.
      
      Further design details, the cryptographic assessment and
      large array of test results are documented at
      http://www.chronox.de/jent.html.
      
      CC: Andreas Steffen <andreas.steffen@strongswan.org>
      CC: Theodore Ts'o <tytso@mit.edu>
      CC: Sandy Harris <sandyinchina@gmail.com>
      Signed-off-by: default avatarStephan Mueller <smueller@chronox.de>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      bb5530e4
  14. 21 May, 2015 1 commit
    • Herbert Xu's avatar
      crypto: echainiv - Add encrypted chain IV generator · a10f554f
      Herbert Xu authored
      This patch adds a new AEAD IV generator echainiv.  It is intended
      to replace the existing skcipher IV generator eseqiv.
      
      If the underlying AEAD algorithm is using the old AEAD interface,
      then echainiv will simply use its IV generator.
      
      Otherwise, echainiv will encrypt a counter just like eseqiv but
      it'll first xor it against a previously stored IV similar to
      chainiv.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      a10f554f
  15. 04 Mar, 2015 1 commit
  16. 29 Dec, 2014 1 commit
  17. 25 Aug, 2014 1 commit
    • Tim Chen's avatar
      crypto: sha-mb - multibuffer crypto infrastructure · 1e65b81a
      Tim Chen authored
      This patch introduces the multi-buffer crypto daemon which is responsible
      for submitting crypto jobs in a work queue to the responsible multi-buffer
      crypto algorithm.  The idea of the multi-buffer algorihtm is to put
      data streams from multiple jobs in a wide (AVX2) register and then
      take advantage of SIMD instructions to do crypto computation on several
      buffers simultaneously.
      
      The multi-buffer crypto daemon is also responsbile for flushing the
      remaining buffers to complete the computation if no new buffers arrive
      for a while.
      Signed-off-by: default avatarTim Chen <tim.c.chen@linux.intel.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      1e65b81a
  18. 04 Jul, 2014 1 commit
  19. 20 Jun, 2014 1 commit
  20. 25 Feb, 2014 1 commit
  21. 05 Dec, 2013 1 commit
    • Cesar Eduardo Barros's avatar
      crypto: more robust crypto_memneq · fe8c8a12
      Cesar Eduardo Barros authored
      Disabling compiler optimizations can be fragile, since a new
      optimization could be added to -O0 or -Os that breaks the assumptions
      the code is making.
      
      Instead of disabling compiler optimizations, use a dummy inline assembly
      (based on RELOC_HIDE) to block the problematic kinds of optimization,
      while still allowing other optimizations to be applied to the code.
      
      The dummy inline assembly is added after every OR, and has the
      accumulator variable as its input and output. The compiler is forced to
      assume that the dummy inline assembly could both depend on the
      accumulator variable and change the accumulator variable, so it is
      forced to compute the value correctly before the inline assembly, and
      cannot assume anything about its value after the inline assembly.
      
      This change should be enough to make crypto_memneq work correctly (with
      data-independent timing) even if it is inlined at its call sites. That
      can be done later in a followup patch.
      
      Compile-tested on x86_64.
      Signed-off-by: default avatarCesar Eduardo Barros <cesarb@cesarb.eti.br>
      Acked-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      fe8c8a12
  22. 25 Oct, 2013 1 commit
  23. 07 Oct, 2013 1 commit
    • James Yonan's avatar
      crypto: crypto_memneq - add equality testing of memory regions w/o timing leaks · 6bf37e5a
      James Yonan authored
      When comparing MAC hashes, AEAD authentication tags, or other hash
      values in the context of authentication or integrity checking, it
      is important not to leak timing information to a potential attacker,
      i.e. when communication happens over a network.
      
      Bytewise memory comparisons (such as memcmp) are usually optimized so
      that they return a nonzero value as soon as a mismatch is found. E.g,
      on x86_64/i5 for 512 bytes this can be ~50 cyc for a full mismatch
      and up to ~850 cyc for a full match (cold). This early-return behavior
      can leak timing information as a side channel, allowing an attacker to
      iteratively guess the correct result.
      
      This patch adds a new method crypto_memneq ("memory not equal to each
      other") to the crypto API that compares memory areas of the same length
      in roughly "constant time" (cache misses could change the timing, but
      since they don't reveal information about the content of the strings
      being compared, they are effectively benign). Iow, best and worst case
      behaviour take the same amount of time to complete (in contrast to
      memcmp).
      
      Note that crypto_memneq (unlike memcmp) can only be used to test for
      equality or inequality, NOT for lexicographical order. This, however,
      is not an issue for its use-cases within the crypto API.
      
      We tried to locate all of the places in the crypto API where memcmp was
      being used for authentication or integrity checking, and convert them
      over to crypto_memneq.
      
      crypto_memneq is declared noinline, placed in its own source file,
      and compiled with optimizations that might increase code size disabled
      ("Os") because a smart compiler (or LTO) might notice that the return
      value is always compared against zero/nonzero, and might then
      reintroduce the same early-return optimization that we are trying to
      avoid.
      
      Using #pragma or __attribute__ optimization annotations of the code
      for disabling optimization was avoided as it seems to be considered
      broken or unmaintained for long time in GCC [1]. Therefore, we work
      around that by specifying the compile flag for memneq.o directly in
      the Makefile. We found that this seems to be most appropriate.
      
      As we use ("Os"), this patch also provides a loop-free "fast-path" for
      frequently used 16 byte digests. Similarly to kernel library string
      functions, leave an option for future even further optimized architecture
      specific assembler implementations.
      
      This was a joint work of James Yonan and Daniel Borkmann. Also thanks
      for feedback from Florian Weimer on this and earlier proposals [2].
      
        [1] http://gcc.gnu.org/ml/gcc/2012-07/msg00211.html
        [2] https://lkml.org/lkml/2013/2/10/131Signed-off-by: default avatarJames Yonan <james@openvpn.net>
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Cc: Florian Weimer <fw@deneb.enyo.de>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      6bf37e5a
  24. 23 Sep, 2013 1 commit
  25. 11 Sep, 2013 1 commit
    • Herbert Xu's avatar
      crypto: crct10dif - Add fallback for broken initrds · 26052f9b
      Herbert Xu authored
      Unfortunately, even with a softdep some distros fail to include
      the necessary modules in the initrd.  Therefore this patch adds
      a fallback path to restore existing behaviour where we cannot
      load the new crypto crct10dif algorithm.
      
      In order to do this, the underlying crct10dif has been split out
      from the crypto implementation so that it can be used on the
      fallback path.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      26052f9b
  26. 06 Sep, 2013 1 commit
  27. 24 Jul, 2013 1 commit
  28. 09 Jul, 2013 1 commit
  29. 20 May, 2013 1 commit
  30. 25 Apr, 2013 1 commit
  31. 19 Jan, 2013 1 commit
  32. 06 Dec, 2012 1 commit
  33. 07 Oct, 2012 1 commit
    • David Howells's avatar
      KEYS: Implement asymmetric key type · 964f3b3b
      David Howells authored
      Create a key type that can be used to represent an asymmetric key type for use
      in appropriate cryptographic operations, such as encryption, decryption,
      signature generation and signature verification.
      
      The key type is "asymmetric" and can provide access to a variety of
      cryptographic algorithms.
      
      Possibly, this would be better as "public_key" - but that has the disadvantage
      that "public key" is an overloaded term.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      964f3b3b
  34. 01 Aug, 2012 3 commits