Skip to content
Snippets Groups Projects
Select Git revision
0 results
Search by author
  • Any Author
0 authors
  1. Feb 01, 2016
  3. Jan 30, 2016
  5. Jan 27, 2016
  7. Dec 09, 2015
    • 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
  9. Oct 15, 2015
  11. Oct 14, 2015
  13. Aug 21, 2015
    • 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
  15. Aug 17, 2015
  17. Jun 25, 2015
    • 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
  19. Jun 17, 2015
  21. Jun 09, 2015
  23. Jun 04, 2015
  25. 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
  27. 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
  29. Mar 04, 2015
  31. Dec 29, 2014
  33. 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
  35. Jul 04, 2014
  37. Jun 20, 2014
  39. Feb 25, 2014
  41. Dec 05, 2013
    • 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
  43. Oct 25, 2013
  45. Oct 07, 2013
    • 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/131



Signed-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
  47. Sep 23, 2013
  49. Sep 12, 2013
    • 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
  51. Sep 07, 2013
  53. Jul 24, 2013
  55. Jul 09, 2013
  57. May 20, 2013
  59. Apr 25, 2013
  61. Jan 19, 2013
  63. Dec 06, 2012
  65. Oct 08, 2012
    • 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
  67. Aug 01, 2012