トリプルDES

トリプルデータ暗号化アルゴリズム
	3DES 全体図
一般的な
初版	1981
由来	デス
暗号の詳細
キーサイズ	112 または 168 ビット
ブロックサイズ	64ビット
構造	フェイステルネットワーク
ラウンド	DES相当の48ラウンド
最高の公開暗号解読
	Lucks: 2 32 個の既知の平文、 2 90個の DES 暗号化を含む 2 113 個の操作、2 88 個のメモリ。Biham: 2 28 個のターゲットキーから 1 つを見つけ、キーごとに少数の選択された平文と 2 84 個の暗号化を使用する。

暗号化において、トリプル DES ( 3DESまたはTDES )、正式にはトリプルデータ暗号化アルゴリズム( TDEAまたはトリプル DEA ) は、対称鍵ブロック暗号であり、各データブロックにDES暗号アルゴリズムを 3 回適用します。データ暗号化標準 (DES) の 56 ビットキーは、現代の暗号解読技術とスーパーコンピューティングの能力を考えるともはや十分ではないと考えられています。トリプル DES は、有効なセキュリティを 112 ビットに高めます。2016年にリリースされたCVE 、 CVE-2016-2183 では、DES および 3DES 暗号化アルゴリズムに重大なセキュリティ脆弱性が明らかになりました。このCVEと3DESの不十分なキーサイズが相まって、NISTは2019年に3DESを非推奨にし、2023年末までにすべての使用（すでに暗号化されたデータの処理を除く）を禁止しました。^[1] 3DESは、より安全で堅牢なAESに置き換えられました。

米国政府および業界標準では、このアルゴリズムの名前をTDES（トリプルDES）およびTDEA（トリプルデータ暗号化アルゴリズム）と略していますが、^[2] RFC 1851では、このアイデアが最初に発表されたときから3DESと呼ばれており、この名前はその後、ほとんどのベンダー、ユーザー、暗号学者によって広く使用されるようになりました。^[3]^[4]^[5]^[6]

歴史

1978年、ウォルター・タックマンは2つの56ビットキーを使用したDESを使用した3重暗号化方式を提案しました。 1981年に、マークルとヘルマンは112ビットのセキュリティを備えた3DESのより安全な3重キーバージョンを提案しました。^[7]

標準

トリプルデータ暗号化アルゴリズムは、いくつかの標準文書でさまざまに定義されています。

RFC 1851、ESPトリプルDES変換^[8]（1995年に承認）
ANSI ANS X9.52-1998トリプルデータ暗号化アルゴリズムの動作モード^[9]（1998年に承認、2008年に撤回^[10]）
FIPS PUB 46-3データ暗号化規格（DES）^[11]（1999年に承認、2005年に撤回^[12]）
NIST特別刊行物800-67改訂2トリプルデータ暗号化アルゴリズム（TDEA）ブロック暗号に関する勧告^[13]（2017年に承認、2024年に撤回^[14]）
ISO / IEC 18033-3:2010: パート3: ブロック暗号^[15] (2005年に承認)

アルゴリズム

オリジナルの DES 暗号の56 ビットのキーサイズは、設計された時点では一般的に十分であると考えられていましたが、計算能力の向上により、ブルートフォース攻撃が可能になりました。トリプル DES は、まったく新しいブロック暗号アルゴリズムを設計する必要なく、DES のキーサイズを大きくしてこのような攻撃から保護する比較的簡単な方法を提供します。

DES のような短い鍵長を持つブロック暗号化アルゴリズムの強度を高める単純な方法は、1 つの鍵ではなく 2 つの鍵を使用し、各ブロックを 2 回暗号化することです。元の鍵長がビットの場合、この方式によりビットの長さの鍵を使用する場合と同等のセキュリティが実現されると期待できます。残念ながら、この方法は中間者攻撃に対して脆弱です。つまり、となる既知の平文ペアが与えられると、ビットの鍵を持つ理想的に安全なアルゴリズムから期待される手順ではなく、手順ごとに鍵ペアを復元できます。 $(K1,K2)$ $E_{K2}(E_{K1}({\textrm {plaintext}}))$ $n$ $2n$ $(x,y)$ $y=E_{K2}(E_{K1}(x))$ $(K1,K2)$ $2^{n+1}$ $2^{2n}$ $2n$

