11 Jan, 2008

6 commits

  • This generator generates an IV based on a sequence number by xoring it
    with a salt. This algorithm is mainly useful for CTR and similar modes.

    This patch also sets it as the default IV generator for ctr.

    Signed-off-by: Herbert Xu

    Herbert Xu
     
  • As discussed previously, this patch moves the basic CTR functionality
    into a chainable algorithm called ctr. The IPsec-specific variant of
    it is now placed on top with the name rfc3686.

    So ctr(aes) gives a chainable cipher with IV size 16 while the IPsec
    variant will be called rfc3686(ctr(aes)). This patch also adjusts
    gcm accordingly.

    Signed-off-by: Herbert Xu

    Herbert Xu
     
  • When the data spans across a page boundary, CTR may incorrectly process
    a partial block in the middle because the blkcipher walking code may
    supply partial blocks in the middle as long as the total length of the
    supplied data is more than a block. CTR is supposed to return any unused
    partial block in that case to the walker.

    This patch fixes this by doing exactly that, returning partial blocks to
    the walker unless we received less than a block-worth of data to start
    with.

    This also allows us to optimise the bulk of the processing since we no
    longer have to worry about partial blocks until the very end.

    Thanks to Tan Swee Heng for fixes and actually testing this :)

    Signed-off-by: Herbert Xu

    Herbert Xu
     
  • This patch replaces the custom inc/xor in CTR with the generic functions.

    Signed-off-by: Herbert Xu

    Herbert Xu
     
  • This patch adds countersize to CTR mode.
    The template is now ctr(algo,noncesize,ivsize,countersize).

    For example, ctr(aes,4,8,4) indicates the counterblock
    will be composed of a salt/nonce that is 4 bytes, an iv
    that is 8 bytes and the counter is 4 bytes.

    When noncesize + ivsize < blocksize, CTR initializes the
    last block - ivsize - noncesize portion of the block to
    zero. Otherwise the counter block is composed of the IV
    (and nonce if necessary).

    If noncesize + ivsize == blocksize, then this indicates that
    user is passing in entire counterblock. Thus countersize
    indicates the amount of bytes in counterblock to use as
    the counter for incrementing. CTR will increment counter
    portion by 1, and begin encryption with that value.

    Note that CTR assumes the counter portion of the block that
    will be incremented is stored in big endian.

    Signed-off-by: Joy Latten
    Signed-off-by: Herbert Xu

    Joy Latten
     
  • This patch implements CTR mode for IPsec.
    It is based off of RFC 3686.

    Please note:
    1. CTR turns a block cipher into a stream cipher.
    Encryption is done in blocks, however the last block
    may be a partial block.

    A "counter block" is encrypted, creating a keystream
    that is xor'ed with the plaintext. The counter portion
    of the counter block is incremented after each block
    of plaintext is encrypted.
    Decryption is performed in same manner.

    2. The CTR counterblock is composed of,
    nonce + IV + counter

    The size of the counterblock is equivalent to the
    blocksize of the cipher.
    sizeof(nonce) + sizeof(IV) + sizeof(counter) = blocksize

    The CTR template requires the name of the cipher
    algorithm, the sizeof the nonce, and the sizeof the iv.
    ctr(cipher,sizeof_nonce,sizeof_iv)

    So for example,
    ctr(aes,4,8)
    specifies the counterblock will be composed of 4 bytes
    from a nonce, 8 bytes from the iv, and 4 bytes for counter
    since aes has a blocksize of 16 bytes.

    3. The counter portion of the counter block is stored
    in big endian for conformance to rfc 3686.

    Signed-off-by: Joy Latten
    Signed-off-by: Herbert Xu

    Joy Latten