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 document obsoletes RFC 4009.
Lee, et al. Informational [Page 1]

RFC 4269 The SEED Encryption Algorithm December 20051. Introduction1.1. Changes from RFC 4009
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.
1.2. SEED Overview
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 20051.3. Notation
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
2. The Structure of SEED
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:
Input : (L, R)
for i = 1 to 15
T = R;
R = L ^ F(Ki, R);
L = T;
L = L ^ F(K16, R), R=R
Output : (L, R)
Where T is a temporary.
2.1. The Round Function F
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 20052.4. Decryption Procedure
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.
2.5. SEED Object Identifiers
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.
algorithm OBJECT IDENTIFIER ::= { iso(1) member-body(2) korea(410)
kisa(200004) algorithm(1) }
id-seedCBC OBJECT IDENTIFIER ::= { algorithm seedCBC(4) }
seedCBCParameter ::= OCTET STRING (SIZE(16))
-- 128-bit Initialization Vector
The id-seedCBC OID is used when the Cipher Block Chaining (CBC) mode
of operation based on the SEED block cipher is provided.
id-seedMAC OBJECT IDENTIFIER ::= { algorithm seedMAC(7) }
seedMACParameter ::= INTEGER -- MAC length, in bits
The id-seedMAC OID is used when the message authentication code (MAC)
algorithm based on the SEED block cipher is provided.
pbeWithSHA1AndSEED-CBC OBJECT IDENTIFIER ::=
{ algorithm seedCBCwithSHA1(15) }
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].
3. Security Considerations
No security problem has been found on SEED. See [ISOSEED] and
[CRYPTREC].
Lee, et al. Informational [Page 6]

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.
Lee, et al. Informational [Page 16]