「ハッシュ関数」を含む日記 RSS

はてなキーワード: ハッシュ関数とは

2023-11-06

anond:20231105160951

接尾辞じゃあ弱いが、もう一歩進んで暗算できる程度に平易で他人から推測されにくいオレオレハッシュ関数を一つ作っておくのは手だ

いつも使う特定文字列サイト名やドメイン等やらをsaltとして塗した上でオレオレハッシュ関数を通してパスワードを生成するって形にしておけばパスワードのものは使いまわさずに済むぞ

2021-05-21

人生を左右するのは主に運だということがわかった。

であるからには大学受験も5割は運の問題にするべき。

具体的には、適当乱数ハッシュ関数の16進数表記の一桁目を当てる問題かにしよう。

2020-05-26

anond:20200526170021

ハッシュ関数というのは俺も好き。暗号化よりもハッシュ化の方がかっこいいと思う。出力値から入力値を逆算(復号)することはできないからな。しかしお前が何を言おうとしているのかは俺には分からない。まさに、ハッシュ値だ。

2019-09-12

ISUCON9予選のレギュレーションバグについて

ことの顛末

ISUCON 9 参加記 - kyuridenamidaのブログ

ISUCON9 レギュレーション違反の対応について [追記あり] : ISUCON公式Blog

TL;DR

本文

そもそもレギュレーション違反なのか問題

パスワードを平文で保存すること禁止する」というレギュレーションに対して、「パスワード+#」が違反したと見なされたのが最初見解

ここでいう「平文」が出てくる文脈は、初期実装のbcryptからも明らかなように暗号理論文脈だと考えられる。ここに疑念を挟む人はまずいないだろう。

そして暗号理論文脈で言う「平文」とは明確な定義があり、今回で言えば「パスワード文字列のもの」だ。

まりパスワード+#」は「平文」ではない。

これは学問的には異論余地がないので、このことを知らなかった人や、どっちもどっち論に立っていた人は、素直にごめんなさいすべきだ。

たとえば以下のツイート主が主張するような「原理的に元に戻せるのは全部平文」なんて定義暗号理論では受け入れられていない。複合可能なら全部平文なの?


もう話はここで終わってもいいのだが、まだまだ論点があるので続ける。

平文と同程度の強度は実質平文なのでは問題

この立場に立っている人も結構いるように見かけたが、レギュレーションからそれが読み取れないので無理がある。

第一に、レギュレーションでは暗号強度に関して全く触れられていない。

第二に、OK暗号強度の線引きがあるのならベンチマークでチェックすべきだ。

特に後者は今回(自分の知る限り)誰も言っていなかった気がするが、セキュリティの側面も持たせるのなら仕組みで担保しなきゃダメだろう。

運営側が想定していたレギュレーションが、平文よりも高い暗号強度での保持であったとしても、そのことが明確にわか文章になっていないので、レギュレーション文言実装バグしか言いようがない。

そもそも効率化のためにセキュリティ犠牲にするのはどうなのよ問題
ウェブアプリケーションとしてありえない実装ダメでしょ問題

実はこの立場運営擁護していた人が一番多かった気がしてしまうのだが、見事にハシゴを外されてドンマイとしか言いようがない。

たとえば有名人だとこの人とか。


残念ながらISUCON運営公式の言説として、平文とまではいかなくても暗号強度を犠牲にすることは想定内であったことがアナウンスされている。

bcryptによる負荷の対処方法として、サーバを追加、軽量なハッシュ関数での代替、あるいは平文での保持を開発チームにおいて想定しましたが、現実問題として、パスワードなどの情報流出などの事件が発生しており、平文での格納は一般的に推奨されない実装方法だという認識を同時に持ちました。

ウェブアプリケーション開発者として、みたいなことを大上段に出されても、ISUCON現実ウェブサービスであれば許容できないようなハックを用いてでも高速化するコンテストである、という文脈は、それこそ過去ISUCON確立されてきたものなわけで、ISUCONを知らないのなら黙っといたほうがいい、としか言いようがない。

なお実サービスでは当然やらないことをやるのはどうよ、みたいな話を持ち出すと、今回おそらく運営脳内レギュレーションではMD5あたりもOKだったのでは、という辺りを考え出すと、やはりどこがラインなのか明確じゃないよねって話に結局なる。(2019年MD5を許す実サービスは流石にないよね?)

そこを明確にしたいなら文章化(脳内レギュレーション実装)をがんばるか、ベンチマークなどで担保するしかなかったという結論は変わらない。

それが出来ないなら何でもありになるのは当然の帰結だし、それを美学だとかプライドだとか個々人の価値観が大きく異なる概念で縛ろうとするのは、こと競技に関しては真摯姿勢ではない。

