「RoOT」を含む日記 RSS

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

2022-03-14

スマホに一番ハマってたのが12年くらい前

当時はiPhoneSMSするのが新鮮だったしAndroidroot取ってADBするのが面白かった

最近スマホガジェットとしての新鮮さがない

2022-03-13

テレワークでも猿から進化できない職場

ID管理ができてない、面倒だからrootを全員に配る

ネットワーク管理ができてない(WIFIが遅いとか2年ほざいてる)

・その割に監視ソフトは真っ先に入れて興奮する

から進化できないなあ

2022-02-19

派遣バイトrootパスワード教える現場

「ロールベースアクセス制御」というのを聞いたことがないのだろうか?

例えば、「メール管理者」とか「バックアップ実行者」みたいな区分だ。Linuxならカンタンに設定できる。

派遣バイト操作を間違えないように、正社員はそのたびに席を立って後ろから確認する。

馬鹿すぎてあきれてしまったw

部長にハンコ承認依頼を出すための課長のハンコ承認申請」とかのほうがまだ可愛げがあるわw

2022-02-12

Android端末買ったら店員に有料セキュリティソフトの導入を強く勧められたのだが本当に必要なのか?

わからんのでここで聞いてみる。

曰く、androidオープンソースで公開されているから狙われまくりとのこと。

その店員さん自身の使っているセキュリティソフトを聞くと、聞き覚えのある大手ソフトだった。

端末の用途としては電子辞書を読むのとWebサーフィンぐらいでさほど危ないことはないつもりではある。Webブラウザ経由で感染するウイルスがあったらダメだが。

もしくは、無料ので足りるならそれもアリだが…無料も山程合って下手に選ぶと逆に危険ではありそうだ。幾つか聞き慣れたのはあるが、しかしそれはWindowsでの話であってandroidでも優秀かも分からない。

判断付かないなら年額数千円のを入れた方がいいのだろうか?

2/13追記

ありがとう不要なのか。確かにandroidってWindowsに比べ操作の制約厳しい気がするから強いのだろう。

けれどroot権限奪取の脆弱性も時々出いるなのでそういうのに当たらないように祈るしかいかな。

2021-11-14

すげー頭悪い運用システムあるある

Root権限しかなくて全メンバーに使いまわさせる

 → ID付与してログ監査すれば確実という発想がなく、何かトラブったら誰がやったかからない

踏み台Windows場合、RDPのバージョン10年前の7.0でクソ遅いカクカク描画のまま

 → 10.0にすればGPUレンダリングになってスムースになるのだがその知識がない

馬鹿って哀れだなと思った

2021-10-22

anond:20211022075231

rootパスワードなので危険だ!ということで常に3人横に並んで作業する

2人はぼーっと座ってるだけ

anond:20211022074238

ID設計すらしてなかったようでrootパスワードを30人で使いまわすというヤバすぎる案件なら知ってる

2021-10-05

anond:20211005111218

ぺるまちがっとるぞ・・・

だけど、ホントあれは苦痛。せめて root に対抗したかったら admin にしとけよ と思ったわ

2021-08-26

(root) Additional property {service-name} is not allowed

ドッカー今ポーズ?とかいうのがうごかなくなった

何もしてないのに壊れた。と言いたいところだけど多分こないだドッカーをアップデートたからだとおもう

でもあっぷでーとしただけでこわれないでほしい

ググったけいつものようにろくな情報が出てこない

ITってさマジでろくな情報ネットに転がってねーよな。あるかもしれんけどグーグル検索ゴミすぎてヒットしないっていう

とりあえず念力でdocker-comppose.yamlおかしいかもしれないと当たりをつけた。

{service-name} っていうサービスyamlにとうろくしてるんだけど、なんかの手違いでこのサービスの値をうまく読み込めていないのだろうと、直感だけで決めつける

そんでとりあえずyamlふぉーまっとをググってみてくる。

へいしゃかんきょうのファイルyamlルート空間直下サービスをチョクで併記する感じなのだが、ネットで出てくる参考記事にはservice: 要素でくるんでいる

今まで動いてたのが動かなくなるの死ねって感じなので死ねって祈りながら、とりあえずservice:要素をルートに追加して、いままでトップレベル野ざらしにしてた各種サービス要素をservice:の下に入れる

docker-conpose up -d

実行で無事動作しました。

ドッカーアップデートするのいいけど設定ファイル読み込みの後方五巻壊すんじゃねーよかす

なんでいつもいつもエスパー能力使わないと行けないんだよ。このていどの記事ネット上に置いとけバカちんが

2021-08-25

Almost all countries take root of English