したがって、トリプル DES は、それぞれ 56 ビット (パリティビットを除く) の 3 つのDESキー、、で構成される「キーバンドル」を使用します。暗号化アルゴリズムは次のとおりです。 $K1$ $K2$ $K3$

{\textrm {暗号文}}=E_{K3}(D_{K2}(E_{K1}({\textrm {平文}}))).

つまり、で暗号化し、で復号化してからで暗号化します。 $K1$ $K2$ $K3$

復号化はその逆です:

{\textrm {平文}}=D_{K1}(E_{K2}(D_{K3}({\textrm {暗号文}}))).

つまり、で復号化し、で暗号化し、で復号化します。 $K3$ $K2$ $K1$

各トリプル暗号化では、64 ビットのデータブロック1 つが暗号化されます。

いずれの場合も、中間の操作は最初と最後の操作の逆になります。これにより、キーオプション 2 を使用する場合のアルゴリズムの強度が向上し、キーオプション 3 を使用した DES との下位互換性が確保されます。

キーイングオプション

標準では、3 つのキーイングオプションが定義されています。

キーイングオプション1: 3つの鍵はすべて独立しています。3TDEA ^[16]またはトリプル長鍵^{[17]と呼ばれることもあります。}
これは 3 × 56 = 168 個の独立したキービットを持つ最も強力な方法です。それでも中間者攻撃に対しては脆弱ですが、攻撃には 2 ^{2 × 56 の}手順が必要です。
キーイングオプション2: K ₁と K _{2 は}独立しており、K ₃ = K ₁である。2TDEA ^[16]または倍長鍵^{[17]と呼ばれることもある。}
これにより、56*2 または 112 ビットの短いキー長と、DES とキーオプション 1 の間の妥当な妥協点が提供されますが、上記と同じ注意事項があります。^{[18]これは、攻撃に 2}⁵⁶ステップしか必要としない「ダブル DES」よりも改善されています。NIST は 2015 年にこのオプションを禁止しました。^[16]
キーイングオプション3: 3 つのキーはすべて同一です (つまり、 K ₁ = K ₂ = K _{3 )}。
これは2つの演算が打ち消されるためDESと下位互換性がある。ISO/IEC 18033-3ではこのオプションは許可されておらず、NISTではK ₁ = K ₂またはK ₂ = K ₃は許可されていない。^[16]^[13]

各DESキーは8つの奇数パリティバイトで構成され、56ビットのキーと8ビットのエラー検出で構成されます。^[9]キーバンドルには、オプション1の場合は24バイト、オプション2の場合は16バイト、オプション3の場合は8バイトが必要です。

NIST (およびTrusted Platform Moduleの承認済みアルゴリズムの現在の TCG 仕様バージョン 2.0 ) では、次の 64 個の 64 ビット値のいずれかを任意のキーで使用することも禁止されています (これらのうち 32 個は他の 32 個の 2 進数の補数であり、これらのキーのうち 32 個は他の 32 個のバイトの逆順列でもあることに注意してください)。これらは 16 進数で次のようにリストされます (各バイトの最下位ビットは奇数パリティ生成ビットであり、実質的に 56 ビットのキーを形成するときに破棄されます)。