(たとえば大相撲のような競技でも、横綱が変化しちゃダメという美学に関して喧々諤々な議論が起きたりする)

運営はどうすべきだったか

今回は見逃して次回からルール文化をがんばる

王道はこれ。

脳内レギュレーションを明文化できていなかった、という反省を踏まえて次がんばるしかない。

今回は他チームから問い合わせがあったらしいが「平文」の定義をきちんと調べさえすれば、想定していた回答ではないが「パスワード+#」は平文ではないので今回のレギュレーション違反には当たらない、という結論を伝えるべきだったように思う。

運営側が求める最低限の強度の実装で追試験

現実的な落とし所はこっちだったかもしれない。おそらく該当チームも、これなら反発はしなかったんじゃないか

今回は競技中の質問に回答をしなかったという問題もあった。

まりこういうことを伝えたらどうだったか



今後のこと

まだ本戦があるんやで

ということで騒ぎは終わりにしたい、という気持ちに関しては多くの人の一致を見るはずだ。

一方で運営側の朝令暮改のような対応に不信感や疑問を持つ人が多いのも事実だと思う。

ボランティアでがんばってるんだから目を瞑ろう、という感情的意見もまあ分かる。お疲れ様だ。

たこれは個人的見解だが、特に今回の予選問題過去最高傑作と言っても過言ではないくらいよく出来ていると思うし、流通額をスコアとするビジネス上の目的意識させるというメッセージ性も素晴らしいと思うので、今回の一件を持って問題作扱いされてほしくない気持ちは正直ある。


でもきちんと総括しないで先に進んでも誰も幸せにならないのもまた事実だと思う。

ということで、運営側はレギュレーション文言バグっていたことをちゃんと認めて、該当チームに落ち度が全く無かったことを謝罪した上で、次に進んでほしい。

競技中に質問に答えなかったこと、参戦後ブログ根拠裁定をくだしたことも悪手だと思うが、それ以上に、「レギュレーション違反はなかった」ことをきちんと伝えて名誉回復してあげるのが一番の筋のはずだ。

2019-03-12

anond:20190312002838

ハッシュ関数にすればいいんだよ。

小川さんと木村さんの苗字を合わせてダイジェスト計算したらaSDFgHjkになりました。

aSDFgHjkは苗字データベースで照合したら下田だったので子供苗字下田です。

法律で決めてしまえば夫婦間で無駄な争いも生じない。

2018-11-29

anond:20181129122332

それな。

毎回頭に日時でも付けてハッシュ関数呼べばええねん

2018-04-30

ブロックチェーンの使いどころ

ブロックチェーン流行ってるじゃん。あれ使えば何でも、改竄絶対不可能になって、所有権保証できるんだろ。超すげー。

ということで、俺様が考えるブロックチェーンの使いどころを書き記す。よく聞け。

パブリックプライベート、コンソーシアム

これらの違いは、早い話がブロックチェーンを誰が運用してるんですか、という話だ。

パブリックブロックチェーン

パブリックブロックチェーンでは、誰もがブロックチェーン運用するノードになれる。そのために、現実的不正ができないよう、ノード間で見張り合うシステム必要になる。

Bitcoinのようにお金を扱うシステムで、皆が台帳を持ったら、誰もが、自分のところにお金が入ってきたことにしたり、自分の使ったはずのお金を使ってないことにしたり、といったことをやりたがる。

Bitcoinは、Proof of Workという仕組みで、そういった不正現実的にはできないようにすることで、お互いに信用できない人同士の分散台帳というもの可能にした。

Bitcoin革新的だったのは、「信用できない人たちに分散台帳を管理させたらみんな好き勝手不正するに決まってる!」という常識をぶち破り、そういった人達による台帳管理ができることを示したから。

プライベートブロックチェーン

企業業務商売ブロックチェーンを使おうとすると、誰もがノードになれるとか、誰もがノードアクセスできるとか、そういった仕組みは望まれないことが多いらしい。

そこで、自分たちだけの閉じた環境ブロックチェーンを作ろうという試みが、プライベートブロックチェーンだ。

ここでは、Bitcoinが起こした革命である、信用できない人たちによる分散台帳管理なんてもの必要がない。

プライベートブロックチェーン、いろいろと研究されたり、実証実験が行われたりしているが、

「なんでブロックチェーンでやる必要があるんですか?」にどう答えられるのか、よく分からない。

「なんでブロックチェーンでやる必要があるんですか?」については、後でさらに深く掘り下げる。


コンソーシアムブロックチェーン

プライベートブロックチェーン意味ないよね、と気づいた人達が次に考えたこと。

銀行間とか、企業間とか、組織をまたいでブロックチェーン作ればいいじゃないか、と。

組織力学の都合上、そうするのがいいなら、勝手にやってください。

けれど、Bitcoinが起こした革命である、他のノードに嘘ついてまで不正をしようとしている者同士が、ひとつの台帳を保持できる、というそ特性必要ある?

今も銀行間でいろいろ、電子データをやりとりしてると思うけど、そんな不正しようとしてる銀行あるの?

「なんでブロックチェーンでやる必要があるんですか?」に、技術的には答えられないのがコンソーシアムブロックチェーンだ。


それ、データベースいいんじゃないですか問題

ブロックチェーン使って何かやろうとすると、大体の人がぶち当たるのが「それ、ブロックチェーンでやる必要あるんですか?」「データベースじゃダメなんですか?」って問題だ。

この問題に陥るのは大抵、ブロックチェーンの持つ自律分散思想理解せずに、誰かが管理しよう、特権を持とう、中心的存在になろうとしてるからだ。

管理者がいるなら、管理者がデータベースを作って、そこでやればいい。その方が話はシンプルだ。


もっとひどいのは、データベースデータベースで別で置いて、ブロックチェーンに載せられるカラムブロックチェーンに載せて、その取引IDデータベースに記録しようと考えている場合だ。

全部データベースでやった方が作るのも運用するのも楽なことになぜ気づかない。アホなのか。


そもそもブロックチェーンは何を保証するのか

改竄防止だトレーサビリティだと騒いでいる人がいるが。そもそもブロックチェーンは何を保証するのか。

ブロックチェーンに載ってからは、確かに改竄は難しい。電子署名不正取引ブロックチェーンに載せないこともできる。


けれど、必要タイミングで正しい入力を与えるのは、ブロックチェーンを使う側の仕事で、

電子署名などのプログラム的に検証できるもの以外で不正が行われても、ブロックチェーンは何も検知できない。


ブロックチェーン自体最近発明だが、ブロックチェーンで使われている、ハッシュ関数電子署名などは、

もっとから改竄検知や偽造防止に使われていた技術で、それらを適切に利用すれば、ブロックチェーンを使わずとも、大抵の目的は達成できる。


ブロックチェーンは一体何に使えるのか

これらの話、知っている人には「うん、そうなんだよねー」って感じだったと思うが、知らなかった人は「じゃあブロックチェーン、一体何に使えるんだよ」と苛ついてきた頃かと思う。

ブロックチェーンは何にも使えないのか。いいや、そんなことはない。

用途1: フリーライド

Bitcoinは、送金するのには手数料がいるが、残高照会は無料でできる。他のブロックチェーンも同様のものが多い。

そこで、参照されることは多数あるが追加、変更されることが滅多にないものパブリックブロックチェーンに載せて、データ置き場として活用する方法を考えれば、

ブロックチェーンを使って低コストで何かをすることは可能かもしれない。


用途2: 作りっぱなしのシステム

ブロックチェーンは、誰も管理しなくても動く夢のような仕組みだ。

ブロックチェーンと、staticなHTMLjsなり、なんかのスクリプトなりがあれば成り立つシステムを作ると、作った人が何もしなくてもネットワークが維持されるシステムの完成だ。

気軽に作って、誰も運用しなくても勝手に回るシステムが作れる。本当に素晴らしいことだ。

2018-01-26

anond:20180126225849

仮想通貨のことを「暗号通貨は…」って言ったら「え、仮想通貨の間違い?www」と訂正されたことあるけど、英語を直訳すると暗号通貨のほうが正しいしそいつ絶対ハッシュ関数のハの字もしらないよなぁ

2017-11-28

https://anond.hatelabo.jp/20171128044314

量子コンピューター一般化したら

ビットコインは上がるの?下がるの?関係ないの?

前提

量子コンピューター一般化したら 」というと焦点がぼやけるから

現行の公開鍵暗号方式秘密鍵や、

ハッシュ関数の逆変換が簡単に求められるようになったら

という前提でいこう。

 

考え方

何か中央集権的な手段で、過去取引履歴保護してやらないかぎり

下がるというか、価値ゼロになる。

なぜならば過去取引履歴自由捏造できるようになるため。

 

ビットコインでは過去取引履歴から口座の残高を求めるので、取引履歴捏造されると

ある人はあなたの口座には100BTCがあると言い、

別の人はあなたの口座には1BTCも入っていないと言う状況になる。

そして、どちらが正しいかを判定する手段は無い。

 

しかし、過渡期に量子コンピュータでも有効ハッシュ関数などを使って

「『正しい』過去取引履歴」が中央集権的に確定させることはできる。

そうすれば前述の問題は発生しなくなる。

ブロック生成の仕様を、量子コンピュータでも解けない計算に切り替えれば、

運用も続けられる。

 

結論

中央集権的な仕組みを入れないとする原則を貫くなら、無価値になる。

しかしその原則を破って価値を保つことは可能である

