「乱数表」を含む日記 RSS

はてなキーワード: 乱数表とは

2021-06-29

https://players.wotvffbe.com/1322/

なんか妙だな

提供割合に基づいてランダム配列した2つのリスト作成し、どちらを引くか抽選

上記リストの並び順で連続する10体が提供され、次の消費者は前の消費者の結果の続きから提供

③ 全体としての排出率は正しい

結果: 提供される10枠分の組み合わせが相当限られる

①②③から下の結果って導けるか?

単に「ランダム」とだけ書いてあるけど、これがカルドセプトサーガみたいに乱数の扱いがクソで事実上ランダムじゃなかったってんなら組み合わせが限られるのもまあ分かる


ああ理解できた

最初に2つのリスト作成したら、もうこのリストが再作成されることはないのか

なぜか「使い切ったら再作成されるんだろう」と問題文に書かれていない仮定をしていた

その通りに使い切ったら再作成すりゃよかったのにな

ロマサガとかの乱数表を思い出したよ

実装バグじゃなくて設計バグだな

消費者庁に怒られたのは、プレイヤーは固定された組み合わせのうち1つしか引けないが

どこかの組み合わせに「当たり」が複数入ってしまっていた場合、組み合わせごとの「当たり」の排出率が下がるからだろうなー

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-10-08

なぜ、本人確認にこだわるのか

俺はまぁラディカルというか原理主義者なので、本人確認なんてものID+パスワードでいいと思っているわけ。

でも割とよく世間では、ID+パスだけだと本人の確認になっていないとか言うアホ理論がまかり通っていて、そんなわけねーだろということを証明します。

多要素認証

他要素認証を使えば本人確認になる、という説がまことしやかにまかり通っているけど、そんなのじゃ「本人確認」にはなりません。

例えばメジャースマホを使った確認を例に取ると、ID+パス入力だけじゃなく、事前登録したスマホに入っている暗号アプリで、自動生成した暗号入力すると、ID+パス+スマホの所持が揃ったので本人です。って感じで認証するんだけど、これスマホ奪われてたら誰でもできるよな。

確率低い?とはいえ本人意外もできるっていう点だと、ID+パスワードと同じで「本人を確認したことにはならんだろう。

同じことはEメールワンタイムパスワードを送付して、ID+パスワード+ワンタイムパスワード認証する方法もだけど、これも、メールアドレス権利確認してるだけど、それが奪われていたら、本人以外でも利用できる。

事前に物理的な乱数表ドングルマイナンバーカードつかった認証も、奪われれば本人以外が認証突破できるので、「本人確認」できるとは限らない。

ID+パスワードより強度は上がるけど、それは認証の強度が上がったと言うべきであり「本人確認」できるとか、いいきっちゃうのは、本質を知らないで適当セキュリティ語ってて、だるい

生体認証

じゃあ生体認証使えば良いという。感じもするかもしれないけど、指紋コピーとか簡単にできます

認証も難しいかもしれないけど頑張れば突破できそうだし、何なら本人の指やら首を切り落とせば、突破できると思うので、これも「本人確認したことになるとは限らない。双子とかクローン使うこともできるしな。

代理問題

例えば友人とか、本人の許可を得て代理としてシステムサービス操作する必要がある場面ってあるわけで、

そういう場面だとID+パスワードだけ知っていれば代理操作をすることができるわけです。

あ、お前らは友達居なかったな。でも大丈夫ボットサービスかに代理に処理をしてもらうことを考えれば同じで、

ボットサービス操作してもらいたいサービスID+パス登録すれば、それだけで代理操作してもらえる。

これが、多要素認証になると、代理操作出来ないくなる。「本人」が操作代理させる意志をもっていても、端末を友達に貸し与えて四六時中持ち歩かせるわけにもいかないし、よくわからねーボットサービス指紋情報やら、生体認証登録するのやりすぎてる。

セキュリティ上がってるとか喜んでるけど、それは裏を返せば使い勝手が下がっているとも言えるわけです。

そこまで使い勝手が下がってて、じゃあそれに報いるだけのセキュリティ上昇が期待できるかと言われれば、前述のように本気を出せば他人がそのセキュリティ突破することはできるわけで、基本的にはコスパ悪い。

もちろん医療とか金融とかクリティカルな場面では使うべきだと思うけど、何でもかんでも多要素認証生体認証、みたいなノリは気が狂ってるとしか言いようがない。

あとセキュリティが上がっているだけで「本人確認」ではない。ボットスマホを預けるとかメールを読み取る権利を渡せば実現できる。くっそめんどくさいし危険だけどできる。本人意外が操作できるってことは「本人確認」として機能していない証拠です。

