  |
はてなキーワード: RSA暗号とは
この程度でも600万は稼げるという夢を持つか、こんなのでもちょっと何かが違うだけで600万稼げるか否かが分かれてしまう業界に闇を感じるか、600万程度で何ドヤってるの？と思うかはご自由にどうぞ（外資系ってもっと稼げるの？）。
歳は30台前半。学部卒。BtoB向けのパッケージ製品の開発プロジェクトで、設計、コーディング、テストあたりを担当している。仕様について発注元との折衝もやっている。
業務で使う技術のうち、自分自身がそれなりに習得しているものだけを書く。プライベートでしか習得・使用していない技術は別。
以上。
PythonもgitもDockerもkubernetesもAnsibleもCIツールもAWSもGCPもRuby on Railsも知らなくてもなんとかなってしまっている。業務でこれらのスキルを要求されることは（今のところは）ないから。
楽でいいと思う一方、このままだと将来ヤバいとも思っている。いざ転職となったときに詰みそう。
でもいざとなったらググっていくらでも独学できるだろうとたかをくくっているので焦ってはいない。
というか「その他」のところに書いた能力が高ければ世の中大体はなんとかなるんじゃないの。知らんけど。
ちなみに自分は構築できないというだけで、プロジェクトではJenkinsとかgradleとかbabelだかwebpackだかでビルド環境は整えられている。
あとプライベートで、単純な仕様の独自言語のコンパイラフロントエンドをC++とLLVMで作っている（これで金が稼げるとは微塵も思っておらず、完全にただの趣味）。
例のAppleのSSL/TLSのバグの件、日本語情報がなかったので意訳しました。
Adam Langleyさんによって書かれた原文はこちら。要所要所に親切なリンクがついているので、ぜひ原文も見てみてください。
Apple's SSL/TLS bug (22 Feb 2014)
https://www.imperialviolet.org/2014/02/22/applebug.html
(Hi Adam Langley, Than you for your blog! We really appreciate you.)
-----
昨日、AppleはばかばかしいiOS向けのセキュリティアップデートを発行した。 それは詳しく明かされていないが、SSL/TSLについてとんでもなく恐ろしい間違いを示すものだった。 その答えは既にハッカーニュースのトップにタレこまれている(https://news.ycombinator.com/item?id=7281378)し、アップルが隠したい秘密はもうバレてしまっていると思う。 そして現在、俺たちはその誤った情報を正すステージに来ているんだ。 ほらここに、Appleのbugがあるんだ。：
static OSStatus SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams, uint8_t *signature, UInt16 signatureLen) { OSStatus err; ... if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail; ... fail: SSLFreeBuffer(&signedHashes); SSLFreeBuffer(&hashCtx); return err; }(Quoted from Apple's published source code.)
(訳者注：(Quoted from Apple's published source code)→sslKeyExchange.c) 2行のgotoがあるだろ。 2行目のgotoは、見て分かる通り常に発動する。 変数[err]にはエラーを示す値が入らず、正常を示す値のままfailに飛ぶってことだ。 それって成功したのと同じなんだよね！ この署名検証処理は(訳者注：SSL/TLSハンドシェイクのやりとりのうちの一つである)ServerKeyExchangeメッセージの署名を検証するものだ。 このServerKeyExchangeでは、"the ephemeral key"（通信のための一時的な鍵）を交換するためのDHE や ECDHE という暗号スイートが使われる。 そのサーバーは言うんだ。 「ここに"the ephemeral key"と署名があるよ、ほら、これが証明書だ。君はこれが僕からのものだってわかってくれるよね！」 今、もし"the ephemeral key"と証明書の関係が破たんしているならば、すべては無意味なんだ。 これってつまり、正規の証明書チェーンをクライアントに送信したけど、ハンドシェイクへの署名には正しくない間違った（つまり適当にその辺で作った）鍵を使ったり、そもそもハンドシェイクに署名しなかったりってことができるってことなんだよ！ そこには、今君が通信しているサーバーが、サーバー証明書に含まれる公開鍵の秘密鍵を持っているってことの証明が、何もないんだ。 これはSecureTransport(というライブラリ)に入っていて、以下に影響する。 ・iOS 7.0.6より前(俺は7.0.4で確認した) ・OS X 10.9.2より前(10.9.1で確認した) (訳者注：つまりiOS 7.0.6、OS X 10.9.2で解決した) これはSecureTransportを使っているすべてに影響するけど、ChromeとFirefoxはそうじゃない。 ChromeとFirefoxはSSL/TLSのためにNSSを使っている。 でも、それはあんまり君のマシンがSecureTransportを使っていないってことを意味しないよ。(ソフトって更新されるしね) 超特急でテストサイトを作ってみたよ。https://www.imperialviolet.org:1266 ポート番号に気を付けてね。(テストサイトはCVE番号になってるよ) 443は通常通りに動いているからね。 ポート1266のサーバーと443のサーバーは同じ証明書を送っているけど、完全に異なるキーで署名しているんだ。 君がもしポート1266のHTTPSサイトにアクセスできたんだったら、君のマシンはこのイケてるバグを抱えてるってことだね。:) それってつまり、証明書チェーンは正しいってことで、そしてハンドシェイクと証明書チェーンの関係は壊れたってことで、もう俺はどんな証明書も信じないよ。 またこれは、DHE または ECDHE 暗号スイートを使っているサイトに影響を及ぼすだけじゃないんだ。 攻撃者は、この暗号スイートを使うサーバーを自分で建てるようになるだろう。 また、これはTLS 1.2には影響しない。このバグを含まないTLS 1.2の別の関数があったから。 でも攻撃者は使うプロトコルをある程度選ぶことができるから、安心できないよ。 (訳者注：サーバー側がTLS1.2を使えないことにしていたら、それ以外の例えばSSL3.0とかTLS1.0とか1.1で通信が始まっちゃうから。) でもでも、クライアント側でTLS1.2だけを使えるようにしておけば、それは今回の問題の回避策になる。。 同じく、クライアント側でRSA暗号スイートだけを許可するということも、ServerKeyExchangeが発生しなくなるので今回の問題の回避策になる。 (2つのうち、1つ目のほうがだいぶ好ましい。) 俺のテストサイトでは、iOS 7.0.6 と OS X 10.9.2で問題は解決していた。 (更新：このバグはOS X 10.9 のときに入ったように見えたけど、iOS6にもっあったぽい。iOS 6.1.6は昨日リリースされたよ。) こんなような微妙なバグって、悪夢だ。 俺はこれは単なるミスだと思うし、なんかもうほんと最悪って思う。 ここに、今回の問題を明らかにするコードがある。：
extern int f(); int g() { int ret = 1; goto out; ret = f(); out: return ret; }
もし俺が"-Wall "を付けてコンパイルしたとしても、XcodeのGCC 4.8.2 や Clang 3.3は死んでるコード(the dead code)について警告をしないんだ。 本当にビックリだよ！！！ ここで警告が出ていたらこの問題は止められたのに。でもたぶん、現実には死んでるコードが多すぎて無視することにしてるんだろうね。 (ピーター・ネルソンが教えてくれたけど、Clangはこれを警告するための"-Wunreachable-code"を持ってる。でもこれ、なんと"-Wall "には含まれてない！) if文に{}をつけないことを許すコーディングスタイルはこの問題を誘発したかもしれない。 でも、人は{}を付けたとしても間違ったプログラムを書くことがあるから、これは俺はあんまり関係ないように思う。 テストケースはこれを見つけることができたはずだけど、今回のはいろいろ条件が複雑なやつだったから難しかったと思う。 TLSのめちゃめちゃ多くのオプションを試さなきゃいけなかったからね。しかも正常系じゃないやつも。 俺、TLSLiteでちゃんとテストしてるか思い出せないもん。(月曜日怖いかも) コードレビューはこの種類のバグについて効果的でありえる。 ただし単なる審査じゃなく、それぞれの変更に対してしっかりとレビューすることだ。 Appleのコードレビューカルチャーがどんなもんか知らないけど、もし俺が同じようなことをやっちゃったとしたら、同僚のWan-Teh や Ryan Sleevi がばっちり見つけてくれたと、固く信じてる。 でも、誰もがそんなにいい仲間を持てるわけじゃないよね。 最後に。昨日、Appleが証明書のホスト名をちゃんとチェックしていなかったことについて多くの議論があったんだけど、 それは OS X のコマンドラインでcurlを使うと、IPじゃない証明書でもIPでHTTPSにつながっちゃうってだけだったよ。変だけど。 Safariはこの問題には関係なかったよ。
サマーウォーズの鑑賞中、セキュリティ描写が気になって映画を半分（主にカズマパート）しか楽しめなかった。
その後、はたしてどのような描写であれば納得感を得られたのかと妄想していたら、妙な答えに行き着いた。
http://d.hatena.ne.jp/LM-7/20090831/1251727185
ここにあるように、もしあの2056桁の数列がRSA暗号における鍵であるとして、健二が素因数分解により平文（おそらくアバターの操作や仮想建物への入室のためのパスワード）の復号をマトモに暗算で行っているということは考えにくい。そこには何らかのショートカットが存在するはず。おそらく、OZの暗号鍵生成アルゴリズムに実装上のバグがあり、何らかの推察（法nに規則性、乱数が甘いとか）を許してしまうような物だろう。これは、おそらくOZの技術者の中では既知のもので、対応中のものだったのではないだろうか。そう、だいたい55人くらいにはそのショートカット法を知られていたくらいには。
ここで思い出してほしいのは、健二はOZのメンテナンスのアルバイトをしていたということ。
メンテナンスのため管理棟（だっけ？）と言われる領域へログインし、何か作業を行っている様子が見られる。どんな作業かは分からないが、物理部の彼らのこと、そうした暗号への興味もあるだろうし、知ってしまっていたとしてもおかしくはない。（こんな危険なバグの対応をバイトの学生に任せるなんてありえないが、あるいはバイトとはこの問題への対応のためのテストであり、その過程で知ってしまったのかもしれない。）
だが、ラブマシーンの描写を見ると、できることはアバターを乗っ取ることだけで、OZの基幹系システムそのものを乗っ取ったわけではない。あくまでアバターの可能な範囲での権限の行使に限られていて、たとえば花札のルールに介入したり、配られる札を操作したりするようなことはできない。
ラブマシーンが米軍によりOZに放たれたとき、彼にできることは相当限られていたはず。
彼が暴れるためには、多くのユーザの秘密鍵の管理を行う管理棟へ入れるアバターを乗っ取ることが必要だった。
ラブマシーンは何かのきっかけで上記の脆弱性を知り、OZ管理者に近いアバターの鍵をなぜか知り、その解を解けそうな人物へ送付する。メールでその鍵の復号を知る。
それを手がかりに秘密鍵へのアクセスを可能にし、あとは選択平文攻撃によってアバターを次々に乗っ取っていく。でも、最初の一歩、管理棟への出入りのための鍵はどこから？
その、最初の鍵は、どうやって手に入れたんだろう？
ここで、一人の傷心の人物が浮かび上がる。
OZでバイトしていた、物理に興味のある、あまり目立たなかった人物。
彼は暗号を自力で解くほど数学の才に恵まれていたわけではなかったが、秘密鍵のありかと、脆弱性があることは知っていた。
じゃん拳に負け、東京に一人残った彼。
傷心の彼はその日、管理塔のまわりをうろつくラブマシーンに気がついた。何でも知ろうとし何でも吸収しようとするbot。
本当は、知識を吸収して報告するだけの何も権限のないbot。
そう、佐久間敬君、きみ、あれに何か渡さなかったかい？その見返りとして健二のアバターを使うように申し出たり？
暴走したラブマシーンとは、あれは君？
昔、妖精現実のトップにあった記事。探しても見つからないや。
「水からの伝言」…水は否定的な言葉を見せたときと肯定的な言葉を見せたときで異なる結晶を作る。
（念のために言うが、↑は科学的事実ではない。しかしネタとして、あえて） これが成り立つ世界を考える。ただし、次の公準も仮定する。
考古学的応用: 水は世界中の言語を理解できるので、 未解読文字の解読に役立つ。 少なくとも、お礼を言っているのか、宣戦布告の文章か、といった程度の判別はつく。 「正しい解読結果をアルファベットで表記したとき1文字目は大文字小文字を区別せずにAである」「…Bである」…と書いてある30枚弱の紙を水に見せて、どれが肯定的かを判断することを、結果の文字列長（この整数値も水に問い合わせることができる）だけ繰り返せば、あらゆる謎の古文書が解読できる。 水さん、ありがとう。
問1: 解読結果が1万文字以内であることは分かっている文がある。 解読結果の文字列長を表す整数値を必ず確定させるのに必要な最小の「水への問い合わせ回数」はいくつか。
問2: 現在は不治の病であるXについて、それを根治する薬品があると仮定する。 その有効成分をIUPAC等の標準的な化合物命名法で記述して1万文字以内であると仮定せよ。 以上によって、水が肯定否定を判断できるなら、難病のいくつかが克服できることを説明せよ。
問3: 水に問い合わせられるときP=NP問題は肯定的に解決されるか。
軍事的応用1: ゆえにRSA暗号、楕円曲線暗号、その他、いかなる未知の暗号であっても、ダイレクトに高速にクラックできる。 上記同様、解読結果のどれが肯定的か1文字ずつ判断させるだけで良い。量子通信・量子暗号さえ解読できてしまうだろう。
軍事的応用2: さらに、暗号に限らず、情報一般に応用できるから、チャフによる妨害や、敵の欺まん電波を見破るように水を結晶させる装置を弾頭に装着することで、電子妨害を受けない強力な兵器を構築できる。
こういうの、大好きだ。