実際にはビットコイン価値を保つ方を、人々は選ぶだろう。

2017-09-11

https://anond.hatelabo.jp/20170910205249

まじな話をすると、N予備校プログラミング入門コースやるのがオススメ

https://www.nnn.ed.nico

一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。

月額1000円だけどしっかり勉強すれば一ヶ月の無料間中に終わると思う。

もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラム講師曰く去年はこれで二人エンジニア就職を決めたらしい。

内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職必要な環境構築やセキュリティまでみっちりやる。

http://qiita.com/sifue/items/7e7c7867b64ce9742aee#%E3%82%B3%E3%83%B3%E3%82%BB%E3%83%97%E3%83%88%E3%82%92%E3%82%82%E3%81%A8%E3%81%AB%E6%A7%8B%E6%88%90%E3%81%95%E3%82%8C%E3%81%9F%E3%82%B3%E3%83%BC%E3%82%B9%E3%81%A8%E5%86%85%E5%AE%B9

講師が書いてる入門コースで習うことがまとめ。テキスト教材もあるけど授業も1項目を2時間で説明している。授業は週2の生放送とそのアーカイブがある。

↓みたいなことが学べる

----

Webプログラミング入門コース

Web ブラウザとは (Chrome, デベロッパーコンソール, alert)

はじめてのHTML (VSCode, HTML, Emmet)

さまざまなHTMLタグ (h, p, a, img, ul, tableタグ)

HTMLで作る自己紹介ページ (HTMLタグ組み合わせ, コンテンツ埋め込み)

はじめてのJavaScript (JS, ES6, エラー)

JavaScriptでの計算 (値, 算術演算子, 変数, 代入)

JavaScript論理を扱う (論理値, 論理積, 論理和, 否定, 比較演算子, if)

JavaScriptループ (ループ, for)

JavaScriptコレクション (コレクション, 配列, 添字, undefined)

JavaScript関数 (関数, 関数宣言, 引数, 戻り値, 関数呼び出し, 再帰)

JavaScriptオブジェクト (オブジェクト, モデリング, プロパティ, 要件定義)

はじめてのCSS (CSS, セレクタ, background-color, border)

CSSを使ったプログラミング (transform, id, class)

Webページの企画とデザイン (企画, 要件定義, モックアップ, 16進数カラーコード)

診断機能の開発 (const, let, JSDoc, インタフェース, 正規表現, テストコード)

診断機能組込み (div, 無名関数, アロー関数, ガード句, truthy, falsy)

ツイート機能の開発 (リバースエンジニアリング, URI, URL, URIエンコード)

Linux開発環境構築コース

LinuxというOS (VirtualBox, Vagrant, Ubuntuインストール, OS, CUIの大切さ)

コンピューター構成要素 (ノイマンコンピューター, プロセス, lshw, man, ps, dfの使い方)

ファイル操作 (pwd, ls, cd, mkdir, rm, cp, mv, find, ホストマシンとの共有ディレクトリ)

標準出力 (標準入力標準出力標準エラー出力パイプgrep)

vi (vimtutor)

シェルプログラミング (シバン, echo, read, 変数, if)

通信ネットワーク (パケット, tcpdump, IPアドレス, TCP, ルーター, ping)

サーバークライアント (tmux, nc, telnet)

HTTP通信 (http, https, DNS, hostsファイル, ポートフォワーディング)

通信をするボットの開発 (cron, ログ収集)

GitHubウェブサイトの公開 (GitHub, リポジトリ, fork, commit, 情報モラル)

イシュー管理とWikiによるドキュメント作成 (Issues, Wiki)

GitとGitHub連携 (git, ssh, clone, pull)

GitHubへのpush (init, add, status, インデックス, commit, push, tag)

Gitのブランチ (branch, checkout, merge, gh-pages)

ソーシャルコーディング (コンフリクト、プルリクエスト)

Webアプリ基礎コース

Node.js (Node.js, nodebrew, Linux, REPL, コマンドライン引数, プルリク課題)

集計処理を行うプログラム (集計, 人口動態CSV, Stream, for-of, 連想配列Map, map関数)

アルゴリズムの改善 (アルゴリズム, フィボナッチ数列, 再帰, time, プロファイル, nodegrind, O記法, メモ化)

ライブラリ (ライブラリ, パッケージマネージャー, npm)

Slackボット開発 (slack, mention, bot)

HubotとSlackアダプタ (hubot, yo)

モジュール化された処理 CRUD, オブジェクトライフサイクル, filter)

ボットインタフェースとの連携 (モジュールのつなぎ込み, trim, join)

同期I/Oと非同期I/O (同期I/O, 非同期I/O, ブロッキング)

例外処理 (try, catch, finally, throw)

HTTPサーバー (Web, TCPとUDP, Webサーバーの仕組み, Node.jsイベントループ, リスナー)

