Eric Lee / smarc-fsl-linux-kernel

20 Sep, 2018

1 commit

  • 64def6f35   crypto: aes-generic - fix aes-generic regression on powerpc ... Browse Code »

    commit 6e36719fbe90213fbba9f50093fa2d4d69b0e93c upstream.

    My last bugfix added -Os on the command line, which unfortunately caused
    a build regression on powerpc in some configurations.

    I've done some more analysis of the original problem and found slightly
    different workaround that avoids this regression and also results in
    better performance on gcc-7.0: -fcode-hoisting is an optimization step
    that got added in gcc-7 and that for all gcc-7 versions causes worse
    performance.

    This disables -fcode-hoisting on all compilers that understand the option.
    For gcc-7.1 and 7.2 I found the same performance as my previous patch
    (using -Os), in gcc-7.0 it was even better. On gcc-8 I could see no
    change in performance from this patch. In theory, code hoisting should
    not be able make things better for the AES cipher, so leaving it
    disabled for gcc-8 only serves to simplify the Makefile change.

    Reported-by: kbuild test robot
    Link: https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg30418.html
    Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83356
    Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83651
    Fixes: 148b974deea9 ("crypto: aes-generic - build with -Os on gcc-7+")
    Signed-off-by: Arnd Bergmann
    Signed-off-by: Herbert Xu
    Cc: Horia Geanta
    Signed-off-by: Greg Kroah-Hartman

    Arnd Bergmann
     

12 Apr, 2018

1 commit

  • 7cae67e31   crypto: aes-generic - build with -Os on gcc-7+ ... Browse Code »

    [ Upstream commit 148b974deea927f5dbb6c468af2707b488bfa2de ]

    While testing other changes, I discovered that gcc-7.2.1 produces badly
    optimized code for aes_encrypt/aes_decrypt. This is especially true when
    CONFIG_UBSAN_SANITIZE_ALL is enabled, where it leads to extremely
    large stack usage that in turn might cause kernel stack overflows:

    crypto/aes_generic.c: In function 'aes_encrypt':
    crypto/aes_generic.c:1371:1: warning: the frame size of 4880 bytes is larger than 2048 bytes [-Wframe-larger-than=]
    crypto/aes_generic.c: In function 'aes_decrypt':
    crypto/aes_generic.c:1441:1: warning: the frame size of 4864 bytes is larger than 2048 bytes [-Wframe-larger-than=]

    I verified that this problem exists on all architectures that are
    supported by gcc-7.2, though arm64 in particular is less affected than
    the others. I also found that gcc-7.1 and gcc-8 do not show the extreme
    stack usage but still produce worse code than earlier versions for this
    file, apparently because of optimization passes that generally provide
    a substantial improvement in object code quality but understandably fail
    to find any shortcuts in the AES algorithm.

    Possible workarounds include

    a) disabling -ftree-pre and -ftree-sra optimizations, this was an earlier
    patch I tried, which reliably fixed the stack usage, but caused a
    serious performance regression in some versions, as later testing
    found.

    b) disabling UBSAN on this file or all ciphers, as suggested by Ard
    Biesheuvel. This would lead to massively better crypto performance in
    UBSAN-enabled kernels and avoid the stack usage, but there is a concern
    over whether we should exclude arbitrary files from UBSAN at all.

    c) Forcing the optimization level in a different way. Similar to a),
    but rather than deselecting specific optimization stages,
    this now uses "gcc -Os" for this file, regardless of the
    CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE/SIZE option. This is a reliable
    workaround for the stack consumption on all architecture, and I've
    retested the performance results now on x86, cycles/byte (lower is
    better) for cbc(aes-generic) with 256 bit keys:

    -O2 -Os
    gcc-6.3.1 14.9 15.1
    gcc-7.0.1 14.7 15.3
    gcc-7.1.1 15.3 14.7
    gcc-7.2.1 16.8 15.9
    gcc-8.0.0 15.5 15.6

    This implements the option c) by enabling forcing -Os on all compiler
    versions starting with gcc-7.1. As a workaround for PR83356, it would
    only be needed for gcc-7.2+ with UBSAN enabled, but since it also shows
    better performance on gcc-7.1 without UBSAN, it seems appropriate to
    use the faster version here as well.

    Side note: during testing, I also played with the AES code in libressl,
    which had a similar performance regression from gcc-6 to gcc-7.2,
    but was three times slower overall. It might be interesting to
    investigate that further and possibly port the Linux implementation
    into that.

    Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83356
    Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83651
    Cc: Richard Biener
    Cc: Jakub Jelinek
    Cc: Ard Biesheuvel
    Signed-off-by: Arnd Bergmann
    Acked-by: Ard Biesheuvel
    Signed-off-by: Herbert Xu
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Arnd Bergmann
     

