Network Working Group H.J. Lee Request for Comments: 4269 S.J. Lee Obsoletes: 4009 J.H. Yoon Category: Informational D.H. Cheon J.I. Lee KISA December 2005
The SEED Encryption Algorithm
Status of This Memo
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes the SEED encryption algorithm, which has been adopted by most of the security systems in the Republic of Korea. Included are a description of the encryption and the key scheduling algorithm (Section 2), the S-boxes (Appendix A), and a set of test vectors (Appendix B).
This specification obsoletes RFC 4009, because RFC 4009 had ambiguous function and SS-boxes definitions cryptographically. Thus, some definitions have been changed, and for better understanding, the SEED pseudo codes have been modified. This update is to provide clarity and facilitate the development of interoperable implementations. The SEED algorithm itself has not been changed.
This specification updates RFC 4009 in the following areas:
- Pseudo code changes. The pseudo code in Section 2 of RFC 4009 is insufficient for the explanation of the structure of SEED. Thus, detailed pseudo code is introduced.
- Some corrections of errata, which are the definitions of R1', Z, X, and SS-boxes.
SEED is a 128-bit symmetric key block cipher that has been developed by KISA (Korea Information Security Agency) since 1998. SEED is a national standard encryption algorithm in the Republic of Korea [TTASSEED] and is designed to use the S-boxes and permutations that balance with the current computing technology. It has the Feistel structure with 16-round and is strong against DC (Differential Cryptanalysis), LC (Linear Cryptanalysis), and related key attacks, balanced with security/efficiency trade-off.
The features of SEED are outlined as follows:
- The Feistel structure with 16-round - 128-bit input/output data block size - 128-bit key length - A round function that is strong against known attacks - Two 8x8 S-boxes - Mixed operations of XOR and modular addition
SEED has been widely used in the Republic of Korea for confidential services such as electronic commerce; e.g., financial services provided in wired and wireless communication.
Lee, et al. Informational [Page 2]
RFC 4269 The SEED Encryption Algorithm December 2005
The following notation is used in the description of the SEED encryption algorithm:
& bitwise AND ^ bitwise exclusive OR + addition in modular 2**32 - subtraction in modular 2**32 || concatenation << n left circular rotation by n bits >> n right circular rotation by n bits 0x hexadecimal representation
The input/output block size of SEED is 128 bits, and the key length is also 128 bits. SEED has the 16-round Feistel structure. A 128-bit input is divided into two 64-bit blocks (L, R), and the right 64-bit block is an input to the round function F, with a 64-bit subkey Ki generated from the key schedule. L is the most significant 64 bits of 128-bit input, and R is the least significant 64 bits.
A pseudo code for the structure of SEED is as follows:
SEED uses two 8x8 S-boxes, permutations, rotations, and basic modular operations such as exclusive OR (XOR) and additions to provide strong security, high speed, and simplicity in its implementation.
A 64-bit input block of the round function F is divided into two 32-bit blocks (R0, R1) and wrapped with 4 phases:
Lee, et al. Informational [Page 3]
RFC 4269 The SEED Encryption Algorithm December 2005
- A mixing phase of two 32-bit subkey blocks (Ki0, Ki1) - 3 layers of function G (see Section 2.2), with additions for mixing two 32-bit blocks
Where R0 is the most significant 32 bits of R, and R1 is the least significant 32 bits.
The outputs (R0', R1') of function F are as follows:
The function G has two layers: a layer of two 8x8 S-boxes and a layer of block permutation of sixteen 8-bit sub-blocks. The outputs Z (= Z3 || Z2 || Z1 || Z0) of the function G with four 8-bit inputs X (= X3 || X2 || X1 || X0) are as follows:
The key schedule generates each round's subkeys. It uses the function G, addition in modular 2**32, subtraction in modular 2**32, and (left/right) circular rotation. A 128-bit input key is divided into four 32-bit blocks (Key0, Key1, Key2, Key3). The two 32-bit subkeys of the ith round, Ki0 and Ki1, are generated as follows:
Decryption procedure is the reverse step of the encryption procedure. It can be implemented by using the encryption algorithm with reverse order of the round subkeys.
For those who may be using SEED in algorithm negotiation within a protocol, or in any other context that may require the use of Object Identifiers (OIDs), the following three OIDs have been defined.
PBEParameters ::= SEQUENCE { salt OCTET STRING, iteration INTEGER } -- Total number of hash iterations
This OID is used when a password-based encryption in CBC mode based on SHA-1 and the SEED block cipher is provided. The details of the Password-Based Encryption (PBE) computation are well described in Section 6.1 of [RFC2898].
[ISOSEED] ISO/IEC, ISO/IEC JTC1/SC 27 N 256r1, "National Body contributions on NP 18033 Encryption algorithms in response to document SC 27 N 2563", October, 2000
Alfred Hoenes (ah@tr-sys.de) has contributed significantly to work on the definitions of R1', Z, X, and SS-boxes. Thanks for his contribution to this document.
Lee, et al. Informational [Page 7]
RFC 4269 The SEED Encryption Algorithm December 2005
RFC 4269 The SEED Encryption Algorithm December 2005
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.