1. 16 May, 2018 1 commit
  2. 05 Jan, 2018 1 commit
  3. 23 Apr, 2015 1 commit
  4. 31 Mar, 2015 1 commit
  5. 31 Oct, 2011 1 commit
  6. 26 Jul, 2011 1 commit
  7. 18 Nov, 2009 1 commit
  8. 12 Nov, 2009 1 commit
  9. 19 Oct, 2009 1 commit
  10. 25 Dec, 2008 1 commit
  11. 29 Aug, 2008 3 commits
  12. 21 Apr, 2008 2 commits
  13. 16 Jul, 2007 1 commit
  14. 12 Feb, 2007 1 commit
  15. 21 Sep, 2006 3 commits
    • Herbert Xu's avatar
      [CRYPTO] api: Added crypto_type support · e853c3cf
      Herbert Xu authored
      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: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      e853c3cf
    • Herbert Xu's avatar
      [CRYPTO] api: Split out low-level API · cce9e06d
      Herbert Xu authored
      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: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      cce9e06d
    • Herbert Xu's avatar
      [CRYPTO] api: Add crypto_alg reference counting · 6521f302
      Herbert Xu authored
      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: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      6521f302
  16. 09 Jan, 2006 1 commit
    • Herbert Xu's avatar
      [CRYPTO] Allow multiple implementations of the same algorithm · 5cb1454b
      Herbert Xu authored
      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: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      5cb1454b
  17. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4