01.01.01.01.01.01.01、FE.FE.FE.FE.FE.FE.FE.FE、E0.FE.FE.E0.F1.FE.FE.F1、1F.01.01.1F.0E.01.01.0E、
01.01.FE.FE.01.01.FE.FE、FE.FE.01.01.FE.FE.01.01、E0.FE.01.1F.F1.FE.01.0E、1F.01.FE.E0.0E.01.FE.F1、
01.01.E0.E0.01.01.F1.F1、FE.FE.1F.1F.FE.FE.0E.0E、E0.FE.1F.01.F1.FE.0E.01、1F.01.E0.FE.0E.01.F1.FE、
01.01.1F.1F.01.01.0E.0E、FE.FE.E0.E0.FE.FE.F1.F1、E0.FE.E0.FE.F1.FE.F1.FE、1F.01.1F.01.0E.01.0E.01、
01.FE.01.FE.01.FE.01.FE、FE.01.FE.01.FE.01.FE.01、E0.01.FE.1F.F1.01.FE.0E、1F.FE.01.E0.0E.FE.01.F1、
01.FE.FE.01.01.FE.FE.01、FE.01.01.FE.FE.01.01.FE、E0.01.01.E0.F1.01.01.F1、1F.FE.FE.1F.0E.FE.FE.0E、
01.FE.E0.1F.01.FE.F1.0E、FE.01.1F.E0.FE.01.0E.F1、E0.01.1F.FE.F1.01.0E.FE、1F.FE.E0.01.0E.FE.F1.01、
01.FE.1F.E0.01.FE.0E.F1、FE.01.E0.1F.FE.01.F1.0E、E0.01.E0.01.F1.01.F1.01、1F.FE.1F.FE.0E.FE.0E.FE、
01.E0.01.E0.01.F1.01.F1、FE.1F.FE.1F.FE.0E.FE.0E、E0.1F.FE.01.F1.0E.FE.01、1F.E0.01.FE.0E.F1.01.FE、
01.E0.FE.1F.01.F1.FE.0E、FE.1F.01.E0.FE.0E.01.F1、E0.1F.01.FE.F1.0E.01.FE、1F.E0.FE.01.0E.F1.FE.01、
01.E0.E0.01.01.F1.F1.01、FE.1F.1F.FE.FE.0E.0E.FE、E0.1F.1F.E0.F1.0E.0E.F1、1F.E0.E0.1F.0E.F1.F1.0E、
01.E0.1F.FE.01.F1.0E.FE、FE.1F.E0.01.FE.0E.F1.01、E0.1F.E0.1F.F1.0E.F1.0E、1F.E0.1F.E0.0E.F1.0E.F1、
01.1F.01.1F.01.0E.01.0E、FE.E0.FE.E0.FE.F1.FE.F1、E0.E0.FE.FE.F1.F1.FE.FE、1F.1F.01.01.0E.0E.01.01、
01.1F.FE.E0.01.0E.FE.F1、FE.E0.01.1F.FE.F1.01.0E、E0.E0.01.01.F1.F1.01.01、1F.1F.FE.FE.0E.0E.FE.FE、
01.1F.E0.FE.01.0E.F1.FE、FE.E0.1F.01.FE.F1.0E.01、E0.E0.1F.1F.F1.F1.0E.0E、1F.1F.E0.E0.0E.0E.F1.F1、
01.1F.1F.01.01.0E.0E.01、FE.E0.E0.FE.FE.F1.F1.FE、E0.E0.E0.F1.F1.F1.F1、1F.1F.1F.1F.0E.0E.0E.0E

許可されるキーに対するこれらの制限により、トリプル DES はキーオプション 1 と 2 のみで再承認されました。通常、3 つのキーは強力なランダムジェネレーターから 24 バイトを取得して生成され、キーオプション 1 のみを使用する必要があります (オプション 2 では 16 のランダムバイトのみが必要ですが、強力なランダムジェネレーターはアサートするのが難しいため、オプション 1 のみを使用するのがベストプラクティスと見なされます)。

複数のブロックの暗号化

すべてのブロック暗号と同様に、複数のデータブロックの暗号化と復号化は、通常、ブロック暗号アルゴリズムとは独立して定義できるさまざまな動作モードを使用して実行できます。ただし、ANS X9.52 では直接指定され、NIST SP 800-67 では SP 800-38A ^[19]を介して指定されているように、一部のモードは、それらのモードの一般的な仕様に必ずしも適用されない特定の制約の下でのみ使用する必要があります。たとえば、ANS X9.52 では、暗号ブロック連鎖の場合、初期化ベクトルは毎回異なる必要があると指定されていますが、ISO/IEC 10116 ^[20]ではそうではありません。FIPS PUB 46-3 と ISO/IEC 18033-3 では、単一ブロックアルゴリズムのみが定義されており、複数のブロックの動作モードには制限がありません。

安全

一般的に、3つの独立したキー（キーオプション1）を持つトリプルDESのキーの長さは168ビット（3つの56ビットDESキー）ですが、中間者攻撃のため、有効なセキュリティは112ビットしかありません。^[16]キーオプション2では、有効なキーサイズが112ビットに削減されます（3番目のキーが最初のキーと同じであるため）。ただし、このオプションは、特定の選択平文攻撃または既知平文攻撃の影響を受けやすく、^[21]^[22]そのため、NISTでは80 ビットのセキュリティしか持たないと指定されています。^[16]これは安全ではないと考えられます。その結果、トリプルDESの廃止予定が2017年にNISTによって発表されました。^[23]

