18 Jul, 2016

1 commit

  • This patch removes the old crypto_grab_skcipher helper and replaces
    it with crypto_grab_skcipher2.

    As this is the final entry point into givcipher this patch also
    removes all traces of the top-level givcipher interface, including
    all implicit IV generators such as chainiv.

    The bottom-level givcipher interface remains until the drivers
    using it are converted.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

07 Jun, 2016

1 commit


09 Dec, 2015

1 commit

  • Some ciphers actually support encrypting zero length plaintexts. For
    example, many AEAD modes support this. The resulting ciphertext for
    those winds up being only the authentication tag, which is a result of
    the key, the iv, the additional data, and the fact that the plaintext
    had zero length. The blkcipher constructors won't copy the IV to the
    right place, however, when using a zero length input, resulting in
    some significant problems when ciphers call their initialization
    routines, only to find that the ->iv parameter is uninitialized. One
    such example of this would be using chacha20poly1305 with a zero length
    input, which then calls chacha20, which calls the key setup routine,
    which eventually OOPSes due to the uninitialized ->iv member.

    Signed-off-by: Jason A. Donenfeld
    Cc:
    Signed-off-by: Herbert Xu

    Jason A. Donenfeld
     

20 Oct, 2015

1 commit

  • Currently a number of Crypto API operations may fail when a signal
    occurs. This causes nasty problems as the caller of those operations
    are often not in a good position to restart the operation.

    In fact there is currently no need for those operations to be
    interrupted by user signals at all. All we need is for them to
    be killable.

    This patch replaces the relevant calls of signal_pending with
    fatal_signal_pending, and wait_for_completion_interruptible with
    wait_for_completion_killable, respectively.

    Cc: stable@vger.kernel.org
    Signed-off-by: Herbert Xu

    Herbert Xu
     

22 Jun, 2015

1 commit

  • Currently for skcipher IV generators they must provide givencrypt
    as that is the whole point. We are currently replacing skcipher
    IV generators with explicit IV generators. In order to maintain
    backwards compatibility, we need to allow the IV generators to
    still function as a normal skcipher when the RNG Is not present
    (e.g., in the initramfs during boot). IOW everything but givencrypt
    and givdecrypt will still work but those two will fail.

    Therefore this patch assigns a default givencrypt that simply
    returns an error should it be NULL.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

25 May, 2015

1 commit


26 Apr, 2015

1 commit


26 Jan, 2015

1 commit


22 Dec, 2014

