Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 18 7月, 2016 1 次提交
    • H
      crypto: skcipher - Remove top-level givcipher interface · 3a01d0ee
      由 Herbert Xu 提交于 
      This patch removes the old crypto_grab_skcipher helper and replaces
it with crypto_grab_skcipher2.

As this is the final entry point into givcipher this patch also
removes all traces of the top-level givcipher interface, including
all implicit IV generators such as chainiv.

The bottom-level givcipher interface remains until the drivers
using it are converted.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      3a01d0ee
  3. 23 6月, 2016 3 次提交
  5. 20 6月, 2016 1 次提交
  7. 01 2月, 2016 1 次提交
  9. 30 1月, 2016 1 次提交
  11. 27 1月, 2016 1 次提交
  13. 09 12月, 2015 1 次提交
    • A
      crypto: rsa - RSA padding algorithm · 3d5b1ecd
      由 Andrzej Zaborowski 提交于 
      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: NAndrew Zaborowski <andrew.zaborowski@intel.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      3d5b1ecd
  15. 15 10月, 2015 1 次提交
  17. 14 10月, 2015 1 次提交
  19. 21 8月, 2015 1 次提交
    • H
      crypto: skcipher - Add top-level skcipher interface · 7a7ffe65
      由 Herbert Xu 提交于 
      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: NHerbert Xu <herbert@gondor.apana.org.au>
      7a7ffe65
  21. 17 8月, 2015 1 次提交
  23. 25 6月, 2015 1 次提交
    • S
      crypto: jitterentropy - avoid compiler warnings · dfc9fa91
      由 Stephan Mueller 提交于 
      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: NStephan Mueller <smueller@chronox.de>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      dfc9fa91
  25. 17 6月, 2015 2 次提交
  27. 09 6月, 2015 1 次提交
  29. 04 6月, 2015 4 次提交
  31. 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
  33. 22 5月, 2015 1 次提交
    • 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
  35. 04 3月, 2015 1 次提交
  37. 29 12月, 2014 1 次提交
  39. 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
  41. 04 7月, 2014 1 次提交
  43. 20 6月, 2014 1 次提交
  45. 25 2月, 2014 1 次提交
  47. 05 12月, 2013 1 次提交
    • C
      crypto: more robust crypto_memneq · fe8c8a12
      由 Cesar Eduardo Barros 提交于 
      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: NCesar Eduardo Barros <cesarb@cesarb.eti.br>
Acked-by: NDaniel Borkmann <dborkman@redhat.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      fe8c8a12
  49. 26 10月, 2013 1 次提交
  51. 07 10月, 2013 1 次提交
    • J
      crypto: crypto_memneq - add equality testing of memory regions w/o timing leaks · 6bf37e5a
      由 James Yonan 提交于 
      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: NJames Yonan <james@openvpn.net>
Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
Cc: Florian Weimer <fw@deneb.enyo.de>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      6bf37e5a
  53. 24 9月, 2013 1 次提交
  55. 12 9月, 2013 1 次提交
    • H
      crypto: crct10dif - Add fallback for broken initrds · 26052f9b
      由 Herbert Xu 提交于 
      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: NHerbert Xu <herbert@gondor.apana.org.au>
      26052f9b
  57. 07 9月, 2013 1 次提交
  59. 24 7月, 2013 1 次提交
  61. 10 7月, 2013 1 次提交
  63. 20 5月, 2013 1 次提交
  65. 25 4月, 2013 1 次提交
  67. 20 1月, 2013 1 次提交