RFC 3713
A Description of the Camellia Encryption Algorithm
RFC 3713: A Description of the Camellia Encryption Algorithm 💖
Okay bestie, this one is Request for Comments 3713 🎀. It came out of the Network Working Group in April 2004 and it's Informational, so it's sharing info, not setting a standard 🦋. The authors are M. Matsui and J. Nakajima from Mitsubishi Electric Corporation, plus S. Moriai from Sony Computer Entertainment Inc. ✨ The title block doesn't list anything it obsoletes or updates, so it's just a solo mission 🧚
Status of This Memo
This memo gives info to the Internet community. It doesn't specify an Internet standard of any kind 🌸 Distribution is unlimited, so share away 💅
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. 🔒
Abstract
Okay so this doc describes the Camellia encryption algorithm 🌈 Camellia is a block cipher with a 128-bit block size and 128-, 192-, and 256-bit keys ✨ The algorithm description comes in two parts, the key scheduling part and the data randomizing part, and it's giving very organized 💜
1. Introduction ✨
1.1. Camellia
Camellia was jointly developed by Nippon Telegraph and Telephone Corporation and Mitsubishi Electric Corporation in 2000 [CamelliaSpec] 🎀 It has 128-bit block size and 128-, 192-, and 256-bit key sizes, which is the same interface as the Advanced Encryption Standard (AES) 🦋 Camellia is known for being good in both software and hardware, plus it's super secure, so it's a total main character 👑
From a practical view, it's designed to be flexible on 32-bit processors (the ones everywhere on the Internet) and on many other things too, like 8-bit processors in smart cards, cryptographic hardware, embedded systems, and so on [CamelliaTech] 🧚 It's also giving great key setup time, and its key agility is better than AES's 🔥
Camellia has been checked by the wide cryptographic community during several projects for evaluating crypto algorithms 🫶 The EU NESSIE (New European Schemes for Signatures, Integrity and Encryption) project [NESSIE] recommended it as a cryptographic primitive, and it's also on the list of cryptographic techniques for Japanese e-Government systems that the Japan CRYPTREC (Cryptography Research and Evaluation Committees) [CRYPTREC] picked 😭✨
2. Algorithm Description
Camellia can be split into a "key scheduling part" and a "data randomizing part" 💖
2.1. Terminology
These operators are what the doc uses to describe the algorithm 🌸
& bitwise AND operation.
| bitwise OR operation.
^ bitwise exclusive-OR operation.
<< logical left shift operation.
>> logical right shift operation.
<<< left rotation operation.
~y bitwise complement of y.
0x hexadecimal representation.Heads up, the logical left shift operation is done with infinite data width 👀
The constant values of MASK8, MASK32, MASK64, and MASK128 are defined like this 🍓
MASK8 = 0xff;
MASK32 = 0xffffffff;
MASK64 = 0xffffffffffffffff;
MASK128 = 0xffffffffffffffffffffffffffffffff;2.2. Key Scheduling Part
In the key schedule part of Camellia, we have the 128-bit variables KL and KR, and they're defined like this 🦋 For 128-bit keys, the 128-bit key K is used as KL, and KR is 0 🌈 For 192-bit keys, the leftmost 128 bits of K are used as KL, and KR is the concatenation of the rightmost 64 bits of K and the complement of the rightmost 64 bits of K 💅 For 256-bit keys, the leftmost 128 bits of K are used as KL, and the rightmost 128 bits of K are used as KR 🔥
128-bit key K:
KL = K; KR = 0;
192-bit key K:
KL = K >> 64;
KR = ((K & MASK64) << 64) | (~(K & MASK64));
256-bit key K:
KL = K >> 128;
KR = K & MASK128;The 128-bit variables KA and KB are generated from KL and KR like this 🧚 KB only gets used if the secret key is 192 or 256 bits, so keep that in mind 👀 D1 and D2 are 64-bit temporary variables, and the F-function is described in Section 2.4 ✨
D1 = (KL ^ KR) >> 64;
D2 = (KL ^ KR) & MASK64;
D2 = D2 ^ F(D1, Sigma1);
D1 = D1 ^ F(D2, Sigma2);
D1 = D1 ^ (KL >> 64);
D2 = D2 ^ (KL & MASK64);
D2 = D2 ^ F(D1, Sigma3);
D1 = D1 ^ F(D2, Sigma4);
KA = (D1 << 64) | D2;
D1 = (KA ^ KR) >> 64;
D2 = (KA ^ KR) & MASK64;
D2 = D2 ^ F(D1, Sigma5);
D1 = D1 ^ F(D2, Sigma6);
KB = (D1 << 64) | D2;The 64-bit constants Sigma1, Sigma2, ..., Sigma6 are used as "keys" in the F-function 💜 In hexadecimal, they look like this 🎀
Sigma1 = 0xA09E667F3BCC908B;
Sigma2 = 0xB67AE8584CAA73B2;
Sigma3 = 0xC6EF372FE94F82BE;
Sigma4 = 0x54FF53A5F1D36F1C;
Sigma5 = 0x10E527FADE682D1D;
Sigma6 = 0xB05688C2B3E6C1FD;64-bit subkeys are made by rotating KL, KR, KA, and KB and then taking the left or right half of them 🌸
For 128-bit keys, the 64-bit subkeys kw1, ..., kw4, k1, ..., k18, ke1, ..., ke4 are generated like this 🍓
kw1 = (KL <<< 0) >> 64;
kw2 = (KL <<< 0) & MASK64;
k1 = (KA <<< 0) >> 64;
k2 = (KA <<< 0) & MASK64;
k3 = (KL <<< 15) >> 64;
k4 = (KL <<< 15) & MASK64;
k5 = (KA <<< 15) >> 64;
k6 = (KA <<< 15) & MASK64;
ke1 = (KA <<< 30) >> 64;
ke2 = (KA <<< 30) & MASK64;
k7 = (KL <<< 45) >> 64;
k8 = (KL <<< 45) & MASK64;
k9 = (KA <<< 45) >> 64;
k10 = (KL <<< 60) & MASK64;
k11 = (KA <<< 60) >> 64;
k12 = (KA <<< 60) & MASK64;
ke3 = (KL <<< 77) >> 64;
ke4 = (KL <<< 77) & MASK64;
k13 = (KL <<< 94) >> 64;
k14 = (KL <<< 94) & MASK64;
k15 = (KA <<< 94) >> 64;
k16 = (KA <<< 94) & MASK64;
k17 = (KL <<< 111) >> 64;
k18 = (KL <<< 111) & MASK64;
kw3 = (KA <<< 111) >> 64;
kw4 = (KA <<< 111) & MASK64;For 192- and 256-bit keys, the 64-bit subkeys kw1, ..., kw4, k1, ..., k24, ke1, ..., ke6 are generated like this 🫶
kw1 = (KL <<< 0) >> 64;
kw2 = (KL <<< 0) & MASK64;
k1 = (KB <<< 0) >> 64;
k2 = (KB <<< 0) & MASK64;
k3 = (KR <<< 15) >> 64;
k4 = (KR <<< 15) & MASK64;
k5 = (KA <<< 15) >> 64;
k6 = (KA <<< 15) & MASK64;
ke1 = (KR <<< 30) >> 64;
ke2 = (KR <<< 30) & MASK64;
k7 = (KB <<< 30) >> 64;
k8 = (KB <<< 30) & MASK64;
k9 = (KL <<< 45) >> 64;
k10 = (KL <<< 45) & MASK64;
k11 = (KA <<< 45) >> 64;
k12 = (KA <<< 45) & MASK64;
ke3 = (KL <<< 60) >> 64;
ke4 = (KL <<< 60) & MASK64;
k13 = (KR <<< 60) >> 64;
k14 = (KR <<< 60) & MASK64;
k15 = (KB <<< 60) >> 64;
k16 = (KB <<< 60) & MASK64;
k17 = (KL <<< 77) >> 64;
k18 = (KL <<< 77) & MASK64;
ke5 = (KA <<< 77) >> 64;
ke6 = (KA <<< 77) & MASK64;
k19 = (KR <<< 94) >> 64;
k20 = (KR <<< 94) & MASK64;
k21 = (KA <<< 94) >> 64;
k22 = (KA <<< 94) & MASK64;
k23 = (KL <<< 111) >> 64;
k24 = (KL <<< 111) & MASK64;
kw3 = (KB <<< 111) >> 64;
kw4 = (KB <<< 111) & MASK64;2.3. Data Randomizing Part
2.3.1. Encryption for 128-bit keys
The 128-bit plaintext M gets split into the left 64-bit D1 and the right 64-bit D2 ✨
D1 = M >> 64;
D2 = M & MASK64;Encryption runs an 18-round Feistel structure, with FL- and FLINV-functions inserted every 6 rounds 🔥 The F-function, FL-function, and FLINV-function are all described in Section 2.4 🧚
D1 = D1 ^ kw1; // Prewhitening
D2 = D2 ^ kw2;
D2 = D2 ^ F(D1, k1); // Round 1
D1 = D1 ^ F(D2, k2); // Round 2
D2 = D2 ^ F(D1, k3); // Round 3
D1 = D1 ^ F(D2, k4); // Round 4
D2 = D2 ^ F(D1, k5); // Round 5
D1 = D1 ^ F(D2, k6); // Round 6
D1 = FL (D1, ke1); // FL
D2 = FLINV(D2, ke2); // FLINV
D2 = D2 ^ F(D1, k7); // Round 7
D1 = D1 ^ F(D2, k8); // Round 8
D2 = D2 ^ F(D1, k9); // Round 9
D1 = D1 ^ F(D2, k10); // Round 10
D2 = D2 ^ F(D1, k11); // Round 11
D1 = D1 ^ F(D2, k12); // Round 12
D1 = FL (D1, ke3); // FL
D2 = FLINV(D2, ke4); // FLINV
D2 = D2 ^ F(D1, k13); // Round 13
D1 = D1 ^ F(D2, k14); // Round 14
D2 = D2 ^ F(D1, k15); // Round 15
D1 = D1 ^ F(D2, k16); // Round 16
D2 = D2 ^ F(D1, k17); // Round 17
D1 = D1 ^ F(D2, k18); // Round 18
D2 = D2 ^ kw3; // Postwhitening
D1 = D1 ^ kw4;The 128-bit ciphertext C gets built from D1 and D2 like this 💖
C = (D2 << 64) | D1;2.3.2. Encryption for 192- and 256-bit keys
The 128-bit plaintext M gets split into the left 64-bit D1 and the right 64-bit D2 🌈
D1 = M >> 64;
D2 = M & MASK64;This time it's a 24-round Feistel structure, with FL- and FLINV-functions inserted every 6 rounds 💅 The F-function, FL-function, and FLINV-function are all described in Section 2.4 🦋
D1 = D1 ^ kw1; // Prewhitening
D2 = D2 ^ kw2;
D2 = D2 ^ F(D1, k1); // Round 1
D1 = D1 ^ F(D2, k2); // Round 2
D2 = D2 ^ F(D1, k3); // Round 3
D1 = D1 ^ F(D2, k4); // Round 4
D2 = D2 ^ F(D1, k5); // Round 5
D1 = D1 ^ F(D2, k6); // Round 6
D1 = FL (D1, ke1); // FL
D2 = FLINV(D2, ke2); // FLINV
D2 = D2 ^ F(D1, k7); // Round 7
D1 = D1 ^ F(D2, k8); // Round 8
D2 = D2 ^ F(D1, k9); // Round 9
D1 = D1 ^ F(D2, k10); // Round 10
D2 = D2 ^ F(D1, k11); // Round 11
D1 = D1 ^ F(D2, k12); // Round 12
D1 = FL (D1, ke3); // FL
D2 = FLINV(D2, ke4); // FLINV
D2 = D2 ^ F(D1, k13); // Round 13
D1 = D1 ^ F(D2, k14); // Round 14
D2 = D2 ^ F(D1, k15); // Round 15
D1 = D1 ^ F(D2, k16); // Round 16
D2 = D2 ^ F(D1, k17); // Round 17
D1 = D1 ^ F(D2, k18); // Round 18
D1 = FL (D1, ke5); // FL
D2 = FLINV(D2, ke6); // FLINV
D2 = D2 ^ F(D1, k19); // Round 19
D1 = D1 ^ F(D2, k20); // Round 20
D2 = D2 ^ F(D1, k21); // Round 21
D1 = D1 ^ F(D2, k22); // Round 22
D2 = D2 ^ F(D1, k23); // Round 23
D1 = D1 ^ F(D2, k24); // Round 24
D2 = D2 ^ kw3; // Postwhitening
D1 = D1 ^ kw4;The 128-bit ciphertext C gets built from D1 and D2 like this 🧚
C = (D2 << 64) | D1;2.3.3. Decryption
Decryption works the same way as encryption, you just reverse the order of the subkeys 🔥 Like, that's literally the whole trick 💅
That is to say:
For a 128-bit key 👑
kw1 <-> kw3
kw2 <-> kw4
k1 <-> k18
k2 <-> k17
k3 <-> k16
k4 <-> k15
k5 <-> k14
k6 <-> k13
k7 <-> k12
k8 <-> k11
k9 <-> k10
ke1 <-> ke4
ke2 <-> ke3For a 192- or 256-bit key 🌸
kw1 <-> kw3
kw2 <-> kw4
k1 <-> k24
k2 <-> k23
k3 <-> k22
k4 <-> k21
k5 <-> k20
k6 <-> k19
k7 <-> k18
k8 <-> k17
k9 <-> k16
k10 <-> k15
k11 <-> k14
k12 <-> k13
ke1 <-> ke6
ke2 <-> ke5
ke3 <-> ke42.4. Components of Camellia
This is where the building blocks live, the F-function, FL-function, and FLINV-function that all the rounds above keep calling 🧚✨ Part 2 picks up right here 🫶
2.4.1. F-function
okay so the F-function is literally the main character 💅 It takes two parameters. The first is the 64-bit input data F_IN, and the second is the 64-bit subkey KE. It spits out 64-bit data F_OUT 🦋
F(F_IN, KE)
begin
var x as 64-bit unsigned integer;
var t1, t2, t3, t4, t5, t6, t7, t8 as 8-bit unsigned integer;
var y1, y2, y3, y4, y5, y6, y7, y8 as 8-bit unsigned integer;
x = F_IN ^ KE;
t1 = x >> 56;
t2 = (x >> 48) & MASK8;
t3 = (x >> 40) & MASK8;
t4 = (x >> 32) & MASK8;
t5 = (x >> 24) & MASK8;
t6 = (x >> 16) & MASK8;
t7 = (x >> 8) & MASK8;
t8 = x & MASK8;
t1 = SBOX1[t1];
t2 = SBOX2[t2];
t3 = SBOX3[t3];
t4 = SBOX4[t4];
t5 = SBOX2[t5];
t6 = SBOX3[t6];
t7 = SBOX4[t7];
t8 = SBOX1[t8];
y1 = t1 ^ t3 ^ t4 ^ t6 ^ t7 ^ t8;
y2 = t1 ^ t2 ^ t4 ^ t5 ^ t7 ^ t8;
y3 = t1 ^ t2 ^ t3 ^ t5 ^ t6 ^ t8;
y4 = t2 ^ t3 ^ t4 ^ t5 ^ t6 ^ t7;
y5 = t1 ^ t2 ^ t6 ^ t7 ^ t8;
y6 = t2 ^ t3 ^ t5 ^ t7 ^ t8;
y7 = t3 ^ t4 ^ t5 ^ t6 ^ t8;
y8 = t1 ^ t4 ^ t5 ^ t6 ^ t7;
F_OUT = (y1 << 56) | (y2 << 48) | (y3 << 40) | (y4 << 32)
| (y5 << 24) | (y6 << 16) | (y7 << 8) | y8;
return FO_OUT;
end.so the whole vibe is: XOR the input with the subkey, chop it into eight bytes, run each byte through a lookup table, mix them back together with XORs, and stitch the result into 64 bits ✨ the return FO_OUT; line is spelled exactly like that in the original, btw, so don't panic if it looks like a typo 🙈
SBOX1, SBOX2, SBOX3, and SBOX4 are lookup tables that take 8-bit input and give 8-bit output. The bestie-friendly part is that SBOX2, SBOX3, and SBOX4 are all built out of SBOX1, like a family tree 🌳
SBOX2[x] = SBOX1[x] <<< 1;
SBOX3[x] = SBOX1[x] <<< 7;
SBOX4[x] = SBOX1[x <<< 1];SBOX1 is the OG table below. For example, SBOX1[0x3d] equals 86, so you can check your work 💜
SBOX1:
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: 112 130 44 236 179 39 192 229 228 133 87 53 234 12 174 65
10: 35 239 107 147 69 25 165 33 237 14 79 78 29 101 146 189
20: 134 184 175 143 124 235 31 206 62 48 220 95 94 197 11 26
30: 166 225 57 202 213 71 93 61 217 1 90 214 81 86 108 77
40: 139 13 154 102 251 204 176 45 116 18 43 32 240 177 132 153
50: 223 76 203 194 52 126 118 5 109 183 169 49 209 23 4 215
60: 20 88 58 97 222 27 17 28 50 15 156 22 83 24 242 34
70: 254 68 207 178 195 181 122 145 36 8 232 168 96 252 105 80
80: 170 208 160 125 161 137 98 151 84 91 30 149 224 255 100 210
90: 16 196 0 72 163 247 117 219 138 3 230 218 9 63 221 148
a0: 135 92 131 2 205 74 144 51 115 103 246 243 157 127 191 226
b0: 82 155 216 38 200 55 198 59 129 150 111 75 19 190 99 46
c0: 233 121 167 140 159 110 188 142 41 245 249 182 47 253 180 89
d0: 120 152 6 106 231 70 113 186 212 37 171 66 136 162 141 250
e0: 114 7 185 85 248 238 172 10 54 73 42 104 60 56 241 164
f0: 64 40 211 123 187 201 67 193 21 227 173 244 119 199 128 1582.4.2. FL- and FLINV-functions
the FL-function is another slay 🎀 It takes two parameters: the 64-bit input data FL_IN and the 64-bit subkey KE. It returns 64-bit data FL_OUT.
FL(FL_IN, KE)
begin
var x1, x2 as 32-bit unsigned integer;
var k1, k2 as 32-bit unsigned integer;
x1 = FL_IN >> 32;
x2 = FL_IN & MASK32;
k1 = KE >> 32;
k2 = KE & MASK32;
x2 = x2 ^ ((x1 & k1) <<< 1);
x1 = x1 ^ (x2 | k2);
FL_OUT = (x1 << 32) | x2;
end.and then there's FLINV, which is the inverse of FL. so if you undo FL, you get FLINV 🔄 it's giving "undo button" energy 🌸
FLINV(FLINV_IN, KE)
begin
var y1, y2 as 32-bit unsigned integer;
var k1, k2 as 32-bit unsigned integer;
y1 = FLINV_IN >> 32;
y2 = FLINV_IN & MASK32;
k1 = KE >> 32;
k2 = KE & MASK32;
y1 = y1 ^ (y2 | k2);
y2 = y2 ^ ((y1 & k1) <<< 1);
FLINV_OUT = (y1 << 32) | y2;
end.3. Object Identifiers 🏷️
okay so here's where we get our official name tags. The Object Identifier for Camellia with a 128-bit key in Cipher Block Chaining (CBC) mode looks like this:
id-camellia128-cbc OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) 392 200011 61 security(1)
algorithm(1) symmetric-encryption-algorithm(1)
camellia128-cbc(2) }The Object Identifier for Camellia with a 192-bit key in CBC mode is:
id-camellia192-cbc OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) 392 200011 61 security(1)
algorithm(1) symmetric-encryption-algorithm(1)
camellia192-cbc(3) }And the Object Identifier for Camellia with a 256-bit key in CBC mode is:
id-camellia256-cbc OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) 392 200011 61 security(1)
algorithm(1) symmetric-encryption-algorithm(1)
camellia256-cbc(4) }these algorithms need an Initialization Vector (IV) 🫶 to figure out the IV value, they take parameters like this:
CamelliaCBCParameter ::= CamelliaIV -- Initialization Vector
CamelliaIV ::= OCTET STRING (SIZE(16))when these object identifiers are used, the plaintext gets padded before encryption according to RFC2315 [RFC2315]. don't skip the padding, bestie 🙏
4. Security Considerations 🔐
okay this part is SERIOUS, so pay attention 🚨 The recent advances in cryptanalytic techniques are remarkable. A quantitative evaluation of security against powerful cryptanalytic techniques, such as differential cryptanalysis and linear cryptanalysis, is considered to be essential when designing any new block cipher. The authors evaluated the security of Camellia by using state-of-the-art cryptanalytic techniques. They confirmed that Camellia has no differential and linear characteristics that hold with probability more than 2^(-128). That means it is extremely unlikely that differential and linear attacks will succeed against the full 18-round Camellia 💀 Camellia was also designed to offer security against other advanced cryptanalytic attacks, including higher order differential attacks, interpolation attacks, related-key attacks, truncated differential attacks, and so on [Camellia]. the vibe is "we tested this so hard" 💪✨
5. Informative References 📚
these are the sources the spec leans on. here they all are, with every detail kept:
[CamelliaSpec]Aoki, K., Ichikawa, T., Kanda, M., Matsui, M., Moriai, S., Nakajima, J. and T. Tokita, "Specification of Camellia --- a 128-bit Block Cipher". http://info.isl.ntt.co.jp/camellia/[CamelliaTech]Aoki, K., Ichikawa, T., Kanda, M., Matsui, M., Moriai, S., Nakajima, J. and T. Tokita, "Camellia: A 128-Bit Block Cipher Suitable for Multiple Platforms". http://info.isl.ntt.co.jp/camellia/[Camellia]Aoki, K., Ichikawa, T., Kanda, M., Matsui, M., Moriai, S., Nakajima, J. and T. Tokita, "Camellia: A 128-Bit Block Cipher Suitable for Multiple Platforms - Design and Analysis -", In Selected Areas in Cryptography, 7th Annual International Workshop, SAC 2000, Waterloo, Ontario, Canada, August 2000, Proceedings, Lecture Notes in Computer Science 2012, pp.39-56, Springer-Verlag, 2001.[CRYPTREC]"CRYPTREC Advisory Committee Report FY2002", Ministry of Public Management, Home Affairs, Posts and Telecommunications, and Ministry of Economy, Trade and Industry, March 2003. http://www.soumu.go.jp/joho_tsusin/security/cryptrec.html, CRYPTREC home page by Information-technology Promotion Agency, Japan (IPA) http://www.ipa.go.jp/security/enc/CRYPTREC/index-e.html[NESSIE]New European Schemes for Signatures, Integrity and Encryption (NESSIE) project. http://www.cryptonessie.org[RFC2315]Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998.
Appendix A. Example Data of Camellia 🧪
here are the test vectors in hex, so you can check that your implementation is literally correct 🫶
128-bit key
Key : 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10
Plaintext : 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10
Ciphertext: 67 67 31 38 54 96 69 73 08 57 06 56 48 ea be 43
192-bit key
Key : 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10
: 00 11 22 33 44 55 66 77
Plaintext : 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10
Ciphertext: b4 99 34 01 b3 e9 96 f8 4e e5 ce e7 d7 9b 09 b9
256-bit key
Key : 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10
: 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff
Plaintext : 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10
Ciphertext: 9a cc 23 7d ff 16 d7 6c 20 ef 7c 91 9e 3a 75 09Acknowledgements 🌷
Shiho Moriai worked for NTT when this document was developed. Thank you, queen 👑
Authors' Addresses 📮
the authors, with their contact info exactly as listed:
Mitsuru Matsui
Mitsubishi Electric Corporation
Information Technology R&D Center
5-1-1 Ofuna, Kamakura
Kanagawa 247-8501, Japan
Phone: +81-467-41-2190
Fax: +81-467-41-2185
EMail: matsui@iss.isl.melco.co.jp
Junko Nakajima
Mitsubishi Electric Corporation
Information Technology R&D Center
5-1-1 Ofuna, Kamakura
Kanagawa 247-8501, Japan
Phone: +81-467-41-2190
Fax: +81-467-41-2185
EMail: june15@iss.isl.melco.co.jp
Shiho Moriai
Sony Computer Entertainment Inc.
Phone: +81-3-6438-7523
Fax: +81-3-6438-8629
EMail: shiho@rd.scei.sony.co.jp
camellia@isl.ntt.co.jp (Camellia team)Full Copyright Statement ⚖️
Copyright (C) The Internet Society (2004). 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. It also does not 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. And that's the whole spec, bestie 🎉🦋
📦 where this page comes from
- ietf: rfc3713 2004-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms