rfc-4010

Use of the SEED Encryption Algorithm in Cryptographic Message Syntax (CMS)

J. Park, S. Lee, J. Kim, J. Lee
date2005-02 streamIETF areasec wgsmime statusPROPOSED STANDARD pages13 canonicalhttps://www.rfc-editor.org/rfc/rfc4010 doi10.17487/RFC4010 errataview
This document specifies the conventions for using the SEED encryption algorithm for encryption with the Cryptographic Message Syntax (CMS). SEED is added to the set of optional symmetric encryption algorithms in CMS by providing two classes of unique object identifiers (OIDs). One OID class defines the content encryption algorithms and the other defines the key encryption algorithms. [STANDARDS-TRACK]

Extracted elements (17)

design-rationale §3.4.2

Alternative initial values are accommodated for cases where the desired integrity scope extends beyond the wrapped period or where the key data is not a multiple of 64 bits. RFC 3394 delegates definition of such alternatives to NIST key management publications.

crypto, security

design-rationale §3

SEED key wrapping and unwrapping is done in conformance with the AES key wrap algorithm [RFC3394], with 'AES' replaced by 'SEED'. This reuse of the established AES key wrap structure provides the same integrity and confidentiality properties for SEED-wrapped keys.

crypto, security

design-rationale §1.1

SEED was chosen for use in CMS because it is a Korean national industrial standard (TTASSEED), widely deployed in South Korean electronic commerce and financial services, and has been evaluated as cryptographically secure by ISO/IEC JTC 1/SC 27 and Japan CRYPTREC. It is resistant to differential, linear, and related-key attacks.

crypto, security

interoperability-note §2

SEED is added as an optional symmetric encryption algorithm in CMS alongside existing algorithms defined in RFC 3370 (CMSALG). A CMS agent selects SEED by using the corresponding OID; it is not mandatory unless local policy requires it, and both sender and receiver must support it for SEED-encrypted messages to be exchanged.

crypto, security, email

normative-requirement §4 SHOULD

An S/MIME client SHOULD announce supported cryptographic functions via the SMIMECapabilities attribute, which MUST be signed by the client. OIDs SHOULD be logically separated by functional category and MUST be ordered by preference.

crypto, security, email

normative-requirement §4 MUST

If an S/MIME client is required to support symmetric encryption with SEED, the SMIMECapabilities attribute MUST contain the SEED OID (id-seedCBC) in the symmetric algorithms category, and the associated parameter MUST be SeedSMimeCapability ::= NULL.

crypto, security, email

normative-requirement §3.4.1 MUST

If unwrapping produces A[0] equal to any value other than A6A6A6A6A6A6A6A6, the unwrap MUST return an error and MUST NOT return any key data.

crypto, security

normative-requirement §2.1 MUST

The AlgorithmIdentifier parameters field MUST be present for id-seedCBC, and MUST contain the 16-octet Initialization Vector (IV) encoded as SeedCBCParameter ::= SeedIV (OCTET STRING SIZE(16)).

crypto, security

normative-requirement §2.2 MUST

The parameter associated with the id-npki-app-cmsSeed-wrap OID MUST be absent, because the key wrapping procedure itself defines how and when to use an IV.

crypto, security

protocol-element §2.1

SEED content-encryption algorithm in CBC mode is identified by OID id-seedCBC: { iso(1) member-body(2) korea(410) kisa(200004) algorithm(1) seedCBC(4) }. This OID is used when SEED is applied for content encryption in CMS.

crypto, security

protocol-element §2.2

SEED key-encryption algorithm is identified by OID id-npki-app-cmsSeed-wrap: { iso(1) member-body(2) korea(410) kisa(200004) npki-app(7) smime(1) alg(1) cmsSEED-wrap(1) }. This OID is used when SEED wraps a content-encryption key (CEK).

crypto, security

protocol-element §3.4.1

The default Initial Value (IV) for the SEED key wrap integrity check register is the 64-bit hexadecimal constant A6A6A6A6A6A6A6A6. Recovering this value after unwrap confirms key data integrity with a 2^-64 probability of undetected corruption.

crypto, security

protocol-element §3.3

The SEED key unwrap algorithm takes as input a KEK K and (n+1) 64-bit ciphertext blocks {C[0]..C[n]}, reverses the wrap steps, and returns n plaintext blocks or an error if the recovered integrity check register A does not match the expected initial value.

crypto, security

protocol-element §3.2

The SEED key wrap algorithm takes as input a KEK K and n 64-bit plaintext key data blocks {P[1]..P[n]}, and produces (n+1) 64-bit ciphertext blocks {C[0]..C[n]}, performing s=6n encryption steps using SEED in a Feistel-style integrity-preserving wrap.

crypto, security

security-consideration §5

Security considerations from the CMS specifications [RFC3852, RFC3370] and the AES key wrap algorithm [RFC3394] apply to this document. No security problem has been found on SEED according to CRYPTREC evaluation. The document does not introduce new security mechanisms beyond those already in CMS.

crypto, security

wire-format §2.1

SeedCBCParameter is defined as SeedIV ::= OCTET STRING (SIZE(16)), a 128-bit (16-byte) initialization vector required as the AlgorithmIdentifier parameter for SEED-CBC content encryption.

crypto, security

wire-format §4

The SMIMECapability SEQUENCE for SEED MUST be DER-encoded as the hexadecimal string: 30 0C 06 08 2A 83 1A 8C 9A 44 01 04 05 00. SeedSMimeCapability is defined as NULL.

crypto, security, email