「RSA」を含む日記

■anond:20250104180455

おう、頑張れq(*･ω･*)pﾌｧｲﾄ!

色々調べると、どうやらRSAの週15時間労働義務は

マクロン大統領の選挙公約である「完全雇用の実現」という政策目標に沿った措置の一つのようで

RSAの支給条件を厳しくすることで、社会保障費の増加を抑える狙いがあった可能性も出てきた

はてブでは有力説だった「これは支援ばっかり受けてないで働け、という目的の制度ではない」のほうはかなり怪しくなってきたので

このまま埋もれてしまわないように是非盛り立ててほしい

Permalink | 記事への反応(0) | 13:22

ツイートシェア

■anond:20250103234318

KSM News ＆ Research(パリに拠点を置く翻訳者·通訳者のエキスパート集団が発信するニュースメディア)も

『マクロン政権は、完全雇用の実現という政策目標に沿った一連の措置の一つとして、RSAの支給条件を厳しくする改正を計画』

『新制度においては、社会給付の窓口や失業保険管理機関、職業安定機関などの関連部署のすべてが就業支援の目標に向けて協力し、受給者に対しては、それぞれの需要や必要を見極めつつ、週15時間以上の活動（トレーニングなど含む）を義務付ける契約を結ばせることになる』という記事を発信しているね

記事によると、試験導入でめざましい就業率の向上があったみたいだし、週15時間以上を義務づけるといってもそれなりの配慮はされるっぽいから、悪い政策ではないのかもしれないけど

『完全雇用の実現という政策目標に沿った一連の措置の一つとして』行われるというのが、労働参加強化の政策の目的·方向性であり

生活保護に関わるすべての部署が『完全雇用の実現』という政策目標へのコミットを強く求められることになるということなら

就業目標の達成という数字ありきで福祉が歪み、強引に労働契約結ばされる運用実態になるのでは、という懸念は当然抱くし

慎重に複数のニュースメディアに当たれば当たるほど

「これは所得保障に甘んじてないで働け、という目的の政策ではない」というブクマカの見立てはやっぱり違うのではないか

むしろ、「所得保障の条件が甘いから働かず就業状況悪い」という問題の克服こそがこの政策の主目的、という見立ての方が合っているのでは、としか思えなくなっていく

Permalink | 記事への反応(0) | 02:00

ツイートシェア

■anond:20250103215410

そもそもフランスの現行生活保護「RSA」の前身となるRMIは

The Japan Institute for Labour Policy and Trainingのレポートによると

『受給者が就職した場合就労所得のすべてが手当てから減額される制度であったため、就職したが故に世帯収入が減少してしまうことがあり、働かずにRMIを受給し続けるケースが増加、受給者の社会復帰率の低下が問題となっていた』で

『そこで働かずに生活保護を受けるよりも、少しでも働いた方が収入増につながる制度、すなわちアクティベーション型の制度として登場したのがRSA』らしいから

「支援ばっかり受けてないで働け、という目的の制度ではなく、社会への復帰支援を目的とした労働義務なので良い」ってコメントがなにやらめちゃくちゃ人気のようだけど

制度の成り立ちや方向性からして

「支援ばっかり受けてないで働け、という目的の制度」でしかなく、それが強化されましたよという話でしかないと思うんだよね

Permalink | 記事への反応(0) | 22:12

ツイートシェア

■anond:20250103161518

https://www.aide-sociale.fr/reforme-rsa/

The most important consideration that will be required of beneficiaries of the SSA is the obligation to “work” at least 15 hours a week.

This obligation shall be fixed on a range of 15 to 20 hours of professional activity.

In other words, the RSA shall be paid provided that a minimum of 15 hours of weekly activity is carried out.

うーん、素人が検索して拾い読みしているだけだが、「RSAが週15時間の労働を条件に支給されるようになった」のは今年からなのでは？Togetterのまとめに大きな問題はなさそうに思えたが。

こちらは素人なので識者のコメントがあると有難い。

Permalink | 記事への反応(1) | 16:25

ツイートシェア

■anond:20250103160724

