アール‐シー‐フォー【RC4】
RC4
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2021/08/22 15:15 UTC 版)
ナビゲーションに移動 検索に移動一般 | |
---|---|
設計者 | ロナルド・リベスト |
初版発行日 | 1994年に漏洩(1987年に設計) |
暗号詳細 | |
鍵長 | 40–2048 bits |
状態長 | 2064 bits (1684 effective) |
ラウンド数 | 256 |
速度 | 7 cycles per byte on Pentium[1] |
RC4(あるいはARCFOUR)とは、SSLやWEPなどで広く使われているストリーム暗号である。
概要
RC4はロナルド・リベストにより1987年に開発されたストリーム暗号であり、このアルゴリズムを用いて発生させた疑似乱数列と平文の排他的論理和をとったものが暗号文になる。RC4は利用方法によってはWEPのように安全性が保てないことがある。RC4はWEP、WPA、MPPE (Microsoft Point to Point Ecryption)、Winny、TLS/SSL(オプション)、SSH(オプション)で暗号化を行うために用いられている。
2015年の時点において、NSAのような機関であればTLS/SSLを利用していてもRC4を解読できる疑いがあり[2]、マイクロソフトではRC4を使わないようにすることを推奨している[3][4][5]。2015年2月には TLSのすべてのバージョンにおいてRC4の利用を禁止する提議 RFC 7465 が公開された。
歴史
RC4は、1987年にRSAセキュリティ社でロナルド・リベストによって開発された。公式には "Rivest Cipher 4" と呼ばれるが、"Ron's Code" の略語とされることもある。参照:RC2、RC5、RC6。
RC4は当初は企業秘密 (trade secret) であった。ところが1994年9月に何者かが匿名でCypherpunksのメーリングリストにRC4の解説を流してしまった。この解説は直ぐにニューズグループ sci.crypt にポストされて、インターネットに広がった。アルゴリズムが公知になったので、RC4は企業秘密ではなくなったが、"RC4" の名称は商標である。従って、RC4と称さずに非公式に実装するのは合法であるようだが[独自研究?]、商標であるRC4の名称を使うことはできない。それで、RC4はしばしば、商標問題を回避するために "ARCFOUR"(Alleged-RC4, なぜならば、RSA社は公式にはアルゴリズムを公開していないので)という名前が使用されることがある。
そして "ARCFOUR" は、無線通信のためのWEPやWPA、あるいはTLSやWinnyなどの広く使用されている暗号化プロトコルとその標準の一部となった。
安全性
TLS/SSLにおいてRC4を用いたCipher Suiteについては、その脆弱性に対処されており安全であると考えられていた。2011年には、ブロック暗号のCBCモードの取り扱いに関する脆弱性であったBEAST攻撃への対応策の一つとして、その影響を受けないストリーム暗号であるRC4に切り替えることが推奨されていた[6]。しかし、2013年にTLS/SSLでのRC4への効果的な攻撃法が報告され、BEASTへの対策としてRC4を用いることは好ましくないとされた[7]。RC4に対する攻撃法は、AlFardan、Bernstein、Paterson、Poettering、Schuldtによって報告された。新たに発見されたRC4の鍵テーブルにおける統計的な偏り[8]を利用することで、平文の一部が回復可能であるというものである[9][10]。この攻撃法により、13 × 220通の暗号文を用いれば128ビットのRC4が解読可能であることが示され、2013年のUSENIXセキュリティシンポジウムにおいて「実現可能である」と評された[11][12]。
関連項目
脚注
- ^ P. Prasithsangaree and P. Krishnamurthy (2003). Analysis of Energy Consumption of RC4 and AES Algorithms in Wireless LANs .
- ^ John Leyden (2013年9月6日). “That earth-shattering NSA crypto-cracking: Have spooks smashed RC4?”. The Register. 2013年12月4日閲覧。
- ^ “Security Advisory 2868725: Recommendation to disable RC4”. Microsoft (2013年11月12日). 2013年12月4日閲覧。
- ^ “マイクロソフト セキュリティ アドバイザリ 2868725 - RC4 を使用禁止にするための更新プログラム”. Microsoft (2013年11月13日). 2014年10月10日閲覧。
- ^ “draft-ietf-tls-prohibiting-rc4-01 - Prohibiting RC4 Cipher Suites” (2014年10月1日). 2014年10月8日閲覧。
- ^ security – Safest ciphers to use with the BEAST? (TLS 1.0 exploit) I've read that RC4 is immune – Server Fault
- ^ ivanr. “RC4 in TLS is Broken: Now What?”. Qualsys Security Labs. 2013年7月30日閲覧。
- ^ Pouyan Sepehrdad, Serge Vaudenay, Martin Vuagnoux (2011). “Discovery and Exploitation of New Biases in RC4”. Lecture Notes in Computer Science 6544: 74–91. doi:10.1007/978-3-642-19574-7_5 .
- ^ Green, Matthew. “Attack of the week: RC4 is kind of broken in TLS”. Cryptography Engineering. 2014年6月24日閲覧。
- ^ Nadhem AlFardan, Dan Bernstein, Kenny Paterson, Bertram Poettering and Jacob Schuldt. “On the Security of RC4 in TLS”. Royal Holloway University of London. 2014年6月24日閲覧。
- ^ AlFardan, Nadhem J.; Bernstein, Daniel J.; Paterson, Kenneth G.; Poettering, Bertram; Schuldt, Jacob C. N. (8 July 2013) (PDF). On the Security of RC4 in TLS and WPA 2014年6月24日閲覧。.
- ^ AlFardan, Nadhem J.; Bernstein, Daniel J.; Paterson, Kenneth G.; Poettering, Bertram; Schuldt, Jacob C. N. (15 August 2013). “On the Security of RC4 in TLS” (PDF). 22nd USENIX Security Symposium. p. 51 2014年6月24日閲覧. "Plaintext recovery attacks against RC4 in TLS are feasible although not truly practical"
外部リンク
- IETF draft - A Stream Cipher Encryption Algorithm "Arcfour"
- RFC 4345 - Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol
- RFC 6229 - Test Vectors for the Stream Cipher RC4
- RFC 7465 - Prohibiting RC4 Cipher Suites
- SCAN's entry for RC4
- Attacks on RC4
- RC4 - Cryptology Pointers by Helger Lipmaa
- RSA Security Response to Weaknesses in Key Scheduling Algorithm of RC4
- 五十部孝典:「RC4の脆弱性とSSL/TLSへの攻撃」、2014年2月13日、NICT情報セキュリティシンポジウム(発表スライド)
RC4
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2022/05/09 06:55 UTC 版)
「Transport Layer Security」の記事における「RC4」の解説
RC4もTLSのすべてのバージョンにおいて利用を禁止するRFC 7465が公開された。MozillaおよびマイクロソフトではRC4を無効化することを推奨している。 RC4そのものに対する攻撃法は多く報告されているが、TLS/SSLにおいてRC4を用いたCipher Suiteについては、その脆弱性に対処されており安全であると考えられていた。2011年には、ブロック暗号のCBCモードの取り扱いに関する脆弱性であったBEAST攻撃への対応策の一つとして、ストリーム暗号であるためその影響を受けないRC4に切り替えることが推奨されていた。しかし、2013年にTLS/SSLでのRC4への効果的な攻撃が報告され、BEASTへの対応としてRC4を用いることは好ましくないとされた。RC4に対する攻撃は、AlFardan、Bernstein、Paterson、Poettering、Schuldtによって報告された。新たに発見されたRC4の鍵テーブルにおける統計的な偏りを利用し、平文の一部を回復可能であるというものである。この攻撃では、13 × 220の暗号文を用いることで128ビットのRC4が解読可能であることが示され、2013年のUSENIXセキュリティシンポジウムにおいて「実現可能」と評された。2013年現在では、NSAのような機関であればTLS/SSLを利用したとしてもRC4を解読可能であるとの疑惑がある。 2015年現在ではクライアントのほとんどは既にBEASTへの対処が完了していることから、RC4はもはや最良の選択肢ではなくなっており、TLS 1.0以前においてもCBCモードを用いることがより良い選択肢となっている。
※この「RC4」の解説は、「Transport Layer Security」の解説の一部です。
「RC4」を含む「Transport Layer Security」の記事については、「Transport Layer Security」の概要を参照ください。
- RC4のページへのリンク