[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                            G. Rose
Internet-Draft                                                 P. Hawkes
Expires: August 6, 2004                                        M. Paddon
                                                                Qualcomm
                                                        February 6, 2004


       SOBER-128: A Fast Stream Cipher with Simultaneous Message
                          Authentication Code
                        draft-paddon-sober128-01

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 except that the right to
   produce derivative works is not granted.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its 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.

   This Internet-Draft will expire on August 6, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

   SOBER-128 is a fast software-oriented stream cipher based on simple
   32 bit operations. Keys and optional nonces of arbitrary length are
   supported. Enumeration of keys is thought to be the most efficient
   attack for key lengths of 128 bits or less. SOBER-128 may be
   configured to calculate an arbitrary length Message Authentication
   Code (MAC) as part of the encryption or decryption process. Source
   code for SOBER-128 is freely available, and use of this source code,
   or independent implementations, is permitted for any purpose under a
   fee free license.



Rose, et al.             Expires August 6, 2004                 [Page 1]


Internet-Draft                 SOBER-128                   February 2004


Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1   Usage and Threat Model . . . . . . . . . . . . . . . . . . .  3
   2.    Terminology and Notation . . . . . . . . . . . . . . . . . .  4
   3.    Description  . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.1   The Linear Feedback Shift Register . . . . . . . . . . . . .  5
   3.2   The Non-Linear Filter  . . . . . . . . . . . . . . . . . . .  5
   3.3   The Non-Linear Plaintext Feedback Function . . . . . . . . .  6
   3.4   Encryption and Decryption  . . . . . . . . . . . . . . . . .  6
   3.5   Message Authentication Code Generation . . . . . . . . . . .  7
   3.5.1 MAC Accumulation . . . . . . . . . . . . . . . . . . . . . .  7
   3.5.2 MAC Finalization . . . . . . . . . . . . . . . . . . . . . .  7
   4.    Cipher Initialization  . . . . . . . . . . . . . . . . . . .  9
   4.1   Key Setup  . . . . . . . . . . . . . . . . . . . . . . . . .  9
   4.2   Nonce Setup  . . . . . . . . . . . . . . . . . . . . . . . . 10
   5.    Message Authentication with Partial Encryption . . . . . . . 11
   6.    Security Considerations  . . . . . . . . . . . . . . . . . . 13
   7.    IPR Notices  . . . . . . . . . . . . . . . . . . . . . . . . 14
         Normative References . . . . . . . . . . . . . . . . . . . . 15
         Informative References . . . . . . . . . . . . . . . . . . . 16
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
   A.    Multab Specification . . . . . . . . . . . . . . . . . . . . 18
   B.    SBox Specification . . . . . . . . . . . . . . . . . . . . . 20
   C.    Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 22
         Intellectual Property and Copyright Statements . . . . . . . 25

























Rose, et al.             Expires August 6, 2004                 [Page 2]


Internet-Draft                 SOBER-128                   February 2004


1. Introduction

   SOBER-128 is a stream cipher designed to be fast (faster than a block
   cipher in counter mode), easy to use correctly, well understood,
   freely available, and secure. It is based entirely on a well-studied
   primitive in such a manner that preserves the existing analyses [2].
   Additionally, SOBER-128 introduces functionality to enable
   simultaneous calculation of an optional Message Authentication Code
   (MAC), which can be used for integrity checking operations on
   partially or fully encrypted messages. The design allows for the use
   of a secret key and non-secret nonce.

   SOBER-128 uses a secret key, of arbitrary length. Enumeration of keys
   is thought to be the most efficient attack for key lengths of 128
   bits or less. It is a software-oriented cipher, based on 32 bit
   operations (such as 32 bit exclusive-or and addition modulo 2**32),
   and references to small fixed arrays. Consequently, SOBER-128 is at
   home in many computing environments, from smart cards to large
   computers. Source code for SOBER-128 [3] is freely available and use
   of this code, or independent implementations, is permitted for any
   purpose subject to the license granted in Section 7.

1.1 Usage and Threat Model

   SOBER-128 can generate a single encryption keystream of arbitrary
   length form a given key. In this mode it would be possible to use
   SOBER-128 as a replacement for the commonly deployed RC4 cipher in,
   for example, SSL/TLS. In this mode, no nonce is required. In practice
   though, much communication is done in messages, where it is desirable
   to provide message integrity for the whole message, and privacy
   (encryption) for all or part of the message. SOBER-128 also supports
   the use of a single secret key for the entire (multi-message)
   communication, using a nonce to distinguish individual messages.

   SOBER-128 is intended to provide security under the condition that no
   nonce is ever reused (with the same key), that no more than 2**80 32
   bit words of data are processed with one key, and that no data
   failing authentication checks will be further processed (in
   particular, that the result of decrypting a message that fails
   authentication will not be revealed). There is no requirement that
   nonces be random, which makes guaranteeing their uniqueness much
   easier. For correct operation, the sender and recipient of secure
   data must agree on which parts of the data are encrypted and which
   parts are authenticated, as the encryption operation is
   plaintext-aware when message authentication is being performed.






Rose, et al.             Expires August 6, 2004                 [Page 3]


Internet-Draft                 SOBER-128                   February 2004


2. Terminology and Notation

   An "octet" is an 8 bit quantity and a "word" is a 32 bit quantity.

   A "plaintext" is a sequence of unencrypted octets and a "ciphertext"
   is a sequence of encrypted octets. A "keystream" is a sequence of
   octets with which a plaintext or ciphertext is combined to achieve
   encryption or decryption respectively.

   A "key" is a cipher parameter, used to initialize the cipher's state.
   A "nonce" is a cipher parameter that changes from message to message.

   The following notations are used in this document:

      x ** y     "x" to the power of "y"
      x + y      addition, modulo 2**32, of words "x" and "y"
      x & y      bitwise AND of "x" and "y"
      x | y      bitwise OR of "x" and "y"
      x ^ y      bitwise XOR of "x" and "y"
      x << n     zero-extended "n"-bit left shift of "x"
      x >> n     zero-extended "n"-bit right shift of "x"
      x >>> n    "n"-bit right rotate of "x"
      a[n]       the "n"'th element of array "a"
      a.length   the number of elements in array "a"

      All operators implicitly group left to right, without precedence,
      unless explicit parentheses are used.

   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 [1].




















Rose, et al.             Expires August 6, 2004                 [Page 4]


Internet-Draft                 SOBER-128                   February 2004


3. Description

   SOBER-128 is constructed from a linear feedback shift register
   (LFSR), a non-linear filter (NLF) and a nonlinear plaintext feedback
   function (PFF). The NLF is used to generate the keystream, and the
   PFF is used to perturb the LFSR when a MAC is desired.

   SOBER-128 is operated in one of two basic modes:

   1.  Synchronous mode: This is the simplest mode of operation, wherein
       the keystream generation is independent of the plaintext. This
       mode SHOULD be used when a MAC is not required.

   2.  Message authentication mode: This mode utilizes the PFF to
       perturb the LFSR state with plaintext during encryption or
       decryption. After the message has been processed, the keystream
       generator is used to produce a MAC. This mode MUST be used when a
       MAC is required.

   It is possible to utilize the PFF, as per the message authentication
   mode, but without the intention of generating a MAC. This has the
   disadvantage of removing the LFSR's guarantee of a long period, with
   no benefit. Therefore, this mode of operation is NOT RECOMMENDED.
   Instead, a nonce SHOULD be used to introduce message specific
   uniqueness into a keystream.

3.1 The Linear Feedback Shift Register

   The LFSR consists of 17 words of state, designated R[0] through
   R[16]. A stepping operation is defined on the LFSR:

          Step(R):
              x = R[15] ^ R[4] ^ (R[0] << 8)
                  ^ Multab[(R[0] >> 24) & 0xff];
              for (i = 0 to 15):
                  R[i] = R[i + 1];
              R[16] = x;

   where "Multab" is a look up table of 256 constants, as defined in
   Appendix A.

3.2 The Non-Linear Filter









Rose, et al.             Expires August 6, 2004                 [Page 5]


Internet-Draft                 SOBER-128                   February 2004


   The NLF function is defined as:

          NLF(R, Konst) = f((((f(R[0] + R[16]) >>> 8) + R[1]) ^ Konst)
                          + R[6]) + R[13];

   where "f" is a substitution box function and "Konst" is a constant
   that is calculated during cipher initialization.

   The function "f" is defined as:

          f(x) = SBox[x >> 24] ^ x;

   where "SBox" is a substitution box lookup table of 256 constants, as
   specified in Appendix B.

3.3 The Non-Linear Plaintext Feedback Function

   The PFF is defined as:

          PFF(R, Konst, x) = f((f(R[4] + x) >>> 8) + Konst);


3.4 Encryption and Decryption

   Encryption is achieved by producing a keystream, which is then
   combined with the plaintext. The keystream is generated in groups of
   4 octets, designated v[0] through v[3], by the following algorithm:

          Step(R);
          x = NLF(R, Konst);
          for (i = 0 to 3):
              v[i] = x & 0xff;
              x = x >> 8;

   In other words, the 4 octets of keystream are encoded in the output
   word of the NLF, and are extracted in least significant octet first
   order.

   To encrypt, a keystream of the same length as the plaintext is
   generated. Encryption is then achieved by the following algorithm:

          for (i = 0 to p.length - 1):
              c[i] = p[i] ^ v[i];

   where "p" is the plaintext, "v" is the keystream, and "c" is the
   ciphertext. Excess keystream octets must be discarded. In practice,
   keystream generation and encryption SHOULD be performed
   incrementally, processing as few as 4 octets per iteration.



Rose, et al.             Expires August 6, 2004                 [Page 6]


Internet-Draft                 SOBER-128                   February 2004


   Decryption is symmetrical, with the same keystream being combined
   with the ciphertext to extract the plaintext:

          for (i = 0 to p.length - 1):
              p[i] = c[i] ^ v[i];


3.5 Message Authentication Code Generation

   SOBER-128 calculates a MAC in two phases: accumulation (which occurs
   during encryption) and finalization.

3.5.1 MAC Accumulation

   Accumulation is contemporaneous with keystream generation: as each
   group of 4 keystream octets is produced, the corresponding 4
   plaintext octets is used to perturb the LFSR state in a non-linear
   fashion. If the plaintext octets are designated p[0] through p[3],
   then this feedback is achieved by the following algorithm:

           x = 0;
           for (i = 3 to 0):
               x = (x << 8) | p[i];
           R[4] = PFF(R, Konst, x);

   If the plaintext is not an exact multiple of 4 octets in length, the
   final feedback operation MUST be executed as if the plaintext were
   padded with trailing, zero-valued octets.

   MAC accumulation and keystream generation depend on different LFSR
   elements, therefore NLF and PFF MAY be calculated in any order
   following each stepping of the LFSR. The LFSR is only stepped once
   for each contemporaneous keystream-word-generation/
   plaintext-word-feedback cycle. However, whether encrypting or
   decrypting, accumulation MUST always be performed with plaintext
   octets.

   Plaintext may be accumulated without encryption. This allows a
   message to be partially encrypted but fully accumulated for the
   resulting message authentication code. When accumulation without
   encryption is being performed, keystream octets MUST be consumed (by
   discarding) as if encryption was occurring.

3.5.2 MAC Finalization







Rose, et al.             Expires August 6, 2004                 [Page 7]


Internet-Draft                 SOBER-128                   February 2004


   Finalization consists of executing the following algorithm:

           Include(R, INITKONST);
           for (i = 0 to 17):
               Diffuse(R, Konst);

   A sequence of additional keystream octets, of desired length, are
   then generated. These octets form the MAC. MACs SHOULD NOT exceed 256
   bits.

   The "Include" operation is defined as:

           Include(R, x):
               R[15] = R[15] + x;

   The "Diffuse" operation is defined as:

           Diffuse(R, Konst):
               Step(R);
               x = NLF(R, Konst);
               R[4] = R[4] ^ x;

   The constant "INITKONST" has the value 0x6996c53a.




























Rose, et al.             Expires August 6, 2004                 [Page 8]


Internet-Draft                 SOBER-128                   February 2004


4. Cipher Initialization

   SOBER-128 MUST be initialized with a key, and MAY further be
   initialized with a nonce, before encryption or decryption takes
   place.

4.1 Key Setup

   A key consists of a sequence of "k" octets, designated K[0] through
   K[k-1]. A key's length MUST be an exact multiple of 4 octets. While
   key length is not bounded, the cipher's design does not guarantee
   additional security with key lengths in excess of 128 bits.

   SOBER-128 is keyed using the following algorithm:

          /* initialize state */
          R[0] = 1; R[1] = 1;
          for (i = 2 to 16):
              R[i] = R[i - 1] + R[i - 2];
          Konst = INITKONST;

          /* load the key */
          LoadKey(R, Konst, K);

          /* calculate Konst */
          repeat:
              Step(R);
              x = NLF(R, Konst);
          until (x & 0xff000000) != 0;
          Konst = x;

   The "Loadkey" operation is defined as:

          LoadKey(R, Konst, K):
              i = 0;
              while (i < K.length):
                  x = 0;
                  for (j = 0 to 3):
                      x = (x << 8) | K[i + j];
                  Include(R, x);
                  Diffuse(R, Konst);
                  i = i + 4;
              Include(K.length);
              for (i = 0 to 16):
                  Diffuse(R, Konst);

   If the cipher is to be used for multiple messages, then R and Konst
   MAY be saved at this point. This state is known as the "key state".



Rose, et al.             Expires August 6, 2004                 [Page 9]


Internet-Draft                 SOBER-128                   February 2004


   Reloading the R and Konst with a saved key state is equivalent to
   re-keying with the original key.

   If the cipher is not being used with nonces, then the key state is
   used as the the initial cipher state, i.e. the state from which
   keystream generation can commence.

4.2 Nonce Setup

   A nonce, when used, consists of a sequence of "n" octets, designated
   N[0] through N[n-1]. A nonce's length MUST be an exact multiple of 4
   octets.

   When using a nonce, the initial cipher state is calculated from the
   key state by applying the following operation:

          LoadKey(R, Konst, N);

   A zero length nonce is permissible, and yields an initial cipher
   state distinct from the key state.































Rose, et al.             Expires August 6, 2004                [Page 10]


Internet-Draft                 SOBER-128                   February 2004


5. Message Authentication with Partial Encryption

   It is not an uncommon situation to have a stream of messages, each of
   which has some sort of header that needs to be sent unencrypted (e.g.
   for routing) followed by an encrypted payload, however the whole
   message should be integrity protected. Having messages that are only
   partly integrity protected is NOT RECOMMENDED.

   Assume, by way of example, messages of 14 octets, of which the first
   6 are to be sent unencrypted, and that a 64 bit (8 octet) MAC is to
   be appended. These messages should be processed in the following way:

   1.  The transmitted message requires a unique nonce; this might be
       simply a message counter. The cipher state is reinitialized using
       this nonce, as described in Section 4.2, and the nonce is
       transmitted ahead of the message. Assume a 4 octet nonce value.

   2.  The first 4 octets of the message are accumulated for message
       integrity, as described in Section 3.5.1. Since the octets are
       not going to be encrypted, the corresponding 4 octets of
       keystream are notionally calculated and discarded (in an
       optimized implementation the NLF need never be evaluated).

   3.  The next 4 octets are all integrity protected but only the last
       two are encrypted. The plaintext octets MUST all be accumulated,
       as described in Section 3.5.1. For the encryption, 4 octets of
       keystream MUST be calculated as described in Section 3.4; the
       first two MUST be discarded and the second two are used to
       encrypt the second 2 octets of plaintext, as described in Section
       3.4. The LFSR MUST be stepped only once.

   4.  The next 4 octets are both encrypted and accumulated for message
       integrity. The LFSR is stepped once, the plaintext octets are
       gathered and accumulated as in Section 3.5.1, and the octets are
       encrypted as in Section 3.4.

   5.  The final 2 octets are both encrypted and protected. The LFSR is
       stepped once and 4 octets of keystream are generated as in
       Section 3.4; the first 2 octets are used to encrypt the remaining
       octets of the message, and the remaining keystream octets are
       discarded. For message integrity, the 2 plaintext octets are
       supplemented by 2 zero octets for accumulation as described in
       Section 3.5.1.

   6.  The MAC is generated, as described in Section 3.5.2, and appended
       to the message.

   The decryption process is symmetrical. First the cipher is



Rose, et al.             Expires August 6, 2004                [Page 11]


Internet-Draft                 SOBER-128                   February 2004


   reinitialized with the received nonce (potentially checking for
   replay of old messages at this time). Then the message is processed,
   noting that the ciphertext must be XORed with the keystream octets to
   yield the plaintext octets needed to accumulate the MAC. After the
   message payload has been processed, a new MAC MUST be generated in
   the manner of Section 3.5.2, and verified to be equal to the received
   MAC. Messages that fail this check MUST be discarded.

   Let "H" represent the octets of the message header to be
   authenticated but not encrypted, "P" the octets of the message
   plaintext to be encrypted and authenticated, "C" the corresponding
   ciphertext octets, "N" the octets of the nonce, and "M" the octets of
   the MAC. Then the input message:

         -----------------------------
         |H|H|H|H|H|H|P|P|P|P|P|P|P|P|
         -----------------------------

    is eventually transmitted as:

         -----------------------------------------------------
         |N|N|N|N|H|H|H|H|H|H|C|C|C|C|C|C|C|C|M|M|M|M|M|M|M|M|
         -----------------------------------------------------

   In a general purpose implementation, which is sequentially passed
   arbitrary extents of octets in order to build up a message, it is
   often convenient to buffer unconsumed keystream octets and
   unprocessed feedback octets. After the LFSR is stepped, 4 keystream
   octets are generated, buffered, and consumed (by encrypting with them
   or discarding them) as plaintext octets become available. Conversely,
   feedback octets are collected as plaintext becomes available, and are
   accumulated when 4 feedback octets are buffered (prior to the next
   stepping of the LFSR). When the plaintext is exhausted, all buffered
   keystream octets are discarded. If any feedback octets have been
   collected, they are padded with zero octets and one last accumulation
   operation is performed.















Rose, et al.             Expires August 6, 2004                [Page 12]


Internet-Draft                 SOBER-128                   February 2004


6. Security Considerations

   SOBER-128 was developed from the SOBER family of stream ciphers, the
   original SOBER being proposed by Rose in 1998 [4][5]. In 2000, the
   SOBER ciphers were submitted to the NESSIE program [6]; SOBER-t16 as
   a stream cipher for 128 bit key strength and SOBER-t32 as a stream
   cipher with 256 bit key strength [7]. SOBER-t16 and SOBER-t32 proved
   to be among  the strongest stream cipher submissions to NESSIE.
   However, both ciphers were found to fall short of the stringent
   NESSIE requirements. SOBER-128 is an improved version of SOBER-t32.
   The modifications directly address the concerns arising in the
   analyses of the t-class ciphers. The 128 bit key strength proposed
   for SOBER-128 is reduced from the 256 bit key strength proposed for
   SOBER-t32 to ensure that SOBER-128 provides far in excess of the
   stated security level.

   SOBER-128 is intended to provide 128 bit security. The base attack on
   SOBER-128 is an exhaustive key search, which has a computational
   complexity of 2**128. In all attacks, it is assumed that the attacker
   observes a certain amount of keystream produced by one or more secret
   keys, and the attacker knows the corresponding plaintext and nonces.
   SOBER-128 is considered to resist an attack if either the attack
   requires the owner of the secret key(s) to generate more than 2**80
   key stream words, or the computational complexity of the attack is
   equivalent to the attacker rekeying the cipher 2**128 times and
   generating at least 5 words of output each time. We claim that
   SOBER-128 fulfils the security requirements of a stream cipher and
   MAC, when used subject to the condition that no key/nonce tuple is
   ever reused, and no more than 2**80 words are processed with one key.

   The authors believe that SOBER-128 substantially exceeds the stated
   level of security. At the time this document was written, the only
   known or hypothesized attacks of complexity less than 2**256 are
   distinguishing attacks requiring more than 2**128 octets of known
   plaintext.
















Rose, et al.             Expires August 6, 2004                [Page 13]


Internet-Draft                 SOBER-128                   February 2004


7. IPR Notices

   The SOBER family of encryption algorithms are covered by patents in
   the United States of America and other countries. A free and
   irrevocable license is hereby granted for the use of such patents to
   the extent required to utilize the SOBER family of encryption
   algorithms for any purpose, subject to the condition that any
   commercial product utilizing any of the SOBER family of encryption
   algorithms should show the words "Encryption by QUALCOMM" either on
   the product or in the associated documentation.









































Rose, et al.             Expires August 6, 2004                [Page 14]


Internet-Draft                 SOBER-128                   February 2004


Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.















































Rose, et al.             Expires August 6, 2004                [Page 15]


Internet-Draft                 SOBER-128                   February 2004


Informative References

   [2]  Hawkes, P. and G. Rose, "Primitive Specification for SOBER-128",
        Cryptology ePrint Archive 2003/081, 2003, <http://
        eprint.iacr.org/2003/081.pdf>.

   [3]  Rose, G., "SOBER-128 C-language Reference Implementation", 2003,
        <http://www.qualcomm.com.au/PublicationsDocs/s128.tgz>.

   [4]  Rose, G., "SOBER: A Stream Cipher based on Linear Feedback over
        GF(2**8)", Technical report, QUALCOMM Australia , 1998, <http://
        www.qualcomm.com.au/PublicationsDocs/sober.ps>.

   [5]  Rose, G., "A Stream Cipher based on Linear Feedback over
        GF(2**8)", Proceedings of the Australian Conference on
        Information Security and Privacy (ACISP) , 1998.

   [6]  "NESSIE: New European Schemes for Signatures, Integrity, and
        Encryption", <http://www.cryptonessie.org/>.

   [7]  Hawkes, P. and G. Rose, "The t-class of SOBER Stream Ciphers",
        Technical Report, QUALCOMM Australia , October 1999, <http://
        www.qualcomm.com.au/PublicationsDocs/TC.pdf>.


Authors' Addresses

   Gregory G. Rose
   Qualcomm International Inc.
   Level 3, 230 Victoria Road
   Gladesville, NSW  2111
   Australia

   Phone: +61 2 9817 4188
   EMail: ggr@qualcomm.com


   Philip Hawkes
   Qualcomm International Inc.
   Level 3, 230 Victoria Road
   Gladesville, NSW  2111
   Australia

   Phone: +61 2 9817 4188
   EMail: phawkes@qualcomm.com






Rose, et al.             Expires August 6, 2004                [Page 16]


Internet-Draft                 SOBER-128                   February 2004


   Michael Paddon
   Qualcomm International Inc.
   Level 3, 230 Victoria Road
   Gladesville, NSW  2111
   Australia

   Phone: +61 2 9817 4188
   EMail: mwp@qualcomm.com











































Rose, et al.             Expires August 6, 2004                [Page 17]


Internet-Draft                 SOBER-128                   February 2004


Appendix A. Multab Specification

   Multab is a 256 word lookup table, indexed from 0 to 255, with the
   values:

         0x00000000 0xd02b4367 0xed5686ce 0x3d7dc5a9
         0x97ac41d1 0x478702b6 0x7afac71f 0xaad18478
         0x631582ef 0xb33ec188 0x8e430421 0x5e684746
         0xf4b9c33e 0x24928059 0x19ef45f0 0xc9c40697
         0xc62a4993 0x16010af4 0x2b7ccf5d 0xfb578c3a
         0x51860842 0x81ad4b25 0xbcd08e8c 0x6cfbcdeb
         0xa53fcb7c 0x7514881b 0x48694db2 0x98420ed5
         0x32938aad 0xe2b8c9ca 0xdfc50c63 0x0fee4f04
         0xc154926b 0x117fd10c 0x2c0214a5 0xfc2957c2
         0x56f8d3ba 0x86d390dd 0xbbae5574 0x6b851613
         0xa2411084 0x726a53e3 0x4f17964a 0x9f3cd52d
         0x35ed5155 0xe5c61232 0xd8bbd79b 0x089094fc
         0x077edbf8 0xd755989f 0xea285d36 0x3a031e51
         0x90d29a29 0x40f9d94e 0x7d841ce7 0xadaf5f80
         0x646b5917 0xb4401a70 0x893ddfd9 0x59169cbe
         0xf3c718c6 0x23ec5ba1 0x1e919e08 0xcebadd6f
         0xcfa869d6 0x1f832ab1 0x22feef18 0xf2d5ac7f
         0x58042807 0x882f6b60 0xb552aec9 0x6579edae
         0xacbdeb39 0x7c96a85e 0x41eb6df7 0x91c02e90
         0x3b11aae8 0xeb3ae98f 0xd6472c26 0x066c6f41
         0x09822045 0xd9a96322 0xe4d4a68b 0x34ffe5ec
         0x9e2e6194 0x4e0522f3 0x7378e75a 0xa353a43d
         0x6a97a2aa 0xbabce1cd 0x87c12464 0x57ea6703
         0xfd3be37b 0x2d10a01c 0x106d65b5 0xc04626d2
         0x0efcfbbd 0xded7b8da 0xe3aa7d73 0x33813e14
         0x9950ba6c 0x497bf90b 0x74063ca2 0xa42d7fc5
         0x6de97952 0xbdc23a35 0x80bfff9c 0x5094bcfb
         0xfa453883 0x2a6e7be4 0x1713be4d 0xc738fd2a
         0xc8d6b22e 0x18fdf149 0x258034e0 0xf5ab7787
         0x5f7af3ff 0x8f51b098 0xb22c7531 0x62073656
         0xabc330c1 0x7be873a6 0x4695b60f 0x96bef568
         0x3c6f7110 0xec443277 0xd139f7de 0x0112b4b9
         0xd31dd2e1 0x03369186 0x3e4b542f 0xee601748
         0x44b19330 0x949ad057 0xa9e715fe 0x79cc5699
         0xb008500e 0x60231369 0x5d5ed6c0 0x8d7595a7
         0x27a411df 0xf78f52b8 0xcaf29711 0x1ad9d476
         0x15379b72 0xc51cd815 0xf8611dbc 0x284a5edb
         0x829bdaa3 0x52b099c4 0x6fcd5c6d 0xbfe61f0a
         0x7622199d 0xa6095afa 0x9b749f53 0x4b5fdc34
         0xe18e584c 0x31a51b2b 0x0cd8de82 0xdcf39de5
         0x1249408a 0xc26203ed 0xff1fc644 0x2f348523
         0x85e5015b 0x55ce423c 0x68b38795 0xb898c4f2
         0x715cc265 0xa1778102 0x9c0a44ab 0x4c2107cc



Rose, et al.             Expires August 6, 2004                [Page 18]


Internet-Draft                 SOBER-128                   February 2004


         0xe6f083b4 0x36dbc0d3 0x0ba6057a 0xdb8d461d
         0xd4630919 0x04484a7e 0x39358fd7 0xe91eccb0
         0x43cf48c8 0x93e40baf 0xae99ce06 0x7eb28d61
         0xb7768bf6 0x675dc891 0x5a200d38 0x8a0b4e5f
         0x20daca27 0xf0f18940 0xcd8c4ce9 0x1da70f8e
         0x1cb5bb37 0xcc9ef850 0xf1e33df9 0x21c87e9e
         0x8b19fae6 0x5b32b981 0x664f7c28 0xb6643f4f
         0x7fa039d8 0xaf8b7abf 0x92f6bf16 0x42ddfc71
         0xe80c7809 0x38273b6e 0x055afec7 0xd571bda0
         0xda9ff2a4 0x0ab4b1c3 0x37c9746a 0xe7e2370d
         0x4d33b375 0x9d18f012 0xa06535bb 0x704e76dc
         0xb98a704b 0x69a1332c 0x54dcf685 0x84f7b5e2
         0x2e26319a 0xfe0d72fd 0xc370b754 0x135bf433
         0xdde1295c 0x0dca6a3b 0x30b7af92 0xe09cecf5
         0x4a4d688d 0x9a662bea 0xa71bee43 0x7730ad24
         0xbef4abb3 0x6edfe8d4 0x53a22d7d 0x83896e1a
         0x2958ea62 0xf973a905 0xc40e6cac 0x14252fcb
         0x1bcb60cf 0xcbe023a8 0xf69de601 0x26b6a566
         0x8c67211e 0x5c4c6279 0x6131a7d0 0xb11ae4b7
         0x78dee220 0xa8f5a147 0x958864ee 0x45a32789
         0xef72a3f1 0x3f59e096 0x0224253f 0xd20f6658

   Multab implements Galois Field multiplication; see [2] for further
   details. A hardware implementation might directly evaluate the
   multiplication operation.


























Rose, et al.             Expires August 6, 2004                [Page 19]


Internet-Draft                 SOBER-128                   February 2004


Appendix B. SBox Specification

   SBox is a 256 word lookup table, indexed from 0 to 255, with the
   values:

         0xa3aa1887 0xd65e435c 0x0b65c042 0x800e6ef4
         0xfc57ee20 0x4d84fed3 0xf066c502 0xf354e8ae
         0xbb2ee9d9 0x281f38d4 0x1f829b5d 0x735cdf3c
         0x95864249 0xbc2e3963 0xa1f4429f 0xf6432c35
         0xf7f40325 0x3cc0dd70 0x5f973ded 0x9902dc5e
         0xda175b42 0x590012bf 0xdc94d78c 0x39aab26b
         0x4ac11b9a 0x8c168146 0xc3ea8ec5 0x058ac28f
         0x52ed5c0f 0x25b4101c 0x5a2db082 0x370929e1
         0x2a1843de 0xfe8299fc 0x202fbc4b 0x833915dd
         0x33a803fa 0xd446b2de 0x46233342 0x4fcee7c3
         0x3ad607ef 0x9e97ebab 0x507f859b 0xe81f2e2f
         0xc55b71da 0xd7e2269a 0x1339c3d1 0x7ca56b36
         0xa6c9def2 0xb5c9fc5f 0x5927b3a3 0x89a56ddf
         0xc625b510 0x560f85a7 0xace82e71 0x2ecb8816
         0x44951e2a 0x97f5f6af 0xdfcbc2b3 0xce4ff55d
         0xcb6b6214 0x2b0b83e3 0x549ea6f5 0x9de041af
         0x792f1f17 0xf73b99ee 0x39a65ec0 0x4c7016c6
         0x857709a4 0xd6326e01 0xc7b280d9 0x5cfb1418
         0xa6aff227 0xfd548203 0x506b9d96 0xa117a8c0
         0x9cd5bf6e 0xdcee7888 0x61fcfe64 0xf7a193cd
         0x050d0184 0xe8ae4930 0x88014f36 0xd6a87088
         0x6bad6c2a 0x1422c678 0xe9204de7 0xb7c2e759
         0x0200248e 0x013b446b 0xda0d9fc2 0x0414a895
         0x3a6cc3a1 0x56fef170 0x86c19155 0xcf7b8a66
         0x551b5e69 0xb4a8623e 0xa2bdfa35 0xc4f068cc
         0x573a6acd 0x6355e936 0x03602db9 0x0edf13c1
         0x2d0bb16d 0x6980b83c 0xfeb23763 0x3dd8a911
         0x01b6bc13 0xf55579d7 0xf55c2fa8 0x19f4196e
         0xe7db5476 0x8d64a866 0xc06e16ad 0xb17fc515
         0xc46feb3c 0x8bc8a306 0xad6799d9 0x571a9133
         0x992466dd 0x92eb5dcd 0xac118f50 0x9fafb226
         0xa1b9cef3 0x3ab36189 0x347a19b1 0x62c73084
         0xc27ded5c 0x6c8bc58f 0x1cdde421 0xed1e47fb
         0xcdcc715e 0xb9c0ff99 0x4b122f0f 0xc4d25184
         0xaf7a5e6c 0x5bbf18bc 0x8dd7c6e0 0x5fb7e420
         0x521f523f 0x4ad9b8a2 0xe9da1a6b 0x97888c02
         0x19d1e354 0x5aba7d79 0xa2cc7753 0x8c2d9655
         0x19829da1 0x531590a7 0x19c1c149 0x3d537f1c
         0x50779b69 0xed71f2b7 0x463c58fa 0x52dc4418
         0xc18c8c76 0xc120d9f0 0xafa80d4d 0x3b74c473
         0xd09410e9 0x290e4211 0xc3c8082b 0x8f6b334a
         0x3bf68ed2 0xa843cc1b 0x8d3c0ff3 0x20e564a0
         0xf8f55a4f 0x2b40f8e7 0xfea7f15f 0xcf00fe21



Rose, et al.             Expires August 6, 2004                [Page 20]


Internet-Draft                 SOBER-128                   February 2004


         0x8a6d37d6 0xd0d506f1 0xade00973 0xefbbde36
         0x84670fa8 0xfa31ab9e 0xaedab618 0xc01f52f5
         0x6558eb4f 0x71b9e343 0x4b8d77dd 0x8cb93da6
         0x740fd52d 0x425412f8 0xc5a63360 0x10e53ad0
         0x5a700f1c 0x8324ed0b 0xe53dc1ec 0x1a366795
         0x6d549d15 0xc5ce46d7 0xe17abe76 0x5f48e0a0
         0xd0f07c02 0x941249b7 0xe49ed6ba 0x37a47f78
         0xe1cfffbd 0xb007ca84 0xbb65f4da 0xb59f35da
         0x33d2aa44 0x417452ac 0xc0d674a7 0x2d61a46a
         0xdc63152a 0x3e12b7aa 0x6e615927 0xa14fb118
         0xa151758d 0xba81687b 0xe152f0b3 0x764254ed
         0x34c77271 0x0a31acab 0x54f94aec 0xb9e994cd
         0x574d9e81 0x5b623730 0xce8a21e8 0x37917f0b
         0xe8a9b5d6 0x9697adf8 0xf3d30431 0x5dcac921
         0x76b35d46 0xaa430a36 0xc2194022 0x22bca65e
         0xdaec70ba 0xdfaea8cc 0x777bae8b 0x242924d5
         0x1f098a5a 0x4b396b81 0x55de2522 0x435c1cb8
         0xaeb8fe1d 0x9db3c697 0x5b164f83 0xe0c16376
         0xa319224c 0xd0203b35 0x433ac0fe 0x1466a19a
         0x45f0b24f 0x51fda998 0xc0d52d71 0xfa0896a8
         0xf9e6053f 0xa4b0d300 0xd499cbcc 0xb95e3d40






























Rose, et al.             Expires August 6, 2004                [Page 21]


Internet-Draft                 SOBER-128                   February 2004


Appendix C. Test Vectors

   Define "TESTKEY" to be the octet stream:

         0x74 0x65 0x73 0x74 0x20 0x6b 0x65 0x79
         0x20 0x31 0x32 0x38 0x62 0x69 0x74 0x73

   Define "TESTNONCE" to be the octet stream:

         0x00 0x00 0x00 0x00

   1.  When a plaintext of 20 zero octets is encrypted in synchronous
       mode using TESTKEY as the key and TESTNONCE as the nonce, the
       resulting ciphertext is:


           0x43 0x50 0x0c 0xcf 0x89 0x91 0x9f 0x1d
           0xaa 0x37 0x74 0x95 0xf4 0xb4 0x58 0xc2
           0x40 0x37 0x8b 0xbb

   2.  When a plaintext of 10,020 zero octets is encrypted in
       synchronous mode using TESTKEY as the key and TESTNONCE as the
       nonce, the last 20 octets of the resulting ciphertext is:

           0xf3 0x65 0x18 0x3f 0xdb 0x56 0x7e 0x50
           0xbc 0xd1 0x84 0x1b 0x76 0xc9 0x25 0x01
           0x56 0xca 0x34 0xbb

   3.  When a plaintext of 20 zero octets is accumulated in message
       authentication mode using TESTKEY as the key and TESTNONCE as the
       nonce, the resulting 20 octet message authetication code is:

           0x1c 0x06 0xc4 0x1e 0xcd 0xdc 0x39 0xc2
           0xd8 0xca 0xf1 0xeb 0x19 0xb6 0x96 0xd6
           0xcc 0x66 0x60 0x7f

   4.  When a plaintext of 20 zero octets is encrypted in message
       authentication mode using TESTKEY as the key and TESTNONCE as the
       nonce, the resulting ciphertext is:

           0x43 0x50 0x0c 0xcf 0x1a 0x92 0x20 0xc6
           0x9a 0x0e 0x44 0x67 0xd8 0x7e 0x27 0x17
           0xbd 0x08 0x93 0x4d

   5.  Set "VECTOR" to be the ciphertext resulting from encrypting a
       plaintext of 20 zero octets in synchronous mode using TESTKEY as
       the key and TESTNONCE as the nonce. When VECTOR is encrypted in
       synchronous mode using VECTOR as the key and without a nonce, and



Rose, et al.             Expires August 6, 2004                [Page 22]


Internet-Draft                 SOBER-128                   February 2004


       the resulting ciphertext becomes the new value VECTOR, and this
       operation is repeated for a total of 999,999 times, the final
       value of VECTOR is:

           0x2c 0x80 0x4d 0x44 0xcb 0xeb 0xb7 0x5e
           0x46 0xdc 0x59 0x8b 0x80 0xda 0xf5 0x47
           0x09 0x60 0x03 0x09

   6.  Set "VECTOR" to be the ciphertext resulting from encrypting a
       plaintext of 20 zero octets in synchronous mode using TESTKEY as
       the key and a zero length nonce. When the first 4 octets of
       VECTOR are encrypted in synchronous mode using TESTKEY as the key
       and the first 4 octets of VECTOR as the nonce, and the resulting
       ciphertext becomes the new first 4 octets of VECTOR, and this
       operation is repeated for a total of 999,999 times, the final
       value of VECTOR is:

           0x92 0x28 0xc7 0x79 0x91 0x75 0x49 0x8c
           0x6d 0x5f 0xfb 0xcd 0x8a 0xfb 0x85 0x07
           0x48 0x21 0x4a 0x8f

   7.  Set "VECTOR" to be 512 zero octets and "MAC" to be 20 zero
       octets. Call the first octet in MAC "MAC[0]", the second
       "MAC[1]", and so forth. Define "N" to be the value ((MAC[0] % 16)
       + 5). Set "CIPHER" to be a message authentication mode cipher,
       initialized with TESTKEY and without a nonce. When the two least
       significant bits in MAC[3] have the value:

          0: accumulate the first MAC[2] octets of VECTOR with CIPHER,
          then encrypt the next MAC[1] octets of VECTOR with CIPHER,

          1: accumulate the first MAC[1] octets of VECTOR with CIPHER,
          then encrypt the next MAC[2] octets of VECTOR with CIPHER,

          2: accumulate the first MAC[2] octets of VECTOR with CIPHER,
          then decrypt the next MAC[1] octets of VECTOR with CIPHER,

          3: accumulate the first MAC[1] octets of VECTOR with CIPHER,
          then decrypt the next MAC[2] octets of VECTOR with CIPHER,

       and a message authentication code of N octets is generated and
       stored in the first N octets of MAC, and CIPHER is reinitialized
       with TESTKEY as the key and MAC as the nonce, and this operation
       is repeated for a total of 1,000,000 times, the final value of
       MAC is:

           0xdf 0xc5 0xba 0x58 0xc6 0xea 0x22 0x6c
           0xc4 0x72 0x0c 0x22 0x63 0xdf 0x98 0xe4



Rose, et al.             Expires August 6, 2004                [Page 23]


Internet-Draft                 SOBER-128                   February 2004


           0xa6 0x20 0x59 0xd9


















































Rose, et al.             Expires August 6, 2004                [Page 24]


Internet-Draft                 SOBER-128                   February 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2004). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Rose, et al.             Expires August 6, 2004                [Page 25]


Internet-Draft                 SOBER-128                   February 2004


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.











































Rose, et al.             Expires August 6, 2004                [Page 26]


Html markup produced by rfcmarkup 1.121, available from https://tools.ietf.org/tools/rfcmarkup/