  |
はてなキーワード: Windowsとは
[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)鍵交換方式とは、ディッフィー君とヘルマン君が下宿で階段をドタドタやってる時に天啓のように降ってきたと言われる、ネット上に数字そのものを公開することなく、2者間で同じ1つの乱数を得る方法である。
送信者と受信者の間で共通の1つの乱数を得ることができ、その乱数を第三者に知られることがない。
上で何度か「公開鍵暗号の秘密鍵と公開鍵は、平文に対して両方使えば平文に戻り、順序は関係ない」と書いたのを覚えているだろうか。Diffie-Hellmanはこれに似た方式だ。まず、AさんとBさんは送信者がお互い本人であることを証明できるようにする(公開鍵基盤を使う)。そして、それぞれ手元で乱数AとBを生成する。次に、鍵用の乱数Aを適当な乱数で暗号化した鍵Aと、鍵用の乱数Bを適当な乱数で暗号化した鍵Bを計算し、お互いに送り付ける。この暗号Aと暗号Bは盗聴されているものとする。
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で割った余り、
である。
なお、くれぐれも簡単と聞いてPython 2.7とかで実装しようとしないように。算数の上手い人が作ったライブラリを使え。暗号処理の自作は絶対バグらせて割られるのがオチだ。ちなみにDiffie-Hellman-Merkleの三人目のマークル氏というのは両名と何のゆかりもないので普通は名前に入れないのだが、Merkle氏の先行研究が直接の元ネタなので入れるべきだと主張する派閥もある。俺はどっちでもいいと思うが折角なので入れておく。
ここでやっとE2E暗号化が登場する。上のセクションでしれっと書いたが、DH鍵交換が完了した時に送信者と受信者が得る共通の乱数は、各々ローカルで都度生成する乱数を元にしている。身許保証は公開鍵によるが、鍵は公開鍵に縛られないのだ。つまり、SNSやメールサーバその他、身許を保証する機能と文章をやり取りする機能があるツールと、そのツールで間違いなく本人にDH鍵交換の暗号を送れるクライアントアプリがあれば、その経路で本人同士の間だけで共通の乱数を生成し、それを「セッション鍵」として共通鍵暗号方式による通信経路が設定できる。
この「公開鍵認証基盤で本人確認し、DH鍵交換でセッション鍵を設定し、鍵を端末に出し入れすることなく、受信側端末のメモリに入るまで暗号化を解くこともないまま、共通鍵暗号で通信する」のがいわゆる「End-to-End 暗号化」である。
E2E暗号化を行うと、鍵はDH鍵交換で生成され、端末の外に出ないし書き出す必要もなく、通信の中で割り出す事もできず、通信が終われば破棄してもよい。好きなだけ定期再生成してもよい。認証に使う公開鍵と数学的な関係もない。一度設定してしまえば、SNS運営にチャットログを出させても鍵交換した意味不明な履歴と意味不明な暗号文が出てくるのみで、盗聴者をなりすまさせて鍵を再設定させても前の鍵と何も関係のない新しい鍵が出てくるだけで、意味不明な暗号文の解読の助けにはならない。ちょっと量子コンピュータめいているが、端末となりすましの両方で鍵を一致させることもできない。
ざっくり言えば送信側端末と受信側端末に残っている平文か鍵をバレる前にぶっこ抜く以外に解読方法がない。
これは盗聴関係者にとって非常に大きな問題で、米国のFBIなどは盗聴能力を維持するには法規制以外に策がないと考えている。DH鍵交換のアルゴリズムは上に書いた剰余以外にも楕円曲線を用いた数学的に更に複雑なものもあり、ソースはネットにいくらでも転がっているし、電子計算機アルゴリズムの常でやたら強力な癖に計算量的には全然負担にならない。NSAなどは数学者を揃えて最高のアルゴリズムを提供する振りをして、規格書で事前に決めた一定の数学的特徴を備えているべき定数に備えていないものを指定するとか、実装でミスが出やすい関数を選ぶなど小細工を入れているが俺は二次関数も分からんので詳しいことは知らん。しばしば政府の陰謀にキレた若いITキッズが小細工を抜いて差し替えた再実装を公開したりして揉めている。
実際にSNSなどでE2E暗号化を実装する上での問題点は、本人確認、機種変とマルチデバイス、嫌がらせ対応がある。まず本人確認がコケればMITMは可能だ。E2Eでは鍵を外に出さないのがメリットなので複数端末ログインができず(鍵が変わって別端末で書いたメッセージは解読できなくなる)、運営で常時メッセージを監視できない(したら意味がない)ので嫌がらせ対応が多少困難になる。またMITBというか、改造偽アプリで抜かれる可能性は、まあ、ある。
https://pc.watch.impress.co.jp/docs/news/1281606.html
ウェブとかのUIでチェックボックスでいいものをラジオボタンにされてるような使いづらさ
半角か全角で左だったり右だったりを考えないと行けなくて不便すぎる
ボタンの並びが違うだけならともかく1キーの左にボタンがないからキー割り当ての変更で戻すこともできないし
しかも無変換なくなるって、普段から無変換で変換候補並んでる状態からひらがなに戻したり、カタカナ変換したりとかで常用してる人からすると不便すぎ
Mac のキー配置が好きなら Mac 変えばいいのであってWindowsにまで持ってくるのやめてほしい
慣れてる物を変えるのが一番ダメな変更
全部のSurfaceがこれになったらもうSurfaceは買わないわ
最近、仕事のスタイルのせいなのか、文字入力の対象が短文入力フィールド（検索窓、コメント欄、チャットの入力欄、その他）ばかりになってきて、結果猛烈にイラついていることがある。それは、入力欄にカーソル合わせるたびに、IMEのオンオフがその欄の仕様に合わせて変わることで、日本語入れるつもりが英数字が並んでいる、あるいはその逆になっていて打ち直すシチュエーションが激増している。体感的には、タイピングの1/3位が、この理由での打ち直しになっている感がある。Macだと「かな」「英数」のキーがあるので、最初にそれを押す癖がついていて問題ないのだが、Windowsだと相当イラつく（仕事柄選べない）。Enterで変換確定のつもりがメッセージ送信していたという事故も嫌になる程多い。
もう20年以上Windows使ってるけど、最近いろんなアプリの色んな短文入力フィールドを使うっていう状況が猛烈に増えていて、これまでにないレベルでストレスが溜まる。
みなさんどうやって克服しているんでしょうか。
なおWindows１０から SP1 SP2とかではなく 細かいバージョンに成るらしく・・・
XX月版だと大丈夫とか うちはリリースしなきゃいけないのかと 広報と・・・
今さらここで何かを書いても，あまり助けにならないかもしれないけれど，もしまだ入門する気があったら気に留めておいてほしい．
package, use-package, leafどれでも構わない．ただ混在させるとエラーやwarningを出したりするので，統一をしたほうがいいとは思う．新しいとか古いとかはこの際気にしなくていい．最近はEmacs標準でpackage.elがついているので，めんどくさければ全部packageを使えば問題ない．
こういうのは，Emacsを使っているうちに「自分は.emacsをいじるのを結構楽しんでいるな」と思ったときに，新しいのやスマートな方法を調べれば十分だ．
これは入門時は仕方ない．ただ後述するhydraを使ってくれ．そうすれば一度調べたものをもう一度調べることがなくなると思う．
hydraを使おう．
https://github.com/abo-abo/hydra
hydraってのは，複雑なキーバインドを覚えられない，覚えたくない場合に入れるパッケージだ．Emacsだと，導入したパッケージにデフォルトで設定されているキーバインドと，自分でカスタマイズしたキーバインド，両方を覚えておく必要がある．けど，そんなの覚えてられるのは一部だけなので，よく使うコマンド一覧を自分で設定できて，それを表示してくれるのがhydraだ．
表示するコマンド一覧を自分で設定するので，↑で調べたときに調べたコマンドを全部hydraの設定に書いておくといい．また，そのときにキーバインドも判明したのであれば，hydraのコマンド説明部分にキーバインドも書いておくといい．
これはすまん．使ってる人は実はそこまで少数ではないんじゃないかなと思っているけど，確かに日本語発信している情報は少ない．あと，たいていのパッケージがgithub等に公開されていて，玄人達は，英語が読める or そもそもソースがlispで書いてあるんだから読めばいいじゃん，という人たちが多い気はする．確かに私も日本語の情報は特に少ないと感じている．
Emacs-jpのbeginners-helpはあんまりbeginnerじゃない質問がされているけれど，気にせず初心者質問をしても大丈夫な場所なので，遠慮なく聞いてくれ．回答がわからなければ，「何言ってるのか全然わからん」と言ってくれ．
そういえば私もWindowsでEmacsを使ったことがないので何もわからない……．でも，そこまで困っているならきっとWindows Emacsユーザ全員が困っているはずなので，Emacs-jpで聞いてみたらいいかもしれない．もしくはWindowsユーザチャンネルを作ってみたらいいかもしれない．すまん，これについては助けになれない．
キーバインドが覚えられないのは，実はあなただけじゃなくてみんな同じだったからhydraなんてものが出てきたし，日本語情報が少ないのは事実だ．だからあまり卑下しないでくれ．偉そうに書いたけど，私も日本語情報が少なくて結構わからないことは多かったりする．READMEに書いてあるとおりにセットアップしてもエラーが出たりすることは結構多い．だから，こういう意見に耳を傾けて，Emacsコミュニティが人類に優しくなってほしいと願っている．
もうIMEパッチはほとんど要らない、むしろパッチがあるとインクリメンタルサーチで日本語が使えなくなるので、自分にとっては不便。
無印Windows版Emacsの唯一の問題は、ATOKで確定を Control-N とかでやると、確定文字列がControlキー付きで送られてしまうので、バッファへの入力が無効になってしまうこと。
諦めてリターンキーなどで確定するようにした。
https://anond.hatelabo.jp/20200921040234
Doing Vfork: resource temporarily unavailableに苦しみつつもgnupackを使っているが、
わかるわかるwww。
とりあえず、Visual Studio などのIDEでできることは、Emacsは使わない。
普通の「テキストエディタ」の用途だけで使えばいいと思えば気も楽になるよ。
たまに Mac, Linux を使うとき、共通のインタフェースで複雑なカスタマイズが可能なエディタがあることがすごく助かってる。
なにしろ1984年生まれで、マウスが普及する前に生まれたエディタだ。
右手をマウスとキーボードで往復することを前提とした左手のC-c, C-v などのコピーペーストのショートカットの概念がない。
これが辛い。すごく他のアプリとかけ離れてて辛い。ここだけは脳にスイッチを作るしかない。英語と日本語おぼえるようなものだな。
あと考えてみたら、今やEmacsで使う時間の 99%は org-mode だなー。あははは。
org-mode で、Python とか Julia とかをデータと統合したりすると、Jypiter なみに柔軟なノートブックが作れる。
あとは、前のコメントにもあったが、 Lisp系とか、マイナーな関数型プログラミング言語 (Agda2とかね) はEmacsしか選択しないなー。
Emacs、一生入門できない
あたまがうんちで出来てる俺にはむり
package, use-package, leafやらのいろんな方法が混在していてわけわからん
便利そうなパッケージの説明見に行くと、設定方法の説明に使ってるのがpackageだったりuse-packageだったりもっと古いやつだったりでわけわからんくなる
結局packageとuse-packageの混在したわけわからんinit.elを書く羽目になる
しかも設定書いたつもりでも反映されてなかったりするし原因調べようにも全部英語
さっきもRedoってどうやるんだ？ってなってググった
いちいちググりに行かないといけないのがしちめんどくさい
しかもなんだよC-g C-/って。覚えてられっかよ。C-yでRedoさせろよ。なんだよyankって。
・とにかくキーバインドを覚えるのが面倒
「キーボードから手を離さずに操作を完結させる」ってものに憧れてEmacs触り始めたんだけどさ。
結局のところキーバインドいちいち忘れるから調べるのに結局時間かかって意味ねえじゃん
物覚えいい人達は気にならないんだろうけどさ
でもCtrl+f, b, p, n, a, e, m, hだけは覚えた これだけは他のエディタでも便利なので使ってる
あと、他のエディタでこういうの有効にする設定使うとコピーがM-wだったり検索がC-sだったりになるけどそこは我慢して使ってる 一回覚えちゃったし
・使ってる人が居ないので情報もない
もう既に使いこなせてる強い人だけが使ってるのか知らんけど、全然情報が無い
「2020年代のEmacs入門」とかいう記事書いてる人が居たんだけど、例によって強い人がなんかいろいろ書いてんなーぐらいしかわからん
あれ読んだ後によしEmacs使ってなんか書くぞ～～って進めるとは思えん 俺の頭がパッパラパーなだけな気もするけど
同じ人が書いた「Emacs入門から始めるleaf.el入門」とかもそうだけど、「初心者を想定して書いてます！」みたいな雰囲気を初め出しといて途中からぜんぜんわっからーん状態になる
Emacsについての情報が集まるらしいEmacs-jpとかいうslackのグループがあるらしいので覗いてみたんだけども
そこでされてる会話がムズすぎてロクに聞けん
beginners-helpって書いてる場所でされてる質問も回答もいみわからん
稀にいるガチ初心者も、幾つかやりとりした後は「〇〇って本読んで勉強してね」って答えだけ貰って満足してるし
俺その本持ってんだけど上で書いたパッケージのくだりとかわからんまんまだわ
さっきの入門記事もだけど、人はLinuxか、あってもMacしかつかわん前提なんか？ってくらいwindowsに冷たい
windowsのEmacsだと日本語打てるようになるまですら一苦労だった
なんかimeパッチ？とかいうのをあてたやつを配布してる人がいたからそれ使ってるけど
その人が居なくなったら俺Emacsのバージョン上げられなくなるじゃん！
WSLとかいうのも使ってみたけど、外部からファイルいじったら全てがバグってしんだ あとブラウザの起動ができなかったりそんなこんなでやめた
「windowsでEmacsを使う方法」とかいう便利そうなwikiに書いてあったからいけるやん！って思ったんだけどな～～～～～アホには無理でした
俺はほぼ初期設定のVScodeでやっていくわ
どうせ俺の仕事とかには関係ない趣味だけの話だしな いちいちイライラしたくない
文字打てたらそれで満足することにするわ
大学初年時に、プログラムって文字で書くんだーみたいな知識すら初めてだった自分が課題で使わされて以来、
いつか使えるようになりたいとおもってたけど諦めますわ
なんかEmacsの解説してるいい記事でもあったら教えて下さい。
ふと、C言語でテトリスでも作りたいなぁ、GTKがいいなぁと思い、どの環境が一番適しているか調べてみたが
意外にもLinux＆Qt Creator＆CMakeの組み合わせが最強であった。
・Windows（MinGW）…pkg-configの出力がc:\msys2\mingwではなく/mingwになりIDEへのライブラリの設定に難儀するなど、何をするにもトラブる。
・Qt Creator…CMakeでプロジェクトを作って読み込んだらビルド設定やインテリセンス、補完、デバッガがすべて完璧に動作した。MakeFileプロジェクトでも、AutoToolsでも何でもうまく行く気がする。
・Vim…めんどくさすぎる
・Anjuta…AutotoolsでGTKのプロジェクトをデフォルトでサポートしていて何も設定が必要ないが、
ウィンドウの縦分割ができない、ブレークポイントの設定がマウスで出来ない、定義への移動のショートカットがデフォルトで設定されてないなどつらすぎる場面が多い
・Geany…補完をするのにctagsコマンドで辞書ファイルを作成する必要がある。このことから補完以外でもマトモな支援は期待できなそう
・Eclipse…ビルドツールの設定に難あり。依存ライブラリの追加が一個ずつしか出来ない。"."や":："を入力するか、Ctrl+Spaceを押さないと補完が出てこない。