ログ (ログ, ログレベル)

HTTPのメソッド (メソッド, GET, POST, PUT, DELETE, CRUDとの対応)

HTMLフォーム (フォームの仕組み, form, input)

テンプレートエンジン (テンプレートエンジン, jade)

HerokuWebサービスを公開 (Webサービスの公開, heroku, dyno, toolbelt, login, create, logs)

認証利用者を制限する (認証, Basic認証, Authorizationヘッダ, ステータスコード)

Cookie を使った秘密匿名掲示板 (Cookie, Set-Cookie, expire)

UI、URI、モジュール設計 (モジュール設計, フォームメソッド制限, リダイレクト, 302)

フォームによる投稿機能の実装 (モジュール性, textarea, 303)

認証された投稿の一覧表示機能 (パスワードの平文管理の問題, 404, テンプレートのeach-in)

データベースへの保存機能の実装 (データベース, PostgreSQL, 主キー)

トラッキングCookieの実装 (トラッキング Cookie, IDの偽装, Cookie の削除)

削除機能の実装 (データベースを利用した削除処理, 認可, サーバーサイドでの認可)

管理者機能の実装 (Web サービス管理責任, 管理者機能の重要性)

デザインの改善 (Bootstrap, レスポンシブデザイン, セキュリティの問題があるサイトを公開しない)

脆弱性 (脆弱性, 脆弱性で生まれる損失, 個人情報保護法, OS コマンド・インジェクション)

XSS脆弱性対策 (XSS, 適切なエスケープ処理, リグレッション)

パスワード脆弱性対策(ハッシュ関数, メッセージダイジェスト, 不正アクセス禁止法, パスワードジェネレーター, 辞書攻撃)

セッション固定化攻撃脆弱性対策 (セッション, セッション固定化攻撃, ハッシュ値による正当性チェック)

より強固なセッション管理 (推測しづらいセッション識別子, 秘密鍵)

CSRF脆弱性対策 (CSRF, ワンタイムトークン)

安全なHerokuへの公開 (脆弱性に対する考え方, HTTPの廃止)

Webアプリ応用コース

Webフレームワーク (Express.js, フレームワーク導入, 簡単なAPI, セキュリティアップデート, Cookie パーサー, ミドルウェア, 外部認証, ロガー)

ExpressのAPI (app, Properties, Request, Response, Router)

GitHubを使った外部認証 (Passport, OAuth)

スティングフレームワーク (Mocha, レッド, グリーン, リファクタリング)

継続的インテグレーション (CircleCI)

クライアントフレームワーク (Webpack, Chrome 以外のブラウザでもES6)

DOM操作フレームワーク (jQuery, jQueryアニメーション, this)

AJAX (jQuery.ajax, クロスドメイン, 同一生成元ポリシー, x-requested-by, CORS)

WebSocket (WebSocket, WebSocketの状態遷移, Socket.io)

RDBとSQL (DDL, DCL, CREATE, DROP, INSERT, DELETE, UPDATE, WHERE)

データモデリング (リレーショナルモデル, 正規化)

テーブルの結合 (外部結合, 内部結合, 片側外部結合, JOIN ON)

インデックス (インデックス, 複合インデックス, Bツリー)

集計とソート (SUM, COUNT, ORDER BY, GROUP BY)

「予定調整くん」の設計 (要件定義、用語集、データモデル、URL設計モジュール設計、MVC)

認証とRouterモジュールの実装 (Mocha, supertest, passport-stub, モックテスト)

予定とユーザーの保存 (セキュリティ要件, UUID, 複合主キー)

予定とユーザーの一覧の表示 (非同期処理, Promise, then)

出欠とコメントの表示 (入れ子の連想配列, Promise.all, 子どもからデータを消す)

出欠とコメント更新 (Promiseチェイン, リファクタリング)

予定の編集と削除 (要件の衝突, 関数再利用)

デザインの改善 (this, グローバルオブジェクト)

セキュリティ対策と公開 (X-Frame-Options, Heroku環境変数)

2016-01-05

[][][][]

原理から学ぶネットワーク・セキュリティ - 第4回 ハッシュ関数:ITpro

同じ人がいったんパスワードを変更して,再び元に戻してもshadowファイルソルトのおかげで元には戻らず,パスワードが元と同じものとは,設定者以外には分からないのです。


Googleで以前使用したパスワードを設定したいなら! - pochi-pの絵日記

皆さんももしGmail等を使っていてGoogleパスワードを以前のものに戻したくなったら、是非「100回無関係パスワードに変更して、それから以前のパスワードに変更」してみてくださいね

2015-12-19

[][][]

bitcoin・blockchain

ビットコイン - Wikipedia


