「RSA」を含む日記 RSS

はてなキーワード: RSAとは

2024-03-09

anond:20240309075252

世界最大の素数は、RSA社の金庫にしまわれている(たぶん嘘)。

2023-09-27

SSL/TLSの鍵交換にRSAは使われない」「電子署名=秘密鍵暗号化は間違い」

こんなしょーもないことを何年も言い続けてる病人、ヤバくね?

2022-10-14

anond:20221014012607

IMFが一昨日発表してます

ご参照ください

IMF Growth Forecast: 2023

USA🇺🇸: 1%

Germany🇩🇪: -0.3%

France🇫🇷: 0.7%

Italy🇮🇹: -0.2%

Spain🇪🇸: 1.2%

Japan🇯🇵: 1.6%

UK🇬🇧: 0.3%

Canada🇨🇦: 1.5%

China🇨🇳: 4.4%

India🇮🇳: 6.1%

Russia🇷🇺: -2.3%

Brazil🇧🇷: 1%

Mexico🇲🇽: 1.2%

KSA🇸🇦: 3.7%

Nigeria🇳🇬: 3%

RSA🇿🇦: 1.1%

http://IMF.org/WEO-oct22 #WEO

2021-07-18

anond:20210718103715

たとえば、RSA暗号理論計算機の有限時間内の演算が難しいという特性を使っているわけじゃん。つまり暗号化されたものは確実に復号できるという特性を持ち、かつ有限時間以内に割り切れる可能性がほぼ無い」という特性を持つことは数学的にも正しく、計算機科学でも成り立つ事実じゃん。SHA-1ハッシュ暗号として脆弱なのは、異なるファイルで同じハッシュ値を作れることが PoC されたことであって、数学的に脆弱性が解読されたわけじゃないだろ?もし、数学的にこの脆弱性がわかっていたら、もっと早い段階でハッシュの衝突が起きていたと思うのだが、違うのかい?一応は SHA-1 で衝突が起こることは数学的に予期されていたが、これだけハッシュ破りに時間がかかったのだから有用性はあったとはおもうけどね。

2021-02-14

インストリー5章の感想とそのほか

はてぶ匿名初めてなのではてな記法使えません。

ディアソムニア箱推しです。

大前提として、ディズニー映画知識ウェブであらすじ見ましたくらいしかありません。ツイステの元ネタ原作の方読んでたし映画はわざわざ見なくていいかなって……実写のマレフィセントは見ました。

ドルジャミルの贔屓も意見を目にするまでちらっとも思ってませんでした。意見を見ても「まあリドルくんはマブダチの寮長だから我々のお母さんポジだもんな……」とか考えてました。シェフまでは。ジャミルに関しては意識もしてませんでした。後編2までは。

5章で気になった点を、読みやすさとか考えずに書いていきます。ても更新遅すぎて気になったところあんまり覚えてません。長いので読み返す気もあんまりわかないです。あとキャラディスが入ると思います。ごめんなさい。

【前半:エペルに話してたヴィルさんの自論超腹立った】

ここのシーンあまりにも嫌いなので記憶から消し去ってるんですけど、

エペルは強い男らしい筋肉がなりたい自分の姿で、それとは真反対である愛らしいしぐさに嫌悪感を抱いているような描写があったと思います。それに対してヴィルさんは、男らしいだなんて前時代的な考え!みたいな感じのことを言ってましたよね。そしてここがTwitterで絶賛されてたと思います

私はここの部分ピンポイントで嫌いです。いや確かに好きな服を着て振る舞うはいいかもしれないし、そういう感じで絶賛されてましたけど、それ嫌がってる人にお前の考えは古い!!!って言って強要してるの地獄でしょ。少なくとも私は嫌です。

ていうかエペルには外見に似合う可愛さを要求しておきながら自分は悪役の仕事断るやん!相手ネージュくんだったからなのかもしれんけど!なに!?自分発言覚えられへんのか……!? エペルにあんなこと言うんなら受けろやその仕事……(この時点ではこういう矛盾意図的に配置してオーバーロッド伏線にするんだろうな〜と考えていました)

【後編:最終章にむけた準備を進めてるのはわかるけどユニーク魔法なんとかならんかったん?】

呪いジュースは詳しい人が言ってるし割愛します。多分これTwitterで「カリムの特技が毒の判定だからヴィルの仕込んだ毒をカリムが見つけるんだ!」ってめっちゃ言われてたか公式がそういう展開避けたんじゃないですか?知らんけど。1つ言うなら、殺意を隠せてない暗殺ちょっとずさんすぎる……です。 ちなみにここが原作映画踏襲!とかも知りません。私の知ってる狩人は「可愛い子に命乞いされたわ〜まあここで殺さなくてもこんな所で生きられんし女王命令は達成できるしな!逃がしたろ!」ってイノシシの肝持って帰った人です。詳しい人教えてください。

簡単に言うと、ポムフィオーレ寮の話なのにユニーク魔法判明したポムフィオーレ生がヴィルさんのヤツだけなのはおかしい、です。1年生の元田舎ヤンキーエペルが持ってないのはともかく、ルークユニーク魔法は匂わせもないやん。正確に狙った位置に何かを投げるってマレウス様もできますユニーク魔法ではないし。もしかして目分量で身体測定できるやつがそうですか?そんなこと言われたら泣くが……?

あとポムモブ生でなさすぎて悲しい。2章の方がでてたやん、バトルもしたし。もしかしてポムメイン章は2章だった……??

【後編:見せ場全部マレウス様が持ってったじゃん…………】

ディアソムニアオタクなので、唐突に出てくるマレウス様とかシルバくんとかしか見えてないんですけど、それでもあの時のマレウス様の登場はおかしかったと思います。どこの世界にその章の主役たちより目立ってるその後のメインする人がおんねん。ツイステッドワンダーランドにいます。まあマレウス様は強いから……で済ませられるほど穏やかなオタクでは無いです……。

あとヴィルさんのオーバーロッドを知ってる人数が少なすぎる。少なくとも今まで各寮生は目の当たりにしてたのに今回ぶっちぎりで少ない。モブ生の存在覚えてます

【後編:ジャミルソロパートいきなり何?】

これを言ってる人すごく多いので私の簡単感想のみ書きます

練習の時に、

ヴィル「オーディションの時にダンスが1番上手かったのアンタだからソロパート入れるけどいいわね?」

ジャミル「わかった」

くらいのやり取り入れろよ……なんで「あ〜ジャミルダンスが得意だから、映えるしソロパート入れたんかな〜」ってこっちが察さなきゃいけないんだよ。推理小説か? 推理小説でもこんなことしませんが?

まあ単純にリズミック班との連携不足ですよね。絶対報告足りてないわ。でもソシャゲスケジュールギリギリになりがちなので(メンテ中に実装するやつ頑張って作ってるとかある)最終チェックする時間なかったんだと思います

【後半:なんで出場者が投票権持ってんの?】

そもそもあれってVDCの出場者に投票権が無ければ良かったんですよ。

わかってる範囲でNRCの出場者は『ヴィル、エペル、ルークカリム、ジャミルエースデュース』の7人で、RSAの出場者って『ネージュと7人のドワーフ』で8人じゃないですか。もう出場者の人数差で公平ではないですよね。まあたかが1票差ですけど……いやすみません1票差でナイトレイブンカレッジ負けたんでした。

あと個人的ネージュくんはNRCに投票して欲しかったな……ほら……ネージュくん、「ヴィーくんたちのすごかったから、僕NRCに投票したんだ!」くらい言いそうじゃないですか……?そうしたらヘイトも下がったと思いません……?

世界規模の大会に見えなかったなあの意見は私もそう思います。合同文化祭

【後編:ヤッホー斉唱なに?】

