22 Jun, 2015

1 commit

  • The RNG may not be available during early boot, e.g., the relevant
    modules may not be included in the initramfs. As the RNG Is only
    needed for IPsec, we should not let this prevent use of ciphers
    without IV generators, e.g., for disk encryption.

    This patch postpones the RNG allocation to the init function so
    that one failure during early boot does not make the RNG unavailable
    for all subsequent users of the same cipher.

    More importantly, it lets the cipher live even if RNG allocation
    fails. Of course we no longer offer IV generation and which will
    fail with an error if invoked. But all other cipher capabilities
    will function as usual.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

04 Jun, 2015

1 commit

  • We currently do the IV seeding on the first givencrypt call in
    order to conserve entropy. However, this does not work with
    DRBG which cannot be called from interrupt context. In fact,
    with DRBG we don't need to conserve entropy anyway. So this
    patch moves the seeding into the init function.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

26 Nov, 2014

1 commit

  • This adds the module loading prefix "crypto-" to the template lookup
    as well.

    For example, attempting to load 'vfat(blowfish)' via AF_ALG now correctly
    includes the "crypto-" prefix at every level, correctly rejecting "vfat":

    net-pf-38
    algif-hash
    crypto-vfat(blowfish)
    crypto-vfat(blowfish)-all
    crypto-vfat

    Reported-by: Mathias Krause
    Signed-off-by: Kees Cook
    Acked-by: Mathias Krause
    Signed-off-by: Herbert Xu

    Kees Cook
     

01 Aug, 2014

1 commit


02 Dec, 2010

1 commit


15 Apr, 2009

1 commit

  • If crypto_ablkcipher_encrypt() returns synchronous,
    eseqiv_complete2() is called even if req->giv is already the
    pointer to the generated IV. The generated IV is overwritten
    with some random data in this case. This patch fixes this by
    calling eseqiv_complete2() just if the generated IV has to be
    copied to req->giv.

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

    Steffen Klassert
     

29 Aug, 2008

2 commits


01 May, 2008

1 commit

  • After attaching the IV to the head during encryption, eseqiv does not
    increase the encryption length by that amount. As such the last block
    of the actual plain text will be left unencrypted.

    Fortunately the only user of this code hifn currently crashes so this
    shouldn't affect anyone :)

    Signed-off-by: Herbert Xu

    Herbert Xu
     

08 Mar, 2008

1 commit


23 Feb, 2008

1 commit


11 Jan, 2008

1 commit

  • This generator generates an IV based on a sequence number by xoring it
    with a salt and then encrypting it with the same key as used to encrypt
    the plain text. This algorithm requires that the block size be equal
    to the IV size. It is mainly useful for CBC.

    It has one noteworthy property that for IPsec the IV happens to lie
    just before the plain text so the IV generation simply increases the
    number of encrypted blocks by one. Therefore the cost of this generator
    is entirely dependent on the speed of the underlying cipher.

    Signed-off-by: Herbert Xu

    Herbert Xu