1. 25 Apr, 2019 8 commits
  2. 19 Apr, 2019 2 commits
    • 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
  3. 18 Apr, 2019 30 commits