ブロックサイズが64ビットと短いため、同じキーで大量のデータを暗号化する場合、3DESはブロック衝突攻撃に対して脆弱になります。Sweet32攻撃は、これがTLSとOpenVPNでどのように悪用されるかを示しています。^[24] TLSの3DESベースの暗号スイートに対する実際のSweet32攻撃では、完全な攻撃にはブロック（785 GB）が必要でしたが、研究者は幸運にも約ブロック後に衝突を発見し、わずか25分で済みました。 $2^{36.6}$ $2^{20}$

TDEA のセキュリティは、1 つのキーバンドルで処理されるブロックの数によって影響を受けます。1 つのキーバンドルを使用して、64 ビットを超えるデータブロックに暗号化保護 (暗号化など) を適用することはできません。 $2^{20}$
— トリプルデータ暗号化アルゴリズム（TDEA）ブロック暗号の推奨事項（SP 800-67 Rev2）^[13]

OpenSSLはバージョン1.1.0（2016年8月）以降、デフォルトで3DESを含んでおらず、これを「弱い暗号」とみなしています。^[25]

使用法

2008年現在、電子決済業界ではトリプルDESが使用されており、 EMVなどそれに基づいた標準の開発と普及が続いています。^[26]

Microsoft OneNoteの以前のバージョン^[27] 、Microsoft Outlook 2007 ^[28]、Microsoft System Center Configuration Manager 2012 ^[29]では、ユーザーコンテンツとシステムデータをパスワードで保護するためにトリプルDESを使用しています。しかし、2018年12月に、マイクロソフトはOffice 365サービス全体で3DESを廃止すると発表しました。^[30]

FirefoxとMozilla Thunderbirdは、マスターパスワードを使用する際に、CBCモードのトリプルDESを使用してウェブサイト認証ログイン資格情報を暗号化します。 ^[31]

実装

以下は、Triple DES をサポートする暗号化ライブラリのリストです。

上記の実装の一部では、それ以降のバージョンまたは最近のバージョンでは、デフォルトのビルドに 3DES が含まれていない場合があります。

参照

参考文献と注記

