Home | History | Annotate | Download | only in doc

Lines Matching full:octets

98 







Crypto Forum Research Group                              David A. McGrew
Internet Draft                                       Cisco Systems, Inc.
Expires April, 2003                                        October, 2002



                          Integer Counter Mode
                       <draft-irtf-cfrg-icm-00.txt>


Status of this Memo

   This document is an Internet Draft and is in full conformance with
   all provisions of Section 10 of RFC-2026. Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and working groups.  Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet Drafts as reference
   material or to cite them other than as "work in progress."

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.


1. Abstract


  This document specifies Integer Counter Mode (ICM), a mode of
  operation of a block cipher which defines an indexed keystream
  generator (which generates a keystream segment given an index).
  This mode is efficient, parallelizable, and has been proven secure
  given realistic assumptions about the block cipher.  Test vectors
  are provided for AES.

  Counter Mode admits many variations.  The variant specified in
  this document is secure and flexible, yet it enables a single
  implementation of a keystream generator to suffice in different
  application domains.






McGrew                                                          [Page 1]


Internet Draft            Integer Counter Mode             October, 2002


2. Notational Conventions

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
  this document are to be interpreted as described in RFC-2119 [B97].


3. Introduction

  Counter Mode is a way to define a pseudorandom keystream generator
  using a block cipher [CTR].  The keystream can be used for additive
  encryption, key derivation, or any other application requiring
  pseudorandom data.

  In ICM, the keystream is logically broken into segments.  Each
  segment is identified with a segment index, and the segments have
  equal lengths.  This segmentation makes ICM especially appropriate
  for securing packet-based protocols.


4. ICM

  In this section, ICM keystream generation and encryption are
  defined.


4.1. ICM Parameters

  The following parameters are used in ICM.  These parameters MUST
  remain fixed for any given use of a key.

  Parameter              Meaning
  -----------------------------------------------------------------
  BLOCK_LENGTH           the number of octets in the cipher block
  KEY_LENGTH             the number of octets in the cipher key
  OFFSET_LENGTH          the number of octets in the offset
  SEGMENT_INDEX_LENGTH   the number of octets in the segment index
  BLOCK_INDEX_LENGTH     the number of octets in the block index


4.2. Keystream Segments

  Conceptually, ICM is a keystream generator that takes a secret key
  and a segment index as an input and then outputs a keystream
  segment.  The segmentation lends itself to packet encryption, as
  each keystream segment can be used to encrypt a distinct packet.

  A counter is a value containing BLOCK_LENGTH octets which is



McGrew                                                          [Page 2]


Internet Draft            Integer Counter Mode             October, 2002


  incremented using an increment function based on integer addition,
  to produce a sequence of distinct values which are used as inputs to
  the block cipher.  (In the context of this specification, an integer
  is an octet string, the most significant of which is the first.)
  The output blocks of the cipher are concatenated to form the
  keystream segment.  The first octet of the segment is the first
  octet of the first output block, and so on.  A schematic of this
  process is shown in Figure 1.


  Figure 1.  The generation of a keystream segment given a segment
  index and a block cipher key K.  Here C[i] and S[i] denote the ith
  counter and keystream block, respectively.

        segment
         index
           |
           v
         C[0] -----> C[1] -----> C[2] -----> ...
           |           |           |
           v           v           v
         +---+       +---+       +---+
      K->| E |    K->| E |    K->| E |       ...
         +---+       +---+       +---+
           |           |           |
           v           v           v
         S[0]        S[1]        S[2]        ...

  The ith counter C[i] of the keystream segment with segment index s
  is defined as

   C[i] = (i + s * (256^BLOCK_INDEX_LENGTH)) (+) r

  where r denotes the shifted Offset, which is defined as the Offset
  times 256^(BLOCK_LENGTH - OFFSET_LENGTH).  (This multiplication
  left-shifts the Offset so that it is aligned with the leftmost
  edge of the block.)  Here ^ denotes exponentiation and (+) denotes
  the bitwise exclusive-or operation.

  The number of blocks in any segment MUST NOT exceed
  256^BLOCK_INDEX_LENGTH.  The number of segments MUST NOT exceed
  256^SEGMENT_INDEX_LENGTH.  These restrictions ensure the uniqueness
  of each block cipher input.  They also imply that each segment
  contains no more than (256^BLOCK_INDEX_LENGTH)*BLOCK_LENGTH octets.

  The sum of SEGMENT_INDEX_LENGTH and BLOCK_INDEX_LENGTH MUST NOT
  exceed BLOCK_LENGTH / 2.  This requirement protects the ICM
  keystream generator from potentially failing to be pseudorandom (see



McGrew                                                          [Page 3]


Internet Draft            Integer Counter Mode             October, 2002


  the rationale).

  Figure 2.  An illustration of the structure of a counter with
  BLOCK_LENGTH = 8, SEGMENT_INDEX_LENGTH = 2, and BLOCK_INDEX_LENGTH
  = 2.  The field marked `null' is not part of either the block
  or segment indices.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              null                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          segment index        |          block index          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


4.3. ICM Encryption

  Unless otherwise specified, ICM encryption consists of bitwise
  exclusive-oring the keystream into the plaintext to produce
  the ciphertext.


4.4 ICM KEY

  An ICM key consists of the block cipher key and an Offset.  The
  Offset is an integer with OFFSET_LENGTH octets, which is used to
  `randomize' the logical starting point of keystream.  The Offset is
  crucial to providing security; see the rationale.  The value of
  OFFSET_LENGTH SHOULD be at least half that of BLOCK_LENGTH.

  For the purposes of transporting an ICM key, e.g. in a signaling
  protocol, that key SHOULD be considered a sequence of octets in
  which the block cipher key precedes the Offset.


5. Implementation Considerations

  Implementation of the `add one modulo 2^m' operation is simple.  For
  example, with BLOCK_LENGTH = 8 (m=64), it can be implemented in C as

  if (!++x) ++y;

  where x and y are 32-bit unsigned integers in network byte order.
  The implementation of general purpose addition modulo 2^m is
  slightly more complicated.

  The fact that the Offset is left-aligned enables an implementation



McGrew                                                          [Page 4]


Internet Draft            Integer Counter Mode             October, 2002


  to avoid propagating carry values outside of the block index and/or
  the segment index.  Choosing an OFFSET_LENGTH value equal to half
  that of BLOCK_LENGTH avoids all of these carries, since the Offset
  is then shifted so that it occupies the most significant octets