はてなブックマーク - 新井俊一のソフトウェアビジネスブログ: 今話題のブロックチェーンとは何なんだ? 部外者の技術者として考察してみる。

はてなブックマーク - イーサリアム共同創業者Vitalik Buterinが語る、ブロックチェインの真の価値 | ビットコインニュースのBTCN

「ビットコインはインターネットの再来だ」

ビットコインがブロックチェーンより重要な理由 | TechCrunch Japan

ブロックチェーン技術は、蒸気機関や燃焼機関と同様に扱われるべき世紀の発明であり、金融界どころか、その外までをも変貌させてしまう可能性を秘めている。」

http://jp.cointelegraph.com/news/115873/what-is-the-reason-that-a-world-financial-institution-invests-in-a-block-chain-technology-as-a-favorite-of-the-fin-technical-center-all-togetherjp3

ロシアの政治家でIT起業家でもあるニコライ・ニキフォロフはブロックチェーンテクノロジーに注目


ハッシュ関数改ざんを検出する

http://itpro.nikkeibp.co.jp/article/COLUMN/20071031/286012/?ST=selfup&P=2



Amazon.co.jp: 仮想通貨革命 電子書籍: 野口 悠紀雄: Kindleストア

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

2014-07-15

http://anond.hatelabo.jp/20140715162504

めんどくさいからハッシュ関数で生成してる。

管理パスワードマネージャ任せだけど、無くしてもたいてい何とかなるのが便利。

マスターパスワード適当に決めて、サービス名(YahooとかHatenaとか)と組み合わせて変換した上で

ハッシュ関数にかけた下位何桁かを登録用に使ってる。

2013-03-23

プロテクト強化後のもふったーも予想以上に酷かった件(追記あり)