英語初心者も、ある程度英語を覚えれば、英語話者が読んで感心するようなネイティブ英語を学びたい、と思うのは当然だ。教科書試験用の英文はたいていは文法理解をメインにしており、多くても数段落文章で、いわゆる物語レポートの全体ではないから、それで文章構成作法を学ぶのは難しい。わずかに学術界むけに英語論文の書き方の参考書があるのと、一般向けの、手間がかかりそうな洋画脚本対訳本と、その他に文学対訳書が少しあるぐらいだ。大手出版英語書は多くは教科書参考書の類、以前あった文学対訳書が専門の出版社も、もうなくなってしまった。多くの諸国根付いている英語利用が日本根付かないのは、何が障害なのか。

Use of English takes root in most of the countries in the world. But it seems not in Japan. What are the obstacles in it?

2021-07-26

PCI Express Root Portの警告がイベントビューアを16連打するせいでPCプチフリする

止め方わかった

プライマリ デバイス名: PCI\VEN_8086&DEV_9D14&SUBSYS_07671028&REV_F1

とあるので、デバイスマネージャで表示(V)から接続順にして「PCI Express Root Port」で「9D14」と名前のついてるものPCI Express Root Portごと無効にする

PCI Express Root Portの9D14に繋がっているデバイスではなく、PCI Express Root Portの9D14そのもの右クリックしてプロパティから無効化する

これを警告が出て困ってるデバイスすべてに対して行う

結果的ノートPCセカンドグラボRADEON)と無線LAN無効化する羽目になった

ちょっとした3Dゲームゲームプログラミングもできなくなってめっちゃ不便

ノートPCでそんなもんやるなというご指摘はまあそりゃ心底ごもっともだが色々あったんだよ、次はちっちゃくてもデスクトップマシン買う予定

前の増田こちら→ anond:20210722160252

2021-07-22

過去1時間に12460のシステム警告

イベントビューア曰く1秒間に20くらいの警告イベント

修正されたハードウェア エラーが発生しました。

コンポーネント: PCI Express Root Port

エラー ソース: Advanced Error Reporting (PCI Express)

プライマリ バス:デバイス:機能: 0x0:0x1C:0x4

セカンダリ バス:デバイス:機能: 0x0:0x0:0x0

プライマリ デバイス名:PCI\VEN_8086&DEV_9D14&SUBSYS_07671028&REV_F1

うん、ノートPCマザボの近くで物理的になんかアレな雰囲気パームレスト付近を強く押したり本体ゴンと衝撃強めに置くといろいろ起こる)

これ記録行為無効にできないかなあ

これ起きるとシステム動作10秒くらい止まるんだよね

2021-06-25

ラッキング下準備

まず、基本となるLAMP自鯖を作って出来る限りのセキュリティを施すナリ

これでLinux系鯖の基本くらいは理解できるようにならないと侵入してもやることが無いナリ

次はツールの使い方を覚えるためにKaliLinuxとかを使って何とかして自鯖セキュリティを破って侵入するか

自分SQLインジェクションとかXSSとか書いて侵入するナリ

なお、簡単に入れる鯖はセキュリティ意識低いので拾ってきたバックドアでも問題無いナリ(例えばrootパスデフォ設定の所とか)

ここまで来たら後は近所の無線をaircrack-ng等でカラッキングtor+tsocksかproxychains辺りを使って恒心するナリ 

2021-05-18

[]打ち消されない

打ち消されない/can't be counteredという効果は、呪文能力が打ち消されることを防ぐ効果である

解説

「打ち消されない」という効果は、「〜〜を打ち消す」という効果を持った呪文能力によって打ち消されることを無視する。

基本的には、打ち消しを得意とする青の対抗色である赤と緑のカードの持つ能力である。赤、緑に次ぐ3番手は青であり、最初印刷された最後の言葉/Last Word以後はしばらく登場していなかったが、呪文においては至高の評決/Supreme Verdict、クリーチャーにおいては真珠湖の古きもの/Pearl Lake Ancient以来定期的に現れている。黒は思考のひずみ/Thought Distortionでこの効果を持ち4番手となった。白はこの役割を持たない。

普通の打ち消しでは対抗できないため、打ち消し戦術を使う側は他の対処を考えなければならない。

打ち消し呪文対象にならないということではない。

例えば、突然の衰微/Abrupt Decayを対象に蝕み/Undermineを唱えた場合、蝕みの解決に際し、突然の衰微のコントローラーは3点のライフを失う。

テンペストスクラーグノス/Scragnothが最初に持った能力である

緑の打ち消されないカードはほぼ全てクリーチャーカードである。またクリーチャー呪文を打ち消されなくするカードも擁する。

打ち消されない呪文能力対処

以下には、打ち消されない呪文能力から受ける影響を低減する方向での対処例を示し、戦場に出てから対処する方法割愛する。

