RC4

出典: フリー百科事典『ウィキペディア(Wikipedia)』
移動: 案内検索
RC4
一般
設計者 ロナルド・リベスト
初版発行日 1994年に漏洩(1987年に設計)
暗号詳細
鍵長 40–2,048 bits
状態長 2,064 bits (1,684 effective)
ラウンド数 256
速度 7 cycles per byte on Pentium[1]

RC4(あるいはARCFOUR)とは、SSLWEPなどで広く使われているストリーム暗号である。

概要[編集]

RC4はロナルド・リベストにより1987年に開発されたストリーム暗号であり、このアルゴリズムで発生させた疑似乱数列と平文との排他的論理和が暗号文となる。RC4はWEPのように利用方法によっては安全性を保てない。RC4はWEP、WPAMPPE (Microsoft Point to Point Ecryption)、WinnyTLS/SSL(オプション)、SSH(オプション)で暗号化をするのに使われている。

2013年現在では、NSAのような機関であればTLS/SSLを利用したとしてもRC4を解読可能であるとの疑惑があり[2]MicrosoftではRC4を無効化することを推奨している[3][4][5]

歴史[編集]

RC4は、1987年にRSAセキュリティ社でロナルド・リベストによって開発された。公式には "Rivest Cipher 4" と呼ばれるが、"Ron's Code" の略語とされることもある。参照:RC2RC5RC6

RC4は当初は営業秘密 (trade secret) であった。ところが1994年9月に何者かが匿名CypherpunksメーリングリストにRC4の解説を流してしまった。この解説は直ぐにニューズグループ sci.crypt にポストされて、インターネットに広がった。アルゴリズムが公知になったので、RC4は営業秘密ではなくなったが、"RC4" の名称は商標である。従って、RC4と称さずに非公式に実装するのは合法であるようだが、RC4の名称を使うことはできない。それで、RC4はしばしば、商標問題を回避するために "ARCFOUR"(Alleged-RC4, なぜならば、RSA社は公式にはアルゴリズムをリリースしていないから)という名前が使用されることがある。

そして "ARCFOUR" は、無線通信のためのWEPWPA、あるいはTLSなどの良く使用されている暗号化プロトコルとその標準の一部となった。

安全性[編集]

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]

関連項目[編集]

脚注[編集]

  1. ^ P. Prasithsangaree and P. Krishnamurthy (2003). Analysis of Energy Consumption of RC4 and AES Algorithms in Wireless LANs. http://www.sis.pitt.edu/~is3966/group5_paper2.pdf. 
  2. ^ John Leyden (2013年9月6日). “That earth-shattering NSA crypto-cracking: Have spooks smashed RC4?”. The Register. 2013年12月4日閲覧。
  3. ^ Security Advisory 2868725: Recommendation to disable RC4”. Microsoft (2013年11月12日). 2013年12月4日閲覧。
  4. ^ マイクロソフト セキュリティ アドバイザリ 2868725 - RC4 を無効化するための更新プログラム”. Microsoft (2013年11月13日). 2014年10月10日閲覧。
  5. ^ draft-ietf-tls-prohibiting-rc4-01 - Prohibiting RC4 Cipher Suites” (2014年10月1日). 2014年10月8日閲覧。
  6. ^ security – Safest ciphers to use with the BEAST? (TLS 1.0 exploit) I've read that RC4 is immune – Server Fault
  7. ^ ivanr. “RC4 in TLS is Broken: Now What?”. Qualsys Security Labs. 2013年7月30日閲覧。
  8. ^ 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. http://link.springer.com/chapter/10.1007%2F978-3-642-19574-7_5. 
  9. ^ Green, Matthew. “Attack of the week: RC4 is kind of broken in TLS”. Cryptography Engineering. 2014年6月24日閲覧。
  10. ^ 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日閲覧。
  11. ^ 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. http://www.isg.rhul.ac.uk/tls/RC4biases.pdf 2014年6月24日閲覧。. 
  12. ^ 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. https://www.usenix.org/sites/default/files/conference/protected-files/alfardan_sec13_slides.pdf 2014年6月24日閲覧. "Plaintext recovery attacks against RC4 in TLS are feasible although not truly practical" 

外部リンク[編集]