https://www.sortiraparis.com/en/news/in-paris/articles/239100-what-s-changing-in-january-2025-unemployment-traffic-transport

この記事ではRSA reformのところかな

Permalink | 記事への反応(1) | 16:11

ツイートシェア

■anond:20250103160303

https://www.parisettoi.fr/news/20240819-003

RSAは元来、受給者への就業奨励を建前とする給付だったが、受給から抜け出せなくなる人が多いことが問題視されていた。

「建前」と書かれているが、これはどういうニュアンスなんだろう。教えてくれると助かる。

Permalink | 記事への反応(1) | 16:07

ツイートシェア

■anond:20250103152718

ブクマカが「Togetterまとめに書いてある程度の偏ったチョイ情報で良し悪し語っている」と決めつける態度がおかしい

RSAの労働契約義務が今年始まったばかりのものだと勘違いしてるコメが多かったのって、Togetterまとめのタイトルが「今年から」だったことに(実際は15年前のRSAスタートした時からずっとです)かなり引っ張られていると思うのだけど

このレベルの勘違いしたまま、それを指摘し正すこともできないままのブクマカに複雑な生活保護問題の是非判断ができると思うか？

Permalink | 記事への反応(2) | 15:39

ツイートシェア

■anond:20250103140258

元増田は特に触れてないけど

フランスでRSAが導入されたのは2009年で、その当時から「労働参入契約義務」はあった

だから、元増田のリンクにあるような調査データや研究文がすでにあるわけで

Permalink | 記事への反応(0) | 14:28

ツイートシェア

■anond:20250103135851

理念どおり行くとは限らないから社会実装まで見なければいけないと言いたいなら大阪市に結び付けなくてもフランスのRSAの紹介だけでよいということでは

Permalink | 記事への反応(1) | 14:02

ツイートシェア

■anond:20250103130206

というより元増田の文脈は「赤旗に同調して叩いているブクマカ憎し」だから「パソナを叩くならフランスのRSAも叩かないとダブスタだろ」という主張のためにRSAを悪く書いているのであって

元増田の思考としては「自分はパソナを叩きも賞賛もせず意見保留／フランスに対しても叩きも賞賛もせず意見保留／だがパソナを叩くブクマカお前たちはフランスも叩かなければダブスタだぞ」なんだろ

根本的な議題への自分の意見は表明せずメタ議論したいだけ

Permalink | 記事への反応(1) | 13:08

ツイートシェア

■anond:20250103004001

ザックリ言うと、赤旗が批判した「違法な指導」、「派遣業者への利益誘導」が

フランスのRSAを日本に導入することで

違法な指導は合法化なものになり、派遣業者への利益誘導が全国的に大手を振るうようになるってこと

つまり、大阪×パソナの就職サポートと

フランスパリの「民間の派遣会社から行政が買い取った派遣ポストへ余すことなくRSA 受給者の就労先としてあてがう」べく「RSA 受給者に対して，派遣先への就職を参入契約に盛りこむ」は極めて近いことをしているわけだから

一方を賞賛して、一方を邪悪と呼ぶのはダブスタになるってことだね

Permalink | 記事への反応(1) | 00:46

ツイートシェア

■大阪市のパソナ生活保護就職サポート事業は叩いたのに

フランスの就労指向型生活保護システムを絶賛するブクマカさんは

無知なのか、ダブスタなのか、欧米無条件礼賛思考なのか知らないが、フランスの実態をあまりに無視しすぎている

では、実際にフランスの生活保護の現場では何が起きているのか、見てみよう

https://www.jstage.jst.go.jp/article/spls/8/2/8_20/_pdf/-char/ja

RSA 法上に現れた就労促進的方向性は，現場

レベルでは実際にはどのように対応されているのだろうか

パリの事例をもとに就労促進的性格の具体的な現れを検討する

ソーシャルワーカーにとって，担当する地区の労働市場の動向や，具体的な雇用政策の内容を十分に把握し，専門的に就労支援を行うことは困難である

具体的にどのような就労支援が実施されているのだろうか