02 Nov, 2017

1 commit

  • b24413180   License cleanup: add SPDX GPL-2.0 license identifier to files with no license ... Browse Code »

    Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

10 Jun, 2017

1 commit

  • 6755fd269   crypto: ecdh - add privkey generation support ... Browse Code »

    Add support for generating ecc private keys.

    Generation of ecc private keys is helpful in a user-space to kernel
    ecdh offload because the keys are not revealed to user-space. Private
    key generation is also helpful to implement forward secrecy.

    If the user provides a NULL ecc private key, the kernel will generate it
    and further use it for ecdh.

    Move ecdh's object files below drbg's. drbg must be present in the kernel
    at the time of calling.

    Signed-off-by: Tudor Ambarus
    Reviewed-by: Stephan Müller
    Signed-off-by: Herbert Xu

    Tudor-Dan Ambarus
     

11 Feb, 2017

2 commits

  • 7d6e91050   crypto: improve gcc optimization flags for serpent and wp512 ... Browse Code »

    An ancient gcc bug (first reported in 2003) has apparently resurfaced
    on MIPS, where kernelci.org reports an overly large stack frame in the
    whirlpool hash algorithm:

    crypto/wp512.c:987:1: warning: the frame size of 1112 bytes is larger than 1024 bytes [-Wframe-larger-than=]

    With some testing in different configurations, I'm seeing large
    variations in stack frames size up to 1500 bytes for what should have
    around 300 bytes at most. I also checked the reference implementation,
    which is essentially the same code but also comes with some test and
    benchmarking infrastructure.

    It seems that recent compiler versions on at least arm, arm64 and powerpc
    have a partial fix for this problem, but enabling "-fsched-pressure", but
    even with that fix they suffer from the issue to a certain degree. Some
    testing on arm64 shows that the time needed to hash a given amount of
    data is roughly proportional to the stack frame size here, which makes
    sense given that the wp512 implementation is doing lots of loads for
    table lookups, and the problem with the overly large stack is a result
    of doing a lot more loads and stores for spilled registers (as seen from
    inspecting the object code).

    Disabling -fschedule-insns consistently fixes the problem for wp512,
    in my collection of cross-compilers, the results are consistently better
    or identical when comparing the stack sizes in this function, though
    some architectures (notable x86) have schedule-insns disabled by
    default.

    The four columns are:
    default: -O2
    press: -O2 -fsched-pressure
    nopress: -O2 -fschedule-insns -fno-sched-pressure
    nosched: -O2 -no-schedule-insns (disables sched-pressure)

    default press nopress nosched
    alpha-linux-gcc-4.9.3 1136 848 1136 176
    am33_2.0-linux-gcc-4.9.3 2100 2076 2100 2104
    arm-linux-gnueabi-gcc-4.9.3 848 848 1048 352
    cris-linux-gcc-4.9.3 272 272 272 272
    frv-linux-gcc-4.9.3 1128 1000 1128 280
    hppa64-linux-gcc-4.9.3 1128 336 1128 184
    hppa-linux-gcc-4.9.3 644 308 644 276
    i386-linux-gcc-4.9.3 352 352 352 352
    m32r-linux-gcc-4.9.3 720 656 720 268
    microblaze-linux-gcc-4.9.3 1108 604 1108 256
    mips64-linux-gcc-4.9.3 1328 592 1328 208
    mips-linux-gcc-4.9.3 1096 624 1096 240
    powerpc64-linux-gcc-4.9.3 1088 432 1088 160
    powerpc-linux-gcc-4.9.3 1080 584 1080 224
    s390-linux-gcc-4.9.3 456 456 624 360
    sh3-linux-gcc-4.9.3 292 292 292 292
    sparc64-linux-gcc-4.9.3 992 240 992 208
    sparc-linux-gcc-4.9.3 680 592 680 312
    x86_64-linux-gcc-4.9.3 224 240 272 224
    xtensa-linux-gcc-4.9.3 1152 704 1152 304

    aarch64-linux-gcc-7.0.0 224 224 1104 208
    arm-linux-gnueabi-gcc-7.0.1 824 824 1048 352
    mips-linux-gcc-7.0.0 1120 648 1120 272
    x86_64-linux-gcc-7.0.1 240 240 304 240

    arm-linux-gnueabi-gcc-4.4.7 840 392
    arm-linux-gnueabi-gcc-4.5.4 784 728 784 320
    arm-linux-gnueabi-gcc-4.6.4 736 728 736 304
    arm-linux-gnueabi-gcc-4.7.4 944 784 944 352
    arm-linux-gnueabi-gcc-4.8.5 464 464 760 352
    arm-linux-gnueabi-gcc-4.9.3 848 848 1048 352
    arm-linux-gnueabi-gcc-5.3.1 824 824 1064 336
    arm-linux-gnueabi-gcc-6.1.1 808 808 1056 344
    arm-linux-gnueabi-gcc-7.0.1 824 824 1048 352

    Trying the same test for serpent-generic, the picture is a bit different,
    and while -fno-schedule-insns is generally better here than the default,
    -fsched-pressure wins overall, so I picked that instead.

    default press nopress nosched
    alpha-linux-gcc-4.9.3 1392 864 1392 960
    am33_2.0-linux-gcc-4.9.3 536 524 536 528
    arm-linux-gnueabi-gcc-4.9.3 552 552 776 536
    cris-linux-gcc-4.9.3 528 528 528 528
    frv-linux-gcc-4.9.3 536 400 536 504
    hppa64-linux-gcc-4.9.3 524 208 524 480
    hppa-linux-gcc-4.9.3 768 472 768 508
    i386-linux-gcc-4.9.3 564 564 564 564
    m32r-linux-gcc-4.9.3 712 576 712 532
    microblaze-linux-gcc-4.9.3 724 392 724 512
    mips64-linux-gcc-4.9.3 720 384 720 496
    mips-linux-gcc-4.9.3 728 384 728 496
    powerpc64-linux-gcc-4.9.3 704 304 704 480
    powerpc-linux-gcc-4.9.3 704 296 704 480
    s390-linux-gcc-4.9.3 560 560 592 536
    sh3-linux-gcc-4.9.3 540 540 540 540
    sparc64-linux-gcc-4.9.3 544 352 544 496
    sparc-linux-gcc-4.9.3 544 344 544 496
    x86_64-linux-gcc-4.9.3 528 536 576 528
    xtensa-linux-gcc-4.9.3 752 544 752 544

    aarch64-linux-gcc-7.0.0 432 432 656 480
    arm-linux-gnueabi-gcc-7.0.1 616 616 808 536
    mips-linux-gcc-7.0.0 720 464 720 488
    x86_64-linux-gcc-7.0.1 536 528 600 536

    arm-linux-gnueabi-gcc-4.4.7 592 440
    arm-linux-gnueabi-gcc-4.5.4 776 448 776 544
    arm-linux-gnueabi-gcc-4.6.4 776 448 776 544
    arm-linux-gnueabi-gcc-4.7.4 768 448 768 544
    arm-linux-gnueabi-gcc-4.8.5 488 488 776 544
    arm-linux-gnueabi-gcc-4.9.3 552 552 776 536
    arm-linux-gnueabi-gcc-5.3.1 552 552 776 536
    arm-linux-gnueabi-gcc-6.1.1 560 560 776 536
    arm-linux-gnueabi-gcc-7.0.1 616 616 808 536

    I did not do any runtime tests with serpent, so it is possible that stack
    frame size does not directly correlate with runtime performance here and
    it actually makes things worse, but it's more likely to help here, and
    the reduced stack frame size is probably enough reason to apply the patch,
    especially given that the crypto code is often used in deep call chains.

    Link: https://kernelci.org/build/id/58797d7559b5149efdf6c3a9/logs/
    Link: http://www.larc.usp.br/~pbarreto/WhirlpoolPage.html
    Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11488
    Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79149
    Cc: Ralf Baechle
    Signed-off-by: Arnd Bergmann
    Signed-off-by: Herbert Xu

    Arnd Bergmann
     
  • b5e0b032b   crypto: aes - add generic time invariant AES cipher ... Browse Code »

    Lookup table based AES is sensitive to timing attacks, which is due to
    the fact that such table lookups are data dependent, and the fact that
    8 KB worth of tables covers a significant number of cachelines on any
    architecture, resulting in an exploitable correlation between the key
    and the processing time for known plaintexts.

    For network facing algorithms such as CTR, CCM or GCM, this presents a
    security risk, which is why arch specific AES ports are typically time
    invariant, either through the use of special instructions, or by using
    SIMD algorithms that don't rely on table lookups.

    For generic code, this is difficult to achieve without losing too much
    performance, but we can improve the situation significantly by switching
    to an implementation that only needs 256 bytes of table data (the actual
    S-box itself), which can be prefetched at the start of each block to
    eliminate data dependent latencies.

    This code encrypts at ~25 cycles per byte on ARM Cortex-A57 (while the
    ordinary generic AES driver manages 18 cycles per byte on this
    hardware). Decryption is substantially slower.

    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Herbert Xu

    Ard Biesheuvel
     

