Skip to content
Snippets Groups Projects
  1. May 30, 2019
  2. May 24, 2019
  3. May 21, 2019
    • Thomas Gleixner's avatar
      treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 13 · 1ccea77e
      Thomas Gleixner authored
      
      Based on 2 normalized pattern(s):
      
        this program is free software you can redistribute it and or modify
        it under the terms of the gnu general public license as published by
        the free software foundation either version 2 of the license or at
        your option any later version this program is distributed in the
        hope that it will be useful but without any warranty without even
        the implied warranty of merchantability or fitness for a particular
        purpose see the gnu general public license for more details you
        should have received a copy of the gnu general public license along
        with this program if not see http www gnu org licenses
      
        this program is free software you can redistribute it and or modify
        it under the terms of the gnu general public license as published by
        the free software foundation either version 2 of the license or at
        your option any later version this program is distributed in the
        hope that it will be useful but without any warranty without even
        the implied warranty of merchantability or fitness for a particular
        purpose see the gnu general public license for more details [based]
        [from] [clk] [highbank] [c] you should have received a copy of the
        gnu general public license along with this program if not see http
        www gnu org licenses
      
      extracted by the scancode license scanner the SPDX license identifier
      
        GPL-2.0-or-later
      
      has been chosen to replace the boilerplate/reference in 355 file(s).
      
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: default avatarJilayne Lovejoy <opensource@jilayne.com>
      Reviewed-by: default avatarSteve Winslow <swinslow@gmail.com>
      Reviewed-by: default avatarAllison Randal <allison@lohutok.net>
      Cc: linux-spdx@vger.kernel.org
      Link: https://lkml.kernel.org/r/20190519154041.837383322@linutronix.de
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1ccea77e
  4. May 17, 2019
    • Eric Biggers's avatar
      crypto: hash - fix incorrect HASH_MAX_DESCSIZE · e1354400
      Eric Biggers authored
      
      The "hmac(sha3-224-generic)" algorithm has a descsize of 368 bytes,
      which is greater than HASH_MAX_DESCSIZE (360) which is only enough for
      sha3-224-generic.  The check in shash_prepare_alg() doesn't catch this
      because the HMAC template doesn't set descsize on the algorithms, but
      rather sets it on each individual HMAC transform.
      
      This causes a stack buffer overflow when SHASH_DESC_ON_STACK() is used
      with hmac(sha3-224-generic).
      
      Fix it by increasing HASH_MAX_DESCSIZE to the real maximum.  Also add a
      sanity check to hmac_init().
      
      This was detected by the improved crypto self-tests in v5.2, by loading
      the tcrypt module with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y enabled.  I
      didn't notice this bug when I ran the self-tests by requesting the
      algorithms via AF_ALG (i.e., not using tcrypt), probably because the
      stack layout differs in the two cases and that made a difference here.
      
      KASAN report:
      
          BUG: KASAN: stack-out-of-bounds in memcpy include/linux/string.h:359 [inline]
          BUG: KASAN: stack-out-of-bounds in shash_default_import+0x52/0x80 crypto/shash.c:223
          Write of size 360 at addr ffff8880651defc8 by task insmod/3689
      
          CPU: 2 PID: 3689 Comm: insmod Tainted: G            E     5.1.0-10741-g35c99ffa20edd #11
          Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
          Call Trace:
           __dump_stack lib/dump_stack.c:77 [inline]
           dump_stack+0x86/0xc5 lib/dump_stack.c:113
           print_address_description+0x7f/0x260 mm/kasan/report.c:188
           __kasan_report+0x144/0x187 mm/kasan/report.c:317
           kasan_report+0x12/0x20 mm/kasan/common.c:614
           check_memory_region_inline mm/kasan/generic.c:185 [inline]
           check_memory_region+0x137/0x190 mm/kasan/generic.c:191
           memcpy+0x37/0x50 mm/kasan/common.c:125
           memcpy include/linux/string.h:359 [inline]
           shash_default_import+0x52/0x80 crypto/shash.c:223
           crypto_shash_import include/crypto/hash.h:880 [inline]
           hmac_import+0x184/0x240 crypto/hmac.c:102
           hmac_init+0x96/0xc0 crypto/hmac.c:107
           crypto_shash_init include/crypto/hash.h:902 [inline]
           shash_digest_unaligned+0x9f/0xf0 crypto/shash.c:194
           crypto_shash_digest+0xe9/0x1b0 crypto/shash.c:211
           generate_random_hash_testvec.constprop.11+0x1ec/0x5b0 crypto/testmgr.c:1331
           test_hash_vs_generic_impl+0x3f7/0x5c0 crypto/testmgr.c:1420
           __alg_test_hash+0x26d/0x340 crypto/testmgr.c:1502
           alg_test_hash+0x22e/0x330 crypto/testmgr.c:1552
           alg_test.part.7+0x132/0x610 crypto/testmgr.c:4931
           alg_test+0x1f/0x40 crypto/testmgr.c:4952
      
      Fixes: b68a7ec1 ("crypto: hash - Remove VLA usage")
      Reported-by: default avatarCorentin Labbe <clabbe.montjoie@gmail.com>
      Cc: <stable@vger.kernel.org> # v4.20+
      Cc: Kees Cook <keescook@chromium.org>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Tested-by: default avatarCorentin Labbe <clabbe.montjoie@gmail.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      e1354400
  5. Apr 27, 2019
    • Johannes Berg's avatar
      netlink: make validation more configurable for future strictness · 8cb08174
      Johannes Berg authored
      
      We currently have two levels of strict validation:
      
       1) liberal (default)
           - undefined (type >= max) & NLA_UNSPEC attributes accepted
           - attribute length >= expected accepted
           - garbage at end of message accepted
       2) strict (opt-in)
           - NLA_UNSPEC attributes accepted
           - attribute length >= expected accepted
      
      Split out parsing strictness into four different options:
       * TRAILING     - check that there's no trailing data after parsing
                        attributes (in message or nested)
       * MAXTYPE      - reject attrs > max known type
       * UNSPEC       - reject attributes with NLA_UNSPEC policy entries
       * STRICT_ATTRS - strictly validate attribute size
      
      The default for future things should be *everything*.
      The current *_strict() is a combination of TRAILING and MAXTYPE,
      and is renamed to _deprecated_strict().
      The current regular parsing has none of this, and is renamed to
      *_parse_deprecated().
      
      Additionally it allows us to selectively set one of the new flags
      even on old policies. Notably, the UNSPEC flag could be useful in
      this case, since it can be arranged (by filling in the policy) to
      not be an incompatible userspace ABI change, but would then going
      forward prevent forgetting attribute entries. Similar can apply
      to the POLICY flag.
      
      We end up with the following renames:
       * nla_parse           -> nla_parse_deprecated
       * nla_parse_strict    -> nla_parse_deprecated_strict
       * nlmsg_parse         -> nlmsg_parse_deprecated
       * nlmsg_parse_strict  -> nlmsg_parse_deprecated_strict
       * nla_parse_nested    -> nla_parse_nested_deprecated
       * nla_validate_nested -> nla_validate_nested_deprecated
      
      Using spatch, of course:
          @@
          expression TB, MAX, HEAD, LEN, POL, EXT;
          @@
          -nla_parse(TB, MAX, HEAD, LEN, POL, EXT)
          +nla_parse_deprecated(TB, MAX, HEAD, LEN, POL, EXT)
      
          @@
          expression NLH, HDRLEN, TB, MAX, POL, EXT;
          @@
          -nlmsg_parse(NLH, HDRLEN, TB, MAX, POL, EXT)
          +nlmsg_parse_deprecated(NLH, HDRLEN, TB, MAX, POL, EXT)
      
          @@
          expression NLH, HDRLEN, TB, MAX, POL, EXT;
          @@
          -nlmsg_parse_strict(NLH, HDRLEN, TB, MAX, POL, EXT)
          +nlmsg_parse_deprecated_strict(NLH, HDRLEN, TB, MAX, POL, EXT)
      
          @@
          expression TB, MAX, NLA, POL, EXT;
          @@
          -nla_parse_nested(TB, MAX, NLA, POL, EXT)
          +nla_parse_nested_deprecated(TB, MAX, NLA, POL, EXT)
      
          @@
          expression START, MAX, POL, EXT;
          @@
          -nla_validate_nested(START, MAX, POL, EXT)
          +nla_validate_nested_deprecated(START, MAX, POL, EXT)
      
          @@
          expression NLH, HDRLEN, MAX, POL, EXT;
          @@
          -nlmsg_validate(NLH, HDRLEN, MAX, POL, EXT)
          +nlmsg_validate_deprecated(NLH, HDRLEN, MAX, POL, EXT)
      
      For this patch, don't actually add the strict, non-renamed versions
      yet so that it breaks compile if I get it wrong.
      
      Also, while at it, make nla_validate and nla_parse go down to a
      common __nla_validate_parse() function to avoid code duplication.
      
      Ultimately, this allows us to have very strict validation for every
      new caller of nla_parse()/nlmsg_parse() etc as re-introduced in the
      next patch, while existing things will continue to work as is.
      
      In effect then, this adds fully strict validation for any new command.
      
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8cb08174
  6. Apr 25, 2019
  7. Apr 19, 2019
    • Eric Biggers's avatar
      crypto: ccm - fix incompatibility between "ccm" and "ccm_base" · 6a1faa4a
      Eric Biggers authored
      
      CCM instances can be created by either the "ccm" template, which only
      allows choosing the block cipher, e.g. "ccm(aes)"; or by "ccm_base",
      which allows choosing the ctr and cbcmac implementations, e.g.
      "ccm_base(ctr(aes-generic),cbcmac(aes-generic))".
      
      However, a "ccm_base" instance prevents a "ccm" instance from being
      registered using the same implementations.  Nor will the instance be
      found by lookups of "ccm".  This can be used as a denial of service.
      Moreover, "ccm_base" instances are never tested by the crypto
      self-tests, even if there are compatible "ccm" tests.
      
      The root cause of these problems is that instances of the two templates
      use different cra_names.  Therefore, fix these problems by making
      "ccm_base" instances set the same cra_name as "ccm" instances, e.g.
      "ccm(aes)" instead of "ccm_base(ctr(aes-generic),cbcmac(aes-generic))".
      
      This requires extracting the block cipher name from the name of the ctr
      and cbcmac algorithms.  It also requires starting to verify that the
      algorithms are really ctr and cbcmac using the same block cipher, not
      something else entirely.  But it would be bizarre if anyone were
      actually using non-ccm-compatible algorithms with ccm_base, so this
      shouldn't break anyone in practice.
      
      Fixes: 4a49b499 ("[CRYPTO] ccm: Added CCM mode")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      6a1faa4a
    • Eric Biggers's avatar
      crypto: gcm - fix incompatibility between "gcm" and "gcm_base" · f699594d
      Eric Biggers authored
      
      GCM instances can be created by either the "gcm" template, which only
      allows choosing the block cipher, e.g. "gcm(aes)"; or by "gcm_base",
      which allows choosing the ctr and ghash implementations, e.g.
      "gcm_base(ctr(aes-generic),ghash-generic)".
      
      However, a "gcm_base" instance prevents a "gcm" instance from being
      registered using the same implementations.  Nor will the instance be
      found by lookups of "gcm".  This can be used as a denial of service.
      Moreover, "gcm_base" instances are never tested by the crypto
      self-tests, even if there are compatible "gcm" tests.
      
      The root cause of these problems is that instances of the two templates
      use different cra_names.  Therefore, fix these problems by making
      "gcm_base" instances set the same cra_name as "gcm" instances, e.g.
      "gcm(aes)" instead of "gcm_base(ctr(aes-generic),ghash-generic)".
      
      This requires extracting the block cipher name from the name of the ctr
      algorithm.  It also requires starting to verify that the algorithms are
      really ctr and ghash, not something else entirely.  But it would be
      bizarre if anyone were actually using non-gcm-compatible algorithms with
      gcm_base, so this shouldn't break anyone in practice.
      
      Fixes: d00aa19b ("[CRYPTO] gcm: Allow block cipher parameter")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      f699594d
  8. Apr 18, 2019
    • Eric Biggers's avatar
      crypto: shash - fix missed optimization in shash_ahash_digest() · 67cb60e4
      Eric Biggers authored
      
      shash_ahash_digest(), which is the ->digest() method for ahash tfms that
      use an shash algorithm, has an optimization where crypto_shash_digest()
      is called if the data is in a single page.  But an off-by-one error
      prevented this path from being taken unless the user happened to provide
      extra data in the scatterlist.  Fix it.
      
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      67cb60e4
    • Eric Biggers's avatar
      crypto: cryptd - remove ability to instantiate ablkciphers · 0a877e35
      Eric Biggers authored
      
      Remove cryptd_alloc_ablkcipher() and the ability of cryptd to create
      algorithms with the deprecated "ablkcipher" type.
      
      This has been unused since commit 0e145b47 ("crypto: ablk_helper -
      remove ablk_helper").  Instead, cryptd_alloc_skcipher() is used.
      
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      0a877e35
    • Sebastian Andrzej Siewior's avatar
      crypto: scompress - initialize per-CPU variables on each CPU · 8c3fffe3
      Sebastian Andrzej Siewior authored
      
      In commit 71052dcf ("crypto: scompress - Use per-CPU struct instead
      multiple variables") I accidentally initialized multiple times the memory on a
      random CPU. I should have initialize the memory on every CPU like it has
      been done earlier. I didn't notice this because the scheduler didn't
      move the task to another CPU.
      Guenter managed to do that and the code crashed as expected.
      
      Allocate / free per-CPU memory on each CPU.
      
      Fixes: 71052dcf ("crypto: scompress - Use per-CPU struct instead multiple variables")
      Reported-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Tested-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      8c3fffe3
    • Eric Biggers's avatar
      crypto: run initcalls for generic implementations earlier · c4741b23
      Eric Biggers authored
      
      Use subsys_initcall for registration of all templates and generic
      algorithm implementations, rather than module_init.  Then change
      cryptomgr to use arch_initcall, to place it before the subsys_initcalls.
      
      This is needed so that when both a generic and optimized implementation
      of an algorithm are built into the kernel (not loadable modules), the
      generic implementation is registered before the optimized one.
      Otherwise, the self-tests for the optimized implementation are unable to
      allocate the generic implementation for the new comparison fuzz tests.
      
      Note that on arm, a side effect of this change is that self-tests for
      generic implementations may run before the unaligned access handler has
      been installed.  So, unaligned accesses will crash the kernel.  This is
      arguably a good thing as it makes it easier to detect that type of bug.
      
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      c4741b23
    • Eric Biggers's avatar
      crypto: testmgr - fuzz AEADs against their generic implementation · 40153b10
      Eric Biggers authored
      
      When the extra crypto self-tests are enabled, test each AEAD algorithm
      against its generic implementation when one is available.  This
      involves: checking the algorithm properties for consistency, then
      randomly generating test vectors using the generic implementation and
      running them against the implementation under test.  Both good and bad
      inputs are tested.
      
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      40153b10
    • Eric Biggers's avatar
      crypto: testmgr - fuzz skciphers against their generic implementation · d435e10e
      Eric Biggers authored
      
      When the extra crypto self-tests are enabled, test each skcipher
      algorithm against its generic implementation when one is available.
      This involves: checking the algorithm properties for consistency, then
      randomly generating test vectors using the generic implementation and
      running them against the implementation under test.  Both good and bad
      inputs are tested.
      
      This has already detected a bug in the skcipher_walk API, a bug in the
      LRW template, and an inconsistency in the cts implementations.
      
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      d435e10e
    • Eric Biggers's avatar
      crypto: testmgr - fuzz hashes against their generic implementation · 9a8a6b3f
      Eric Biggers authored
      
      When the extra crypto self-tests are enabled, test each hash algorithm
      against its generic implementation when one is available.  This
      involves: checking the algorithm properties for consistency, then
      randomly generating test vectors using the generic implementation and
      running them against the implementation under test.  Both good and bad
      inputs are tested.
      
      This has already detected a bug in the x86 implementation of poly1305,
      bugs in crct10dif, and an inconsistency in cbcmac.
      
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      9a8a6b3f
    • Eric Biggers's avatar
      crypto: testmgr - add helpers for fuzzing against generic implementation · f2bb770a
      Eric Biggers authored
      
      Add some helper functions in preparation for fuzz testing algorithms
      against their generic implementation.
      
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      f2bb770a
    • Eric Biggers's avatar
      crypto: testmgr - identify test vectors by name rather than number · 951d1332
      Eric Biggers authored
      
      In preparation for fuzz testing algorithms against their generic
      implementation, make error messages in testmgr identify test vectors by
      name rather than index.  Built-in test vectors are simply "named" by
      their index in testmgr.h, as before.  But (in later patches) generated
      test vectors will be given more descriptive names to help developers
      debug problems detected with them.
      
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      951d1332
    • Eric Biggers's avatar
      crypto: testmgr - expand ability to test for errors · 5283a8ee
      Eric Biggers authored
      
      Update testmgr to support testing for specific errors from setkey() and
      digest() for hashes; setkey() and encrypt()/decrypt() for skciphers and
      ciphers; and setkey(), setauthsize(), and encrypt()/decrypt() for AEADs.
      This is useful because algorithms usually restrict the lengths or format
      of the message, key, and/or authentication tag in some way.  And bad
      inputs should be tested too, not just good inputs.
      
      As part of this change, remove the ambiguously-named 'fail' flag and
      replace it with 'setkey_error = -EINVAL' for the only test vector that
      used it -- the DES weak key test vector.  Note that this tightens the
      test to require -EINVAL rather than any error code, but AFAICS this
      won't cause any test failure.
      
      Other than that, these new fields aren't set on any test vectors yet.
      Later patches will do so.
      
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      5283a8ee
    • Vitaly Chikunov's avatar
      crypto: ecrdsa - add EC-RDSA test vectors to testmgr · 32fbdbd3
      Vitaly Chikunov authored
      
      Add testmgr test vectors for EC-RDSA algorithm for every of five
      supported parameters (curves). Because there are no officially published
      test vectors for the curves, the vectors are generated by gost-engine.
      
      Signed-off-by: default avatarVitaly Chikunov <vt@altlinux.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      32fbdbd3
    • Vitaly Chikunov's avatar
      crypto: ecrdsa - add EC-RDSA (GOST 34.10) algorithm · 0d7a7864
      Vitaly Chikunov authored
      
      Add Elliptic Curve Russian Digital Signature Algorithm (GOST R
      34.10-2012, RFC 7091, ISO/IEC 14888-3) is one of the Russian (and since
      2018 the CIS countries) cryptographic standard algorithms (called GOST
      algorithms). Only signature verification is supported, with intent to be
      used in the IMA.
      
      Summary of the changes:
      
      * crypto/Kconfig:
        - EC-RDSA is added into Public-key cryptography section.
      
      * crypto/Makefile:
        - ecrdsa objects are added.
      
      * crypto/asymmetric_keys/x509_cert_parser.c:
        - Recognize EC-RDSA and Streebog OIDs.
      
      * include/linux/oid_registry.h:
        - EC-RDSA OIDs are added to the enum. Also, a two currently not
          implemented curve OIDs are added for possible extension later (to
          not change numbering and grouping).
      
      * crypto/ecc.c:
        - Kenneth MacKay copyright date is updated to 2014, because
          vli_mmod_slow, ecc_point_add, ecc_point_mult_shamir are based on his
          code from micro-ecc.
        - Functions needed for ecrdsa are EXPORT_SYMBOL'ed.
        - New functions:
          vli_is_negative - helper to determine sign of vli;
          vli_from_be64 - unpack big-endian array into vli (used for
            a signature);
          vli_from_le64 - unpack little-endian array into vli (used for
            a public key);
          vli_uadd, vli_usub - add/sub u64 value to/from vli (used for
            increment/decrement);
          mul_64_64 - optimized to use __int128 where appropriate, this speeds
            up point multiplication (and as a consequence signature
            verification) by the factor of 1.5-2;
          vli_umult - multiply vli by a small value (speeds up point
            multiplication by another factor of 1.5-2, depending on vli sizes);
          vli_mmod_special - module reduction for some form of Pseudo-Mersenne
            primes (used for the curves A);
          vli_mmod_special2 - module reduction for another form of
            Pseudo-Mersenne primes (used for the curves B);
          vli_mmod_barrett - module reduction using pre-computed value (used
            for the curve C);
          vli_mmod_slow - more general module reduction which is much slower
           (used when the modulus is subgroup order);
          vli_mod_mult_slow - modular multiplication;
          ecc_point_add - add two points;
          ecc_point_mult_shamir - add two points multiplied by scalars in one
            combined multiplication (this gives speed up by another factor 2 in
            compare to two separate multiplications).
          ecc_is_pubkey_valid_partial - additional samity check is added.
        - Updated vli_mmod_fast with non-strict heuristic to call optimal
            module reduction function depending on the prime value;
        - All computations for the previously defined (two NIST) curves should
          not unaffected.
      
      * crypto/ecc.h:
        - Newly exported functions are documented.
      
      * crypto/ecrdsa_defs.h
        - Five curves are defined.
      
      * crypto/ecrdsa.c:
        - Signature verification is implemented.
      
      * crypto/ecrdsa_params.asn1, crypto/ecrdsa_pub_key.asn1:
        - Templates for BER decoder for EC-RDSA parameters and public key.
      
      Cc: linux-integrity@vger.kernel.org
      Signed-off-by: default avatarVitaly Chikunov <vt@altlinux.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      0d7a7864
    • Vitaly Chikunov's avatar
      crypto: ecc - make ecc into separate module · 4a2289da
      Vitaly Chikunov authored
      
      ecc.c have algorithms that could be used togeter by ecdh and ecrdsa.
      Make it separate module. Add CRYPTO_ECC into Kconfig. EXPORT_SYMBOL and
      document to what seems appropriate. Move structs ecc_point and ecc_curve
      from ecc_curve_defs.h into ecc.h.
      
      No code changes.
      
      Signed-off-by: default avatarVitaly Chikunov <vt@altlinux.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      4a2289da
    • Vitaly Chikunov's avatar
      crypto: Kconfig - create Public-key cryptography section · 3d6228a5
      Vitaly Chikunov authored
      
      Group RSA, DH, and ECDH into Public-key cryptography config section.
      
      Signed-off-by: default avatarVitaly Chikunov <vt@altlinux.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      3d6228a5
    • Vitaly Chikunov's avatar
      X.509: parse public key parameters from x509 for akcipher · f1774cb8
      Vitaly Chikunov authored
      
      Some public key algorithms (like EC-DSA) keep in parameters field
      important data such as digest and curve OIDs (possibly more for
      different EC-DSA variants). Thus, just setting a public key (as
      for RSA) is not enough.
      
      Append parameters into the key stream for akcipher_set_{pub,priv}_key.
      Appended data is: (u32) algo OID, (u32) parameters length, parameters
      data.
      
      This does not affect current akcipher API nor RSA ciphers (they could
      ignore it). Idea of appending parameters to the key stream is by Herbert
      Xu.
      
      Cc: David Howells <dhowells@redhat.com>
      Cc: Denis Kenzior <denkenz@gmail.com>
      Cc: keyrings@vger.kernel.org
      Signed-off-by: default avatarVitaly Chikunov <vt@altlinux.org>
      Reviewed-by: default avatarDenis Kenzior <denkenz@gmail.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      f1774cb8
    • Vitaly Chikunov's avatar
      KEYS: do not kmemdup digest in {public,tpm}_key_verify_signature · 83bc0299
      Vitaly Chikunov authored
      
      Treat (struct public_key_signature)'s digest same as its signature (s).
      Since digest should be already in the kmalloc'd memory do not kmemdup
      digest value before calling {public,tpm}_key_verify_signature.
      
      Patch is split from the previous as suggested by Herbert Xu.
      
      Suggested-by: default avatarDavid Howells <dhowells@redhat.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: keyrings@vger.kernel.org
      Signed-off-by: default avatarVitaly Chikunov <vt@altlinux.org>
      Reviewed-by: default avatarDenis Kenzior <denkenz@gmail.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      83bc0299
    • Vitaly Chikunov's avatar
      crypto: akcipher - new verify API for public key algorithms · c7381b01
      Vitaly Chikunov authored
      
      Previous akcipher .verify() just `decrypts' (using RSA encrypt which is
      using public key) signature to uncover message hash, which was then
      compared in upper level public_key_verify_signature() with the expected
      hash value, which itself was never passed into verify().
      
      This approach was incompatible with EC-DSA family of algorithms,
      because, to verify a signature EC-DSA algorithm also needs a hash value
      as input; then it's used (together with a signature divided into halves
      `r||s') to produce a witness value, which is then compared with `r' to
      determine if the signature is correct. Thus, for EC-DSA, nor
      requirements of .verify() itself, nor its output expectations in
      public_key_verify_signature() wasn't sufficient.
      
      Make improved .verify() call which gets hash value as input and produce
      complete signature check without any output besides status.
      
      Now for the top level verification only crypto_akcipher_verify() needs
      to be called and its return value inspected.
      
      Make sure that `digest' is in kmalloc'd memory (in place of `output`) in
      {public,tpm}_key_verify_signature() as insisted by Herbert Xu, and will
      be changed in the following commit.
      
      Cc: David Howells <dhowells@redhat.com>
      Cc: keyrings@vger.kernel.org
      Signed-off-by: default avatarVitaly Chikunov <vt@altlinux.org>
      Reviewed-by: default avatarDenis Kenzior <denkenz@gmail.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      c7381b01
    • Vitaly Chikunov's avatar
      crypto: rsa - unimplement sign/verify for raw RSA backends · 3ecc9725
      Vitaly Chikunov authored
      
      In preparation for new akcipher verify call remove sign/verify callbacks
      from RSA backends and make PKCS1 driver call encrypt/decrypt instead.
      
      This also complies with the well-known idea that raw RSA should never be
      used for sign/verify. It only should be used with proper padding scheme
      such as PKCS1 driver provides.
      
      Cc: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
      Cc: qat-linux@intel.com
      Cc: Tom Lendacky <thomas.lendacky@amd.com>
      Cc: Gary Hook <gary.hook@amd.com>
      Cc: Horia Geantă <horia.geanta@nxp.com>
      Cc: Aymen Sghaier <aymen.sghaier@nxp.com>
      Signed-off-by: default avatarVitaly Chikunov <vt@altlinux.org>
      Reviewed-by: default avatarHoria Geantă <horia.geanta@nxp.com>
      Acked-by: default avatarGary R Hook <gary.hook@amd.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      3ecc9725
    • Vitaly Chikunov's avatar
      crypto: akcipher - default implementations for request callbacks · 78a0324f
      Vitaly Chikunov authored
      
      Because with the introduction of EC-RDSA and change in workings of RSA
      in regard to sign/verify, akcipher could have not all callbacks defined,
      check the presence of callbacks in crypto_register_akcipher() and
      provide default implementation if the callback is not implemented.
      
      This is suggested by Herbert Xu instead of checking the presence of the
      callback on every request.
      
      Signed-off-by: default avatarVitaly Chikunov <vt@altlinux.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      78a0324f
    • Herbert Xu's avatar
      crypto: des_generic - Forbid 2-key in 3DES and add helpers · d7198ce4
      Herbert Xu authored
      
      This patch adds a requirement to the generic 3DES implementation
      such that 2-key 3DES (K1 == K3) is no longer allowed in FIPS mode.
      
      We will also provide helpers that may be used by drivers that
      implement 3DES to make the same check.
      
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      d7198ce4
Loading