ことのあらまし
  1. Twitterクライアントもふったーの作者「TweetDeckのconsumer secret簡単に抜ける、終わってる」(http://blog.livedoor.jp/blackwingcat/archives/1760823.html)
  2. 別の誰か「もふったーのconsumer secretも簡単に抜ける」(http://d.hatena.ne.jp/kusano_k/20130318/1363640368)
  3. もふったーの作者「プロテクト強化した」(http://blog.livedoor.jp/blackwingcat/archives/1762970.html)

プロテクトかけたアルゴリズムを実装したバージョン差し替え」たなんて言われると本当に「プロテクト」がかかっているのか確かめてみたくなるのが人情というもの。というわけで、プロテクト強化後のもふったー(v0.9.6b)からconsumer secretが抜けるか試してみた。結論から言うと、あっけなく取り出せた。以下に手順を記す。

手順

動作がよくわかっていないアプリケーションを解析して仕様を明らかにすることをリバースエンジニアリングと呼ぶ。ソフトウェアリバースエンジニアリングは基本的に対象を逆アセンブルしてひたすら読むことによって行う(その補助に1命令ずつ実行してレジスターやメモリーの様子を観察することもある)。しかし、よっぽど小規模なものでなければオブジェクトコード全体を逆アセンブルして最初から最後まで読むなんてのは不可能だ。人間の読速度には限界があるし、時間も有限だからだ。そして、詳しい動作を知りたい部分というのは全体のごく一部であることが多いので全逆アセンブリを読むのには非常に無駄が多い。

からリバースエンジニアリングはいかに詳らかにすべき動作を行っているコードを絞り込むか(=読むべき逆アセンブリを少なくするか)が重要になる。

この場合も同様だ。TwitterGUIクライアントを頭から読むのは到底無理なので、どうやって解析すべきコードの範囲を狭めるかを考えた。それにはOAuth認証においてconsumer secretがどのような役割を果たすのかを知る必要がある。

OAuth認証で、consumer secretはそのままサーバーに送信されたりはしない。signatureの生成にHMAC-SHA1が使われ、その鍵にconsumer secretが使われる。HMACは次のように算出される。

HMAC (K,m) = H ((K ⊕ opad) ∥ H ((K ⊕ ipad) ∥ m))

ここで

である

まずはこのあたりから攻めようと思った。SHA-1計算はいくつか特徴的な定数が使われるので、そこからSHA-1計算に使われているであろう関数444190を特定する。この関数エントリーポイントに中断点(ブレークポイント)を設定してOAuth認証をさせるべくもふったーの「ブラウザ認証ボタンを押す。狙い通り中断するので関数を抜けるまで実行する。関数401100の4012DAに出た。少し下を見るとこのようになっている。

CPU Disasm
Address   Hex dump          Command                                      Comments
00401311  |.  33F6          xor     esi, esi
00401313  |   8D8C24 A40000 /lea     ecx, [local.54]
0040131A  |.  394C24 14     |cmp     dword ptr ss:[local.90], ecx
0040131E  |.  75 0E         |jne     short 0040132E
00401320  |.  3BF5          |cmp     esi, ebp
00401322  |.  73 29         |jae     short 0040134D
00401324  |.  0FB68434 A400 |movzx   eax, byte ptr ss:[esi+esp+0A4]
0040132C  |.  EB 21         |jmp     short 0040134F
0040132E  |   3BF5          |cmp     esi, ebp
00401330  |.  73 1B         |jae     short 0040134D
00401332  |.  8B5424 18     |mov     edx, dword ptr ss:[local.89]
00401336  |.  52            |push    edx                                 ; /Arg1 =  [LOCAL.89]
00401337  |.  8D8C24 FC0000 |lea     ecx, [local.33]                     ; |
0040133E  |.  8BD6          |mov     edx, esi                            ; |
00401340  |.  E8 CB4D0000   |call    00406110                            ; \mofooter.00406110
00401345  |.  83C4 04       |add     esp, 4
00401348  |.  0FB6C0        |movzx   eax, al
0040134B  |.  EB 02         |jmp     short 0040134F
0040134D  |   33C0          |xor     eax, eax
0040134F  |   34 5C         |xor     al, 5C
00401351  |.  888434 B80000 |mov     byte ptr ss:[esi+esp+0B8], al
00401358  |.  83C6 01       |add     esi, 1
0040135B  |.  83FE 40       |cmp     esi, 40
0040135E  |.^ 72 B3         \jb      short 00401313
00401360  |.  895C24 3C     mov     dword ptr ss:[local.80], ebx
0040134F  |   34 5C         |xor     al, 5C

が注意を引く。もしかしてこれはopadとのxorではないか?

00401351  |.  888434 B80000 |mov     byte ptr ss:[esi+esp+0B8], al

xorした結果を格納している。

先ほどの中断点は無効化しこのループを抜けた地点である401360まで飛ばす。この時点でesp+0B8を見ると次のようになっている。

Hex dump
64 2E 16 64|37 04 32 6D|0F 0D 26 29|3A 37 1F 2F|
18 69 6E 6E|0D 25 29 33|11 34 29 69|12 36 24 1E|
05 16 33 6A|04 3B 0E 68|7A 5C 5C 5C|5C 5C 5C 5C|
5C 5C 5C 5C|5C 5C 5C 5C|5C 5C 5C 5C|5C 5C 5C 5C|

あとはこれと5Cとをxorすればconsumer secretが手に入る。終わり。

追伸

はてな増田スーパーpre記法で半角の<>が含まれていると投稿が出来ないのを早く直してください。

3/23 18:45追記

もふったーの作者から反応があった。「本気だったつもりのもふったーのデバッグ処理が残ってた」らしい(http://blog.livedoor.jp/blackwingcat/archives/1763951.html)。修正したとのことなので最新版(v0.9.6e)を見てみた。確かに若干変更されているが何の問題もない。SHA-1の呼び出しに中断点を設置して渡されているバイト列を見るだけ。

CPU Disasm
Address   Hex dump          Command                                  Comments
00401324  |.  8D4424 20     |lea     eax, [local.102]
00401328  |.  50            |push    eax                             ; /Arg1 = 
00401329  |.  E8 623A0400   |call    00444D90                        ; \mofooter.00444D90

ここでeaxが指すメモリーを見ると以下のようになっている。

01 23 45 67|89 AB CD EF|FE DC BA 98|76 54 32 10|
F0 E1 D2 C3|00 02 00 00|00 00 00 00|40 00 00 00|
40 4F 73 53|62 54 5C 7E|59 57 53 42|55 45 7A 57|
61 47 7A 5B|42 4F 7B 61|5D 66 5E 7A|42 7F 40 63|
79 66 05 55|79 4C 60 42|02 10 36 36|36 36 36 36|
36 36 36 36|36 36 36 36|36 36 36 36|36 36 36 36|

先頭32バイトゴミ無視して0x36とxorすればconsumer secretが得られる。

2012-05-05

http://anond.hatelabo.jp/20120505001212

なんか sha1md5 などによるハッシュ化に似たような話だね。

それらのハッシュ関数はその原理上、衝突することが避けられない。

その解釈と数値というものも、衝突という概念があり得るものなら別物の可能性があるし、無いなら両者は同じものでしょ。

2009-05-16

http://anond.hatelabo.jp/20090516121216

一言でバイナリツリーと言っても

実はレッドブラックだったり、

積み込みをどこで均一化するか?とかハッシュ関数はどうするか?

削除するときに木の均衡をどうするか?

メモリは事前に取るのか?キャッシュはするか?

など、B木といっても山ほどアルのでB木と書いても、山ほどやることはあるので

どんなB木かってのは、もっと書き込まないとわからないとおもう。

少なくともB木というだけでは何も説明できていないとおもう。

逆に、その程度なら、関数名を なんちゃらBtreeと書いておけば済むことだと思う。

最悪のツリー構造バイナリーツリーじゃぁ、ベクターの方がマシだし。

その部分をどうしたか?という部分が重要で、それって、日本語で書いた方が長くならない?

C言語コメントの方がわかりやすくない?

やっぱり、横暴かなぁ。バランスが難しいです。

2009-03-27

ハッシュ関数を調べた

http://anond.hatelabo.jp/20090326142330 の続き

pythonでベンチとった。試した方法は以下

  1. md5hex: md5を使う
  2. crc32x4: 4分割してそれぞれcrc32にかけてつなぐ
  3. headtail: 初めの16文字と終りの16文字をつなぐ
  4. skipover: 等間隔に32文字とる

長くなるので、使用したスクリプトと生の結果は http://anond.hatelabo.jp/20090326123924 に貼った。

結果としては、早さは3, 4, 1, 2の順で、3を基準にとると、

文字列md5hexcrc32x4headtailskipoverループ回数
2566.6361.01.465536
10248.3361.02.016384
409626851.02.54096

という比率になった。

文字列長が長くなるとやはり後2つが有利だ。また、今回は32文字に切り詰めたがそれでもコリジョンは発生しなかった。アルゴリズム上、数文字だけの変化には対応出来ない可能性があるが、切り詰める量が少なく入力にいくらかのランダム性があれば実用になると思う。

(追記:URLで使ったら、ランダム性が悪くてコリジョン出た。素直にmd5ベターかもしれない)

しかし、この程度の速度差であれば、コリジョン耐性を重視して素直にmd5を使用するのも良いかもしれない。特に、今時はネイティブコードライブラリをほぼ標準で持つ処理系が多いため、まずはmd5で、としても間違いはなさそう。

2009-03-26

ハッシュ関数を調べる

セキュリティ目的ではない。ハッシュテーブルで使うような奴でキャッシュで使いたい。

手軽なほうが良い。軽いほうが良い。推測可能でよい。数十バイトくらいの文字列にしたい。

md5が一番汎用っぽいけど、無駄に重い気がする。crc32は軽そうだしそれなりに汎用っぽいけど、ハッシュ長が短いのがめんどい

ベターはなんだろう。セオリーはなんだろう。

調べた→ http://anond.hatelabo.jp/20090327015620

ベンチ用スクリプト

#!/usr/local/bin/python
from sys import argv, stderr
from time import time
from string import ascii_letters, join
from random import choice
from hashlib import md5
from binascii import crc32
from itertools import izip

time_fmt = '%10s: %5d ms'
shift = int(argv[1]) if len(argv)>1 and argv[1].isdigit() else 2
length = 0x100 << shift
cycle = 0x10000 &gt;&gt; shift
print &gt;&gt; stderr, 'string length: 0x%x, cycle: 0x%x' % (length, cycle)
data = tuple(''.join(choice(ascii_letters) for i in xrange(length)) for j in xrange(cycle))

start = time()
md5hex = tuple(md5(s).hexdigest() for s in data)
print &gt;&gt; stderr, time_fmt % ('md5hex', (time() - start) * 1000)

start = time()
crc32x4 = tuple(''.join('%08x' % abs(crc32(s[i::4])) for i in (0, 1, 2, 3)) for s in data)
print &gt;&gt; stderr, time_fmt % ('crc32x4', (time() - start) * 1000)

start = time()
startend = tuple(s[:16]+s[-16:] for s in data)
print &gt;&gt; stderr, time_fmt % ('headtail', (time() - start) * 1000)

start = time()
skip = tuple(s[::(len(s)/32+1)] for s in data)
print &gt;&gt; stderr, time_fmt % ('skipover', (time() - start) * 1000)

for s in izip(data, md5hex, crc32x4, startend, skip):
    print join(s)

実行結果

% python hashbench.py 0 &gt; hash0.txt
string length: 0x100, cycle: 0x10000
    md5hex:   199 ms
   crc32x4:  1081 ms
  headtail:    30 ms
  skipover:    41 ms
% python hashbench.py 2 &gt; hash1.txt
string length: 0x400, cycle: 0x4000
    md5hex:    83 ms
   crc32x4:   363 ms
  headtail:    10 ms
  skipover:    20 ms
% python hashbench.py 4 &gt; hash2.txt
string length: 0x1000, cycle: 0x1000
    md5hex:    52 ms
   crc32x4:   170 ms
  headtail:     2 ms
  skipover:     5 ms

2007-05-26

ころころアカウント変える奴がウザイ

その分だけ他の人が選べる文字列が減っていく事に少しは申し訳ないと思わないのかね。他人と被らないような、全然脈絡のない文字列にして欲しい。ハッシュ関数みたいなやつ。

つーかチラシの裏にでも書いてろよ。

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