本人確認は出来ないのか?

はい、出来ません。限りなく本人っぽいです。ということまでしかわかりません。

仮に対面で人間認証するって事になっても、詐欺師の人は整形もすれば書類も偽造で取り揃えます

なので、本人確認基本的に無理です。

軽々しく「本人確認」とか言うな。本人って誰が判定するんだよ。まわりか?

まわりが勝手に「本人」であることを認証したり確認したとしてだよ、その「本人」が記憶喪失になって、「本人」であることを拒絶したのならそいつは本人なのか?それとも別人か?

答えろ!

2020-09-10

anond:20200909091623

それを逆から暗証番号を固定して(よく使われる2525とか日付とか)、入手した大量の口座番号でリバースブルートフォース攻撃を仕掛けられることが発覚したってのが今回のドコモ口座事件よ(実際の手口がこれかは別にして、それができてしまシステムだった)

から1万件の口座番号を入手できても、盗み出せるのはそのうち数十件程度となる

本来ネット銀行オンライン取引をするなら2段階認証乱数表使ったりして本人確認があるからキャッシュカードの代わり)、口座番号と暗証番号が分かっただけでは盗み出せないのだけど、ドコモ口座がその抜け道を用意していたという話だな

2020-04-25

anond:20200425213532

ワンタイムパスワード乱数表カードで二段階三段階認証している所なら大丈夫

基本、「その端末外のもの」と「端末内」の情報を組み合わせて認証するものであれば、安全度合いはかなり上がる。

法人口座であれば、更に別の設定が複数あるし、銀行専用端末を用意していれば、なおさら安全

それでも間違って詐欺集団に送金するBECがあるが、そこまで行くと自己責任だと思う。

2015-07-02

銀行中の人だけど、苦々しい会計簿アプリのことを書くよ

ホッテントリにがってるので、ちょっと書いてみるよ。

http://twinavi.jp/topics/it/5593e714-5b0c-4b21-99f5-3f94ac133a21

銀行人間としても、この手のアプリは苦々しく思っている。

やめてほしいなあ、と思う理由は次の3点。

不正払戻への対応めんどい

事故犯罪によって預金不正に払戻されたとする。あまり知られていないのだけれど、このとき預金者に明らかな過失がなかった場合には、損失額は銀行補填する(預金保障規程という。ペイオフとは別物)。

明らかな過失というのは「普通やらんだろ」っていう内容のもので、例えば

で、会計簿アプリのケースも、自己責任パスワード預けていたとすれば「預金者の明らかな過失」にほぼ該当すると思われるので、銀行側が損失補てんをする必要はない。その点の心配はない。

ただし預金から補てん請求があったときに、「預金者に明らかな過失があった」ことを証明する義務銀行側にある。大規模なデータ漏れなどの際に不正払戻しの被害が生じたら、当行預金者の被害者存在確認と損失額の把握、預金者が「アプリ側にパスワード預けてた」ことの立証を書類にしていく必要があるのだけれど、正直、そんな面倒な仕事をさせないでくれ、と思う。そういうときに限って「銀行アプリデータ提供していたからいけないんだ」とか言い出すクレーマー絶対現れるし。

ここまで書いて気がついたけど、そもそも乱数表=取引パスワードログインパスワードでしょ?データ閲覧のためだけなら乱数表データ不要なはずなのに、なんでそれ収集するのさ?

フィッシング詐欺材料を作らないでくれ

これだけフィッシングサイトに気をつけろって言っていても被害者は減らない。

アプリの画面に似せたフィッシングサイトが横行すれば(時間問題だと思う)被害者は増加するだろう。上記とも関係するが、犯罪者に余計な知恵を付けさせないでくれ。

銀行重要商売リソースを使わないでほしい

これは、銀行の外の人から見ればどうでもいい話なんだけど。

預金クレジットカードの決済履歴は、その人の消費性向を如実に表す貴重なデータだ。

が透けて見える。銀行ではずいぶん前から、こういった過去データ分析してその人の消費性向にあった金融商品を高い精度で提案したい、という研究を進めている。銀行とすれば将来の商売需要ネタが、他者に把握されるというのは極めて都合が悪い。やめてほしい。

~~~

もちろん預金者本人のデータ預金者がどう使おうと自由なわけだけれど、

普段から個人情報は格段にセンシティブな取扱をしている手前、

こういう形でデータが外部に流れていくのは、所在なさというか心地悪さというか、気持ちの悪さを感じる。

そもそも、自分の中でも最もプライベート情報をよく他所様のフォームにホイホイ入力ちゃうよなぁ、ってのが個人的感想で。

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