時間停止/Time Stopや精神壊しの罠/Mindbreak Trap、アショクの消去/Ashiok's Erasure等で呪文能力追放する。

造物の学者、ヴェンセール/Venser, Shaper Savantや粗暴な排除/Brutal Expulsion等で呪文バウンスしてしまう。

対象を取る場合、誤った指図/Misdirection等で対象を変更する。あるいは明滅やバウンス、呪禁やプロテクション破壊不能付与対象保護したり、立ち消えを発生させたりする。

文章変更効果により呪文ルール文章を書き換える。

事前にエメリアの盾、イオナ/Iona, Shield of Emeriaや翻弄する魔道士/Meddling Mage、呪われたトーテム像/Cursed Totem等で唱えられない・起動できない状況を作る。

事前からの切削や手札破壊マナ拘束等により、唱えるために必要な条件を奪う。

アーテイのおせっかい/Ertai's Meddlingで、呪文効果の発生を遅らせる(その後、対象不適正になった場合は立ち消える)。

過去ルール

かつては、対象を取る呪文能力不正対象になった場合解決時にルールによって打ち消されていた。(→立ち消え)

ドミナリア発売に伴うルール変更(2018年4月27日発効)により、不正対象である時はルールによって打ち消されるのではなく単に解決されないことになったため、対象をとる呪文能力が打ち消されない場合に使われていた「呪文能力によっては打ち消されない」という文章を「打ち消されない」とするオラクル変更が同時期に行われた。

この時期にルールによる打ち消しを防ぐ事ができる例外として、金粉ドレイク/Gilded Drakeが存在していた。現在ルール変更に合わせて、不正対象となっても解決される能力へと変更されている。

未来予知部族呪文が登場してから、一時樹根スリヴァー/Root Sliverの能力でそれらがルールにより打ち消されなかった時期があった。2008年1月オラクル更新で、これは「呪文能力により打ち消されない」に改められていた。

2021-04-14

anond:20210414004942

毎回アカウント発行するよりSSO運用する方が絶対に面倒だと思う、共用サーバーがそんなにあるとも思えないし使う人にroot投げて自分管理させれば良いのに

全員のアクセス必要ものがあるなら手作業せずに全員のアカウントざっと登録して初期パス入れてメール発射するスクリプトくらいPythonかなんかで書いておくと良い

2021-04-11

anond:20210411105124

え、そんな事可能なの?

スマホならまだしもPCなら自分root管理者なんだから、できないことなんてないと思うんだけど

2021-04-04

セクシー大臣みたいな人があんなに権限のある立場に居るのって、

イケメンで社内人気が高い2年目のペーペーに本番環境root権限を与えちゃってるような感じがする。

2021-02-07

活動自粛呼びかけるのに緊急事態宣言って必要か?

一枚の紙切るのに業務用の裁断機持ち出すような無駄を感じる。

テロウイルス蔓延を同じ道具で対処しようとする雑さが怖い

ありとあらゆる事を想定しているが故に権限が強すぎるんじゃないかね。

既存緊急事態宣言を廃する必要は無いと思うが、もう少し目的別で権限を細かく制限した簡易版を用意しとくべきだと思う。

ウイルス蔓延対策版の緊急事態宣言なら、施設徴発医療目的用途に限る、とかさ。

Linuxサーバ触るユーザー向けに全部root権限渡すような雑な運用は早急に止めるべきだと思う。

2020-12-27

私の土日を返して!

もう、年末差し迫った12/25の夜7時を過ぎた頃、お偉方からセールスフォースの設定に問題がないか確認しろとのお達しが来た。

はぁ?私、もう仕事収めて帰りたいんですけど?!むしろ寝たいんですけど!

今まで、私がどんだけ仕事してたのか知ってる??

年の瀬の金曜の夜7時を過ぎてから言う?お前やれよ!と、心の中で毒付きながらも、何にも言えない社畜

弊社のブラックぶりに泣きたくなる。

そして、セールスフォースと、この時期に漏洩公表した楽天殺意を覚える。

芸能人離婚みたいに年末の土日に公開して有耶無耶にしようとしたんだろうけど、めじ勘弁してくれー!

自分なりに情報収集検証

まず、2016年の設定変更?そんなのあったっけ??

2016年リリースノートを見る。そんな変更どこにもない。英語版にもない。念のため2020年まで見る。ない。

偉い人の見てるニュースほんとなん?

そんな問題あったら、とっくのとうにアメリカ問題になってんじゃね?とか思いつつ調べる社畜

と、こないだペイペイでもあったアクセス権?もしかしてこないだJPCERT から来てた、アクセス権のアレ?

そしてセールスフォースドキュメントを見に行くわけだけど、コレは…。