筆者の調査時に開かれた CTI の議題は，「RSA 受給者への派遣業務提供事業をどのように効率よく実施していくか」ということであった。

すなわちパリは，今後２年間（当時）で，1000人分の派遣ポストを民間の派遣会社から購入することになっていた。行政が買い取った派遣ポストへ余すことなく RSA 受給者の就労先としてあてがう

　この雇用政策が実施に移される段階で，ソーシャルワーカーは RSA 受給者との面談のなかで，派遣労働可能な RSA 受給者に対して，派遣先への就職を参入契約に盛りこむよう提案するのである。CTI では，当初５つの CTI に割り当てた派遣ポストが各 CTI 内で十分消化できているか監視する。不均衡が生じていれば，他の CTI との調整が行われ，こうして２年後にはパリが派遣会社から買い取ったポストが“無駄なく”そして“効率よく”消化されることを目指すのである

就労支援と言いつつ、実態は派遣会社から派遣枠を買う→それを「効率よく無駄なく消化」するために、生活保護受給者にあてがうべく調整が行われ、受給者は参入契約を盾にとられるので最終的に抗えない

この行政と民間斡旋業者の取引によって、さて何が起きるだろうか

条件の悪いブラックな派遣案件を扱う業者に公金が流れ、劣悪なブラック職場は温存され、労働市場全体の質が低く保たれるという弊害が起きてしまうのだ

他にも、上記リンクの寄稿では、このような興味深いことも書かれている

基礎 RSA では37％，そして活動RSA では12％が，フルタイム労働時間の半分に満たない超短時間労働に従事している状況である。

超短時間労働者率が全被用者の７％でしかないことにかんがみると，基礎 RSA の超短時間労働者は圧倒的に多いと言える。

　しかもこのような短時間労働への従事が大半の場合，本人の希望に反してなされている。先のDARES 調査によれば，基礎 RSA の短時間労働の88％が，そして活動 RSA でも短時間労働者の74％の人が，「希望する労働時間よりも少ないためもっと働きたい」と望んでいるのである。

早い話が、自立できるようなまともな仕事は斡旋されず、スキマバイトの売れ残りのようなものを弱い立場の人に押し付ける、みたいな構図なのだ

さて、ここまで色々言ってきたが「受給者の分際で選り好みするな働け」という意見で一貫してるならまだいいのだ。一理はあるから否定はしない

しかし、だ。ここで思い出してほしいのだ。ブクマカによる大阪パソナ生活保護就職サポート大叩きを

https://b.hatena.ne.jp/entry/s/www.jcp.or.jp/akahata/aik24/2024-11-21/2024112101_02_0.html

記事の内容を抜粋すると

失業で困窮して生活保護を申請した３０代男性は「再スタートを決めて最後のライフライン（生活保護）に頼りました。派遣生活で疲れ果て、安定した正規雇用の職をじっくり探したいと伝えたのに、パソナの派遣職員に『何でもいいから』と言われました」と絶望。「このままでは生活保護を開始できないと言われ、生活できないので、希望とは違う会社にも応募。

全大阪生活と健康を守る会の大口耕吉郎会長

「求職活動をしなければ保護が受けられなくなる」などの言葉で、利用者に「指導」を行う違法な事例も報告されていると指摘

「就職サポートの支援ミスマッチは数字を見れば明らかで、ただの大手派遣企業のもうけ口になっている」

なのだが

この赤旗記事に対して付いた人気ブコメが

「邪悪な仕組み」「官製貧困ビジネス」だったわけだが、ここで改めてフランス生活保護の現実を振り返ってみよう

①『何でもいいから』と言われました」と絶望。「このままでは生活保護を開始できないと言われ、生活できないので、希望とは違う会社にも応募」

②「求職活動をしなければ保護が受けられなくなる」などの言葉で、利用者に「指導」を行う違法な事例も報告されている

フランスのRSAを日本で導入すると、少なくとも①と②は違法でも問題でもなくなるのだ

なにせフランスの就労指向型生活保護では①が合法的に行われており、②も首都パリで同様のことが行われていたのだから

「フランス素晴らしい！真似しよう」と主張するなら、大阪パソナの事例は当然導入後は叩けなくなる

