Skip to content

K
Kernel

openeuler / Kernel
大约 1 年 前同步成功

通知 5
Star 0
Fork 0
K
Kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 04 6月, 2015 5 次提交
  3. 03 6月, 2015 1 次提交
  5. 27 5月, 2015 1 次提交
    • S
      crypto: jitterentropy - add jitterentropy RNG · bb5530e4
      由 Stephan Mueller 提交于 
      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: NStephan Mueller <smueller@chronox.de>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      bb5530e4
  7. 26 5月, 2015 1 次提交
  9. 22 5月, 2015 2 次提交
    • H
      crypto: echainiv - Add encrypted chain IV generator · a10f554f
      由 Herbert Xu 提交于 
      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: NHerbert Xu <herbert@gondor.apana.org.au>
      a10f554f
    • H
      crypto: seqiv - Add support for new AEAD interface · 856e3f40
      由 Herbert Xu 提交于 
      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: NHerbert Xu <herbert@gondor.apana.org.au>
      856e3f40
  11. 11 5月, 2015 1 次提交
    • D
      crypto: 842 - change 842 alg to use software · 2062c5b6
      由 Dan Streetman 提交于 
      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: NDan Streetman <ddstreet@ieee.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      2062c5b6
  13. 07 4月, 2015 1 次提交
  15. 12 3月, 2015 1 次提交
  17. 10 3月, 2015 1 次提交
  19. 04 3月, 2015 2 次提交
  21. 02 3月, 2015 1 次提交
  23. 01 3月, 2015 1 次提交
  25. 27 2月, 2015 1 次提交
  27. 29 12月, 2014 1 次提交
  29. 24 12月, 2014 1 次提交
  31. 04 9月, 2014 1 次提交
  33. 27 8月, 2014 2 次提交
  35. 25 8月, 2014 1 次提交
    • T
      crypto: sha-mb - multibuffer crypto infrastructure · 1e65b81a
      由 Tim Chen 提交于 
      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: NTim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      1e65b81a
  37. 02 8月, 2014 2 次提交
  39. 04 7月, 2014 1 次提交
  41. 03 7月, 2014 1 次提交
    • J
      crypto: fips - only panic on bad/missing crypto mod signatures · 002c77a4
      由 Jarod Wilson 提交于 
      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: NJarod Wilson <jarod@redhat.com>
Acked-by: NNeil Horman <nhorman@tuxdriver.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      002c77a4
  43. 20 6月, 2014 2 次提交
  45. 21 3月, 2014 1 次提交
    • C
      crypto: sha - SHA1 transform x86_64 AVX2 · 7c1da8d0
      由 chandramouli narayanan 提交于 
      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: NChandramouli Narayanan <mouli@linux.intel.com>
Reviewed-by: NMarek Vasut <marex@denx.de>
Acked-by: NH. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      7c1da8d0
  47. 26 10月, 2013 1 次提交
  49. 05 10月, 2013 1 次提交
    • A
      ARM: add support for bit sliced AES using NEON instructions · e4e7f10b
      由 Ard Biesheuvel 提交于 
      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: NNicolas Pitre <nico@linaro.org>
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      e4e7f10b
  51. 24 9月, 2013 2 次提交
  53. 07 9月, 2013 1 次提交
  55. 24 7月, 2013 1 次提交
  57. 10 7月, 2013 1 次提交
  59. 21 6月, 2013 1 次提交