なんて見にくい!もっと親切に画像入れてくれー!しかも回りくどくて何回も繰り返しちゃう

外人でなんでこう言うので平気なんだろう?ガイドブックとかも文字だけで全然わかんないよね。

文字だけで脳内画像が浮かんでくる特殊能力でもみんな持ってんのか?

そして日本語だとリンク切れてたり、英語の方にしか乗ってない情報盛りだくさん。深夜に英語読むのって辛いよね。もう文字アラビア文字みたいに見えて挫折しそうになるよ。

そして、問題アクセス権にあることを友人からアドバイスで知る。

おバカな私はここに辿り着くまでに2徹しちゃったですよ。

無駄ゲストユーザーに詳しくなったよ!

そして。改めて状況を見ると、こんな基本の設定間違えるやついるかー!バカにすんなー!そして私の睡眠時間土曜日返せー!と偉い人の頭を片っ端から引っ叩いて回りたい!

ゲストユーザオブジェクトの参照権限与えるなんて、そんなバカいるの??

つーか、いたからこんな大ごとになってんだろうけど。

おバカな人たちご愁傷様です。

念のため共有設定を見直したけど、もちろん外部共有なんてしてなかった。(フォームなどは除く)

楽◯だのPay◯a yとか大丈夫

こんな基本設定間違ってるなんて他のサイトの基本設定も間違ってんじゃないの?よく恥ずかしげもなく公開できたな。

もしかして設定全部rootでやってたり、フォルダ権限777だったりScot.taigerとか残ってるんじゃね?とか思っちゃうよ。

とにかく私の土日返してくれ!でも、楽◯ポイント10万点ぐらいくれたら許すw

もしくは今日やる予定だった大掃除代わりにしてくれー!

2020-10-29

勝手死ぬな」「勝手に生きるな」と勝手に言われるし勝手に言う

要は自分が何を言いたいかというと健康診断検査つらい」なんですが。

それについていろいろと考察した長い文章が下に続いているだけ。

社会

日本人寿命が長いのって、国民皆保険があるからお金負担が安いことと、会社員が35歳以降に人間ドックを毎年受けることで早期発見治療しているかなのだろうか?人類医療で生かされてる(活かされてる)んだよな、健康的な意味でも、寿命的な意味でも。そりゃあそうだ。予防医学だよな。歯医者の定期健診を受ける、とか。

でも、トシくって様々な検査ちょっと辛かったりするのを目の当たりにすると、

検査をしたり医療を受けたりしてまでも生き永らえたいというモチベーションが、果たして自分にはあるのだろうか?」

という疑問が湧いてきてしまうのだよな・・・

積極的安楽死か、消極的安楽死か、なんか、そういうのが脳裏によぎる。

会社員でいる以上は、自分労働リソースとして供出しているのだから、その「労働リソースとして将来的にどのくらい使えるか」ということが会社的には気になるわけだし、あと法律で決まってるのかな?その辺の理由で、会社から言われたとおり健康診断を受けなきゃならない。「直せばまだ労力として使えるのならちゃんと直せ」というのが、営利企業や国力といった視点から論理と言えるだろう。

なんか、自分の体は自分だけのものじゃない」という感覚がする。「公僕」、会社社会の共有物かのような感じがする。

それは良いことなのか、悪いことなのか。

あ、検査がつらいんで受けません。安楽死しまーす。っていう自分の体に自己決定権利はないのかな。それ人道的にどうなのかな。

その「自分の体が自分のものじゃない」の最たるものが、家族意向により、胃ろうで生かされている人間でしょう。倫理的にどうなのでしょうか。かくいう私の親戚にもいます。こわいので面会していないです。いまはコロナで面会もままならないですが。

医学は、人為的に死をコントロールできる術です。進歩すればするほどコントローラブルな範囲が広がる。いずれは不老不死も実現するのかも知れない。

そのコントローラーを渡されて握るのは、本人であるべきなのか、他人であるべきなのか。自分というシステムroot権限は誰が持つのか。


えらい

それにしても、35歳くらいを超えてる会社員の全員がこういう検査受けてる、ってすごくないですか?

人によっては人間ドックを毎年サボってる常習犯が居たりして、まあ気持ちはわかる・・・ってなっちゃう。

医療体制がすごいのもあるし、検査にみんな耐えてるのえらいですよね。

医療進歩して検査負担を減らす改善継続的に行われていて、胃カメラを口から入れるとき不快感を減らすためにイカリングみたいな白い輪っかをくわえると、かなりラクになるんですよね。あれ。ノーベル平和賞でしょ。10年前に受けた時あんなのなかったし肩に注射麻酔してたんですけど、最近はのどスプレー麻酔になったし1時間麻酔切れるし、カメラ自体も細くなった。昔の胃カメラトラウマになってる人もいると思いますけど、いまだいぶ負担減ってるんで、バリウム飲むよりもラクじゃないかと思いますよ。


