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, . [3] Rose, G., "SOBER-128 C-language Reference Implementation", 2003, . [4] Rose, G., "SOBER: A Stream Cipher based on Linear Feedback over GF(2**8)", Technical report, QUALCOMM Australia , 1998, . [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", . [7] Hawkes, P. and G. Rose, "The t-class of SOBER Stream Ciphers", Technical Report, QUALCOMM Australia , October 1999, . 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]