30 Nov, 2016

2 commits

28 Nov, 2016

1 commit

  • 266d05160   crypto: simd - Add simd skcipher helper ... Browse Code »

    This patch adds the simd skcipher helper which is meant to be
    a replacement for ablk helper. It replaces the underlying blkcipher
    interface with skcipher, and also presents the top-level algorithm
    as an skcipher.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

01 Nov, 2016

1 commit

25 Oct, 2016

2 commits

18 Jul, 2016

1 commit

  • 3a01d0ee2   crypto: skcipher - Remove top-level givcipher interface ... Browse Code »

    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: Herbert Xu

    Herbert Xu
     

23 Jun, 2016

3 commits

  • 3c4b23901   crypto: ecdh - Add ECDH software support ... Browse Code »

    * Implement ECDH under kpp API
    * Provide ECC software support for curve P-192 and
    P-256.
    * Add kpp test for ECDH with data generated by OpenSSL

    Signed-off-by: Salvatore Benedetto
    Signed-off-by: Herbert Xu

    Salvatore Benedetto
     
  • 802c7f1c8   crypto: dh - Add DH software implementation ... Browse Code »

    * Implement MPI based Diffie-Hellman under kpp API
    * Test provided uses data generad by OpenSSL

    Signed-off-by: Salvatore Benedetto
    Signed-off-by: Herbert Xu

    Salvatore Benedetto
     
  • 4e5f2c400   crypto: kpp - Key-agreement Protocol Primitives API (KPP) ... Browse Code »

    Add key-agreement protocol primitives (kpp) API which allows to
    implement primitives required by protocols such as DH and ECDH.
    The API is composed mainly by the following functions
    * set_secret() - It allows the user to set his secret, also
    referred to as his private key, along with the parameters
    known to both parties involved in the key-agreement session.
    * generate_public_key() - It generates the public key to be sent to
    the other counterpart involved in the key-agreement session. The
    function has to be called after set_params() and set_secret()
    * generate_secret() - It generates the shared secret for the session

    Other functions such as init() and exit() are provided for allowing
    cryptographic hardware to be inizialized properly before use

    Signed-off-by: Salvatore Benedetto
    Signed-off-by: Herbert Xu

    Salvatore Benedetto
     