加齢と経済消費傾向

若い頃ってさ、なんか、さまざまな「リソース」というもの無限であるかのように錯覚していた。

言い方を変えれば「有限なリソース」という概念のものが頭の中になかったのかも知れない。

健康時間も、仕事にかけられる労力も、無限だと思ってたので、スケジュールも何もなくがむしゃらに働いていたような。

でも社会に出て、あ、いろんなものって有限なんだなって気づいて。そのリソース管理がすごく難しいことに気づいていった。

そして30を超えると、「自分健康寿命」というリソースの有限さをひしひしと感じるようになる。

若いころはモノを買うときお金の使い方がコスパばっかり考えていたように思う。安物買いの銭失いだ。

それはそれで「将来への投資」の考えがなさすぎる、貧者の思想だとは思うけど。お金に対してそういう貧しい考え方で育ってしまったのだから仕方がない。トシとっていってお金の使い方が少しはマシになったし、服にかけるお金がふえたりした。

トシを取ると自分寿命が頭の隅にチラつくので、コスパが多少悪くてもペイするように意識が変わっていっていると思う。

「いまは時期が悪い」とか言ってチャンスを見送っているうちに自分寿命のほうがなくなっていくからね。

たとえ時期が多少悪くても、じゃあいまやろう。お金をポンと出してやったぜ。と。

経済の話でいうところの「機会損失」って、商品在庫があるとか、買える機会とか、開催期間が限定されたイベントとか、そういう「外的な機会」の損失するかどうかを焦点にしがちに見えるけども、それだけじゃないんだな。外的機会がある間に、かつ、自分健康もなければならない。健康でなければ商品を購入して満足することができないから。

健康が不足していて機会損失も大いにあり得るわけです。「大切な推しイベントなのに風邪ひいていけなくなった」とか。

これっていうのは「推しは推せるときに推せ」「孝行したいときに親はいない」と通じるものがある。

から商売するのって、「ちょっと健康不安が出てきて、かつ、そこそこお金持ってる人」を狙うのが効率よさそうですよね。健康商品じゃなくても。

ゲスいですが。足元見てる。

そういうターゲッティングして商売してる人間自体も、いずれはその該当者になるんですよ。

自己決定

「おれは長生きしないんだ」つって、暴飲暴食してる人、ラク死ねると思うなよ。苦しむぞ。みたいな脅しツイートを見かけたりしますけど、まあ確かにそうなんですけど、それも安楽死があれば解決するんですよね。

日本における安楽死議論での反対派って「イジメみたいに同調圧力によって安楽死自己決定を促されてしま危惧ドグマにしてますけど、

すでに健康診断圧力によってつらい検査を受けさせられてる」現状があるので、たしかにそうかも。そうなるだろうなあとは思われます

自殺と他殺」という対比の概念がありますが、それと同じように「自生と他生」とでもいいましょうか。

どう転んでも、自分の体の健康維持や死についての決定権は、自分けが独占的・排他的に所有してはいない(できない)ようですね・・・。やはり自分の体は公僕性、公共物性を帯びているようです。それは国民皆保険であるから、国としては保険治療コストの高い病気をなるべく支払わずに済ませたいので、治療コストの高い病気にかかるリスクを下げておくための検査コストを支払っておく(強制的に受けさせる)ほうがトータルでコストが安い、という計算なのでしょうか。

他者圧力によって胃ろうで生かされてしまうようなことがある社会と、

他者圧力によって安楽死で死なされてしまうことがある社会

どっちがマシなんですかね?

同調圧力存在すること自体は不変なんですね。


勝手死ぬな」

勝手に生きるな」

勝手に言われるし、勝手に言う。

介錯してラクにさせてあげたほうがいいんじゃない?とも思うし、

もっと生きたかったんじゃない?とも思える。

人為的に死をコントロールできてしまうということは、サバイバーズ・ギルトってやつが生まれる。生存者の罪悪感。

面倒なことにならないように、自分の生死を他者人為的コントロール下に置かれることが無いようにしたいですね。

やっぱ自分コントローラ握って健康診断うけるかどうか決めたり、コロっと安楽死理想なんですよ。でもそれって一貫性としては、このコロナのご時世で「公衆衛生を省みない自分勝手自由な行動に出ることの許容」をも意味してしまうのですが。感染症や、医療保険の有無、といった社会的な連帯関係のものは物議をかもしますよね。そりゃ。

タイマーをセットできればいいのにね。デスノートみたいに。

自分死ぬときVR-HMDかぶって、なんか、すごい音と映像で逝きたい。