また

③「就職サポートの支援ミスマッチは数字を見れば明らかで、ただの大手派遣企業のもうけ口になっている」

も、パリの事例と「基礎 RSA の短時間労働の88％が，そして活動 RSA でも短時間労働者の74％の人が，「希望する労働時間よりも少ないためもっと働きたい」と望んでいるデータがあることから

フランスのRSAでも起きていることであり、「フランス素晴らしい！真似しよう」と主張するなら(以下略

◆結論

まあ、結局「日本でもフランスでも制度理念や目的だけは素晴らしい制度ってあるんですよね、色々と。でもそれだけで良し悪しを判断したらダメだよね」ってことなのだ

散々揉めた高プロや裁量労働制だって、政府の主張する理念や目的だけを聞くと「全然悪くないもの」に聞こえなくもないのだ

でも、だ。こういう制度は「実際に社会にどう実装されて、どんな副作用が起きうるか」までしっかりみて検証しないと、良し悪しの判断なんて到底できない

その当たり前の意識がブクマカさん欠けてませんか？と問いかけたところで、この話を一旦締めたい

Permalink | 記事への反応(10) | 00:32

ツイートシェア

■anond:20240629085310

Akiraの場合

Akira Ransomwareは、近年特に注目されているランサムウェアの一つで、その動作は高度で多様な手法を取り入れています。以下に、Akiraランサムウェアの動作について詳しく説明します。

動作の概要

侵入経路

Akiraは主にフィッシングメール、リモートデスクトッププロトコル（RDP）の悪用、既知の脆弱性の悪用などを通じてシステムに侵入します。特に、未修正のソフトウェアやシステムの脆弱性を狙うことが多いです。

初期感染と展開

システムに侵入すると、Akiraはネットワーク内で横移動を試みます。これは、ネットワーク内の他のデバイスにも感染を広げるためです。横移動には、認証情報の窃取や利用可能なネットワーク共有の探索が含まれます。

暗号化プロセス

ファイル暗号化の前に、Akiraはターゲットシステムの特定のディレクトリをスキャンし、暗号化対象のファイルをリストアップします。次に、強力な暗号化アルゴリズム（通常はAESとRSAの組み合わせ）を使用して、ファイルを暗号化します。

最近のバージョンでは、部分的な暗号化手法（インターミッテント暗号化）を採用することで、暗号化速度を上げつつ、検出を回避する手法が確認されています​ (Bitdefender)​。

データの窃取

暗号化に加えて、Akiraは重要なデータを盗み出し、そのデータを公開することで二重に脅迫することがあります。これにより、被害者に対する身代金要求の圧力を強化します。

身代金要求

暗号化が完了すると、被害者のデスクトップに身代金要求メッセージが表示されます。このメッセージには、データを復号化するための手順と支払い方法が記載されています。通常、暗号通貨（ビットコインなど）での支払いが求められます。

特徴的な技術

RustとC++の利用

Akiraの一部バージョンはRustというプログラミング言語で書かれており、これによりコードの安全性が向上し、セキュリティ研究者による逆コンパイルが難しくなっています。また、C++で書かれたバージョンも存在し、多様な環境での実行が可能です​ (CISA)​。

VMware ESXiの標的化

Akiraは特にVMware ESXi仮想マシンを標的とすることが多く、これにより企業の仮想環境全体に影響を与えることができます。

多層的な攻撃手法

Akiraは単純なファイル暗号化にとどまらず、データ窃取やネットワーク内での横移動、他のマルウェアの導入など、多層的な攻撃手法を組み合わせています。これにより、攻撃の成功率を高め、被害者に対するプレッシャーを強化します。

Permalink | 記事への反応(0) | 09:00

ツイートシェア

■anond:20240309075252

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

Permalink | 記事への反応(1) | 13:57

ツイートシェア

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

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

Permalink | 記事への反応(1) | 23:36

ツイートシェア

■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

Permalink | 記事への反応(0) | 01:40

ツイートシェア

■anond:20210718103715

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

Permalink | 記事への反応(0) | 15:54

ツイートシェア

■メインストーリー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章で同じようなことされたらブチギレると思います。すみません既にマスターシェフと茨の信奉者の件でキレてます。

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

Permalink | 記事への反応(1) | 05:23

ツイートシェア

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

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

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

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

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

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

でも示し方が最悪。

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

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

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

でも5章は？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Permalink | 記事への反応(1) | 13:30

ツイートシェア

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

anond:20200608212713

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

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

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

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

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

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

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

⑤数学的な仕組みの説明

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

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

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

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

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

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

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

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

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

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

・パスワード１で暗号化したものがパスワード２で復号できるだけでなく、その逆つまりパスワード２で暗号化したものがパスワード１で復号できる（※）

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

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

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

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

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

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

応用的な利用

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（サーバ証明書）

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

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

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

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

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

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

Permalink | 記事への反応(1) | 20:11

ツイートシェア

■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つだったのか?

Permalink | 記事への反応(0) | 21:33

ツイートシェア

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

• 上記配列は日本開催の時にしたが、順位はそのまま。
• 国・地域名の表記は https://www.joc.or.jp/games/olympic/code/ に拠ったが、右記は変更した:「西サモア→サモア」「英領→イギリス領」「米領→アメリカ領」
• 日本語文字列照合順番になってたらいいなあ。

Permalink | 記事への反応(0) | 23:03

ツイートシェア

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

anond:20170911232449

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

こんにちは。

試験、受けました。

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

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

プロフィール

30代。

普通科高卒。

製造業。

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

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

言語はVBA、VB、バッチ。

一ヶ月に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割くらいは過去問の流用で問題ができあがる。

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

午後の対策が難しい。

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

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

• 過去問を解く(試験本番で選択する時間を考え、制限時間は1問につき30分ではなく、29分くらいにする)
• すぐに答え合わせはせず、問題文に何が書いてあるか、頭の中で具体的にイメージできるようになるまで、時間をかけて読み込む
• 制限時間ありの解答と、なしの解答を並べ、先ほど出来上がったイメージから論理的に正誤の判断を導けるようにする
• 答え合わせをし、自分の作り上げた論理と他人の論理が乖離していないか確認する
• 以下、繰り返し

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

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

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

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

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

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

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

ってことですかね。

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

はぁ…10万欲しいなぁ…

以上で終わりです。

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

お疲れ様でした。

Permalink | 記事への反応(1) | 23:57

ツイートシェア

■anond:20160426145507 の続き

anond:20160426124418 と anond: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 の実装がすべてセキュアだというのではありませんが、たいてい問題は少ないです。こうしたシステムは通常、次のふたつのアプローチのどちらかに従っています:

• ユーザが自分のアカウントに直接アクセストークンを生成できるようになっており、そのトークンを自分の統合したいソフトウェアに自分で施すことができるので、ばかげた要求や危険な転送やリダイレクトを回避できる。
• client_secret が、一般的なパスワードのように平文のまま渡されるデータとして機能するのではなく、それ自体では暗号学的な共通鍵であり、そこから認証コードを生成するようになっているシステムなので、ばかげた要求や危険な転送やリダイレクトを回避できる。この種のシステムでは一般的に、ユーザが自分の認証情報さえ持っておらず、SSO (シングル・サインオン) の仕組みを使うだけである。

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

他の選択肢

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

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

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

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

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

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

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

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

他に使われている技術は、サードパーティがどんな権限を必要としているかをある種の XML や JSON ファイルで定義してウェブサイトに送信できるようにするサービスのものです。ユーザがあるページを自分のアカウントで訪問し、ファイルの 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/

Permalink | 記事への反応(2) | 15:03

ツイートシェア

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

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

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

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

長すぎ；読まない

ECDHとAES256-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.0 や SSL 3.0 を有効にしているそこのあなた、今すぐ無効にしましょう。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CBC も CBC-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 サーバーで確認できない形に暗号化されるとメッセージの配送ができなくなるため、通信相手や通信の有無については秘密ではないと考えられます。

Permalink | 記事への反応(0) | 00:27

ツイートシェア