そこは校歌でしょ(日本人感想

NRC側にヤッホー歌うことを提案してくるなら、ネージュくん側もNRCの曲歌って欲しかったですね。ちょっとネージュくんに高望みしすぎたかな……まあみんな高校生だし仕方ないかな…………

これに関しても既に散々言われてるのでこれ以上は言いません。

まあミュートでツイステやってるのでみんなが何を歌ってたのかTwitter見るまで知らなかったんですよね。困った時は脳内蛍の光を流しておけの精神に基づき当時私の中では全員蛍の光歌ってました。

推したちに盲目自分でも、結構違和感のあるシナリオだったなと思います。前半が多少読み応えあっただけに残念です。

ルーク壁紙の裏って獲物の隠し撮りだと思ってたけどつまりあれってネージュくんのブロマイドなんですよね。ネージュくん要素、ちょっとでもあればな……こんなことにはならんかったやろうなあ……

レウス様がマニア気質があるので正直7章怖いです。今回の不満点って推しではないから、冷静に見れてたとは思うんですが、7章で同じようなことされたらブチギレると思いますすみません既にマスターシェフと茨の信奉者の件でキレてます

お目汚し失礼いたしました。

2021-01-26

ツイステ5章でヴィランが勝てなかった話

ツイステ5章後編2配信されましたね。

ライターのせいでルークネージュヘイトサンドバッグになってるのが辛い。

あの展開ならサンドバッグになるのが当たり前で擁護ができなくて辛い。

これはこの二人が悪いんじゃなくて展開が悪い、ネージュに対してはライターからの悪意すら感じる。

ヴィランヒーローを打ち倒すと言うのはやっちゃいけないというこの世界ルールは分かってますディズニーではヴィランが勝っちゃいけないし。

でも示し方が最悪。

マジフト大会でNRCが負け続けているというのは理由がありました。

RSAはチームワークが完璧で、NRCは我が我がと自分ばかりで他人を顧みないスタイルから。これは負ける理由が明らかですし、真っ当だから救いもある。

個人プレーが悪いとは言いませんが、ここで示された理由なら、ヴィランでも改心(皆で協力)したら勝てるチャンスがありそうで希望を持てます

でも5章は?

私はVDCダンス甲子園のような、本当にプロを夢見てたりする子たちが日々研鑽して努力をして優劣を競い合うガチ大会だと思っていました。

NRCがガチで仕上げてきたRSAに負けるなら、それは仕方なかった。

ヴィランが負ける世界という摂理に照らし合わせたとしても、こっちがしてきた努力相手が上回ったのだろうという背景があるから納得できます

でも結果は、ヴィランは真っ当に努力を重ねたとしても、ヒーローが同じ舞台に立って仕舞えば、それが例えパフォーマンスにすらなってない思い出作りのお遊戯会だとしても負けてしまうということを示されただけだった。

本当に何を伝えたかったのか分からない。

RSAが優勝しNRCが勝てないのは分かっていました。でもどうしてお遊戯会にした?

悪役が悪役たりえるのって悪いところがあるからでは?

真っ当に努力して、しようとした悪いことも未遂に終わってこの結末って何?

ネージュお遊戯会で出場したこと、そしてルークの一票で負けてしまった設定にしたこと、そしてあのタイミングネージュファンであることを明かしてしまたこと、それが本当に最悪でした。

ルークネージュに入れた理由は納得できるものです。

けれど、それによって勝敗が決し、ルーク戦犯に仕立てあげるストーリーは一体誰が喜ぶのか分かりません。

原作忠実とか狩人の役目とか、まず示し方が最悪です。原作忠実の話が見たいなら原作ます

タイミングも内容も失望するしかできない事でヴィルとプレイヤーを裏切るのが狩人の役目なら、そもそもVDCに出ないで欲しかった。

重ね重ね言いますが、世界摂理は分かりますナイトレイブンカレッジ所属してる時点で正義には勝てません。

彼らには悪いところがあり、だから勝てない。

そう信じていただけに、真っ当に努力をした人間ヒーローお遊戯会に負けてしまうという5章は本当に心底、大嫌いです。

2020-06-09

公開鍵暗号方式理解するのってなかなか難しい

anond:20200608212713

エントリーの人がどこまで理解しているか不明だけど、自分初心者だったときこういう説明がほしかったという話をしてみる。

暗号方式特に公開鍵暗号理解が難しいのはいくつか理由がある。

物理的なものに例えられない

②素朴な利用例が少なく応用的な利用がいくつもある

③実際の利用例はアプリの一機能になっていて見えづらい

また、ざっくりした概念以上のものをきちんと理解しようと思うと

④何がどのくらい安全で何がどのくらい危険セキュリティ的な概念説明

数学的な仕組みの説明

必要になり、これがまた挫折の原因になる。


ここでは自分的にこういう順番で概念を把握していったという流れを書いてみる。

利用者から見た公開鍵暗号の特徴

まず、物理的な錠前や書留郵便イメージするのはあきらめてほしい。

あくまでもデジタルデータを別のデジタルデータに変換して再び元に戻すためのものだ。

公開鍵暗号登場以前は、パスワードを使って変換(暗号化)して、同じパスワードを使って元に戻す(復号化)という共通鍵暗号時代が長く続いた。

そこに、ひとつの大発明があった。

それが暗号化のパスワードと復号化のパスワードで異なるものを使うという技術だ。

特殊数学アルゴリズムパスワードから、それと対になるパスワード2を生成する

パスワードからパスワード1を逆算することは困難

パスワード1で暗号化したものパスワード2で復号できるだけでなく、その逆つまりパスワード2で暗号化したものパスワード1で復号できる(※)

今はその数学アルゴリズムまで理解する必要はない。ただそういうことが可能になったというだけでいい。

パスワード1(秘密鍵)を自分以外が見られないように保管して、パスワード2(公開鍵)を通信相手に渡せば暗号通信ができそうということは理解できると思う。

ちなみにこのパスワードの長さは、プログラムで生成した100桁以上の数字が使われることが多く、それを定型的な千文字程度のテキストにして使われるのが一般的

ツールで生成すると千文字程度のテキストファイル秘密鍵用と公開鍵用の2個できる。

これだけの桁数なので暗号化復号化の計算はそれなりに時間がかかる。(※)

(※) このあたりは一般的公開鍵暗号というよりRSA公開鍵暗号特有の話も混ざってます。詳しくは専門書参照


応用的な利用

次にこの発明を使ったらどういうことができるだろうか、応用できる先を考えてみよう。

(a)秘密鍵暗号化した文書を送るね。公開鍵は〇○○だよ

誰でも最初に思いつく例だけどシンプルすぎて共通鍵と変わらなくありがたみがない。

(b)僕にメッセージを送るときは僕の公開鍵暗号化してね(いわゆる公開鍵暗号

これだと「僕」以外は秘密鍵がなく復号できないので安全

メッセージ送信先を間違って別人に送ってしまっても他人は読めないし、経路のどこかで盗み見や内容の一部を改竄されたりすることがない。

メッセージに返信するときは今度は「僕」ではなく相手公開鍵を使って暗号化する。

(c)本文を毎回全部暗号化すると時間がかかるから共通鍵を君の公開鍵暗号化したものを送るね。それを君の秘密鍵で復号したら以降は高速な共通鍵暗号通信しよう(鍵交換)

共通鍵暗号の高速性というメリットを利用できて、かつ生の共通鍵がネット流れるリスク排除した良いとこ取りの方式

(d)暗号化しない本文と、本文から計算したハッシュ値秘密鍵暗号化したものを送るね。公開鍵で復号化したハッシュ値がそっちで計算したハッシュ値と同じなら本文は改竄されてないよ。

それからこの暗号化は僕しかできないから確かにから送られた文書、僕から送られた内容である保証できるよ。(電子署名

この「電子署名」の実現により、さらに次のような応用が可能になる。

(e)ログイン時に毎回パスワードを打つと見られたりして危険からユーザ名等に署名したものを送るね。公開鍵で復号(検証OKならログインさせて(公開鍵認証

(f)僕は信頼できるよ。これがAさんの署名入りのお墨付き検証してみて。

Aさんは信頼できるよ。これがBさんの署名入りのお墨付き検証してみて。

Bさんは信頼できるよ。これが世界一信頼できる人の署名入りのお墨付き検証してみて。

サーバ証明書

アプリの一機能としての見え方

前項のようなやりとりはほとんどアプリ自動的にやってくれるので、コンピュータ技術者以外の人が公開鍵秘密鍵を直接扱う機会は現状ほとんどないと思う。

ウェブブラウザアドレス欄に鍵マークが表示されていたらそれは鍵交換やサーバ証明書技術が使われていて、鍵マーク右クリックすると証明書を表示できる。

メールアプリでも最近自動的に鍵交換やサーバ証明書が使われている。

もしメールアプリPGPの設定オプションがあればそこで公開鍵秘密鍵を設定すると特定相手と本格的な暗号メールがやり取り可能になる。

サーバ操作するコンピュータ技術者だと公開鍵認証もよく使われていて、ツールで生成した公開鍵サーバ登録してログインに利用してる。

2018-07-30

anond:20180728230300

virtually all事実上すべてって訳す人いるの?と思いましたが…

WordReference.com - Language Forums - virtually allで、

virtually allは、ほぼ全て(almost, but not quite, all)だと思うんだけど、どうよ?

地域(BE or Au E or RSA E or any other E)によって違いがあったりするの? という感じの質問が出ていたので、

それを参考にするといいと思います

てか、何故、正答例を載せておかないかな…もしかして、そこが初心者の間違いの1つだったのか?

2018-02-25

五輪開会式の入場行進を「いろは順」にしたら

順番国・地域コード五十音順との差
168ギリシャGRE-115 (←53)
1イタリアITA+19 (←20)
2イラクIRQ+19 (←21)
3イラン・イスラム共和国IRI+19 (←22)
4イエメンYEM+12 (←16)
5イギリスGBR+12 (←17)
6イギリス領バージン諸島IVB+12 (←18)
7イスラエルISR+12 (←19)
8インドIND+15 (←23)
9インドネシアINA+15 (←24)
10ロシア連邦RUS+196 (←206)
11ハイチHAI+123 (←134)
12ハンガリーHUN+133 (←145)
13バハマBAH+125 (←138)
14バヌアツVAN+123 (←137)
15バルバドスBAR+128 (←143)
16バーレーンBRN+117 (←133)
17バージン諸島ISV+115 (←132)
18バミューダBER+122 (←140)
19バングラディシュBAN+127 (←146)
20パレスチナPLE+124 (←144)
21パナマPAN+115 (←136)
22パラオ共和国PLW+119 (←141)
23パラグアイPAR+119 (←142)
24パプアニューギニアPNG+115 (←139)
25パキスタンPAK+110 (←135)
26ニカラグアNCA+100 (←126)
28ニュージーランドNZL+101 (←129)
29ニジェールNIG+98 (←127)
30ホンコン・チャイナHKG+141 (←171)
31ホンジュラスHON+141 (←172)
32ボリビアBOL+137 (←169)
33ボツワナBOT+135 (←168)
34ボスニア・ヘルツェゴビナBIH+133 (←167)
35ポルトガルPOR+135 (←170)
36ポーランドPOL+130 (←166)
37ベトナムVIE+122 (←159)
38ベリーズBIZ+125 (←163)
39ベルギーBEL+126 (←165)
40ベネズエラVEN+121 (←161)
41ベナンBEN+119 (←160)
42ベラルーシBLR+120 (←162)
43ペルーPER+121 (←164)
44トリニダード・トバゴTRI+75 (←119)
45トルクメニスタンTKM+75 (←120)
46トルコTUR+75 (←121)
47トーゴTOG+69 (←116)
48トンガTGA+74 (←122)
49ドイツGER+66 (←115)
50ドミニカDMA+67 (←117)
51ドミニカ共和国DOM+67 (←118)
52チリCHI+60 (←112)
53朝鮮民主主義人民共和国PRK+58 (←111)
54チャイニーズ・タイペイTPE+52 (←106)
55チャドCHA+52 (←107)
56チェコ共和国CZE+49 (←105)
57チュニジアTUN+53 (←110)
58中華人民共和国CHN+51 (←109)
59中央アフリカCAF+49 (←108)
60リベリアLBR+140 (←200)
61リトアニアLTU+136 (←197)
62リヒテンシュタインLIE+137 (←199)
63リビアLBA+135 (←198)
64ルワンダRWA+139 (←203)
65ルーマニアROU+136 (←201)
66ルクセンブルグLUX+136 (←202)
67カタールQAT-24 (←43)
68カナダCAN-24 (←44)
69カーボベルデCPV-29 (←40)
70カザフスタンKAZ-28 (←42)
71カメルーンCMR-25 (←46)
72カンボジアCAM-24 (←48)
73ガイアナGUY-32 (←41)
74ガボンGAB-29 (←45)
75ガーナGHA-36 (←39)
76ガンビアGAM-29 (←47)
77ヨルダンJOR+117 (←194)
78タイTHA+23 (←101)
79タジキスタンTJK+24 (←103)
80タンザニア連合共和国TAN+24 (←104)
81大韓民国KOR+21 (←102)
82レバノンLBN+123 (←205)
83レソトLES+121 (←204)
84ソロモン諸島SOL+16 (←100)
85ソマリアSOM+14 (←99)
86ツバルTUV+27 (←113)
87ネパールNEP+43 (←130)
88ナイジェリアNGR+35 (←123)
89ナウルNRU+35 (←124)
90ナミビアNAM+35 (←125)
91ラトビアLAT+105 (←196)
92ラオス人民民主共和国LAO+103 (←195)
93ウルグアイURU-65 (←28)
94ウガンダUGA-69 (←25)
95ウクライナUKR-69 (←26)
96ウズベキスタンUZB-69 (←27)
97ノルウェーNOR+34 (←131)
98オランダNED-60 (←38)
99オーストリアAUT-63 (←36)
100オーストラリアAUS-65 (←35)
101オマーンOMA-64 (←37)
102クロアチアCRO-41 (←61)
103クック諸島COK-44 (←59)
104クウェートKUW-46 (←58)
105グレナダGRN-45 (←60)
106グアムGUM-49 (←57)
107グアテマラGUA-51 (←56)
108マリMLI+69 (←177)
109マルタMLT+69 (←178)
110マダガスカルMAD+65 (←175)
111マレーシアMAS+68 (←179)
112マラウイMAW+64 (←176)
113マケドニアMKD+61 (←174)
114マーシャル諸島MHL+59 (←173)
115ケイマン諸島CAY-53 (←62)
116ケニアKEN-53 (←63)
117フィリピンPHI+32 (←149)
118フィジーFIJ+30 (←148)
119フィンランドFIN+31 (←150)
120フランスFRA+34 (←154)
121ブルガリアBUL+34 (←155)
122ブルネイダルサラーBRU+35 (←157)
123ブルキナファソBUR+33 (←156)
124ブルンジBDI+34 (←158)
125ブラジルBRA+28 (←153)
126ブータンBHU+25 (←151)
127プエルトリコPUR+25 (←152)
128コロンビアCOL-60 (←68)
129コソボKOS-63 (←66)
130コートジボワールCIV-66 (←64)
131コモロCOM-64 (←67)
132コスタリカCRC-67 (←65)
133コンゴCGO-64 (←69)
134コンゴ共和国COD-64 (←70)
135エチオピアETH-103 (←32)
136エリトリアERI-103 (←33)
137エルサルバドルESA-103 (←34)
138エクアドルECU-109 (←29)
139エジプトEGY-109 (←30)
140エストニアEST-109 (←31)
141デンマークDEN-27 (←114)
142アイルランドIRL-140 (←2)
143アイスランドISL-142 (←1)
144アルバニアALB-133 (←11)
145アルーバARU-137 (←8)
146アルメニアARM-134 (←12)
147アルジェリアALG-138 (←9)
148アルゼンチンARG-138 (←10)
149アラブ首長国連邦UAE-142 (←7)
150アフガニスタンAFG-146 (←4)
151アメリカ領サモアASA-145 (←6)
152アメリカ合衆国USA-147 (←5)
153アゼルバイジャンAZE-150 (←3)
154アンドラAND-139 (←15)
155アンゴラANG-142 (←13)
156アンティグア・バーブーダANT-142 (←14)
157サウジアラビアKSA-86 (←71)
158サモアSAM-86 (←72)
159サントメ・プリンシペSTP-86 (←73)
160サンマリノSMR-85 (←75)
161ザンビアZAM-87 (←74)
162キリバスKIR-108 (←54)
163キルギスタンKGZ-108 (←55)
164キプロスCYP-113 (←51)
165キューバCUB-113 (←52)
166ギニアGUI-117 (←49)
167ギニアビサウGBS-117 (←50)
169メキシコMEX+15 (←184)
170南アフリカRSA+11 (←181)
171南スーダンSSD+11 (←182)
172ミクロネシア連邦FSM+8 (←180)
173ミャンマーMYA+10 (←183)
174シリア・アラブ共和国SYR-94 (←80)
175シェラレオSLE-99 (←76)
176シンガポールSGP-95 (←81)
177ジョージアGEO-98 (←79)
178ジャマイカJAM-100 (←78)
179ジブチDJI-102 (←77)
180ジンバブエZIM-98 (←82)
181東ティモールTLS-34 (←147)
182モロッコMAR+9 (←191)
183モルドバ共和国MDA+7 (←190)
184モルディヴMDV+5 (←189)
185モナコMON+3 (←188)
186モーリタニアMTN±0 (←186)
187モーリシャスMRI-2 (←185)
188モザンビークMOZ-1 (←187)
189モンゴルMGL+3 (←192)
190モンテネグロMNE+3 (←193)
191セイシェルSEY-99 (←92)
192セルビアSRB-97 (←95)
193セネガルSEN-99 (←94)
194赤道ギニアGEQ-101 (←93)
195セントルシアLCA-97 (←98)
196セントクリストファー・ネイビスSKN-100 (←96)
197セントビンセント・グレナディーンVIN-100 (←97)
198スイスSUI-115 (←83)
199スロバキアSVK-110 (←89)
200スロベニアSLO-110 (←90)
201スペインESP-115 (←86)
202スリナムSUR-115 (←87)
203スリランカSRI-115 (←88)
204スワジランドSWZ-113 (←91)
205スーダンSUD-120 (←85)
206スウェーデンSWE-122 (←84)
27日本JPN+101 (←128)

2017-10-18

応用情報技術者試験を受けてきました

anond:20170911232449

上の日記を書いた増田です。

こんにちは

試験、受けました。

ことさら話題にするようなことでもないかもしれませんが、せっかくなので書きます

これから受ける人などの参考になれば幸いです。

プロフィール

30代。

普通科高卒

製造業

プログラミング歴は数ヶ月。

それまではExcelWordがちょっと分かるくらいだった。

言語VBAVBバッチ

一ヶ月に100行書いてるかどうかといった感じ。

製造現場身体を動かしながら、改善の種を探している。

所持資格はTOEIC700、日商簿記2級など。

基本情報は受けたことがない。

受験

動機

内製のソフトC++でできていて、これを色々弄くれるようになればあんなところやこんなところまで自動化できるなあ、でも何も知らないまま弄るのはちょっと怖いなあ…

そうだ、勉強しよう!

合格すればついでに報奨金(10万)も貰えるしね!

勉強期間、学習時間

8月半ば、受験申込期間の締め切りギリギリ試験存在を知り応募。

勉強期間は2ヶ月ほど。

平日は1日1〜2時間。土日は1日3〜5時間。まったく勉強しなかった日が10日ほど。

体感的な総学習時間100時間ほど。

学習方法

最初に、ネット評価の高かった合格教本という本を買って読んでみた。

基本情報知識もない状態だと、書いてあることがもうほんとにまったく分からず、挫折しそうになった。

方針を変えて、応用情報技術者試験ドットコム過去問道場をひたすら回した。

からない言葉ネットで調べて、これはと思う説明出会ったらOneNoteにひたすらコピペした。

最後の2週間はドットコムユーザー登録をし、理解度問題を色分けするようにした。

最後の1週間でピヨ太くんのサイト(正式名称長い)を見つけ、分からない言葉はまずこのサイト検索するようにした。

午後対策過去問を本番と同じ時間で4回分解いたくらい。

合格教本は結局ほとんど読まなかった。

午後の選択問題

受験前は、

…のどれかを選ぼうかなと考えていた。

いわゆるストラテジ、マネジメント系科目だけで固めても良かったのだけど、組込みなんかは普段生活からイメージやすいし、2時間半の長丁場ならテクノロジ系科目を間に挟んだ方がほどよく頭のリフレッシュになるかなーと思っていた。

実際の試験では、

…を選んだ。

試験当日(午前)

試験会場に時計がなかったので、時計が無い状態受験した。

机上に置けるような時計は持っていなかったし、まあ午前だけなら時計が無くても大丈夫だろうとタカをくくっていた。

問題を順当に最後まで解いて、全て順番通りにマークされてることを確認してから、手を挙げて外へ出た。

出てからスマホの電源を入れて時間確認した。

15分ほど余っていた。

試験当日(午後)

さすがに午後は時計が無いとマズイと思い、休憩中に買ってくる。

セキュリティ(必須問題)の設問1で長考してしまい、20分ほど経っても解答用紙の半分が埋まっていない状態

とりあえず他の問に移り、最後に余った時間セキュリティに戻る方針シフト

経営はぱっと見簿記知識が生かせそうだと思い選んだのだけど、「固定長期適合率」がどういう計算式なのか見当がつかない。

早々に切り上げる。

組込みの設問1でまたも長考、ほぼ解答を埋められたものの、結局40分ほど費やす

この時点で残り1時間と少ししかなく、かなり焦る。

サビマネ監査は焦りから問題文の通読ができず、設問を最初に読むようになり、結果読み返しが増えてしまった。

監査を終えたところで5分くらい余ったので、這々の体でセキュリティに戻る。

なんとか穴埋めしフィニッシュ

午前とは逆に、始終時間との戦いだった。

自己採点

午前は78.75点。

午後は厳しめで53点、甘めで66点(TAC基準)。

セキュリティ、サビマネ監査の点数がかなり流動的。

午前は問題用紙に選んだ選択肢に○する余裕があったのだけど、午後はそれがなくなって、問題解くのに必死自分が何を書いたかしっかり思い出せない。

色々と書いたけれど、そういう訳で正直受かってるかまったく分からない。

配点、部分点次第といったところ。

怖い。

感想

午前の対策簡単だ。

ただ過去問を解くだけのロボットと化せばいいだけ。

体感3割〜4割くらいは過去問の流用で問題ができあがる。

いわゆる一般常識で解ける問題も多い。

午後の対策が難しい。

午後対策でよく見られるのは「国語の読解力をつける」というアドバイスだが、読解力というのは漠然としていてレベルの向上も分かりづらい。

今の私なら、以下の順番で勉強を進めるかもしれない。

ま、受かってたらやらないんだけどね!

そもそも、「試験合格するための勉強」に終始して、最初動機なおざりなっちゃった感が否めません。

公開鍵暗号方式といえば、RSAだよね!知ってる知ってる」

…でもそれらがなんなのかはよく知らない、みたいな。

一つ確実に「分かった」と胸を張って言えることは、

からないことは、調べればいい。

分かる人に、聞けばいい。

ってことですかね。

受かってなかったとしても、もう受けないかもしれませんね。

はぁ…10万欲しいなぁ…

以上で終わりです。

最後まで読んでいただきありがとうございます

お疲れ様でした。

2016-04-26

anond:20160426145507 の続き

anond:20160426124418anond:20160426145507 の続きだゾ。てか長えよ

(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数動画アップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認証プロキシSaaS アプリを筆者は作った。好評だったが、これはもちろん本来あるべきでない欠陥のexploitのはず。)

(略: 個人ユーザ向けのAPI設計ばかりで、雇用者上司アカウント管理するという観点がない。SAMLでは普通にできるのに、OAuthとなるとセキュリティ的に云々と言って拒むサービスばかり。別のUIで既にできてることをAPIにしても意味がない。これまでできなかったことをAPIで可能にするのではなく、単なるシングルサインオンでよければ他にある。実際Googleは個人向けにはOAuth活用しているが、Google Apps for BusinessはOAuth以外のシステムを使っている。)

(略: 主要な設計ミスは、外部サービスすべてを同等に疑うところ。管理者が各サービスの信用性を判断して権限を調節できるようにしないところ。これまでどれほど多くの製品OAuthの面倒さのために失敗してきたことか。)

普通実装における」OAuth代替

適切な OAuth ベース設計とはどのようなもの

ここまでで「普通実装における」OAuth がまったくおかしいということはわかりましたが、OAuth が実際うまくいくのはどういうときでしょうか。

初期の OAuth 規格および概念におおよそ付き従っているシステム一般的に言って、新しい規格ベースのよりもセキュアで、マシです。OAuth 1.0 の実装がすべてセキュアだというのではありませんが、たいてい問題は少ないです。こうしたシステムは通常、次のふたつのアプローチのどちらかに従っています:

はいえ、このように設計されている OAuth ベースシステムはごくごく希少で、しか一般的にこうしたシステムは、他のところで使われている OAuth とは似ても似つかぬものです。OAuth 1.0 規格の方に寄って頑張っていますが、公式には 1.0 は非推奨ですから、こうしたアプローチを使っているシステムはそのうち「アップデート」されて OAuth 2.0概念や追加機能すべてを加えて再構築され、セキュリティユーザビリティをだめにしてしまうことになります。これこそ筆者があらゆる OAuth ベースのものを見逃したくない理由です。もっと古く、もっと機能的な形式OAuth を使っていても、システムに「改善」が必要だという素敵な考えを管理者のだれかが閃いて台無しにしてしまうからです。ご迷惑をおかけしてすみませんと言うぐらいなら、まったく別のものを使うほうが良いですよね。

他の選択肢

他に手はないかと探すとき、人々はよく他の「フレームワーク」にはどんなものがあるかを知ろうとします。しかし、考え抜かれたセキュアな設計を実現するためには必ずしもフレームワーク必要というわけではありません。現状、OAuth とはどのようなものかについての意見サービスごとに異なっていますので、承認の具体的な動作の仕組みもまったく一定ではありません。そんな中でフレームワークを探しまわるのは、簡単にできることをいたずらに複雑化しているだけのことが多いです。唯一ほんとうに難しい要素、しっかりした規格の必要な要素は、使用する鍵パラメータ改竄を防ぐため変数署名する方法だけであり、この点に関して、ほとんどの OAuth ベース実装は一切何もしてくれません。

ウェブサービスの最大手である Amazon は、世界中企業サービス提供する一流プロバイダで、合計 30% 以上という途方もない市場シェア他者を圧倒していますAmazonアプローチは、自分アプリ認証情報を生成できるコントロールパネルへのアクセスを、すべてのアカウントおよびアカウント管理者提供することです。この認証情報で、どの Amazon サービス作業できるか、そのサービスでどの操作を実行できるか、どの権限作業しなければいけないかを指定できます。この認証情報必要に応じて「アカウントホルダ」の人が破棄することもできます

AmazonAPI における認証承認技術には、本質的制限が多く潜在的危険性のあるリダイレクトを一切必要しません。Amazonプロトコル認証情報は、直接送ることは一切なく、データ署名に使うのであって、これでブラウザを通してパラメータを送る必要のあるときにも改竄不可能にすることができるのです。

Amazon設計アカウントの利用状況を API の利用まで適切に把握できますし、API認証承認もすべて Amazonからスタートし、その際のアプリ認証情報も「Amazon の」コントロールパネルから生成されます。この認証情報はその後、いかなるトークン交換システムも使わず直接 API プロセスで使われます。この設計なら「普通実装における」OAuth が達成している真のセキュリティ目標をすべて達成し、かつ前述したセキュリティ上およびユーザビリティ上の問題をすべて回避しています

ひとつ言及せざるをえない短所は、Amazon権限システムが幾分わかりにくく、あまりユーザに優しくないということです。ただし、このことは何故かほとんどのコントロールパネルにも言えることで、いずれにせよ UI 設計問題であって、承認プロセス自体の失点ではありません。さらに、Amazonコントロールパネルはかなりキビキビ使えて、それ自体API でも使えます。この点たとえば Google場合のように、筆者の知る限りメタ API もなく、何をするにも何十もの手順が必要なのとは大違いです。

Amazon認証および承認メソッドは他のサービスプロバイダにも幾つかコピーされていますGoogle 自身企業向け製品の一部でこれを利用できるようにしていますGoogle 自身純粋OAuth 設計企業サービスに向いていないことを認めており、企業サービスには JSON Web Tokens (JWT) の利用を推奨しています

JWT はサービス間の SSOAPI 利用を可能にする規格です。多くの点で JWT は SAML に似ていますが、SAML はややこしくて、XML Security (名前と違って、まったくセキュアではない) の上に構築され、API 利用に向いていないのに比べ、JWT は SAML の主要な目標を、単純かつ使いやす方法で一切の面倒なく達成しています。HMAC 実装ひとつ用意し、JSON の構築と解析の方法を知っておけば JWT は使えます既製品をお求めでしたら、膨大な JWT ライブラリが既に存在していますよ。

ただ Google場合典型的な JWT 利用法よりも高度で、HMAC のかわりに、もっと高度ですがこの分野では人気の低い RSA デジタル署名を利用するよう要求していますGoogleコントロールパネルではアカウント管理者自分企業サービス用に新しい鍵ペアを生成でき、API ログイン署名するために使う秘密鍵ダウンロードできます。こちらのほうが HMAC よりセキュリティは高いですが、Googleプロセス全体を本当に無駄に複雑化していますコントロールパネルしょっちゅう完全に再設計して、前と同じことをしたいのに使い方が違っていて混乱する点は言うまでもありません。JWT 利用の実例必要なら他をあたるようお勧めします。

他に使われている技術は、サードパーティがどんな権限必要としているかをある種の XMLJSON ファイル定義してウェブサイト送信できるようにするサービスのものです。ユーザがあるページを自分アカウント訪問し、ファイルURL (あるいは中身) をそこに貼り付けると、その外部サービスあるいはアプリが求めている権限の一覧やそこに含まれ説明などが表示されるようになっています。それを見て認可したいと思うユーザは、認証情報を生成してそのサードパーティアプリあるいはサービスに貼り付けますユーザは後で無効にしたくなったら認証情報を破棄することができます。これも、開発者おかし負担を強いることなく、すべてのアカウントAPI サービスがあり、権限管理を備え、サービス自体からフローが始まる、実にセキュアな設計です。

承認管理のためにサービスから提供してもらう必要が本当にあるのは、適切な役職 (管理者アカウント所有者など) を持つユーザ自分に割り当てられた権限や (望むなら) 期限を持つ認証情報API 利用のために生成できる何らかのパネルだけです。こうした認証情報はその後、お好みのセキュアな認証システムを通して利用することができます。たとえば HTTP Basic Authentication over HTTPS のような単純なもの、これは事実上どの HTTP ライブラリにも入っていますし、HTTP Digest Authentication、これはもっとセキュアでありながらほとんどの良質なライブラリサポートされていますし、その他 HMAC, RSA, 楕円関数など認証情報ネットに通す必要のない暗号学的テクノロジー活用した認証プログラムに基づくものなら何でも使えます特に HMAC は、承認認証実装するほとんどすべての人 (Amazon や、一部の OAuth 実装も含む) によって既に使われています

こういった種々の実績あるテクニックは、セキュアなプラットフォームを作るために CSRF 対策など複数フレームワーク同士の相性を勉強する必要があるという重荷を軽くしてくれますし、一般的に、既存アーキテクチャワンタッチで装着できるようなモジュール化の実装が可能です。ユーザアプリ認証情報が盗まれる可能性をなくしてくれます。ややこしい CSPRNG を常に使用する必要もありません。このようなシステムOAuth の生まれるずっと前から存在しており、現在でも一般的です。OAuth は、ユーザ認証情報要求したり他に弱点があったりするような一部の劣悪な設計システムよりはセキュリティが良いかもしれませんが、既にある真の設計を置き換えるものではありません。OAuth が解決すると主張する問題点は実のところ、既存の良く設計されたシステムには存在していませんし、「普通実装における」OAuth は実のところ、解決すると主張する問題の多くを招き入れるばかりか、最初存在していなかった問題まで生じさせています宣伝文句と違って、OAuth にすれば自然と驚くほどセキュアになるというわけではなく、むしろ数々の短所実装の困難さを考えれば、他の考え抜かれた選択肢のほうがはるかに優れています

これからサービス設計をして API アクセス提供することになっている方はどうか、ご自分が実現しようとなさっているのが何なのかを本当に考えてください。他の人がやっていることをコピーするだけで済ませたり宣伝を丸呑みしたりしないでください。どうしてもコピーしなければいけないなら、Amazon (これが最善です) や Rackspace, IBM SoftLayer, Linode, VULTR, Zoho, Zoom ほか、API の素直で健全認証システムを構築する方法について現時点で多少なりとも理解のあるところをコピーするようにしてください。

2016 年 4月 Insane Coder

http://no-oauth.insanecoding.org/

2015-10-15

LINE Engineers' Blog掲載された記事を読み解こうとして力尽きた

http://developers.linecorp.com/blog/ja/?p=3591

Letter Sealing って何でしょうか。私気になります

必要範囲で、原文を引用しています。原文は先に引用元アドレスと閲覧日時を記し、引用記法によって地の文識別できるようにしています

長すぎ;読まない

ECDHAES256-CBC 使ってみた。通信相手の認証については読み取れない。

暗号通信の流れ

図2 において、 Server のところで Re-Encryption (一度復号されて、再度暗号化されている) ことが明示されています

この図を素直に読むと、送信者からサーバーまでの通信路は暗号化されているものLINEサーバーが受信したところで復号されて平文で保存され、サーバーから信者までの通信路は暗号化されていると理解できます文脈から、この流れを変えたいのであると推測できます

SSL公開鍵暗号

http://developers.linecorp.com/blog/ja/?p=3591 より引用2015年10月14日 22時40分に閲覧:

加えて、LINEでは、仮に通信ネットワークの傍受が行われたとしてもメッセージを覗くことができないように、公開鍵暗号(public key encryption)方式を使っていますユーザーに対してLINEアプリ提供する際、暗号化ができる公開鍵のみをアプリに入れて提供し、ユーザー端末とサーバ接続されたときだけLINEサーバでのみ解析できる暗号化された安全チャネルを作ります。こうすることで、SSL(Secure Socket Layer)より軽く、LINEの全バージョンで使用できる安全暗号化を実現できます

SSL はすでに時代遅れの代物で、 2015年現在は皆さん TLS を利用されていることでしょう。 Web ブラウザSSL 2.0SSL 3.0 を有効にしているそこのあなた、今すぐ無効しましょう。

TLS では、公開鍵暗号方式共通鍵暗号方式電子証明書暗号学的ハッシュ関数といった複数暗号技術要素を組み合わせて安全通信路を確保しています

RSA代表される公開鍵暗号方式一般的AES代表される共通鍵暗号方式と比べて計算量が大きい、つまり重たい処理となります

このため TLS では、通信路を流れるデータ暗号化に共通鍵暗号を用いて、共通鍵の共有や相手の認証のために公開鍵暗号方式を用いるのが一般的です。

仮にメッセージ暗号化に RSA を用いているとしたら、 SSL より軽いという点をどのように実装しているのか気になります

http://developers.linecorp.com/blog/ja/?p=3591 より引用2015年10月14日 22時40分に閲覧:

ユーザー側のLINEアプリ(クライアント)には、サーバが発行したRSA鍵を使用してデータ暗号化に使う暗号化鍵値を共有します。この鍵を利用してデータ暗号化すると、第三者メッセージを見ることができなくなります

これは上で説明したとおり SSLTLS でも行っていることです。

RSA を用いているので安全であるという主張をしていますが、メッセージ暗号化に用いられている暗号スイートアルゴリズムの種類、鍵の長さ、ブロック暗号場合暗号利用モード、そしてハッシュアルゴリズムの種類)は、その通信路が安全である判断できるか否かを決める大切な情報です。

http://developers.linecorp.com/blog/ja/?p=3591 より引用2015年10月14日 22時40分に閲覧:

既存RSA方式秘密データの共有に使う安全方式ではありますが、鍵管理の面から見ると、ユーザー側の端末でそれぞれのRSA鍵をすべて管理しなければならないという問題があり、その代替手段としてDHを使用するようになりました。

DH および ECDH による共通鍵暗号に用いる鍵の交換は SSLTLS でも実装されており近年では広く使われていますSSL より軽いと主張し、 SSLTLS公開鍵暗号方式以外の要素によって担保している安全性をどのように確保しているか不明実装に比べると、大きな改善です。

なお SSLTLS においては通信相手の公開鍵を全て管理する必要がないように、上で説明した電子証明書による公開鍵基盤 (PKI) の仕組みを利用しています

まり共通鍵暗号に用いる鍵の交換にどのような手段を用いるかは、鍵管理とは(ほぼ)独立です。

共通鍵暗号暗号利用モード

http://developers.linecorp.com/blog/ja/?p=3591 より引用2015年10月14日 22時40分に閲覧:

ここでメッセージ暗号化に使用している暗号アルゴリズムAES-CBC-256という方式で、現在一般に使われている暗号アルゴリズムの中で最も強度が高いと評価されています

メッセージ認証と組み合わせない CBCビット反転攻撃に弱いことが知られていますGCM ではデータ暗号化と認証を同時に行うためビット反転攻撃に耐性がありますAESGCM で利用するのは、 最近TLS実装では広く用いられており、 Googletwitter も利用しています

CBCCBC-MAC のようにメッセージ認証と組み合わせることでビット反転攻撃に強くなります

解決されない鍵管理問題

図6 のとおり、 ECDH共通鍵暗号に用いる鍵の交換を行うにしても通信相手の公開鍵必要です。 上で説明したとおり鍵管理という問題への解決策になりません。また公開鍵が本当に通信相手のものであることをどのように検証するのかについても不明です。通信相手の検証は、送信側では秘密の話を他の人に知られないように、受信側では他の人になりすまされないように、双方にて必要です。

ここから安易パターン想像ですが、通信相手の公開鍵情報LINE ユーザー情報の一部として LINE サーバー管理されており、必要に応じて安全通信路を用いて LINE サーバーから取得するようなものではないかと思います公開鍵情報のやりとりに用いられる通信路に正しく実装された TLS が用いられていて、サーバークライアントの両方が認証されていて、現在の水準から見て妥当レベル暗号スイートが用いられていることを願うばかりです。

公開鍵秘密鍵がどこでどのように保管されているのか気になります。各端末で保管するのが安全ですが、サービス要求として端末を乗り換えてもメッセージが読めるという条件を安易に満たすために秘密鍵LINE サーバーに預託していないことを祈るばかりです。

ECDH 鍵の生成は計算量が大きい処理であり質の良い乱数必要します。 PC に比べると非力なスマートフォンで生成した鍵の質をどのように担保しているのか気になります

2015年10月17日 10時16分追記

先ほど閲覧したところ、上記引用箇所の多くは削除されていました。公開鍵が本当に通信相手のものであることをどのように検証するのかについては明らかではないようです。 LINE サーバーが介在する形であれば、鍵をすり替えることで別のユーザーになりすますことが可能でしょう。または、 LINE アプリに何か細工をする方がより簡単でしょう。

ECDH 鍵はその場限り (ephemeral) という説明がないので Perfect Forward Secrecy ではないと考えられ、望ましくないという意見もあるようです。 LINE サーバーとの間に安全通信路を確立する目的で ECDH 鍵を用いる場合LINE サーバーが用いる秘密鍵漏洩は全てのユーザーに影響を与えうるため PFS は非常に重要です (TLS を用いた Web サーバーでも同様です) 。一方ユーザー間でメッセージ暗号化する場合ユーザー所有の ECDH 鍵についてはそのユーザーに影響が限定されます通信相手ごとに必要なその場限りの鍵生成とユーザー所有の ECDH 鍵を利用した鍵交換にかかる計算量と ECDH漏洩リスクを天秤にかけて PFS を採用しないという判断かもしれません。

通信の秘密という観点ではメッセージの内容だけではなく誰と通信たか (または、していないか) という情報も守りたくなります。宛先を LINE サーバー確認できない形に暗号化されるとメッセージの配送ができなくなるため、通信相手や通信の有無については秘密ではないと考えられます

2013-03-13

サーバ初心者Webサービスを公開するうえで考えたこと

だって自作Webサービス公開しました

http://www.radiosonde.net/

これまで他の人に用意してもらったサーバ自分プログラムを動かしたことはありましたが

自分自身で一からサーバをセットアップしたことはほとんどなかったので、いろいろとハマりました。

作業を進める上で困ったり考えたりしたことを書いていきます

ちなみにサーバ自体はさくらのクラウドOSにはCentOSを使用しているので、それ前提のお話になります

SSHファイヤーウォールの設定

最初サーバを起動してから速やかにSSHファイヤーウォールの設定を変更しました。

はてブなんかでも定期的に話題になっているのでおなじみですね。

SSHポートを22以外の別のポートに変更する

rootによるリモートログインを禁止する

パスワードログインを禁止し、鍵認証有効にする

・念のためrootパスワードを潰しておく

SSHHTTP(S)など、どうしても公開しなければならないポート以外は遮断する

SSHポートについてIP制限が行えるならば尚良い

さらっと書きましたが、設定をミスって自分自身もログインできなくなり、何度かOSの再インストールを繰り返しています

から気付いた事ですが、さくらのクラウドではクラウド管理画面のリモートスクリーン経由でローカルログインできるので

別にOSインストールしなくてもiptablesの設定を変更できたんですよね...

逆に言うといくらファイヤーウォールとSSHを設定しても管理画面にパスワードログイン環境が残ってしまうので

パスワード管理には引き続きしっかり気を使う必要がある。ということでもあります


Webアプリの動作が重い

httpd,php,mySQL,memcachedなど必要サービスインストール、設定し

作成したWebアプリプログラムを乗せて動かしてみました。が、動作が重いような...

開発環境ではさくさく動いていたのに、本番環境ではどのページ遷移ももっさりしています

abで計測してみたところ、開発環境のおよそ2分の1のスコアとなってしまいました。

開発環境が仮想2コアのメモリ1Gだったのに対し、本番環境が仮想1コアのメモリ2G

CPUの性能について半減しているのでそのせいかな、と思いつつ設定を見なおしていたところ

特に使っていないと思われたipv6を停止した途端にパフォーマンス改善されました。

ページ遷移に伴うもっさり感が解消され、abの計測結果も開発環境と遜色ない結果が出ています

デフォルト有効になっていたipv6の影響により余計な処理が走っていたのかもしれません。


サーバから送信したメール迷惑メールと判定される

パフォーマンス改善に喜んだのも束の間、会員登録などの処理でWebアプリからメールを送信したところ、Gmail宛のメールがことごとく迷惑メールと判定されるという事案が発生。

spfの設定を行なうメールの内容について吟味するなどの回避策を試してみましたが一向に改善されません。

試しにHotMailexciteメールアカウントに送信したところ、そちらではそもそもメールを受け付けてもらえずエラーコードが返って来る始末。

困り果てていたところ、エラーの内容からサーバIPがspamhousにスパム送信元として登録されていることが判明しました。

postfixホスト名の設定がデフォルトで「localhost.localdomain」などとなっており、それをそのまま使っていたためにGmailスパム送信元として通報してしまったようです。

設定を修正し、spamhousに解除依頼を提出。事なきを得ました。


KVSの変更

クラウドを利用すれば、サーバを停止することなく簡単な設定でスケールできるようになる。

と、自分勝手に思い込んでいたせいなのですが、消えては困るデータの一部をmemcachedに保存する実装を行なっていました。

実際のところさくらのクラウドではサーバを完全に停止しなければプラン変更を実施できないし

そもそもサーバが落ちたらどうするんだよ。ということで、急遽KVSを変更する必要に迫られました。

速度の低下が気にかかったため、いくつかの候補を実際に動かし

phpスクリプトから1万件のデータ読み書きを行うという形でmemcached比較してみたところ次のような結果に。

サービス1万件書込1万件読込
memcached 2.55秒 2.30秒
handlersocket 21.23 2.71秒
InnoDB20.23 5.10
kyotoTycoon 8.22秒 7.72秒

さすがに読み書きそれぞれmemcachedが最速ですが、読み出しについてはhandlersocketも負けていません。mySQLから普通にSELECTしてもmemcachedの2倍程度の時間しかからないという結果が意外でした。

しかしながら書き込みのほうではhandlersocketもmemcached10倍近くの時間がかかっており、少々速度的な影響が気になってきますmemcachedの倍のパフォーマンスを記録したという記事を見たことがあるので、設定、チューニングについて生かしきれていない部分があるのかもしれないとも思いましたが、知識が不足しているところで無理をすると問題が発生した時に対処できないと考え、候補から除外することとしました。

結局、今回の用途では読み込み処理より書き込み処理のほうが圧倒的に多いことも考慮し、kyotoTycoonを採用しました。実際の利用箇所に組み込んでabで計測してみたところ、だいたい30%程度のパフォーマンス低下にとどまっており、これなら許容範囲かと考えています

mySQLレプリケーションが止まる

実行系と参照系に分ける形でmySQLレプリケーションを行なっていたのですが、度々レプリケーションが停止する現象が発生しました。

一部のテーブルについて肥大する可能性が考えられたため、参照系に接続するプログラムで使わないテーブルをレプリケーションから除外していたのが原因です。

例えばtabelAをレプリケーションし、tableXをレプリケーションしないという設定にしたうえで

実行系でINSERT INTO `tableA` SELECT `value` FROM `tableX`などといったクエリを発行すると、参照系にtableXが無いためエラーが発生して止まってしまます

レプリケーションするテーブルを限定する場合プログラム側でも注意を払わないと危険です。当たり前ですが。

サーバ監視にmonitを使用

監視といえばcactinagios定番なのかもしれませんが、設定が複雑そうで尻込みし、monitを使用することにしました。

簡単な設定でloadaverageやメモリHDDの使用量をチェックできるほか

httpdmysqldなどといったサービスプロセス監視し、もし落ちていたら自動で起動してくれるので助かります

Webアプリの秘匿

パスワード保護を行うとしても、サイト全体の管理画面など自分しか使わないプログラムWeb晒しておきたくない。

というわけで、一部のWebアプリを秘匿する設定を行いました。

管理画面のWebアプリを9999番など閉じているポートに設置した上で、SSHを利用したトンネルを掘ります。といっても

ssh -t -L 9999:localhost:9999 user@xxx.xxx.xxx.xxx

上記のようなコマンド管理画面のWebアプリを置いたサーバログインするだけです。

ブラウザアドレス欄にhttp://localhost:9999/と打ち込めば、接続が開いている間のみアクセス可能になる感じですね。

サーバログインできる人でなければ実行できないことなので、気分的にある程度安心します。

SSHログバックアップ

自動ログバックアップを行いたいと考えたのですが、パスワード無しの鍵でログインして転送する形には抵抗がありました。

調べてみたところ、authorized_keysに公開鍵を記入する際の設定で、その鍵でできることを制限するという手段があるようでした。

具体的には、authorized_keysに

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="some commands" ssh-rsa AAAAB3NzaC1yc2EAAA...

などとして公開鍵を追加しておくと、その鍵でログインした直後にcommand=""の部分で設定したコマンドを実行して接続を終了する挙動となり

接続フォワードもできなくなるため、パスワード無しでも鍵の流出に関するリスクを最低限に留めることができるというわけです。

commandの実行結果は標準出力から受け取ることができるので、例えばcommand=""の部分にファイルの内容を表示する処理を設定していたとすれば

ssh -i .ssh/no_password_key user@xxx.xxx.xxx.xxx > /path/to/file

などとしてログインの結果をファイルに書き込むだけで、簡単にファイル転送が実現できます


まとめ

他にも大小さまざまな問題に行きあたりましたが、忘れてしまったor書ききれないのでここまでとします。

たった1つのサイトを公開するにしても問題というのは尽きないものだと実感させられました。

今は基本的な情報だけでなく、ちょっと突っ込んだ内容でも検索で解決していけるので嬉しいですね。手がかりを残してくれた先達に感謝することしきりです。

現状ではひとまずの見切りを付けて公開していますが、より堅牢で負荷に強いサーバとなるよう、随時チューニングを行なっていこうと考えています

最後

作ったWebサービスについて少し書きます

サイト名は「Radiosonde」

個人サイトや小規模な商業サイトなどプロモーションにあまりお金をかけられないサイトを主な対象とした、無料で出稿できる広告ネットワークサービスです。

既存サービスで近いのは「あわせて読みたい」や「zenback」、各社提供RSS相互リンクサービスなどになるでしょうか。

広告としての体裁がある分、それらより若干積極的な性質になるのではと考えています

現時点ではサービス本体のプロモーションに苦心するという本末転倒のものの状況でありますが、もしよろしければ見ていただけると嬉しいです。

2011-10-12

匿名性の無さ

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

http://anond.hatelabo.jp/20111006234714

http://twitter.com/i315 さんでしょうか

さてわたしも不登校なわけですが,お前とはどうかんがえても方向性が違うので
ただおもしろがって見ているだけにしますね!!!!

sora_h でした!!! 匿名性ないね!!!

追記: http://twitter.com/#!/Glass_saga/status/124131595606167554 ということでPGP署名を施しました.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)

iQEcBAEBAgAGBQJOlaZiAAoJEIHMzVZz47asMIsH/0AUmA8eAkXrtNzDVX7asUYs
5FO06sNUxMYZEeVDTyOwDsYxjPkDnW7QGe7na7ZRHFm1/WeaYepRhvf7Q4QePCjX
B0ZTPwt0liQpRecZIwh615UmDVv5nd6wLJiNNQZqJQc+CMfeT1tzqr/nwuqfTJSz
wU1MeVBVaxKbpl+iOIDGu/nbXlcTsNSE0gKieTuLFcoHOmXyKDwbF27+s2vt0TkK
oBwJZWZVCQRHTMCLSRc/iAaQnV6zjQpeRPVxyd8fzuLedcArKYGDQsgvpPP7Gycy
yxPuJHc5q5Q5LiHVYkcMQ1FzzGTKy7U0b5MIkm6es6qMutPTOM3CA7BA6fuGDgw=
=qKpD
-----END PGP SIGNATURE-----

gpg: Signature made Wed Oct 12 23:38:26 2011 JST using RSA key ID 73E3B6AC

gpg: Good signature from "Shota Fukumori <sorah@tubusu.net>"

追記2: リンク先だけ抜粋しときます

http://anond.hatelabo.jp/20111006234714

http://twitter.com/i315

http://twitter.com/Glass_saga/status/124131595606167554

2010-06-10

http://anond.hatelabo.jp/20100610112133

その解析に、現存するPCでは生きてるうちに終わらない程度の演算が必要であればいい。

なるほど。指定ツールでのビルド時にRSAとかでキーを生成しして自作ゲームバイナリに埋め込むわけですね。

でもそれってコピーしたゲームソースを、その指定コンパイラを使ってリビルドしてキーを付加すればいいだけ

なんじゃないかな。キー生成がブラックボックスでもコピー+キーは生成できちゃうような。

ばらまく人に「指定ツール導入」&「それなりの知識」という負担が増えるから多少はましな気もしますが、現状でも

ROMから抜くのはど素人じゃできないわけで、そんなに難しい話じゃない気が。

まあ、こういう方法があるのに、それをやらない、というなら自作文化はその程度の代物だった、ということで、

より納得しながら、滅びるのを眺められますw

PARは別に違法性ないよね? メモリ改造ツールはマジコン問題とは切り離していいんじゃないかな。

2009-10-28

Rubyを最大63%高速化した中学生

@ITにて、@ITの「Rubyを最大63%高速化した中学生は超多忙!」というインタビュー記事が公開されています。

これまで、Lispの“仏さま”竹内郁雄氏、東大博士課程の女性プログラマ五十嵐悠紀氏、プログラミング言語Cyanを開発した高校生 林拓人氏、その続編(「国語ができる(=日本語できちんとした文章が書ける)人じゃないとプログラムは書けない」という竹内郁雄氏の発言の解説)に続く、連載物の一つである。

今回の記事の筑波大駒場付属中の3年生金井仁弘氏は、/.Jでも告知があった「セキュリティ & プログラミングキャンプ 2009」に参加し、Ruby1.9Ruby1.8よりフィボナッチ数列計算で低速化しているのに着目、構造体の判定メソッドの一部をループの外に出すことで最大で約63%、全体で約8%の高速化に成功したと言う。また「RSA解読のためのフェルマーの小定理の証明」を授業で行っているなど、色々と興味深い内容だ。

皆さん、中三の夏に何してました?

2008-07-23

OpenSSH の Fingerprint を AA にする新機能を試してみた

OpenSSH に "Fingerprint ASCII Visualisation" という機能がついたらしい

http://www.st.ryukoku.ac.jp/~kjm/security/memo/2008/07.html#20080722_OpenSSH

多分。サーバの公開鍵の Fingerprint をアスキーアート化して、そのビジュアルを覚えてサーバなりすましを防ぎましょう!という技術だと思います。但しexperimental。

とりあえず手元で make してみる

$ tar -zxvf openssh-5.1p1.tar.gz
$ cd openssh-5.1p1
$ ./configure
$ make

Macでも問題なくmakeできた。

VisualHostKey オプションデフォルトオフなのだけど、設定変えるのが面倒なので ssh に -o "VisualHostKey yes" オプションをつけて起動してみる。接続先は普段使ってるホストで。

$ ./ssh -o "VisualHostKey yes" ***.###.%%%

結果、こんな風に表示された。

Host key fingerprint is 
   _,,....,,_  _人人人人人人人人人人人人人人人_
-''"::::::::::`''>93:e6:d0:6b:75:6d:22:be:d8:7f:11:ad:50:dc:16:6f<
ヽ::::::::::::::::::::: ̄^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^ ̄
 |::::::;ノ´ ̄\:::::::::::\_,. -‐ァ     __   _____   ______
 |::::ノ   ヽ、ヽr-r'"´  (.__    ,´ _,, '-´ ̄ ̄`-ゝ 、_ イ、
_,.!イ_  _,.ヘーァ'二ハ二ヽ、へ,_7   'r ´          ヽ、ン、
::::::rー''7コ-‐'"´    ;  ', `ヽ/`7 ,'==─-      -─==', i
r-'ァ'"´/  /! ハ  ハ  !  iヾ_ノ i イ iゝ、イ人レ/_ルヽイ i |
!イ´ ,' | /__,.!/ V 、!__ハ  ,' ,ゝ レリイi (ヒ_]     ヒ_ン ).| .|、i .||
`!  !/レi' (ヒ_]     ヒ_ン レ'i ノ   !Y!""  ,___,   "" 「 !ノ i |
,'  ノ   !'"    ,___,  "' i .レ'    L.',.   ヽ _ン    L」 ノ| .|
 (  ,ハ    ヽ _ン   人!      | ||ヽ、       ,イ| ||イ| /
,.ヘ,)、  )>,、 _____, ,.イ  ハ    レ ル` ー--─ ´ルレ レ´

Password:

確かにFingerprintがAAで出てきた。これは覚えやすい。

別のホストにも接続...

$ ./ssh -o "VisualHostKey yes" ***.###.%%%

結果

Host key fingerprint is ff:fb:f0:43:c4:85:9f:70:16:7d:d8:f1:7d:dc:79:53
      ,,,,,,pxxvxxg,,,,_
   ,,df(^"゛ g、    ^゜゜lq
  〈!   ,,dl゜゛   ./==x]t,,_
   ]l.__,,g[,,,,,,,,,,,,,,p4"   .l[^k
   ][「,,pr=t、`、  ____ .l[ ]
  g" ][_  ]!  ./「゜^゜9,,「n,,]
 4゜ .。、.\イ   ゜lk ,,g[  .l]
 ]l. 〈^゜ltn4,,,,_        ]
 ヨ。. ゜ll._   ゜"9n......./ff  ]
  ヨ、.\q,,,,____   ,,gf゛ gl゜
   ^9nnxxxxx゜゜゜゜゜゜゜゜゜゜xvtf"゛

Password:

なんかこわい!

$ ./ssh -o "VisualHostKey yes" ***.###.%%%

結果

Host key fingerprint is 36:fc:e6:85:b7:f5:22:7e:45:f4:d8:5d:5d:f4:83:86
+--[ RSA 1024]----+
|                 |
|.. .o  .         |
|...o.            |
|    . o . .      |
|   + E + * +     |
|  o +   S =      |
| . . o   o .     |
|  ... o * o      |
|     . .         |
+-----------------+

Password:

ネットハックかよ!





ちなみに最後のだけホント。

2008-06-17

キモい趣味

20代半ばの理系な男ですが、合コンとかで初対面の人に趣味を聞かれたとき、

無難に「読書映画」と言ってしまいます。

でも実は人には言えないキモい趣味を幾つか持っているので、

これが、どれぐらいキモいのか判別お願いします。

素因数分解

趣味歴4年。

数ある素因数分解法をプログラミングで実装したり、

新しい素因数分解法を考えたりしています。

現在は数体ふるいに目処が付き、楕円曲線法に興味があるところです。

目指すはRSAチャレンジ

将棋

趣味歴3年。

主にハンゲームでやってます。300戦ほどして、勝率は6割ぐらい?

定石を覚えつつ、勝ったり負けたりの毎日。

(ハンゲだと終盤の詰め力が身につかないので、どうもなぁ…)

ネット将棋じゃ強くなれないのかと思って、将棋教室に通いたいと思っているのだけれど、なかなか機会が……。

小説

趣味歴1年。

書きたい物語を溜め込む毎日。

プロットの書き方などは知らず、ただ駄文を書き連ねています。

誰にも見せないし、どこにも発表する予定は無いです。

以上3つです。土日はこの趣味で、生涯の研究課題素数、遊び=将棋妄想小説 としてパソコンに向かっています。

やっぱりどれも初対面の相手に言うべきことじゃないですよね………。

2008-04-22

フィッシング詐欺組織トロイの木馬を併用する新攻撃

EMC傘下のセキュリティ企業RSA4月21日、「Rock Phish」と名乗る犯罪組織フィッシング詐欺トロイの木馬を併用した新たな攻撃を仕掛けていることが分かったと伝えた。

 RSAによると、Rock Phish欧州を拠点とする犯罪組織で、2004年以来、金融機関を狙ったフィッシング詐欺を仕掛けている。RSAの推定では世界各国で起きているフィッシング詐欺の50%以上はRock Phishが関与。ユーザーをだまして偽サイト入力させたパスワードなどを使って、銀行口座から現金を盗み出している。

 今回この組織が、新たに「Zeus」というトロイの木馬の亜種を使い始めたことが判明したという。スパムなどから偽サイトに誘導されたユーザーは、そこで銀行口座などの情報入力しなかったとしても、知らないうちにマルウェア感染させられる。

 Zeusは感染したユーザーコンピュータから個人情報などを収集し、外部に送信するトロイの木馬。これまでに150種類以上の亜種が出回っている。

 しかも今回のケースでは、Googleを思わせるURLを使ってマルウェアホスティングされているため、セキュリティソフトも通過してしまう可能性があるとRSAは伝えている。

SEOスパム 検索スパム

SEO スパム

 
ログイン ユーザー登録
ようこそ ゲスト さん