臨床宗教師仕事の中に「VR機材の管理」も含まれてくると思うんですよね、今後は。「テクノ法要」もありますし。映像や音声のクリエイターも、その走馬灯のような「最期映像」をクリエイトする日が来るわけですよ。

からVR業界から法曹界医療関係転職するようなキャリアパスもあるでしょうね今後は。

塞翁が馬

みとりびと、おくりびと

2020-10-11

エンドツーエンド暗号化(通称: E2E)について解説する

[B! セキュリティ] フェイスブックの暗号化、日米英などが見直し要求へ (写真=AP) 日本経済新聞

エンドツーエンド暗号化という技術がある。

暗号とは

平文一定アルゴリズムに従って暗号から生成したノイズデータを掛け合わせ、意味が読み取れない暗号を作るのが暗号化である。逆に意味が取れない暗号から平文を求める操作復号と呼ぶ。アルゴリズムがよく知られていながら暗号鍵が無ければ復号できないものがよい暗号と言われる。一般には256bitAESでも使っておけばまずパッと見ても聞いても数学的にもほぼ乱数区別できなくなる。

ノイズデータの生成方法には色々あり、事前に送り付けた乱数表を使い使用後は破棄するもの、事前に送り付けた共通鍵や公開鍵を使うもの、都度生成するものなどがある。掛け合わせる方法も色々あり、乱数表に書いてある数字暗号文を足し合わせると平文になるもの共通鍵を暗号文に使うと平文になるもの公開鍵を使うと平文になるものなどがある。

共通鍵を平文に使うと暗号文になり、共通鍵を暗号文に使うと平文になるものを、対称暗号とか共通暗号と呼ぶ。

公開鍵を平文に使うと暗号文になり、暗号文に秘密鍵を使うと平文になるもの公開鍵暗号と呼ぶ。非対称暗号ともいう。

ノーマルモードコモンモードみたいで意味不明だが耐えろ。

共通暗号でも公開鍵暗号でも「平文が、暗号文になり、平文に戻る」というところは同じだが、

共通鍵では「平文→   鍵→暗号文→鍵   →平文」と同じ鍵を使い、

公開鍵では「平文→ 公開鍵暗号文→秘密鍵 →平文」と二種類の鍵を順に使う。

なお、この二種類の鍵は順に使えば順序はどっちでも良い。先に秘密鍵で処理して公開鍵で処理することも可能だ。とにかく2種類両方を使えば良い。

共通暗号は分かりやすい。zipパスみたいなもんだ。Wi-Fiパスワードも同じだ。だが公開鍵暗号については、二種類の鍵を順番に使うと何が良いのかと思う人も多いだろう。どうせ暗号で読めないのだからいいじゃないかと思うだろう。実は名前の通り鍵を公開しても全くノーダメージというところがメリットなのだ。書かなかったが公開鍵から秘密鍵数学的に求めることは不可能である。逆も不可能である。そして処理する順番もどっちでもいい。つまり適当暗号文と鍵の片割れを公開しておくことで、もう片割れの所有を証明できるである。これが公開鍵暗号醍醐味である

この技術HTTPS証明書に使われている。というかすべての公開鍵基盤で使われている。.pemとか.cerとかid_rsa.pubはこの片割れであり、ウェブブラウザの「証明書の検証」とは、ネットを見てる時にサーバが送ってくる「適当暗号文」として"*.hatena.ne.jp"のハッシュを知らん鍵で暗号化したものハッシュを知らん鍵で暗号化したものハッシュ暗号化したものに対して、事前にWindowsインストールした時に付いてきたHatena-Masuda Ultra Global Root CAかいったけったいな鍵の片割れを使ってみてちゃんと復号出来てるかチェックしているのである

ここまでが暗号技術のおさらいである。

暗号化通信とは

暗号化通信を行うには、暗号鍵でデータ暗号化すればいい。暗号化には共通暗号を使うのが高速で便利だ。公開鍵暗号原理的に計算量が多く低速であるしかし、どうやって共通鍵を事前に知らせればいい? 公開鍵暗号共通鍵を暗号化すれば、受け取り手自分秘密鍵で復号できるだろう。しかし、秘密鍵は本当に秘密か? 暗号文と秘密鍵が手に入れば、公開鍵暗号でも解読できてしまうのではないか? HTTPS化しているウェブサービスでも、TLSロードバランサで終端してデータセンタ内は平文だったりするのではないか? そこで鍵交換、セッション鍵生成の議論が登場する。

Diffie-Hellman-Merkle鍵交換方式

Diffie-Hellman-Merkle(Diffie-Hellman)鍵交換方式とは、ディッフィー君とヘルマン君が下宿階段をドタドタやってる時に天啓のように降ってきたと言われる、ネット上に数字のものを公開することなく、2者間で同じ1つの乱数を得る方法である