^ Barker, Elaine; Roginsky, Allen (2019-03-01). 「暗号化アルゴリズムと鍵の長さの使用の移行」(PDF) . Gaithersburg, MD: NIST Publications. p. 7. doi :10.6028/nist.sp.800-131ar2. NIST SP 800-131A 改訂 2. 2019-05-11 にオリジナルからアーカイブ(PDF)されました。2022-09-20に取得。
^ 「トリプル DES 暗号化」。IBM。2010年 5 月 17 日閲覧。
^ アラナジ、ハムダン。 O。ザイダン、BB;ザイダン、AA;ジャラブ、ハミッド A.シャバー、M.アル・ナバニ、Y. (2010 年 3 月)。「9 つの要素内での DES、3DES、および AES 間の新しい比較研究」。コンピューティングジャーナル。2 (3)。arXiv : 1003.4085。Bibcode :2010arXiv1003.4085A。ISSN 2151-9617。
^ 「Cisco PIX 515E セキュリティアプライアンススタートアップガイド: DES ライセンスまたは 3DES-AES ライセンスの取得」(PDF)。Cisco 。2006 年。2016 年2月 7 日にオリジナルからアーカイブ(PDF) 。2017年 9 月 5 日に取得。
^ 「3DES アップデート: ほとんどの銀行は完了していますが...」ATM & Debit News。2007 年 3 月 29 日。2013 年 5 月 10 日時点のオリジナルよりアーカイブ。2017年 9 月 5 日に閲覧。
^ RFC 2828 および RFC 4949
^ Merkle, R. および M. Hellman、「多重暗号化のセキュリティについて」、Communications of the ACM、vol. 24、no. 7、pp. 465–467、1981 年 7 月。
^ Karn, P.; Metzger, P.; Simpson, W. (1995 年 9 月). ESP トリプル DES 変換. doi : 10.17487/RFC1851 . RFC 1851.
^ ab 「ANSI X9.52-1998 トリプルデータ暗号化アルゴリズムの動作モード」。 2017年9月5日閲覧。ANSI X3.92-1981データ暗号化アルゴリズムを拡張します。
^ 「撤回通知: ANS 承認日から少なくとも 10 年経過」(PDF)。ANSI規格アクション。第 39 巻、第 46 号。ANSI。2008年 11 月 14 日。5 ページ。ISSN 0038-9633。2017年 9 月 6 日のオリジナルからアーカイブ(PDF) 。2017年 9 月 5 日に取得。
^ 「FIPS PUB 46-3: データ暗号化規格 (DES)」(PDF)。米国商務省。1999年10月25日。2003年4月5日時点のオリジナルよりアーカイブ(PDF) 。2017年9月5日閲覧。
^ 「連邦情報処理標準 (FIPS) 46–3 の撤回承認の発表…」(PDF)。連邦官報。70 (96)。2005 年 5 月 19 日。2008 年 9 月 17日のオリジナルからアーカイブ(PDF) 。2017年 9 月 5 日に取得。
^ abc Barker, Elaine; Mouha, Nicky (2017 年 11 月). 「NIST Special Publication 800-67 Revision 2: トリプルデータ暗号化アルゴリズム (TDEA) ブロック暗号に関する推奨事項」(PDF) . NIST . doi : 10.6028/NIST.SP.800-67r2 . 2017 年 12 月 1 日のオリジナルからアーカイブ(PDF) . 2017 年 11 月 21 日取得。
^ NIST が特別刊行物 800-67 改訂 2 を撤回 https://csrc.nist.gov/news/2023/nist-to-withdraw-sp-800-67-rev-2
^ 「ISO/IEC 18033-3:2010 情報技術 - セキュリティ技術 - 暗号化アルゴリズム - パート3: ブロック暗号」。ISO。2010年12月。 2017年9月5日閲覧。
^ abcdef Barker, Elaine (2016 年 1 月). 「NIST Special Publication 800-57: 鍵管理に関する推奨事項パート 1: 一般事項」(PDF) (第 4 版). NIST . 2016 年 2 月 7 日のオリジナルからアーカイブ(PDF)されました。2017年 9 月 5 日に取得。
^ ab 「暗号化ガイド: トリプル DES」。Cryptography World。2017 年 3 月 12 日時点のオリジナルよりアーカイブ。2017 年 9 月 5 日閲覧。
^ Katz, Jonathan; Lindell, Yehuda (2015).現代暗号入門. Chapman and Hall/CRC . p. 223. ISBN 9781466570269。
^ NIST 特別刊行物 800-38A、ブロック暗号の動作モード、方法、および技術に関する推奨事項、2001 年版 (PDF)
^ 「ISO/IEC 10116:2006 情報技術 - セキュリティ技術 - n ビットブロック暗号の動作モード」（第 3 版）。2006 年 2 月。2017 年 9 月 5 日閲覧。
^ Merkle, Ralph ; Hellman, Martin (1981 年 7 月). 「多重暗号化のセキュリティについて」(PDF) . Communications of the ACM . 24 (7): 465–467. CiteSeerX 10.1.1.164.251 . doi :10.1145/358699.358718. S2CID 11583508. 2013 年 2 月 10 日のオリジナル(PDF)からアーカイブ。2013年 11 月 15 日に取得。
^ van Oorschot, Paul ; Wiener, Michael J. (1990). 2鍵3重暗号化に対する既知平文攻撃EUROCRYPT '90, LNCS 473. pp. 318–325. CiteSeerX 10.1.1.66.6575 .
^ 「TDEA の現在の使用と廃止に関する更新」nist.gov 2017 年 7 月 11 日。2019年8 月 2 日閲覧。
^ 「Sweet32: TLS および OpenVPN の 64 ビットブロック暗号に対する誕生日攻撃」。sweet32.info。2017年9 月 5 日閲覧。
^ Salz, Rich (2016-08-24). 「SWEET32 の問題、CVE-2016-2183」。OpenSSL。2024年10 月 11 日閲覧。
^ 「付録 B 承認済み暗号化アルゴリズム - B1.1 データ暗号化規格 (DES)」。EMV 4.2: Book 2 - セキュリティとキー管理(4.2 版)。EMVCo。2008年6 月。p. 137。2017 年 7 月 18 日にオリジナルからアーカイブ。2009 年 3 月 21 日に取得。倍長キーのトリプル DES 暗号化アルゴリズム (ISO/IEC 18033-3 を参照) は、付録 A1 で指定されている暗号化および MAC メカニズムで使用される承認済み暗号化アルゴリズムです。このアルゴリズムは、ISO 16609 で標準化された (シングル) DES アルゴリズムに基づいています。
^ Escapa, Daniel (2006-11-09). 「パスワード保護されたセクションの暗号化」。Daniel Escapa の OneNote ブログ。2009-12-16 にオリジナルからアーカイブ。2010-01-28に取得。
^ 「電子メールメッセージの暗号化 – Outlook – Microsoft Office Online」。office.microsoft.com。2008年12 月 25 日時点のオリジナルからのアーカイブ。適用対象: Microsoft Office Outlook 2007
^ Microsoft TechNet 製品ドキュメント、Configuration Manager で使用される暗号化コントロールのテクニカルリファレンス、2012 年 10 月。
^ 「管理ポータル」。portal.office.com 。 2023年3月14日閲覧。
^ Mozilla NSS ソースコード。背景情報については、ディレクトリ構造の説明 (特に導入セクションと「セキュリティ」セクション) を参照してください。

