14 Jul, 2009

2 commits


08 Jul, 2009

1 commit


18 Jun, 2009

1 commit

  • FIPS-140 requires that all random number generators implement continuous self
    tests in which each extracted block of data is compared against the last block
    for repetition. The ansi_cprng implements such a test, but it would be nice if
    the hw rng's did the same thing. Obviously its not something thats always
    needed, but it seems like it would be a nice feature to have on occasion. I've
    written the below patch which allows individual entropy stores to be flagged as
    desiring a continuous test to be run on them as is extracted. By default this
    option is off, but is enabled in the event that fips mode is selected during
    bootup.

    Signed-off-by: Neil Horman
    Acked-by: Matt Mackall
    Signed-off-by: Herbert Xu

    Neil Horman
     

02 Jun, 2009

1 commit

  • We currently allocate temporary memory that is used for testing
    statically. This renders the testing engine non-reentrant. As
    algorithms may nest, i.e., one may construct another in order to
    carry out a part of its operation, this is unacceptable. For
    example, it has been reported that an AEAD implementation allocates
    a cipher in its setkey function, which causes it to fail during
    testing as the temporary memory is overwritten.

    This patch replaces the static memory with dynamically allocated
    buffers. We need a maximum of 16 pages so this slightly increases
    the chances of an algorithm failing due to memory shortage.
    However, as testing usually occurs at registration, this shouldn't
    be a big problem.

    Reported-by: Shasi Pulijala
    Signed-off-by: Herbert Xu

    Herbert Xu
     

18 Feb, 2009

1 commit

  • This is based on a report and patch by Geert Uytterhoeven.

    The functions crypto_alloc_tfm and create_create_tfm return a
    pointer that needs to be adjusted by the caller when successful
    and otherwise an error value. This means that the caller has
    to check for the error and only perform the adjustment if the
    pointer returned is valid.

    Since all callers want to make the adjustment and we know how
    to adjust it ourselves, it's much easier to just return adjusted
    pointer directly.

    The only caveat is that we have to return a void * instead of
    struct crypto_tfm *. However, this isn't that bad because both
    of these functions are for internal use only (by types code like
    shash.c, not even algorithms code).

    This patch also moves crypto_alloc_tfm into crypto/internal.h
    (crypto_create_tfm is already there) to reflect this.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

25 Dec, 2008

1 commit

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

    Herbert Xu
     

29 Aug, 2008

4 commits


10 Jul, 2008

1 commit


11 Jan, 2008

2 commits

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

    Herbert Xu
     
  • The scatterwalk infrastructure is used by algorithms so it needs to
    move out of crypto for future users that may live in drivers/crypto
    or asm/*/crypto.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

11 Oct, 2007

1 commit

  • When scatterwalk is built as a module digest.c was broken because it
    requires the crypto_km_types structure which is in scatterwalk. This
    patch removes the crypto_km_types structure by encoding the logic into
    crypto_kmap_type directly.

    In fact, this even saves a few bytes of code (not to mention the data
    structure itself) on i386 which is about the only place where it's
    needed.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

07 Feb, 2007

2 commits


21 Sep, 2006

9 commits

  • This patch removes the old HMAC implementation now that nobody uses it
    anymore.

    Signed-off-by: Herbert Xu
    Signed-off-by: David S. Miller

    Herbert Xu
     
  • This patch adds two block cipher algorithms, CBC and ECB. These
    are implemented as templates on top of existing single-block cipher
    algorithms. They invoke the single-block cipher through the new
    encrypt_one/decrypt_one interface.

    This also optimises the in-place encryption and decryption to remove
    the cost of an IV copy each round.

    Signed-off-by: Herbert Xu

    Herbert Xu
     
  • The sleeping flag used to determine whether crypto_yield can actually
    yield is really a per-operation flag rather than a per-tfm flag. This
    patch changes crypto_yield to take a flag directly so that we can start
    using a per-operation flag instead the tfm flag.

    Signed-off-by: Herbert Xu

    Herbert Xu
     
  • When the final result location is unaligned, we store the digest in a
    temporary buffer before copying it to the final location. Currently
    that buffer sits on the stack. This patch moves it to an area in the
    tfm, just like the CBC IV buffer.

    Signed-off-by: Herbert Xu

    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: Herbert Xu
    Signed-off-by: David S. Miller

    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: Herbert Xu
    Signed-off-by: David S. Miller

    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: Herbert Xu
    Signed-off-by: David S. Miller

    Herbert Xu
     
  • A crypto_template generates a crypto_alg object when given a set of
    parameters. this patch adds the basic data structure fo templates
    and code to handle their registration/deregistration.

    Signed-off-by: Herbert Xu
    Signed-off-by: David S. Miller

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

    Herbert Xu
     

10 Jan, 2006

1 commit

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

    Herbert Xu
     

02 Sep, 2005

1 commit

  • 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: Herbert Xu
    Signed-off-by: David S. Miller

    Herbert Xu
     

15 Jul, 2005

1 commit


07 Jul, 2005

3 commits

  • This patch ensures that cit_iv is aligned according to cra_alignmask
    by allocating it as part of the tfm structure. As a side effect the
    crypto layer will also guarantee that the tfm ctx area has enough space
    to be aligned by cra_alignmask. This allows us to remove the extra
    space reservation from the Padlock driver.

    Signed-off-by: Herbert Xu
    Signed-off-by: David S. Miller

    Herbert Xu
     
  • This patch makes a needlessly global function static.

    Signed-off-by: Adrian Bunk
    Signed-off-by: Herbert Xu
    Signed-off-by: David S. Miller

    Adrian Bunk
     
  • This patch adds hooks for cipher algorithms to implement multi-block
    ECB/CBC operations directly. This is expected to provide significant
    performance boots to the VIA Padlock.

    It could also be used for improving software implementations such as
    AES where operating on multiple blocks at a time may enable certain
    optimisations.

    Signed-off-by: Herbert Xu
    Signed-off-by: David S. Miller

    Herbert Xu
     

24 May, 2005

1 commit

  • The netlink gfp_any() problem made me double-check the uses of in_softirq()
    in crypto/*. It seems to me that we should be checking in_atomic() instead
    of in_softirq() in crypto_yield. Otherwise people calling the crypto ops
    with spin locks held or preemption disabled will get burnt, right?

    Signed-off-by: David S. Miller

    Herbert Xu
     

17 Apr, 2005

1 commit

  • 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!

    Linus Torvalds