20 Jun, 2016

1 commit

  • 53964b9ee   crypto: sha3 - Add SHA-3 hash algorithm ... Browse Code »

    This patch adds the implementation of SHA3 algorithm
    in software and it's based on original implementation
    pushed in patch https://lwn.net/Articles/518415/ with
    additional changes to match the padding rules specified
    in SHA-3 specification.

    Signed-off-by: Jeff Garzik
    Signed-off-by: Raveendra Padasalagi
    Signed-off-by: Herbert Xu

    Jeff Garzik
     

01 Feb, 2016

1 commit

  • 735d37b54   crypto: engine - Introduce the block request crypto engine framework ... Browse Code »

    Now block cipher engines need to implement and maintain their own queue/thread
    for processing requests, moreover currently helpers provided for only the queue
    itself (in crypto_enqueue_request() and crypto_dequeue_request()) but they
    don't help with the mechanics of driving the hardware (things like running the
    request immediately, DMA map it or providing a thread to process the queue in)
    even though a lot of that code really shouldn't vary that much from device to
    device.

    Thus this patch provides a mechanism for pushing requests to the hardware
    as it becomes free that drivers could use. And this framework is patterned
    on the SPI code and has worked out well there.
    (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/
    drivers/spi/spi.c?id=ffbbdd21329f3e15eeca6df2d4bc11c04d9d91c0)

    Signed-off-by: Baolin Wang
    Signed-off-by: Herbert Xu

    Baolin Wang
     

30 Jan, 2016

1 commit

  • a7c58ac06   crypto: crc32 - Rename generic implementation ... Browse Code »

    The generic crc32 implementation is currently called crc32. This
    is a problem because it clashes with the lib implementation of crc32.

    This patch renames the crypto crc32 to crc32_generic so that it is
    consistent with crc32c. An alias for the driver is also added.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

27 Jan, 2016

1 commit

09 Dec, 2015

1 commit

  • 3d5b1ecde   crypto: rsa - RSA padding algorithm ... Browse Code »

    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: Andrew Zaborowski
    Signed-off-by: Herbert Xu

    Andrzej Zaborowski
     

15 Oct, 2015

1 commit

14 Oct, 2015

