翻譯 RFC 4648: Base16、Base32 和 Base64 資料編碼
阿新 • • 發佈：2020-08-03
每年都會有人嘗試翻譯 RFC 系列文件，為了能更好地迭代和組織所翻譯的內容，我建立了一個 GitHub 倉庫，希望有興趣的人可以參與進來。翻譯是個既耗時又費力的事情，因此我期望的是一種細水長流的模式，即使是幾句話的翻譯或調整，都可以通過 PR 或郵件的方式提交，慢慢地積累來完成這一專案。
https://github.com/dianbo-rfc/dianbo-rfc
另外，為了方便 RFC 文件的閱讀，我試著建立了一個網站。網站的視覺效果應該會好些，使用了等寬字型，並且有中英對照；但畢竟是第一次進行網站開發，且使用的是最低配的伺服器，響應時間、頁面佈局會有很多問題。
https://dianbo-rfc.cn/progress
下面的譯文是釋出此文章時的版本，未來可能更新的譯文需要到 GitHub 或網站上閱讀：
Network Working Group S. Josefsson Request for Comments: 4648 SJD Obsoletes: 3548 October 2006 Category: Standards Track Base16、Base32 和 Base64 資料編碼 Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006). 摘要 此文件描述了經常使用的 base 64、base 32 和 base 16 編碼方案。此外, 它 還討論了以下內容: 在編碼資料中使用換行符、在編碼資料中使用填充符、在 編碼資料中使用非字母表中的字元、不同編碼字母表的使用、及規範編碼。 Josefsson Standards Track [Page 1] RFC 4648 Base-N Encodings October 2006 目錄 1. 導言 ............................................................3 2. 此文件中使用的約定 ..............................................3 3. 各實現間的差異 ..................................................3 3.1. 編碼資料中的換行符 .........................................3 3.2. 編碼資料中的填充符 .........................................4 3.3. 編碼資料中非字母表中字元的解釋 .............................4 3.4. 字母表的選擇 ...............................................4 3.5. 規範編碼 (Canonical Encoding) ..............................5 4. Base 64 編碼 ....................................................5 5. 具有 "對 URL 和檔名安全的字母表" 的 Base 64 編碼 ..............7 6. Base 32 編碼 ....................................................8 7. 具有 "擴充套件十六進位制的字母表" 的 Base 32 編碼 ....................10 8. Base 16 編碼 ...................................................10 9. 圖解和示例 .....................................................11 10. 測試樣例 ......................................................12 11. ISO C99 中的 Base64 編碼的實現 ................................14 12. 安全注意事項 ..................................................14 13. 自 RFC 3548 以來的修改 ........................................15 14. 致謝 ..........................................................15 15. Copying Conditions ............................................15 16. 參考文獻 ......................................................16 16.1. 前提類參考文獻 ...........................................16 16.2. 資訊類參考文獻 ...........................................16 Josefsson Standards Track [Page 2] RFC 4648 Base-N Encodings October 2006 1. 導言 由於歷史遺留原因, 有些環境只能使用 US-ASCII [1] 表示的資料, 而資料的 Base 編碼 (Base encoding) 經常被用在這種情況中。Base 編碼也可以被用於 不受歷史遺留原因所限制的新應用中, 僅僅是因為它使得 "通過文字編輯器來 操作物件" 成為可能。 過去, 不同的應用程式具有不同的需求, 因此它們有時會以略微不同的方式來 實現 Base 編碼。如今, 有些協議規範有時會普遍地使用 Base 編碼, 尤其是 "base64", 但是卻沒有該編碼的準確描述或參考文獻。多用途網際網路郵件擴充套件 (MIME, Multipurpose Internet Mail Extensions) 經常被用作是 base64 的 參考文獻, 但是它沒有考慮到換行符 (line-wrapping) 或非字母表中字元所造 成的結果。此規範的目的是建立起通用的字母表及編碼時的注意事項。這將有 望減少其它文件中的歧義性, 從而實現更好的互操作性。 2. 此文件中使用的約定 在此文件中, 關於關鍵詞【必須】、【禁止】、【必要的】、【應當】、 【不應】、【推薦的】、【可以】與【可選的】的解釋, 見 [2] 中的描 述。 3. 各實現間的差異 這裡, 我們將討論過去的各 Base 編碼實現之間的差異, 並在適當時, 規定了 用於將來的具體的推薦行為。 3.1. 編碼資料中的換行符 MIME [4] 經常被用作是 base 64 編碼的參考文獻。但是, MIME 並沒有定義 "base 64" 本身, 而是定義了被用於 MIME 中的 "base 64 內容傳輸編碼" ("base 64 Content-Transfer-Encoding")。其中, MIME 強制性限制了: 使用 base 64 編碼的資料, 其每行長度為 76 個字元。MIME 繼承了隱私增強郵件 (PEM, Privacy Enhanced Mail) [3] 中的編碼, 並指出它 "實際上是相同的"; 但是, PEM 使用的每行長度為 64 個字元。MIME 和 PEM 的限制都是由於 SMTP 中存在的限制所造成的。 程式實現【禁止】向使用 base 編碼的資料中新增換行符, 除非參考了此文件 的其它規範, 有明確地指示 base 編碼器: 在特定數量的字元後新增換行符。 Josefsson Standards Track [Page 3] RFC 4648 Base-N Encodings October 2006 3.2. 編碼資料中的填充符 在某些情況下, 不需要或不用在 base 編碼的資料中使用填充符 ("=")。在一 般情況下, 當無法假設傳輸資料的大小時, 需要使用填充符來產生正確的編碼 資料。 程式實現【必須】在編碼資料的末尾包含適當的填充字元, 除非參考了此文件 的其它規範另有明確規定。 base64 和 base32 編碼中的字母表使用了填充符, 見下面第 4 節和第 6 節的 描述, 但是 base16 編碼中的字母表不需要它, 見第 8 節。 3.3. 編碼資料中非字母表中字元的解釋 Base 編碼使用了一個特殊的、刪減版的字母表來編碼二進位制資料。由於資料損 壞或設計原因, base 編碼的資料中可能存在非字母表中的字元。非字母表中的 字元可能被用作 "隱蔽通道" ("covert channel"), 其中非協議的資料可能出 於惡意目的而被髮送。此外, 為了探索實現中的錯誤 (例如, 可能導致記憶體溢 出攻擊), 非字母表中的字元也可能會被髮送。 當程式實現在解釋 base 編碼的資料時, 若發現數據中包含 base 字母表外的 字元, 程式實現【必須】拒絕編碼資料, 除非參考了此文件的其它規範另有明 確規定。這些規範可能會同 MIME 一樣規定: 在解釋資料時, 應當簡單地忽略 掉在 base 編碼字母表以外的字元 ("在接受的內容上要放寬")。注意, 這意味 著: 任何相鄰的回車/換行 (CRLF) 均構成 "非字母表中字元", 並被忽略掉。 此外, 這類規範【可以】將出現在編碼資料末尾的填充符 "=" 認作是非字母表 中的字元, 並將其忽略掉。如果在字串的末尾發現了超出允許數量的填充字 符 (例如, 一個 base 64 字串以 "===" 結束), 則超出的填充字元【可以】 被忽略。 3.4. 字母表的選擇 不同的應用對字母表中的字元有不同的需求。以下是一些需求, 用於確定應當 使用哪個字母表: Josefsson Standards Track [Page 4] RFC 4648 Base-N Encodings October 2006 o 由人類處理。字元 "0" 和 "O" 很容易混淆, 字元 "1"、"l" 和 "I" 也很 容易混淆。在下面的 base32 字母表中, 沒有字元 "0" (零) 和 "1" (一), 根據情況, 一個解碼器可能將 0 解釋為 O, 並將 1 解釋為 I 或 L 。(但 是, 在預設情況下, 不應如此; 見前面的章節。) o 編碼後的資料, 其結構要滿足其它要求。對於 base 16 和 base 32 編碼, 這確定了使用大寫或小寫的字母表。對於 base 64 編碼, 非字母表中的字 符 (特別是 "/") 可能會在檔名和 URL 中出現問題。 o 用作識別符號。一些字元, 特別是 base 64 字母表中的 "+" 和 "/", 會被傳 統的文字搜尋/索引工具視為分詞符。 沒有能夠滿足所有的需求、被普遍接受的字母表。一個關於高度專業化變體的 示例, 見 IMAP [8]。在此文件中, 我們記錄並命名了一些當前正在被使用的字 母表。 3.5. 規範編碼 (Canonical Encoding) base 64 和 base 32 編碼中的填充步驟, 如果沒有被正確地實現, 將會導致編 碼後的資料出現不易察覺的改變。例如, 對於 base 64 編碼, 如果它的輸入僅 為一個八位位元組, 則使用到了第一個符號中所有 6 個位元位, 但是隻使用了下 一個符號中前 2 個位元位。遵循協議的編碼器【必須】將擴充的位元位置零, 這將在下文描述填充符時進步一說明。如果不保留這一特性, 則不存在對 base 編碼的規範表示, 且會出現: 多個 base 編碼字串被解碼為相同的二進位制數 據。如果保留這一特性, 則能夠保證規範編碼。 在一些環境中, 對於資料中的變動非常嚴格, 因此: 如果未將填充位元位置為 零, 則編碼器【可以】選擇拒絕編碼資料。與此相關的規範可能規定一個特殊 的行為。 4. Base 64 編碼 下文中對 base 64 編碼的描述來自於 [3], [4], [5] 與 [6]。可以使用 "base64" 來代稱此編碼方案。 Base 64 編碼被設計成: 在允許使用區分大小寫的表示形式時, 它能夠表示任 意的八位元組序列, 但是並不需要被人類可讀。 Josefsson Standards Track [Page 5] RFC 4648 Base-N Encodings October 2006 編碼使用了一個包含 US-ASCII 中的 65 個字元的字元子集, 其中的每個可打 印字元能夠表示 6 位元的資料。(額外的第 65 個字元是 "=", 其被用於表示 需要特殊的處理)。 編碼的過程是將 "24 位組" 的多組輸入位元, 表示為多個 "由 4 個編碼字元 構成" 的多個字串。按照從左至右的處理順序, 每 3 個 "8 位組" 的原始輸 入構成一個 "24 位組" 的編碼輸入。這些 "24 位組" 的輸入將被視作由 4 個 "6 位組" 的資料構成, 每一組都會被編碼為 base 64 字母表中的單個字元。 每個 6 位組的資料被用作 "64 個可列印字元的陣列" 的索引。被索引所引用 的字元置於輸出字串中。 表 1: Base 64 編碼的字母表 值 編碼 值 編碼 值 編碼 值 編碼 0 A 17 R 34 i 51 z 1 B 18 S 35 j 52 0 2 C 19 T 36 k 53 1 3 D 20 U 37 l 54 2 4 E 21 V 38 m 55 3 5 F 22 W 39 n 56 4 6 G 23 X 40 o 57 5 7 H 24 Y 41 p 58 6 8 I 25 Z 42 q 59 7 9 J 26 a 43 r 60 8 10 K 27 b 44 s 61 9 11 L 28 c 45 t 62 + 12 M 29 d 46 u 63 / 13 N 30 e 47 v 14 O 31 f 48 w (填充符) = 15 P 32 g 49 x 16 Q 33 h 50 y 如果在資料的末尾, 可用於編碼的資料少於 24 位元, 則需進行特殊的處理。 使得在對資料的末尾編碼時, 總是能夠以完整的 "24 位組" 的編碼方式結束。 當輸入位元組中的位數少於 24 位元時, 會在輸入的右側新增值為 0 的位元, 以構成一個完整的 "6 位組"。接著使用字元 "=" 對資料的末尾進行填充。因 為, 所有 base 64 編碼的輸入都是整數個八位位元組, 所以只會出現一下情況: (1) 如果編碼輸入的最後部分的位元位數是 24 的整數倍; 則編碼輸出的最後 部分的字元個數是 4 的整數倍, 且沒有用字元 "=" 填充。 Josefsson Standards Track [Page 6] RFC 4648 Base-N Encodings October 2006 (2) 如果編碼輸入的最後部分的位元位數剛好是 8 位; 則編碼輸出的最後部分 將會是: 2 個編碼字元, 再後跟 2 個 "=" 填充符。 (3) 如果編碼輸入的最後部分的位元位數剛好是 16 位; 則編碼輸出的最後部 分將會是: 3 個編碼字元, 再後跟 1 個 "=" 填充符。 5. 具有 "對 URL 和檔名安全的字母表" 的 Base 64 編碼 具有 "對 URL 和檔名安全的字母表" 的 Base 64 編碼, 已經被用於 [12]。 有些替換用的字母表, 建議使用 "~" 作為第 63 個字元。因為, 在一些檔案系 統的環境中, 字元 "~" 具有特殊的含義, 所以建議還是使用本節所描述的編碼 方案。剩餘的未被 URI 所保留的字元是 ".", 但是在一些檔案系統的環境中, 不允許在一個檔名中使用多個 ".", 因此使得字元 "." 也沒有吸引力。 當在 URI [9] 中使用時, 填充字元 "=" 通常是被百分號編碼的 (percent- encoded), 但是如果隱士地知道資料的長度, 則可以通過跳過填充符來避免這 一情況; 見第 3.2 節。 這裡給出的編碼方案可用 "base64url" 來代稱。不應認為此編碼與 "base64" 編碼相同, 且不應僅用 "base64" 來指代此編碼。除非另有說明, 否則 "base64" 指代的是前面章節中的 base 64 編碼。 此編碼方案, 除了在第 62 個和第 63 個字元上有所區別, 從技術上而言與之 前的相同, 如表 2 所示。 Josefsson Standards Track [Page 7] RFC 4648 Base-N Encodings October 2006 表 2: "對 URL 和檔名安全的" Base 64 編碼的字母表 值 編碼 值 編碼 值 編碼 值 編碼 0 A 17 R 34 i 51 z 1 B 18 S 35 j 52 0 2 C 19 T 36 k 53 1 3 D 20 U 37 l 54 2 4 E 21 V 38 m 55 3 5 F 22 W 39 n 56 4 6 G 23 X 40 o 57 5 7 H 24 Y 41 p 58 6 8 I 25 Z 42 q 59 7 9 J 26 a 43 r 60 8 10 K 27 b 44 s 61 9 11 L 28 c 45 t 62 - (減號) 12 M 29 d 46 u 63 _ (下劃線) 13 N 30 e 47 v 14 O 31 f 48 w 15 P 32 g 49 x 16 Q 33 h 50 y (填充符) = 6. Base 32 編碼 下文中對 base 32 編碼的描述來自於 (更正後的) [11]。可以使用 "base32" 來代稱此編碼方案。 Base 32 編碼被設計成: 在需要使用不區分大小寫的表示形式時, 它能夠表示 任意的八位元組序列, 但是並不需要被人類可讀。 編碼使用了一個包含 US-ASCII 中的 33 個字元的字元子集, 其中的每個可打 印字元能夠表示 5 位元的資料。(額外的第 33 個字元是 "=", 其被用於表示 需要特殊的處理)。 編碼的過程是將 "40 位組" 的多組輸入位元, 表示為多個 "由 8 個編碼字元 構成" 的多個字串。按照從左至右的處理順序, 每 5 個 "8 位組" 的原始輸 入構成一個 "40 位組" 的編碼輸入。這些 "40 位組" 的輸入將被視作由 8 個 "5 位組" 的資料構成, 每一組都會被編碼為 base 32 字母表中的單個字元。 當一個位元流通過 base 32 編碼方式進行編碼時, 必須假定該位元流的位序滿 足最高位優先。因此, 在位元流的第一個 8 位位元組中, 第一個位元是最高位, 第八個位元是最低位, 依此類推。 Josefsson Standards Track [Page 8] RFC 4648 Base-N Encodings October 2006 每個 5 位組的資料被用作 "32 個可列印字元的陣列" 的索引。被索引所引用 的字元置於輸出字串中。這些字元是從 US-ASCII 的數字和大寫字母中選出, 如下表 3 所示: 表 3: Base 32 編碼的字母表 值 編碼 值 編碼 值 編碼 值 編碼 0 A 9 J 18 S 27 3 1 B 10 K 19 T 28 4 2 C 11 L 20 U 29 5 3 D 12 M 21 V 30 6 4 E 13 N 22 W 31 7 5 F 14 O 23 X 6 G 15 P 24 Y (填充符) = 7 H 16 Q 25 Z 8 I 17 R 26 2 如果在資料的末尾, 可用於編碼的資料少於 40 位元, 則需進行特殊的處理。 使得在對資料的末尾編碼時, 總是能夠以完整的 "40 位組" 的編碼方式結束。 當輸入位元組中的位數少於 40 位元時, 會在輸入的右側新增值為 0 的位元, 以構成一個完整的 "5 位組"。接著使用字元 "=" 對資料的末尾進行填充。因 為, 所有 base 32 編碼的輸入都是整數個八位位元組, 所以只會出現一下情況: (1) 如果編碼輸入的最後部分的位元位數是 40 的整數倍; 則編碼輸出的最後 部分的字元個數是 8 的整數倍, 且沒有用字元 "=" 填充。 (2) 如果編碼輸入的最後部分的位元位數剛好是 8 位; 則編碼輸出的最後部分 將會是: 2 個編碼字元, 再後跟 6 個 "=" 填充符。 (3) 如果編碼輸入的最後部分的位元位數剛好是 16 位; 則編碼輸出的最後部 分將會是: 4 個編碼字元, 再後跟 4 個 "=" 填充符。 (4) 如果編碼輸入的最後部分的位元位數剛好是 24 位; 則編碼輸出的最後部 分將會是: 5 個編碼字元, 再後跟 3 個 "=" 填充符。 (5) 如果編碼輸入的最後部分的位元位數剛好是 32 位; 則編碼輸出的最後部 分將會是: 7 個編碼字元, 再後跟 1 個 "=" 填充符。 Josefsson Standards Track [Page 9] RFC 4648 Base-N Encodings October 2006 7. 具有 "擴充套件十六進位制的字母表" 的 Base 32 編碼 下文中對 base 32 編碼的描述來自於 [7]。可以使用 "base32hex" 來代稱此 編碼方案。不應認為此編碼與 "base32" 編碼相同, 且不應僅用 "base32" 來 指代此編碼。此編碼有被用於 NextSECure3 (NSEC3) [10]。 此字母表具有一個 base64 和 base32 的字母表所缺少的特性, 即: 當對資料 通過按位比較的方式進行排序時, 該字母表能保證編碼後的資料具有同原始數 據相同的排序順序。 此編碼方案, 除了在字母表上有所區別, 其它方面與之前的相同。新的字母表 如表 4 所示。 表 4: "擴充套件十六進位制的" Base 32 編碼的字母表 值 編碼 值 編碼 值 編碼 值 編碼 0 0 9 9 18 I 27 R 1 1 10 A 19 J 28 S 2 2 11 B 20 K 29 T 3 3 12 C 21 L 30 U 4 4 13 D 22 M 31 V 5 5 14 E 23 N 6 6 15 F 24 O (填充符) = 7 7 16 G 25 P 8 8 17 H 26 Q 8. Base 16 編碼 下文中的描述是原始的, 但是與先前的描述類似。本質上, Base 16 編碼是標 準的不區分大小寫的十六進位制編碼, 且可以使用 "base16" 或 "hex" 來代稱此 編碼方案。 編碼使用了一個包含 US-ASCII 中的 16 個字元的字元子集, 其中的每個可打 印字元能夠表示 4 位元的資料。 編碼的過程是將 "8 位組" (即八位位元組) 的多組輸入位元, 表示為多個 "由 2 個編碼字元構成" 的多個字串。按照從左至右的處理順序, 從原始輸入中取 出 "8 位組" 作為編碼輸入。這些 "8 位組" 的輸入將被視作由 2 個 "4 位 組" 的資料構成, 每一組都會被編碼為 base 16 字母表中的單個字元。 每個 4 位組的資料被用作 "16 個可列印字元的陣列" 的索引。被索引所引用 的字元置於輸出字串中。 Josefsson Standards Track [Page 10] RFC 4648 Base-N Encodings October 2006 表 5: Base 16 編碼的字母表 值 編碼 值 編碼 值 編碼 值 編碼 0 0 4 4 8 8 12 C 1 1 5 5 9 9 13 D 2 2 6 6 10 A 14 E 3 3 7 7 11 B 15 F 不同於 base 32 和 base 64 編碼, 這裡不需要特殊的填充符; 因為 base 16 編碼的最小單元是八位位元組, 這在所有的資料中都能得到保證。 9. 圖解和示例 為了在二進位制和 base 編碼之間進行轉換, 需要將輸入儲存在某一結構中, 並 從中提取所需的輸出。下圖中所展示的 base 64 編碼的例子, 來自於 [5]。 +--first octet--+-second octet--+--third octet--+ |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| +-----------+---+-------+-------+---+-----------+ |5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0| +--1.index--+--2.index--+--3.index--+--4.index--+ 下圖所展示的 base 32 編碼的例子, 來自於 [7]。在 base-32 編碼後的值中, 每個連續的字元都表示: 原始的八位位元組序列中的 5 個連續位元。因此, 每組 "由 8 個編碼字元構成" 字串表示一個 "由 5 個八位位元組構成" (40 位元) 的序列。 1 2 3 01234567 89012345 67890123 45678901 23456789 +--------+--------+--------+--------+--------+ |< 1 >< 2| >< 3 ><|.4 >< 5.|>< 6 ><.|7 >< 8 >| +--------+--------+--------+--------+--------+ <===> 8th character <====> 7th character <===> 6th character <====> 5th character <====> 4th character <===> 3rd character <====> 2nd character <===> 1st character Josefsson Standards Track [Page 11] RFC 4648 Base-N Encodings October 2006 下面有關 Base64 資料編碼的示例來自於 [5] (已更正)。 Input data: 0x14fb9c03d97e Hex: 1 4 f b 9 c | 0 3 d 9 7 e 8-bit: 00010100 11111011 10011100 | 00000011 11011001 01111110 6-bit: 000101 001111 101110 011100 | 000000 111101 100101 111110 Decimal: 5 15 46 28 0 61 37 62 Output: F P u c A 9 l + Input data: 0x14fb9c03d9 Hex: 1 4 f b 9 c | 0 3 d 9 8-bit: 00010100 11111011 10011100 | 00000011 11011001 pad with 00 6-bit: 000101 001111 101110 011100 | 000000 111101 100100 Decimal: 5 15 46 28 0 61 36 pad with = Output: F P u c A 9 k = Input data: 0x14fb9c03 Hex: 1 4 f b 9 c | 0 3 8-bit: 00010100 11111011 10011100 | 00000011 pad with 0000 6-bit: 000101 001111 101110 011100 | 000000 110000 Decimal: 5 15 46 28 0 48 pad with = = Output: F P u c A w = = 10. 測試樣例 BASE64("") = "" BASE64("f") = "Zg==" BASE64("fo") = "Zm8=" BASE64("foo") = "Zm9v" BASE64("foob") = "Zm9vYg==" BASE64("fooba") = "Zm9vYmE=" BASE64("foobar") = "Zm9vYmFy" BASE32("") = "" BASE32("f") = "MY======" BASE32("fo") = "MZXQ====" Josefsson Standards Track [Page 12] RFC 4648 Base-N Encodings October 2006 BASE32("foo") = "MZXW6===" BASE32("foob") = "MZXW6YQ=" BASE32("fooba") = "MZXW6YTB" BASE32("foobar") = "MZXW6YTBOI======" BASE32-HEX("") = "" BASE32-HEX("f") = "CO======" BASE32-HEX("fo") = "CPNG====" BASE32-HEX("foo") = "CPNMU===" BASE32-HEX("foob") = "CPNMUOG=" BASE32-HEX("fooba") = "CPNMUOJ1" BASE32-HEX("foobar") = "CPNMUOJ1E8======" BASE16("") = "" BASE16("f") = "66" BASE16("fo") = "666F" BASE16("foo") = "666F6F" BASE16("foob") = "666F6F62" BASE16("fooba") = "666F6F6261" BASE16("foobar") = "666F6F626172" Josefsson Standards Track [Page 13] RFC 4648 Base-N Encodings October 2006 11. ISO C99 中的 Base64 編碼的實現 在 ISO C99 中有 Base64 編碼與解碼的實現, 該實現被認為是遵循了此 RFC 中的所有建議, 可以從這裡獲取: http://josefsson.org/base-encoding/ 其中給出的程式碼不是必須的。 由於工作流程相關的原因, 不能在此 RFC 中包含該程式碼 (見 RFC 3978 中第 5.4 節)。 12. 安全注意事項 在實現 base 編碼與解碼時, 需要注意: 不要引入會造成記憶體溢位攻擊、或其 它攻擊的漏洞。解碼器不應因無效輸入而崩潰, 例如遇到了嵌入在資料中的字 符 NUL (ASCII 0). 在解碼過程中, 如果選擇忽略掉非字母表中的字元, 且沒有 (按照建議) 拒絕 掉整個編碼資料, 則可能產生成一個導致資訊 "洩露" 的隱蔽通道 (covert channel)。被忽略的字元也可以被用於其它的惡意目的, 例如: 規避字串的 判等、或出發實現中的 bug。未遵循推薦做法的應用, 應當弄清: 忽略非字母 表中的字元, 這一行為背後的含義。類似的, 當以不區分大小寫的方式來處理 base 16 和 base 32 的字母表時, 字母大小寫的變化可能被用於洩露資訊、或 導致字串的判等失敗。 當使用填充符時, 需要考慮一些非有效位元位的安全性, 因為它們可能被濫用 來洩露資訊、或繞過字串的判等、或觸發實現中存在的問題。 Base 編碼從視覺上隱藏了那些的易被識別的資訊, 例如密碼, 但是它實際上並 未提供任何的計算保密性。而這有可能會導致安全事故, 例如: 當用戶在報告 網路協議所交換的詳細資訊時 (可能是為了說明其它問題), 會意外地將密碼洩 露, 因為她並沒有意識到 base 編碼不能保護密碼。 Base 編碼不會使文字熵增, 但是它確實增加了文字的長度, 並以特徵概率分佈 (characteristic probability distribution) 的形式為密碼分析過程 (cryptanalysis) 提供了簽名。 Josefsson Standards Track [Page 14] RFC 4648 Base-N Encodings October 2006 13. 自 RFC 3548 以來的修改 添加了 "使用擴充套件十六進位制字母表的 base32" 的內容, 該編碼被用於保留編碼 資料的排序順序。 參考了 IMAP, 以說明其中用到的特殊的 Base64 編碼。 修復了從 RFC 2440 複製過來的示例。 添加了有關 "提供密碼分析簽名" 的安全注意事項。 添加了測試樣例。 修復了筆誤。 14. 致謝 Several people offered comments and/or suggestions, including John E. Hadstate, Tony Hansen, Gordon Mohr, John Myers, Chris Newman, and Andrew Sieber. Text used in this document are based on earlier RFCs describing specific uses of various base encodings. The author acknowledges the RSA Laboratories for supporting the work that led to this document. This revised version is based in parts on comments and/or suggestions made by Roy Arends, Eric Blake, Brian E Carpenter, Elwyn Davies, Bill Fenner, Sam Hartman, Ted Hardie, Per Hygum, Jelte Jansen, Clement Kent, Tero Kivinen, Paul Kwiatkowski, and Ben Laurie. 15. Copying Conditions Copyright (c) 2000-2006 Simon Josefsson Regarding the abstract and sections 1, 3, 8, 10, 12, 13, and 14 of this document, that were written by Simon Josefsson ("the author", for the remainder of this section), the author makes no guarantees and is not responsible for any damage resulting from its use. The author grants irrevocable permission to anyone to use, modify, and distribute it in any way that does not diminish the rights of anyone else to use, modify, and distribute it, provided that redistributed derivative works do not contain misleading author or version information and do not falsely purport to be IETF RFC documents. Derivative works need not be licensed under similar terms. Josefsson Standards Track [Page 15] RFC 4648 Base-N Encodings October 2006 16. 參考文獻 16.1. 前提類參考文獻 [1] Cerf, V., "ASCII format for network interchange", RFC 20, October 1969. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 16.2. 資訊類參考文獻 [3] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421, February 1993. [4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [5] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998. [6] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [7] Klyne, G. and L. Masinter, "Identifying Composite Media Features", RFC 2938, September 2000. [8] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. [9] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [10] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNSSEC Hash Authenticated Denial of Existence", Work in Progress, June 2006. [11] Myers, J., "SASL GSSAPI mechanisms", Work in Progress, May 2000. [12] Wilcox-O'Hearn, B., "Post to P2P-hackers mailing list", http://zgp.org/pipermail/p2p-hackers/2001-September/ 000315.html, September 2001. Josefsson Standards Track [Page 16] RFC 4648 Base-N Encodings October 2006 作者地址 Simon Josefsson SJD EMail: [email protected] Josefsson Standards Track [Page 17] RFC 4648 Base-N Encodings October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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 [email protected]. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Josefsson Standards Track [Page 18]