[1] Barker, Elaine; Roginsky, Allen (2019-03-01). 「暗号化アルゴリズムと鍵の長さの使用の移行」(PDF) . Gaithersburg, MD: NIST Publications. p. 7. doi :10.6028/nist.sp.800-131ar2. NIST SP 800-131A 改訂 2. 2019-05-11 にオリジナルからアーカイブ(PDF)されました。2022-09-20に取得。

[2] 「トリプル DES 暗号化」。IBM。2010年 5 月 17 日閲覧。

[3] アラナジ、ハムダン。 O。ザイダン、BB;ザイダン、AA;ジャラブ、ハミッド A.シャバー、M.アル・ナバニ、Y. (2010 年 3 月)。「9 つの要素内での DES、3DES、および AES 間の新しい比較研究」。コンピューティングジャーナル。2 (3)。arXiv : 1003.4085。Bibcode :2010arXiv1003.4085A。ISSN 2151-9617。

[4] 「Cisco PIX 515E セキュリティアプライアンススタートアップガイド: DES ライセンスまたは 3DES-AES ライセンスの取得」(PDF)。Cisco 。2006 年。2016 年2月 7 日にオリジナルからアーカイブ(PDF) 。2017年 9 月 5 日に取得。

[5] 「3DES アップデート: ほとんどの銀行は完了していますが...」ATM & Debit News。2007 年 3 月 29 日。2013 年 5 月 10 日時点のオリジナルよりアーカイブ。2017年 9 月 5 日に閲覧。

[6] RFC 2828 および RFC 4949

[7] Merkle, R. および M. Hellman、「多重暗号化のセキュリティについて」、Communications of the ACM、vol. 24、no. 7、pp. 465–467、1981 年 7 月。

[8] Karn, P.; Metzger, P.; Simpson, W. (1995 年 9 月). ESP トリプル DES 変換. doi : 10.17487/RFC1851 . RFC 1851.

[ANSIx952-9] 「ANSI X9.52-1998 トリプルデータ暗号化アルゴリズムの動作モード」。 2017年9月5日閲覧。ANSI X3.92-1981データ暗号化アルゴリズムを拡張します。

[10] 「撤回通知: ANS 承認日から少なくとも 10 年経過」(PDF)。ANSI規格アクション。第 39 巻、第 46 号。ANSI。2008年 11 月 14 日。5 ページ。ISSN 0038-9633。2017年 9 月 6 日のオリジナルからアーカイブ(PDF) 。2017年 9 月 5 日に取得。

[11] 「FIPS PUB 46-3: データ暗号化規格 (DES)」(PDF)。米国商務省。1999年10月25日。2003年4月5日時点のオリジナルよりアーカイブ(PDF) 。2017年9月5日閲覧。

[12] 「連邦情報処理標準 (FIPS) 46–3 の撤回承認の発表…」(PDF)。連邦官報。70 (96)。2005 年 5 月 19 日。2008 年 9 月 17日のオリジナルからアーカイブ(PDF) 。2017年 9 月 5 日に取得。

[NIST67r2-13] Barker, Elaine; Mouha, Nicky (2017 年 11 月). 「NIST Special Publication 800-67 Revision 2: トリプルデータ暗号化アルゴリズム (TDEA) ブロック暗号に関する推奨事項」(PDF) . NIST . doi : 10.6028/NIST.SP.800-67r2 . 2017 年 12 月 1 日のオリジナルからアーカイブ(PDF) . 2017 年 11 月 21 日取得。