1 commit

  • 22287b0b5   crypto: akcipher - Changes to asymmetric key API ... Browse Code »

    Setkey function has been split into set_priv_key and set_pub_key.
    Akcipher requests takes sgl for src and dst instead of void *.
    Users of the API i.e. two existing RSA implementation and
    test mgr code have been updated accordingly.

    Signed-off-by: Tadeusz Struk
    Signed-off-by: Herbert Xu

    Tadeusz Struk
     

21 Aug, 2015

1 commit

  • 7a7ffe65c   crypto: skcipher - Add top-level skcipher interface ... Browse Code »

    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: Herbert Xu

    Herbert Xu
     

17 Aug, 2015

1 commit

  • a26bcb048   crypto: null - Use NULL2 in Makefile ... Browse Code »

    The Kconfig option NULL2 has been added as CRYPTO_MANAGER now
    depends indirectly on NULL2. However, the Makefile was not updated
    to use the new option, resulting in potential build failures when
    only NULL2 is enabled.

    Fixes: 149a39717dcc ("crypto: aead - Add type-safe geniv init/exit helpers")
    Reported-by: kbuild test robot
    Signed-off-by: Herbert Xu

    Herbert Xu
     

25 Jun, 2015

1 commit

  • dfc9fa919   crypto: jitterentropy - avoid compiler warnings ... Browse Code »

    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: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     

17 Jun, 2015

2 commits

09 Jun, 2015

1 commit

  • fbb145bc0   crypto: drbg - use pragmas for disabling optimization ... Browse Code »

    Replace the global -O0 compiler flag from the Makefile with GCC
    pragmas to mark only the functions required to be compiled without
    optimizations.

    This patch also adds a comment describing the rationale for the
    functions chosen to be compiled without optimizations.

    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     

04 Jun, 2015

4 commits

  • a5b151d11   crypto: rng - Remove krng ... Browse Code »

    This patch removes krng so that DRBG can take its place.

    Signed-off-by: Herbert Xu

    Herbert Xu
     
  • 71ebc4d1b   crypto: chacha20poly1305 - Add a ChaCha20-Poly1305 AEAD construction, RFC7539 ... Browse Code »

    This AEAD uses a chacha20 ablkcipher and a poly1305 ahash to construct the
    ChaCha20-Poly1305 AEAD as defined in RFC7539. It supports both synchronous and
    asynchronous operations, even if we currently have no async chacha20 or poly1305
    drivers.

    Signed-off-by: Martin Willi
    Acked-by: Steffen Klassert
    Signed-off-by: Herbert Xu

    Martin Willi
     
  • f979e014c   crypto: poly1305 - Add a generic Poly1305 authenticator implementation ... Browse Code »

    Poly1305 is a fast message authenticator designed by Daniel J. Bernstein.
    It is further defined in RFC7539 as a building block for the ChaCha20-Poly1305
    AEAD for use in IETF protocols.

    This is a portable C implementation of the algorithm without architecture
    specific optimizations, based on public domain code by Daniel J. Bernstein and
    Andrew Moon.

    Signed-off-by: Martin Willi
    Acked-by: Steffen Klassert
    Signed-off-by: Herbert Xu

    Martin Willi
     
  • c08d0e647   crypto: chacha20 - Add a generic ChaCha20 stream cipher implementation ... Browse Code »

    ChaCha20 is a high speed 256-bit key size stream cipher algorithm designed by
    Daniel J. Bernstein. It is further specified in RFC7539 for use in IETF
    protocols as a building block for the ChaCha20-Poly1305 AEAD.

    This is a portable C implementation without any architecture specific
    optimizations. It uses a 16-byte IV, which includes the 12-byte ChaCha20 nonce
    prepended by the initial block counter. Some algorithms require an explicit
    counter value, for example the mentioned AEAD construction.

    Signed-off-by: Martin Willi
    Acked-by: Steffen Klassert
    Signed-off-by: Herbert Xu

    Martin Willi
     

27 May, 2015

1 commit

  • bb5530e40   crypto: jitterentropy - add jitterentropy RNG ... Browse Code »

    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
    CC: Theodore Ts'o
    CC: Sandy Harris
    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     

22 May, 2015

1 commit

  • a10f554fa   crypto: echainiv - Add encrypted chain IV generator ... Browse Code »

    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: Herbert Xu

    Herbert Xu
     

04 Mar, 2015

1 commit

29 Dec, 2014

1 commit

25 Aug, 2014

1 commit

  • 1e65b81a9   crypto: sha-mb - multibuffer crypto infrastructure ... Browse Code »

    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: Tim Chen
    Signed-off-by: Herbert Xu

    Tim Chen
     

04 Jul, 2014

1 commit

20 Jun, 2014

1 commit