1. 26 May, 2010 1 commit
  2. 13 Aug, 2009 1 commit
    • Herbert Xu's avatar
      crypto: ctr - Use chainiv on raw counter mode · aef27136
      Herbert Xu authored
      Raw counter mode only works with chainiv, which is no longer
      the default IV generator on SMP machines.  This broke raw counter
      mode as it can no longer instantiate as a givcipher.
      This patch fixes it by always picking chainiv on raw counter
      mode.  This is based on the diagnosis and a patch by Huang
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
  3. 10 Jan, 2008 6 commits
    • Herbert Xu's avatar
      [CRYPTO] seqiv: Add Sequence Number IV Generator · 0a270321
      Herbert Xu authored
      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: default avatarHerbert Xu <herbert@gondor.apana.org.au>
    • Herbert Xu's avatar
      [CRYPTO] ctr: Refactor into ctr and rfc3686 · 5311f248
      Herbert Xu authored
      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: default avatarHerbert Xu <herbert@gondor.apana.org.au>
    • Herbert Xu's avatar
      [CRYPTO] ctr: Fix multi-page processing · 0971eb0d
      Herbert Xu authored
      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
      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: default avatarHerbert Xu <herbert@gondor.apana.org.au>
    • Herbert Xu's avatar
      [CRYPTO] ctr: Use crypto_inc and crypto_xor · 3f8214ea
      Herbert Xu authored
      This patch replaces the custom inc/xor in CTR with the generic functions.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
    • Joy Latten's avatar
      [CRYPTO] ctr: Add countersize · 41fdab3d
      Joy Latten authored
      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: default avatarJoy Latten <latten@austin.ibm.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
    • Joy Latten's avatar
      [CRYPTO] ctr: Add CTR (Counter) block cipher mode · 23e353c8
      Joy Latten authored
      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.
      So for example,
      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: default avatarJoy Latten <latten@austin.ibm.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>