23 Feb, 2008

1 commit


11 Jan, 2008

6 commits

  • This patch adds an async field to /proc/crypto for ablkcipher and aead
    algorithms.

    Signed-off-by: Herbert Xu

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

    Herbert Xu
     
  • This patch creates the infrastructure to help the construction of givcipher
    templates that wrap around existing blkcipher/ablkcipher algorithms by adding
    an IV generator to them.

    Signed-off-by: Herbert Xu

    Herbert Xu
     
  • This patch introduces the geniv field which indicates the default IV
    generator for each algorithm. It should point to a string that is not
    freed as long as the algorithm is registered.

    Signed-off-by: Herbert Xu

    Herbert Xu
     
  • Different block cipher modes have different requirements for intialisation
    vectors. For example, CBC can use a simple randomly generated IV while
    modes such as CTR must use an IV generation mechanisms that give a stronger
    guarantee on the lack of collisions. Furthermore, disk encryption modes
    have their own IV generation algorithms.

    Up until now IV generation has been left to the users of the symmetric
    key cipher API. This is inconvenient as the number of block cipher modes
    increase because the user needs to be aware of which mode is supposed to
    be paired with which IV generation algorithm.

    Therefore it makes sense to integrate the IV generation into the crypto
    API. This patch takes the first step in that direction by creating two
    new ablkcipher operations, givencrypt and givdecrypt that generates an
    IV before performing the actual encryption or decryption.

    The operations are currently not exposed to the user. That will be done
    once the underlying functionality has actually been implemented.

    It also creates the underlying givcipher type. Algorithms that directly
    generate IVs would use it instead of ablkcipher. All other algorithms
    (including all existing ones) would generate a givcipher algorithm upon
    registration. This givcipher algorithm will be constructed from the geniv
    string that's stored in every algorithm. That string will locate a template
    which is instantiated by the blkcipher/ablkcipher algorithm in question to
    give a givcipher algorithm.

    Signed-off-by: Herbert Xu

    Herbert Xu
     
  • Note: From now on the collective of ablkcipher/blkcipher/givcipher will
    be known as skcipher, i.e., symmetric key cipher. The name blkcipher has
    always been much of a misnomer since it supports stream ciphers too.

    This patch adds the function crypto_grab_skcipher as a new way of getting
    an ablkcipher spawn. The problem is that previously we did this in two
    steps, first getting the algorithm and then calling crypto_init_spawn.

    This meant that each spawn user had to be aware of what type and mask to
    use for these two steps. This is difficult and also presents a problem
    when the type/mask changes as they're about to be for IV generators.

    The new interface does both steps together just like crypto_alloc_ablkcipher.

    As a side-effect this also allows us to be stronger on type enforcement
    for spawns. For now this is only done for ablkcipher but it's trivial
    to extend for other types.

    This patch also moves the type/mask logic for skcipher into the helpers
    crypto_skcipher_type and crypto_skcipher_mask.

    Finally this patch introduces the function crypto_require_sync to determine
    whether the user is specifically requesting a sync algorithm.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

11 Oct, 2007

2 commits


06 Aug, 2007

1 commit


11 Jul, 2007

2 commits


02 May, 2007

1 commit