[14] NIST が特別刊行物 800-67 改訂 2 を撤回 https://csrc.nist.gov/news/2023/nist-to-withdraw-sp-800-67-rev-2

[15] 「ISO/IEC 18033-3:2010 情報技術 - セキュリティ技術 - 暗号化アルゴリズム - パート3: ブロック暗号」。ISO。2010年12月。 2017年9月5日閲覧。

[NIST57r4-16] Barker, Elaine (2016 年 1 月). 「NIST Special Publication 800-57: 鍵管理に関する推奨事項パート 1: 一般事項」(PDF) (第 4 版). NIST . 2016 年 2 月 7 日のオリジナルからアーカイブ(PDF)されました。2017年 9 月 5 日に取得。

[cryptography_world-17] 「暗号化ガイド: トリプル DES」。Cryptography World。2017 年 3 月 12 日時点のオリジナルよりアーカイブ。2017 年 9 月 5 日閲覧。

[18] Katz, Jonathan; Lindell, Yehuda (2015).現代暗号入門. Chapman and Hall/CRC . p. 223. ISBN 9781466570269。

[19] NIST 特別刊行物 800-38A、ブロック暗号の動作モード、方法、および技術に関する推奨事項、2001 年版 (PDF)

[20] 「ISO/IEC 10116:2006 情報技術 - セキュリティ技術 - n ビットブロック暗号の動作モード」（第 3 版）。2006 年 2 月。2017 年 9 月 5 日閲覧。

[21] Merkle, Ralph ; Hellman, Martin (1981 年 7 月). 「多重暗号化のセキュリティについて」(PDF) . Communications of the ACM . 24 (7): 465–467. CiteSeerX 10.1.1.164.251 . doi :10.1145/358699.358718. S2CID 11583508. 2013 年 2 月 10 日のオリジナル(PDF)からアーカイブ。2013年 11 月 15 日に取得。

[22] van Oorschot, Paul ; Wiener, Michael J. (1990). 2鍵3重暗号化に対する既知平文攻撃EUROCRYPT '90, LNCS 473. pp. 318–325. CiteSeerX 10.1.1.66.6575 .

[tdea-deprecation-23] 「TDEA の現在の使用と廃止に関する更新」nist.gov 2017 年 7 月 11 日。2019年8 月 2 日閲覧。

[24] 「Sweet32: TLS および OpenVPN の 64 ビットブロック暗号に対する誕生日攻撃」。sweet32.info。2017年9 月 5 日閲覧。

[25] Salz, Rich (2016-08-24). 「SWEET32 の問題、CVE-2016-2183」。OpenSSL。2024年10 月 11 日閲覧。

[26] 「付録 B 承認済み暗号化アルゴリズム - B1.1 データ暗号化規格 (DES)」。EMV 4.2: Book 2 - セキュリティとキー管理(4.2 版)。EMVCo。2008年6 月。p. 137。2017 年 7 月 18 日にオリジナルからアーカイブ。2009 年 3 月 21 日に取得。倍長キーのトリプル DES 暗号化アルゴリズム (ISO/IEC 18033-3 を参照) は、付録 A1 で指定されている暗号化および MAC メカニズムで使用される承認済み暗号化アルゴリズムです。このアルゴリズムは、ISO 16609 で標準化された (シングル) DES アルゴリズムに基づいています。

[27] Escapa, Daniel (2006-11-09). 「パスワード保護されたセクションの暗号化」。Daniel Escapa の OneNote ブログ。2009-12-16 にオリジナルからアーカイブ。2010-01-28に取得。

[28] 「電子メールメッセージの暗号化 – Outlook – Microsoft Office Online」。office.microsoft.com。2008年12 月 25 日時点のオリジナルからのアーカイブ。適用対象: Microsoft Office Outlook 2007

[29] Microsoft TechNet 製品ドキュメント、Configuration Manager で使用される暗号化コントロールのテクニカルリファレンス、2012 年 10 月。

[30] 「管理ポータル」。portal.office.com 。 2023年3月14日閲覧。

[31] Mozilla NSS ソースコード。背景情報については、ディレクトリ構造の説明 (特に導入セクションと「セキュリティ」セクション) を参照してください。