Skip to content
Snippets Groups Projects
Select Git revision
0 results
Search by author
  • Any Author
0 authors
  1. Jun 04, 2015
  3. Jun 03, 2015
  5. May 27, 2015
    • 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
  7. May 26, 2015
  9. May 22, 2015
    • 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
    • Herbert Xu's avatar
      crypto: seqiv - Add support for new AEAD interface · 856e3f40
      Herbert Xu authored 
      
This patch converts the seqiv IV generator to work with the new
AEAD interface where IV generators are just normal AEAD algorithms.

Full backwards compatibility is paramount at this point since
no users have yet switched over to the new interface.  Nor can
they switch to the new interface until IV generation is fully
supported by it.

So this means we are adding two versions of seqiv alongside the
existing one.  The first one is the one that will be used when
the underlying AEAD algorithm has switched over to the new AEAD
interface.  The second one handles the current case where the
underlying AEAD algorithm still uses the old interface.

Both versions export themselves through the new AEAD interface.

Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      856e3f40
  11. May 11, 2015
    • Dan Streetman's avatar
      crypto: 842 - change 842 alg to use software · 2062c5b6
      Dan Streetman authored 
      
Change the crypto 842 compression alg to use the software 842 compression
and decompression library.  Add the crypto driver_name as "842-generic".
Remove the fallback to LZO compression.

Previously, this crypto compression alg attemped 842 compression using
PowerPC hardware, and fell back to LZO compression and decompression if
the 842 PowerPC hardware was unavailable or failed.  This should not
fall back to any other compression method, however; users of this crypto
compression alg can fallback if desired, and transparent fallback tricks
callers into thinking they are getting 842 compression when they actually
get LZO compression - the failure of the 842 hardware should not be
transparent to the caller.

The crypto compression alg for a hardware device also should not be located
in crypto/ so this is now a software-only implementation that uses the 842
software compression/decompression library.

Signed-off-by: default avatarDan Streetman <ddstreet@ieee.org>
Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      2062c5b6
  13. Apr 07, 2015
  15. Mar 12, 2015
  17. Mar 10, 2015
  19. Mar 04, 2015
  21. Mar 02, 2015
  23. Mar 01, 2015
  25. Feb 27, 2015
  27. Dec 29, 2014
  29. Dec 23, 2014
  31. Sep 04, 2014
  33. Aug 27, 2014
  35. Aug 25, 2014
    • 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
  37. Aug 02, 2014
  39. Jul 04, 2014
  41. Jul 03, 2014
    • Jarod Wilson's avatar
      crypto: fips - only panic on bad/missing crypto mod signatures · 002c77a4
      Jarod Wilson authored 
      
Per further discussion with NIST, the requirements for FIPS state that
we only need to panic the system on failed kernel module signature checks
for crypto subsystem modules. This moves the fips-mode-only module
signature check out of the generic module loading code, into the crypto
subsystem, at points where we can catch both algorithm module loads and
mode module loads. At the same time, make CONFIG_CRYPTO_FIPS dependent on
CONFIG_MODULE_SIG, as this is entirely necessary for FIPS mode.

v2: remove extraneous blank line, perform checks in static inline
function, drop no longer necessary fips.h include.

CC: "David S. Miller" <davem@davemloft.net>
CC: Rusty Russell <rusty@rustcorp.com.au>
CC: Stephan Mueller <stephan.mueller@atsec.com>
Signed-off-by: default avatarJarod Wilson <jarod@redhat.com>
Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      002c77a4
  43. Jun 20, 2014
  45. Mar 21, 2014
    • chandramouli narayanan's avatar
      crypto: sha - SHA1 transform x86_64 AVX2 · 7c1da8d0
      chandramouli narayanan authored 
      
This git patch adds x86_64 AVX2 optimization of SHA1
transform to crypto support. The patch has been tested with 3.14.0-rc1
kernel.

On a Haswell desktop, with turbo disabled and all cpus running
at maximum frequency, tcrypt shows AVX2 performance improvement
from 3% for 256 bytes update to 16% for 1024 bytes update over
AVX implementation.

This patch adds sha1_avx2_transform(), the glue, build and
configuration changes needed for AVX2 optimization of
SHA1 transform to crypto support.

sha1-ssse3 is one module which adds the necessary optimization
support (SSSE3/AVX/AVX2) for the low-level SHA1 transform function.
With better optimization support, transform function is overridden
as the case may be. In the case of AVX2, due to performance reasons
across datablock sizes, the AVX or AVX2 transform function is used
at run-time as it suits best. The Makefile change therefore appends
the necessary objects to the linkage. Due to this, the patch merely
appends AVX2 transform to the existing build mix and Kconfig support
and leaves the configuration build support as is.

Signed-off-by: default avatarChandramouli Narayanan <mouli@linux.intel.com>
Reviewed-by: default avatarMarek Vasut <marex@denx.de>
Acked-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      7c1da8d0
  47. Oct 25, 2013
  49. Oct 04, 2013
    • Ard Biesheuvel's avatar
      ARM: add support for bit sliced AES using NEON instructions · e4e7f10b
      Ard Biesheuvel authored 
      Bit sliced AES gives around 45% speedup on Cortex-A15 for encryption
and around 25% for decryption. This implementation of the AES algorithm
does not rely on any lookup tables so it is believed to be invulnerable
to cache timing attacks.

This algorithm processes up to 8 blocks in parallel in constant time. This
means that it is not usable by chaining modes that are strictly sequential
in nature, such as CBC encryption. CBC decryption, however, can benefit from
this implementation and runs about 25% faster. The other chaining modes
implemented in this module, XTS and CTR, can execute fully in parallel in
both directions.

The core code has been adopted from the OpenSSL project (in collaboration
with the original author, on cc). For ease of maintenance, this version is
identical to the upstream OpenSSL code, i.e., all modifications that were
required to make it suitable for inclusion into the kernel have been made
upstream. The original can be found here:

    http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=6f6a6130



Note to integrators:
While this implementation is significantly faster than the existing table
based ones (generic or ARM asm), especially in CTR mode, the effects on
power efficiency are unclear as of yet. This code does fundamentally more
work, by calculating values that the table based code obtains by a simple
lookup; only by doing all of that work in a SIMD fashion, it manages to
perform better.

Cc: Andy Polyakov <appro@openssl.org>
Acked-by: default avatarNicolas Pitre <nico@linaro.org>
Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      e4e7f10b
  51. Sep 23, 2013
  53. Sep 07, 2013
  55. Jul 24, 2013
  57. Jul 09, 2013
  59. Jun 21, 2013
  61. Jun 05, 2013