1 commit

  • Fixed style errors reported by checkpatch.

    WARNING: Missing a blank line after declarations
    + u8 *end_page = (u8 *)(((unsigned long)(start + len - 1)) & PAGE_MASK);
    + return max(start, end_page);

    WARNING: line over 80 characters
    + scatterwalk_start(&walk->out, scatterwalk_sg_next(walk->out.sg));

    WARNING: Missing a blank line after declarations
    + int err = ablkcipher_copy_iv(walk, tfm, alignmask);
    + if (err)

    ERROR: do not use assignment in if condition
    + if ((err = crypto_register_instance(tmpl, inst))) {

    Signed-off-by: Joshua I. James
    Signed-off-by: Herbert Xu

    Joshua I. James
     

30 Oct, 2013

1 commit

  • Previously we would use eseqiv on all async ciphers in all cases,
    and sync ciphers if we have more than one CPU. This meant that
    chainiv is only used in the case of sync ciphers on a UP machine.

    As chainiv may aid attackers by making the IV predictable, even
    though this risk itself is small, the above usage pattern causes
    it to further leak information about the host.

    This patch addresses these issues by using eseqiv even if we're
    on a UP machine.

    Signed-off-by: Herbert Xu
    Acked-by: Steffen Klassert
    Acked-by: David S. Miller

    Herbert Xu
     

19 Feb, 2013

1 commit

  • Three errors resulting in kernel memory disclosure:

    1/ The structures used for the netlink based crypto algorithm report API
    are located on the stack. As snprintf() does not fill the remainder of
    the buffer with null bytes, those stack bytes will be disclosed to users
    of the API. Switch to strncpy() to fix this.

    2/ crypto_report_one() does not initialize all field of struct
    crypto_user_alg. Fix this to fix the heap info leak.

    3/ For the module name we should copy only as many bytes as
    module_name() returns -- not as much as the destination buffer could
    hold. But the current code does not and therefore copies random data
    from behind the end of the module name, as the module name is always
    shorter than CRYPTO_MAX_ALG_NAME.

    Also switch to use strncpy() to copy the algorithm's name and
    driver_name. They are strings, after all.

    Signed-off-by: Mathias Krause
    Cc: Steffen Klassert
    Signed-off-by: Herbert Xu

    Mathias Krause
     

11 Apr, 2012

1 commit


02 Apr, 2012

1 commit


29 Mar, 2012

1 commit

  • We lookup algorithms with crypto_alg_mod_lookup() when instantiating via
    crypto_add_alg(). However, algorithms that are wrapped by an IV genearator
    (e.g. aead or genicv type algorithms) need special care. The userspace
    process hangs until it gets a timeout when we use crypto_alg_mod_lookup()
    to lookup these algorithms. So export the lookup functions for these
    algorithms and use them in crypto_add_alg().

    Signed-off-by: Steffen Klassert
    Signed-off-by: Herbert Xu

    Steffen Klassert
     

11 Nov, 2011

1 commit


21 Oct, 2011

2 commits


29 Jan, 2011

1 commit


23 Jun, 2010

1 commit

  • Stanse found a potential NULL dereference in ablkcipher_next_slow.
    Even though kmalloc fails, its retval is dereferenced later. Return
    from that function properly earlier.

    Signed-off-by: Jiri Slaby
    Acked-by: David S. Miller
    Signed-off-by: Herbert Xu

    Jiri Slaby
     

19 May, 2010

1 commit

  • These are akin to the blkcipher_walk helpers.

    The main differences in the async variant are:

    1) Only physical walking is supported. We can't hold on to
    kmap mappings across the async operation to support virtual
    ablkcipher_walk operations anyways.

    2) Bounce buffers used for async more need to be persistent and
    freed at a later point in time when the async op completes.
    Therefore we maintain a list of writeback buffers and require
    that the ablkcipher_walk user call the 'complete' operation
    so we can copy the bounce buffers out to the real buffers and
    free up the bounce buffer chunks.

    These interfaces will be used by the new Niagara2 crypto driver.

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

    David S. Miller
     

16 Feb, 2010

1 commit


14 Aug, 2009

1 commit

  • Recently we switched to using eseqiv on SMP machines in preference
    over chainiv. However, eseqiv does not support stream ciphers so
    they should still default to chainiv.

    This patch applies the same check as done by eseqiv to weed out
    the stream ciphers. In particular, all algorithms where the IV
    size is not equal to the block size will now default to chainiv.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

25 Jun, 2009

2 commits

  • As it stands we use chainiv for sync algorithms and eseqiv for
    async algorithms. However, when there is more than one CPU
    chainiv forces all processing to be serialised which is usually
    not what you want. Also, the added overhead of eseqiv isn't that
    great.

    Therefore this patch changes the default sync geniv on SMP machines
    to eseqiv. For the odd situation where the overhead is unacceptable
    then chainiv is still available as an option.

    Note that on UP machines chainiv is still preferred over eseqiv
    for sync algorithms.

    Signed-off-by: Herbert Xu

    Herbert Xu
     
  • When a sync givcipher algorithm is requested, if an async version
    of the same algorithm already exists, then we will loop forever
    without ever constructing the sync version based on a blkcipher.

    This is because we did not include the requested type/mask when
    getting a larval for the geniv algorithm that is to be constructed.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

18 Feb, 2009

1 commit

  • When an skcipher constructed through crypto_givcipher_default fails
    its selftest, we'll loop forever trying to construct new skcipher
    objects but failing because it already exists.

    The crux of the issue is that once a givcipher fails the selftest,
    we'll ignore it on the next run through crypto_skcipher_lookup and
    attempt to construct a new givcipher.

    We should instead return an error to the caller if we find a
    givcipher that has failed the test.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

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