送信者と受信者の間で共通の1つの乱数を得ることができ、その乱数第三者に知られることがない。

上で何度か「公開鍵暗号秘密鍵公開鍵は、平文に対して両方使えば平文に戻り、順序は関係ない」と書いたのを覚えているだろうか。Diffie-Hellmanはこれに似た方式だ。まず、AさんとBさんは送信者がお互い本人であることを証明できるようにする(公開鍵基盤を使う)。そして、それぞれ手元で乱数AとBを生成する。次に、鍵用の乱数Aを適当乱数暗号化した鍵Aと、鍵用の乱数Bを適当乱数暗号化した鍵Bを計算し、お互いに送り付ける。この暗号Aと暗号Bは盗聴されているものとする。

Aさんの手元には乱数A、適当暗号Bがある。

Bさんの手元には乱数B、適当暗号Aがある。

AさんとBさんはそれぞれ鍵Bと鍵Aに対して暗号化を行う。すると鍵BAと鍵ABが生まれる。このとき数学的な都合により鍵BA == 鍵ABである

では、暗号A、暗号B、適当A、適当Bのみから鍵ABや乱数Aを求めることはできないのか? 可能だが式変形などで「解く」ことができず、総当たりになるため計算量が膨大になる。従って実質的にはできない。

或は、暗号A、暗号Bを掛け合わせれば、鍵ABになるのではないか? これもできない。暗号AまたはBと掛け合わせるのは生の乱数AまたはBでなければ意味がない。第三者乱数Cを作って暗号AやBと掛け合わせても、鍵ACや鍵BCになってしまい、鍵ABと一致しない。

これにより、手元で生成した乱数以外のすべての情報が公開で既知で盗聴されているにもかかわらず、2者間で秘密暗号鍵用乱数を得ることができる。

原始的Diffie-Hellman鍵交換の実際の計算は非常に簡単であり、この「暗号化」は事前に決めた別の方法で生成する既知の2つの整数X, Yと乱数A, Bに対して、

暗号A = XをA乗してYで割った余り、

暗号B = XをB乗してYで割った余り、

鍵AB = 暗号BをA乗してYで割った余り、

BA = 暗号AをB乗してYで割った余り

である

なお、くれぐれも簡単と聞いてPython 2.7とかで実装しようとしないように。算数の上手い人が作ったライブラリを使え。暗号処理の自作絶対バグらせて割られるのがオチだ。ちなみにDiffie-Hellman-Merkleの三人目のマークル氏というのは両名と何のゆかりもないので普通名前に入れないのだが、Merkle氏の先行研究が直接の元ネタなので入れるべきだと主張する派閥もある。俺はどっちでもいいと思うが折角なので入れておく。

End-to-End(E2E) 暗号化

ここでやっとE2E暗号化が登場する。上のセクションでしれっと書いたが、DH鍵交換が完了した時に送信者と受信者が得る共通乱数は、各々ローカルで都度生成する乱数を元にしている。身許保証公開鍵によるが、鍵は公開鍵に縛られないのだ。つまりSNSメールサーバその他、身許を保証する機能文章をやり取りする機能があるツールと、そのツールで間違いなく本人にDH鍵交換の暗号を送れるクライアントアプリがあれば、その経路で本人同士の間だけで共通乱数を生成し、それを「セッション鍵」として共通暗号方式による通信経路が設定できる。

この「公開鍵認証基盤で本人確認し、DH鍵交換でセッション鍵を設定し、鍵を端末に出し入れすることなく、受信側端末のメモリに入るまで暗号化を解くこともないまま、共通暗号通信する」のがいわゆる「End-to-End 暗号化である

E2E暗号化を行うと、鍵はDH鍵交換で生成され、端末の外に出ないし書き出す必要もなく、通信の中で割り出す事もできず、通信が終われば破棄してもよい。好きなだけ定期再生成してもよい。認証に使う公開鍵数学的な関係もない。一度設定してしまえば、SNS運営チャットログを出させても鍵交換した意味不明な履歴意味不明な暗号文が出てくるのみで、盗聴者をなりすまさせて鍵を再設定させても前の鍵と何も関係のない新しい鍵が出てくるだけで、意味不明な暗号文の解読の助けにはならない。ちょっと量子コンピュータめいているが、端末となりすましの両方で鍵を一致させることもできない。

ざっくり言えば送信側端末と受信側端末に残っている平文か鍵をバレる前にぶっこ抜く以外に解読方法がない。

