1. 18 2月, 2009 1 次提交
  2. 05 2月, 2009 1 次提交
  3. 25 12月, 2008 2 次提交
    • H
      crypto: api - Rebirth of crypto_alloc_tfm · 7b0bac64
      Herbert Xu 提交于
      This patch reintroduces a completely revamped crypto_alloc_tfm.
      The biggest change is that we now take two crypto_type objects
      when allocating a tfm, a frontend and a backend.  In fact this
      simply formalises what we've been doing behind the API's back.
      
      For example, as it stands crypto_alloc_ahash may use an
      actual ahash algorithm or a crypto_hash algorithm.  Putting
      this in the API allows us to do this much more cleanly.
      
      The existing types will be converted across gradually.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      7b0bac64
    • H
      crypto: api - Move type exit function into crypto_tfm · 4a779486
      Herbert Xu 提交于
      The type exit function needs to undo any allocations done by the type
      init function.  However, the type init function may differ depending
      on the upper-level type of the transform (e.g., a crypto_blkcipher
      instantiated as a crypto_ablkcipher).
      
      So we need to move the exit function out of the lower-level
      structure and into crypto_tfm itself.
      
      As it stands this is a no-op since nobody uses exit functions at
      all.  However, all cases where a lower-level type is instantiated
      as a different upper-level type (such as blkcipher as ablkcipher)
      will be converted such that they allocate the underlying transform
      and use that instead of casting (e.g., crypto_ablkcipher casted
      into crypto_blkcipher).  That will need to use a different exit
      function depending on the upper-level type.
      
      This patch also allows the type init/exit functions to call (or not)
      cra_init/cra_exit instead of always calling them from the top level.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      4a779486
  4. 29 8月, 2008 2 次提交
  5. 10 7月, 2008 1 次提交
  6. 21 4月, 2008 1 次提交
  7. 11 1月, 2008 1 次提交
    • H
      [CRYPTO] skcipher: Create default givcipher instances · b9c55aa4
      Herbert Xu 提交于
      This patch makes crypto_alloc_ablkcipher/crypto_grab_skcipher always
      return algorithms that are capable of generating their own IVs through
      givencrypt and givdecrypt.  Each algorithm may specify its default IV
      generator through the geniv field.
      
      For algorithms that do not set the geniv field, the blkcipher layer will
      pick a default.  Currently it's chainiv for synchronous algorithms and
      eseqiv for asynchronous algorithms.  Note that if these wrappers do not
      work on an algorithm then that algorithm must specify its own geniv or
      it can't be used at all.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      b9c55aa4
  8. 20 10月, 2007 1 次提交
  9. 11 7月, 2007 1 次提交
  10. 19 5月, 2007 1 次提交
  11. 07 2月, 2007 2 次提交
  12. 07 12月, 2006 1 次提交
  13. 11 10月, 2006 1 次提交
  14. 21 9月, 2006 11 次提交
    • H
      [CRYPTO] api: Add crypto_comp and crypto_has_* · fce32d70
      Herbert Xu 提交于
      This patch adds the crypto_comp type to complete the compile-time checking
      conversion.  The functions crypto_has_alg and crypto_has_cipher, etc. are
      also added to replace crypto_alg_available.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      fce32d70
    • H
      [CRYPTO] api: Added crypto_type support · e853c3cf
      Herbert Xu 提交于
      This patch adds the crypto_type structure which will be used for all new
      crypto algorithm types, beginning with block ciphers.
      
      The primary purpose of this abstraction is to allow different crypto_type
      objects for crypto algorithms of the same type, in particular, there will
      be a different crypto_type objects for asynchronous algorithms.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      e853c3cf
    • H
      [CRYPTO] api: Added crypto_alloc_base · 6d7d684d
      Herbert Xu 提交于
      Up until now all crypto transforms have been of the same type, struct
      crypto_tfm, regardless of whether they are ciphers, digests, or other
      types.  As a result of that, we check the types at run-time before
      each crypto operation.
      
      This is rather cumbersome.  We could instead use different C types for
      each crypto type to ensure that the correct types are used at compile
      time.  That is, we would have crypto_cipher/crypto_digest instead of
      just crypto_tfm.  The appropriate type would then be required for the
      actual operations such as crypto_digest_digest.
      
      Now that we have the type/mask fields when looking up algorithms, it
      is easy to request for an algorithm of the precise type that the user
      wants.  However, crypto_alloc_tfm currently does not expose these new
      attributes.
      
      This patch introduces the function crypto_alloc_base which will carry
      these new parameters.  It will be renamed to crypto_alloc_tfm once
      all existing users have been converted.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      6d7d684d
    • H
      [CRYPTO] api: Added asynchronous flag · f3f632d6
      Herbert Xu 提交于
      This patch adds the asynchronous flag and changes all existing users to
      only look up algorithms that are synchronous.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      f3f632d6
    • H
      [CRYPTO] api: Added spawns · 6bfd4809
      Herbert Xu 提交于
      Spawns lock a specific crypto algorithm in place.  They can then be used
      with crypto_spawn_tfm to allocate a tfm for that algorithm.  When the base
      algorithm of a spawn is deregistered, all its spawns will be automatically
      removed.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6bfd4809
    • H
      [CRYPTO] api: Allow algorithm lookup by type · 492e2b63
      Herbert Xu 提交于
      This patch also adds the infrastructure to pick an algorithm based on
      their type.  For example, this allows you to select the encryption
      algorithm "aes", instead of any algorithm registered under the name
      "aes".  For now this is only accessible internally.  Eventually it
      will be made available through crypto_alloc_tfm.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      492e2b63
    • H
      [CRYPTO] api: Add cryptomgr · 2b8c19db
      Herbert Xu 提交于
      The cryptomgr module is a simple manager of crypto algorithm instances.
      It ensures that parameterised algorithms of the type tmpl(alg) (e.g.,
      cbc(aes)) are always created.
      
      This is meant to satisfy the needs for most users.  For more complex
      cases such as deeper combinations or multiple parameters, a netlink
      module will be created which allows arbitrary expressions to be parsed
      in user-space.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2b8c19db
    • H
      [CRYPTO] api: Added event notification · 2825982d
      Herbert Xu 提交于
      This patch adds a notifier chain for algorithm/template registration events.
      This will be used to register compound algorithms such as cbc(aes).  In
      future this will also be passed onto user-space through netlink.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2825982d
    • H
      [CRYPTO] api: Split out low-level API · cce9e06d
      Herbert Xu 提交于
      The crypto API is made up of the part facing users such as IPsec and the
      low-level part which is used by cryptographic entities such as algorithms.
      This patch splits out the latter so that the two APIs are more clearly
      delineated.  As a bonus the low-level API can now be modularised if all
      algorithms are built as modules.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      cce9e06d
    • H
      [CRYPTO] api: Add crypto_alg reference counting · 6521f302
      Herbert Xu 提交于
      Up until now we've relied on module reference counting to ensure that the
      crypto_alg structures don't disappear from under us.  This was good enough
      as long as each crypto_alg came from exactly one module.
      
      However, with parameterised crypto algorithms a crypto_alg object may need
      two or more modules to operate.  This means that we need to count the
      references to the crypto_alg object directly.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6521f302
    • H
      [CRYPTO] api: Rename crypto_alg_get to crypto_mod_get · 72fa4919
      Herbert Xu 提交于
      The functions crypto_alg_get and crypto_alg_put operates on the crypto
      modules rather than the algorithms.  Therefore it makes sense to call
      them crypto_mod_get and crypto_alg_put respectively.
      
      This is needed because we need to have real algorithm reference counters
      for parameterised algorithms as they can be unregistered from below by
      when their parameter algorithms are themselves unregistered.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      72fa4919
  15. 26 6月, 2006 3 次提交
  16. 21 3月, 2006 2 次提交
  17. 10 1月, 2006 2 次提交
    • H
      [CRYPTO] api: Require block size to be less than PAGE_SIZE/8 · 7302533a
      Herbert Xu 提交于
      The cipher code path may allocate up to two blocks of data on the stack.
      Therefore we need to place limits on the maximum block size.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      7302533a
    • H
      [CRYPTO] Allow multiple implementations of the same algorithm · 5cb1454b
      Herbert Xu 提交于
      This is the first step on the road towards asynchronous support in
      the Crypto API.  It adds support for having multiple crypto_alg objects
      for the same algorithm registered in the system.
      
      For example, each device driver would register a crypto_alg object
      for each algorithm that it supports.  While at the same time the
      user may load software implementations of those same algorithms.
      
      Users of the Crypto API may then select a specific implementation
      by name, or choose any implementation for a given algorithm with
      the highest priority.
      
      The priority field is a 32-bit signed integer.  In future it will be
      possible to modify it from user-space.
      
      This also provides a solution to the problem of selecting amongst
      various AES implementations, that is, aes vs. aes-i586 vs. aes-padlock.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      5cb1454b
  18. 30 10月, 2005 1 次提交
  19. 02 9月, 2005 1 次提交
    • H
      [CRYPTO]: Added CRYPTO_TFM_REQ_MAY_SLEEP flag · 64baf3cf
      Herbert Xu 提交于
      The crypto layer currently uses in_atomic() to determine whether it is
      allowed to sleep.  This is incorrect since spin locks don't always cause
      in_atomic() to return true.
      
      Instead of that, this patch returns to an earlier idea of a per-tfm flag
      which determines whether sleeping is allowed.  Unlike the earlier version,
      the default is to not allow sleeping.  This ensures that no existing code
      can break.
      
      As usual, this flag may either be set through crypto_alloc_tfm(), or
      just before a specific crypto operation.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      64baf3cf
  20. 07 7月, 2005 4 次提交