これは盗聴関係者にとって非常に大きな問題で、米国FBIなどは盗聴能力を維持するには法規制以外に策がないと考えている。DH鍵交換のアルゴリズムは上に書いた剰余以外にも楕円曲線を用いた数学的に更に複雑なものもあり、ソースネットいくらでも転がっているし、電子計算機アルゴリズムの常でやたら強力な癖に計算量的には全然負担にならない。NSAなどは数学者を揃えて最高のアルゴリズム提供する振りをして、規格書で事前に決めた一定数学的特徴を備えているべき定数に備えていないもの指定するとか、実装ミスが出やす関数を選ぶなど小細工を入れているが俺は二次関数分からんので詳しいことは知らん。しばしば政府陰謀にキレた若いITキッズが小細工を抜いて差し替えた再実装を公開したりして揉めている。

実際にSNSなどでE2E暗号化実装する上での問題点は、本人確認機種変マルチデバイス嫌がらせ対応がある。まず本人確認コケればMITMは可能だ。E2Eでは鍵を外に出さないのがメリットなので複数端末ログインができず(鍵が変わって別端末で書いたメッセージは解読できなくなる)、運営で常時メッセージ監視できない(したら意味がない)ので嫌がらせ対応が多少困難になる。またMITBというか、改造偽アプリで抜かれる可能性は、まあ、ある。

まとめ

  • 平文を鍵で暗号化するのが暗号である
  • DH鍵交換では、信頼されない通信路を使って2者間で鍵を生成できる。
  • E2E暗号化では、端末上で鍵を都度生成し、その端末以外での復号を防げる。

終わりに

時間もかけてこの程度かもうちょっと短く書けるだろボケ🍆と思ったので投稿する。

2020-08-19

Apple野良ストアを認めろといっているブクマカ中国スパイなの?

はてブ以外でこんなこと言ってるヒト見たことないんだけど。

ブクマではApp Store以外が認められることでユーザーメリットがあるって言ってる増田が多いが、およそ信じがたい。

AndroidだとAmazonKindleストアやHuaweiのストアなんかが比較メジャーだと思うが、特にメリットを感じたことはない。Amazon Kindle ストアは使ったことがあるが、Playストアに対する優位性はゼロで、アプリが少なく不便なだけだった。

そうは言っても、具体的に何が起こりえるのかを列挙してから出ないと判断はできないと思うので、以下のとおり検討してみる。

App Store以外のアプリストアが認められることで、ユーザーにとって起こり得る変化としては、以下が考えられるだろう。

1) 同じモノが安く買える:

自社ストアに誘導したい特定パブリッシャー手数料を割り引くことや、そもそも自社ストアなので手数料分を割り引くことを行えばあり得る。フリーライド以外の何物でもないけど。

ちなみに、EpicがやってるSteam対抗のPCゲームストアは、手数料割引分を開発者還元しているのでユーザーにはほぼメリットのない状況である

2) 様々な理由App Store で認められないアプリダウンロードできる

これは更に以下の3つに分けられる。

2-1) セキュリティ的な理由で認められないアプリダウンロードできる:

危険なだけでメリットとは言い難い。

2-2) Apple利益に反する (商売上の競合や反社会的行為) のため認められないアプリダウンロードできる:

メリットといえばメリットだが、具体例に乏しい。AndroidであってiPhoneにないものとしては、ゲーム機エミュレーターなんかが挙げられるだろうか。違法に近い。

2-3) 中国製のbanされたアプリダウンロードできる

WeChatTikTokダウンロードできるのは、人によってはメリットになるかもしれない。米国政府を敵に回すので、起こりそうにもないが。

3) Apple が嫌いで、なるべくAppleお金を落としたくないが、iPhoneを持っているユーザー精神の安定を得られる:

rootとって勝手にやってくれ。

結論

Emulatorなどの違法アプリを導入できる可能性が高まること、米国からbanされる中国製アプリ使用できる可能性があるほか、一般ユーザーにとってのメリットは見当たらなかった。

考察

野良ストア推進はやっぱ中国スパイかも。

2020-06-15

anond:20200614012513

さらbashシェルからshシェルの起動に成功、その後exitコマンドによってshシェルからbashシェルに帰還


残念ながら、君がshだと思ってるものは、実はbash

$ ls -l /usr/bin/sh
lrwxrwxrwx. 1 root root 4 11月  9  2019 /usr/bin/sh -> bash

2020-06-14

CentOS8の起動に成功してしまった……

これで俺もアノニマスの一員だな……

起動だけならまだしも、ターミナルエミュレーターからsuコマンドを用いてパスワード入力root権限を取得してアノニマス御用達テキストエディタVimダウンロードにも成功してしまった

さらbashシェルからshシェルの起動に成功、その後exitコマンドによってshシェルからbashシェルに帰還、更にlogoutコマンドによりbashシェルからログアウトにも成功してしまった

もう完全にハッカーだよ俺……

ヤバいヤバいヤバい……

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